 |
The model represents a deployed or deployable system at a high degree of semantic correctness, consistency and completeness. |
Domains: Architecture |
|
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
Roles | Responsible:
| Modified By:
|
Tasks | Input To:
| Output From:
|
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)
|
Notation | The 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 Representation | The 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 having | A 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
|