Simple-and-optimized-Xtend-batch-M2M-transformation.adoc

Simple and Optimized Xtend Batch M2M Transformation

This is a pure Xtend implementation for the example transformation described in CPS to Deployment Transformation.

Introduction

The basic idea for the batch transformations - both for the simple and optimized versions - is to programmatically traverse the model that is to be transformed and apply all the transformation rules where they are applicable. Model traversal is done by using only basic language concepts and without using any advanced technologies or complex frameworks.

How does it work

The basic concept of this batched transformation is to transform a CPS model to a complete deployment model. This solution doesn’t support incremental transformation, only the whole model can be transformed, and it uses the following steps:

• It receives a root element for a mapping model which connects a CPS model root and a Deployment model root. The initialization step is to clear all traces from the mapping model and to delete all deployment hosts, if there is any.

• Iterates over every HostInstance in the CPS model using foreach and transforms each of them to DeploymentHosts. In every iteration DeploymentApplications are also created from ApplicationInstances (see next step) and added to the hosts' containments which are allocated to the host being processed.

• For each ApplicationInstance a DeploymentApplication is created. If the ApplicationType of the ApplicationInstance refers to a StateMachine, a DeploymentBehavior is also added for the ApplicationInstance (see next step)

• The States of the StateMachine referred by the ApplicationType are transformed to BehaviorStates. For each State, the Transitions are transformed to BehaviorTransitions (see next step)

• For each Transition between States of a StateMachine a BehaviorTransition is created connecting the corresponding BehaviorStates.

Handling of 1-to-n mappings

Mappings with 1-to-n multiplicity are created in the following cases

• StateMachine - DeploymentBehavior

• State - BehaviorState

• Transition - BehaviorTransition

This means that a trace is only created once for each of these CPS elements, and as the transformation advances the list of deployment elements of the trace might expand.

Creation of triggers

Triggers are created after all other model elements are created. First all mappings for Transitions in the CPS model are collected. In the next step all Transitions are selected which are sending a message (at this point we use that every transition can send/receive up to one message). When this is done all corresponding receiver Transitions are searched based on the action string. After this a trigger is created for each BehaviorTransition mapped to the sender Trace and each BehaviorTransition mapped to the receiver Traces if their container DeploymentHosts can communicate with each other.

To inspect DeploymentHost communication capability, their corresponding HostInstances are used: the communicatesWith relation is traversed using DFS. When the receiver HostInstances in the CPS model can be reached, the corresponding DeploymentHost is regarded as reachable.

Class of the transformation and example

The class for the transformation is an Xtend class named CPS2DeploymentBatchTransformationSimple. To apply the transformation, just instantiate the class with a traceability model pointing to the CPS and Deployment model roots and invoke the execute method :

// we assume there is an initialization row before like CPSToDeployment cps2dep = ...
xform = new CPS2DeploymentBatchTransformationSimple(cps2dep)
xform.execute

Optimized batch M2M transformation

In order to speed up the Xtend based variant we also developed a so called optimized version (CPS2DeploymentBatchTransformationOptimized). It is based on the simple batch transformation, however, includes the following optimizations:

• A caching mechanism that is to store the created traceability information for created model elements in map data structures (one map for both directions) to avoid traversal of traceability model. In case of BehaviorTransitions, the application type ID, action ID and HostInstance are also stored based on the CPS model for faster trigger creation.

• Code restructuring for better loop execution

• When creating triggers, the data for the receiver behavior transition are obtained in the outer for loop instead of the inner for loop.

This version can be executed using the following commands:

xform = new CPS2DeploymentBatchTransformationOptimized(cps2dep)
xform.execute

Summary and comparison

These two batch transformation methods, compared to the other implemented transformation techniques, have proven to be the least time-effective. However, it can be said that the optimized version preformed the same transformation during half the time of the simple transformation. The memory consumption is not necessarily low, but it was not the bottleneck concerning the performance.

The introduced transformations are not taking changes into consideration, they always perform a complete traversal of the CPS model. This is the main reason for the bad performance results compared to the incremental transformations when there is a change in the CPS model, that needs to be propagated via a repeated, complete transformation to the Deployment model.