Statecharts

1. Statecharts

2. Objectives • Learn the concepts for modeling object states • Learn Statechart notation to depict object state models • Do some modelling… • Consider some issues…

3. Statecharts history and purpose • Statecharts are a form of state transition diagram (STD) that allow for nesting, orthogonality (concurrency) and broadcasting, thus reducing the complexity of many STDs. • They were invented by Israeli computer scientist David Harel. • A statechart is used to describe the complex internal behavior of a class. • It charts the possible lifecycles of objects from that class. (Similar to Entity Life Histories)

4. Statecharts usage • A statechart is used to show the life cycle of the objects from complex classes. • Simple classes do not need to have statechart. • The state of an object is related to the values of its variables. • A statechart can also be used for a system overview. • A statechart can also be used for interface design. • A statechart can be used to describe a protocol

5. State models - the basics • State modelling uses a different set of concepts from Class diagrams, Interaction diagrams etc • We need to understand the concepts and learn notation • Phases of an object’s lifecycle (States) • How an object changes its state (Events, Transitions) • Behaviour in each state (Actions, Activities) • ... • Also need to tie up with known OO concepts • operations, attributes…

6. State models - the basics • State - “A condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event” • Event - “A significant occurrence that has a location in time and space…a stimulus that can trigger a state transition” • Transition - “A relationship between two states indicating that an object in the first state will perform certain actions and enter the second state when a certain event occurs and conditions are satisfied” state event click Off On click transition

7. A simple Statechart (Door) close lock Open Closed (unlocked) Closed (locked) open unlock

8. Initial & Final States Baby Toddler Initial State Child Teenager Adult Final State

9. Thinking about Time • For a class with a Statechart, each object is always in one of the defined states - never between states • Therefore events and transitions are regarded as having zero or insignificant duration (ie there are no gaps between states) LAMP Off On Off On Off TRAFFIC LIGHT (UK) Time

10. Actions • Action - “An executable atomic computation that results in a change of state of the system or the return of a value” • Deemed to have insignificant duration & be non-interruptible • Actions may appear on transitions, or inside states (internal transition). Burglar Alarm System code entered / beep Idle Armed code entered/ beep test button pressed intruder detected / start alarm test button pressed code entered / silence alarm Ringing Test Mode intruder detected / beep

11. Activities • Activity - “ongoing non-atomic execution within a state machine” • Has duration & is interruptible • Can only be placed inside states (not on transitions). • May be a sequence of actions or may name another state machine • Indicated by keyword do/ Idle Armed code entered / beep intruder detected Ringing Counting do / countdown / start alarm

12. Activity states • States with ongoing activities are known as Activity States • UML provides an alternative notation to visually distinguish them • Activity States also used in Activity Diagrams Ordinary State Activity State

13. Automatic transitions • Aka Triggerless transition or Completion transition • “Triggered implicitly when source state completes its activity” • so this activity cannot be an endless loop Activity state code entered / beep Counting Idle Automatic transition - requires no event Ringing

14. Useful Keywords • entry/ - pseudo event inside a state, associated action(s) to be performed whenever the object enters (or re-enters) the state. • exit/ - pseudo event inside a state, associated action(s) to be performed whenever the object leaves the state. • do/ - inside a state, identifies an activity • after/ - indicates a relative time. Eg after 2 seconds; after 1 ms since exiting idle. (Default start time is entry to current state) • when/ - indicates a condition becoming true (including absolute times) Eg when 11.30; when temp < 0. • /defer - pseudo action inside a state, associated event(s) not handled in current state, but not totally discarded either - queued for handling in a subsequent state.

15. State A State B do / activity A entry / action Jexit / action K do / activity B entry / action P exit / action Q Processing Sequence • When event E occurs (and object is in state A): • Activity A is terminated. • Exit action K is performed. • Action X on the transition is performed. • Entry action P is performed. • Activity B is started. event E / action X

16. Self Transitions • Event E (self transition) => • Stop activity A • Perform actions K, X, J • Start activity A • Event F (internal transition) => • Perform action Z State A event E / action X do / activity A entry / action Jexit / action K event F / action Z

17. Statecharts - advanced

18. Guard conditions • Qualifies whether to respond to event • Boolean condition • Evaluated when event is detected • Actions/transition only occur if condition is true • Allows same event to be associated with multiple responses Spaces Available Full booking [delegates = capacity] booking [delegates < capacity] / add delagate A training course

19. Sub-states • A state can be decomposed into sub-states • One of the sub-states can be the default initial state for that super-state • Transitions can go to & from super-state or sub-states • entry/exit actions performed in defined sequence Super Sub1 Sub2

20. Concurrent sub-states Overhead Projector On Desk Light Off On Floor Light On

21. State explosions A text item – most transitions not shown! B I Bold onItalics offUnderline off Bold offItalics offUnderline off Bold offItalics onUnderline off B I U U Bold offItalics onUnderline on Bold onItalics offUnderline on U U B I B I Bold offItalics offUnderline on Bold onItalics onUnderline off Bold onItalics onUnderline on

22. Orthogonal states Underline on Bold on Italics on B B I I U U Underline off Bold off Italics off

23. History states B A interrupt B1 C resume H B2 H* indicates a deep history

24. Junction States Junction states entry / q / b / c e /a f / a;b;c Source Target exit / p Outcomes - e / a; p; b; q; c f / p; a; b; c; q

25. Join and Fork A1 A2 B1 B2 fork join

26. A B1 Class Class B2 Implementing States • Statechart concepts must be mapped to OO concepts • Events, States, Actions, Activities, Transitions, Guards operations attributes associations

27. TCPEstablished TCPConnection TCPListening TCPClosed open() close() acknowledge() open() close() acknowledge() open() close() acknowledge() open() close() acknowledge() ‘State’ Design Pattern (1) • INTENT– Allow an object to alter its behaviour when its internal state changes. The object will appear to change its class. Heuristic – normally an object should not actually change its class X From Design Patterns Gamma, Helm, Johnson, Vlissides

28. TCPEstablished TCPConnection TCPState TCPListening TCPClosed open() close() acknowledge() open() close() acknowledge() open() close() acknowledge() open() close() acknowledge() open() close() acknowledge() ‘State’ Design Pattern (2) state.Open() From Design Patterns Gamma, Helm, Johnson, Vlissides

29. Statechart example Initial State Final State Event (event parameter) State Transition Action Nested State

30. Object Constraint Language

31. What is a constraint {self.transaction -> forAll(t:Transaction | t.value > 100)} Account Transaction 1 0..* An Account can only hold transactions worth more than £100

32. Design by Contract put (element: T, key: STRING) is -- insert element with given key require count < capacity do .. insertion algorithm ... ensure count <= capacity; item (key) = element; count = old count + 1 end --put Obligations Benefits Get modified table Call put only on a in which x is Client non-full table associated with key No need to deal with Insert x so that it the case in which the may be retrieved Contractor table is full before through key insertion

33. OCL requirements • The OCL must enable us to express extra, necessary, information on object models. • The OCL must be a precise and unambiguous language that can be easily read by developers and customers. • The OCL must be a declarative language, its expressions can have no side-effects. • OCL must be a typed language so that OCL expressions can be type checked for correctness.

34. OC Language is ... • OCL is a typed language • The OCL is a language of expressions. • An OCL expression is valid if it is written according to the rules (formal grammar) of OCL. • A constraint is a valid OCL expression of type Boolean. • A constraint is a restriction on one or more values of (part of) an object-oriented model or system.

35. Customer name: Stringtitle: Stringage: IntegerisMale: Boolean Boolean expressions title = if isMale then ‘Mr.’ else ‘Ms.’ endif age >= 18 and age < 66 name.size < 100

36. Context for a constraint Vehicle 1..4 Wheel Vehicle self.wheelCount <= 4 and self.wheelCount >= 1

37. Multiplicity constraints Vocabulary VocabElement Hint 1 0..* 1 0..5 Equivalent constraints expressed on the classes VocabElementself.hint -> size >= 0 and self.hint -> size <= 5 VocabElementself.vocabulary -> size = 1 Hintself.vocabElement -> size = 1

38. Flight Person Subset constraint pilot crew 1..* flightAttendant 0..* Flightself.crew -> includes( self.pilot ) Flightself.crew -> includesAll(self.flightAttendants)

39. OCL collections Collection Set Bag Sequence minussymmetricDifferenceasSequenceasBag asSequenceasSet firstlastat(int)appendprependasBagasSet

40. OCL Summary • Constraints are required in the UML because the notations can never be sufficiently expressive to capture all we know. • Constraints are one way to practice design by contract. • The OCL is a formal notation for precisely specifying constraints in object models.

41. Module Summary • Statecharts in UML are related to classes and they describe the possible lifetimes of all the possible objects from that class. • Statecharts are an advance on earlier state modeling notations because they allow nesting and concurrency. • Statecharts are only drawn for classes with significant complexity. • Statecharts can be used for more than object lifecycle modeling.

42. Questions or Comments? ?