Artifact:  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:	Software Architect
Reports:	Design-Model Survey
Examples:	Design Model, from the Course Registration System Design Model (in the combined Rose Model), from the Collegiate Sports Paging System (e-business)
More information:	Guidelines:Design Model Guidelines:Association Guidelines:Aggregation Guidelines:Generalization Guidelines:Import Dependency in Design Guidelines:Class Diagram Guidelines:Sequence Diagram Guidelines:Concurrency Guidelines:Collaboration Diagram Guidelines:Layering Guidelines:Subscribe-Association Guidelines:Statechart Diagram Checkpoints:Design Model
Purpose Properties Timing Responsibility Tailoring

Input to Activities: Manage Dependencies Identify Targets of Test Identify Test Ideas Database Design Implement Component Perform Unit Tests Describe the Run-time Architecture Structure the Implementation Model Construct Architectural Proof-of-Concept Review the Design Class Design Define Testability Elements Identify Design Elements Architectural Analysis Identify Design Mechanisms Incorporate Existing Design Elements Use-Case Analysis

Output from Activities: Identify Design Elements Architectural Analysis Identify Design Mechanisms Incorporate Existing Design Elements Use-Case Analysis

Purpose

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

Timing

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

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, use-case realizations, and the diagrams themselves; instead, these are under the corresponding designers and use-case designer's responsibilities.

Tailoring

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
• if the design model will be maintained to be consistent with the implementation, and to what extent it will be reverse-engineered from the implementation (see Tool Mentor: Reverse-Engineering Code Using Rational Rose®)  

Document tailoring decisions in the Artifact: Design Guidelines.

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process