1. Modeling State-Dependent Objects Using Colored Petri Nets
Robert G. Pettit IV
Hassan Gomaa
MOCA 01
Workshop on Modeling of Objects, Components, and Agents
George Mason University
Department of Information and Software Engineering

2. Research Goals
Goal is to provide behavioral analysis capabilities for concurrent object-oriented software architecture designs
Determine absense of deadlocks
Validation of event sequences and timing
Colored Petri nets (CPNs) used as underlying formalism to achieve the desired validation
Petri net translation must be automatable
Transparent to the object architect
Object architectures are expressed in terms of the UML
Several different types of objects must be addressed
This paper focuses specifically on state-dependent objects

3. Modeling UML Dynamic Behavior
Concurrent design developed using COMET method
Collaboration diagrams form basis for CPN translation
Use case scenarios dictate event sequences
Executed in DesignCPN simulator
Objects
Active vs. Passive
Asynchronous vs. Periodic
Communication
Synchronous vs. Queued
Translation to CPNs determined by stereotypes and tagged values
Supported stereotypes are described in the COMET method

4. State-Dependent Objects (SDOs)
Stereotyped as <<state-dependent>>
Operate as controllers within the system
Behavior depends on both the input events and the current state of the object
In COMET, each state-dependent object encapsulates a state machine
Represented as a UML statechart associated with the state-dependent object

5. Modeling SDOs with CPNs
Architecture modeled using a hierarchy of CPN subnets
Top-level CPN model represents the system context
Places represent system interfaces
Single transition represents the system being modeled
First decomposition represents the system architecture
Models system collaboration diagram
Captures objects and their connections
Each object is then represented with its own subnet
Captures the basic structure (control flow) of each concurrent object
Transitions within state-dependent objects are further decomposed to capture:
Statechart structure
Behavior of individual states

6. High-Level SDO Subnet
Discuss flow of control within the active state-dependent object
Control token
Inputs and outputs
ExecuteSTD substitution transition
Process time
Discuss how “state” is modeled using a tuple of state and conditions

7. Top-Level CPN State Chart Model
First decomposition of ExecuteSTD captures the structure of the statechart
Statechart is “flattened” to remove hierarchical state decomposition
Interim representation to facilitate systematic mapping to CPN model
CPN model contains one transition for each state
Transitions enabled via arc incriptions corresponding to the current state

8. Modeling Individual States
Each “state” transition is further decomposed to capture specific behavior
First transition in path executes code segment to determine next state and action path based
Remaining place-transition pairs are traversed based on the desired actions

9. Benefits of CPN Modeling
Simulation
Automated testing of state-dependent behavior
“What-if” analysis of input events, states, and conditions
Interactive execution to explore detailed areas of concern
Performance analysis
Timing analyzed in relation to other sytem objects
Only as good as the architect’s estimation of process time for each object
Occurrence graph
Deadlock detection
Coverage analysis

10. Example: Cruise Control
Real-time control system to manage speed of an automobile
State-dependent behavior based on:
Driver input
Current cruise control setting
Condition of engine (on or off) and brake (pressed or released)

11. Cruise Control SDO Cruise Control SDO (from collaboration diagram)
Cruise Control Statechart

12. Cruise Control SDO CPN Model
Discuss connections to overall cruise control model
Discuss elaboration of the general SDO subnet

13. Cruise Control Top-Level Statechart CPN
Relate to cruise control statechart from previous slide
Discuss how each transition is only enabled if the current state matches the state being modeled.

14. Cruise Control Idle State
Relate to both the cruise control statechart and to the previous CPN model
Discuss how the code segment works
Traverse an action branch and relate it to the cruise control statechart

15. Conclusions and Future Research
UML dynamic behavior can be represented using colored Petri nets
Statecharts may be systematically mapped to CPN representations
Petri net theory used to validate dynamic properties
Occurrence graphs detect deadlock and starvation
Simulator used to execute models and provide functional analysis
CASE tools may also provide statistical analysis
Completed research effort will provide mechanism to automate validation of dynamic behavioral properties
UML collaboration diagrams
Use case scenarios