Supuesta vulneración del derecho a la libertad de contratación

Before presenting the actual transformations, this sections introduces some basic ideas used to realise the transformations which support the following requirements (introduced in section2.4.1). First, transformations for the PCM need to be split among the developer roles. How to accomplish this has already been introduced in section3.1.2. Second, struc- turing the transformations in a special way eases support of Coupled Transformations and allows reuse among common transformation parts. In order to support the special structuring, the Template Method design pattern (Gamma et al.,1995, p.325) is ported to the used template engine. The following gives details on this.

The transformations developed in this thesis are model-2-text transformations map- ping PCM instances to code. The decision to favour model-2-text transformations over model-2-model transformations is grounded on the unavailability of working model-2- model transformation engines, e.g., a QVT engine, at the time of writing. Nevertheless, most of the time this thesis describes the transformations on a conceptual level. It only presents model-2-text transformation templates occasionally to illustrate special issues.

Conceptually, a migration to model-2-model transformations when mature model-2- model transformation engines become available should be no problem. These engines

can be used to shift parts of the transformation logic on the model level removing it from the model-2-text transformations.

There are at least two possible options to realize transformations where one transfor- mation depends on the other as it is the case for Coupled Transformations. One option which is always available is to implement the code and prediction transformations inde- pendently from scratch. To link both transformations, the transformations read the same parameter set (mark model). This offers the advantage to focus on the target platform of the respective transformation both in its implementation and in its generated output. For example, the simulation transformation could use all features of the underlying simula- tion framework, producing a highly optimized simulation code. However, when looking at the generated output, the difference between a specialized simulation implementation and a specialized code skeleton implementation is potentially high, making it difficult to include the same parameterisations in both transformations in order to validate the Coupled Transformations ideas.

Hence, a different approach is used in this thesis. The idea originates from the Tem- plate Method design patternGamma et al.(1995) used in object-oriented languages. The pattern is applied in cases where a base algorithm exists which forms a common skeleton for a whole set of algorithms. Each instance of the algorithm only changes the behaviour at certain predefined spots in the total algorithm. The base algorithm is the template which contains the so called template methods, which defer their actual implementation to implementations in subclasses.

Some transformation languages support inheritance which is needed to use the Tem- plate Method pattern (e.g., in the upcoming OMG Model-2-Text standard (Object Man-

agement Group (OMG), 2007b)). However, these engines are still immature. Because of

this, the transformations presented in this thesis use the template-based model-2-text en- gine of openArchitectureWare, version 4.2 (oAW) (openArchitectureWare (oAW), 2007). The idea is to use oAW to simulate the Template Method pattern. OpenArchitectureWare offers a template override facility which can be used to simulate inheritance, the exact technical details are omitted here as they are highly dependent on the actual transforma- tion engine and subject to change as the transformation engines - including oAW - further mature.

However, conceptually, the Template Method pattern allows to define transforma- tions which share a common part, based on common templates. However, certain parts of the transformation output change based on the selected set of template methods (see figure4.6). The transformations presented in sections4.4-4.7utilize the template method based approach. Depending on the actual target (SimuCom, ProtoCom, or code skele- tons) certain parts of the output change while others remain constant. This allows the

transformations to support multiple targets which share a common transformation core. This common core also eases the inclusion of the same mark model in all transformations which is needed for Coupled Transformations.

Basis- Transformation- Template _Tem p la te - M e th o d s S im u la ti o n - T e m p la te -M e th o d s C o d e -S k e le to n s - T e m p la te -M e th o d s

Figure 4.6: Template Methods used to Implement Coupled Transformations

Consider the following example to understand transformations based on template methods. To generate code from a RDSEFF, a transformation has to visit all AbstractAc- tions in a behaviour sequentially from the StartAction to the StopAction and generate code for each type of action visited. Now consider a LoopAction in this chain of actions for which code should be generated. Having SimuCom as target, the code has to determine the value of the random variable describing the number of loop iterations and then iterate over the loop body for this amount of times (see listing 4.1). The transformation gener- ating a code skeleton generates a loop control flow statement like for, but in contrast to the simulation transformation, the loop iteration count is not known. Hence, a comment is generated from the loop iteration count specification (see listing4.2). This information informs the programmer about the assumptions in the model from which the code has been generated. This allows him to give feedback in case the assumptions prove wrong during implementation. In such a case, the model can be adjusted accordingly.

Listing 4.1Simulation Loop

int max_count = evaluate("IntPMF[(10;0.4)(20;0.6)]"); for (int i=0; i < max_count; i++) {

// generated loop body }

Listing 4.2Code Skeleton Loop

for (int i=0;

i < 0 /*To do, loop IntPMF[(10;0.4)(20;0.6)]*/; i++) {

// generated loop body }

In this example, common behaviour in both transformations is to iterate on the actions of a RDSEFF. The different code fragments generated for the LoopAction is specialized behaviour in a template method.

For the SimuCom transformation all PCM concepts related to random variables are part of special template methods like the loop action shown in the example. This espe- cially includes the interaction with simulated hardware resources loaded with resource demands in InternalActions. On the other hand, the transformation rules for components and composed structures is common and hence, part of the core transformation. The following sections give more details.

The template method based transformations also enable to easily create the ProtoCom mapping, which uses a mixture of the template methods for the simulation mapping and the code-skeleton mapping. For this, missing behaviour in the PCM model instance is replaced with simulated behaviour. Only a small amount of the template methods is specifically dedicated to the prototype mapping while all others are simply reused. Sim- ulating resource demands on real hardware resources is the only part specific for Proto- Com. It replaces SimuCom’s resource demand processing based on simulated hardware resources.