Architecture Modeling - SPES 2020

Architecture Modeling
ports must have the same type (we do not treat issues related to types in depth, here, so we adopt
this simple principle for ease of exposition). A simple sample system is depicted in Figure 4.4,
where only the connection names and not the port names are given.
Figure 4.4: Simple example system
In a design process, composed systems usually do not exist a-priori (except in case of re-use),
but are the result of a concrete design step. For example, due to a design decision, it may be
found that an initially identified air condition system shall be realized by a sequential composition
of different sub-systems. The first subsystem may provide air from the environment, the
second one has to bring this air to its correct temperature, and so on. Contract-based design
helps in such situation not only to allocate responsibilities for the respective sub-components,
but also to trace back whether the requirements of the component are satisfied when all of
its sub-components satisfy their “local” requirements. The corresponding proof obligations are
subsumed by so-called Virtual Integration Testing (VIT). The term virtual is due to the fact, that
these proof obligations are independent from the implementation of the respective components.
That is, if a virtual integration test has been performed successfully, any set of implementations
satisfying the responsibilities of the respective sub-components are inherently covered by the
VIT. We will discuss satisfaction of an implementation in Section 4.3.
VIT defines the conditions under which the contracts of all sub-components, when put together,
satisfy the contract(s) of the parent component, and which verification steps have to be
performed in order to establish this property. The relevant property is denoted refinement and
is discussed in Section 4.2.2. VIT also defines proof obligations necessary to verify that two
(or more) components can be put together reasonably at all. Component R in the figure above
could for example state, that the input values on its input l2r always are below, say, 30 ◦ C. If the
guarantee of component L would state that its output on l2r is always between 25 and 35 ◦ C, it
would obviously be problematic to put L and R together. Compatibility of contracts is discussed
in Section 4.2.1.
Compatibility is however only one property necessary to properly compose components. As
for the contracts of a single component, VIT also requires that the composition of components
does not violate receptiveness and consistency. This becomes particularly evident when components
are composed to form a control loop as in Figure 4.4 via ports l2r and r2l, where inports
and outports of components are mutually connected. Thus, a reasonable design methodology
relies on receptiveness and consistency for composing components.
Another proof obligation of VIT, that shall not be discussed here in detail, concerns some
form of stability. In the figure above, contract CL could for example state that the output on
l2r becomes 0 if the input r2l is 1, and vice verse. Contract CR could equivalently state that
the output r2l becomes 0 if its input l2r becomes 1 (and vice verse). Although the respective
contracts are compatible, and even strongly consistent, the resulting system will not be stable,
53/ 156