Architecture Modeling - SPES 2020

Architecture Modeling
can usually only be realized by making assumptions about the frequency at which data arrives
at the input port p1. Thus for the real-time aspect of the HRC a contract might be:
C1
strong assumption p1.e1 occurs each 10ms with jitter 1ms
weak assumption true
guarantee delay between p1.e1 and p2.f1 within [0ms,10ms]
The different patterns, which can be instantiated in order to specify the assumptions and guarantees
of a contract, are defined in Section 6.1.1. Each pattern belongs to a category (functional
patterns, real-time patterns), which is reflected by its name. For example all patterns with names
prefixed by the letter F are functional patterns and the prefix R denotes a real-time pattern. The
category of a pattern gives a first hint for the specification of which aspect it may be suited best.
With regard to the example contract C1 an instance of the pattern R2 has been used for the
strong assumption and an instance of the pattern R3 for the guarantee. The concrete number of
the pattern does not need to be specified, as it can be automatically derived from the syntax of
the expression.
2.3.2 Hierarchy and Composition
When a component is used as part(↑) in the context of another component, its ports(↑) can
be linked to other parts forming a composition of components. That composition is again a
component, whose behavior is given by the behavior of its constituting parts. Thus components
can support both top-down as well as bottom-up design approaches and mixed forms thereof.
2.3.2.1 Hierarchy
ComponentC
part2:ComponentB
component
instance
role
Ports
part1:ComponentA
ComponentA
C1
aspect
specification
aspect
realization
Figure 2.9: Hierarchy of components
component
specification
The component model of HRC supports the type/part concept found in many other modeling
languages, e. g. the UML [41]. Figure 2.9 shows an illustration of that concept. An HRC
ComponentA is modelled with its ports and contracts that specify the behavior of that HRC
under the different aspects. That HRC can be used in the context of other HRCs playing the role
of a part in that context. A part denotes component instances that the surrounding HRC owns
by composition. In the example, the HRC ComponentA is used as part with the role name
part1 in the context of the HRC ComponentC. The aspect specifications characterized by
contracts that are linked to ComponentA and corresponding realizations are valid for part1
as well. This holds for any context, in which ComponentA is used as a part.
The type/part concept results in a possibly deeply nested hierarchy of components ultimately
leading to some top-level component specification. Such a hierarchy of HRCs can be con-
13/ 156