VIATRA2/Activity Diagrams to Petri Nets

Aim

This tutorial example presents a transformation from a core subset of UML2 Activities to the domain of Petri-Nets (also known as Place/Transition Nets). This simple transformation imitates a set of complex, real-world model transformations that map high-level engineering models such as BPEL into semantical domains (i.e. mathematical formalisms) such as transition systems, for formal verification and analysis by tools such as SAL.

The example is meant to be the first one to read after completing the Hello World tutorial, and contains the explanation of design decisions, important graph patterns and GT rules, as well as some VTCL code. As an important point, this tutorial includes an exercise for readers, to help them learn transformation development.

TODO

Background

VIATRA2

The tutorial assumes that the readers have already familiarized themselves with the basic features of the user interface of VIATRA2, the notion of model transformation and the basic concepts of the formalism GTASM. The Getting Started block is recommended reading before starting this tutorial. In particular, the Using Transformations page introduces how to load and use this transformation.

Source domain: UML Activities

Core set of UML2 Activity Diagram elements

UML Activities form a standard workflow description language, with countless modeling tools and diagram editors available. This tutorial will use the core elements of UML Activity modeling.

An Activity is the model of the process, represented in an Activity Diagram (AD) by a large box containing nodes and edges. An activity consists of several action nodes (also called executable nodes, more precisely opaque actions), denoted by smaller rounded blocks; each represent some action that is performed for some time during this process. We will only be interested in the most common kind of activity edges: control flow edges connect actions to define their sequence of execution. This sequence starts at the initial node, and terminates at the flow final node. These two are not actual actions, but special control nodes.

Further control nodes include the decision node, that represents a branching into two or more possible paths of execution according to some criterion (the criterion itself is not represented in our subset of UML Activities). These alternative paths meet at control nodes called merge nodes, from which point they proceed with the same sequence. A similar pair of control nodes is fork and join, which denote respectively a point where the execution is split into several concurrent threads, and a point where these threads of events catch up with each other to proceed as a single sequence.

See `uml/activity_forkjoin.uml` for an example source model, and `uml/activity_forkjoin.umlact` as the Activity Diagram visualizing it.

Target domain: Petri Nets

Example Petri Net

Petri Nets (PN) are a mathematical formalism for specifying the behaviour of discrete systems. This formalism excels at modeling concurrency and synchronization, resource constraints and loosely dependent subsystems. There are efficient analysis (model checking) tools for Petri Nets, capable of e.g. finding deadlocks, deciding the reachability of states with given properties, proving the conservation of resources or the cyclic nature of a sequence of events.

In the core subset of the formalism, a PN is a directed bipartite graph. One partition of nodes are called places, and represented by circles in diagrams. The other type of nodes is the transition, commonly represented by an elongated rectangle. Edges can flow either from a transition to a place, or from a place to a transition, and will be called arcs to distinguish from UML Activity Edges.

A state of the PN is defined by a marking, which assigns a natural number (0, 1, or more) to each place. This number is visualized as the number of tokens contained in the place, indicated by small dots in the circle. The marking of the initial state is an important part of the definition of the Petri Net.

A transition is said to be enabled or fireable in a state if each of its incoming arcs come from marked places (i.e. containing at least one token). A state change of the Petri Net is the firing of an enabled transition; this consists of removing a token from each incoming place, and adding a token to each place at the end of outgoing arcs from the transition.

Transformation design: mapping Activities into Petri Nets

Action and control flow

We interpret UML Activity semantics in a way such that executing and action is not instantaneous, but can last for some time. Also, there is no obligation for an action to start as soon as the previous one in the sequence is finished, some time can pass in-between. Thus for each Action, the resulting Petri Net should have one or more states where the action is being executed. Likewise for each control flow edge, there should be PN states where the edge is active, i.e. execution has passed the action (or control node) at the source of the control flow edge, but has not yet reached the Activity Node at the target of the edge.

Illustrating the principle of mapping a UML Activity Control Flow into the Petri Net domain.
Illustrating the principle of mapping a UML Activity Action into the Petri Net domain.

This goal can be achieved by creating a Petri place for each action and each control flow in the Activity model. In the marking belonging to a state of the Petri net, a token in the place corresponding to an action means that an instance of the process is currently executing the action. Similarly, a token in the place corresponding to a control flow means that the activity edge is currently active.

Obviously, we also need transitions, otherwise the Petri Net would be static. For each control flow incoming in an action, a transition should be created to represent the start of execution of the action. This transition has an incoming arc from the place representing the control flow, and an outgoing arc to the place representing the action. Thus the transition is enabled if the activity edge is active, and firing it will start the execution of the action and cease the activation of the edge. Similarly, a transition should represent the termination of the action, with an incoming arc from the place of the action, and an outgoing arc to the place of the edge.

This argument suggests the following principle for the transformation. Each control flow edge will be mapped into a place representing when the edge is active. Each action should be mapped into two transitions and a place in-between, with two arcs linking the three Petri nodes. The first transition represents entering the action, the place (more precisely, a token in the place) represents that the state is during the execution of the action, and the second transition represents exiting the action. Then the entering transition of the action should be linked by an incoming arc to the place representing the incoming activity edge, and the exiting transition should be linked by an outgoing arc to the place representing the outgoing activity edge.

Initial and flow final nodes

Illustrating the principle of mapping a Flow Final Node of a UML Activity model into the Petri Net domain.

When execution reaches a flow final node in the Activity, the instance of the process terminates. More precisely, if there are several threads of execution (due to a fork node), the one that reaches the flow final node terminates, while others are unaffected (this is the difference between the flow final node and a different type of terminating node). In Petri Net terminology, the token representing the activation of the incoming control flow edge should be consumed by the flow final node, without putting a token in any place representing an activity edge or action. This is achieved by a transition that has an incoming arc from the place corresponding to the control flow edge pointing to the flow final node, and no outgoing arcs.

Illustrating the principle of mapping an Initial Node of a UML Activity model into the Petri Net domain.

There are at least two ways to interpret an initial node. One possibility is that the node can activate the outgoing control flow edge exactly once, thereby starting the process. In some contexts, however, it makes more sense to assume that the initial node can activate the control flow an arbitrary number of times, launching multiple process instances that are executed concurrently. Both versions can be represented by Petri Nets (although in the second case there would be a semantic issue with join nodes, which is out of scope for this tutorial). In both cases, the initial node is mapped into a transition, with an outgoing arc to the place corresponding to the outgoing control flow edge. We opted to choose the first interpretation; a place marked initially with one token (the only marked place in the initial state) is created and connected by an arc to the transition corresponding to the initial node. This marked place ascertains that the transition can fire only once, as the token will be removed upon the firing, rendering the transition disabled from that time on. The other interpretation can be achieved by simply omitting this place and the arc; in this case the transition would be able to fire any time, an arbitrary number of times.

Fork and join

Illustrating the principle of mapping a Fork Node of a UML Activity model into the Petri Net domain.
Illustrating the principle of mapping a Join Node of a UML Activity model into the Petri Net domain.

Fork nodes have one incoming and several outgoing activity edges. When the incoming edge is active, the fork node activates all outgoing edges, so that several flows are created that will proceed concurrently. A straightforward Petri Net representation is a single transition, with incoming and outgoing arcs to the places representing incoming and outgoing control flow edges, respectively.

Join nodes mark a point of execution that can only proceed (i.e. activate the single outgoing edge) when all joined flows have reached it, i.e. all incoming activity edges are active. The Petri Net representation, much like that of the fork node, is a single transition, with incoming and outgoing arcs to the places representing incoming and outgoing control flow edges, respectively.

Implementation using GT rules

Once we have designed the overall principle of the transformation, we can formalize it using GT rules, and implement them in VTCL, the transformation language of VIATRA2.

Control Flow

Illustration of a graph pattern, consisting of a control flow element and the place corresponding to it.

Specifying graph transformation rules requires specifying graph patterns. Our first pattern expresses a control flow element that has already been mapped into the Petri Net domain. Thus the pattern consists of a control flow element from a UML Activity, the Petri Net place corresponding to it, and a special traceability link between them. Such links will be useful later as they help to remember which Petri Net node corresponds to which UML model element, preserving a mapping between source and target models, thereby achieving traceability.

The visual illustration of this pattern looks admittedly strange, as the traceability link connects to the control flow element, which is an edge. It is good to remember that for this and similar purposes, VIATRA2 models tolerate edges (relations) connecting to other edges. Furthermore in this case, the control flow element is actually a node in the abstract UML model, despite being denoted by an edge on the Activity Diagram. It is useful to keep in mind that transformations always operate on the abstract syntax, from which the concrete syntax may differ significantly. As a further deviation from the visual illustration of this pattern, we actually constructed the pattern with an additional node for the Petri Net itself, and an edge that identifies the place as belonging to this net. While not apparent right now, this addition will be useful later.

The following VTCL snippet defines the graph pattern `mappedControlFlow`.

```   pattern mappedControlFlow(ControlFlow, PetriPlace, PetriNet) = {
'ControlFlow'(ControlFlow);
find activityEdgeMapping(ControlFlow, PetriPlace);
find placeOfNet(PetriPlace, PetriNet);
}
```

The three pattern variables are `ControlFlow`, `PetriPlace`, and `PetriNet`; they are intended to be mapped onto the control flow element, the place in the Petri Net, and the net itself, respectively.

The pattern imposes three constraints on these variables. The first one identifies the variable `ControlFlow` to be an entity of the type also called `ControlFlow`. Normally, only variable names are capitalized. As the name of the type starts with a capital letter, it has to be enclosed in single apostrophes to mark it as the name of a (meta)model element, as opposed to the name of a variable. The second constraint identifies an "`activityEdgeMapping`" between the activity edge (`ControlFlow`) and its image in the target model (`PetriPlace`); this is the part of the pattern that finds the traceability link. Finally, asserting "`placeOfNet`" ensures that `PetriPlace` is a place, `PetriNet` is a net, and the former is contained in the latter.

How does this single line assert all these? Actually, "`placeOfNet`" is not an edge (relation) of the model (and neither is "`activityEdgeMapping`"). They are graph patterns themselves, and the find keyword indicates pattern composition (or pattern invocation), which basically means reusing a predefined pattern as part of a different pattern. This utility pattern is defined this way:

``` pattern placeOfNet(PetriPlace, PetriNet) = {
net(PetriNet);
place(PetriPlace);
net.places(Places, PetriNet, PetriPlace);
}
```

The first constraint asserts that variable `PetriNet` is an entity of type `net`. The second constraint declares the variable `PetriPlace` is an entity of type `place`. The final constraint assert that the variable `Places` is a relation (note the ternary structure) of the type `net.places`, that connects from `PetriNet` to `PetriPlace`. This simple pattern thus matches Petri places belonging to Petri nets. Notice the absence of pattern variable `Places` from the list of parameters of the pattern: it is deliberately hidden from the outside.

Illustration of a GT Rule for mapping Control Flow.

Now, we can finally create Graph Transformation (GT) rule that map a control flow edge into a Petri place. This will be our first GT rule, and luckily it is a quite simple one.

The LHS would be a trivial pattern that recognizes a control flow edge. The RHS is the graph pattern `mappedControlFlow` defined above, so it contains an activity edge (actually, the same activity edge), a place, and a traceability link between them. By the definition of GT rules, the rule will be applicable on each control flow, and the result of the application would be a new Petri place, with a traceability link established between them.

It is possible for the control structure of the transformation program to guarantee that the GT rule is applied on each control flow element exactly once. Yet, it is often a good idea to formulate GT rules in such a way that it is immediately apparent that they cannot be applied on the same spot repeatedly. Here we achieve this by a so-called Negative Application Condition (NAC). A NAC is an extra constraint attached on the LHS pattern that, when satisfied, will invalidate a match of the pattern. NACs can also be described as graph patterns. In our case, the NAC pattern consists of the same control flow element already having a traceability link. Since it is a negative condition, the LHS will only match control flow elements that have not already been mapped into the Petri Net domain. In various graph pattern figures, NACs are indicated by red crosses, by entirely red visual elements, or by red boxes enclosing the pattern with NAC or NEG written on them. In the VTCL textual syntax, they are indicated by the keyword neg, followed by the invocation of the pattern constituting the NAC:

``` gtrule transformControlFlow(out ControlFlow, in PetriNet) = {
precondition pattern unmappedControlFlow(ControlFlow) = {
'ControlFlow'(ControlFlow);
neg find activityEdgeMapping(ControlFlow, NoPetriPlace);
}
postcondition pattern mappedControlFlow(ControlFlow, PetriPlace, PetriNet) = {
'ControlFlow'(ControlFlow);
find activityEdgeMapping(ControlFlow, PetriPlace);
find placeOfNet(PetriPlace, PetriNet);
}
action {
call copyName(ControlFlow, PetriPlace);
}
}
```

Here we can identify the simple LHS (precondition) pattern consisting of a control flow element and a NAC; our familiar RHS (postcondition) pattern; and finally an action sequence that is responsible for naming the place the same way as the control flow element was named (and giving descriptive names to elements is important). This name copying is defined in an imperative ASM rule called `copyName`, that is simply invoked here. It is worth pointing out that the LHS and RHS share the `ControlFlow` variable, therefore it will mean the same model element in both cases. Also, the action sequence has access to the value of `PetriPlace`, which is the place created by the RHS (or more precisely, by applying the declarative part of the rule).

The parameters of the GT rule are the variables `ControlFlow` and `PetriNet`. The latter is an input parameter: it is meant to be explicitly specified before applying the GT rule. This is important: we do not want to create a new Petri Net with each rule application (even though it it in the RHS but not the LHS), but use the same target model as the container of results everywhere. The control structure of the transformation will have to provide the identity of the target Petri Net when invoking this GT rule. The `ControlFlow` variable, on the other hand, is an output parameter; its value is meant to be determined in the GT rule, by the pattern matching process of the LHS, and propagated to the outside. Parameters can also be specified with the inout keyword, indicating that they can either be fixed or left for pattern matching to identify. Variables such as `PetriPlace`, however, are meant to be created by within the rule application, therefore if they appear as a parameter, it only makes sense to mark them as output parameters.

Action nodes

GT rule for mapping an Action node -- first version

Each Action node has to be transformed to a pair of transitions (representing the start and end of the action) and a place in-between (representing the duration of the action), as well as connecting arcs. It is important to notice that an arc has to be constructed connecting the place representing the incoming activity edge to the transition representing entering the action, and an additional arc is needed from the transition representing exiting from the action to the place representing the outgoing activity edge. Therefore when we are applying the graph transformation rule, we have to be aware of the surroundings of the action node. The easiest way to do this is to include the incoming and outgoing edge (and their respective Petri place counterparts) in the left hand side pattern.

We can now see that this graph pattern will be more complex than the previous one. The LHS will match an action, having an incoming and outgoing control flow, both with a traceability link to their corresponding places. Also, there is a NAC expressing that the action has no traceability link yet, i.e. it has not yet been mapped into the Petri Net domain. The RHS includes the same elements (sans NAC), and the image of the action node: one place, two transitions, all three connected by traceability links to the action node; and four arcs, two of which is between the newly created elements, and the other two connecting them with the previously existing places. Once again, the actual graph patterns and rules will be a little more complex, as the entity representing the Petri Net itself also appears in the pattern, so that the rule can place newly created Petri elements into the net.

Phrases like "the Petri place representing the incoming control flow edge of the activity node" (and the same for the outgoing edge) have already been used numerous times in this tutorial; they appear as sub-patterns in the GT rule for transforming action nodes, and will be used several times in the future as well. This is a great opportunity to reuse this fragment in various places, for improved conciseness, readability, quicker transformation development, and better performance in some cases. First, we create two patterns matching this fragment for incoming and outgoing edges, respectively:

``` pattern placeOfIncomingEdge(ActivityNode, PetriPlace) = {
'ActivityNode'(ActivityNode);
'ActivityNode'.incoming(InComing, ActivityNode, ActivityEdge);
'ActivityEdge'(ActivityEdge);
place.placeTraceEdge(Trace, PetriPlace, ActivityEdge);
place(PetriPlace);
}
pattern placeOfOutgoingEdge(ActivityNode, PetriPlace) = {
'ActivityNode'(ActivityNode);
'ActivityNode'.outgoing(OutGoing, ActivityNode, ActivityEdge);
'ActivityEdge'(ActivityEdge);
place.placeTraceEdge(Trace, PetriPlace, ActivityEdge);
place(PetriPlace);
}
```
GT rule for mapping an Action node -- second version

The two pattern parameters are the activity node and the Petri place representing an incoming/outgoing activity edge. Local variables include the incoming/outgoing activity edge itself, the "Incoming"/"Outgoing" relation (association) between the activity node and activity edge, and the traceability link between the activity edge and the place. The pattern constraints enforce the types of entity and relations variables, as well as the incidence (source/target) of relations. Once again, the action part simply gives meaningful names to the most important new elements.

As these helper graph patterns can be simply invoked within the LHS / RHS patterns, we can compact the code of the graph transformation rule. Neither the LHS nor the RHS will need the local pattern variables representing incoming and outgoing activity edges, their "Incoming"/"Outgoing" relations (coming from the action) and traceability links. Still, the RHS will be quite large, simply because the shear number of model elements to be created.

Some additional compaction is achieved by invoking patterns `activityNodeTransitionMapping` and `activityNodePlaceMapping`, that envelop traceability links between activity nodes and transitions or places, respectively. Similarly, invocations of the patterns `placeTransitionArc`, `transitionPlaceArc`, `placeOfNet` and `transitionOfNet` are used to concisely template the newly created Petri Net features. It might not be immediately obvious why it's worth to reuse these trivial graph patterns, but even patterns as simple as a single edge can conceal a pattern variable (that is matched against the relation) and also assert the type of the two endpoints.

``` gtrule transformExecutableNode(out ActivityNode, in PetriNet) = {
precondition pattern unmappedExecutableNode(ActivityNode, IncomingEdgePlace, OutgoingEdgePlace) = {
'ExecutableNode'(ActivityNode);
find placeOfIncomingEdge(ActivityNode, IncomingEdgePlace);
find placeOfOutgoingEdge(ActivityNode, OutgoingEdgePlace);
neg find activityNodeTransitionMapping(ActivityNode, NoPetriTransition);
}
postcondition pattern mappedExecutableNode(ActivityNode, IncomingEdgePlace, PetriTransitionEnter,
PetriPlaceDuring, PetriTransitionExit, OutgoingEdgePlace, PetriNet) =
{
'ExecutableNode'(ActivityNode);

find placeTransitionArc(IncomingEdgePlace, PetriTransitionEnter);

find activityNodeTransitionMapping(ActivityNode, PetriTransitionEnter);
find transitionOfNet(PetriTransitionEnter, PetriNet);

find transitionPlaceArc(PetriTransitionEnter, PetriPlaceDuring);

find activityNodePlaceMapping(ActivityNode, PetriPlaceDuring);
find placeOfNet(PetriPlaceDuring, PetriNet);

find placeTransitionArc(PetriPlaceDuring, PetriTransitionExit);

find activityNodeTransitionMapping(ActivityNode, PetriTransitionExit);
find transitionOfNet(PetriTransitionExit, PetriNet);

find transitionPlaceArc(PetriTransitionExit, OutgoingEdgePlace);
}
action {
call copyName(ActivityNode, PetriPlaceDuring);
rename(PetriTransitionEnter, name(PetriPlaceDuring) + "Enter");
rename(PetriTransitionExit,  name(PetriPlaceDuring) + "Exit");
}
}
```

It is worth noting that the RHS includes no invocation of the `placeOfIncomingEdge` and `placeOfOutgoingEdge` graph patterns. So why aren't the contents (the activity edge, the "Incoming"/"Outgoing" relation, and the traceability link) deleted? The answer is that the LHS variables that are matched to these elements are simply not visible to the RHS, therefore they will not be deleted. Deletion is avoided if the variable is missing either from the parameters of the RHS pattern, or the parameters of the LHS pattern, or the parameters of the pattern invoked in the LHS that defines these variables. Using this semantic choice, the RHS can sometimes be made simpler.

Using techniques and elements that will be introduced in later sections, the actual code shipped with the example project looks different: finding the place belonging to the incoming and outgoing edge and connecting arcs to them is performed in the action part. Generally, you can reduce the RHS (and sometimes the LHS also) and substitute it with imperative model manipulation in the action sequence. It is also possible to eliminate the RHS altogether; the GT rule will then degenerate to a declarative precondition and a freely programmable action sequence.

``` gtrule transformExecutableNode(out ActivityNode, in PetriNet) = {
precondition pattern unmappedExecutableNode(ActivityNode) = {
'ExecutableNode'(ActivityNode);
neg find activityNodeTransitionMapping(ActivityNode, NoPetriTransition);
}
postcondition pattern mappedExecutableNode(ActivityNode, PetriTransitionEnter,
PetriPlaceDuring, PetriTransitionExit, PetriNet) =
{
'ExecutableNode'(ActivityNode);

find activityNodeTransitionMapping(ActivityNode, PetriTransitionEnter);
find transitionOfNet(PetriTransitionEnter, PetriNet);

find transitionPlaceArc(PetriTransitionEnter, PetriPlaceDuring);

find activityNodePlaceMapping(ActivityNode, PetriPlaceDuring);
find placeOfNet(PetriPlaceDuring, PetriNet);

find placeTransitionArc(PetriPlaceDuring, PetriTransitionExit);

find activityNodeTransitionMapping(ActivityNode, PetriTransitionExit);
find transitionOfNet(PetriTransitionExit, PetriNet);

}
action {
call copyName(ActivityNode, PetriPlaceDuring);
rename(PetriTransitionEnter, name(PetriPlaceDuring) + "Enter");
rename(PetriTransitionExit,  name(PetriPlaceDuring) + "Exit");
forall EdgePlace with apply connectNodeToIncoming(ActivityNode, PetriTransitionEnter, EdgePlace) do skip;
forall EdgePlace with apply connectNodeToOutgoing(ActivityNode, PetriTransitionExit, EdgePlace) do skip;

}
}
```

Fork, join, and flow final nodes

Two GT rules for mapping fork nodes

Mapping fork nodes poses additional challenges. The first step is straightforward: a fork node that has no yet been mapped, will be mapped into a transition that has an incoming arc from the place representing the single incoming activity edge. However, then all outgoing activity edges will have to be mapped to arcs connecting the transition to their respective places. This step is captured by a second GT rule. The two GT rules will have to cooperate: each application of the first rule (i.e. the mapping of a fork node) is tied to applying the second rule for all possible applications incident on this fork node (and its corresponding transition). As the application of the second rule is closely controlled by the application of the first one, it does not need to re-assert that the activity node is indeed a fork node - thus paving the way for reuse.

Implementing the second GT rule is very easy: the LHS and the RHS graph patterns have both been already defined. Of course, this requires us to omit the NAC from the LHS. This is admissible if this rule is only meant to be applied on newly created activity node - transition mappings, but would cause problems (duplicate arcs) if used without care. As we do not name arcs, no action sequence is required.

``` gtrule connectNodeToOutgoing(in ActivityNode, in PetriTransition, out EdgePlace) = {
precondition find placeOfOutgoingEdge(ActivityNode, EdgePlace)
postcondition find transitionPlaceArc(PetriTransition, EdgePlace)
}
```

How do we ensure that this GT rule is applied together with the first one? The action sequence of the first rule can simply apply this GT rule, quantifying over all possible outgoing edges (using graph pattern matching to satisfy the LHS `placeOfOutgoingEdge`).

``` gtrule transformForkNode(out ActivityNode, in PetriNet) = {
precondition pattern unmappedForkNode(ActivityNode, IncomingEdgePlace) = {
'ForkNode'(ActivityNode);
find placeOfIncomingEdge(ActivityNode, IncomingEdgePlace);
neg find activityNodeTransitionMapping(ActivityNode, NoPetriTransition);
}
postcondition pattern mappedForkNode(ActivityNode, IncomingEdgePlace, PetriTransition, PetriNet) =
{
'ForkNode'(ActivityNode);

find activityNodeTransitionMapping(ActivityNode, PetriTransition);
find transitionOfNet(PetriTransition, PetriNet);

find placeTransitionArc(IncomingEdgePlace, PetriTransition);
}
action {
call copyName(ActivityNode, PetriTransition);
forall EdgePlace with apply connectNodeToOutgoing(ActivityNode, PetriTransition, EdgePlace) do skip;
}
}
```

Here, the forall keyword indicates that the `connectNodeToOutgoing` rule should be applied on all LHS matches, i.e. all substitutions of the `EdgePlace` variable (since the other two rule parameters are inputs that are already known). skip means doing nothing; it can be substituted by some real imperative action that will be executed each time `connectNodeToOutgoing` is applied.

The join node, and even the flow final node can be transformed in a similar fashion. (Not the initial node, though: it requires the construction of a marked place and a connecting arc.) However, basically all three of these activity node types are transformed the same way: a transition is created for them, and then for each incoming and outgoing control flow edge, if any, an arc will be created that connects the newly created transition and the place corresponding the activity edge (in the same direction). Since we are already in the spirit of reusing, we can define a single GT rule that transforms these three kinds of activity nodes.

``` gtrule transformForkJoinFinalNode(out ActivityNode, in PetriNet) = {
precondition pattern unmappedForkJoinFinalNode(ActivityNode) = {
neg find activityNodeTransitionMapping(ActivityNode, NoPetriTransition);
}
postcondition pattern mappedForkJoinFinalNode(ActivityNode, PetriTransition, PetriNet) = {
find activityNodeTransitionMapping(ActivityNode, PetriTransition);
find transitionOfNet(PetriTransition, PetriNet);
}
action {
call copyName(ActivityNode, PetriTransition);
forall EdgePlace with apply connectNodeToOutgoing(ActivityNode, PetriTransition, EdgePlace) do skip;
forall EdgePlace with apply connectNodeToIncoming(ActivityNode, PetriTransition, EdgePlace) do skip;
}
}
```

In the precondition, `ActivityNode` is asserted to be either a fork node, a join node, or a flow final node. How is this achieved? By an entity type assertion, using `ad2petri.helpermetamodel.forkJoinFinalNode`, which is a fictive type in a helper metamodel invented just for this transformation, marked as a common supertype of entity types `ForkNode`, `JoinNode` and `FinalNode` (check it out in the model space!). Yes, you can do this in VIATRA2, without actually modifying the original UML and Petri Net metamodels. Moreover, you can even use the or keyword to define disjunctive bodies of graph patterns, although this powerful feature is not usable at LHSs of GT rules, only for general purpose pattern matching, model querying and iteration.

Exercise: decision and merge

TODO

``` ERROR - Could not transform activity node: uml.models.activity_complex_uml.uN596_b4.ComplexActivity.DecisionNode
ERROR - Could not transform activity node: uml.models.activity_complex_uml.uN596_b4.ComplexActivity.MergeNode
*** Cound not transform UML Activity: ComplexActivity
--- Transformation terminated.
```