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

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

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

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

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

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

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

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

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

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)

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

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

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.

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

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