The design model is an object model describing the realization of use cases, and serves as an abstraction of the implementation model and its source code. The design model is used as essential input to activities in implementation and test. 
Other Relationships:  Contains
Role:  Software Architect 
Optionality/Occurrence:  Required. Elaboration and Construction phases.
Templates and Reports: 
Examples: 
UML Representation:  Model, stereotyped as <<designModel>>. 
More Information:   
Input to Activities:    Output from Activities:   

Purpose To top of page

The design model is an abstraction of the implementation of the system. It is used to conceive as well as document the design of the software system. It is a comprehensive, composite artifact encompassing all design classes, subsystems, packages, collaborations, and the relationships between them.

Properties To top of page

Property Name 

Brief Description 

UML Representation 

Introduction  A textual description that serves as a brief introduction to the model.  Tagged value, of type "short text". 
Design Packages

Design Subsystems 

The packages and subsystems in the model, representing a hierarchy.   Owned via the association "represents", or recursively via the aggregation "owns". 
Classes  The classes in the model, owned by the packages.  Owned recursively via the aggregation "owns". 
Capsules  The capsules in the model, owned by the packages.  Owned recursively via the aggregation "owns". 
Interfaces  The interfaces in the model, owned by the packages.  Owned recursively via the aggregation "owns". 
Protocols  The protocols in the model, owned by the packages.  Owned recursively via the aggregation "owns". 
Events and Signals  The events and signals in the model, owned by the packages.  Owned recursively via the aggregation "owns". 
Relationships  The relationships in the model, owned by the packages.  - " - 
Design Use-Case Realizations  The design use-case realizations in the model, owned by the packages.  - " - 
Diagrams  The diagrams in the model, owned by the packages.  - " -  

Timing To top of page

The design model primarily sets the architecture, but is also used as a vehicle for analysis during the elaboration phase. It is then refined by detailed design decisions during the construction phase.

Responsibility To top of page

A software architect is responsible for the integrity of the design model, ensuring the following:

  • The design model as a whole is correct, consistent, and readable. The design model is correct when it realizes the functionality described in the use-case model, and only this behavior.
  • The architecture in the design model fulfills its purpose, including the logical, process, and deployment views. These views are collected in a separate artifact, see Artifact: Software Architecture Document.

Note that the software architect is not responsible for the packages, classes, relationships, design use-case realizations, and the diagrams themselves; instead, these are under the corresponding designers and use-case designer's responsibilities.

Tailoring To top of page

Decide on the following:

  • properties to include
  • whether or not any extensions to the Unified Modeling Language (UML) are needed; for example, your project may require additional stereotypes
  • the level of formality applied to the model
  • tailoring applicable to individual sub-artifacts
  • how the model is mapped to the analysis model (see Guidelines: Design Model)
  • whether a single model or multiple models will be used
  • whether the model will be an abstract specification, a detailed specification, a detailed design, or some combination (see Guidelines: Design Model)
  • how the model is mapped to the implementation model (this is very much affected by the decision to use reverse-engineering, code generation, or round-trip engineering); see Guidelines: Mapping from Design to Code

Document tailoring decisions in your project's design guidelines (see Artifact: Project-specific Guidelines) .



Rational Unified Process   2003.06.13