1 / 52

Real-Time Systems, COSC-4301-01, Lecture 19

Real-Time Systems, COSC-4301-01, Lecture 19. Stefan Andrei. Reminder of the last lecture. Model checking of finite-state systems. Overview of This Lecture. Visual formalism, statecharts, and STATEMATE. Lacks modularity Exponential state explosion

keithharris
Download Presentation

Real-Time Systems, COSC-4301-01, Lecture 19

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. Real-Time Systems, COSC-4301-01, Lecture 19 Stefan Andrei COSC-4301-01, Lecture 19

  2. Reminder of the last lecture • Model checking of finite-state systems COSC-4301-01, Lecture 19

  3. Overview of This Lecture • Visual formalism, statecharts, and STATEMATE COSC-4301-01, Lecture 19

  4. Lacks modularity Exponential state explosion Cannot specify absolute time and time intervals Modular and hierarchical features Refinement: a state decomposed into lower-level states Clustering: set of states combined into a higher-level state Finite-state machine vs Statechart COSC-4301-01, Lecture 19

  5. Applications of Statecharts • Specifying reactive systems. • Reactive systems are complex-driven mechanisms that interact with discrete occurrences in the environment in which they are embedded. • Examples of reactive systems: • Real-time computer systems, communication devices, control plants, VLSI circuits, airplane avionics. • The reactive behavior of real-time systems cannot be captured by specifying the outputs for every possible set of inputs. • Instead, this behavior has to be described by specifying the relationship of inputs, outputs, the system state over time. COSC-4301-01, Lecture 19

  6. Object Behavior • The behavior of an object is defined by its reaction to messages at any point in execution. • Some object behaviors can be studied by: • Object Diagram, OR • Interaction Diagram • Not sufficient: • Cannot model all possible scenarios, e.g., only specific sequence of messages are studied. • Only model some legal (possible) states - show how an object behaves in particular interactions. • We need to know about illegal or impossible states to plan for them. COSC-4301-01, Lecture 19

  7. Specifying Behaviour in UML • Different notation is needed to summarize the overall behaviour of objects. • UML defines a statechart for this purpose. • Complement interaction diagrams for understanding the dynamic behaviour of system: • Interaction Diagram: • Models some inter-object messages with well defined order during a short duration. • Statechart: • Models the entire lifetime of a single object, specifying all possible sequences of messages and responses. COSC-4301-01, Lecture 19

  8. State-dependent Behaviour • Objects respond differently to the same stimulus/events at different times. • Can be modelled by defining a state machine: • It has a set of states: • an object can be in one state at any time; • the state it is in determines how it responds to events. • It has a set of transitions: • an event can cause the object to move from one state to another. COSC-4301-01, Lecture 19

  9. CD Player: An Example • Behaviour of a simple CD player: • A drawer to hold the CD; • Control interface with 3 buttons: • Load button: the drawer will open if it was shut and will shut if it was open; • Stop button: the player will stop playing. If there is no CD, there is no effect; • Play button: the CD will be played. If the drawer is open, the drawer shuts before playing starts. COSC-4301-01, Lecture 19

  10. UML Statechart Semantic • A statechart defines the behaviour of instances of a given class. • It shows: • The possible states of an object; • The events it can detect; • Its response to those events. • An object is in oneactive state at a time: • Events may be received at any time, which can trigger a transition to the next active state; • If an Event only causes a loop on a state (i.e., no change of an active state), the transition is known as self-transition. COSC-4301-01, Lecture 19

  11. Statechart: Deciding States • Identifying separate states: • Informal principle: • States S1 and S2 are separate if an object in state S1 responds differently to at least one event from the way it responds to that event in state S2. • Syntax: • States: rounded rectangles with the name of the state ( ). • Example: • There are 3 states for the CD player: • Closed, Playing, Open. StateName COSC-4301-01, Lecture 19

  12. trigger Statechart: Identifying Events • Events are usually external stimulus: • E.g., messages that can be sent to an object; • Internal stimulus will be covered later in the lecture. • Events usually cause an object to change state: • Moving from one state to another is known as transition; • Events that causes transition are known as trigger; • Events can optionally carry data (similar to message parameter). • Syntax: • An arrow with the trigger attached ( ). • Example: • There are three events for the CD Player: load, play, stop. COSC-4301-01, Lecture 19

  13. Statechart CD Player: Statechart Ver. 1 • Figure 10.1 from [Priestley; 2004], page 210 Transition: From Closed state to Open state triggered by load event. State: The Open state. COSC-4301-01, Lecture 19

  14. Initial and Final States • To specify the first active state when an object is created/initialized: • Use Initial State: • A transition leading from the initial state indicates the first active state. • No event should be written on a transition from an initial state. • Syntax: a black disc ( ). • To model the destruction of an object: • Use Final State: • Represent the end of flow, i.e., the object no longer exists. • May correspond to actual destruction for software object. • Syntax: a circled black disc ( ). COSC-4301-01, Lecture 19

  15. Statechart CD Player: Statechart Ver. 2 Initial State:CD Player switched on • Figure 10.2 from [Priestley; 2004], page 212 Final State: Switched Off the CD Player COSC-4301-01, Lecture 19

  16. Non-Deterministic System • When two or more transitions leading from a state share the same trigger: • No way to distinguish between them; • Randomly choose one of them; • The same history of events may end up in a different state; • Known as non-deterministic system. • Can be removed by adding information to distinguish between transitions with the same trigger. COSC-4301-01, Lecture 19

  17. CD Player: Non Deterministic Example • In real-life, a CD player will not play if there is no CD inside. • Statechart Ver. 2 does not describe this. • Correct Behaviour: • When the play event is detected, the CD Player should remain in the Closed state if there is no CD inside. • Resulting Statechart (partial), Figure 10.3 from [Priestley; 2004], page 213: This transition should be used when there is a CD inside. This transition should be for no CD inside. Statechart COSC-4301-01, Lecture 19

  18. Guard Condition • Although the two transitions are meant for different scenarios, the statechart does not distinguish among the two, resulting in non-deterministic behavior. • The non-determinism can be removed if we can specify the condition that determine the correct transition to use. • Syntax: trigger [guard_condition] • Semantics: • If a transition has a guard condition, it can only fire if that transition is evaluated to true; • If all guard conditions are false and there is no unguarded transition, the event will be ignored. • Usually, only one condition is true (determinism). COSC-4301-01, Lecture 19

  19. Statechart CD Player: Statechart Ver. 3 • Figure 10.4 from [Priestley; 2004], page 213 Guard Condition • Note that guard conditions are also added to transitions leading from the Open state. What do they represent? COSC-4301-01, Lecture 19

  20. Actions • A state can have actions triggered. • There are three ways an action can be triggered: • By an event; • By entering a state; • By leaving a state. • An action triggered by an event takes place in response to that event: • Syntax: Trigger [Guard_Condition] /action • Example: • The CD drawer will be closed when play is detected in the Open state. COSC-4301-01, Lecture 19

  21. Statechart CD Player: Statechart Ver. 4 • Figure 10.5 from [Priestley; 2004], page 215 Action triggered by Event COSC-4301-01, Lecture 19

  22. Action: Entering/Exiting a State • An action can be triggered as soon as the state is entered. • Useful to capture actions that must be performed regardless the transition used to arrive at the state. • Syntax: • Write in a compartment in the state box: entry/action • Similarly, an action can be performed just before leaving a state. • Syntax: • Write in a compartment in the state box: exit/action COSC-4301-01, Lecture 19

  23. CD Player: Statechart (partial) • Figure 10.6 from [Priestley; 2004], page 215 Action triggered by entering a state. Action triggered by leaving a state. Statechart Question: What happened when the play buttonis pressed during CD playing? COSC-4301-01, Lecture 19

  24. Action and Activity • Properties of Actions: • Short, self-contained processing; • Finished “instantaneously”; • Cannot be interrupted by events. • An “action” that does not conform to the above is termed as activity instead. • Property of Activities: • Performed during a state; • Carry out for an extended period of time; • Can be interrupted by events. • Syntax: • Write in a compartment of the state box: do/activity COSC-4301-01, Lecture 19

  25. Statechart (Partial) CD Player: Activity Example • Figure 10.7 from [Priestley; 2004], page 216 • Question: When the play track activity is being performed, what happen if the stop button is pressed? Activity performed during the Playing state. COSC-4301-01, Lecture 19

  26. Completion Transition • As well as being interrupted by events, some activities will come to an end of their own accord. • If an activity completes uninterrupted, then it can trigger a completion transition. • these are transitions without event labels. • Multiple completion transitions can be distinguished by guard conditions. • Example: • When the play track activity is completed: • If it is the last track, go to Closed state; • If it is not the last track, play the next track. COSC-4301-01, Lecture 19

  27. Statechart (Partial) CD Player: Completion Transition Example • Figure 10.8 from [Priestley; 2004], page 217 Completion Transition:No more track. Stop playing Completion Transition:Play the next track COSC-4301-01, Lecture 19

  28. Internal Transition • These are transitions that leave the object in the same state but does not trigger the entry and exit actions: • A self-transition is not appropriate. Why? • Use an Internal Transition which does not trigger the entry and exit action. • Syntax: • Write in a compartment of the state box: event/action • Example: • Suppose we add an info button for the CD Player to display the remaining playing time for current track. COSC-4301-01, Lecture 19

  29. CD Player: Internal Transition • Figure 10.9 from [Priestley; 2004], page 218 • Compare the two different ways to model the info button. Info /display time Statechart – Self- transition(Partial) Statechart – Internal Transition (Partial) COSC-4301-01, Lecture 19

  30. Composite State • States that share similar behavior can be grouped into a Composite State to simplify the statechart. • Composite State: • Syntax similar to simple state; • Contains a number of substates; • When a composite state is active, exactly one of the substate must be active; • Transitions can lead away from a composite state as well as any of its substates. • Example: • CD Player: the response to the play event is similar during the Open or Closed states. COSC-4301-01, Lecture 19

  31. Statechart CD Player: Composite State • Figure 10.10 from [Priestley; 2004], page 219 Composite State Transition shared by all substates Sub-State Transition specific to one substate COSC-4301-01, Lecture 19

  32. Composite State: Additional Property • A composite state is just like a simple state: • Can have Entry/Exit actions; • Can have extended activity. • A composite state is also like a mini-statechart: • Can have an Initial State to indicate the default substate if a transition terminates at boundary of a composite state; • Can have a Final State, which is triggered when ongoing activity within the state has finished. • Transitions: • Leading away from a composite state apply to all substates; • Arrive at composite state go to the default/initial state; • Can cross composite state boundaries. COSC-4301-01, Lecture 19

  33. CD Player: pause button • Pressing the pause button causes playing to be interrupted; • When the button is pressed again, playing continues from the position where it was paused, Figure 10.11 from [Priestley; 2004], page 220. Only triggers if the Composite State is entered. As there is no entry action, reentering the Playing substate will not restart the track. Statechart COSC-4301-01, Lecture 19

  34. History State • When a composite state is entered, it begins at the initial state or directly transits into one of the substates. • Sometimes, it is useful to re-enter a composite state at a point at which it was left. • Re-enter the last active substate. • Indicate this using the History State. • Transitions arriving at the History State activates the last active substate. • If there is no last active substate, a default state can be indicated by an unlabelled transition from History State. • Syntax: • A circled ‘H’ ( ) H COSC-4301-01, Lecture 19

  35. CD Player: History State • Suppose that re-pressing play button: • During Playing: restart and play the current track; • During Paused: restart the current track but remain paused, Figure 10.12 from [Priestley; 2004], page 221. Make use of History State to model the behavior correctly. Statechart Question: Does the statechart on slide 31 model this correctly? COSC-4301-01, Lecture 19

  36. CD Player: Final Version Statechart • Figure 10.13 from [Priestley; 2004], page 222 Statechart COSC-4301-01, Lecture 19

  37. Entry /action Exit /action Do /activity Event /action State Name Statechart Notation Summary Event(param) [condition] /action Transition and Trigger State H Initial State Final State HistoryState COSC-4301-01, Lecture 19

  38. Steps for Constructing Statechart • Identify the objects that have complex behavior; • Determine the initial and final states of the object; • Identify the events that affect the entity; • Working from the initial state, trace the impact of events and identify the intermediate states; • Identify any entry and exit actions on the states; • Expand states into a composite state if necessary; • Check that actions in the state are supported by operation (method); • Refine the class if necessary. • Another example of constructing Statechart: “Ticket Machine”. COSC-4301-01, Lecture 19

  39. Creating a Statechart • How information from interaction diagrams can be used to derive statecharts? • It can be hard to identify all necessary states. • Statecharts can be developed incrementally: • consider individual sequences of events received by an object; • these might be specified on interaction diagrams; • start with a statechart for one interaction; • add states as required by additional interactions. COSC-4301-01, Lecture 19

  40. Ticket Machine • Consider a ticket machine with two events: • select a ticket type; • enter a coin. • Basic interaction is to select a ticket and then enter coins. • model this as a ‘linear’ statechart, Figure 10.14 from [Priestley; 2004], page 224. • Problems: • It defines only one transaction, whereas the ticket machine is able to carry out repeated transactions; • It shows only 3 coins, but this number should be arbitrary. COSC-4301-01, Lecture 19

  41. Refining the Statechart • This can be improved by adding ‘loops’: • the number of coins entered will vary: entry will continue until the ticket is paid for; • the whole transaction can be repeated. • State ‘Idle’: no transaction is in progress, Figure 10.15 from [Priestley; 2004], page 225. COSC-4301-01, Lecture 19

  42. Adding Another Interaction • Suppose the requirements allow the user to enter a coin before selecting a ticket. • A ‘coin’ transition from the ‘Idle’ state is needed to handle this event. • this transition can’t go to the ‘Paying for Ticket’ state as the ticket is not yet selected. • so a new state ‘Inserting Coins’ is required. • The statechart is thus built up step-by-step. COSC-4301-01, Lecture 19

  43. Adding a Second Interaction • If all coins are entered before ticket selected, Figure 10.16 from [Priestley; 2004], page 226: COSC-4301-01, Lecture 19

  44. Integrating the Interactions • Suppose the requirements allow the user to enter some coins before selecting a ticket and the rest after that. • In fact, events can occur in any sequence, Figure 10.17 from [Priestley; 2004], page 227: COSC-4301-01, Lecture 19

  45. Time Events • Suppose the ticket machine times out after 30 seconds. • we need to fire a transition that is not triggered by a user-generated event; • UML defines time events to handle these cases. • Example: a transition will fire 30 seconds after the ‘no ticket selected’ state is entered, Figure 10.18 from [Priestley; 2004], page 228. COSC-4301-01, Lecture 19

  46. Activity States • Both ‘No Ticket Selected’ and ‘Ticket Selected’ should check if the machine is able to return any change that is required. • Efficient solution: activity states! • Activity states defines periods of time when the object is carrying out internal processing. • unlike normal activities, these cannot be interrupted by external events; • only completion transitions leading from them; • useful for simplifying the structure of complex statecharts. COSC-4301-01, Lecture 19

  47. Returning Change • Note that activity as a property of state (slide 23) is not the same as activity states. • Use an activity state to calculate change, Figure 10.19 from [Priestley; 2004], page 229. COSC-4301-01, Lecture 19

  48. Ticket Machine Statechart • It incorporates ‘Pressing Cancel’ in the middle of a transaction. • The composite state ‘Transaction’ reduces the number of statechart transitions, Figure 10.20 from [Priestley; 2004], page 230. Statechart COSC-4301-01, Lecture 19

  49. Summary • Visual formalism, statecharts, and STATEMATE: • Statecharts COSC-4301-01, Lecture 19

  50. Reading suggestions • Chapter 5 of [Cheng; 2002]; • Chapter 10 of [Priestley; 2004], where this is: • M. Priestley: Practical Object-Oriented Design with UML. Second Edition, 2004, ISBN: 978-0071-239233 COSC-4301-01, Lecture 19

More Related