Systems Analysis and Design I

1. Systems Analysis and Design I Session 7 Specifying Control

2. Recap • Object Interaction and Collaboration • Section 9.2 (pp. 260 – 262) • CRC Cards • Section 7.6 (pp. 215 – 218) • Communication Diagrams • Section 7.4 (pp. 194 – 197) • Section 9.4 (pp. 280 – 284) • Sequence Diagrams • Section 9.3 – 9.3.3 (pp. 262 – 276) • Model Consistency • Section 9.7 (p. 289) 2

3. Today • States and events • section 11.2, pp. 314-315 • Basic notation of state machines • Section 11.3, pp. 316-321 • Further notations • Composite states (section 11.4.1, pp.321-323) • Concurrent states (section 11.4.2, pp.323-324) • Ensure consistency with other UML models • Section 11.7, pp. 334-335

4. State • All objects have a state • An object’s state is defined as the totality of the current values of data within the object and its associations with other objects • E.g., the class StaffMemberhas an attributestartDatewhich determines whether aStaffMemberobject is in the probationary state • The current state of an object is a result of the events that have occurred to the object (think of a vending machine!) • A state describes a particular condition that an object may occupy for a period of time • while it awaits some event or trigger. • Conceptually, an object remains in a state for an interval of time. • Movement from one state to another is called a transition • Initiated by a trigger • When the triggering event occurs, a transition fires

5. Types of Event A trigger is an event that can cause a state change and is relevant to objects (or the modelled element) • A change trigger occurs when a condition becomes true. • A call trigger occurs when an object receives a call for one of its operations either from another object or from itself. • A signal trigger occurs when an object receives a signal (an asynchronous communication). • A relative-time trigger is caused by the passage of a designated period of time after a specified event (frequently the entry to the current state). No syntactic difference

6. State Machine Diagrams • UML uses state machines to model • states and state dependent • behaviours for objects and • for interactions • Previously known as statecharts • Objects = various UML elements • (systems, subsystems, interfaces, • and ports) 6

7. state machine GradeRate State GradeRate [rateStartDate <= currentDate] Initial pseudostate Pending Lapsed Active Change trigger Change trigger [rateFinishDate <= currentDate] Transition between states after [1 year] Relative time trigger Final psuedostate State machine Movement from one state to another is dependent upon events that occur with the passage of time. state machine for the class GradeRate.

8. Interaction vs state • A model of state behaviour in a state machine captures all the possible responses of a single object to all the use cases in which it is involved • A sequence/communication diagram captures the responses of all the objects that are involved in a single use case or other interaction • A state machine can be seen as a description of all the possible lifecyle that an object may follow • a more detailed view of a class

9. This trigger must correspond to an operation in the Campaign class State Name Commissioned authorised(authorisationCode) [contractSigned] /setCampaignActive Active Notation for States and Events Alternative notation for a state • For call and signal events, the format of the transition string is • trigger-signature[guard]/activity-expression • An activity-expression is executed when a trigger causes the transition to fire • Activity-expression with multiple actions • Left-mouse-down(location)[validItemSelected] / menuChoice=pickMenuItem(location); menuChoice.highlight

10. Internal activities compartment Name compartment State Name entry /activity-expression exit /activity-expression do /activity-expression Internal Activities • So far, action-expressions that are associated with a transition • It can also be useful to model internal activities associated with a state • These activities may be triggered by an event that • causes the state to be entered or results in exiting the state • State with internal activities • The internal activities compartment lists the internal activities or state activities that are executed in that state. • Each internal activity has a label stipulating under which circumstances the activity expression will be invoked • Three kinds have a special notation: entry and exit activities (no guard condition!) • State activities: with “do”, which may persist for a period of time State activities

11. Name compartment Menu Visible entry/ displayMenu do / playSoundClip exit / hideMenu Internal activities compartment itemSelected / highlightItem Internal transitions compartment ‘Menu Visible’State State with internal transitions The same as triggers, but do NOT cause a state change and do NOT invoke the entry/exit activities Menu Visible state for a DropDownMenuobject. Exiting the state triggers hideMenu() entry action causes the menu to be displayed While the object remains in the Menu Visible state, the activity causes a sound clip to be played. event itemSelected() triggers the action highlightItem()

12. /assignManager; assignStaff Authorized(authorizationCode) [contractSigned] /setCampaignActive Commissioned Completed Active campaignCompleted /prepareFinalStatement paymentReceived(payment) [paymentDue - payment > 0] paymentReceived(payment) [paymentDue - payment <= 0] Paid archiveCampaign /unassignStaff; unassignManager state machine for the class Campaign. Action-expression assigning manager and staff on object creation Recall the syntax: trigger-signature[guard]/activity-expression Guard condition ensuring complete payment before entering Paid Recursive transition models any payment event that does not reduce the amount due to zero or beyond.

13. /assignManager; assignStaff Authorized(authorizationCode) [contract signed] /setCampaignActive Commissioned Completed Active Paid campaignCompleted /prepareFinalStatement paymentReceived(payment) [paymentDue - payment < 0] /generateRefund paymentReceived(payment) [paymentDue - payment > 0] paymentReceived(payment) [paymentDue - payment = 0] archiveCampaign /unassignStaff; unassignManager A revised state machine for the classCampaign If the user requirements were to change, so that an overpayment is now to result in the automatic generation of a refund, a new transition is added.

14. Further notations • Composite states • Concurrent states • Entry and exit pseudostates • Junction and choice psedudostates • History pseudostates

15. Active extendCampaign /modify Budget advertsApproved /authorise confirmSchedule Advert Preparation Running Adverts Scheduling campaignCompleted /prepareFinalStatement Decomposition compartment Composite (Nested) States The transition from the initial pseudostate symbol should not be labelled with an event but may be labelled with an action, though it is not required in this example The Active state of Campaign showing nested substates. Idea: represent at different levels of detail to reflect a hierarchy of states Substates

16. Active : Running Composite (Nested) States If the details of the submachine is not required on the higher-level state machine or is just too much to show on one diagram, the higher-level state machine can be annotated with the hidden decomposition indicator icon The submachine Running is referenced using the include statement. The Active state of Campaign with the detail hidden. Hidden decomposition indicator icon (two small state symbols linked together)

17. Concurrent States • Objects can have concurrent states • regarded as a product of two (or more) distinct sets of substates • Each of which can be entered and exited independently of substates in the other set • A transition to a complex state is equivalent to a simultaneous transition to the initial states of each concurrent state machine. • An initial state must be specified in both nested state machines • in order to avoid ambiguity about which substate should first be entered in each concurrent region • Once the composite state is entered, a transition may occur within either concurrent region without having any effect on the state in the other concurrent region. • A transition out of the Active state applies to all its substates (no matter how deeply nested).

18. Active Running advertsApproved /authorize extendCampaign /modify Budget confirmSchedule campaignCompleted /prepareFinalStatement Advert Preparation Running Adverts Scheduling Evaluation Survey Monitoring surveyComplete runSurvey The Active state with concurrent substates Two submachines

19. Transition fired by completion event State 1 State 2 someTrigger Transition caused by the event someTrigger Completion Event State 1 will exit when its submachine is completed, generating a completion event. State 1 will exit when the trigger someTrigger occurs irrespective of which substate the submachine occupies.

20. Fork Join SynchronisedConcurrentThreads Shows that the composite state is NOT exited until both concurrent nested state machines are exited. Explicitly showing how an event triggering a transition to a state with nested concurrent states causes specific concurrent substates to be entered. fork pseudostate and join pseudostate

21. sm Advert StoryBoard Entry pseudostate Exit pseudostate smAdvertPrepSM Advert Reworked Advert Reworked AdvertPrep: AdvertPrepSM abort Advert Aborted abort Advert Aborted AdvertRunning Entry & Exit Pseudostates It is useful to model exceptional entry to and exit from a submachine state. This is achieve using an entry pseudostateand an exit pseudostate

22. StateC StateD StateA StateB Junction & Choice Pseudostates Choice pseudostate Junction pseudostate x [condition2] [condition1] [>15] [<15] [=15] UML offers notation to show decision points. Each exit transition has a guard condition and if they all share a common argument A junction pseudostate has one or more entry transitions and will have one or more exit transitions (merge and static conditional branching)

23. Differences of Junction and Choice When Event1 occurs, guard conditions are evaluated prior to invoke the action corresponding to Event1. When Event1 occurs, guard conditions are evaluated after invoke the action corresponding to Event1. Junction Choice

24. Consistency Checking • Consistency checks are an important task in the preparation of a complete set of models. • Highlight omissions and errors, and encourages the clarification of any ambiguity or incompleteness in the requirements. • Every event: appear as an incoming message for the appropriate object on an interaction diagram(s). • Every action: correspond to the execution of an operation on the appropriate class, and perhaps also to the dispatch of a message to another object. • Every event: correspond to an operation on the appropriate class (but note that not all operations correspond to events). • Every outgoing message sent from a state machine must correspond to an operation on another class.

25. Take Home Messages • States and events • Basic notation of state machines • Further notations • Ensure consistency with other UML models 34