Work Product (Artifact): Design Model








var defaultQueryStr = '?proc={002674F9-6511-4D15-8623-B761D8C48986}&path={002674F9-6511-4D15-8623-B761D8C48986},{C67C8E56-D9B6-499C-8171-C153FB28F1C3},_COQSJhi2Edq_uI8xTPML6g';
var backPath = './../../';
var imgPath = './../../images/';
var nodeInfo=null;
contentPage.preload(imgPath, backPath, nodeInfo, defaultQueryStr, false, true, false);










Work Product (Artifact): 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:



Software Architect


Modified By:



Software Architect





Input ToMandatory:



Construct Architectural Proof-of-Concept


Optional:



Architectural Analysis


External:


None




Output From


Architectural Analysis






Properties



Optional


Planned



Illustrations



Examples


CSPS Rose Model






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


Design Model





Concepts


Component


Structured Class





Guidelines


Aggregation


Association


Class Diagram


Communication Diagram


Concurrency


Design Model


Generalization


Import Dependency in Design


Layering


Representing Interfaces to External Systems


Sequence Diagram


Statechart Diagram


Subscribe-Association








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







contentPage.onload();
contentPage.processPage.fixDescriptorLinks();