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.
<strong>Architecture</strong> <strong>Modeling</strong><br />
ServiceBinding and compatibility of Services There are two case distinctions for<br />
binding Services by means of ServiceBinding. If services of different ports shall be<br />
bound establishing an assembly connection like illustrated in Figure 3.30a, then the directions<br />
of both services need to be complementary (required for provided and vice versa). In the<br />
case of delegation connections like depicted in Figure 3.30b, the directions must be the same.<br />
Further the services must be compatible. Two services are compatible if their signatures are<br />
the same. That means they associate the same DataType as returnType and have identical<br />
Parameters with regard to their name and types.<br />
Connector and compatibility of Ports When defining assembly connections<br />
or delegation connections between Ports by means of the concept<br />
Connector, all InteractionPoints of the Ports defined by their corresponding<br />
PortSpecification are bound. Which pairs of InteractionPoints are bound is<br />
determined by name. All pairs of InteractionPoints (Flows or Services) must be<br />
compatible as described above.<br />
FlowDirection<br />
in<br />
out<br />
bidirectional<br />
FlowKind<br />
discrete<br />
continuous<br />
event<br />
Serv iceDirection<br />
provided<br />
required<br />
Parameter<br />
+part 0..*<br />
RichComponentProperty<br />
PortSpecification<br />
1<br />
+component<br />
+type<br />
1<br />
+portSpecification<br />
+formalParameter +service<br />
0..*<br />
0..1<br />
1<br />
«isOfType»<br />
+type 1<br />
«isOfType»<br />
+interactionPoint<br />
RichComponent<br />
Port<br />
+ isConjugated: Boolean<br />
0..*<br />
Serv ice<br />
InteractionPoint<br />
+ direction: ServiceDirection<br />
+service 1..*<br />
«isOfType»<br />
+component<br />
+port<br />
«isOfType»<br />
1<br />
0..*<br />
+port<br />
1..*<br />
+component<br />
1<br />
Connector<br />
«instanceRef»<br />
+interconnection<br />
Flow<br />
+ direction: FlowDirection<br />
+ kind: FlowKind<br />
+returnType<br />
1<br />
«isOfType»<br />
+type 1<br />
DataType<br />
+type 1<br />
0..*<br />
Interconnection<br />
FlowBinding Serv iceBinding<br />
«instanceRef»<br />
Figure 3.31: Meta-model integration of the composition concepts<br />
+flow<br />
1..*<br />
«instanceRef»<br />
Composition of Contracts: If a composition of components is specified by means of the<br />
described concepts, that composition is correct with regard to the syntactical interfaces of the<br />
parts and the composition. However it must also be ensured, that the contracts specified for<br />
the components typing the parts are compatible and are a valid refinement of the contracts<br />
of the composition. Figure 3.32 illustrates that relation. The components ComponentA and<br />
ComponentB have contracts C1 resp. C2. They are used as parts in the context of the composition<br />
ComponentC, which in turn has a contract C12. The contracts are linked to the<br />
components by means of the Satisfy-trace link described in 3.3.1.3. When constructing<br />
a composition, the relationship of the contracts associated with the concerned components is<br />
specified by means of the Entail-trace link.<br />
42/ 156