Architecture Modeling - SPES 2020

Architecture Modeling
For our application as specifications, the logical formulas in question will denote sets of traces
of valuations of connections, resp., ports. Then we can define satisfaction of contracts by components
(and systems).
Definition 6.3.3 (Satisfaction) A component M satisfies a formula G, written M |= G, if and
only if [[M]] ⊆ [[G]]. Similarly, it satisfies a contract C, written M |= C, if and only if [[M]] ⊆ [[C]].
Thus, we have
6.3.2 Contracts: Properties
M |= (As,Aw,G) ⇔ [[M]] ∩ [[As]] ∩ [[Aw]] ⊆ [[G]] .
To be able to base the design process on contracts, we need operations on contracts and related
properties. The most basic relation between contracts is that of entailment, which is called
refinement here.
Definition 6.3.4 (Refinement) A contract C ′ = (A ′ s,A ′ w,G ′ ) refines a contract C = (As,Aw,G),
written C ′ ⇒ C, if
[[C ′ ]] ⊆ [[C]] and[[As]] ⊆ [[A ′ s]] ,
i. e. if it is (in total) more restrictive and its strong assumption is less restrictive. Equivalently,
C ′ ⇒ C if form(C ′ ) ⇒ form(C) and As ⇒ A ′ s in the usual logical meaning of implication.
Thus, a component satisfying a refinement of a contract C satisfies also C. The second part of the
condition for refinement states that the strong assumption may only get weaker in refinements.
As a consequence, the strong assumption of a contract will always remain sufficient to establish
the strong assumption made by a component satisfying a refinement. In practice, refinement
usually removes nondeterminism from the guarantee, thus strengthening it, and/or permits more
environment behaviour, weakening the assumption(s). This relation is called dominance.
Definition 6.3.5 (Dominance) A contract C ′ = (A ′ s,A ′ w,G ′ ) dominates a contract C =
(As,Aw,G), written C ′ C, if A ′ s ⇐ As, A ′ w ⇐ Aw and G ′ ⇒ G.
It is easy to see that dominance implies refinement but not vice versa. In practice, dominance is
easier to establish (i. e., less complex to check) and often sufficient for refinement proofs to go
through.
In the design process, often more general relations than refinement are called for because A
specification should be implementable. We capture this intuition by the notion of (strong) consistency.
Definition 6.3.6 (Consistency) Let the interface I of a component in HRC be given.
1. A contract C (resp., a set of contracts C ) over I is weakly consistent if [[C]] is nonempty
(resp.,
C∈C [[C]] is nonempty).
2. A contract C (resp., set of contracts C ) over I is strongly consistent if the receptive kernel
of [[C]] (resp.,
C∈C [[C]]) w.r.t. the inports in I is nonempty.
Weak consistency is consistency in the logical sense, a necessary condition for every meaningful
specification. Strong consistency takes the direction of ports into account, guaranteeing the
existence of an implementation on the semantic level. It is more difficult to check than weak
consistency.
Whether the direction of ports is taken into account in a contract can be defined on the logical
level.
146/ 156