1 CIS224 Software Projects: Software Engineering and Research Methods Lecture 6 State Machine and Activity Diagrams (Based on Stevens and Pooley (2006,

1

CIS224Software Projects: Software Engineering

and Research Methods

Lecture 6State Machine and Activity Diagrams

(Based on Stevens and Pooley (2006, Chapters 11 and 12)

& Fowler (2004, Chapters 10 and 11)

David [email protected]

www.titanmusic.com/teaching/cis224-2007-8.html

2

Introduction

on loan on the shelf

returned()

borrowed()Initial pseudo-state or start marker

• 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 object’s 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

on loan on the shelf

returned()/book.copyReturned(self)

borrowed()/book.copyBorrowed(self)

• An event is something done to an object, such as being sent a message

• An action is something an object does, such as it sending a message

• Action caused by an event can be recorded on transition after a forward slash

4

Entry and exit actions

on loan on the shelf

returned()/book.copyReturned(self)

borrowed()/book.copyBorrowed(self)

on loan

entry/book.copyBorrowed(self)

on the shelf

entry/book.copyReturned(self)

returned()

borrowed()

on loan

exit/book.copyReturned(self)

on the shelf

exit/book.copyBorrowed(self)

returned()

borrowed()

• 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!

5

Guards

not borrowable borrowable

copyReturned()

copyBorrowed()[last copy]

copyReturned()

copyBorrowed()[not last copy]

• 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 <= 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

Typing

entry/highlight allexit/update fieldcharacter/handle characterhelp[verbose]/open help pagehelp[quiet]/update status bar

• 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/<activity>”

– 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

Update hardwarewindow

Searching

do/ search for new hardwareDisplay new hardware

window

cancel

search

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”

Enter connection details

Show connections

Choose networkconnection type Choose ISP Enter account details

save

back

next next

back

newcancel

9

Concurrent states

On

Off

onoff

Display time Display alarm time

Play CDPlay radio

alarm

time

CD

radio

• 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

• 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

Receiveorder

Fill order Send invoice

Receivepayment

Overnightdelivery

Ordinarydelivery

Closeorder

decision

initial node or start marker

fork

action

flow or (activity) edge

join

activity final or stop marker

merge

Synchronization bar

[rushorder]

[else]

11

Partitions (“swim lanes”)

Receiveorder

Fill order Send invoice

Receivepayment

Overnightdelivery

Ordinarydelivery

Closeorder

[rushorder]

[else]

Order fulfillment department Customer services department Finance department • 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

Leave for airport

Pack bags

Taxi arrives

time signal

accept signal

Two hours before flight

• 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

– Activity’s 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 usually waits for an external event to happen before allowing the

flow to continue– 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

Receive cancel request Cancel order

Process order Request payment Receive payment Ship order

Report metre reading

At end of month

• 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

• Once payment received, “Ship order” action carried out• “Receive cancel request” accept 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

fork join

• Created by initial node/start marker or accepted signal• Consumed by an action which then passes token on

when action completed• Fork: one token in, one token out for each outgoing flow• Join: when received token from each incoming flow,

produces one token on outgoing flow

15

Flows and edges

Receiveinvoice

Makepayment

Receiveinvoice

Makepayment

Receiveinvoice

Makepayment

Order

A A

• 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!• Can pass objects along

flows

16

Decomposing actions

Regular deliveryOvernightdelivery

Order

Order

Deliver Order

[else][Rush order]

Receiveorder

Fill order Send invoice

Receivepayment

Closeorder

Deliverorder

rake symbol

Receiveorder

Fill order Send invoice

Receivepayment

Overnightdelivery

Ordinarydelivery

Closeorder

[rushorder]

[else]

Can take portion of an activity diagram, define it as a subactivity and call it as an actionSubactivity denoted by action with a “rake” symbolSubactivity has input and output parameters

17

Pins and transformations

«transformation»appointment.patient

CancelAppointment

NotifyPatient

«transformation»appointment.cancellationNotice

message patient

appointment

• Actions can have parameters• Can show parameters with pins• Pins correspond to parameter boxes in subactivity diagram• Output parameters must match input parameters

– If don’t 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

Take incourse works

Return markedcourse works

Mark course work

Enter markin database

Collection of course works

List box pin

• 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

Allocate papers to reviewers

Publish accepted papers

Deadline for submission

«concurrent»

Collection of submitted papers

Collection of accepted papers

[reject]

[accept]

Reviewpaper

• 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, <<concurrent>>

• 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

Select drink

Dispense drink

Insert coins

A

B {joinSpec = A and B and value of inserted coins >= price of selected drink}

• 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 event[guard]/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