Assignment 1: SE2-Software Design & Architecture
(CS446/CS646/ECE452) Spring 2011

Main|Schedule|Term Project

Assignment 1: (Due on June 8th, 2011)

Goal:

You are to produce a pdf report that documents the architecture of the software that you propose to develop for your proposed (term project) system. Your target audience is a manager, project manager and/or system designer who is somewhat but not intimately familiar with your project.

In this assignment you will produce two different architectures for your proposed system. You will then compare the strength and weaknesses of each and select one out of the two. Your selection should be backed up by your analysis report.

Report:

You report should include the following sections:

Cover matter

Introduction and Overview: About 1 to 3 pages summarizing the purpose of report, its organization, and its salient conclusions. A person should be able to read just the abstract or just the introduction and have a good idea what is in the rest of your report.

Architecture: Give the overall structure of the system that you are proposing to implement, with descriptions of each major component and of the interactions among them. These components are to be primarily packages, subsystems or modules, but also include threads or processes (as in Unix processes), files, and data bases. In your descriptions, concentrate on goals, requirements, evolvability, testability, etc., rather than on lower level concepts such as classes, variables and control flow. However, you should clarify global control flow, such as units of concurrency and method of passing control from one component to another. Your system's architecture should be easy to understand, with simple interfaces, and modest interactions among packages, subsystems and modules.

Architectural style: Clarify what style of architecture (in the sense of Garlan and Shaw) that you are proposing.

Level of detail: You are not to concentrate on minor components, such as classes and procedures, which are smaller than packages or modules. However, you may wish to discuss important abstractions, patterns, classes, data structures or algorithms that are critical to the successful implementation of your architecture.

Diagrams: You should use diagrams that clearly illustrate the structure of your system. You may choose to use various kinds of UML diagrams. Do not give diagrams that are too low level, eg, do not give diagrams of details within objects, nor within modules. You can use tools such to help you draw diagrams, but this is not required. Do not include diagrams that are difficult to read.

External Interfaces: List information transmitted to/from the system, such as by Graphical User Interfaces, files, data bases, messages or networks. Do not give details such as menus, but rather concentrate on information content. Although the information to be stored in a database should be specified, the form of this data need not be given.

Use Cases: Give a small number of essential Use Cases that illustrate the use of the your system. Show or explain how each Use Case activates or uses the various major parts of your proposed architecture.

Data Dictionary: Include a glossary that briefly defines the key terms used in your architecture, giving when appropriate, the "type" (such as a class, module, algorithm, subsystem, etc.) of the item being explained.

Naming Conventions: List any naming conventions used in your architecture. Explain any abbreviations that you use.

Test Plan: Briefly describe how you plan on testing your system. (Perhaps a page.)

Methodology and Cost: Give a plan for how the system is to be implemented, (what modules and subsystems in what order, by whom and how to do unit testing), with estimates of number of lines in each module and number of person hours to both implement and unit test each module. (You are to record this same information during your development, to compare with these estimates.) (Roughly a page or two.)

Performance: Discuss any parts of the system that are likely to be performance critical, i.e., which might not run fast enough. (Perhaps a quarter page.)

Evolvability: Discuss how your architecture is designed to support future changes in the your system. (Perhaps a page.)

Feasibility Studies: Investigate and report on the feasibility of key or risky parts of your system. You may wish to do small prototypes investigating the use of these. (Perhaps one or two pages.)

References: List any documents that your reader may wish to or need to read in conjunction with your report. Since the report is to be web readable, include links to references when appropriate.

Constraints


Last updated on: May 26th, 2011 by Atif Khan.