Lecture 6 State Machine and Activity Diagrams Based

Lecture 6 State Machine and Activity Diagrams (Based on Stevens and Pooley (2006, Chapters 11 and 12) & Fowler (2004, Chapters 10 and 11) David Meredith d. meredith@gold. ac. uk www. titanmusic. com/teaching/cis 224 -2007 -8. html CIS 224 Software Projects: Software Engineering and Research Methods 1

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, on. Shelf, which records whether or not a copy of a book is in the library or on loan – Initially, on. Shelf == true to indicate that the copy is in the library – When Copy object receives borrowed() message and on. Shelf is true, it changes the value of on. Shelf 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 on. Shelf back to true – Copy object should never receive returned() message when on. Shelf 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” 2

Actions and events • 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 3

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

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 <= 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 5 allows for an unambiguous condition to be specified

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 6

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 7

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” 8

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

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” – • Fork splits one thread into two or more concurrent threads – • • 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 – • start two or more tasks in parallel Join merges two or more threads into one – • they are independent 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 10

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 11

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 – 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 12

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 • 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 13 – Enabled from start of containing activity (no input flows)

Tokens • 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 14

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

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 16

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 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 17 action (which are implicitly joined)

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 18

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, <<concurrent>> • If paper rejected, ends flow; otherwise, token added to output collection • Output collection passed to “Publish accepted papers” 19 • Expansion region acts as a filter

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 20

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 21