Architecture Modeling - SPES 2020

Architecture Modeling
ments, design decisions with derived requirements and a final implementation. The developed
product has to be tested on all levels, which includes validating the integration of components,
systems and the entire product. On each design-phase on the left branch the architecture might
be regarded from different perspectives as the ones shown in Figure 2.2. Models of each perspective
can address different aspects. However not all aspects are relevant in each combination
of abstraction level and perspective. For example an aspect safety might be regarded in every
perspective whereas an aspect real-time is not regarded in a geometrical perspective.
e.g. Maintainability
Assessment Process
Analysis of Product Level
Requirements
Development of
Functional
Architecture
e.g Cost
Assessment Process
Development of
System
Architecture
Development of
Technology-oriented
Architecture
Safety
Assessment Process
Early virtual Integration
based on formal analysis
techniques
Development of
Deployment
Architecture
Mechanical
Electrical
Digital Hardware
Software
Modultest
Subsystem
Integration
System Integration
Figure 2.3: V-model
The architecture meta-model is based on the meta-model of Heterogeneous Rich Components
(HRC), which has formally defined semantics (discussed in Section 6.2). The meta-model,
which incorporates the concepts we describe in this quick-tour, is designed to be independent
of any application domain (e. g. automotive, avionics, medical). It defines the concepts and
how they are related to each other. That allows us to interpret domain specific meta-models
according to these concepts, thereby making analysis techniques available.
Note that it is out of the scope of this document to describe a development process defining
a sequence of steps to be carried out and what concepts to use in which development step.
That also means the way the design space, spanned by the two dimensions abstraction level
and perspective, is traversed is not prescribed here. The previous paragraph describing a development
process according to the V-model and relating it to the concepts of abstraction levels,
perspectives and aspects has to be understood as an example. Instead concepts for establishing
traceability are provided for carrying out transitions in the matrix, as well as resulting proof
obligations are described.
2.1 Abstraction levels
A system under development(↑) or a constituting design item (e.g. a component) can be modeled
on different abstraction levels(↑). Less abstract models belonging to a lower abstraction
level may increase the degree of detail of the description of the design item at hand. For example
the interface description may be refined as well as the demanded behavior. Therefore increasing
the level of detail, thus at the same time lowering the level of abstraction, adds knowledge about
Product
Integration
Certification
6/ 156