Software Diagrams
martinpham
SE311StateDiagram.pptxUML State Diagram
UML Statechart Diagram (STD)
Shows the sequences of states that objects of a class go through during its life cycle in response to external events and also the responses and actions in reaction to an event.
Model elements
States
Transitions
Events
Actions and activities
STD Elements
A Event - is a significant or noteworthy occurrence
e.g. a phone receiver is taken off the hook
A State - is the condition of an object at a moment in time
- the time between events.
e.g. a phone is in the state of being “idle” after the receiver is placed on the hook until it is taken off the hook.
A transition - is a relationship between two states that indicates that when an event occurs, the object moves from the prior state to the subsequent state.
e.g. when the event “off hook” occurs, transition the phone from the “idle” to “active” state.
Example: STD for a Phone
Idle
Initial state
Active
off hook
on hook
transition
event
state
(c) National Centre for Software Technology
13 March, 2021
Object Oriented Analysis and Design
4
Classes that Need State Diagrams
State-dependent classes
objects react differently to events depending on their state
State-independent classes do not need State Diagrams
an object always responds the same way to an event
Event Types
External Event (also known as system event)
is caused by something outside the system boundary
e.g. when a cashier presses the “enter item” button on a POST, an external event has occurred.
Internal Event
is caused by something inside our system boundary.
In terms of SW, an internal event arises when an operation is invoked via a message sent from another internal object. (The messages in collaboration diagrams suggest internal events)
Temporal Event
is caused by the occurrence of a specific date and time or passage of time.
State
Abstraction of attribute values and links of an object
Sets of values are grouped together into a state
Corresponds to the interval between two events received by the object
events represent points in time
states represent intervals of time
Has duration
State
Often associated with a
continuous activity
value satisfying some condition
Event separates two states
State separates two events
State Diagram
Graph relating events and states
Nodes are states; arcs are events
Describes behaviour of a single class of objects
Can represent
one-shot life cycles
continuous loops
State Diagram
Continuous loop
graph is a loop
no definite start state
not concerned about how the loop starts
dial tone
idle
dialling
digit (n)
on-hook
on-hook
digit (n)
State
Transition
Event
off-hook
Example:
State Diagram
One-shot life cycle
represents objects with finite lives
initial state entered on creation of object
entering final state destroys object
initial state shown using solid circle
final state(s) shown using bull’s eye
White’s move
Black’s move
start
white
moves
black
moves
Black wins
Draw
White wins
stalemate
stalemate
Example:
Transition Actions, Guard Conditions
Transition Actions
a transition can cause an action to fire. In SW, this may represent the invocation of a method of an object
Transition Guard conditions
a transition may also have a conditional guard -- or boolean test. The transition is only taken if the test passes.
Idle
Active
off hook / play dial tone
on hook
event
[ valid subscriber ]
action
guard condition
Guard Condition
Boolean function of object values
Valid over an interval of time
Can be used as guards on transitions
Guard condition shown in brackets, following event name
login
password
[user name]
Guard condition
Operations
Attached to states or transitions
Performed in response to corresponding states or events
Types
Activity
Action
Operations
Activity
operation that takes time to complete
associated with a state
include continuous or sequential operations
notation “do: A” within a state box
indicates activity A
starts on entry
ends on exit
login
do : display login prompt
password
do: get password
Operations
Action
instantaneous operation
associated with an event
notation
slash (“/”) and name of the action, following the event
Idle
Menu
visible
right button down / display popup menu
right button up / erase popup menu
cursor moved / highlight menu item
Example
Validating
do /check
item
Dispatching
do /initiate
delivery
Completed
Pending
/ get first item
Start
[All items valid &&
all items available ]
Delivered
[All items valid &&
some items not in stock ]
Item Received
[some items not in stock ]
Get next item
[not all items validated ]
Item Received
[ all items available ]
Self-transition
State
Transition
Activity
Example
Idle
Reading product
codes
Closing transaction
start button pressed /
print receipt header
total button
pressed
complete button pressed /
print receipt footer
product code input (product code) /
print product price
Nested State Diagrams
State diagrams can get complex
For better understanding and management
A State in a state diagram can be expanded into a state diagram at another level
Inheritance of transitions
Example: Nested States
Playing Dial Tone
complete
Idle
Talking
Connecting
Dialing
connected
digit
digit
Active
off hook / play dial tone
[ valid subscriber ]
on hook
Example
prompt
reading
char (c)
char (c)
start
Enter key
password
Subject of a State Diagram
Software Classes
the STD shows the sequences of states that objects of a class go through during its life cycle in response to external events and also its responses and actions in reaction to an event.
Use cases
the STD depicts the overall system events and their sequence within a use case
Example: STD for Buy Items Use Case
Waiting for Sale
enterItem
Entering Items
Waiting for Payment
enterItem
endSale
makePayment
State Diagram
A state diagram (also called state machine diagram) depict the various states that an object may be in and the transitions between those states.
Appropriate to be developed for complex objects.
From UML Distilled (pp. 107-108):
A lock in a haunted house: keep valuables in a safe that’s hard to find
To reveal the lock to the safe, I have to remove a strategic candle from its holder, but this will reveal the lock only while the door is closed. In the Wait state, if the candle is removed providing the door is closed, you reveal the lock and move to the Lock state. Once I can see the lock, I can insert my key to open the safe. For extra safety, I make sure that I can open the safe only if I re-place the candle first. If a thief neglects this precaution, I’ll unleash a killer rabbit to him.
A state is a condition in which an object can be at some point during its lifetime, for some finite period of time. State diagrams describe all the possible states a particular object can get into and how the object’s state changes as a result of external events that reach the object.
State Diagram
From UML Distilled (pp. 107-108):
A lock in a haunted house: keep valuables in a safe that’s hard to find
To reveal the lock to the safe, I have to remove a strategic candle from its holder, but this will reveal the lock only while the door is closed. In the Wait state, if the candle is removed providing the door is closed, you reveal the lock and move to the Lock state. Once I can see the lock, I can insert my key to open the safe. For extra safety, I make sure that I can open the safe only if I re-place the candle first. If a thief neglects this precaution, I’ll unleash a killer rabbit to him.
A state is a condition in which an object can be at some point during its lifetime, for some finite period of time. State diagrams describe all the possible states a particular object can get into and how the object’s state changes as a result of external events that reach the object.
States
States are represented by the values of the attributes or data members of an object.
Initial state
state
Terminal state
transition
States are represented by the values of the attributes or data members of an object.
In a UML state machine diagram . . .
[click] An initial or start state is represented by a solid circle.
[click] A state is represented by a rounded rectangle.
[click] A final state is represented by a solid circle with another open circle around it.
[click] A transition is a change of an object from one state (the source state) to another (the target state) triggered by events, conditions, or time. Transitions are represented by an arrow connecting two states.
We’ll discuss more about the specifics of transitions on the next slide.
Transitions
Transitions are the result of the invocation of a method that causes an important change in state.
Each transition has a label that comes in three parts. All the parts are optional.
trigger-signature [guard]/activity
candle removed [door closed]/reveal lock
The trigger-signature is usually a single event that triggers a potential change of state.
Missing trigger-signature [rare] – you take the transition immediately.
The guard, if present, is a Boolean condition that must be true for the transition to be taken.
Missing guard – always take the transition.
The activity is some behavior that’s “executed” during the transition.
Missing activity – don’t do anything during the transition.
Again, a transition is a change of an object from one state (the source state) to another (the target state) triggered by events, conditions, or time.
Each transition has a label that comes in three parts. [click] All three parts of the label are optional.
The trigger-signature is usually a single event that triggers a potential change of state. A missing trigger-signature, which happens rarely, indicates that you take the transition immediately.
The guard, if present, is a Boolean condition that must be true for the transition to be taken. A guarded transition occurs only if the guard resolves to true. Only one transition can be taken out of a given state. If more than one guard condition is true, only one transition will fire. The choice of transition to fire is nondeterministic if no priority rule is given. A missing guard indicates that you always take the transition once the trigger-signature has fired.
The activity is some behavior that’s “executed” during the transition. A missing activity means that you don’t do anything during the transition.
trigger-signature: event that causes a potential change of state
guard: Boolean condition that must be true for transition to happen
activity: behavior that’s executed during the transition
Let’s review these three elements of a transition in the context of a state diagram. Here is a state diagram for a lock in a haunted house. The scenario goes:
To reveal the lock to the safe, I have to remove a strategic candle from its holder, but this will reveal the lock only while the door is closed. In the Wait state, if the candle is removed providing the door is closed, you reveal the lock and move to the Lock state. Once I can see the lock, I can insert my key to open the safe. For extra safety, I make sure that I can open the safe only if I replace the candle first. If a thief neglects this precaution, I’ll unleash a killer rabbit to him.
[click]
The trigger-signature is usually a single event that triggers a potential change of state. In this case, the state change from the lock being in the waiting state to the locked state is initiated when the candle is removed.
[click] The guard, if present, is a Boolean condition that must be true for the transition to be taken. A guarded transition occurs only if the guard resolves to true. In this case, we’re still trying to decide if the lock will go from the waiting state to the locked state if the candle is removed – it only will do so if the door is closed.
[click] The activity is some behavior that’s “executed” during the transition. In this case, the behavior is that the lock will be revealed.
Rules for State Diagrams
There is one initial state (can be multiple final states).
Every state can be reached from the initial state.
From each state, there must be a path to a final state.
Every transition between states must be labeled with an event that will cause that transition.
When an event occurs, you can take only one transition. If you have multiple transitions with the same event, the guards must be mutually exclusive.
Transitions that are not shown are illegal OR show transitions that cause errors.
There are some rules for state diagrams.
There is only one initial state.
Every state can be reached from the initial state.
From each state, there must be a path to a final state.
Every transition between states must be labeled with an event that will cause that transition.
When an event occurs, you can take only one transition. If you have multiple transitions with the same event, the guards must be mutually exclusive.
And finally . . .
Transitions that are not shown are illegal OR show transitions that cause errors.
Utility of Use Case State Diagrams
For a complex use case with many system events e.g. create entity in ERD editor a STD that shows the legal order of external events is helpful.
The Use case STDs serve as inputs to a designer to develop a design that ensures correct system event order. Possible design solutions include:
hard-coded conditional tests for out of order events
disabling widgets in active windows to disallow illegal events
a state machine interpreter that runs a state table representing the use case STD.
Class Exercises
ATM Example
Startup Use case
The system is started up when the operator turns the operator switch to the "on" position. The operator will be asked to enter the amount of money currently in the cash dispenser, and a connection to the bank will be established. Then the servicing of customers can begin.
Shutdown Use Case
The system is shut down when the operator makes sure that no customer is using the machine, and then turns the operator switch to the "off" position. The connection to the bank will be shut down. Then the operator is free to remove deposited envelopes, replenish cash and paper, etc.
Class Exercises
ATM Session User Case
A session is started when a customer inserts an ATM card into the card reader slot of the machine. The ATM pulls the card into the machine and reads it. (If the reader cannot read the card due to improper insertion or a damaged stripe, the card is ejected, an error screen is displayed, and the session is aborted.) The customer is asked to enter his/her PIN, and is then allowed to perform one or more transactions, choosing from a menu of possible types of transaction in each case. After each transaction, the customer is asked whether he/she would like to perform another. When the customer is through performing transactions, the card is ejected from the machine and the session ends. If a transaction is aborted due to too many invalid PIN entries, the session is also aborted, with the card being retained in the machine.
The customer may abort the session by pressing the Cancel key when entering a PIN or choosing a transaction type.
