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. 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 p1 p2 p3 p4 p5 t2 t3 t4 t1 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. 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 LM of the OVEN IP ER OP... LM of the USER IP ER OP....... LM of the Power Tube LM of the Light Tube Power Tube Light Tube..... IP ER OP IP OP ER........... ITA OTA ITA OTA ITA OTA ITA OTA Event ILP

11. 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. IP ER OP ITA OTA LM of the Object Event Router In-place Out-place Object Outgoing external events incoming........

12. 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) ITA OTA LM of the Object Event Router In-place Out-place Object Outgoing external events incoming........ ER OP IP

13. 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. LM of the OVEN IP ER OP... LM of the USER IP ER OP....... LM of the Power Tube LM of the Light Tube Power Tube Light Tube..... IP ER OP IP OP ER........... ITA OTA ITA OTA ITA OTA ITA OTA Event ILP

14. From abstract to target model: The target model structure object page nINL page main page object page 1 -- 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. LM of the OVEN IP ER OP... LM of the USER IP ER OP....... LM of the Power Tube LM of the Light Tube Power Tube Light Tube..... IP ER OP IP OP ER........... ITA OTA ITA OTA ITA OTA ITA OTA Event ILP

15. 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 S1 T1 T2 S2 substitution transition socket object page nINL page main page object page 1

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

17. From abstract to target model: The target model structure object page nINL page main page object page 1 -- 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. LM of the OVEN IP ER OP... LM of the USER IP ER OP....... LM of the Power Tube LM of the Light Tube Power Tube Light Tube..... IP ER OP IP OP ER........... ITA OTA ITA OTA ITA OTA ITA OTA Event ILP

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 socke t

20. From abstract to target model: The target model structure object page nINL page main page object page 1 -- 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. LM of the OVEN IP ER OP... LM of the USER IP ER OP....... LM of the Power Tube LM of the Light Tube Power Tube Light Tube..... IP ER OP IP OP ER........... ITA OTA ITA OTA ITA OTA ITA OTA Event ILP

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. The object page for the Servant object port Idle Active Start Statechart for Servant

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

24. From abstract to target model: The target model structure object page nINL page main page object page 1 -- 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. LM of the OVEN IP ER OP... LM of the USER IP ER OP....... LM of the Power Tube LM of the Light Tube Power Tube Light Tube..... IP ER OP IP OP ER........... ITA OTA ITA OTA ITA OTA ITA OTA Event ILP

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

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

28. Simulation traces  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) 1 A ***@(1:New#2) {} 2 A ***@(1:New#2) {} 3 A ***@(1:New#2) { tok = Start} 4 A ***@(1:New#4)

29. 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. Master: Init -> Waiting | Start Servant: Idle -> Active Start |

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

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  foreach t  CT(obj) do  if consume(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);  else if consume(t, e1)  then generate a code segment that contains the  following function call:  c1(obj, e1);  else if generate(t, receiver_obj, e2)  then generate a code segment that contains  the following function call:  c2(obj, receiver_obj, e2);  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  foreach t  CT(obj) do  if consume(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);  else if consume(t, e1)  then generate a code segment that contains the  following function call:  c1(obj, e1);  else if generate(t, receiver_obj, e2)  then generate a code segment that contains  the following function call:  c2(obj, receiver_obj, e2);  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 should be 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 !