Architecture Modeling - SPES 2020

Architecture Modeling
context does not comply to a strong assumption, then this constitutes an ”illegal” out of specification
usage of the corresponding component. Weak assumptions structure contracts according
to cases wrt. the integration context. That means a strong assumption can be confined by a weak
assumption and for that particular integration context a more precise guarantee may be given.
If a component is used accordingly to its strong assumptions, it will guarantee the behavior
specified by the guarantee, provided the weak assumption is fulfilled.
TextuallyRepresentedElement
+ textualRepresentation: String
Assertion
ProcessRequirement
+stronglyAssuming
+weakAssumption
0..1
1
+strongAssumption
0..1
+guarantee
+aspect
SystemArtefact Aspect
Requirement
+ rationale: String [0..*]
SystemRequirement
Stakeholder
InformalAssertion FormalAssertion +assertion +formal BlockOccurrence
+type
BehaviorBlock
0..1
0..1
0..1
+weaklyAssuming 0..1
0..*
+stakeholder
0..*
0..1
«isOfType»
+guaranting
Figure 3.27: Meta-model integration of the concept of Contracts
In the meta-model the concept of contracts is represented by the meta-class
SystemRequirement (see Figure 3.27). The naming difference is motivated by the existence
of the concept ProcessRequirement. Both are requirements and we wish to emphasise
that by name. However the concept of ProcessRequirement is out of the scope of this
document and we will use the terms SystemRequirement and Contract interchangeably.
A Contract associates an Assertion in three roles, which correspond to the elements
of its constituting triple. An assertion can be either an InformalAssertion or a
FormalAssertion. Apart from this, an assertion always is a specification of the dynamics
exposed at the interface (InteractionPoints in all Ports) of a component with regard
to a certain aspect. The loose coupling of SystemRequirement and RichComponent
allows the reuse of a SystemRequirement and to associate it with different components via
the Satisfy-trace link. Note that when specifying assumptions (strongAssumption and
weakAssumption), they must not limit the output ports of the component. In turn the guarantee
(guarantee) must not limit the input ports of the component. If an assumption (strong
or weak) has not been specified for a contract, then they are assumed to be true. That means
a component associated with that contract is not restricted with regard to any design context,
which is most certainly not the case!
The BlockOccurrence is typed by an HRC state machine, which is also defined in the
meta-model but not described here (instead see [50]).
Tracability of requirements is an important concept in order to be able to reason about refinement
of them and to provide arguments to certification authorities how implementation require-
1
38/ 156