Architecture Modeling - SPES 2020

Architecture Modeling
and so forth. Each of such design steps usually involves an assignment of requirements to
the identified components. Some requirements are usually derived from formerly identified
requirements, while other requirement occur due to the introduction of new components and
interfaces.
To stress the air conditioning example, we may have the requirement for an air-conditioning
function (in the functional perspective) to provide air from the environment of an airplane with
certain quantity and temperature. To show the simplest form of deriving a requirement for the
logical perspective at the same abstraction level, there may be exactly one logical component
performing the air conditioning function. In such a case, it seems to be obvious to assign the
same requirement to the logical component as to the corresponding function.
In more complex settings, logical components may perform several functions (sequentially,
parallel, or in any other order), or several logical components may be involved performing a
single functionality. Here, deriving requirements for one perspective from another may be more
complex, particularly for the latter case. 3
The same can be said for the relation between logical and technical components. A logical
component may be performed by a single technical entity. It may be also performed by a
composition of different entities, may be involving mechanical, computational and other components.
Indeed there may be requirements that are unique to specific perspectives. For example,
geometrical constraints such as packaging sizes, cable lengths, and so on become important
only in the geometrical perspective. On the other hand, there are typically requirements that
are important for multiple perspectives. Requirements identified for system functions for example
are important in order to establish justification for proper system design. Satisfaction
of those requirements can however often not be established in the functional perspective, e.g.
due to missing specification of internal behavior. SPESMM provides concepts to reason about
requirements across different perspectives, and to establish the corresponding relations.
Abstraction Levels The same problems that occur with respect to reasoning about contracts
across different perspectives hold for abstraction levels. When a system is designed incrementally,
the same system is represented at different levels of granularity. Although various refinement
steps can be established by decomposition of components, there are other cases where
changing the abstraction level is more appropriate. This may be simply due to organizational
boundaries, where different departments in a company are responsible for certain subsystems.
A more formal reason is the fact, that refinement not always follows a decomposition approach,
but demands for more complex m-to-n relations.
Note that there is no explicit deployment defined for different aspects of components. The
reason for this is, that the specification of different aspects has no direction. Instead, aspect
specifications of a component are often closely and interdependently entangled, and relations
between different aspects of specifications have to be made explicit. An example for multiaspect
specification can be found for example in [18].
4.4.1 Mapping
Since the requirements for creating interfaces between perspectives and between abstraction
levels are very similar, the SPESMM introduces the common concept of mapping. Technically,
3 A convenient way to circumvent such problems is to start with a surrounding component that uses decomposition
to achieve the intended result, and that keeps the simple one-to-one relation between functions and logical
components
62/ 156