CSC 422 Kutztown University Dr. Spiegel State Diagrams CSC 422 Kutztown University Dr. Spiegel

State or Statechart Diagrams Finite state machine for 1 class show states objects in class can be in show responses to external stimuli States have associated code can have internal finite state machines Transitions show when state changes

State Diagrams State diagrams are used to show possible states a single object can get into shows states of an object How object changes state in response to events shows transitions between states UML state diagrams are a variation of Statecharts Statecharts are hierarchical state machines Statecharts have formal semantics

State Diagrams: States States are represented as rounded boxes which contain: the state name and the following optional fields entry and exit actions: entry and exit actions are executed whenever the state is entered or exited, respectively internal transitions: internal transitions do not activate the entry and exit actions (different than self-transitions which activate the entry and exit actions). activities: Typically, once the system enters a state it sits idle until an event triggers a transition. Activities help you to model situations where while in a state, the object does some work that will continue until it is interrupted by an event deferred events: If an event does not trigger a transition in a state, it is lost. In situations where you want to save an event until it triggers a transition, use deferred events

State Diagrams: States Tracking entry action entry / setMode(on Track) exit / setMode(off Track) newTarget / tracker.Acquire() do / followTarget selfTest / defer exit action internal transition activity deferred event Note that, “entry”, “exit”, “do”, and “defer” are keywords

State Diagrams: Transitions source state and target state: shown by the arrow representing the transition trigger event: the event that makes the transition fire guard condition: a boolean expression that is evaluated when the trigger event occurs, the transition can fire only if the guard condition evaluates to true action: an executable atomic computation that can directly act on the object that owns the state machine or indirectly on other objects that are visible to the object initial and final states: shown as filled circle and a filled circle surrounded by an unfilled circle, respectively source state target state trigger-event[guard-condition]/action

State Diagrams shows the initial (default) state / getFirstItem getNextItem [not all items checked] Checking do / checkItem cancelled shows the final state

State Diagram Example: Order Object Initial State /getFirstItem [stillMore] / getNextItem [AllItemsChecked && AllItemsAvailable ] Checking do: checkItem Dispatching do: delivery Waiting [AllItemsCheck && SomeNotAvailable ] Delivered ItemReceived [AllItemsAvailable] Delivered ItemReceived [SomeNotAvailable]

Example with Cancelled State Initial State /getFirstItem [stillMore] / getNextItem [AllItemsChecked && AllItemsAvailable ] Checking do: checkItem Dispatching do: delivery Waiting ItemReceived [AllItemsAvailable] [AllItemsCheck && SomeNotAvailable ] Delivered Cancel Cancel Delivered ItemReceived [SomeNotAvailable] Cancel Cancelled

Example: Add Super State /getFirstItem Active [stillMore] / getNextItem [AllItemsChecked && AllItemsAvailable ] Dispatching do: delivery Checking do: checkItem [AllItemsCheck && SomeNotAvailable ] ItemReceived [AllItemsAvailable] Waiting Delivered ItemReceived [SomeNotAvailable] Cancel Delivered Cancelled

Concurrent State Diagrams Order object of example also has states associated with the payment authorization Could Authorize between Dispatching and Delivery. Not nice. Concurrency better system in 2 states while in concurrent mode [Payment not OK] Rejected Authorizing do: checkPmt [Payment OK] Authorized deliver Delivered

Concurrency Example Order Object Waiting Cancelled cancel Checking Dispatching delivered Delivered Authorizing Authorized end Rejected

Concurrency Example (cont) Inside the concurrency block the Order object is in 2 states; when it leaves it is only in one Order object starts out in both the Checking and Authorizing states If the Authorizing:checkPmt step finishes first if successful, state is Authorized and Checking else exit concurrent phase to Rejected else could be Authorizing/Waiting or Authorizing/Dispatching and so on.