Artifact: Implementation Model
| The Implementation Model represents the physical composition of the implementation in terms of Implementation Subsystems, and Implementation Elements (directories and files, including source code, data, and executable files). | |
| Other Relationships: | Contains - Implementation Subsystem - Implementation Element - Testability Element - Test Stub |
| Role: | Software Architect |
| Optionality/Occurrence: | Optional. Elaboration and Construction phases. |
| Templates and Reports: | |
| Examples: | |
| UML Representation: | Model, stereotyped as <<implementation model>>. |
| More Information: | - Guideline: Component Diagram - Checklist: Implementation Model - Guideline: Implementation Model - Guideline: Import Dependency in Implementation - Guideline: Manifest Dependency |
| Input to Activities: - Describe Distribution - Identify Targets of Test - Identify Test Ideas - Implement Test Suite - Plan Subsystem Integration - Plan System Integration - Set Up Configuration Management (CM) Environment - Structure the Implementation Model | Output from Activities: - Structure the Implementation Model |
Purpose
The Implementation Model identifies the physical parts of the implementation so that they can be better understood and managed. The Implementation Model defines the major units of integration around which teams are organized, as well as the units that can be separately versioned, deployed, and replaced.
A more detailed Implementation Model may also include low level source code and derived files, and their relationship to the Design Model. Such detail is recommended only if you have automated synchronization between the model and the files.
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” |
| Implementation Subsystems | The subsystems in the model, representing a hierarchy | Owned via the meta-association “represents”, or recursively via the meta-aggregation “owns” |
| Implementation Elements | The elements in the model, owned by the subsystems | Owned recursively via the meta-aggregation “owns” |
| Relationships | The relationships in the model, owned by the Implementation Subsystems | - “ - |
| Diagrams | The diagrams in the model, owned by the Implementation Subsystems | - “ - |
| Implementation View | The implementation view of the model, which is an architectural view showing the Implementation Subsystems and layers | Elements and diagrams in the view are owned recursively via the meta-aggregation “owns” |
Timing
The Implementation Model structure is established in the Elaboration Phase, and is refined as needed in the Construction Phase.
Responsibility
A software architect is responsible for the integrity of the Implementation Model, and ensures that:
- The Implementation Model as a whole is correct, consistent, and readable. The Implementation Model is correct when it meets all requirements, and is consistent with the Design Model.
- The architecture in the Implementation Model, described in the Implementation View, fulfills its purpose. The Implementation View is described in a separate artifact, refer to the Artifact: Software Architecture Document.
Note that the software architect is not responsible for the Implementation Subsystems and Implementation Elements. instead, these are under the corresponding implementer’s responsibilities.
Tailoring
An Implementation Model is optional. If you choose to create an Implementation Model, the key tailoring decisions are how to relate between the Implementation Model and Design Model, and which Implementation Elements are important enough to model. Guidance on how to make these decisions is covered in Guidelines: Implementation Model. Also see Concepts: Mapping from Design to Code.