State Diagrams CSC 422 Kutztown University Dr Spiegel







![State Diagram Example: Order Object Initial State /get. First. Item [still. More] / get. State Diagram Example: Order Object Initial State /get. First. Item [still. More] / get.](https://slidetodoc.com/presentation_image_h2/452a2b49c2012c8b80c9043d9419a949/image-8.jpg)
![Example with Cancelled State Initial State /get. First. Item [still. More] / get. Next. Example with Cancelled State Initial State /get. First. Item [still. More] / get. Next.](https://slidetodoc.com/presentation_image_h2/452a2b49c2012c8b80c9043d9419a949/image-9.jpg)
![Example: Add Super State /get. First. Item [still. More] / get. Next. Item Checking Example: Add Super State /get. First. Item [still. More] / get. Next. Item Checking](https://slidetodoc.com/presentation_image_h2/452a2b49c2012c8b80c9043d9419a949/image-10.jpg)



- Slides: 13
State Diagrams CSC 422 Kutztown University Dr. Spiegel
State or Statechart Diagrams n Finite state machine for 1 class n n n States n n n show states objects in class can be in show responses to external stimuli have associated code can have internal finite state machines Transitions n show when state changes
State Diagrams n State diagrams are used to show possible states a single object can get into n n How object changes state in response to events n n shows transitions between states UML state diagrams are a variation of Statecharts n n shows states of an object Statecharts are hierarchical state machines Statecharts have formal semantics
State Diagrams: States n States are represented as rounded boxes which contain: n n the state name and the following optional fields n n 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 exit action internal transition activity entry / set. Mode(on Track) exit / set. Mode(off Track) new. Target / tracker. Acquire() do / follow. Target self. Test / deferred event Note that, “entry”, “exit”, “do”, and “defer” are keywords
State Diagrams: Transitions n n n 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 trigger-event[guard-condition]/action target state
State Diagrams shows the initial (default) state / get. First. Item get. Next. Item [not all items checked] Checking do / check. Item cancelled shows the final state
State Diagram Example: Order Object Initial State /get. First. Item [still. More] / get. Next. Item Checking [All. Items. Checked && All. Items. Available ] do: check. Item [All. Items. Check && Some. Not. Available ] Waiting Item. Received [Some. Not. Available] Dispatching do: delivery Item. Received [All. Items. Available] Delivered
Example with Cancelled State Initial State /get. First. Item [still. More] / get. Next. Item [All. Items. Checked && All. Items. Available ] Checking Dispatching do: check. Item [All. Items. Check && Some. Not. Available ] do: delivery Cancel Item. Received [All. Items. Available] Cancel Delivered Waiting Item. Received [Some. Not. Available] Delivered Cancelled
Example: Add Super State /get. First. Item [still. More] / get. Next. Item Checking Active [All. Items. Checked && All. Items. Available ] do: delivery do: check. Item [All. Items. Check && Some. Not. Available ] Item. Received [All. Items. Available] Delivered Waiting Item. Received [Some. Not. Available] Cancelled Dispatching Delivered
Concurrent State Diagrams n n n Order object of example also has states associated with the payment authorization Could Authorize between [Payment not Rejected OK] Dispatching and Authorizing Delivery. Not nice. do: check. Pmt Concurrency better [Payment OK] n system in 2 states while in concurrent mode Authorized deliver Delivered
Concurrency Example Order Object Waiting Cancelled cancel Checking Dispatching delivered Delivered Authorizing Authorized end Rejected
Concurrency Example (cont) n n n 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: check. Pmt step finishes first n n n if successful, state is Authorized and Checking else exit concurrent phase to Rejected else could be Authorizing/Waiting or Authorizing/Dispatching and so on.