Artifact: Analysis Model
The following people use the analysis model:
- The architect and designers, as the input to design.
- If the analysis model is maintained as a living artifact, new project members
use it to familiarize themselves with the system design. Used in this way, the analysis
model acts as an abstract overview of the design.
Property Name |
Brief Description |
UML Representation |
Introduction |
A textual description that serves as a brief introduction to the
model. |
Tagged value, of type "short text". |
Analysis Packages |
The packages in the model, representing a hierarchy. |
Owned via the association "represents", or recursively
via the aggregation "owns". |
Classes |
The classes in the model, owned by the packages. |
Owned recursively via the aggregation "owns". |
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. |
- " - |
This artifact is created following the Activity: Use
Case Analysis.
The Architect is responsible for the integrity of the Analysis Model, ensuring
that:
- It is maintained in a current state, reflecting an abstracted overview of the design.
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 systems 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 and 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.
| |

|