Architecture Modeling - SPES 2020
Architecture Modeling - SPES 2020
Architecture Modeling - SPES 2020
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
ComponentC<br />
<strong>Architecture</strong> <strong>Modeling</strong><br />
part1:ComponentA<br />
part2:ComponentB<br />
ComponentB<br />
C2<br />
«Entail»<br />
C12<br />
«Entail»<br />
ComponentA<br />
Figure 3.32: Composition of components and contracts<br />
Note that this link only declares the proof obligations which have to carried out in order to<br />
ensure a sound (de-)composition. Actually one needs to verify, that the entailing contracts<br />
are compatible, meaning the strong assumption of a contract must not be violated by another<br />
component, which is connected to it. If the entailing contracts are compatible, it must<br />
be checked if the entailing contracts are indeed a refinement of the entailed contract.<br />
Related to the example sketched in Figure 3.32, Compatibility of C1 and C2 needs to be verified<br />
and the pair {C1,C2} must be a refinement of C12. We call such proof obligations Virtual<br />
Integration Testing, which is discussed in Section 4.2.<br />
3.4 Mapping Component Parts<br />
In Section 3.1 the Realize-trace link has been introduced, which allows to trace component<br />
realizations when switching abstraction levels. In Section 3.2 the Allocate-trace link has<br />
been introduced, which allows to trace component allocations between different perspectives.<br />
Both concepts are similar and therefore the superordinate concept of Mapping has been defined.<br />
+type 1<br />
RichComponent<br />
+component 1<br />
«isOfType»<br />
+part 0..*<br />
+mappedTo<br />
RichComponentProperty<br />
1 «instanceRef»<br />
+mapped<br />
1<br />
«instanceRef»<br />
TextuallyRepresentedElement<br />
+ textualRepresentation: String<br />
Allocate<br />
Mapping<br />
0..1<br />
Realize<br />
+mapping<br />
+formal<br />
1<br />
MappingBlock<br />
+mappingBlock 0..1<br />
+behavior 1<br />
BlockOccurrence<br />
1<br />
Serv ice<br />
C1<br />
+ direction: ServiceDirection<br />
+mappingBlock<br />
+mappingLink<br />
«isOfType»<br />
+service 0..1<br />
«instanceRef»<br />
0..*<br />
+type<br />
1<br />
Flow<br />
+ direction: FlowDirection<br />
+ kind: FlowKind<br />
MappingLink<br />
BehaviorBlock<br />
Figure 3.33: Meta-model integration of the mapping concepts<br />
+flow 0..1<br />
«instanceRef»<br />
Figure 3.33 shows how a Mapping relates two parts of components<br />
(RichComponentProperty) to each other. Further a mapping is formalized by means of a<br />
MappingBlock, that has a BlockOccurrence, which is typed by a BehaviorBlock.<br />
The concept of MappingLinks link flows or services of a component taking part in the<br />
43/ 156