Work Product: Design Model
This work product 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.
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 work product encompassing all design classes, subsystems, packages, collaborations, and the relationships between them.

Relationships
RolesResponsible: Modified By:
Input ToMandatory: Optional: External:
  • None
Output From
Properties
Optional
PlannedYes
Illustrations
Examples
Tailoring
Representation Options

UML Representation: Model, stereotyped as <<designModel>>. 

A design model may have the following properties:

  • Introduction: A textual description that serves as a brief introduction to the model.  
  • Design Packages / Design Subsystems: The packages and subsystems in the model, representing a hierarchy.  
  • Classes: The classes in the model, owned by the packages.  
  • Capsules: The capsules in the model, owned by the packages.  
  • Interfaces: The interfaces in the model, owned by the packages.  
  • Protocols: The protocols in the model, owned by the packages. 
  • Events and Signals: The events and signals in the model, owned by the packages.  
  • 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. 

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-work products
  • how the model is mapped to the analysis model (see Guideline: 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 Guideline: 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 Concept: Mapping from Design to Code
More Information
Checklists
Concepts
Guidelines

©  Copyright IBM Corp. 1987, 2006.  All Rights Reserved.