Previous UML Classes Table of Contents UML Packages Next

17.3.1 Model


   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.



    Package (from Kernel ) on page 109


   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 .


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.)
No additional associations


   No additional constraints


   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.


   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.


Figure 17.9 - Three models representing parts of a system

   Figure 17.10 - Two views of one and the same physical system collected in a container model