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
|