Overview OO Using UML: ● The object model describes the structure of the system (objects, Dynamic Models attributes, and operations) ● The dynamic model describes how the objects change state (how the attributes change) and in which order the state changes can take place ● Several models used to find the appropriate dynamic behavior ■ Interaction diagrams Defining how the objects behave ■ Activity diagrams ■ State Diagrams ● Uses finite state machines and expresses the changes in terms of events and states 07-UML-Dynamic 1 2 07-UML-Dynamic We Will Cover ● Why interaction diagrams? Interaction Diagrams ● Sequence diagrams ■ Capturing use-cases ■ Dealing with concurrency ● Collaboration diagrams ● When to use what ● When to use interaction diagrams 07-UML-Dynamic 3 4 07-UML-Dynamic Different Types of Interaction Home Heating Use-Case Diagrams ● An Interaction Diagram typically captures a use- Use case: Power Up case Actors: Home Owner (initiator) Type: Primary and essential ■ A sequence of user interactions Description: The Home Owner turns the power on. Each room ● Sequence diagrams is temperature checked. If a room is below the the desired temperature the valve for the room is ■ Highlight the sequencing of the interactions between opened, the water pump started, the fuel valve objects opened, and the burner ignited. ● Collaboration diagrams If the temperature in all rooms is above the desired temperature, no actions are taken. ■ Highlight the structure of the components (objects) Cross Ref.: Requirements XX, YY, and ZZ involved in the interaction Use-Cases: None 5 6 07-UML-Dynamic 07-UML-Dynamic 1
Sequence Diagrams Example from Fowler an Order entry an Order an Order Line a Stock Item W indow a Hom e O wner the O n-O ff Switch the Controller a Room the W ater Pum p prepare() *[for all order lines] prepare() System O n powerO n() hasStock := check() *[for all room s] [hasStock] tem pStatus:=checkTem p() rem ove() needsReorder := needsToReorder() [needsReorder] [tem pStatus == low] new pum pO n() a Reorder Item [tem pStatus == low] openValve() [hasStock] new a Delivery Item [tem pStatus == low] startBurner() M H Concurrency Another Example new a Transaction a Hom e Owner the On-O ff Switch the Controller the W ater P um p a Transaction new System O n Coordinator powerOn() *[for each room in house] new new a first Transaction a Room Checker checkTem p() a second new Transaction Checker ok tem pLow allDone? [tem pLow] pum pOn() [tem pLow] ok openV alve() [tem pLow] allValid allDone? startBurner() M H Comment the Diagram Collaboration Diagrams :O rder Entry W hen the ow ner W indow turns the syste m on a Hom e O w ner the O n-O ff Sw itch the C ontroller the W ater Pum p the on sw itch notifies S ystem O n 1 : prepare() the controller powerO n() T he controller *[for each room in house] new crea tes a room object a Room :O rder for each room in the building checkTem p() 5 : needsReorder := needsToReorder() T he room s sam ple 2 : *[for all order lines]: the te m perature in prepare() 3 : hasS tock := check() the toom every 5 s. tem pLow W hen a low tem p is W inter stock : detected the room [tempLow ] W inter line : Order Line S tock Item notifies the pum pO n() controller. [tempLow ] 4 : [hasS tock]: openV alve() rem ove() 7 : [hasS tock] :new 6 : [needsReorder]: [tempLow ] new startB urner() M H :Delivery Item a Reorder Item M H 2
Conditional Behavior Comparison ● Something you will encounter trying to capture complex ● Both diagrams capture the same information use-cases ■ People just have different preferences ■ The user does something. If this something is X do this… If this ● We prefer sequence diagrams something is Y do something else… If this something is Z… ■ They clearly highlight the order of things ● Split the diagram into several ■ Invaluable when reasoning about multi-tasking ■ Split the use-case also ● Others like collaboration diagrams ● Use the conditional message ■ Shows the static structure ■ Could become messy ◆ Very useful when organizing classes into packages ● Remember, clarity is the goal! ● We get the structure from the Class Diagrams 13 14 07-UML-Dynamic 07-UML-Dynamic When to Use Interaction Diagrams ● When you want to clarify and explore single use- State Diagrams cases involving several objects ■ Quickly becomes unruly if you do not watch it ● If you are interested in one object over many use- cases -- state transition diagrams ● If you are interested in many objects over many use cases -- activity diagrams 15 07-UML-Dynamic 16 07-UML-Dynamic We Will Cover Where Do State Diagrams Fit? ● State Machines Has a Class Behavior ■ An alternate way of capturing scenarios ◆ Large classes of scenarios • Generally, one state diagram per class ● Syntax and Semantics • Describe the entire behavior of class ● When to use state machines Class • All methods in one state diagram 1 State Diagram 17 18 07-UML-Dynamic 07-UML-Dynamic 3
Events, Conditions, and States Making a Phone Call Scenario To make a call, the caller lifts receiver. The caller gets a dial ● Event: something that happens at a point in time dial tone and the caller dials digit (x). The dial tone ends. ◆ Operator presses self-test button The caller completes dialing the number. The callee phone ◆ The alarm goes off ● Condition: something that has a duration begins ringing at the same time a ringing begins in caller ◆ The fuel level is high phone. When the callee answers the called phone stops ◆ The alarm is on ringing and ringing ends in caller phone. The phones are ● State : an abstraction of the attributes and links of an object (or entire now connected. The caller hangs up and the phones are system) disconnected. The callee hangs up. ◆ The controller is in the state self-test after the self-test button has been pressed and the rest-button has not yet been pressed ◆ The tank is in the state too-low when the fuel level has been below level-low for alarm-threshold seconds 19 20 07-UML-Dynamic 07-UML-Dynamic Partial Class Diagram Event Trace The Caller The Line The Callee caller lifts receiver dial tone begins dials digit (4) dial tone ends 1..1 dials digit (2) Line Phone 1..1 Caller dials digit (3) dials digit (4) 1..1 dials digit (5) ringing tone phone rings 1..1 Callee callee answers tone stops ringing stops phones connected phones connected caller hangs up phones disconnected phones disconnected callee hangs up 21 07-UML-Dynamic State Diagram for Scenario Scenario 2 Idle on-hook The Caller The Callee The Line off-hook caller lifts receiver dial tone begins Dial tone dials digit (4) digit(x) digit(x) dial tone ends dials digit (2) Dialing dials digit (3) valid-number dials digit (4) Ringing dials digit (5) busy tone called-phone-answers caller hangs up Connected called-phone-hangs-up Disconnected 4
Modified State Machine Conditions Idle off-hook ● Sometimes the state transitions are conditional Dial tone digit(x) Idle on-hook Dialing digit(x) off-hook on-hook valid-number Busy tone number-busy Dial tone Connecting routed digit(x) [x = 8] digit(x) [x != 8] digit(x) Ringing digit(x) Dial tone digit(x) Dialing (external) called-phone-answers Dialing Connected valid-number valid-number called-phone-hangs-up Busy tone number-busy Disconnected on-hook Connecting routed Ringing 26 07-UML-Dynamic Operations (AKA Actions) Hierarchical State Machines on-hook Idle Dial tone off-hook do/ sound dial tone Idle dial(x) [x is a digit] dial(x) [x = *] Make Call off-hook Actions are Group states with ● ● Establish call Dial tone performed when a on-hook digit(x) similar characteristics Voice Mail dial(x) Dialing do/ sound dial tone transition is taken or ● Enables information Dialing performed while in a digit(x) valid-number hiding on-hook state number-busy Connecting on-hook Busy tone valid-number Simplifies the number-busy ● on-hook do/ find connection Actions are ● diagrams Busy tone do/ busy tone Connecting on-hook do/ busy tone terminated when routed routed do/ find connection leaving the state Ringing on-hook Ringing do/ ring bell do/ ring bell called-phone-answers / connect line called-phone-answers / on-hook / disconnect line connect line Connected Connected on-hook / disconnect line called-phone-hangs-up / called-phone-hangs-up / disconnect line disconnect line on-hook Disconnected Disconnected on-hook 27 07-UML-Dynamic Information Hiding Event Generalization ● Related events can inherit event properties from each other time Establish call ● If an event at a lower level on-hook dial(x) Idle Dial tone Dialing occurs - the event at a higher off-hook do/ sound dial tone valid-number level also occurred user-input dial(x) [x is a digit] dial(x) [x = *] number-busy Make Call Connecting device ● Event attributes do/ find connection Busy tone Establish call ■ mouse-up.location Voice Mail do/ busy tone routed on-hook ■ mouse-down.device Ringing mouse-button keyboard-key ■ mouse-button.time called-phone-answers / do/ ring bell on-hook / location character connect line disconnect line Connected called-phone-hangs-up / disconnect line on-hook Disconnected mouse-down mouse-up 29 30 07-UML-Dynamic 07-UML-Dynamic 5
Recommend
More recommend
