StateDiagrams (Unified modeling Languages)

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 / setMode(on Track)
exit / setMode(off Track)
newTarget / tracker.Acquire()
do / followTarget
selfTest / defer
entry action
exit action
internal transition
activity
deferred event
Note that, “entry”, “exit”, “do”, and “defer” are keywords

State Diagrams: Transitions
 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
trigger-event[guard-condition]/action
source state target state

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

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

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

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

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
Authorized
[Payment OK]
Authorizing
do: checkPmt
Rejected
[Payment not
OK]
Delivered
deliver

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

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.

StateDiagrams (Unified modeling Languages)

More Related Content

Similar to StateDiagrams (Unified modeling Languages) (20)

Recently uploaded (20)

StateDiagrams (Unified modeling Languages)