Artifact: Shared Model
This work product holds data shared among subsystems such as interfaces and data they share as well as internal design elements used by multiple subsystems.
Domains: Systems Architecture
Extends: Model
Purpose
The purpose of this work product is to represent the functionality, structure, behavior, and performance of the delivered system in a more usable, comprehensible, and reusable form, from which the actual system can be generated in a more-or-less automated fashion.
Relationships
Description
Main Description

The model can be thought of as a repository of semantic concepts and their interrelations, visualized by a set of views. These views can be:

  • Structural (e.g. class diagram, structure diagram, package diagram, source code)
  • Behavioral (e.g. state machine diagram, activity diagram)
  • Interaction (e.g. sequence diagram, timing diagram)
  • Functional (e.g. information flow diagram, use case diagram)
  • Performance (e.g. constraints modifying elements present in the other views)

A model the is composed of a great many contained artifacts or work products. In addition, a model can contain a nested model, such as a Platform-Independent Model (PIM) or Platform-Specific Model (PSM), which are themselves models within the over all model.

A "logical" model can be split across multiple physical realization models for developer convenience; indeed this is almost always the case for large models. A typical large-scale logical model consists of the following separate physical models:

  • System engineering model (specifies the overall system requirements as use cases and the overall system architecture)
  • Software Requirements model (specifies the use cases specific to the software development)
  • (Several) subsystem model (specifies the realization of each architectural unit)
  • Shared model (contains interfaces, classes and types shared among subsystem models)
NotationThe Unified Modeling Language (UML) is the primary language for the representation of models although other domain-specific representations (such as Fault Tree Analysis) are often used in conjunction with the UML.  
Selected RepresentationThe most important diagrams from the UML are: class, state, and sequence diagrams. Other diagrams add value but virtually all systems can be specified and created from only these three basic types.
Key Considerations
Models need to have enough formality and precision to serve their purpose. This normally means that they not only execute properly but can be used as the basis for automatic code generation for the target platform. System engineering models typically are not used for code generation but should usually still execute so that their quality can be assessed. Software models should normally be represented with a higher degree of precision because they represent the analysis or design of the actual system to be deployed.
Tailoring
Impact of not havingA well-formed model provides visualization and communication of the system's structure, behavior, functionality, and performance. Not having a model means that these concepts must be gleaned from examination of the source code, which is at best difficult and in some cases, not feasible.
More Information
Concepts
Guidelines