StateChart Diagrams

1. StateChart Diagrams

2. State Machines • Overview • Change summary • core constructs • notation • Examples • Backward compatibility • User benefits • Issues

3. Overview • State machines specify discrete behavior by mapping received events into sets of states. They may specify detailed behaviors of classes or constrain operational sequences of ports or interfaces. • The core constructs in statemachines include: • States, Regions, Transitions, Events • Notated using state machine diagrams • Typical applications of statemachines include: • object lifecycle • states an “order” object might be in • event-driven behaviors of embedded controllers • UI controllers • valid Sequences of calls via interfaces or ports

4. Change Summaryfor UML 2.0 • New core constructs added: • entry/exit points on submachines • state machine specialization/redefinition • state machine Termination • protocol state machines • transitions pre/post conditions • protocol conformance • UML 1.4 core constructs updated: • metamodel refactoring • Notational enhancements • action blocks • state lists

5. ReleaseCard Entry/Exit Points: Usage ATM invoked submachine VerifyCard usage of exit point acceptCard outOfService ReadAmount: ReadAmountSM aborted OutOfService again rejectTransaction usage of entry point releaseCard VerifyTransaction

6. Entry/Exit Points: Definition ReadAmountSM definition of exit point abort otherAmount selectAmount amount abort EnterAmount aborted definition of entry point ok again

7. ATM Behaviour Statemachine acceptCard() outOfService() amount() <<Redefine>> Behaviour FlexibleATM Statemachine otherAmount() rejectTransaction() Specialization • Redefinition as part of class specialization

8. State machine of ATM to be redefined State Machine Redefinition ATM VerifyCard {final} acceptCard ReadAmount selectAmount selectAmount outOfService OutOfService {final} amount releaseCard VerifyTransaction ReleaseCard {final} {final}

9. State Machine Redefinition • FlexibleATM redefines ATM FlexibleATM ATM {extended} VerifyCard {final} acceptCard ReadAmount {extended} otherAmount selectAmount selectAmount outOfService OutOfService {final} amount EnterAmount ok rejectTransaction releaseCard VerifyTransaction ReleaseCard {final} {final}

10. FlexibleATM Statemachine States and transitions can be added States and state machines can be extended Regions can be added, and regions can be extended Transitions can be replaced or extended Actions can be replaced Guards can be replaced Submachines can be replaced otherAmount EnterAmount EnterAmount ok rejectTransaction State Machine Redefinition {extended} FlexibleATM ATM ReadAmount {extended} SelectAmount VerifyTransaction

11. State Machine Specialization • Independent state machine specialization • not as part of class specialization • facilitates reuse of behaviours ATMmachines <<statemachine>> ATMsm <<statemachine>> FlexibleATMsm

12. Protocol State Machines • Equivalent to pre and post conditions added to the related operations: • takeOff() • Pre • in state "checked" • cleared for take off • Post • landing rear is retracted • in state "flying" check() onGround checked [cleared for take off] takeOff() /[landing rear is retracted] flying land() postcondition instead of action

13. Transition notation State lists logCard logCard alternative choice Idle Req(Id) sequence of actions [ID>10] [ID<=10] MinorReq=Id; MajorReq=Id; Major(Id) Minor(Id) Busy VerifyCard Logged ReleaseCard Example: Notation Enhancements VerifyCard, ReleaseCard Logged Is a notational shorthand for

14. Statesexample Library Title

15. Backward Compatibility • In general all UML 1.4 state machine concepts are preserved in the 2.0 proposal • Submachines: stub-states replaced by connection points • Specialization (only a note in UML 1.4) now specified • Protocol state machines now specified as a separate compliance point

16. User Benefits • Entry/Exit Points • reuse via encapsulation of statemachine control interfaces • scalability • Specialization • reuse, refinement • Protocol State Machines • usage of stat emachines at higher level of abstraction

17. What Does a Statechart Depict?

18. Classifier of a State Machine • The modeling element which is described by the statemachine • Usually a class

19. State MachinesTerms and Concepts • State machine is a behavior that specifies the sequences of states an object goes through during its lifetime • State • Event • Transition

20. State Transition Diagrams • Show a state machine. • Emphasize the event-ordered behavior of an object. • Model the changes in an object in response to the environment. • Document the following: • Causes of change • Alterations in behavior based on the object’s current condition

21. StateCharts vs. Sequence & Collaboration Diagrams • Sequence&Collaboration diagrams show how information passes through the objects of a system over time. • State Transition diagrams show how one object changes over time, • given that methods are invoked on it by other objects. • Changing the statechart states doesn’t influence the Class structure, i.e. Internal affair

22. States • All objects have a “state.” The current state of any object is dictated bythe values stored in its attributes. • Initial • final

23. States • A period of time in the life of an objectduring which it • Satisfies some condition, and/or • Performs some activity, and/or • Waits for some events • Some special states • Start state • At most one • Final state • Can appear many times; all have thesame meaning - namely, the classifierceases to exist

24. States

25. Transitions • Event Trigger • Guard Condition • Action • entry, exit, activity

26. Transitions and Events • Example: statechart forPatient class • A transition without anexplicit event label iscalled trigerless • When source state iscomplete, transitionoccurs

27. Events • An “event” is the stimulus that prompts an object to make the transition from one state to another. • Events take the form of a method call.

28. Events • Trigger transitions • May represent thereceipt of a message: • Between system andactors • Among objects • From an object to itself • Several kinds of events • Signals • Calls • Passage of time, forexample: • after(2 sec) • Change in state, forexample: • when(quantity < 10) • when(date = Y2K)

29. Deferring Events EDo: UG-ban utananezni

30. Internal Actions/Activities

31. Transition Details • Guard Condition • Action

32. Self- & Internal- Transitions

33. Actions • Triggered by an event • An executable, atomic computation • Noninterruptible, runs to completion • Usually the invocation of an operation (a call) • to the state machine classifier • to objects linked to the classifier

34. Actions vs. Events

35. Composite States EDo: We don’t go deeper now

36. Sending Messages:Textual Notation

37. Sending Messages:Graphical Notation • Syntax: a <<send>> dependency drawn from a transition to a class box: the dependency is labeled with the message

38. SuperStates • when you have many states that respond to some of the same events in the same way

39. Overriding superstate transitions

40. Hierarchical invocation of Entry and Exit actions

41. Simple Login State Machine

42. Real world example

43. That’s it for today 