The analysis model contains the analysis classes and any associated
artifacts. The analysis model may be a temporary artifact, as it is in the case
where it evolves into a design model, or it may continue to live on through some
or all of the project, and perhaps beyond, serving as a conceptual overview of
textual description that serves as a brief introduction to the model.
value, of type "short text".
packages in the model, representing a hierarchy.
via the association "represents", or recursively via the
classes in the model, owned by the packages.
recursively via the aggregation "owns".
relationships in the model, owned by the packages.
use-case realizations in the model, owned by the packages.
diagrams in the model, owned by the packages.
The Analysis Model is created in the Elaboration phase, and is updated in the
Construction Phase as the structure of the model is updated.
The software architect is responsible for the integrity of the Analysis Model,
- It is maintained in a current state, reflecting an abstracted overview of
Normally, "analysis classes" will evolve directly into elements in
the Design Model: some become design classes, others become design subsystems.
The goal of Analysis is to identify a preliminary mapping of required behavior
onto modeling elements in the system. The goal of Design is to transform this
preliminary (and somewhat idealized) mapping into a set of model elements which
can be implemented. As a result, there is a refinement in detail and precision
as one moves from Analysis through Design. As a result, the "analysis
classes" are often quite fluid, changeable, and evolve greatly before they
solidify in the Design activities.
Points to consider when deciding whether a separate Analysis Model is needed:
- A separate Analysis Model can be useful when the system must be designed
for multiple target environments, with separate design architectures. The
Analysis Model is an abstraction, or a generalization, of the Design Model.
It omits most of the details of the design in order to provide an overview
of the system’s functionality.
- The design is complex, such that a simplified, abstracted
"design" is needed to introduce the design to new team members.
Again, a well-defined architecture can server the same purpose.
- The extra work required to ensure that the Analysis & Design models
remain consistent must be balanced against the benefit of having a view of
the system which represents only the most important details of how the
system works. It can be very costly to maintain a high degree of fidelity
between the Analysis Model and the Design Model. A less ambitious approach
might be to maintain the Analysis Model with only the most important domain
classes and the key abstractions in the design. As the complexity of the
Analysis Model increases, so does the cost to maintain it.
- Once the Analysis Model is no longer maintained, its value decays rapidly.
At some point, if it is not maintained, it will cease to be useful as it no
longer will accurately reflect the current design of the system. Deciding to
no longer maintain the Analysis Model may be appropriate (it may have served
its purpose), but the decision should be a conscious one.
In some companies, where systems live for decades, or where there are many
variants of the system, a separate analysis model has proven useful.
© 1987 - 2001 Rational Software Corporation