Artifacts > Analysis & Design Artifact Set > Design Model


Design Model
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.
UML representation: Model, stereotyped as «design model».
Role: Designer
More information:
  • Guidelines:Design Model
  • Guidelines:Generalization
  • Checkpoints:Design Model
  • Checkpoints:Design Guidelines

Input to Activities:
  • Architectural Analysis
  • Class Design
  • Design Test
  • Perform Unit Tests
  • Plan Test
  • Review the Design
  • Use-Case Analysis
Output from Activities:
  • Architectural Analysis






Templates, Case-Study, Report.. To top of page

The Word template can be bought through a template package. Case studies and reports are freely available in the table below.

Word
Template
Case
Study
Report
---

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. - " -
Use-Case Realizations The 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. The design model is continuously kept consistent with the use-case model and the implementation model.

Responsibility To top of page

A designer 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 view.

Note that the packages, classes, relationships, use-case realizations, and the diagrams themselves 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 and to the implementation model (see Guidelines: Design Model)
  • if the design model will be elaborated to become executable and testable
  • if the design model will be elaborated in order to allow the final code to be generated
Feedback © 2014 Polytechnique Montreal