August Moscow meeting1August Moscow meeting1August Moscow meeting11 Deductive tools in insertion modeling verification A.Letichevsky INTAS Moscow August 2007

August Moscow meeting2August Moscow meeting2 Content August Moscow 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)

August Moscow meeting3August Moscow 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

August Moscow meeting4August Moscow meeting4August Moscow 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)

August Moscow meeting5August Moscow meeting5 Environment description August Moscow 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

August Moscow meeting6August Moscow meeting6August Moscow 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

August Moscow meeting7 Basic protocols August Moscow 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

August Moscow meeting8 Semantics of BPSL August Moscow 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.

August Moscow meeting9 Partially sequential composition Canonical form of behaviors

August Moscow 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).

August Moscow meeting11 Abstraction relation on states more abstract: Attributed transition systems with the same attribute labeling and validity

August Moscow meeting12 Abstraction relation on systems s's' t't' st a a a s's' t't' st a inverse direct Preserve initial states

August Moscow meeting13 Predicate transformers for abstract implementations State and precondition were valid before Only attributes in precondition can change values Postcondition with assignments

August Moscow 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

August Moscow 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

August Moscow meeting16 Inductive proving of safety safety and precondition were valid before Safety will be valid after

August Moscow 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

August Moscow 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.)