State Machine and Activity Diagrams

1

• State Machine and Activity Diagrams
• (Based on Stevens and Pooley (2006, Chapters 11
  and 12) Fowler (2004, Chapters 10 and 11)

David Meredith Aalborg University
2
Introduction

• Way in which an object responds to a message
  depends on its state
• The state of an object is determined by the
  values in its attributes
• A UML state machine diagram shows how the
  messages that an object receives change its state
• Example
• Class Copy has boolean attribute, onShelf, which
  records whether or not a copy of a book is in the
  library or on loan
• Initially, onShelf true to indicate that the
  copy is in the library
• When Copy object receives borrowed() message and
  onShelf is true, it changes the value of onShelf
  to false to indicate that it is now on loan
• When the copy of the book is returned, a
  returned() message is sent to the Copy object and
  it changes the value of onShelf back to true
• Copy object should never receive returned()
  message when onShelf is true
• If it does, it should probably signal an error
• Copy object has two states on loan and on the
  shelf
• Denoted by boxes with rounded corners
• Change of state (e.g., from on loan to on the
  shelf) is called a transition
• Indicated by arrows between states with solid
  lines and stick heads
• Messages that affect Copy objects state are
  events
• Label transitions with events that cause them
• Initial state indicated by start marker (black
  blob with arrow to initial state)
• Copy object starts off in the state on the shelf

3
Actions and events

• An event is something done to an object, such as
  being sent a message
• E.g., copy.returned() in diagram above
• An action is something an object does, such as it
  sending a message
• E.g., book.copyReturned(self) in diagram above
• Action caused by an event can be recorded on
  transition after a forward slash

4
Entry and exit actions

• May be many different events causing a transition
  to a particular state
• Each of these events might cause the same action
• Recording event/action on every transition
  leading to a state would violate write once
  rule
• Can record action once as being caused by the
  special entry event
• Can also use special exit event
• All diagrams on the left mean the same thing!
• Almost consider start marker!

5
Guards

• It may be the case that an event only causes a
  transition if certain conditions are satisfied
• Conditions can be specified in a guard (e.g.,
  last copy, not last copy, x lt 3, etc.)
• Guard expression can be any expression that has a
  boolean value (i.e., true or false)
• In a guard, can use normal language, object
  constraint language (OCL), programming language
  anything that allows for an unambiguous condition
  to be specified

6
Internal activities

• Entry and exit events trigger internal activities
• Can also define your own internal activities
• Unlike self-transitions, internal activities do
  not trigger entry and exit special events

7
Activity states

• When object in a particular state, not always
  idly waiting for the next event
• Could be engaged in carrying out some activity
• Such a state is called an activity state
• Searching state is an activity state
• Ongoing activity indicated by do/ltactivitygt
• Called a do-activity
• Once do-activity completed, transition without a
  label is taken
• If cancel event occurs during do/search for
  new hardware then do-activity is aborted
  immediately
• Do-activities can be interrupted but regular
  activities (actions) cannot

8
Superstates

• Sometimes, several states share common
  transitions
• Can move shared behaviour into a superstate
• Without superstate here, would have to have a
  cancel transition on each state within Enter
  connection details

9
Concurrent states

• Composite state can be decomposed into two or
  more orthogonal, concurrent state machine
  diagrams
• Concurrent state machines separated by dashed
  line indicating concurrent boundary
• The choices CD/Radio and Time/Alarm time are
  orthogonal (independent)
• History pseudostate indicates that CD/Radio state
  machine goes back to state clock was in when
  switched off
• History pseudostate points to state that is
  active when no history

10
Activity diagrams

• Describe procedural logic, business processes and
  work flow
• Similar to flow charts but can be used to show
  parallel behaviour
• Shows sequence of actions carried out in order to
  achieve some goal
• Fork has one incoming flow and several outgoing,
  concurrent flows
• Send invoice must come before Receive payment
• Send invoice can happen before or after Fill
  order
• they are independent
• Fork splits one thread into two or more
  concurrent threads
• start two or more tasks in parallel
• Join merges two or more threads into one
• outgoing flow only taken when all incoming flows
  reach the join
• Close order when received payment and delivered
• Whole diagram shows an activity which consists of
  a sequence of actions
• Conditional behaviour expressed with decisions
  and merges
• Decision has one incoming flow and two or more
  guarded outgoing flows
• Conditions on outgoing flows must be mutually
  exclusive
• Merge has two or more incoming flows and one
  outgoing flow
• Marks end of conditional behaviour started by
  decision

11
Partitions (swim lanes)

• Can use partitions or swim lanes to record the
  actions within the activity that are carried out
  by each
• Class
• Company department
• Actor
• User
• Can also partition actions according to which use
  cases they belong to

12
Signals in an activity diagram

• Typically, activity starts with invocation of a
  program or an operation or a business process
• Actions can also be triggered by signals from
  external processes
• Activity constantly listens for signals
• Activitys response defined by diagram
• A time signal occurs at a particular instant in
  time (e.g., end of a month, start of a day, every
  microsecond)
• In diagram above, time signal sent two hours
  before flight which triggers the action Pack
  bags
• An accept signal listens for an external event to
  happen before allowing the flow to continue
  (generating a token)
• In diagram above, accept signal waits for taxi to
  arrive before allowing flow to continue
• Join indicates that can only leave for airport
  when bags are packed and the taxi has arrived

13
Signals in an activity diagram

• Send signal sent to some external system
• Request payment signal sent to purchaser
• Receive payment accept signal only starts
  listening after Request payment signal has been
  sent
• And only allows flow to continue when payment has
  been received
• Once payment received, Ship order action
  carried out
• Receive cancel request action accepts signal
  enabled on entry to the containing activity (has
  no input flows)
• At end of month accept time signal generates a
  token which triggers Report metre reading
  action
• Enabled from start of containing activity (no
  input flows)

14
Tokens

• Created by initial node/start marker or accepted
  signal
• Consumed by an action which then generates a
  token on its output flow when action completed
• Fork one token in, one token out for each
  outgoing flow
• Join when received token from each incoming
  flow, generates one token on outgoing flow

15
Flows and edges

• Flow or edge is arrow connecting actions in
  activity diagram
• Simplest flow simply carries token
• Can name flow if desired (but usually not
  necessary)
• If awkward to connect two actions, can use
  connectors
• Avoid connectors if possible means youve got
  to search for the other end!
• Can pass objects along flows

16
Decomposing actions
- Can take portion of an activity diagram, define
it as a subactivity and call it as an action -
Subactivity denoted by action with a rake
symbol - Subactivity has input and output
parameters
17
Pins and transformations

• Actions can have parameters
• Can show parameters with pins
• Pins correspond to parameter boxes in subactivity
  diagram
• Output parameters must match input parameters
• If dont match, can indicate transformation to
  get from one to the other
• Transformation must be query on output pin
  parameter that generates object of right type
  (class) for input pin
• Pins are optional use to show data used and
  produced by actions
• If using pins, then can have multiple in-coming
  flows to an action (which are implicitly joined)

18
Expansion regions

• Use expansion regions when output of action
  triggers same sequence of actions to be performed
  on two or more objects
• Take in course works action generates a
  collection of course works, represented by the
  list box pin
• Each course work in collection is a token for
  input to the Mark course work action
• When course work marked and mark entered in
  database, token passed to output collection
• When all tokens in output collection, single
  token generated and passed to Return marked
  course works action

19
Flow finals

• When have multiple tokens, flow can stop without
  activity stopping
• Flow final indicates termination of flow, not
  activity
• Time signal Deadline for submission triggers
  allocation of submitted papers to reviewers
• Each paper is reviewed by a reviewer and either
  accepted or rejected
• Reviewing done in parallel indicated by
  keyword, ltltconcurrentgtgt
• If paper rejected, ends flow otherwise, token
  added to output collection
• Output collection passed to Publish accepted
  papers
• Expansion region acts as a filter

20
Join specifications

• Join emits token on output flow when token
  arrived on each input flow
• Sometimes want join to emit token when special
  conditions apply
• Can do this with a join specification
• Boolean expression must be true in order for
  token to be emitted on output flow

21
Summary

• State machine diagram shows how state of an
  object changes in response to events
• Transition can be given label with format
  eventguard/action
• Entry and exit events
• Internal activities
• Activity states
• Superstates
• Concurrent states
• Activity diagrams describe procedural logic,
  business processes and work flow
• Forks and joins
• Decisions and merges
• Partitions and swim lanes
• Signals in activity diagrams
• Tokens
• Flows or edges
• Decomposing actions
• Pins and transformations
• Expansion regions
• Flow finals
• Join specifications