1 / 11

Semantics of UML 2.0 Activity Diagram for Business Modeling by Means of Virtual Machine

Semantics of UML 2.0 Activity Diagram for Business Modeling by Means of Virtual Machine. 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

ewan
Download Presentation

Semantics of UML 2.0 Activity Diagram for Business Modeling by Means of Virtual Machine

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Semantics of UML 2.0 Activity Diagram for Business Modelingby Means of Virtual Machine

  2. 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 activitydiagram features, which are significant for business process modeling and definition

  3. Sample Activity Diagram

  4. Subset of the UML 2.0 AD and Limitations • Subset: • All elements from Fundamental, Basic, Intermediateand some elements fromComplete Activities: • Activities, Actions, Control and Object Flows, Activity Parameter Nodes, Pins, Control Nodes, Activity Partitions and Groups • Limitations: • outgoing edge from a ControlNode is not an incoming edge for the same ControlNode • there should be no paths between CallBehaviorActions, InitialNodes, FinalNodes or ActivityParameterNodes containing both ForkNodes and JoinNodes Forbidden Constructs:

  5. 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

  6. 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

  7. 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’sEdges "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

  8. Subset of UML AD Metamodeland mapping to the ADVM classes

  9. 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 ControlNodes 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

  10. Complete Metamodel of our AD VM (Excluding ActivityFactory class)

  11. 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

More Related