Artifact: 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.
Artifact: Analysis Classes represent
roles played by instances of design elements; these roles may be fulfilled by
one or more design model elements. In addition, a single design element may
fulfill multiple roles. The following observations discuss the ways the analysis
roles may be fulfilled:
- An analysis class can become one single class in the design model.
- An analysis class can become a part of a class in the design model.
- An analysis class can become an aggregate class in the design model.
(Meaning that the parts in this aggregate may not be explicitly modeled in
the analysis model.)
- An analysis class can become a group of classes that inherits from the
same class in the design model.
- An analysis class can become a group of functionally related classes in
the design model.
- An analysis class can become a package in the design model (meaning that
it can become a component.)
- An analysis class can become a relationship in the design model.
- A relationship between analysis classes can become a class in the design
- Analysis classes handle primarily functional requirements, and model
objects from the "problem" domain; design classes handle
non-functional requirements, and model objects from the "solution"
- Analysis classes can be used to represent "the objects we want the
system to support," without taking a decision on how much of them to
support with hardware and how much with software. Thus, part of an analysis
class can be realized by hardware, and not modeled in the design model at
Any combination of the above are also possible.
You should decide before the design starts how classes in the design model
should relate to implementation classes; this should be described in the Design
Guidelines specific to the project.
The design model can be more or less close to the implementation model,
depending on how you map its classes, packages and subsystems to components,
packages and subsystems in the implementation model. During implementation, you
will often address small tactical issues related to the implementation
environment that shouldn't have impact on the design model. For example, classes
and subsystems can be added during implementation to handle parallel
development, or to adjust import dependencies. For more information, refer to Activity:
Structure the Implementation Model and Concepts:
Mapping from Design to Code.
There should be a consistent mapping from the design model to the
implementation model. The Artifact: Design
Guidelines should define this mapping, and a consistent level of abstraction
should be applied across the design model.
A good design model
has the following characteristics:
- It satisfies the system requirements.
- It is resistant to changes in the implementation environment.
- It is easy to maintain in relation to other possible object models and to
- It is clear how to implement.
- It does not include information that is best documented in program code.
- It is easily adapted to changes in requirements.
For specific characteristics, see Checkpoints:
© 1987 - 2001 Rational Software Corporation