Dynamic Data Structures - The Component Composition Graph . 125

the composed application consisting of components. The goal within the CCG is to find

a composition that is complete and can be integrated. In this subsection the structure and the rules for the CCG are introduced.

Formally the CCG is a triple CCG:h(C, I, Ti, with a structure similar to the CRG.

– Iis the instantiated set of Interfaces, – Cis the instantiated set of Components, – T : T = ((C×I)∪(I×C))→ {0,1}.

∀i∈I: T = ((C×I)∪(I×C))→ {0,1}.

It entails a cgraph structure cgraph: h(I∪C), T i.

Contrary to the CRG no abstract interfaces or components are supported. The graph directly describes which components are bound using which interfaces.

For instance for two components c1 and c2: c1, c2 ∈ C and an interface i1 ∈ I, the transitions (c1, i1) = 1 and (i1, c2) = 1 implicate thanc1 usesi1 and thati1 is provided byc2, meaning that c1 uses componentc2, so thatc1 andc2 are bound via interfacei1.

Composition Rules

The following description lists the structural composition rules for the components:

Each interface must be provided by not more than one component, otherwise it is not possible to bind the using and providing component.

Interfaces can be used by more than one component. Unless defined differently in the component properties, each provided interface may be used by a multitude of components. Exceptions may be stateful components. For example a check-sum function for a data stream may store intermediate checkcheck-sums internally which forbids multiple usage of the component.

Components can be instantiated more than once. As answer to the issue of state-ful components, components may be instantiated more than once. Practically it is realized by attaching a number to indicate the instance. For example if the system contains two stateful checksum functions: one for incoming and one for outgoing traffic, the first instance is named ’checksum.1’ and the second is ’checksum.2’. The same has to be done for the provided interfaces.

CCG is no tree: Often it is assumed a composition graph is a tree with the system as root and services as leaves. However, in the configKIT component model recon-vergencies are possible (see case a) or c) in Figure5.20), and even intended, since reusing a component multiple times promises to reduce the total code size of the system.

Interface consumption: After binding a component that provides an interface used by another component the composition of both components still provides the in-terfaces. The using side of the interface is consumed. This is a result of the provide-once-use-many-times paradigm in the composition process.

Figure 5.20: Examples for valid and invalid component-interface-connections.

Additional constraints emerge when respecting the behavioral aspects of the components.

They are discussed in Section 5.4.4.

Figure5.20shows several examples for valid and invalid component-interface-connections in the CCG. The five cases are briefly discussed below:

a) it is allowed that one interface that is provided by one component can be used by several components

b) it is allowed that two instances of the same interface can be used by different com-ponents. That may be required if the component that provides the interface can only handle the states of being used by one component. Examples are stateful encryption units for incoming and outgoing data streams.

c) One component can use more than one interface - and one component can provide more than one interface. The specific case where two components share two inter-faces may be applied for complex interinter-faces that are split to improve reusability.

d) and e) It is not allowed that one instance of an interface is provided by more than one component. The number of components that use the interface is irrelevant. A valid alternative would be setup b)

Structurally Complete Compositions

With the rule set defined in the previous paragraphs it is possible to compose systems consisting of components, while it is still unclear under which conditions a composition is complete, i.e. implementable. Basically, a composition can be considered as complete if there are no open dependencies.

Analog to the properties listed in [JDG10] the CCG has to comply with the following requirements:

Reachability: all components of the CCG have to be reachable from the main system component: ∀c ∈ CC : c ∈ (’system’×T^∗). ’System’ is the name of the top

component. This requirement also ensures cohesion of the composition, because interfaces are the only means to reach other components.

Extensiveness: all components given by the user have to be in the composition: ∀c∈ App:c∈C_C.

Completeness: All required interfaces of all components in CCG have to be satisfied by at least one component in the selection:

∀c∈CC : (c×T)⊆CC×T⁻¹

Implementabiliy: All components of the composition must not be abstract but imple-mentable.

Only if those four conditions are satisfied, the composition is complete and hence im-plementable. Beside the implementability, which is an attribute of the components, all rules can be computed within the CCG, which simplifies the check on completeness in practice. However not all syntactically complete compositions are free of contextual con-flicts. Therefore the properties of the components have to be evaluated. This process is introduced in the following section.

5.4.4 A-priori Reasoning about Composition Properties

Propagation of semantic attributes of a composition from the CCG to the PRG is the operation of adding properties and relations associated with the corresponding compo-nent to the PRG.

In this section we first discuss general methods of mapping the properties from the CCG to the PRG. In the second part property models are introduced. The property models are needed to assess specific attributes of the systems on a rather high level before actually implementing the system.

Property Propagation

As introduced earlier, the behavior and attributes of the system are assessed by mapping properties from the selected components to the PRG. Initially, this mapping could be expected as direct projection of features, so that

properties(composition) = [

c∈composition

properties(c) (5.1) However, not all properties can be mapped directly. Properties may also be defined as deduction of the composition. A third sort of properties describe structural properties and dependencies of the composition. Thus, the property assessment can be described with the non-trivial mapping function

properties(composition) =mapping(binding, composition). (5.2) This means that the eventual properties of a composition not only depend on the chosen components but also on the binding within the composition. It reflects that the same selection of components may result in different behavior if the components are connected differently. It also implies that for the same selection and the same binding we can expect the same properties.

Figure 5.21: Example for direct properties: both compositions consist of the same mod-ules (Application, Transport, Link Layer, and Encryption). Still the system properties are different. In (a) the TX cannot access the security services so that no end-to-end secu-rity can be provided, in (b) the Link layer has no crypto function to establish hop-by-hop encryption.

From a practical point of view it has to be differentiated between direct and derived properties:

Direct Properties are properties which are valid on the scope of the entire system once the corresponding component has been added. Many functional properties are valid on global scope because once the component is part of the system also the function is available. Thus, global properties are valid regardless of the actual binding of the component, so that Equation5.1holds true.

An example for global properties is the radio frequency which is set for the whole application once the radio transceiver is selected. This global parameter is the basis for many other properties in the system, but it is not affected by other components.

Another group of examples for direct properties are direct function descriptions, such as the function Event-notification which is available if the corresponding com-ponent is included.

Derived Properties are influenced by the composition of the system and cannot be expressed directly but need a mapping in the context of the binding. For example the quality attributes of a network transport protocol depend on the qualities of the used network protocol.

As another example encryption on link layer does not provide the level of security as encryption on transport layer. Figure 5.21 illustrates both system architec-tures. Both compositions consist of the same modules (Application, Transport, Link Layer, and Encryption). Still the system properties are different. In Figure 5.21(a) the TX cannot access the security services so that no end-to-end security can be provided, in Figure5.21(b) the Link layer has no crypto function to estab-lish hop-by-hop encryption. So the same encryption component unfolds different system properties depending on the usage in the system stack.

Figure 5.22: Property Models as Part of the Working Model: In the PRG of the WM sub-frameworks of properties and relations can be loaded to represent a specific property model. Like the global PRG the models are parametrized by requirements and evaluate the composition.

Such properties may be injected in the interfaces of the components. For instance if the transport protocol uses the encryption component the qualities of the crypto-graphic module are visible for the transport protocol via the used interface. Then the transport protocol may define the global property ’end-to-end-security’ with a specific quality. If the cryptographic component is used only by the data link layer, the global property ’end-to-end-security’ has to be set to ’none’.