CIS224 Software Projects: Software Engineering and Research Methods

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

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

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