A Classification of Model Checking-based Verification Approaches for Software Models Petra Brosch, Sebastian Gabmeyer, Martina Seidl Sebastian Gabmeyer Business Informatics Group Institute of Software Technology and Interactive Systems Vienna University of Technology Favoritenstraße 9-11/188-3, 1040 Vienna, Austria phone: +43 (1) 58801-18804 (secretary), fax: +43 (1) 58801-18896 office@big.tuwien.ac.at, www.big.tuwien.ac.at
Background Motivation Why are we doing this? Existing Surveys focus on model transformations Broaden Scope: Verification approaches for software models Software models = formal, abstract representation of software Actually: plethora of different verification approaches > 70 different papers Points of Interest Influences from techniques used to verify hardware & software Any new techniques? Successful in practice? Difficult due to availability of tools Open research questions
Contributions Classification of Verification Approaches for Software Models Restricted to Model Checking based approaches 1. Feature Model (in the style of Czarnecki and Helsen) Advantages: flexible, sufficiently expressive, easily extensible 2. Classification of five verification approaches Two of which I will discuss during the presentation 3
Feature Model Main Features 1. Verification Goal Aim of the verification, e.g., inter-model consistency 2. Verification Technique Model Checking, Theorem Proving, Static Analysis 3. Specification Language Formalism used to define interesting properties of the system 4. Domain Representation Representation used by the user to create the software models 5. Verification Representation Representation used to verify the software models 4
Verification Goal Goals Consistency Intra-model vs. Inter-model Translation Correctness Source/Target Correctness Transformation Correctness Behavioral Correctness Specified by Operation Contracts Specified by Transformations 5
Consistency Verification Goal Intra-Model Consistency Example: 1. 1x Metamodel 2. 1x Set of Constraints (e.g.: OCL) Q: Does there exist an instance model conforming to the metamodel that satisfies all the constraints? Inter-Model Consistency Example: 1. 1x Model being the Specification 2. 1 Model being the Implementation Q: Is the implementation consistent with the specification? 6
Translation Correctness Verification Goal Goal: Assert that Model A is translated correctly into Model B Source/Target Correctness Q: Is the Target a correct image of the Source? Example Narayanan et al.: State Charts to Extended Hybrid Automata: verify if all states reachable in the SC are reachable in the EHA Transformation Correctness Q: Does the Transformation produce a correct Model B? Does the Transformation terminate? Is the Transformation confluent? Example Buettner et al.: Verify an ATL transformation by analyzing its trace model within Alloy 7
Behavioral Correctness Verification Goal Goal: Does the software described by a model behave as specified? Examples: Dining Philosophers Model: Philosopher + Table + Forks Specify: Every philosopher will eat some time Users printing over a shared printer Model: User + Printer Specify: No two users can print at the same time Behavior can be described either by Operation contracts consist of pre and post conditions Transformations (usually) consist of a LHS and a RHS 8
Verification Technique Theorem Proving Interactive: Guided by the modeler Automatic: CSP, SAT (modulo theories) Static Analysis Sound over-approximation of the real system Example: Constant Propagation Model Checking Automatic, exhaustive testing of all possible states of the implementation int a,b = 100; int t = 0; while (a > 0) do a := a 1; Representation if (a < 51) then t := a; a := b; b := t; fi od States are triples of <a,b,t> Init: <100,100,0> <99,100,0>,, <50,100,0>, <50,100,50>, <100,100,50>, <100,50,50>,, <0,50,50> Does the implementation S satisfy the specification φ, S = φ? φ = Is the state <50,50,50> reachable? 9
Idea behind Model Checking Verification by Model Checking Generate the state space: 1. Initialize the state space to the initial model 2. Apply all applicable transformations currently in the state space 3. Repeat Step 2 until no more states are added to the state space Then: Check if the specification holds in S, e.g., EG φ φ φ φ φ 10
Model Checking Verification Technique Distinguish approaches by State Space Representation: Enumerative vs. Symbolic Property Types Reachability: Can we reach a state from the initial state s.t. property P holds? Safety: Nothing bad happens, e.g., No two users print at the same time Liveness: Something good will eventually happen, e.g., Every philosopher will eat some time 11
Specification Language A property specifies desirable/undesirable system states First Order Logic Temporal Logic: LTL, CTL, CTL*, From every state it is possible to return to the initial state Rewriting Logic search <P : Philosopher state : thinking> =>1 <Q : Philosopher _> Automata There exists a trace to a state such that b always holds OCL 12
Domain Representation Domain Representation used by the modeler Graphs OMG-related: MOF (Ecore), UML, QVT, OCL DSLs, e.g., ATL+Ecore 13
Verification Representation Verification Representation used by the verification engine Algebraic Terms Transition Systems LTS, GTS, Petri Nets Relations & First -Order Logic 14
The Complete Feature Model 15
GROOVE Verifies the behavioral correctness of OO systems Based on Graph Transformation Theory Uses its own Model Checker State Space: User provides initial model User provides a set of transformations that define the behavior GROOVE builds the state space by applying the transformations to the initial graph then: applies the transformations to all resulting graphs stops when no more graphs can be added (or keeps on going indefinitely) Each graph represents a state Each transition corresponds to the application of graph transformation Result: Graph Transition System (GTS) Allows CTL formulas: safety & liveness 16
Classifying GROOVE Verification Goal Verification Technique Behavioral Correctness Model Checking Specification Language Temporal Logic CTL Domain Representation Verification Representation Graphs (Graph) Transition System Behavior specified by Transformation Enumerative Reachability, Safety, Liveness 17
HUGO Verifies the consistency between multiple UML State Charts and Sequence Diagrams SDs = Specification SCs = Implementation Derive Interaction Automaton from SDs Message Traces Uses SPIN model checker Translate Interaction Automaton and SCs into Promela Verifies safety properties Specified by LTL 18
Classifying HUGO Verification Goal Consistency Inter-Model Verification Technique Model Checking Specification Language Temporal Logic LTL Domain Representation Verification Representation UML Linear Transition System Enumerative Safety 19
Conclusion Survey of Verification Approaches for Software Models Feature Model Verification Goal Verification Technique: restricted to Model Checking Specification Language Domain Representation Verification Representation Classification of existing approaches Ongoing Work 20
Questions? 21
Thank you for attention! Visit our website at www.modelevolution.org 22