Mapping UML Diagrams to a Petri Net Notation for System Simulation

1. Mapping UML Diagrams to a Petri Net Notation for System Simulation Zhaoxia Hu (zhu@cs.uic.edu) Supervised by Dr. Sol M. Shatz Concurrent Software Systems Laboratory Department of Computer Science University of Illinois at Chicago June 22, 2004

2. Outline • Motivation • Contribution • Model construction • Model analysis based on simulation • Related work • Future directions

3. Motivation • Integrating formal methods (Petri nets) with object-oriented design concepts (UML) to benefit from the strengths of both approaches • Providing software designers with the tools to achieve model analysis for concurrent systems in the early stage (the design stage) of the software development life cycle. • Leveraging upon existing techniques and tools (Rational Rose Tool, Design/CPN Tool).

4. The cpnUML approach: Overview • Original model: UML statecharts and collaboration diagrams • Target model: colored Petri nets • Objective • Model analysis based on simulation • An incremental approach • Basic Statecharts • Statecharts containing composite states

5. Statechart diagrams and collaboration diagrams • A statechart specifies the set of states an object goes through during its lifetime in response to events, together with its responses to those events. -- an object-based variant of classical (Harel) statecharts • A collaboration diagram is an interaction diagram that emphasizes the structural organization of the objects that send and receive messages.

6. t2 p2 p4 t3 p1 t4 p5 p3 Petri Nets • Petri nets • A formal language that allows the modeling of concurrency • Colored Petri nets • Tokens are differentiated by colors, i.e., data types t1 red blue red

7. The Design/CPN tool • Supports • Construction and editing of large, hierarchical colored Petri nets. • Simulation (automatic and interactive) • Performance analysis based on simulation • Verification by means of state spaces • History • Originally developed by Meta Software, Cambridge MA, USA – in close cooperation with the CPN group at University of Aarhus Denmark • First vision was finished in 1989. • More than 40 man-years have been used for the design and implementation. • From 1996 the distribution, maintenance and further development is done by the CPN group at the University of Aarhus, Denmark. • After less than two months version 3.0 is used by 100 organizations from 30 countries all over the world.

8. Contributions • Construction of the target colored Petri net model • Methodologies for using the target model to achieve model analysis based on simulation

9. From UML to CPN • Two steps • A UML model  an abstract colored Petri net model • Delays binding our transformation approach to a specific CPN notation so that our transformation approach can be implemented by any standard CPN analyzer to support analysis of the resulting CPN. • Separation of concerns • An abstract colored Petri net model  a target net model supported by Design/CPN

10. OVEN Power Tube Event IP IP ITA ..... ... ITA LM of the LM <{V1,V3,V4}> ... <{P2,P1}> ER ..... Power of the ER Tube OVEN ILP OP OP OTA OTA <{L2,L1}> Light Tube <{}> USER IP ..... IP ITA ITA .... LM of LM the ...... of the ER Light ER ... USER Tube OP OTA OP OTA The abstract net model • An abstract system-level model consists of Object Net Models (ONMs) and an Internal Linking Place (ILP) place • An ONM describes the behavior of an individual object (from statechart) • The ILP place defines the communication between the objects (from collaboration diagram) • Routing tokens • Replicate tokens

11. Object IP <type,ex> ITA incoming external events ... In-place Event Router LM <type,in> ER of ..... the Object <type,ex> Out-place <type,ex> OP OTA <type,ex> Outgoing external events Generic Object Petri Net Model • Lifetime behavior model (LM) • Event routing structure • The semantics of UML statecharts (a hypothetical machine) • An event queue – holds incoming event instances until they are dispatched. • An event dispatcher – selects one event at a time from the queue. • Nondeterministic choice • An event processor – processes the dispatched events.

12. Object IP <type,ex> ITA incoming external events ... In-place Event Router LM <type,in> of ..... the ER Object <type,ex> Out-place <type,ex> OTA OP <type,ex> Outgoing external events From Statecharts to Abstract Colored Petri Nets • Basic transformation • States – places • UML Transitions – Petri net transitions • Events – event tokens (to be consumed, stored in input place) • Actions – event tokens (to be generated, stored in event router place)

13. OVEN Power Tube Event IP IP ITA ..... ... ITA LM of the LM <{V1,V3,V4}> ... <{P2,P1}> ER ..... Power of the ER Tube OVEN ILP OP OP OTA OTA <{L2,L1}> Light Tube <{}> USER IP ..... IP ITA ITA .... LM of LM the ...... of the ER Light ER ... USER Tube OP OTA OP OTA From abstract to target model: The target model structure Design/CPN -- CPN Hierarchy: A colored Petri net typically consists of several pages. -- Each page contains a small net structure. -- These pages constitute the hierarchical structure of the net model.

14. main page OVEN Power Tube Event IP IP ITA ..... ... ITA LM object page 1 of INL page object page n the LM <{V1,V3,V4}> ... <{P2,P1}> ER ..... Power of the ER Tube OVEN ILP OP OP OTA OTA <{L2,L1}> Light Tube <{}> USER IP ..... IP ITA ITA .... LM of LM the ...... of the ER Light ER ... USER Tube OP OTA OP OTA From abstract to target model: The target model structure -- The net structure of the target model consists of a two-level tree structure -- The main page describes the high level view of the system. -- INL page and object pages describes the details of the net model for the system.

15. main page object page 1 INL page object page n substitution transition socket socket T1 substitution transition S2 S1 T2 Hierarchical structure of the net model -- Substitution transition: Allows a net transition in the top-level page to represent the entire net structure of a bottom-level page (subpage). -- Sockets and ports: -- colored Petre net places that exist in different locations in a net to act functionally as if they were the same place. -- Allows bottom-level pages to connect to the top-level page. • An example of a top-level page

16. Start /Start Init Waiting Idle Active (a) Statechart for Master (b) Statechart for Servant 1:Start Servant Master (c) Collaboration Diagram An example UML model: Master-Servant system

17. main page OVEN Power Tube Event IP IP ITA ..... ... ITA LM object page 1 of INL page object page n the LM <{V1,V3,V4}> ... <{P2,P1}> ER ..... Power of the ER Tube OVEN ILP OP OP OTA OTA <{L2,L1}> Light Tube <{}> USER IP ..... IP ITA ITA .... LM of LM the ...... of the ER Light ER ... USER Tube OP OTA OP OTA From abstract to target model: The target model structure -- The net structure of the target model consists of a two-level tree structure -- The main page describes the high level view of the system. -- INL page and object pages describes the details of the net model for the system.

18. What is a main page? • Depicts a high-level view of the model structure with the help of substitution transitions. • Consists of • A substitution transition, which represents the INL sub page, which models the communication among the objects • A substitution transition for each object, which represents the object page • An input place (IP) and output place (OP) for each object. These places are the sockets. • Arcs with inscriptions

19. The Main Page for the Master-Servant example -- Subsitution transitions for INL page, and object pages; Places IP and OP; and Arcs socket socket socket socket

20. main page OVEN Power Tube Event IP IP ITA ..... ... ITA LM object page 1 of INL page object page n the LM <{V1,V3,V4}> ... <{P2,P1}> ER ..... Power of the ER Tube OVEN ILP OP OP OTA OTA <{L2,L1}> Light Tube <{}> USER IP ..... IP ITA ITA .... LM of LM the ...... of the ER Light ER ... USER Tube OP OTA OP OTA From abstract to target model: The target model structure -- The net structure of the target model consists of a two-level tree structure -- The main page describes the high level view of the system. -- INL page and object pages describes the details of the net model for the system.

21. What is an object page? • Describes the behavior of an object. • Captures the token routing that characterize any ONM. • Types of Tokens • Active • Used to specified the state which the object is currently in • An instance of Active tokens is denoted as A. • Local Event Token • External and Internal • An instance of Local event tokens is denoted as (External, event_name) or (Internal, event_name).

22. Start Idle Active port port Statechart for Servant The object page for the Servant object

23. Init Waiting port port /Start Statechart for Master The object page for the Master object

24. main page OVEN Power Tube Event IP IP ITA ..... ... ITA LM object page 1 of INL page object page n the LM <{V1,V3,V4}> ... <{P2,P1}> ER ..... Power of the ER Tube OVEN ILP OP OP OTA OTA <{L2,L1}> Light Tube <{}> USER IP ..... IP ITA ITA .... LM of LM the ...... of the ER Light ER ... USER Tube OP OTA OP OTA From abstract to target model: The target model structure -- The net structure of the target model consists of a two-level tree structure -- The main page describes the high level view of the system. -- INL page and object pages describes the details of the net model for the system.

25. What is an INL page? • Models the communication among the objects • Has two functions: • Routing tokens to their destination objects • Replicating tokens when it is necessary for a message to be available to multiple objects • Is derived from the abstract ILP place of the abstract system model • Has global event tokens • An instance of global event tokens is denoted as (object_id, event_name).

26. The INL page for the Master-Servant example port port port port

27. Contributions • Construction of the target colored Petri net model • Methodologies for using the target model to achieve model analysis based on simulation

28. Enable users who are not familiar with Petri net notation to reason about model behaviors. Map simulation results back to UML notation. Design/CPN supports Interactive simulation Automatic simulation Simulation results -- simulation reports (The default simulation report is not useful) Simulation traces 1 A ***@(1:New#2) {} 2 A ***@(1:New#2) {} 3 A ***@(1:New#2) { tok = Start} 4 A ***@(1:New#4)

29. Master: Init -> Waiting | Start Servant: Idle -> Active Start | Simulation trace • Net transitions that are associated with UML transitions are critical for generating simulation traces and MSCs. • Such transitions are called critical transitions. • Simulation trace • A sequence of UML transitions. • For each critical transition, information is recorded in terms of UML terms, such as source state, target state, triggering event, newly generated event(s). -- A code segment is defined for each critical transition. -- A code segment is a sequential piece of Meta Language code. -- A code segment is executed each time the associated net transition fires. -- Simulation traces are generated by executing code segments.

30. /Start Init Waiting The object page for the Master object A code segment is defined for T3, which is a critical transition Statechart for Master

31. Simulation visualization • During simulation, view message passing between objects via Message Sequence Charts (MSCs).

32. Simulation visualization • Net transitions that are associated with UML transitions are critical for generating MSCs. • Such transitions are called critical transitions. • We define a code segment for each critical transition to generate MSCs • Design/CPN provides an ML library for generating the components of MSCs. • A code segment is executed each time the associated net transition fires. A horizontal arrow – a new event is generated and is sent from one object to another A solid rectangle – an event is received, dispatched, and triggers a transition

33. Algorithm for generating MSCs • foreachtCT(obj)do • ifconsume(t, e1) and generate(t, receiver_obj, e2)then generate a code segment that contains the • following two function calls: • c1(obj, e1); • c2(obj, receiver_obj, e2); • elseifconsume(t, e1) • then generate a code segment that contains the • following function call: • c1(obj, e1); • elseifgenerate(t, receiver_obj, e2) • then generate a code segment that contains • the following function call: • c2(obj, receiver_obj, e2); • endif • endif • endif • enddo

34. View control • What is the idea of view control? • As a means to control the complexity of systems analysis, enable designers to view systems at different levels of abstraction.

35. View control • Motivation • Enable designers to be able to reason about the behavior of a subset of the objects or the occurrences of some particular events • Methodology • Define filters to tailor the views for the system behavior • Object filter • Event filter

36. An example of view control – using an event filter Events ButtonPushed, Energize, and Deenergize are selected

37. An example of view control – using object filter

38. Implementation of view control • foreachtCT(obj)do • ifconsume(t, e1) and generate(t, receiver_obj, e2)then generate a code segment that contains the • following two function calls: • c1(obj, e1); • c2(obj, receiver_obj, e2); • elseifconsume(t, e1) • then generate a code segment that contains the • following function call: • c1(obj, e1); • elseifgenerate(t, receiver_obj, e2) • then generate a code segment that contains • the following function call: • c2(obj, receiver_obj, e2); • endif • endif • endif • enddo

39. Implementation of view control • Code segments supports recording information in the MSC  • regenerating the target model when changing the view • To avoid model regeneration, flags are defined for each object and event to introduce control in the code segments and parameterize the target model • A communication mechanism between the conversion tool and the Design/CPN tool – COMMS/CPN library based on TCP/IP include an interface for inputting view control info

40. An example • A prepaid gas station system • Suppose that we want to check the following property: Once the customer cancels the request for purchasing gasoline, the customer’s prepaid amount shouldbe returned. Events of interest: Cancel and GetChange

41. An example Events Cancel and GetChange are selected

42. Tool support • Automated target model generation • XMI file parser  self-defined model file • Generate an abstract net model • Generate the target model • Output the target model to an XML file • An interface for view control

43. Related work • vUML (Lilius and Paltor 1999) • The PROMELA language, SPIN model checker • Jack (Gnesi, Latella, and Massink, 1999) • various formal methods techniques that includes a model checker based on branching time temporal logic • Converting UML state machines into Hierarchical Predicate Transition Net, a type of colored Petri net (Dong, Fu, and He, 2003) • Statechart Simulator for Modeling Architectural Dynamics (Egyed and Wile, 2001)

44. Future work • Extend our methodology so that it handles more sophisticated features of UML statecharts, such as composite states. • Investigate enhanced model analysis capabilities. • Investigate the integration of other UML diagrams, such as use case diagrams and sequence diagrams, in our approach to strengthen the behavioral modeling and analysis. • Evaluate effectiveness using case studies.

45. Comments and Questions? Thanks!