Architecture Modeling - SPES 2020

Architecture Modeling
if there is no delay greater 0 specified in which toggling output takes place in the components.
This property is well-known, and also important in many formalisms used in control- and also
in real-time scheduling theory. In the context of the FOCUS methodology for example, it is
denoted strict causality. Strict causality ensures (beside other important properties) that proof
obligations of VIT can be performed sequentially.
4.2.1 Compatibility and VIT Condition
As stated before, two (or more) components will “work together” properly, only if they are compatible.
Due to the fact that components are characterized by their specifications, compatibility
is defined for contracts.
Compatibility reflects the distinction of responsibilities in that strong assumptions about the
environment of a component must not be violated by another component that is connected to
this component. Technically, this property is expressed by the following definition: Given
components L and R with contracts C L = (A L s ,A L w,G L ) and C R = (A R s ,A R w,G R ), respectively,
where only output ports of L are connected to input ports of R, it must hold
G L =⇒ A R s
(4.1)
that is, if the guarantee of component L is satisfied, then it will “satisfy” the strong assumptions
of component R.
If also output ports of R are connected to input ports of L, it further must hold
G R =⇒ A L s
To give an example, let GL be that statement that its output port o delivers values within
a range of [25,35] ◦C. It characterizes any possibly “behavior” of such temperature over the
time that is not lower than 25◦C and not higher than 35◦C at any time point. This specification
would satisfy an assumption AR s , stating that the temperature is in the range [20,40] ◦C. A more
detailed definition of “behavior” can be found in Section 6.2. However, Equation 4.1 states that,
if component L satisfies its guaranteed behavior, then this will also satisfy the assumption of R
about its environment.
Such definition of compatibility is in “simple” situations a necessary condition. It however
neglects the fact, that composites typically have an interface to their environment. In Figure 4.4
for example, there are four other ports of the composite component to its environment, namely
e2l, l2e, e2r and r2e. Moreover, it also defines compatibility for single contracts only. Since
the parent component of a composite usually also has assumptions about its environment, compatibility
of the composite must take this assumptions into account. Suppose for example, that
the input port e2l of component L specifies some air flow. Suppose further, L has the (strong)
assumption that this air flow is bounded by, say, 50l/s. If now the parent component S has
the (strong) assumption that this flow is bound by, say, 100l/s, the whole composition may
become contradictory with respect to receptiveness and consistency as discussed before. It is
obvious to see why. The specification for L assumes that the input flow is below 50l/s. Only
if this assumption applies, L is bound to its guarantee. Otherwise, its behavior is unspecified.
Compatibility on the other hand relies on the guarantees given by the respective components.
In other words, compatibility holds only if all guarantees given by the involved components are
adhered to.
Formally, compatibility in the general case is defined as follows. Given a component with
strong assumption As, and sub-components with contracts Ci = (Ai i, j
s,Aw ,Gi, j ), compatibility is
(4.2)
54/ 156