09.08.2013 Views

Architecture Modeling - SPES 2020

Architecture Modeling - SPES 2020

Architecture Modeling - SPES 2020

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!