TABLE OF CONTENTS The primary inputs to the design discipline come from the use case analysis and the analysis discipline. That is, the inputs to the design discipline are the use cases, the analysis use case realizations, and the analysis classes and packages identified in the analysis discipline. If, however, you have not carried out the analysis discipline then you must go back to using only the use case analysis, and use that as your starting point.
The design discipline differs from the analysis discipline as it is aimed at implementation abstraction, i.e. how the system should be built, rather than trying to rephrase the system requirements (at a high level of abstraction). That is, it provides the means to enable developers to visualize and reason about the implementation. It identifies major subsystems and their interfaces and deals with implementation-oriented constraints, classes and their responsibilities and operations, and inter-class relationships and their structures. Table 7.1 compares the analysis and design disciplines.
| Analysis workflow | Design workflow |
|---|---|
| Conceptual model | Physical model |
| Describes functional requirements | Determines how system will meet requirements |
| Only uses 3 types of class | Classes as appropriate |
| Less complex (1:5) | More detailed (5:1) |
| Less formal descriptions | More formal descriptions (e.g. visibility of attributes) |
| Created by workshops, interviews etc. | Created by prototypes, visual analysis, engineering |
There are four primary activities in the design discipline, these are:
Architectural/subsystem design. This was discussed in Chapter 4 on software architecture.
Generation of...
