Mapping Specification Notations to Analysis Tools METRO Jianwei Niu jniu@uwaterloo.ca University of Waterloo

North Carolina State University Formal Methods Software engineering is about developing quality software in a predictable way Errors in critical software can cause loss of life Confidence in software can be obtained by using formal methods Formal methods are rigorous means for specification and verification Formal notations and powerful tools (e.g., model checkers) have been increasingly applied in modeling and reasoning about computer-based systems March 26, 2004 North Carolina State University

North Carolina State University Model Checker Model Checker X Spec in input language for X True or False with counter examples Properties March 26, 2004 North Carolina State University

Specification Notation Specification notations describe systems’ behavior Process algebras (e.g., CCS, LOTOS) State-based notations (e.g., statecharts) These notations are suitable and flexible modeling large reactive systems They are intuitive for software practitioners Their composition mechanisms provide facilities to represent concurrency and communication Formal requirements models can be automatically analyzed and requirement errors are easier and cheaper to fix at the requirement stage March 26, 2004 North Carolina State University

Current Approaches for Analyzing Specifications Construct a specific tool to analyze a specification written in a certain notation [Cleaveland & Parrow & Steffen, Harel & Naamad] Model Checker for Notation M Spec in Formal Notation M March 26, 2004 North Carolina State University

Current Approaches for Analyzing Specifications Write a translator from the notation to an existing analyzer [Atlee & Gannon, Avrunin & Corbett & Dillion, Chan et al.] Spec in Formal Notation M Translator from M to X Existing Model Checker (Notation X) March 26, 2004 North Carolina State University

Current Approaches for Analyzing Specifications The number of translators can be reduced for verifying specifications in different notations using different tools Problem for these approaches: semantics of notations is evolving over time Solution: generating analyzers directly from notations’ semantics [Day&Joyce, Dillion & Stirewalt, Pezze & Young] Current Approaches for Analyzing Specifications Develop an intermediate notation and translate to the input languages for different tools [Bensalem et al., Bozga et al., Bultan] Specification in Formal Notation M Existing Model Checker (Notation X) Intermediate Notation Specification in Formal Notation N Existing Model Checker (Notation Y) Specification in Formal Notation S March 26, 2004 North Carolina State University

Current Approaches for Analyzing Specifications Spec in Formal Notation M Semantics for Notation M Existing Model Checker (Notation X) Model Compiler Transition relation (e.g., Kripke structure) [Day & Joyce, Dillion & Stirewalt, Pezze & Young] March 26, 2004 North Carolina State University

A New Approach for Mapping Specification Notations to Analysis Tools Template semantics Specifics of M given by parameters Spec in Formal Notation M Existing Model Checker (Notation X) Common Semantics Model Compiler Transition relation (e.g., Kripke structure) March 26, 2004 North Carolina State University

North Carolina State University Outline of Talk Template Semantics Computation model Step semantics Template parameters Composition operators Template semantics for different notations Generating analysis tools from template semantics Model compiler Parameterized translator Conclusions and future work March 26, 2004 North Carolina State University

North Carolina State University Computation Model A hierarchical transition system (HTS) is a hierarchical, extended state machine without concurrency March 26, 2004 North Carolina State University

Computation Model --- Syntax An HTS contains States and a state hierarchy Internal and external events Variables Transitions March 26, 2004 North Carolina State University

Semantics of HTS --- Snapshot Snapshot: observable point in execution current states current internal events current variable values current generated events Basic Elements Auxiliary Elements used to determine which transitions are enabled auxiliary states auxiliary internal events auxiliary variable values auxiliary external events March 26, 2004 North Carolina State University

North Carolina State University 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 variable values How the HTS is affected by executing a transition Step relates the current snapshot and the next snapshot of an HTS March 26, 2004 North Carolina State University

North Carolina State University Step Semantics Micro-Step: one transition execution Macro-Step: a sequence of micro steps until the system is stable Input macro-step micro-step SS0 SS1 SS2 stable March 26, 2004 North Carolina State University

North Carolina State University Step Semantics Three types of macro-steps Simple diligent take a micro-step if a transition is enabled Simple non-diligent 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 March 26, 2004 North Carolina State University

North Carolina State University Template Semantics 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 March 26, 2004 North Carolina State University

Template Parameters how reset at how changed when a beginning of macro-step how changed when a transition is taken RESET NEXT current state current int_ev current var_val current output history state history int_ev history var_val history ext_ev en_states en_trig en_cond how used to enable a transition March 26, 2004 North Carolina State University

Template Parameters Enabling Events how reset at how changed when a beginning of macro-step how changed when a transition is taken RESET NEXT CS IE AV O CSa IEa AVa Ia en_states en_trig en_cond Enabling Events how used to enable a transition March 26, 2004 North Carolina State University

North Carolina State University 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 in the first micro-step March 26, 2004 North Carolina State University

North Carolina State University 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 Input 1: e /a SS0 SS1 IE = Ia = {e} trig() = e March 26, 2004 North Carolina State University

North Carolina State University 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 Input 1: e /a 2: a SS0 SS0 SS1 SS2 IE = Ia = {e} trig() = e IE = {a} Ia = {e} trig() = a March 26, 2004 North Carolina State University

North Carolina State University 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 Input 1: e /a 2: a 3: e SS0 SS0 SS1 SS2 SS3 IE = Ia = {e} trig() = e IE = {a} Ia = {e} trig() = a IE = {a} Ia = {e} trig() = e March 26, 2004 North Carolina State University

North Carolina State University 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 Input 1: e /a 2: a 3: e SS0 SS0 SS1 SS2 SS3 IE = Ia = {e} trig() = e IE = {a} Ia = {e} trig() = a IE = {a} Ia = {e} trig() = e IE = {a} Ia = {e} trig()  IE  Ia March 26, 2004 North Carolina State University

North Carolina State University Enabling Events Enabling internal events 2. Events generated in the previous micro-step Enabling external events 2. Events from the input are enabling only in the first micro-step Input 1: e /a SS0 SS1 IE =  Ia = {e} trig() = e March 26, 2004 North Carolina State University

North Carolina State University Enabling Events Enabling internal events 2. Events generated in the previous micro-step Enabling external events 2. Events from the input are enabling only in the first micro-step Input 1: e /a 2: a SS0 SS1 SS2 IE =  Ia = {e} trig() = e IE = {a} Ia =  trig() = a March 26, 2004 North Carolina State University

North Carolina State University Enabling Events Enabling internal events 2. Events generated in the previous micro-step Enabling external events 2. Events from the input are enabling only in the first micro-step Input 1: e /a 2: a SS0 SS1 SS2 IE =  Ia = {e} trig() = {e} IE = {a} Ia =  trig() = {a} IE =  Ia =  trig()  IE  Ia March 26, 2004 North Carolina State University

Template Parameters Enabling Events Enabling States how reset at beginning of macro-step how changed when a transition is taken RESET NEXT CS IE AV O CSa IEa AVa Ia en_states en_trig en_cond Enabling Events Enabling States how used to enable a transition March 26, 2004 North Carolina State University

North Carolina State University Outline of Talk Template Semantics Computation model Step semantics Template parameters Composition operators Template semantics for different notations Generating analysis tools from template semantics Model compiler Parameterized translator Conclusions and future work March 26, 2004 North Carolina State University

North Carolina State University Composition Operator CP1 CP2 CP3 CP4 HTS3 HTS4 HTS5 HTS1 HTS2 March 26, 2004 North Carolina State University

North Carolina State University Composition Operator Parallel Interleaving Synchronization Environmental synchronization Rendezvous synchronization Interrupt Sequence Choice March 26, 2004 North Carolina State University

North Carolina State University Composition Operator Parallel Interleaving Synchronization Environmental synchronization Rendezvous synchronization Interrupt Sequence Choice March 26, 2004 North Carolina State University

Parallel Composition Components execute in parallel March 26, 2004 North Carolina State University

Parallel Composition Each component takes a transition if both are enabled simultaneously March 26, 2004 North Carolina State University

Parallel Composition Enabled component executes in isolation March 26, 2004 North Carolina State University

Environmental Synchronization x x Components synchronize on an external synchronization event March 26, 2004 North Carolina State University

Environmental Synchronization x  syncEv x x Each component takes a transition if enabled by an external synchronization event March 26, 2004 North Carolina State University

Environmental Synchronization y  syncEv x x Components interleave March 26, 2004 North Carolina State University

Interrupt Transfer control from one component to the other. March 26, 2004 North Carolina State University

Interrupt Interrupt transition has priority and executes March 26, 2004 North Carolina State University

Interrupt The left component has priority and steps March 26, 2004 North Carolina State University

Composition Operators 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 parameters March 26, 2004 North Carolina State University

Interrupt --- Formal Definition March 26, 2004 North Carolina State University

North Carolina State University Validation Instantiate the template semantics Define parameters Choose composition operators Using our template semantics to describe the semantics for CCS, CSP, LOTOS, statecharts variants, and SDL Niu & Atlee & Day, FSE, 2002 Niu & Atlee & Day, TSE, 2003 March 26, 2004 North Carolina State University

North Carolina State University Validation Template semantics is expressive and succinct to represent different notations SCR, Petri Nets Template semantics eases users’ effort in comparing and understanding specification notations, such as variants of statecharts Harel’s, Pnueli & Shalev’s, RSML, STATEMATE Niu & Atlee & Day, RE, 2003 March 26, 2004 North Carolina State University

North Carolina State University Outline of Talk Template Semantics Computation model Step semantics Template parameters Composition operators Template semantics for different notations Generating analysis tools from template semantics Model compiler Parameterized translator Conclusions and future work March 26, 2004 North Carolina State University

North Carolina State University * METRO Map specification notations to analysis tools using template semantics Use template-based semantics to generate a transition-relation, which then can be used as an input to formal analysis tools * Metro is an environmentally friendly system for rapid transit between disparate places. By analogy, the template semantics approach aims to ease the transit between verification environments. March 26, 2004 North Carolina State University

METRO METRO Specifics of M given by parameters Spec in Formal Notation Existing Model Checker (Notation X) Common Semantics Model Compiler transition relation (e.g.,Kripke structure) March 26, 2004 North Carolina State University

North Carolina State University METRO Existing Model Checker X METRO Spec in Formal Notation M Specifics of M given by parameters Express . Common Semantics Existing Model Checker Y Lu & Atlee & Day & Niu., submitted for publication, 2004 March 26, 2004 North Carolina State University

North Carolina State University March 26, 2004 North Carolina State University

North Carolina State University March 26, 2004 North Carolina State University

North Carolina State University March 26, 2004 North Carolina State University

North Carolina State University March 26, 2004 North Carolina State University

North Carolina State University March 26, 2004 North Carolina State University

North Carolina State University Validation Use two case studies A single lane bridge A heating system Demonstrate model compiler: generating an analyzer from the template semantics description for a given notation Compare Express with model compiler METRO METRO March 26, 2004 North Carolina State University

Comparison Fusion MagicDraw XML S+ SMV comm template semantics Semantic parameters, Composition operators (expressed in logic) comm template semantics symbolic function eval transition relation model checker type checker BDD MagicDraw (with plugin) XML S+ XML S+ SMV optimized translation Semantic parameters, (selected from menus of values) transcription March 26, 2004 North Carolina State University

North Carolina State University Future Work Problem: integrate specifications in Multiple Notations Software practitioners tend to write specifications of different aspects of the system using different notations A framework to parameterize the composition operators while composing Different step semantics Different event languages Different data languages March 26, 2004 North Carolina State University

North Carolina State University Conclusions Template semantics is a new approach to structuring semantics of specification notations Capture common semantics and parameterize notation- specific behavior Define a notation’s execution semantics and composition operators as separate concerns Template semantics is effective and expressive for representing the semantics of many specification notations March 26, 2004 North Carolina State University

North Carolina State University Conclusions Key benefit a template semantics description of a notation can be used as an input to a tool for generating formal analysis tools Secondary benefit template semantics eases the specifiers’ effort in understanding and comparison of different notations March 26, 2004 North Carolina State University

North Carolina State University References Jianwei Niu, Joanne M. Atlee, and Nancy A. Day. "Composable Semantics for Model-Based Notations", Proc. of the 10th ACM SIGSOFT Int. Symp. on the Foundations of Soft. Eng. (FSE), pages 149-158, 2002 Jianwei Niu, Joanne M. Atlee, and Nancy A. Day. "Comparing and Understanding Model-Based Specification Notations", Proc. of the 11th IEEE Int. Requirements Eng. Conf. (RE), pages 188-199, 2003 Jianwei Niu, Joanne M. Atlee, and Nancy A. Day. "Template Semantics for Model-Based Notations", IEEE Transactions on Soft. Eng., vol. 29, no.10, pages 866-882, 2003 Yun Lu, Joanne M. Atlee, Nancy A. Day, and Jianwei Niu. “Model Checking Template-Semantics Specifications”, submitted for publication, 2004 March 26, 2004 North Carolina State University