Specifying Control Based on Chapter 11 of Bennett
Specifying Control Based on Chapter 11 of Bennett, Mc. Robb and Farmer: Object Oriented Systems Analysis and Design Using UML, (2 nd Edition), Mc. Graw Hill, 2002. 03/12/2001 © Bennett, Mc. Robb and Farmer 2002 1
In This Lecture You Will Learn: n n n How to identify requirements for control in an application How to model object life cycles using statecharts How to develop statechart diagrams from interaction diagrams How to model concurrent behaviour in an object How to ensure consistency with other UML models © Bennett, Mc. Robb and Farmer 2002 2
State The current state of an object is determined by the current value of the object’s attributes and the links that it has with other objects n For example the class Staff. Member has an attribute start. Date which determines whether a Staff. Member object is in the probationary state n © Bennett, Mc. Robb and Farmer 2002 3
State n ‘A state is a condition during the life of an object or an interaction during which it satisfies some condition, performs some action or waits for some event. . Conceptually, an object remains in a state for an interval of time. However, the semantics allow for modelling "flow-through" states which are instantaneous as well as transitions that are not instantaneous. ’ (OMG, 2001) © Bennett, Mc. Robb and Farmer 2002 4
Statechart n The current state of a Grade. Rate object can be determined by the two attributes rate. Start. Date and rate. Finish. Date n An enumerated state variable may be used to hold the object state, possible values would be Pending, Active or Lapsed © Bennett, Mc. Robb and Farmer 2002 5
Grade. Rate() Initial state when [rate. Start. Date <= current. Date] Change event Active Transition between states Statechart Pending when [rate. Finish. Date <= current. Date] Lapsed after [1 year] Final state Elapsed-time event © Bennett, Mc. Robb and Farmer 2002 Statechart for the class Grade. Rate. Movement from one state to another is dependent upon events that occur with the passage of time. 6
Types of Event n n A change event occurs when a condition becomes true A call event occurs when an object receives a call to one of its operations either from another object or from itself A signal event occurs when an object receives a signal (an asynchronous communication) An elapsed-time event is caused by the passage of a designated period of time after a specified event (frequently the entry to the current state) © Bennett, Mc. Robb and Farmer 2002 7
Events Commissioned This event must correspond to an operation in the Campaign class authorized(authorization. Code) [contract Signed] /set. Campaign. Active( ) Active © Bennett, Mc. Robb and Farmer 2002 8
Actions and Activities Internal actions and activities for a state Internal transition compartmen t Name compartment State Name entry / action expression exit/ action expression do / activity include / submachine © Bennett, Mc. Robb and Farmer 2002 A state may include a substatechart 9
Menu Visible State Menu Visible state for a Drop. Down. Menu object Event item. Selected() triggers the action highlight. Item() Entry action causes the menu to be displayed Exiting the state triggers hide. Menu() While the object remains in the Menu Visible state, the activity causes a sound clip to be played © Bennett, Mc. Robb and Farmer 2002 10
Action-expression assigning manager and staff on object creation Statechart for the class Campaign /assign. Manager(); assign. Staff() Commissioned authorized(authorization. Code) [contract signed] /set. Campaign. Active() Active campaign. Completed() /prepare. Final. Statement() 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 Completed payment. Received(payment) [payment. Due – payment <= zero] [payment. Due - payment > zero] Paid archive. Campaign() /unassign. Staff(); unassign. Manager() © Bennett, Mc. Robb and Farmer 2002 11
/assign. Manager(); assign. Staff() Commissioned authorized(authorization. Code) [contract signed] /set. Campaign. Active() A revised statechart for the class Campaign 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 Active campaign. Completed() /prepare. Final. Statement() payment. Received(payment) [payment. Due - payment < zero] /generate. Refund() Completed payment. Received(payment) [payment. Due - payment = zero] payment. Received(payment) [payment. Due – payment > zero] Paid archive. Campaign() /unassign. Staff(); unassign. Manager() © Bennett, Mc. Robb and Farmer 2002 12
Nested Substates 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 Active extend. Campaign() /modify Budget() Running Adverts Advert Preparation confirm. Schedule() adverts. Approved() /authorize() Scheduling campaign. Completed() /prepare. Final. Statement() © Bennett, Mc. Robb and Farmer 2002 13
Nested States The Active state of Campaign with the detail hidden The submachine Running is referenced using the include statement Active include / Running Hidden decomposition indicator icon © Bennett, Mc. Robb and Farmer 2002 14
The Active State with Concurrent Substates Active Running extend. Campaign() /modify Budget() Advert Preparation confirm. Schedule() Running Adverts adverts. Approved() /authorize() Scheduling campaign. Completed() /prepare. Final. Statement() Monitoring Survey survey. Complete() run. Survey() © Bennett, Mc. Robb and Farmer 2002 Evaluation 15
Concurrent States n n n A transition to a complex state is equivalent to a simultaneous transition to the initial states of each concurrent statechart An initial state must be specified in both nested statecharts in order to avoid ambiguity about which substate should first be entered in each concurrent region A transition to the Active state means that the Campaign object simultaneously enters the Advert Preparation and Survey states © Bennett, Mc. Robb and Farmer 2002 16
Concurrent States Once the composite states is entered a transition may occur within either concurrent region without having any effect on the state in the other concurrent region n A transition out of the Active state applies to all its substates (no matter how deeply nested) n © Bennett, Mc. Robb and Farmer 2002 17
Synchronized Concurrent Threads. Synchronization bar n n Explicitly showing how an event triggering a transition to a state with nested concurrent states causes specific concurrent substates to be entered Shows that the composite state is not exited until both concurrent nested statecharts are exited © Bennett, Mc. Robb and Farmer 2002 18
Preparing Statecharts n Two approaches may be used: – Behavioural approach – Life cycle approach Allen and Frost (1998) © Bennett, Mc. Robb and Farmer 2002 19
Behavioural Approach 1. 2. 3. 4. Examine all interaction diagrams that involve each class that has heavy messaging. Identify the incoming messages on each interaction diagram that may correspond to events. Also identify the possible resulting states. Document these events and states on a statechart. Elaborate the statechart as necessary to cater for additional interactions as these become evident, and add any exceptions. © Bennett, Mc. Robb and Farmer 2002 20
Behavioural Approach 5. 6. 7. 8. Develop any nested statecharts (unless this has already been done in an earlier step). Review the statechart to ensure consistency with use cases. In particular, check that any constraints that are implied by the statechart are appropriate. Iterate steps 4, 5 and 6 until the statechart captures the necessary level of detail. Check the consistency of the statechart with the class diagram, with interaction Bennett, Mc. Robb and Farmer 2002 diagrams and© with any other statecharts and 21
Sequence Diagram with Implicit States Sequence diagram for use case Set Campaign Completed Campaign Manager : Complete. Campaign. UI select. Client() start. Interface() : Client : Campaign *get. Client() show. Client. Campaigns() list. Campaigns() complete. Campaign() *get. Campaign. Details() Active state campaign. Completed() Completed state © Bennett, Mc. Robb and Farmer 2002 22
/assign. Manager(); assign. Staff() Commissioned authorized(authorization. Code) [contract signed] /set. Campaign. Active() Initial statechart for the Campaign class—a behavioural approach extend. Campaign() /modify Budget() Running Adverts Advert Preparation confirm. Schedule() adverts. Approved() /authorize() Scheduling campaign. Completed() /prepare. Final. Statement() payment. Received(payment) [payment. Due - payment < zero] /generate. Refund() Completed payment. Received(payment) [payment. Due - payment = zero] payment. Received(payment) [payment. Due – payment > zero] Paid archive. Campaign() /unassign. Staff(); unassign. Manager() © Bennett, Mc. Robb and Farmer 2002 23
/assign. Manager(); assign. Staff() Commissioned authorized(authorization. Code) [contract signed] /set. Campaign. Active() Active Revised statechart for the Campaign class extend. Campaign() /modify Budget() Running Adverts Advert Preparation confirm. Schedule() adverts. Approved() /authorize() Scheduling campaign. Completed() /prepare. Final. Statement() payment. Received(payment) [payment. Due - payment < zero] /generate. Refund() Completed payment. Received(payment) [payment. Due - payment = zero] payment. Received(payment) [payment. Due – payment > zero] Paid archive. Campaign() /unassign. Staff(); unassign. Manager() © Bennett, Mc. Robb and Farmer 2002 24
/assign. Manager(); assign. Staff() Commissioned authorized(authorization. Code) [contract signed] /set. Campaign. Active() Active Monitoring survey. Complete() Survey Final version of Campaign statechart Evaluation run. Survey() campaign. Cancelled() /calculate. Costs(); prepare. Final. Statement() Running extend. Campaign() /modify Budget() Running Adverts Advert Preparation confirm. Schedule() campaign. Cancelled() /cancel. Schedule() calculate. Costs(); prepare. Final. Statement() adverts. Approved() /authorize() Scheduling campaign. Completed() /prepare. Final. Statement() Completed payment. Received(payment) [payment. Due - payment < zero] [payment. Due - payment = zero] /generate. Refund() archive. Campaign() © Bennett, Mc. Robb and Farmer 2002 /unassign. Staff(); unassign. Manager() Paid payment. Received(payment) [payment. Due – payment > zero] 25
Life Cycle Approach n n Consider the life cycles for objects of each class Events and states are identified directly from use cases and from any other requirements documentation that happens to be available First, the main system events are listed Each event is then examined in order to determine which objects are likely to have a state dependent response to it © Bennett, Mc. Robb and Farmer 2002 26
Life Cycle Approach Steps 1. 2. 3. 4. Identify major system events. Identify each class that is likely to have a state dependent response to these events. For each of these classes produce a firstcut statechart by considering the typical life cycle of an instance of the class. Examine the statechart and elaborate to encompass more detailed event behaviour. © Bennett, Mc. Robb and Farmer 2002 27
Life Cycle Approach Steps 5. 6. 7. 8. Enhance the statechart to include alternative scenarios. Review the statechart to ensure that is consistent with the use cases. In particular, check that the constraints that the statechart implies are appropriate. Iterate through steps 4, 5 and 6 until the statechart captures the necessary level of detail. Ensure consistency with class diagram and interaction diagrams and other statecharts. © Bennett, Mc. Robb and Farmer 2002 28
Life Cycle Approach Less formal than the behavioural approach in its initial identification of events and relevant classes n Often helpful to use a combination of the two, since each provides checks on the other n © Bennett, Mc. Robb and Farmer 2002 29
Consistency Checking n n Every event should appear as an incoming message for the appropriate object on an interaction diagram Every action should correspond to the execution of an operation on the appropriate class, and perhaps also to the despatch of a message to another object Every event should correspond to an operation on the appropriate class (but note that not all operations correspond to events) Every outgoing message sent from a statechart must correspond to an operation on another class © Bennett, Mc. Robb and Farmer 2002 30
Consistency Checking Consistency checking is an important task in the preparation of a complete set of models n Highlights omissions and errors, and encourages the clarification of any ambiguity or incompleteness in the requirements n © Bennett, Mc. Robb and Farmer 2002 31
Summary In this lecture you have learned about: n How to identify requirements for control in an application n How to model object life cycles using statecharts n How to develop statechart diagrams from interaction diagrams n How to model concurrent behaviour in an object n How to ensure consistency with other UML models © Bennett, Mc. Robb and Farmer 2002 32
References UML Reference Manual (OMG, 2001) n Allen and Frost (1998) n (For full bibliographic details, see Bennett, Mc. Robb and Farmer) © Bennett, Mc. Robb and Farmer 2002 33
- Slides: 33