11/4/2015COSC-4301-01, Lecture 201 Real-Time Systems, COSC-4301-01, Lecture 20 Stefan Andrei.

Slides:



Advertisements
Similar presentations
State Charts Mehran Najafi. Reactive Systems A reactive, event-driven, object is one whose behavior is best characterized by its response to events dispatched.
Advertisements

UML State chart/machine diagram State machine diagram is a behavior diagram which shows discrete behavior of a part of designed system through finite state.
Statecharts Semantics
Vered Gafni – Formal Development of Real Time Systems 1 Statecharts Semantics.
STATEMATE A Working Environment for the Development of Complex Reactive Systems.
Chapter 7 Structuring System Process Requirements
©Katz-2004CS formal SpecificationsLecture--State machines 1 State Machines and Statecharts Formal Specifications CS Spring 2004 Shmuel Katz.
© 2005 Prentice Hall12-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
© 2005 Prentice Hall4-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
1 CS/CPE 426 Senior Projects Chapter 21: State Machines Chapter 22:Advanced State Machines [Arlow and Neustadt 2005] March 24, 2009.
THE OBJECT-ORIENTED DESIGN WORKFLOW Statechart Diagrams.
Statecharts: A Visual Formalism for Complex Systems Jeff Peng Model-based Design Lab.
State Change Modelling. Aim: To introduce the concept and techniques for describing the changes in state that may occur to an object in its lifetime.
Advanced Behavioral Modeling
Detailed Object-Oriented Requirements Definitions
SE-565 Software System Requirements More UML Diagrams.
An Introduction to Rational Rose Real-Time
Chapter 7 Structuring System Process Requirements
Traditional Approach to Requirements Data Flow Diagram (DFD)
02/06/05 “Investigating a Finite–State Machine Notation for Discrete–Event Systems” Nikolay Stoimenov.
Ch.2 Part A: Requirements, State Charts EECE **** Embedded System Design.
- 1 - Embedded Systems—State charts Specifications.
- 1 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Specifications.
Lecture 4 Finite State Machine CS6133 Software Specification and Verification.
Timed UML State Machines Ognyana Hristova Tutor: Priv.-Doz. Dr. Thomas Noll June, 2007.
BPMN By Hosein Bitaraf Software Engineering. Business Process Model and Notation (BPMN) is a graphical representation for specifying business processes.
State Diagrams / System Sequence Diagrams (SSDs)
1 SFWR ENG 3KO4 Software Development Statemate I-CASE Tool for Designing Software Systems from Different Views Statemate I-CASE Tool for Designing Software.
Data Flow Diagrams.
Chapter 7 Structuring System Process Requirements
1 Object-Oriented Modeling Using UML (2) CS 3331 Fall 2009.
Behavioral diagrams Lecture p4 T120B pavasario sem.
CSC 395 – Software Engineering Lecture 13: Object-Oriented Analysis –or– Let the Pain Begin (At Least I’m Honest!)
Object-Oriented Modeling Using UML CS 3331 Section 2.3 of Jia 2003.
StateCharts Peter Marwedel Informatik 12 Univ. Dortmund Germany.
1 Modeling interactions and behavior Lecturer Dr. Mai Fadel.
Ch. 2. Specification and Modeling 2.1 Requirements Describe requirements and approaches for specifying and modeling embedded systems. Specification for.
Chapter 5 Models and UML Notation for The Object-Oriented Approach.
7 Systems Analysis and Design in a Changing World, Fifth Edition.
Course Instructor: Kashif Ihsan 1. Chapter # 3 2.
By: David Harel & Eran Grey Presenter: Elizabeth Antony CISC 836.
1 Kyung Hee University Statecharts Spring Kyung Hee University Specifying Objects’ Behaviour  Interaction diagrams show message-passing behaviour.
CSCI-383 Object-Oriented Programming & Design Lecture 12.
Object Oriented Analysis & Design & UML (Unified Modeling Language)1 Part VI: Design Continuous Activity Diagams State Diagrams.
CS212: Object Oriented Analysis and Design Lecture 34: UML Activity and Collaboration diagram.
Systems Analysis and Design in a Changing World, Fourth Edition
CS3773 Software Engineering Lecture 06 UML State Machines.
Topic 4 - Database Design Unit 1 – Database Analysis and Design Advanced Higher Information Systems St Kentigern’s Academy.
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 10: Statecharts.
2/25/2016COSC , Lecture 191 Real-Time Systems, COSC , Lecture 19 Stefan Andrei.
CS151 Introduction to Digital Design Chapter 5: Sequential Circuits 5-1 : Sequential Circuit Definition 5-2: Latches 1Created by: Ms.Amany AlSaleh.
© 2005 by Prentice Hall Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
Chapter 7 Part II Structuring System Process Requirements MIS 215 System Analysis and Design.
1 7 Systems Analysis and Design in a Changing World, 2 nd Edition, Satzinger, Jackson, & Burd Chapter 7 The Object-Oriented Approach to Requirements.
Systems Analysis and Design in a Changing World, Fourth Edition
Systems Analysis and Design in a Changing World, Fourth Edition
Business Process and Functional Modeling
CHAPTER
Unified Modeling Language
System Design and Modeling
Copyright © Cengage Learning. All rights reserved.
State Machine Diagrams
UML dynamic Modeling (Behavior Diagram)
UML Activity Diagrams & State Charts
Object Oriented System Design
CS/CPE 426 Senior Projects
BPMN - Business Process Modeling Notations
CS/CPE 426 Senior Projects
Dynamic Modeling Lecture # 37.
CS 791Z State Machines & Advanced State Machines
Presentation transcript:

11/4/2015COSC , Lecture 201 Real-Time Systems, COSC , Lecture 20 Stefan Andrei

11/4/2015 COSC , Lecture 20 2 Reminder of the last lecture Visual formalism, statecharts, and STATEMATE:  Statecharts

11/4/2015 COSC , Lecture 20 3 Overview of This Lecture Visual formalism, statecharts, and STATEMATE:  Visual formalism and STATEMATE

11/4/2015 COSC , Lecture 20 4 Finite-state machine vs Statechart (Lecture 18) 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

11/4/2015 COSC , Lecture 20 5 Applications of Statecharts (Lecture 18) 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.

11/4/2015 COSC , Lecture 20 6 The Statechart language Provides graphic features (labeled boxes) to denote states (or sets of states) and transitions between states. A transition from one state to another state takes place when the associated events and conditions are enabled. A state can be decomposed into lower-level states via refinement, and a set of states can be combined into a higher-level state via clustering. This hierarchical specification approach makes it possible for the specifier to zoom-in and zoom-out of a section of the Statechart specification, thus partially remedying the exponential-state explosion problem in classical FSMs.

11/4/2015 COSC , Lecture 20 7 More Statechart Features Furthermore, AND and OR clustering relations, together with the notions of state exclusivity and orthogonality, can support concurrency and independence in system specification. To develop a comprehensive tool capable not only of system specification, [Harel et al.; 1990] extended the work on Statecharts to derive high-level languages for structural and functional specification.

11/4/2015 COSC , Lecture 20 8 Languages for structural and functional specification The language module-charts is used to describe a structural view with a graphical display of the components of the system. The language activity-charts is used to describe a functional view with a graphical display of the functions of the system. They also added mechanisms that provide a friendly user interface, simulated system executions, dynamic analysis, code generation, and rapid prototyping. The entire specification and development is known as STATEMATE.

11/4/2015 COSC , Lecture 20 9 Statecharts In Statecharts, labeled boxes denote states and directed edges indicate transitions between states. A transition takes place when the associated events and conditions are enabled. An expression labeling a transition is of the form event[condition]/action, where event is the event enabling the transition, condition is the condition which must hold for event to enable transition, and action is the action that is executed at precisely the time when the transition is taken. Usually, events and conditions can be treated as inputs and actions as outputs, as in traditional FSMs. However, these three parts of the transition label are optional.

11/4/2015 COSC , Lecture Selected list of special events, conditions, and actions Extensions to FSMs include the use of variables in the label of a transition, logical comparisons in conditions, and assignments in actions.

11/4/2015 COSC , Lecture Special events, conditions, and actions  Figure 5.1 from [Cheng; 2005], page 136

11/4/2015 COSC , Lecture Example started(ignition)[in(countdown) and not active(emergency)] / start(launchy); a := b + c + 1; d := a + 2; This label for a transition indicates that when the system is in the countdown state, the emergency state is not active, and the triggering event “started(ignition) occurs”, then both the action “start(launch)” and the two assignments a := b + c + 1; d := a + 2; are executed in parallel. Note that the expressions to the right of the “:=” must be side-effect free (e.g., if a =1, b =2, c =3, then after the transition is taken, a =6, d =3).

11/4/2015 COSC , Lecture Specifications of the behavior of the pedals for an automobile  Figure 5.2 from [Cheng; 2005], page 137

11/4/2015 COSC , Lecture Specifications of the behavior of the pedals for an automobile Both specifications show that the automobile can be in one of three states:  stop  move  slow Figure (a) shows that:  When accelerator is applied, the transition from the state “stop” to the state “speedup” occurs.  The transition from the state “speedup” to the state “slow” occurs when the brake is applied provided that the condition in the bracket is true (accelerator is not applied) etc.

11/4/2015 COSC , Lecture OR-Decomposition By clustering the states “speedup” and “slow” into a new state “move”, we obtain an equivalent specification in Figure (b). The transition labeled “apply hand brake” leaving state “move” is a high-level interrupt and denotes an exit from “move”. Whether the system is in the state “speedup” OR “slow” does not matter. This transition takes the system from either state to “stop”. Note that the transition labeled “apply accelerator” from state “stop” to the outside of state “move” seems ambiguous. However, the internal default arrow attached to state “speedup” means the system enters state “speedup” (if the transition “apply accelerator” from outside state “move” is taken).

11/4/2015 COSC , Lecture AND-Decomposition: concurrency Is another way to reduce the number of states. Consider the two-process mutual exclusion problem: only one process is allowed in the critical section (C1, C2) at any given time.

11/4/2015 COSC , Lecture Statechart A of Mutex Solution N1,N2 T1,N2 C1,T2 N1,T2 C1,N2T1,T2 N1,C2 T1,C2 The first solution is a finite-state machine.

11/4/2015 COSC , Lecture Statechart B of Mutex Solution mutex n1 t1 c1 n2 t2 c2 P1 requests P2 requests P2 not in c2P1 not in c1 P1P2 The second solution applies AND-decomposition to reduce the number of states.

11/4/2015 COSC , Lecture Comments over the two specifications In the second specification, if the system is in the state “mutex”, then it must be in both states “process 1” and “process 2”. In the first specification, the initial entrance is to state “N1, N2”, whereas in the second specification, the unspecified entrance to “mutex” is solved by the default arrows to enter the pair “n1, n2”. Transitions in “process 1” and “process 2” take place concurrently as governed by the transition labels. Therefore, if “p1 requests” is true, then the system will be in state pair {t1, n2}. So “process 1” and “process 2” are called orthogonal state components obtained by AND-decomposition. Orthogonality feature can reduce the state-explosion problem.

11/4/2015 COSC , Lecture Delays and timeouts The event expression timeout(event, number) represents the event that happens right after the specified number of time units have passed since the occurrence of the specified event. In a real-time system, it is often required to specify that the system stays in state for a certain period of time. This can be done graphically by a box (i.e., state) with a squiggle (i.e., a resistor-like notation), and a numerical bound is specified next to it. The syntax for the duration specification is Δt 1 < Δt 2, where either Δt i may be omitted. A generic event stands for timeout(entered state, bound), where state is the source of the transition and bound is the specified bound.

11/4/2015 COSC , Lecture Condition and selection entrances To reduce the number of line drawings in a large entrance to substates of a superstate, Statecharts employ two connectives represented by a circle. The conditional connective C replaces two or more arrows from outside a state to this state’s substates. This is done by drawing one arrow from outside a state to the C-connective (a circle with a C in it) and then drawing arrows from the connective to their respective substates. The selection connective S also replaces two or more arrows from outside a state to this state’s substates. Here, the state to be entered is selected by the value of a generic event and this value is one of the values labeling the substates.

11/4/2015 COSC , Lecture Condition and selection entrances. Example A robotic arm operator can move the robot arm “up”, “down”, “left”, “right”, “forward” or “backward” by pressing one of the corresponding six buttons. These six events can be modeled by six substates within a “move” state. There is an arrow enters the “move” state from outside this state to the S-connective (a circle with an ‘S’ in it), but no arrows need to be drawn from this connective to the six states.

11/4/2015 COSC , Lecture Un-clustering If the Statechart description is large, we can uncluster it by keeping the parts of interest large. This is done by drawing parts of the Statechart outside of their natural boundaries. This technique is useful for describing a large system. However, unclustering should not be used often since it can create a tree-like structure.

11/4/2015 COSC , Lecture Semantics At the time of its development, Statecharts were only a specification language with no underlying basis for formal analysis or verification. It was not associated with any logics or algebras, and hence was often regarded as a semi-formal specification language. Later, [Harel, Naamad; 1996] presented a semantics for Statecharts. The behaviour of a Statechart can be defined by a simulation of the sequence of steps allowed.

11/4/2015 COSC , Lecture Semantics (cont) The start of a step can be triggered by one or more events. Given the current state, we select a maximal set of compound transitions to fire from the currently enabled set of transitions. A compound transition is a sequence of enabled and thus executable transitions. All the executions of a step or transition are performed in parallel. Statecharts use the instantaneous broadcasting of events as the communication mechanism among states at any level.

11/4/2015 COSC , Lecture Activity-charts The language activity-charts describes the functional decomposition of a system. It is a conceptual modeling language which graphically shows activities or functions with rectilinear shapes. Solid arrows indicate the flow of data items whereas dashed arrows represent the flow of control items. Basic (or atomic) activities cannot be decomposed into lower-level activities and may be described as code in a programming language such as C. An activity takes in input items and produces output items while it is active.

11/4/2015 COSC , Lecture Activity-charts (cont) Data-stores represent buffers where databases or data structures can be stored in an activity. Control activities appear as empty boxes in an activity chart and show the behavioral view of the system. A control activity can control other related activities by sensing their statuses and giving commands to them. The language of Statecharts is used to describe the contents of these control activities.

11/4/2015 COSC , Lecture Module-charts The language module-charts describes the system modules (the physical components), the environment modules (external to the system), and the flow of data and control signals among these modules. Therefore, module-charts provide a structural view of the system. Rectilinear shapes denote modules and rectangles with dashed lines signify storage modules. Environment modules are also represented by rectangles with dashed lines but they are outside the specified system.

11/4/2015 COSC , Lecture Module-charts (cont) As in the states in Statecharts, sub-modules in module-charts may appear inside a module and several levels of encapsulation may exist. Labeled arrows and hyper-arrows represent the flow of information between modules. Example: module-chart of a simplified car  CAR is the main component, which is decomposed into several sub-modules, two of which are brake-system and engine-system.  The brake-system module is further decomposed into 3 sub- modules: signal processor, anti-lock braking unit, normal- braking unit.  The brake-pedal, hand-brake, accelerator, and wheel- sensors are treated as external or environment modules.

11/4/2015 COSC , Lecture Module-chart of a simplified car  Figure 5.5 from [Cheng; 2005], page 141

11/4/2015 COSC , Lecture Statemate Is a commercial specification tool for the designer to specify a system under development (SUD). The tool consists of the three graphical modeling languages (Statecharts, activity-charts, module- charts) and the forms language. The forms language allows the designer to enter this information for specific elements of the specification. This information includes the actions associated with the entrance to and exit from a state, the type/structure of data items, and the definitions of compound events and conditions.

11/4/2015 COSC , Lecture The forms language. Example The form for a data item has fields for name, synonym, description, definition, “consists of”, “attribute name”, and “attribute value”. The “consists of” field is used to structure data items into components, and the “attribute value” field is used to associate the attributes with the data items.

11/4/2015 COSC , Lecture Available tools As a commercial product, STATEMATE has been used for more applications than experimental specification and analysis tools. One of the first and most notable and widely publicized application was the mission specific avionics system for the Israel Aircraft Industries’ Lavi fighter aircraft. Part of the avionics system is specified in Statecharts. Other published applications include cruise control, processing modeling, and communication protocols. More details about STATEMATE can be found at (MAGNUM – for embedded systems; Rhapsody – based on UML).

11/4/2015 COSC , Lecture Summary Visual formalism, statecharts, and STATEMATE  Visual formalism and STATEMATE

11/4/2015 COSC , Lecture Reading suggestions Chapter 5 of [Cheng; 2002]

11/4/2015 COSC , Lecture Coming up next Final Exam:  Chapters 1, 2, 3, 4, 5, and 6 of [Cheng; 2002]  Chapters 1, 3, 10, and 11 of [Kopetz; 1997]  Chapters 1 and 2 of [Stankovic, Spuri, Ramamritham, Buttazzo; 1998]  Chapter 10 of [Priestley; 2004]  Chapters 4 and 6 of [Huth and Ryan; 2004]

11/4/2015 COSC , Lecture Thank you for your attention! Questions?