Architecture Modeling - SPES 2020

Architecture Modeling
creating a view belong to a specific abstraction level. In contrast the viewpoint that provides
means to describe a view is orthogonal to abstraction levels. The notion of viewpoints used
here corresponds to the notion of viewpoints of IEEE 1471-2000 [33]. The term model can be
understood as the description of some original entity that only reflects the relevant (from the
modeller point of view) properties of the original entity. A model is created for purpose and
is used in place of the original entity [46]. In this document when using the term model we
assume it has been created by means of the concepts provided by the architecture meta-model.
Thus, the meta-model is in fact a model of models, which means it describes relevant properties
of models.
A perspective(↑) combines views belonging to different abstraction levels. Thus, it is actually
a viewpoint, as a perspective provides means to construct a view. The terms view, perspective
and abstraction level are illustrated in Figure 2.2. Abstraction levels and perspectives form
a two-dimensional design space, where design artifacts may be placed in. According to the
definition each cell in the matrix is considered a view. The concept of aspects(↑) allow coping
with complexity in constructing a view, i.e. a cell of the matrix. Therefore an aspect is part of a
view. Examples for aspects are: Functional behavior, real-time and safety.
Considering a system under development, the structure of models of each considered perspective
are not necessarily congruent. A model of the functional perspective will be composed
differently than a model of the technical perspective. In contrast a view may address different
aspects of the same design item. Figure 2.1 illustrates that relationship. In Figure 2.2 the matrix
of abstraction levels and perspectives is shown. Some fields of the matrix are intentionally left
blank, because depending on the current phase of the development process certain perspectives
may not be regarded or refined.
Figure 2.2: Matrix of abstraction levels and perspectives
Any development of an embedded system is done according to some process model, which
describes the steps to be taken, together with the work products created in that steps. The Vmodel
(see Figure 2.3) has become a well established model for many development processes.
It shows how an embedded system can be developed along several abstraction levels starting
with user requirements for operational scenarios, analysis of functions with refined require-
5/ 156