Valdis Vitolins, Audris Kalnins, EDOC 2005 Semantics of UML 2.0 Activity Diagram for Business Modeling by Means of Virtual Machine

Valdis Vitolins, Audris Kalnins, EDOC 2005 Introduction The goal of this paper is to define an Activity Diagram Virtual Machine (ADVM), which would describe this token-based semantics formally enough for process execution The paper proposes an ADVM for a subset of activity diagram features, which are significant for business process modeling and definition

Valdis Vitolins, Audris Kalnins, EDOC 2005 Sample Activity Diagram

Valdis Vitolins, Audris Kalnins, EDOC 2005 Subset of the UML 2.0 AD and Limitations Subset: –All elements from Fundamental, Basic, Intermediate and some elements from Complete Activities: –Activities, Actions, Control and Object Flows, Activity Parameter Nodes, Pins, Control Nodes, Activity Partitions and Groups Limitations: a)outgoing edge from a ControlNode is not an incoming edge for the same ControlNode b)there should be no paths between CallBehaviorActions, InitialNodes, FinalNodes or ActivityParameterNodes containing both ForkNodes and JoinNodes Forbidden Constructs:

Valdis Vitolins, Audris Kalnins, EDOC 2005 Activity Diagram Standard Semantics Control Nodes with Guards are working as "traffic switches” for “visibility” of “offered tokens” Only active elements are Action Engines –They try to fill up their input pins with sets of tokens using "transitive closure visibility“ of “offered tokens” Activity Diagram Standard Semantics: –“visibility rules” are harder to implement than simple actions –Processing of “offered tokens” “all at once” doesn’t work correctly for Single Execution mode (important for simulation) - concurrent control tokens may be lost

Valdis Vitolins, Audris Kalnins, EDOC 2005 ADVM Semantics Edges and Control nodes between stable nodes are concatenated into Paths: –PassRule is created from Guards of Path’s edges which are "anded" together –each PassRule can be evaluated independently Main active elements are Push and Pull token Engines: –provide token movement between stable nodes (actions, initial, final) –Push engines are used for outgoing branches –Pull engines are used for incoming branches Our semantics: –Simple and more suitable for execution –Works also in Single Execution mode

Valdis Vitolins, Audris Kalnins, EDOC 2005 ADVM – other elements Action Engines provide token processing in Actions Activity Engines control activity invocation, startup and termination Input/Output Queues - for Actions, Initial, Final and ActivityParameter nodes ("stable places“) Push Paths - contain only Decision, Merge and Fork nodes (or no at all). Pull paths - contain at least one Join node (and Decision and Merge nodes) Pass Rule - Guards of path’s Edges "anded" together Join criterion - join specification for Pull paths, used by Pull Engine Token Group - set of tokens, which is jointly pulled by a Pull Engine into its input pin

Valdis Vitolins, Audris Kalnins, EDOC 2005 Subset of UML AD Metamodel and mapping to the ADVM classes

Valdis Vitolins, Audris Kalnins, EDOC 2005 Paths and Token Engines Paths are created as a "transitive closure" of Edges and IntermediateNodes between Queues of StableNodes. –constraints and conditions, coming from Guards and Control Nodes are "concatenated" into the PassRule TokenEngines for queues are added the following way: –if for an OutputQueue there exists at least one OutgoingPath without Join, then a PushEngine for this OutputQueue is created –if for an InputQueue there exists at least one IncomingPath with Join, then a PullEngine for this InputQueue is created

Valdis Vitolins, Audris Kalnins, EDOC 2005 Complete Metamodel of our AD VM (Excluding ActivityFactory class)

Valdis Vitolins, Audris Kalnins, EDOC 2005 Conclusion Equivalence: –Essential event trace – starts of action executions and the token sets consumed and produced by these actions are the same for both virtual machines on any activity diagram. In our subset of UML Activity Diagrams there is no real race for tokens by actions in the selected subset (no implicit fork, no forks in a path leading to a pull engine, mutually exclusive guards for decisions) any token will be delivered to its destination in our VM not later than in the original VM assertion that all input pins must have at least one token (or an appropriate group of tokens, if this is a “join pin”) for the action to start, becomes true at exactly the same moment when the original VM would have finally collected all the offered tokens Usage: –Works well for BPM and workflow systems, easily implementable –AD simulator – a tool important for workflow validation