Ingegneria del Software II academic year: Course Web-site: [

Transcription

1 Course: Ingegneria del Software II academic year: Course Web-site: [ USING MODEL-CHECKING TECHNIQUES FOR ARCHITECTURE ANALYSIS AND FORMAL PROTOTYPING Lecturer: Henry Muccini and Vittorio Cortellessa Computer Science Department University of L'Aquila -Italy [ [

2 Copyright Notice» The material in these slides may be freely reproduced and distributed, partially or totally, as far as an explicit reference or acknowledge to the material author is preserved. Henry Muccini 2

3 Acknowledgment» This work is joined with Patrizio Pelliccione and Paola Inverardi, University of L Aquila.» The Charmy Website is available online: 3

4 Agenda» Model-Checking» Charmy» SPIN 4

5 Model Checking» Used in studying behaviors of reactive systems» Typically involves three steps: - Create a finite state model (FSM) of the system design - Specify critical correctness properties - Validate the model w/r to the specifications 5

6 Create a FSM» FSM languages - focus on expressing concurrency, synchronization, and communication - abstract details of internal computations - must be precise and unambiguous (formally defined syntax and semantics)» We will use Promela for giving system descriptions 6

7 Specify correctness properties» Safety properties: - Nothing bad ever happens > Formalized using state invariants - execution never reaches a bad state» Liveness properties: - Something good eventually happens > Formalized using temporal logic - special logic for describing sequences 7

8 Validate the model» Execute the model to test it - simulate executions of the system - check satisfaction of safety properties along simulated executions» Exhaustive analysis - generate reachability graph to verify safety and liveness properties» Generate counterexamples to illustrate failures 8

9 Model Checking and Design Validation Simulation (abstract model) & Testing (real system) These techniques explore only some of the possible behaviors Formal Verifications: Conduct an exhaustive exploration of all possible behaviors Examples: theorem provers, termrewriting systems, proof checkers forverification, model checkers Model Checker advantages: Automatic, no supervision or mathematical expertise (for analysis) In the case of fail the process of Model Checking produce a counter-example 9

10 Model Checker Model Checker Specifications Model Checker Input Internal representation Model Checking Algorithm True or false with counter-example Internal representation: Properties Properties feedback 10

11 Model-Checking limitation and solutions» State Explosion Problem» Solutions: - Compress > BDDs (Binary Decision Diagrams) [Bryant 1986] - Reduce 11 > Partial-Order Reduction - Explores only relevant portions of the state space - Idea: usually the validity of a search is independent from the order of intearleaving of concurrent events

12 Model Checker: BDDs 12

13 Model Checker: altre soluzioni allo state explosion» Compositional reasoning Idea: sarebbe interessante poter scomporre la proprieta in sottoproprieta che possono essere verificate su scomposizioni del sistema. Per farlo sono necessarie delle assunzioni sull ambiente:» Abstraction > Assume-guaranteeparadigm - Cone of influence reduction: > Idea: eliminarele variabili chenon interessano - Data abstraction > Idea: sostituirele variabili attuali con dellevariabili astratte 13

14 Model Checker: altre soluzioni allo state explosion» Symmetry Idea: sistemi a stati finiti concorrenti frequentemente hanno componenti replicate. Questo puo essere usato per ottenere un modello ridotto del sistema.» Induction Idea: cercare di raggruppare sistemi a stati finiti in famiglie tali da soddisfare delle proprieta invarianti. In questo modo si puo testare l invarianteper tutti i membri della famiglia. 14

15 Charmy 15

16 Outline» The Context and Motivations - Who are we - Software Architecture (SA) - Charmyoutline» Our proposal - Model Checking 16 - Charmy

17 Charmy Outline» Charmy: - CHeching ARchitectural Models ConsistencY» Initial Goal: - Validate consistency among scenarios and state machines...!ch3?ch1!ch1!ch2?ch2 17 Component P Component Q

18 Subsequent goals Multiple view SA: [ASE01] State machines and scenariosare the most common usedtools to model behavioralaspects; Some view modeledbydifferent models -> inconsistency?; Requirementsand SA: [Straw01] state diagrams are usedtomodel the system dynamics; scenariosare usedtoformalizerequirements. Comparing SAs: [FIDJI02] 18 state machines model different architecturesfor the samesystem; scenariosmodel the behavioral propertiesweare interested the architecturemeets.

19 The Charmy goal 19

20 CHARMY ( SA spec properties Step2 Step1 20 Automatically generated Step3

21 Example» The TC Chain example in TERMA Gmbh» The Siemens CNX models» The compositional reasoning study» 21

22 Challenge 1 : informal but formal» Formal ADLs + Automatic analysis - Time, cost and skills» Informal or Semi-Formal description + Faster and easier - Low automation» Charmy: - model-based specifications used to specify the SA topology and behavior 22 - a formal Promelaprototype is automatically generated

23 Challenge 2 : incremental analysis» SA-based software process: - It is not clear how to incrementally identify and analyze components and connectors - Refinement and Analysis - Goal: > To identify a way to detect faulty components that can be successively refined and analyzed again» Charmy: - An high-level architecture is analyzed; 23 - Faulty components are refined and re-analyzed

24 Challenge 3 : Automation» To generate Promelaspecification automatically from model-based specifications» Goal: to help the industry to meet model checking and formal analysis» Charmy: - A tool is under development 24

25 Summarizing» Model-checking analysis without formal specification knowlege» Incremental analysis of refined components» Deadlock, liveness, inconsistency, incompleteness detected at the architecture level» Testing and Model-checking of Software Architecture 25

26 SPIN The selected Model Checker [Bell Labs 1980] The specification language is Promela (PROcessMEta LAnguage) The properties can be expressed using the temporal logic LTL (Lineartime Temporal Logic) Features: on-the-fly verification i.e. it no need to construct a global state graph as a prerequisite for the verification random, interactive e guided simulations 26 partial order reduction techniques, and (optionally) BDD-like storage techniques to optimize the verification runs

27 SPIN: Promela Promela supports the not-determinism A Promela program consists of: Processes Communication channels Variables Concurrent processes communication: Shared memory Buffered channels (asynchronous communication) 0 dimension channels (rendez-vouscommunication) 27

28 CHARMY» Iterative process» Tool support: - offers a graphical user interface to draw state diagrams and scenarios - a plugin which allows to input existing diagram in the XMI format 28 - a translation engine to automatically derive Promela code and Buchi Automaton

29 CHARMY ( Step2 Step1 29 Step3

30 Step 1: Promela code Each components state diagram is translated in a Promela process, proctype A special process connector is added to manipulate the communication between the components The translation maintain the connectors only for the complex communications Synchronous /Asynchronous communications are realized with Promelaprimitives Component transparency to connectors Q!ch1 Ch1Connector OP()?ch1 P 30

31 Step 1: Promela code proctype Componente1() { s0: <state description>;goto si ;.. sn: a?ch1!ch2 b c Statecharts!ch1 x?ch2 y }.. <state description>;goto sj ; proctype ComponenteM () { } 31 { } proctype Connettore()

32 Step 1: Promela code Basic <state description>: messages exchange Expressing power: After m1 eventually m2 message Invalid end-states Unreachable code Invariants Complete <state description>: messages exchange + stored the exchange time Generated states 8 states for the basic 15 states for the complete Expressing power: All basic verifications The message is exchanged at the time t Message ordered punctually Used principally for the negative scenarios 9684 states for the basic states for the complete 32

33 Step2: LTL Formula Algorithm: To analyze the message order in the scenario To analyze the arrows type (synchronous, asynchronous, ) To identify when a send or receive action is performed over each channel To generate an LTL formula containing the same message order 33

34 Step2: LTL formula Other information used: The only allowed actions are expressed in the scenario: Strict check It is allowed only with the Complete translation algorithm Also other actions not expressed in the scenario are allowed: Loose check These checks type are embedded in the LTL formula. To define theltl formula we are interested in, we need information not expressed in the scenarios 34

35 Step3: SPIN Is the temporal order described in the scenarios satisfied by some paths in the model generated from SPIN? Two verifications type: 1. Exist at least one behavior satisfying the LTL formula 2. All architectural paths are conform with the selected scenario 35

36 Summarizing the parameters EXIST» Frequency: High STRICT» Use: negative scenarios LOOSE» Frequency: Very High» Use: negative scenarios» Algorithm: Complete» Algorithm: Basic FOR ALL Do not sound» Frequency: Very High» Use: Properties that the system must satisfy 36» Algorithm: Basic

37 Tool Support 37

38 Case Studies NICE (Naval Integrated Communication Environment) [FME03] Work developed with Marconi-Selenia -L Aquila Found malfunctioning caused by message loosing Cometa [MasterThesis] Extension to the mobility for Siena, a publish/subscribe middleware Analyzed two solutions in order to select the better AOJ2EE [FIDJI02] Active Object on J2EE reference implementation 38 Analyzed two solutions in order to select the better

39 Advantages» Model complexity and the state explosion reduction obtained by SA-level model checking;» Iterative approach: continuous refinement» Charmy easy to use, practical approach to modelchecking, hiding the modeling complexity;» Test specifications are identified from the architectural model (not from requirements) - Easiest alignment between SA and Test specifications; - Easiest control of the design steps and evolution 39

40 Future work (1/2) Possible solution at the state explosion problem Compositional reasoning Idea: it is interesting to decompose the system specification into properties that describe the behavior of a system's subset. To make it, we need of assumptions over the environment: Assume-guarantee paradigm Slicing-Abstraction Idea: to cut from the system behaviors not interesting for the verification More abstraction level zooming in the subparts Supported by the tool in the static architecture part 40

41 Future work (2/2) What formulas we can derive starting from the scenarios? Message Sequence Charts UML Sequence Diagrams Extensions Considering other properties Tool Introducing the time Increasing the usability Integrate the tool with other tools (ArgoUML, LTSA, ) 41 Integrated analysis

42 Some (of our) References [Straw01] P. Inverardi, H. Muccini and P. Pelliccione. "Checking consistency between architectural models using SPIN". In Proc. ICSE2001 Workshop ``From Software Requirements to Architectures" (STRAW'01), May [ASE2001] P. Inverardi, H. Muccini and P. Pelliccione. "Automated Check of Architectural Models Consistency using SPIN. In Proc. Automated Software Engineering conference, ASE2001, year 2001.» [PhDThesis] H. Muccini. Software Architecture for Testing, Coordination Models and Views Model Checking, PhD thesis, year 2002.» [FIDJI02] P. Inverardi, F. Mancinelli, H. Muccini, and P. Pelliccione. An Experience in Architectural Extensions: Active Objects in J2EE. In Proc. Int. Workshop on Scientific Engineering of Distributed Java Applications (FIDJI'2002), November 2002, Luxembourg. Lecture Notes in Computer Science (LNCS) 2604, pp. 87 ff.» [FME03] D.Compare, P. Inverardi, P. Pelliccione and A. Sebastiani. Integrating model-checking architectural analysis and validation in a real software life-cycle. In Proc. FM 2003: the 12th International FME Symposium, September 2003, Pisa. LNCS series.» [MasterThesis] M.Caporuscio. CoMETA -mobility support in the Siena publish/subscribe middleware. Master s thesis, Università degli Studi dell Aquila -Dipartimentodi Informatica, L Aquila- Italy, March 2002.» [ITB03] P. Inverardi, M. Tivoli, and A. Bucchiarone. Coordinators synthesis for COTSgroup-ware systems: an example. Published in DMC Also Technical Report, University of LAquila, Department of Computer Science, techrep.pdf, March