Architecture Modeling - SPES 2020

Architecture Modeling
F1 whenever event occurs event [does not] occur[s] [during interval]
Phrases in square brackets are optional, bold elements are static keywords of the pattern, and
elements printed in italics represent attributes that have to be instantiated by the requirements
engineer. So a valid instance of the pattern F1 is:
whenever p1.f1 occurs p2.f1 occurs during [8ms,10ms]
The RSL provides patterns that have been categorized according to aspects they address. Despite
that categorization they may also be used for the specification of other aspects. For example
a Probability Pattern can be useful when specifying a failure hypothesis of components,
which clearly is a Safety aspect.
While the concept Contract (resp. SystemRequirement) and BlockOccurrence
is directly expressed in the meta-model, this is not true for the syntax and semantics of
RSL patterns. Figure 3.27 shows that an Assertion referenced in any of the three
roles strongAssumption, weakAssumption or guarantee is a specialization of
TextuallyRepresentedElement. The attribute textualRepresentation contains
that text. Multiple instances of RSL patterns would then be entered in that text field.
Thus, a set of pattern instances specifies a FormalAssertion of a contract, i. e. its strong
and weak assumptions and its guarantee. See Section 6.1.1 for a formal definition of RSL.
3.3.2 Hierarchy and Composition
Once components are defined by means of the RichComponent concept and their syntactical
interface has been specified by Ports, components can be instantiated in the context of
other components as parts forming a composition of components. That composition is again a
component, whose behavior is given by the behavior of its constituting parts.
3.3.2.1 Hierarchy
The instantiation of components in the context of other components is represented in the
meta-model by the RichComponentProperty concept (see Figure 3.29). A component
with its ports and contained behavior is referenced in the role of type by a
RichComponentProperty. That RichComponentProperty is in turn aggregated by
another RichComponent as one of its parts. The behavioral specifications characterized by
contracts that are linked to a RichComponent and corresponding realizations are also instantiated
in any RichComponentProperty typed by the RichComponent. It is allowed to
have multiple instances of the same component in the context of a composition. As this concept
can be applied recursively, it allows to construct deeply nested hierarchies of components. Note
that this is consistent with type/part concepts found in e. g. UML [41] and SysML [39].
3.3.2.2 Composition
When components are used as parts in another component, they have to be interconnected by
binding the flows and services contained in the ports. The concept of Interconnection
is owned by the same component which also owns the parts. An interconnection is either a
delegation connection or an assembly connection. The former links the interaction points of the
outer component, i. e. the composition, with interaction points of its constituting parts. So the
interaction points need to have the same direction. Assembly connections link the interaction
points of parts of a composition to each other. So their directions must be reversed.
40/ 156