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_at_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

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
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
Generic Object Petri Net Model

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

• Lifetime behavior model (LM)
• Event routing structure

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)

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.

14
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
Hierarchical structure of the net model

• An example of a top-level page

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

16
An example UML model Master-Servant system
17
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
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
The object page for the Servant object
23
The object page for the Master object
24
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
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 _at_(1New2) 2 A _at_(1New2)
3 A _at_(1New2) tok Start 4 A
_at_(1New4)
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.
30
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

• 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
• 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

• 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
• endif
• endif
• enddo

39
Implementation of view control
include an interface for inputting view control
info

• 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

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 customers 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!