Description

The high-level design captures the overall design of a system, with the organization of its main modules and their relationships. Taking time to do a carefully throughout design, reaps benefits when implementation starts. This is why we are doing 2 design documents: a high-level (initial) design and a low-level design which will include more details that are elided in the high-level design.

The high-level design should show the overall software architecture of the DCS-ALUMS system and should correspond to a system that provides the required functionality defined in your team's use cases. You will need to make a domain model of the system and then use it plus your use cases to create a high-level design. In your high-level design, you should explain the key modules and their interrelations, as well as some important classes (within the modules).

A suggested process to accomplish this design task is first to decide on an overall layered software architecture and its main modules. Second, have each team member take responsibility for initial design ideas for specific modules; try to divide up the work to be evenly distributed. Third, after initial designs are done, the team should discuss them, with each team member carefully reviewing at least one other team member's design; pair design readers to the module with which their own designed module has the most interactions. (This is called a design walk-through and is a technique used in the software industry.) Fourth, API definitions for modules and classes (i.e., submodules) should be prepared from these initial designs. Each module needs to know what it exports to other modules. These APIs should be complete, including definitions of types and visibility of attributes and public operations. Fifth, make sure to check that all pieces of the design are using the same API definitions and that all necessary functionality has been provided (you can use your use cases to help in this task).

Checking your APIs is very important to doing a consistent and complete high-level design. For each of the major modules, you need to make a list of all types and methods that are exported (i.e., public). There should be written declarations of each class and a type signature for each method, with necessary pre- and post-conditions included in comments. Any team member responsible for a module that imports from the module being checked, needs to make sure that s/he does not need to import more than what is described. It is suggested that the team make a dependence table for each module, to show other modules dependent on it, so if a design change is considered, it is easy to figure out which team members (i.e., directly responsible for dependent modules) need to be consulted. (Although this discussion has been on the level of modules, you need to also take these actions for the described classes within those modules.)

Recall that the use case document defined each team's choices for what they considered to be requirements for a kernel, usable, standard and super system. Similarly, you should do a design the standard system, but indicating which parts of the design correspond to the kernel and usable systems.

Deliverables

• a domain model (graphical)
• a design model (graphical) that shows the module-level relations between key parts of the system
• written documentation of the classes within each module of the design model, including discussion of their exports and imports, method pre-/post-conditions

Document format

• Title page containing: document title (e.g., Requirements for DCS-ALUMS project), name of the team, team members who contributed to this document (including the editor), course information (i.e., CS431, Prof Barbara Ryder, Scott Selikoff- TA) and date.
• Domain model This section demonstrates and discusses your (graphical) domain model for your system.
• Layered Design This section describes the layers in your high-level design, and presents the functionality covered by each layer. It discusses any assumptions about the environment in which your DCS-ALUMS software will be used, that affect this design. It presents a graph of the overall organization of the system with key classes in each module listed. The writeup should make clear why design decisions were made, especially if they were to accomodate possible changes as the software evolves.
• Design model This section presents in text with accompanying diagrams, the design of each layer in the system. This needs to show the attributes, operations and interrelations between the design classes. The description should make clear which parts of the design correspond to the possible kernel, usable and standard systems.
• Discussion This section should consider possible changes that clients may ask for over time (e.g., system improvements) and how resilient your design is with regard to these changes. What modules would be affected and how? Also, you should add things to your design that facilitate testing and debugging of your project.

Last updated by Barbara Ryder at 11:00am, October 15, 2006