Introduction
The idea behind this transformation variant is similar in concept to the Xtend and Query batch variant. Traverse the model and transform the elements according to the specification using VIATRA Query patterns. The main difference is the usage of the VIATRA Batch Transformations and Statements API.
How does it work
In this variant the transformation steps are executed in the following order:
-
Transformation of the host instances
-
Create a new DeploymentHost in the deployment model representing the matched HostInstance. Add trace to traceability.
-
Related patterns:
-
hostInstance
-
-
-
Transformation of the application instances
-
Create a new DeploymentApplication in the deployment model representing the matched ApplicationInstance. Add trace to traceability.
-
Related patterns:
-
applicationInstance
-
cps2depTrace
-
-
-
Transformation of the state machines
-
Create a new DeploymentBehavior in the deployment model representing the matched StateMachine for the ApplicationInstance specified by the pattern. This happens for every ApplicationInstance with a type that defines the StateMachine. Add DeploymentBehavior to proper trace in traceability. If it does not exist, create it.
-
Related patterns:
-
appInstanceWithStateMachine
-
applicationInstance
-
cps2depTrace
-
-
-
Transformation of the states of the state machines
-
Create a new BehaviorState in the deployment model representing the matched State for the ApplicationInstance specified by the pattern. This happens for every ApplicationInstance with a type that defines the StateMachine containing the State. Set the DeploymentBehavior’s current state to the created BehaviorState if the original State was an initial state of it’s state machine. Add BehaviorState to proper trace in traceability. If it does not exist, create it.
-
Related patterns:
-
state
-
appInstanceWithStateMachine
-
applicationInstance
-
cps2depTrace
-
-
-
Transformation of the transitions of the state machines
-
Create a new BehaviorTransition in the deployment model representing the matched State for the ApplicationInstance specified by the pattern. This happens for every ApplicationInstance with a type that defines the StateMachine containing the State containing the Transition. Add BehaviorTransition to proper trace in traceability. If it does not exist, create it.
-
Related patterns:
-
transition
-
state
-
appInstanceWithStateMachine
-
applicationInstance
-
cps2depTrace
-
-
-
Transformation of actions of the transitions
-
Set the trigger between the BehaviorTransitions representing the matched Transitions.
-
Related patterns:
-
action
-
sendAction
-
waitAction
-
actionPair
-
reachableHosts
-
transition
-
state
-
appInstanceWithStateMachine
-
applicationInstance
-
cps2depTrace
-
-
Handling of 1-to-n mappings
The 1-to-n mappings are mainly handled inside the VIATRA Query patterns. Each pattern is written in a way so that it will match each applicable ApplicationInstance, e.g. if a State exists the CPS model and there are 3 ApplicationInstances of the type that defines the StateMachine, then 3 matches will occur, and each of them will add a new BehaviorState to the corresponding DeploymentApplication’s DeploymentBehavior.
Creation of triggers
The creation of the triggers was mostly done leveraging the power of VIATRA Query.
The main pattern used is the one named "actionPair". This pattern returns a Transition with send action, another Transition with the corresponding wait action and an application instance for each of these transitions.
The other important pattern is "reachableHosts". This pattern searches for every HostInstance pair that can directly communicate with each other. Using this pattern we can filter the results of the "actionPair" pattern so we only have to handle the relevant action pair - aplication instance combinations.
Class of the transformation
The implementation of the transformation can be found in the following class:
CPS2DeploymentBatchViatra.xtend
Summary and comparison
If compared to the batch VIATRA Query variant, while being simpler and easier to maintain than its counterpart due to the simplified, more transformation oriented VIATRA API, this implementation offers the same functionality and performance as well.