Architecture Modeling - SPES 2020

4 Steps in Component-Based Design
The SPES architecture meta-model (SPESMM) intends to support development of complex
systems involving a large number of different engineers. In such a process, it is essential to
specify the roles and responsibilities of each engineer: who is responsible for ensuring what,
and under which conditions. Only if this is ensured, integration problems in later design phases
can successfully be identified and fixed.
In SPESMM, first class citizens are components and their interfaces. Components may interact
with each other and with the environment by means of their interfaces, thus forming
a model of the intended system. The SPESMM supports the development process in that it
allows to represent roles and responsibilities of engineers by corresponding concepts in the design
architecture. For example, engineers are usually responsible for distinct parts of the design.
Design artifacts have to be constructed, refined, and implemented in different perspectives and
at different abstraction levels. The SPESMM allows to (formally) express responsibilities for
components in form of contracts, which are an instance of the assume/guarantee specification
style. If different engineers, responsible for certain design artifacts, have to integrate the respective
parts of the design, contracts allow to define under which conditions this integration will be
successful. The same holds for example, if different engineers are responsible for specification
and implementation of certain components. SPESMM provides means to reason about under
which conditions an implementation satisfies the corresponding specification.
The underlying concepts of the SPESMM particularly allow to define proof obligations that
have to be performed in order to ensure whether responsibilities defined for model and component
interfaces are satisfied. In an early design step for example, functionality of the system may
be identified, together with a set of requirements to be satisfied by those functions. When in
a subsequent design phase decomposition of the system into logical components is performed,
it should be explicated which logical components are responsible to guarantee which system
functionality. If this is done ”the right way”, the SPESMM allows the application of tools that,
if not performing proof obligations automatically, explicate which proof obligations have to
be performed in order to ensure satisfaction of the identified function requirements. This section
intends to provide an overview of those concepts related to establish a continuous design
process, and to provide traceability of requirements and the corresponding relations between
design artifacts.
Typically, a design process along the SPESMM involves many different design steps:
• Entry point is the operational perspective, where system boundaries are identified, and
the relevant goals, or initial requirements, are defined.
• The system is then decomposed into distinct functions provided by the system in order to
achieve the goals. Functionality may be further refined into sub-functions in this phase.
Furthermore, requirements are identified for the respective functions which are typically
related to the initial goals and requirements.
• Functionality is partitioned into logical components providing the intended functions, and
45/ 156