Models
The contents of the Models package is shown in Figure 419. The Models
package is one of the packages of the AuxiliaryConstructs package.
Model (from Models)
A model captures a view of a physical system. It is an abstraction of
the physical system, with a certain purpose. This purpose determines
what is to be included in the model and what is irrelevant. Thus the
model completely describes those aspects of the physical system that
are relevant to the purpose of the model, at the appropriate level of
detail.
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 Actors, together
with their interrelationships, such as Associations and Dependencies
Attributes
- viewpoint : String [*] 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), i.e. for a
certain category of stakeholders, e.g. designers, users, or orderers 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 is 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