Context Model

The PCM heavily relies on the idea of having an explicit component context model. The context model of a component captures all information relevant for doing functional and extra-functional reasoning on a component which becomes available after the compo- nent’s implementation phase (Becker et al., 2006c). By this, the component context sep- arates component implementation done by the component developer from component assembly, allocation, and usage. Note that the following uses the term context in a nar- row sense. For example, it excludes the business context of the component resulting from its requirements. The context as used here focuses on functional and extra-functional analyses of component compositions.

Different deployments of the same component results in different context information. For example, the component can be connected differently or allocated on different exe- cution environments. Having an explicit meta-model for the component context allows a separation of the CBSE developer roles as follows. The component developer creates im- plementation specifications of components which are parameterised by aspects depend- ing on the component context, e.g., the binding to other components or the allocation to hardware resources. Afterwards, the remaining developer roles contribute their context- dependent information. This information determines the value of the parameters in the component developer’s implementation specification finally resulting in a complete spec- ification of the component in its context. Hence, all model transformations based on the PCM have to deal with the context model and combine the parameterised component specification and its context into a context-specific component specification.

Currently, the PCM’s context model uses two dimensions to distinguish context infor- mation. The first separates the information according to the developer role that is able to specify the information. The second differentiates context information which has to be specified manually by a developer and context information which analysis methods can derive automatically. The PCM’s meta-model contains only meta-classes for context in- formation that has to be specified manually. An explicit model for the computed context information is not part of the PCM as it may depend on the analysis method. Koziolek

(2008) gives a meta-model for the computed context used in his transformations. The simulation in this thesis uses no explicit derived context model but encodes it directly in the simulation’s state (see section4.4.8for details).

To give an overview on the context model of a component, table 3.1 lists the sub- contexts and their classification. The upper row of table 3.1 highlights the parts of the component context which need manual specification, the lower row gives those proper- ties which can be derived from the specified information.

Assembly Con-

text Allocation Context Usage Context

Connection, Allocation, System usage:

Manual Containment Environment config: - Call probability

specification - Concurrency, security, ... - Call parameter

necessary - Container properties - Workload

- Component configura- tion

Automatic Functional Extra-Functional Inner Usages

computation Parametric Allocation dependent

possible Contracts QoS-Characteristics

Table 3.1: The PCM’s Context Model (based onBecker et al.(2006c))

eral principle, it does not depend on an actual realisation. The way it is currently imple- mented in the PCM’s meta-model is only one alternative which will be extended in future work. However, to ease understanding, references are given which point to the PCM’s meta-model realisation where available.

Assembly Context The upper left field shows attributes of the specified assembly con-

text. A component’s position in an assembly of components is determined by (a) its par- ents composite structure it is part of, e.g., a system or a composite component, and (b) the connectors attached to its required interfaces (for the implementation of the assembly context in the PCM’s meta-model see section 3.4.4). As an example for different connec- tors, figure3.5 shows two instances of the component SyncCache each of them using a different component to provide their service.

Figure 3.5: The same Component in different Assembly Contexts (Becker et al.,2006c) Based on the specified assembly context, Parametric Contracts introduced by Reuss- ner (2001) allow to derive which services of the provided interfaces of a component are available depending on the connected required interfaces.

In the context of this thesis, connectors available in the assembly contexts are trans- formed into technical realisations like RPC calls. They realise calls to required component services at run-time. Generated components have to provide means to establish such connections after their implementation phase as specified in the assembly context by the software architect.

Figure 3.6: The same Component in different Allocation Contexts (Becker et al.,2006c)

Allocation Context The specified allocation context (upper row, center column of ta-

ble3.1) contains information on the allocation of a component onto a soft- and hardware environment (see section 3.7.2 for the realisation of the allocation context in the PCM). The software environment may contain all layers of software hosting a component, like middleware servers, virtual machines, or operating systems. Additionally, it may contain the configuration options of these layers. Support for software layers is still very limited in the PCM. Future work can use the allocation context to store information on software layers hosting a component.

In addition to the executing software layers, the allocation context stores a reference to the hardware environment which executes a component. The hardware environment contains information on the physical hardware like CPU, harddisks, memory, etc. Fig- ure3.6depicts a component in different (hardware) allocation context.

Using the information given in the allocation context, analysis methods can derive execution-environment dependent quality attributes from their respective independent specifications. For example, the simulation presented in this thesis uses the allocation context to determine which simulated resource processes a demand issued by a compo- nent and how long it takes on the given hardware platform to process the demand. Ad- ditionally, it uses the information in the hardware environment to configure its queuing network’s service centres.

Usage Context The usage context of a component (right column of table3.1) gives infor- mation on how a component is used via its provided interfaces. The information contain service call frequencies, service call order and probabilities, as well as characterisations of the input parameters of component calls. The manually specified part of the usage con- text is limited to the outermost part of an assembly of components which the PCM calls System. The PCM implements the specified part of the usage context in its UsageModel (see section3.8).

Having the usage context of the System, analysis methods can derive the usage con- texts of the inner components from it. This is done by evaluating how components trans- form their own usage context into usage contexts of components connected to their re- quired interfaces.

To give an example for a different usage context, consider figure 3.6 again. Let the numbers 0.3 and 0.7 attached to the assembly connectors denote the probability of routing a call to the component in server 1 or in server 2 respectively. Then the usage context of the component allocated on server 2 contains a higher call frequency to its services than the component allocated on server 1.

In this thesis, transformations use the specified usage context to generate workload drivers from it. They simulate the behaviour of users, the request frequency caused by them, or characterisations of the data they pass to the system.

Section 4.4.8 gives details on the different types of contexts in the simulation based analysis method SimuCom introduced in this thesis.