Artifact: Analysis Model
| An object model describing the realization of use cases, and which serves as an abstraction of the Artifact: Design Model. The Analysis Model contains the results of use case analysis, instances of the Artifact: Analysis Class. | |
| Other Relationships: | Contains - Analysis Class |
| Role: | Software Architect |
| Optionality/Occurrence: | Optional. Elaboration and Construction phases. |
| Templates and Reports: | |
| Examples: | - Analysis Model |
| UML Representation: | Model, stereotyped as <<analysis model>>. |
| More Information: | - Concept: Analysis Mechanisms |
| Input to Activities: - Identify Design Elements - Review the Design - Use-Case Analysis - Use-Case Design | Output from Activities: - Define Automation Requirements - Use-Case Analysis |
Purpose
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 the system.
Properties
| 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. | -“ - |
Timing
The Analysis Model is created in the Elaboration phase, and is updated in the Construction Phase as the structure of the model is updated.
Responsibility
The software 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.
Tailoring
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.