1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
|
# Explicit Traceability M2M Transformation
ifdef::env-github,env-browser[:outfilesuffix: .adoc]
ifndef::rootdir[:rootdir: ../]
ifndef::imagesdir[:imagesdir: {rootdir}/images]
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 <<evm#,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 link:https://git.eclipse.org/c/viatra/org.eclipse.viatra.examples.git/tree/cps/transformations/org.eclipse.viatra.examples.cps.xform.m2m.incr.expl/src/org/eclipse/viatra/examples/cps/xform/m2m/incr/expl/queries/cpsXformM2M.vql[cpsXformM2M.vql] 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 link:https://git.eclipse.org/c/viatra/org.eclipse.viatra.examples.git/tree/cps/transformations/org.eclipse.viatra.query.examples.cps.xform.m2m.incr.expl/src/org/eclipse/viatra/query/examples/cps/xform/m2m/incr/expl/rules[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` (link:https://git.eclipse.org/c/viatra/org.eclipse.viatra.examples.git/tree/cps/transformations/org.eclipse.viatra.query.examples.cps.xform.m2m.incr.expl/src/org/eclipse/viatra/query/examples/cps/xform/m2m/incr/expl/CPS2DeploymentTransformation.xtend[source])
### Usage example
The following is a simple example for executing the transformation:
```xtend
// 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 traceability M2M transformation,Query result traceability M2M transformation>>, it behaves correctly even if only the CPS model has been changed after a previous transformation.
|
