Skip to content
This repository has been archived by the owner on May 27, 2019. It is now read-only.

Latest commit

 

History

History
72 lines (49 loc) · 5.96 KB

Explicit-traceability-M2M-transformation.adoc

File metadata and controls

72 lines (49 loc) · 5.96 KB

Explicit Traceability M2M Transformation

This page contains the documentation of the incremental model transformation using Xtend and VIATRA Query with the explicit traceability model used for identifying unsynchronized changes between the CPS and deployment models.

Introduction

This transformation variant uses the Event-driven Virtual Machine (EVM) that is part of VIATRA for specifying and executing a set of independent transformation rules. The rules are developed to monitor the traceability model between a CPS and a deployment model and any element in the CPS model without corresponding traces is transformed to synchronize the CPS and deployment models.

How does it work

For each type in the CPS metamodel, we create several rules for identifying their appearance, disappearance and optionally updates. The preconditions of these rules are defined by VIATRA Query patterns cpsXformM2M.eiq with the following naming convention:

  • unmappedCPSElement: match a CPSElement (e.g. host instance) that has no corresponding trace

  • monitoredCPSElement: match a CPSElement that has complete trace

  • deletedDeploymentElement: match a DeploymentElement that has a trace, but the related CPS element does not exist

The naming convention of rules that use these patterns is the following:

  • CPSElementMapping: matches of unmappedCPSElement pattern are processed to create corresponding elements in the deployment model (e.g. DeploymentApplication for ApplicationInstance) and the trace

  • CPSElementUpdate: matches of monitoredCPSElement pattern are processed to monitor the CPSElement and synchronize attribute changes (e.g. the IP of the host instance is changed)

  • CPSElementRemoval: matches of deletedDeploymentElement pattern are processed to remove the corresponding elements from the deployment model and the trace

There are rules defined for:

  • Host instances

  • Application instances allocated to mapped hosts

  • State machines for each mapped application instance

  • States

  • Transitions

  • Triggers (update is not used)

The transformation execution is completely event-driven, without any priority between rules or imperative control structures. The set of rules are collected and an execution schema is created with a scheduler that is called every time the model has changed. The scheduler invokes the EVM executor that fires all activations that are enabled for any of the rules. Activations are not ordered in any way, the executor simply takes the next enabled in a while loop that runs as long as there is any enabled activation.

Handling of 1-to-n mappings

Since the transformation watches the traceability model, a missing mapping for any 1-to-n mapping is represented as a match of the corresponding unmappedCPSElement pattern. If an application type has 3 instances which are already transformed then there will be 3 unmappedStateMachine matches and also 3 activations of the StateMachineMapping rule.

Creation of triggers

Triggers are found in the CPS model by VIATRA Query patterns that evaluate the actions of transitions, check communication between host instance and check allocation of application instances to hosts. In addition, the traceability model is used to find those BehaviorTransition elements that correspond to the CPS transitions. Note that this is needed since instances of the application type may be allocated to different hosts. Therefore, two CPS transitions with matching send and wait actions may only represent triggers for some or none of the application instances.

Technical details

API

The API of the transformation is the following class: CPS2DeploymentTransformation.xtend (source)

Usage example

The following is a simple example for executing the transformation:

// assume cps2dep is a CPSToDeployment object
// assume engine is an VIATRA Query engine initialized on the resource set containing cps2dep
xform = new CPS2DeploymentTransformation
xform.initialize(cps2dep, engine)
xform.execute()
// model changes are incrementally synchronized
// calling execute later has no effect
xform.dispose

Summary and comparison

The explicit traceability variant implements the CPS-to-Deployment transformation by watching the state of the traceability model and synchronizes any changes incrementally from the CPS model to the Deployment model. After the initial execution (when the traceability and deployment models are empty), the event-driven rules are executed whenever model changes happen and only changed elements are transformed instead of the whole model. Additionally, this variant can be started even if the CPS, deployment and traceability models are already transformed (e.g. by a batch transformation) and it is able to correctly work incrementally from that point. Compared to the Query result bookmarking M2M transformation, it behaves correctly even if only the CPS model has been changed after a previous transformation.