1. August 27-29 2007Moscow meeting1August 27-29 2007Moscow meeting1August 27-29 2007Moscow meeting11 Deductive tools in insertion modeling verification A.Letichevsky INTAS Moscow 27-29 August 2007

2. August 27-29 2007Moscow meeting2August 27-29 2007Moscow meeting2 Content August 27-29 2007Moscow meeting2 1.Specification languages 2.Static requirements checking 3.Trace generation New results in semantics of BPSL New predicate transformers for inductive proving New results in tools development Insertion modeling: Cybernetics and system Analyses 4, 2005 (Specification of systems by means of basic protocols)

3. August 27-29 2007Moscow meeting3August 27-29 2007Moscow meeting3 Specification languages Basic Protocol Specification Language (BPSL) is the main SL of insertion modeling Other languages used for industrial projects –UML –SDL –MSC Translation to BPSL (presentation of S.Potienko) Process language semantics

4. August 27-29 2007Moscow meeting4August 27-29 2007Moscow meeting4August 27-29 2007Moscow meeting44 Basic Protocol Specifications Environment description (structural requirements) Defines the signature and axioms of Basic Language, (first order logic language used for the description of local properties of a system) environment, and agent attributes The set of Basic Protocols (local requirements) Define the transitions of environment with inserted agents Global requirements Define the properties of a system in terms of temporal logic (mostly safety and liveness)

5. August 27-29 2007Moscow meeting5August 27-29 2007Moscow meeting5 Environment description August 27-29 2007Moscow meeting5 Types: Data types simple: int, real, Bool, intervals, enumerated, symbolic (free terms), agent behaviors (process algebra), ADT lists: list (m) of τ object types : functional: (arrays are considered as functional types) Agent types: defined by the set of typed agent attributes Environment attributes: used as functional symbols (simple, lists, and objects = arity 0) Agent attributes: typed names Instances: (for MSC as processes in BPs) Axioms: formulas without attributes (ADT) Rewriting rule systems: equations as in APS (ADT and normal forms) Initial states: formula of basic language or concrete state

6. August 27-29 2007Moscow meeting6August 27-29 2007Moscow meeting6August 27-29 2007Moscow meeting666 Basic protocol is a process with pre- and postconditions Phone n Network phone(n,idle) phone(n, dial) offhook n dialtone n Phone m Phone n Network phone(m,dial) dial(m,n) phone(m, dial n) call setup initial call setup dialing 1 Precondition Postcondition

7. August 27-29 2007Moscow meeting7 Basic protocols August 27-29 2007Moscow meeting7 Algebraic representation: x – list of typed parameters, P – process, and are pre- and postconditions. Preconditions: 1-st order formula with the following literals: State assumptions (like phone(m, idle)) Linear inequalities for numeric Equalities for symbolic Boolean attribute expressions Postconditions: 1-st order formula as in precondition Assignments x:=y considered as statements x´=y Updating lists

8. August 27-29 2007Moscow meeting8 Semantics of BPSL August 27-29 2007Moscow meeting8 Defined by the notion of implementation: Attributed transition system with validity relation s|=α,… such that for each BP and its instantiation (direct implementation) (inverse implementation) For each finite MSC C such that (permutability relation on actions and partially sequential composition of processes). Concrete implementations: interpretation of signature and initial states are fixed as well as deterministic transitions, validity is computed from attribute valuations. Abstract implementations: interpretation of signature and initial states are not fixed, validity is inferenced from the states labeling.

9. August 27-29 2007Moscow meeting9 Partially sequential composition Canonical form of behaviors

10. August 27-29 2007Moscow meeting10 Some results on abstractions A class of concrete implementations Concr(P) is defined and proved to be direct and inverse implementations of consistent BPS P. Two classes Adir(P) and Ainv(P) of direct and inverse abstract implementations has been defined and proved to be implementations of consistent BPS P. Each abstract implementation is an abstraction of some concrete one. There exist the most abstract implementation (is an abstraction of all concrete implementations).

11. August 27-29 2007Moscow meeting11 Abstraction relation on states more abstract: Attributed transition systems with the same attribute labeling and validity

12. August 27-29 2007Moscow meeting12 Abstraction relation on systems s's' t't' st a a a s's' t't' st a inverse direct Preserve initial states

13. August 27-29 2007Moscow meeting13 Predicate transformers for abstract implementations State and precondition were valid before Only attributes in precondition can change values Postcondition with assignments

14. August 27-29 2007Moscow meeting14 Tools for static and dynamic requirements checking The applications of BPSL VRS Verification of Requirement Specifications a tool developed for Motorola Formalizing requirements Experience in Telecommunications, Telematics and other application domains (projects for Motorola) Formal description of MPI library (projects for Intel) Generating tests from requirement specifications

15. August 27-29 2007Moscow meeting15 Static requirements checking Proving consistency and completeness Proving safety Computing invariants Preconditions for BPs (with the same external actions) must not intersect Disjunction of preconditions is valid

16. August 27-29 2007Moscow meeting16 Inductive proving of safety safety and precondition were valid before Safety will be valid after

17. August 27-29 2007Moscow meeting17 Dynamic requirements checking Concrete trace generator –Generating traces and checking properties for concrete models Symbolic trace generator –Generating traces and checking properties for abstract models Checking safety and reachability Generating tests for given coverage criteria More details in presentation of Letichevsky Jr

18. August 27-29 2007Moscow meeting18 Symbolic trace generation Checking applicability of protocol –Satisfiability of current state and precondition –Proving existential formula Computing predicate transformer –Proving predicate transformer formula Combining numeric and symbolic constraints Using data structures (arrays, lists etc.)