*Generalizations
•
Package (from Kernel ) on page 109
Description
The Model construct is defined as a Package. It contains a (hierarchical) set of elements that together describe the physical
system being modeled. A Model may also contain a set of elements that represents the environment of the system, typically
Actor s, together with their interrelationships, such as Associations and Dependencies .
Attributes
Issue 8508 - remove incorrect multiplicity 9191 - change lower bound to 0
| • | viewpoint : String [0..1] | The name of the viewpoint that is expressed by a model. (This name may refer to a profile definition.) | |||
| Associations | |||||
| No additional associations |
Constraints
No additional constraints
Semantics
A model is a description of a physical system with a certain purpose, such as to describe logical or behavioral aspects of
the physical system to a certain category of readers.
Thus, a model is an abstraction of a physical system. It specifies the physical system from a certain vantage point (or viewpoint)
for a certain category of stakeholders (e.g., designers, users, or customers of the system) and at a certain level of abstraction,
both given by the purpose of the model. A model is complete in the sense that it covers the whole physical system, although
only those aspects relevant to its purpose (i.e., within the given level of abstraction and vantage point) are represented
in the model. Furthermore, it describes the physical system only once (i.e., there is no overlapping; no part of the physical
system is captured more than once in a model).
A model owns or imports all the elements needed to represent a physical system completely according to the purpose of this
particular model. The elements are organized into a containment hierarchy where the top-most package or subsystem represents
the boundary of the physical system. It is possible to have more than one containment hierarchy within a model (i.e., the
model contains a set of top-most packages/subsystems each being the root of a containment hierarchy). In this case there is
no single package/subsystem that represents the physical system boundary.
The model may also contain elements describing relevant parts of the system’s environment. The environment is typically modeled
by actors and their interfaces. As these are external to the physical system, they reside outside the package/ subsystem hierarchy.
They may be collected in a separate package, or owned directly by the model. These elements and the elements representing
the physical system may be associated with each other.
Different models can be defined for the same physical system, where each model represents a view of the physical system defined
by its purpose and abstraction level. Typically different models are complementary and defined from the perspectives (viewpoints)
of different system stakeholders. When models are nested, the container model represents the comprehensive view of the physical
system given by the different views defined by the contained models.
Models can have refinement or mapping dependencies between them. These are typically decomposed into dependencies between
the elements contained in the models. Relationships between elements in different models have no semantic impact on the contents
of the models because of the self-containment of models. However, they are useful for tracing refinements and for keeping
track of requirements between models.
Notation
A model is notated using the ordinary package symbol (a folder icon) with a small triangle in the upper right corner of the
large rectangle. Optionally, especially if contents of the model are shown within the large rectangle, the triangle may be
drawn to the right of the model name in the tab.
Presentation Options
A model is notated as a package, using the ordinary package symbol with the keyword «model» placed above the name of the model.
Examples
Figure 17.10 - Two views of one and the same physical system collected in a container model