1. Statecharts Slide: 1

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

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) Slide: 3

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 Slide: 4

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… Slide: 5

6. State models - the basics click state transition event 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” OffOn Slide: 6

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

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

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) OffOn LAMP TRAFFIC LIGHT (UK) Off Time Slide: 9

10. Actions Armed Idle Ringing code entered / beep test button pressed 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 intruder detected / start alarm Test Mode intruder detected / beep code entered / silence alarm test button pressed Slide: 10

11. Activities Armed Idle Ringing code entered / beep 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/ intruder detected Counting do / countdown / start alarm Slide: 11

12. Activity states Activity State Ordinary State 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 Slide: 12

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

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. Slide: 14

15. 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. State A do / activity A entry / action J exit / action K State B do / activity B entry / action P exit / action Q event E / action X Slide: 15

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 do / activity A entry / action J exit / action K event F / action Z event E / action X Slide: 16

17. Statecharts - advanced Slide: 17

18. Guard conditions Spaces Available Full booking [delegates = capacity] booking [delegates < capacity] / add delagate A training course 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 Slide: 18

19. Sub-states Super Sub1Sub2 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 Slide: 19

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

21. State explosions Bold off Italics off Underline off Bold off Italics on Underline off Bold off Italics off Underline on Bold on Italics off Underline off Bold on Italics on Underline off Bold on Italics off Underline on Bold on Italics on Underline on Bold off Italics on Underline on A text item – most transitions not shown! BI U BI U U U B B I I Slide: 21

22. Orthogonal states Bold on Underline on Bold off Italics on Italics off Underline off BBIIU U Slide: 22

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

24. Junction States SourceTarget exit / p entry / q Junction states f / a;b;c / b e /a / c e / a; p; b; q; c f / p; a; b; c; q Outcomes - Slide: 24

25. Join and Fork A1A2 B1B2 forkjoin Slide: 25

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

27. ‘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. TCPEstablished open() close() acknowledge() TCPConnection open() close() acknowledge() TCPListening open() close() acknowledge() TCPClosed open() close() acknowledge() X Heuristic – normally an object should not actually change its class From Design Patterns Gamma, Helm, Johnson, Vlissides Slide: 27

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

29. Statechart example Initial StateFinal State Transition State Nested State Event (event parameter) Action Slide: 29

30. Object Constraint Language Slide: 30

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

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 ObligationsBenefits Client Contractor Call put only on a non-full table Get modified table in which x is associated with key Insert x so that it may be retrieved through key No need to deal with the case in which the table is full before insertion Slide: 32

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. Slide: 33

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. Slide: 34

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

36. Context for a constraint Wheel Vehicle self.wheelCount = 1 1..4 Slide: 36

37. Multiplicity constraints VocabularyVocabElementHint 0..50..*11 VocabElement self.hint -> size >= 0 and self.hint -> size <= 5 VocabElement self.vocabulary -> size = 1 Hint self.vocabElement -> size = 1 Equivalent constraints expressed on the classes Slide: 37

38. Subset constraint FlightPerson pilot flightAttendant crew Flight self.crew -> includes( self.pilot ) Flight self.crew -> includesAll(self.flightAttendants) 0..* 1..* Slide: 38

39. OCL collections Collection SetBagSequence minus symmetricDifference asSequence asBag first last at(int) append prepend asBag asSet asSequence asSet Slide: 39

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. Slide: 40

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. Slide: 41

42. Questions or Comments? Slide: 42