520 likes | 536 Views
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
E N D
Real-Time Systems, COSC-4301-01, Lecture 19 Stefan Andrei COSC-4301-01, Lecture 19
Reminder of the last lecture • Model checking of finite-state systems COSC-4301-01, Lecture 19
Overview of This Lecture • Visual formalism, statecharts, and STATEMATE COSC-4301-01, Lecture 19
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Statechart CD Player: Statechart Ver. 4 • Figure 10.5 from [Priestley; 2004], page 215 Action triggered by Event COSC-4301-01, Lecture 19
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
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
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
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
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
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
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
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
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
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
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
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
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
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
CD Player: Final Version Statechart • Figure 10.13 from [Priestley; 2004], page 222 Statechart COSC-4301-01, Lecture 19
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
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
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
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
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
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
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
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
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
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
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
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
Summary • Visual formalism, statecharts, and STATEMATE: • Statecharts COSC-4301-01, Lecture 19
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