Lecture 6 Template Semantics CS6133 Fall 2011 Software Specification and Verification.

Slides:



Advertisements
Similar presentations
Embedded System, A Brief Introduction
Advertisements

Formal Methods in Software Engineering
UML Statechart semantics Speaker: Fei Mo Tutor: Priv.-Doz. Dr. Thomas Noll Lehrstuhl für Informatik 2 RWTH Aachen SS 07.
Models of Concurrency Manna, Pnueli.
Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
Architecture Representation
Week 6Fall 2001 CS5991 The STATEMATE Semantics of Statecharts D. Harel and A. Naamand Ahmad Alsawi 1-4 Bob Chen 5-8 Dapeng Xie 9-11.
Formal Modelling of Reactive Agents as an aggregation of Simple Behaviours P.Kefalas Dept. of Computer Science 13 Tsimiski Str Thessaloniki Greece.
UPPAAL Introduction Chien-Liang Chen.
CS 290C: Formal Models for Web Software Lecture 4: Implementing and Verifying Statecharts Specifications Using the Spin Model Checker Instructor: Tevfik.
Timed Automata.
Presented by: Thabet Kacem Spring Outline Contributions Introduction Proposed Approach Related Work Reconception of ADLs XTEAM Tool Chain Discussion.
Model Checking. Used in studying behaviors of reactive systems Typically involves three steps: Create a finite state model (FSM) of the system design.
CS189A/172 - Winter 2008 Lecture 7: Software Specification, Architecture Specification.
Software Engineering, COMP201 Slide 1 Protocol Engineering Protocol Specification using CFSM model Lecture 30.
Models of Computation for Embedded System Design Alvise Bonivento.
Specification Formalisms Book: Chapter 5. Properties of formalisms Formal. Unique interpretation. Intuitive. Simple to understand (visual). Succinct.
Modeling State-Dependent Objects Using Colored Petri Nets
1 CS/CPE 426 Senior Projects Chapter 21: State Machines Chapter 22:Advanced State Machines [Arlow and Neustadt 2005] March 24, 2009.
CS 290C: Formal Models for Web Software Lecture 6: Model Driven Development for Web Software with WebML Instructor: Tevfik Bultan.
CS 290C: Formal Models for Web Software Lecture 2: Modeling States with Statecharts Instructor: Tevfik Bultan.
1 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
Chapter 10: Architectural Design
02/06/05 “Investigating a Finite–State Machine Notation for Discrete–Event Systems” Nikolay Stoimenov.
Formal Methods 1. Software Engineering and Formal Methods  Every software engineering methodology is based on a recommended development process  proceeding.
Cheng/Dillon-Software Engineering: Formal Methods Model Checking.
PROGRAMMING LANGUAGES The Study of Programming Languages.
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.
Introduction to Software Testing Chapter 9.4 Model-Based Grammars Paul Ammann & Jeff Offutt
Requirements Expression and Modelling
Mapping Specification Notations to Analysis Tools
Compositional IS Development Framework Application Domain Application Domain Pre-existing components, legacy systems Extended for CD (ontologies) OAD Methods.
The Architecture of Secure Systems Jim Alves-Foss Laboratory for Applied Logic Department of Computer Science University of Idaho By, Nagaashwini Katta.
Mathematical Modeling and Formal Specification Languages CIS 376 Bruce R. Maxim UM-Dearborn.
Introduction to Formal Methods Based on Jeannette M. Wing. A Specifier's Introduction to Formal Methods. IEEE Computer, 23(9):8-24, September,
- 1 - Embedded Systems - SDL Some general properties of languages 1. Synchronous vs. asynchronous languages Description of several processes in many languages.
CS6133 Software Specification and Verification
StateCharts Peter Marwedel Informatik 12 Univ. Dortmund Germany.
Microsoft Research, Foundations of Software EngineeringW. Grieskamp et. al: Behavioral Compositions in Symbolic Domains Behavioral Composition in Symbolic.
Ch. 2. Specification and Modeling 2.1 Requirements Describe requirements and approaches for specifying and modeling embedded systems. Specification for.
Lecture51 Timed Automata II CS 5270 Lecture 5.
An Ontological Framework for Web Service Processes By Claus Pahl and Ronan Barrett.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Fall 2004EE 3563 Digital Systems Design EE 3563 VHSIC Hardware Description Language  Required Reading: –These Slides –VHDL Tutorial  Very High Speed.
Programming Languages and Design Lecture 3 Semantic Specifications of Programming Languages Instructor: Li Ma Department of Computer Science Texas Southern.
1 CSEP590 – Model Checking and Automated Verification Lecture outline for August 6, 2003.
Formal Methods.
CSCI1600: Embedded and Real Time Software Lecture 7: Modeling II: Discrete Systems Steven Reiss, Fall 2015.
CS3773 Software Engineering Lecture 06 UML State Machines.
CSCI1600: Embedded and Real Time Software Lecture 11: Modeling IV: Concurrency Steven Reiss, Fall 2015.
Course: COMS-E6125 Professor: Gail E. Kaiser Student: Shanghao Li (sl2967)
Duminda WijesekeraSWSE 623: Introduction1 Introduction to Formal and Semi- formal Methods Based on A Specifier's Introduction to Formal Methods (J. Wing)
High Performance Embedded Computing © 2007 Elsevier Chapter 1, part 3: Embedded Computing High Performance Embedded Computing Wayne Wolf.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Requirement Analysis SOFTWARE ENGINEERING. What are Requirements? Expression of desired behavior Deals with objects or entities, the states they can be.
CS223: Software Engineering
Software Systems Verification and Validation Laboratory Assignment 4 Model checking Assignment date: Lab 4 Delivery date: Lab 4, 5.
From Natural Language to LTL: Difficulties Capturing Natural Language Specification in Formal Languages for Automatic Analysis Elsa L Gunter NJIT.
CS5270 Lecture 41 Timed Automata I CS 5270 Lecture 4.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini VII. System Specification (I)
Understanding and Comparing Model-Based Specification Notations Jianwei Niu, Joanne Atlee, and Nancy Day University of Waterloo.
Formal methods: Lecture
Graph Coverage for Specifications CS 4501 / 6501 Software Testing
Graph Coverage for Specifications CS 4501 / 6501 Software Testing
Dynamic Modeling Lecture # 37.
Abstract Types Defined as Classes of Variables
Presentation transcript:

Lecture 6 Template Semantics CS6133 Fall 2011 Software Specification and Verification

2 Input Language to Formal Analysis Tools Input languages to many analysis tools are close to low-level computation models Kripke structures BDDs Automata Model in N’s Input Language Model Checker N Properties True or False (with Counterexamples) CS6133

3 Formal Specification Notations Specification notations describe systems’ behavior Process algebras, e.g., CCS, FSP State-based notations, e.g., statecharts Model-based notations are suitable and flexible for modeling large reactive systems Step semantics are intuitive for software practitioners Composition mechanisms provide facilities to represent concurrency, communication, and synchronization Specification errors can be easier and cheaper to fix in the early stages – using analysis tools CS6133

4 Analyzing Specification Notations Model in N’s Input Language Model Checker N Properties True or False (with Counterexamples) How to bridge the gap between specification notations and analysis tools ? Model in Specification Notation M CS6133

5 Current Approaches for Analyzing Specification Construct a specific tool for a specification notation [Cleaveland & Parrow & Steffen, Harel & Naamad] Properties True or False (with Counterexamples) Model in Specification Notation M Model in N’s Input Language Model Checker N Model Checker for Notation M CS6133

6 Current Approaches for Analyzing Specifications Write a translator from a notation to the input language of an analyzer [Atlee & Gannon, Cheng et al., Chan et al.] Model in N’s Input Language Model Checker N Properties True or False (with Counterexamples) Model in Specification Notation M Translator From M to N CS6133

7 Semantics-Based Model Compilation [Day & Joyce, Dillion & Stirewalt, Pezze & Young] Model in N’s Input Language Model Checker N Properties True or False (with Counterexamples) Model in Specification Notation M Semantics for Notation M Model Compiler Transition Relation or Reachability Graph CS6133

8 Parameterized Semantics-Based Model Compilation Model in N’s Input Language Model Checker N Properties True or False (with Counterexamples) Model in Specification Notation M Model Compiler Transition Relation Common Template Semantics Semantics of M Given by Template Parameter Values CS6133

9 Template Semantics Template semantics A new approach to structure the semantics of model-based specification notations that captures the common behavior among notations and parameterizes their differences Separation of concerns among aspects of a notation’s semantics, e.g., step semantics, composition operators CS6133

10 Computation Model Hierarchical transition system (HTS) is a hierarchical, extended finite state machine without concurrency CS6133

11 Computation Model --- Syntax An HTS contains States and a state hierarchy Internal and external events Variables Transitions Example: CS6133

12 Semantics of HTS --- Snapshot Snapshot: observable point in execution Basic Elements current states current internal events current variable values current generated events Auxiliary Elements used to determine which transitions are enabled auxiliary states auxiliary internal events auxiliary variable values auxiliary external events CS6133

13 Common Semantics of HTS Behavior of an HTS is described by the possible execution steps it can take Which transition is enabled enabling states enabling events enabling variables How the HTS is affected by executing a transition Step relates the current snapshot and the next snapshot of an HTS CS6133

14 Micro-step: one transition execution Macro-step: a sequence of micro steps until the system is stable Step Semantics macro-step micro-step Input stable SS 0 SS 1 SS 2 CS6133

15 Three types of macro-steps Simple diligent: e.g., CCS take a micro-step if a transition is enabled Simple non-diligent: e.g., BTS take a micro-step or stay idle Stable: e.g., statecharts a maximal sequence of micro-steps until no enabled transitions for the set of inputs Step Semantics CS6133

16 Common Template Definitions Common semantics reset enabled transitions apply Template parameters  reset state info  reset event info  reset variable info  enabling states  enabling events  enabling variable values  change state  generate events  change variable values CS6133

17 Common Templates enabled_trans (ss,T): the subset of transitions in T that are enabled by snapshot ss’s states, events, and variable values  apply (ss, ,ss’): applying transition  ’s actions (variable assignments, generated events) to snapshot ss may produce snapshot ss’  micro-step (ss, ,ss’): transition  is enabled in snapshot ss, and its actions may produce next snapshot ss’  macro-step (ss,I, ss’): there is a sequence of micro-steps that starts from snapshot reset(ss,I) and ends the macro-step in snapshot ss’  reset (ss,I)=ss r : reseting snapshot ss at the start of a macro- step with inputs I produces snapshot ss r CS6133

18 current state current int_ev current var_val current output auxiliary state auxiliary int_ev auxiliary var_val auxiliary ext_ev en_states en_events en_cond RESET NEXT how reset at beginning of macro-step how changed when a transition is taken how used to enable a transition Template Parameters CS6133

19 current state CS current int_evIE current var_val AV current outputO auxiliary state CSa auxiliary int_evIE auxiliary var_valAVa auxiliary ext_evIa en_states en_events en_cond RESET NEXT how reset at beginning of macro-step how changed when a transition is taken how used to enable a transition Event-Related Template Parameters Enabling Events CS6133

20 Enabling Events Enabling internal events 1. Events generated since the beginning of the macro-step 2. Events generated in the previous micro-step Enabling external events 1. Events from the input are persistent through macro-step 2. Events from the input are enabling only at the first micro-step CS6133

21 Enabling Events Enabling internal events 1. Events generated since the beginning of the macro-step Enabling external events 1. Events from the input are persistent through macro-step SS 1  1 : e, ^a IE =  Ia = {e} trig(  ) = e SS 0 Input CS6133

22 Enabling Events Enabling internal events 1. Events generated since the beginning of the macro-step Enabling external events 1. Events from the input are persistent through macro-step SS 0 SS 2 SS 0 IE = {a} Ia = {e} trig(  ) = a  1 : e, ^a  2 : a IE =  Ia = {e} trig(  ) = e SS 1 Input CS6133

23 Enabling Events Enabling internal events 1. Events generated since the beginning of the macro-step Enabling external events 1. Events from the input are persistent through macro-step SS 0 SS 3 SS 0 IE = {a} Ia = {e} trig(  ) = a  1 : e, ^a  2 : a IE =  Ia = {e} trig(  ) = e SS 1 SS 2 IE = {a} Ia = {e} trig(  ) = e  3 : e Input CS6133

24 Enabling Events Enabling internal events 1. Events generated since the beginning of the macro-step Enabling external events 1. Events from the input are persistent through macro-step SS 0 IE = {a} Ia = {e} trig(  ) = a  1 : e, ^a  2 : a  3 : e IE =  Ia = {e} trig(  ) = e SS 1 SS 2 IE = {a} Ia = {e} trig(  ) = e IE = {a} Ia = {e} trig(  )  IE  Ia SS 3 Input CS6133

25 Enabling Events Enabling internal events 2. Events generated in the previous micro-step Enabling external events 2. Events from the input are enabling only at the first micro-step SS 1  1 : e, ^a IE =  Ia = {e} trig(  ) = e SS 0 Input CS6133

26 Enabling Events Enabling internal events 2. Events generated in the previous micro-step Enabling external events 2. Events from the input are enabling only at the first micro-step SS 2  1 : e, ^a IE =  Ia = {e} trig(  ) = e SS 0 IE = {a} Ia =  trig(  ) = a SS 1  2 : a Input CS6133

27 Enabling Events Enabling internal events 2. Events generated in the previous micro-step Enabling external events 2. Events from the input are enabling only at the first micro-step  1 : e, ^a IE =  Ia = {e} trig(  ) = {e} SS 0 IE = {a} Ia =  trig(  ) = {a} SS 1  2 : a IE =  Ia =  trig(  )  IE  Ia SS 2 Input CS6133

28 current state CS current int_evIE current var_val AV current outputO auxiliary state CSa auxiliary int_evIE auxiliary var_valAVa auxiliary ext_evIa en_states en_events en_cond RESET NEXT how reset at beginning of macro-step how changed when a transition is taken how used to enable a transition Template Parameters for STATEMATE Enabling Events  IE’ = gen(  ) n/a n/a Ia’ = ss.Ia Ia’ =  trig(  )  ss.IE  ss.Ia CS6133

29 Enabling States Current states States at the beginning of the macro-step SS 0 SS 1 SS 2 SS 3 SS 0 CS CSa en_states 11 22 33 CS6133

30 Enabling States Current states SS 0 SS 1 SS 2 SS 3 SS 0 CS = {P} CSa = {P} source(  1 )=P 11 en_states := source (  )  CS CS6133

31 Enabling States Current states SS 0 SS 2 SS 3 SS 0 CS = {P} CSa = {P} source(  1 )= P 11 22 CS = {Q} CSa =  source(  2 )=Q en_states := source (  )  CS SS 1 CS6133

32 Enabling States Current states SS 0 SS 1 SS 3 SS 0 CS = {P} CSa = {P} source(  1 )=P 11 22 33 CS = {Q} CSa =  source(  2 )=Q en_states := source (  )  CS CS = {R} CSa =  source(  3 )=R SS 2 CS6133

33 Enabling States Current states SS 0 SS 1 SS 2 SS 0 CS = {P} CSa = {P} source(  1 )= P 11 22 33 CS = {Q} CSa =  source(  2 )=Q en_states := source (  )  CS CS = {R} CSa =  source(  3 )=R CS = {S} CSa =  source  CS SS 3 CS6133

34 Enabling States States at the beginning of the macro-step SS 0 SS 1 SS 2 SS 3 SS 0 CS = {P} CSa = {P} source(  1 )=P 11 en_states := source (  )  CSa CS6133

35 Enabling States States at the beginning of the macro-step SS 0 CS = {P} CSa = {P} source(  1 )=P 11 CS = {Q} CSa =  source  CSa en_states := source (  )  CSa SS 1 CS6133

36 Compose multiple HTSs into a system, and represent Concurrency Communication Synchronization Constrain Which component to execute When to transfer control to each other How to exchange events and data Rely on template parameters to ensure their semantics are consistent with the step semantics Composition Operators CS6133

37 Composition Operators CP1 CP2CP3 CP4 HTS3 HTS1HTS2 HTS4 HTS5 CS6133

38 Parallel Interleaving Synchronization Environmental synchronization Rendezvous synchronization Interrupt Sequence Choice Composition Operators CS6133

39 Parallel Interleaving Synchronization Environmental synchronization Rendezvous synchronization Interrupt Sequence Choice Composition Operators CS6133

40 Parallel Composition Components execute in parallel CS6133

41 Parallel Composition Each component takes a transition if both are enabled simultaneously CS6133

42 Parallel Composition Enabled component executes in isolation CS6133

43 Environmental Synchronization x x y Components synchronize on an external synchronization event CS6133

44 Environmental Synchronization x x y x  syncEv Each component takes a transition if enabled by an external synchronization event CS6133

45 Environmental Synchronization x x y y  syncEv Components interleave CS6133

46 Interrupt Transfer control from one component to the other CS6133

47 Interrupt Interrupt transition has priority and executes CS6133

48 Interrupt The left component has priority and steps CS6133

49 Interrupt --- Formal Definition CS6133

50 Validation of Template Semantics Template semantics is Succinct Description of a notation is an instantiation of parameters Expressive CCS, CSP, LOTOS, statecharts variants, and BTS SCR, Petri Net, and SDL Extensible History states, negated events, and SDL timers Template semantics eases a user’s effort in understanding and comparing specification notations CS6133

51 Template Semantics for Notations Instantiate the template definitions to describe a modeling notation Specify the notation’s step semantics as a set of parameter values Map notation’s composition operators to pre-defined template composition operators CS6133

52 Comparing Statecharts Variants CS6133

53 : Parameterized Model Compiler CS6133

54 Template semantics forms the theoretical foundation for Parameterized template definitions represent common allowable execution steps of model-based notations Parameters describe a notation’s distinct semantics Composition operators, defined as a separate concern, constrain how multiple HTSs execute concurrently A notation’s semantics is expressed as a set of parameter values and composition operators : Parameterized Model Compiler CS6133

55 takes as input a specification and its template semantics description (a set of template- parameter values and composition operators) produces for a specification a transition relation, which can be used as an input to formal analysis tools (e. g., model checker) eases effort required for mapping multiple notations to analysis tools As a notation evolves, a user only needs to modify parameter values to reflect the notation’s changes : Parameterized Model Compiler CS6133

56 Summary Template semantics: structure a notation’s semantics Capture the common behaviors among notations and parameterizes their differences Separate concerns among aspects of a notation’s semantics Ease a specifier’s effort in understanding and comparing different model-based notations : map specification notations to analysis tools Compile a specification into a transition relation based on the template-semantics description of the notation Facilitate the transformation of new notations or notation variants to analysis tools CS6133