Architecture Modeling - SPES 2020

Architecture Modeling
• Logical components are allocated to a technical system that distinguishes software, processing
and communication hardware, mechanical, hydraulic, and electrical components.
• The technical components are finally allocated to a geometrical space.
The design phases may be performed on different levels of abstraction, representing different
refinements of the initial design.
It should be noted that the SPESMM does not define a concrete design flow. For example,
not all design phases have to be performed on all abstraction levels. Even the number of abstraction
levels and perspectives may vary between different design processes. We can however
identify a set of primitive design steps that are repeatedly applied during such design processes.
More precisely, each design step identified in a certain process supported by the SPESMM can
typically be broken into a sequence of such primitive steps:
Decomposition Most component types defined in the SPESMM can be decomposed. That
is, components are broken down into smaller parts, or sub-components. This includes
for example functions that are decomposed into sub-functions, and the decomposition of
logical components.
Allocation Components within different perspectives of a design are entangled in that they
represent (partly) the same system entities. Functions for example are allocated onto
logical components.
Realization During the design process, the same system may be represented at different levels
of abstraction. We say, the system at a certain abstraction level (and the same perspective)
realizes the system at the higher levels.
Implementation Finally, components gets implemented. Depending on the perspective and abstraction
level, implementations may be automata models, StateCharts, MatLab models,
and even C-Code. Given a characterization of the responsibilities of a component and an
implementation, does it satisfy the responsibilities?
Each design step introduces a set of proof obligations clearly defining under which conditions
all responsibilities of the involved design artifacts are satisfied. This in advance allows to define
clear interfaces between the responsibilities of all engineers involved in a design process. In the
following, the corresponding proof obligations and involved model artifacts for each identified
primitive design step shall be discussed.
4.1 Formalizing Requirement Specifications with Contracts
In order to define how modeling along the SPESMM supports the primitive design steps, it is
important to understand the concept of contracts. In short, contracts characterize components
following the assume/guarantee reasoning style:
• The assumption of a contract defines under which environment conditions a component
is expected to work, and
• the guarantee characterizes ensured behavior of the component, given that the assumptions
are satisfied.
46/ 156