1 / 33

The Models are the Code - Executable UML

The Models are the Code - Executable UML. Lecture 7 - Getting a Lifecycle Paul Krause. Lecture 7 - Getting a Lifecycle. Active Classes vs Passive Classes Some basics of finite automata How to use Statecharts properly Completing the State model with State Transition Tables.

jcarvalho
Download Presentation

The Models are the Code - Executable UML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Models are the Code -Executable UML Lecture 7 - Getting a Lifecycle Paul Krause

  2. Lecture 7 - Getting a Lifecycle • Active Classes vs Passive Classes • Some basics of finite automata • How to use Statecharts properly • Completing the State model with State Transition Tables

  3. Active vs Passive Classes • Active Classes • The behaviour of instances of active classes (“active objects”) varies over time • e.g. Instances of a Thread class can be started, paused, continued, stopped • This behaviour can be captured in a Statechart • Passive Classes • Passive objects have the same behaviour at all times • Operations on a class are sufficient to define its behaviour • Information classes, e.g. Address, are typically of this kind

  4. State • A condition or situation during the life of an object during which it satisfies some condition, performs some action, or waits for some event. • The Unified Modelling Reference Manual

  5. Chewing Gum Liquorice Wine Gum An Abstract Machine Quiet Talkative Happy

  6. 0/0, 1/1 no carry 0/1 start 0/1 1/0 owe carry 1/0 Finite Automata with Output

  7. Moore = Mealy • Mealy machine • Actions are on the transitions (and only on the transitions) • Moore machine • Actions are on entry into new states (and only on entry) • Both are computationally sufficient • Anything that can be expressed as a Moore machine can be expressed as a Mealy machine, and vice-versa

  8. StateA StateB entry/ actions exit/ actions entry/ actions exit/ actions UML Statechart Notation guard condition actions event name e1 [cond] / action1;action2

  9. StateA StateB StateC StateD exit/ x = 10 entry/ action exit/ action exit/ y = 10 entry/ action exit/ action What Happens? initially x = 0 & y = 0 e1 [y < 10] / x = 5 e1 [x < 10] / y = 5

  10. Good Practice for Statecharts • Express the behaviour of Active Classes using a Statechart for each active class • Restrict usage to a subset of the full Statechart notation for clarity: • Actions are specified on entry into a state (not on exit, or on the transition itself) • An individual event can only cause a single transition out of a given state • This usage corresponds to expressing behaviour as a “Moore” machine

  11. Stopped Moving entry/ entry/ Emergency stop in progress Stopped for Evacuation entry/ apply emergency brake entry/ open all doors sound alarm State-dependent behaviour trainMadeSafe fireDetected trainStopped trainStarted trainStopped fireDetected

  12. Updating fuel while stopped Updating fuel while moving Updating fuel during emergency stop Updating fuel during emergency entry/ this.fuelLevel = fuelLevel entry/ this.fuelLevel = fuelLevel entry/ this.fuelLevel = fuelLevel entry/ this.fuelLevel = fuelLevel Stopped for Evacuation Stopped entry/ open all doors sound alarm entry/ Moving Emergency stop in progress entry/ entry/ apply emergency brake Including state-independent behaviour trainMadeSafe fireDetected fuelLevelUpdated trainMadeSafe trainStopped fireDetected trainStarted trainStopped trainStarted trainStopped fireDetected fuelLevelUpdated trainStopped fuelLevelUpdated fireDetected

  13. Updating fuel while stopped Updating fuel while moving Updating fuel during emergency stop Updating fuel during emergency entry/ this.fuelLevel = fuelLevel entry/ this.fuelLevel = fuelLevel entry/ this.fuelLevel = fuelLevel entry/ this.fuelLevel = fuelLevel Stopped for Evacuation Stopped entry/ open all doors sound alarm entry/ Moving Emergency stop in progress entry/ entry/ apply emergency brake Including state-independent behaviour trainMadeSafe fireDetected fuelLevelUpdated trainMadeSafe trainStopped fireDetected trainStarted trainStopped trainStarted trainStopped fireDetected fuelLevelUpdated trainStopped fuelLevelUpdated fireDetected

  14. State-independent behaviour Model State-independent behaviour as operations!

  15. Aircraft registrationNo airframeNo altitude latitude longitude createAircraft getPosition takeOffClearanceGranted landingClearanceGranted readyForDeparture aircraftClearedRunway Ideal Class representation Name Compartment Attribute Compartment Operation Compartment Signal Compartment

  16. Flying Landing On Ground Waiting for Clearance to Take-Off Taking Off State model for Aircraft Class aircraftClearedRunway landingClearanceGranted takeOffClearanceGranted aircraftClearedRunway readyForDeparture In most UML tools, this is the place where the signal events associated with a class are recorded.

  17. MicrowaveOven manufacturer serialNumber {I} lightOn doorOpen powerTubeEnergized cookingTimeRemaining Microwave Oven - being more systematic • When the door is closed and the button pressed, the oven cooks for 1 minute • The light is on when cooking or when the door is open • Further button presses increase the cooking time by 1 minute each • When the timer times out, the power tube and light are turned off and a warning beep is emitted

  18. Signals or Events doorOpened doorClosed buttonPressed timerTimesOut (counts down to zero) Actions Turn on the light Turn off the light Energize the power tube De-energize the power tube Set the timer for 1 min. Add 1 min. to the timer Clear the timer Sound the beeper Events and Actions

  19. 4. Cooking Interrupted entry/ turn off light de-energize power tube clear timer First version of Statechart The numbering does not imply any sequencing doorClosed doorClosed 2. Door Open 1. Ready to Cook buttonPressed doorOpened entry/ turn on light entry/ turn off light 3. Cooking doorOpened entry/ turn on light energize power tube set timer for 1 minute 5. Cooking Complete doorOpened entry/ turn off light de-energize power tube clear timer timerTimesOut

  20. 4. Cooking Interrupted doorClosed entry/ turn off light de-energize power tube clear timer doorClosed 2. Door Open 1. Ready to Cook buttonPressed doorOpened entry/ turn on light entry/ turn off light 3. Cooking doorOpened entry/ turn on light energize power tube set timer for 1 minute 5. Cooking Complete doorOpened entry/ turn off light de-energize power tube clear timer timerTimesOut The Statechart is not a complete model Can a door closed event be generated when the door is already closed? What happens if we press the button when the door is open? What happens if we press the button while cooking? What happens if we press the button when cooking is complete?

  21. State Transition Table

  22. State Transition Table

  23. 4. Cooking Interrupted entry/ turn off light de-energize power tube clear timer buttonPressed New Transition doorClosed doorClosed 2. Door Open 1. Ready to Cook buttonPressed doorOpened entry/ turn on light entry/ turn off light 3. Cooking doorOpened entry/ turn on light energize power tube set timer for 1 minute 5. Cooking Complete doorOpened entry/ turn off light de-energize power tube clear timer timerTimesOut

  24. State Transition Table

  25. 4. Cooking Interrupted entry/ turn off light de-energize power tube clear timer buttonPressed Is this correct? doorClosed doorClosed 2. Door Open 1. Ready to Cook buttonPressed doorOpened entry/ turn on light entry/ turn off light 3. Cooking doorOpened entry/ turn on light energize power tube set timer for 1 minute 5. Cooking Complete buttonPressed doorOpened entry/ turn off light de-energize power tube clear timer timerTimesOut

  26. 4. Cooking Interrupted 6. Cooking Extended entry/ turn off light de-energize power tube clear timer entry/ add 1 min. to timer buttonPressed Discovering new states and events doorClosed doorOpened doorClosed 2. Door Open 1. Ready to Cook doorOpened buttonPressed buttonPressed entry/ turn on light entry/ turn off light 3. Cooking entry/ turn on light energize power tube set timer for 1 minute doorOpened 5. Cooking Complete doorOpened entry/ turn off light de-energize power tube clear timer timerTimesOut buttonPressed timerTimesOut

  27. State Transition Table

  28. 4. Cooking Interrupted 6. Cooking Extended entry/ turn off light de-energize power tube clear timer entry/ add 1 min. to timer buttonPressed Event ignored buttonPressed event will have no effect doorClosed doorOpened doorClosed timerTimesOut event will have no effect buttonPressed event will have no effect 2. Door Open 1. Ready to Cook doorOpened buttonPressed buttonPressed entry/ turn on light entry/ turn off light 3. Cooking entry/ turn on light energize power tube set timer for 1 minute doorOpened 5. Cooking Complete doorOpened entry/ turn off light de-energize power tube clear timer timerTimesOut buttonPressed timerTimesOut

  29. State Transition Table

  30. 4. Cooking Interrupted 6. Cooking Extended entry/ turn off light de-energize power tube clear timer entry/ add 1 min. to timer buttonPressed Can’t Happen another doorOpen event can’t happen here! doorClosed doorOpened doorClosed 2. Door Open 1. Ready to Cook doorOpened another doorClosed event can’t happen here! buttonPressed buttonPressed entry/ turn on light entry/ turn off light 3. Cooking entry/ turn on light energize power tube set timer for 1 minute doorOpened 5. Cooking Complete doorOpened entry/ turn off light de-energize power tube clear timer timerTimesOut buttonPressed timerTimesOut

  31. State Transition Table

  32. Practical benefits for Testing • Writing out the State Transition table helps identify missing transitions • We found one major fault in the first Philips DVD player in this way, even before executing the test cases • Each cell in the table is a potential test case. However, remember: • You do need to execute “Event Ignored” tests • You do not need to execute “Can’t Happen” tests • in fact you will be physically unable to!

  33. Summary • We have seen how Statecharts can be used to model the lifecycles of class instances • Restricting usage of full UML to a precise subset adds clarity to the models, but • Statecharts are an incomplete view of the full state behaviour • Use State Transition Tables to help identify missing transitions and states • Base your test cases on the State Transition Tables and not on the Statechart • See Chapter 9 of Mellor and Balcer

More Related