Rigorous Software Development Concepts, Techniques and ...desousa/2012-2013/CF/RSD_chap2_tour.pdf · transformations Turing-equivalent Existing implementations: ASM Gopher, B Method

Rigorous Software DevelopmentConcepts, Techniques and Tools

A Short Tour

Simao Melo de Sousa

RELEASE (UBI), LIACC (Porto), CCTC (Minho)Computer Science Department

University of Beira Interior, Portugal

October 2011

S. Melo de Sousa (LIACC/DIUBI) Rigorous Software Development 2011 1 / 57

http://www.di.ubi.pt/~release

Outline

1 Preliminaries

2 A Guided Tour

3 Conclusion


Preliminaries

Table of Contents

1 Preliminaries

2 A Guided Tour

3 Conclusion


Preliminaries

A guided tour

What follows?

A guided tour organized by different layers of features:

Specification and analysis of models

Specification and demonstration of properties

Specification and derivation of models

Specification and transformation of models


Preliminaries

A first note: the actual picture

In the first place, why do we need ”an overview” of FM?

(1) As the term ”overview” suggests... The behavioural essence of ICS is notcaptured by a suitable and unified mathematical theory.

In fact, I do not believe that such a general foundation exists, hopefully.

(think about the variety of physics that are needed to successfully design andlaunch a space ship)

So, depending on the goals of the ICS designers and of the verificationprocess, one may prefer a theory over another one, or even may use severalFM theories and tools.

(2) worse ... even if the theory is fixed, several dialects and subsequent toolsmay exist (usually the case). (not enough maturity? absence of consensus?)

so, yes, FMs are a true Babel tower (for a good and a not so good reason).

That’s why drawing a map in this jungle can make some sense.


Preliminaries

A second note: Foundations of Modelling and Verification

At this point we should stress some central notions that are common to avast number of FM tools and techniques.

1 Transition systems (in its logical, relational or algebraical form):capture the operational essence of the modelled systems.

2 Program Logics, namely Hoare Logic: capture the behaviouralessence of the modelled system. Is at the foundations of a large partof FM techniques and tools.

These notions are omnipresent in the overview that follows


A Guided Tour

Table of Contents

1 Preliminaries

2 A Guided Tour

3 Conclusion


A Guided Tour

The main issue of FM - A reminder

Formal Methods intend to provide means to:

ensure that a given ICS has a given (adequate) behaviour

In practice: this central issue is divided into two sub-problems

evidences of behaviour: How to ensure/verify the expected behaviour atthe specification level.

model against code:

1 How to obtain, from a well behaved model, a programwith the same behaviour?

2 or, provided code and specification, how to ensure thatboth share the same behaviour/properties?


A Guided Tour Specification and Analysis

Specification and analysis

Underlying Principle

Formalisms/languages/tools for expressing models/specifications.

Immediate benefits

Formal languages = Rigorous and without ambiguities

require a detailed study and in-depth understanding of the modelledmechanisms (e.g. D. Syme, CISC/IBM);can be used as an Esperanto for the documentation andcommunication between the actors in the ICS design;



Specification and analysis

Underlying Principle

Formalisms/languages/tools for expressing models/specifications.

Immediate benefits

Formal languages = Rigorous and without ambiguities

If the formalisms is tool supported, the behaviour of the modelledsystem can be observed: prototyping.

Suitable framework for rigorous reasoning



Building Models / Specifications

Let’s take a look to the first FM sub-problem: defining and analysingmodels

Informal definition

Formal Specification: Formal definition of ”WHAT” is the systemunder development (in contrast with ”HOW”).

=⇒ result of the system analysis.



Building Models / Specifications

Approaches to Specification

Goal: give a clear (rigorous, mathematical) definition of the behaviour of thesystem under development.Two families of formal specification support. Emphasis in

the manipulated data. behaviour of the target system expressed by themanipulated data and the way they evolve or are related: AlgebraicSpecification or Axiomatic Specification.

the operations. The behaviour of the modelled system is expressed by itsoperations or available mechanisms (services) or actions that can beperformed.Focus: clear definition of the modifications/changes on an internal stateperformed by the operations of the ICS: State based or Model basedSpecification.

Orthogonally: sequential models vs. concurrent or distributed models (CSP, CCS,Process Algebra, Π− calculus, etc.) vs. temporal models (Synchronous Calculus,Duration Calculus, TCTL, etc. )



Model Based Specifications

Principles

Determine the notion of internal state for the target system and focus onthe description of how the operations of the system change the state.

Underlying mathematics

Discrete mathematics, set theory, category theory, logic.

Some formalisms and tools

Sequential: Z, VDM, B, Charity, Alloy, Perfect Developer,Concurrent/reactive: Petri Nets, CCS, CSP, UNITY, event B etc...



Abstract State Machines

ASMs belong to the class of transition systems formalisms.

ICS = Abstract Machines = set of states + set of non deterministictransitions

Transition = selection condition (guard) + machine statetransformations

Turing-equivalent

Existing implementations: ASM Gopher, B Method.



B, a very simple example

MACHINE Car StatusSETS

STATUS = {sold , available}USES CarsVARIABLES statusINVARIANT

status ∈ CARS p→ STATUSINITIALISATION status := ∅OPERATIONS

set status(x ,m) ,PRE m ∈ STATUS ∧ x ∈ CARSTHENstatus(x) := m

ENDEND;



Set and Category Theories

state = Data (sets) + functions + relations

transition = invariants + pre/post conditions

formalism: particularly expressive and modular

numerous implementations: Z, VDM, RAISE, SPECWARE,CHARITY, CAMILA, Alloy, etc.



Algebraic Specification

Principles

Core definitions: the data manipulated by the ICS

Provide an axiomatic description of the behaviour of the operationsthat can manipulate the involved data

=⇒Data types as sets

Operation of the ICS:

Functions: introduced as symbols and their signaturebehaviour of the functions : axiomatically specified by their expectedproperties (equations)



Algebraic Specification

Underlying mathematics

Algebra (particularly multi-sorted algebra), Induction, Equational Logic

Some tools

Sequential: ACT-ONE, CLEAR, OBJ, CASL, SPECWARE, etc...

Concurrent: LOTOS, etc...



A simple example of algebraic specification

Spec: LIST0 (ELT )Extends: Nat0

Sorts: listOperations:

nil : → list // constructorcons : elt → list → list // constructorlength : list → nathd : list → elttl : list → listappend : list → list → listrev : list → list

Axioms: xs, ys : list, x : eltlength(nil) = 0length(cons(s, xs)) = 1 + length(xs)hd(cons(x , xs)) = xtl(cons(x , xs)) = xsappend(nil , ys) = ysappend(cons(x , xs), ys) = cons(x,append(xs,ys))rev(nil) = nilrev(cons(x , xs)) = append(rev(xs), cons(x , nil))

Deductive theorems

∀x, y, z ∈ elt, rev(cons(x, cons(y, cons(z, nil)))) =

cons(z, cons(y, cons(x, nil)))

Inductive theorems

∀xs, ys, zs ∈ list,• length(append(xs, ys)) = length(xs) + length(ys)

• append(append(xs, ys), zs) = append(xs, append(ys, zs))

Proof: by induction. Here list is inductively definedby the constructors nil and cons, and by variables.



Hybrid specifications

Principles

Mix Model based specification with Algebraic specification or withConcurrency calculus

Some tools

RAISE (VDM+CSP), Extended LOTOS, ZCCS, etc...



Automata based Modelling

Again, ∈ transition systems formalisms

transition = event

state = a particular configuration of the internal state of the ICS

particularly suitable for: hardware, concurrent or reactive orcommunicating ICS, protocols, etc.



in a picture: an automaton for a shared printer spooler

Pa,b = Printing request by user a or b,Ta,b = starting printing request for a or b,Fa,b = a or b takes off the prints,N = idle, E = waiting for the prints, L = prints available



Specification for real-time system

Formalisms: Various, mostly extensions of the classical automataformalism. Examples: synchronous languages, temporized or hybridautomata, PLC-automata, etc.

ICS = State machine = states + guarded transitions

State = record a particular configuration of the ICS

Transition = guard (over the configuration or temporal requirements)+ transformation to the internal configuration of the machine

Some tools: Lustre, Esterel, Scade, UPPAAL



Scade in a picture



UPPAAL in a picture



Other formalisms for the formal specification

Orthogonally to these major formal specification paradigms, several othermethodologies and tools tend to complement or be integrated into the

existing universe of formal specification.



Declarative Modelling

=⇒ an important family of formalisms:

Logical formalisms

based on first order logic

data of the target ICS = data-structure in the logical language

function/operations = behaviour described by appropriate formulas(properties).

some formalisms and tools: Prolog, λ-Prolog, etc...

provide animation and execution




Functional formalisms

based on the λ-calculus

data of the target ICS = data-structure expressed in the functionallanguage (usually featuring polymorphism, inductive types, but insome case more complex constructs like dependent types, etc.)

operations = high order functions

implementations:

Programming Languages: Scheme, SML, Haskell, OCaml,Proof Systems: ACL2, DECLARE, AGDA, COQ, PVS, HOL(-light),

ISABELLE etc...

in some cases, provide animation and execution



COQ in a picture




Rewriting Systems

based on the notion of reduction

data of the target ICS = data-structure in the target language

function = computational description via equations

some implementation: MAUDE, ELAN, SPIKE etc...

provide animation and execution


A Guided Tour Specification and Verification

Specifying and proving

Ensuring behaviour

animation and execution is clearly inadequate

Must prove: formal verification




3 kinds of support for the formal verification (J.Rushby hierarchy)

1 Tools that provide a formal framework(without any other support)

2 Tools that provide a formal system for theadequate formulation of reasoning

3 Tools that provide a formal system andcomputational support forexpressing/building proofs

manual proof in natural language,valid if the expert community agrees.

manual proof but using a formallanguage tailored to the expression ofsuch proofs

=⇒ More rigorous (e.g. Lamport,etc...) i.e. in the same tool supportedframework:ability to express models and the proofof their properties

Focus

=⇒ Level 3











Focus

=⇒ Level 3











Focus

=⇒ Level 3











Focus

=⇒ Level 3



Proof systems

Principles

formal system = deductive system

The variety of formalisms can be explained by the balance between twofollowing antagonistic factors:

logical expressivityversus

automation of the deduction



Theorem Provers

. . . or Automated Theorem Provers

Favours: automation of the deduction

Advantages: After a parametrization stage (of the deduction engine),the proof is automaticcan reason upon infinite sets (e.g. by induction)

Drawbacks: cannot express complex properties and proofs.

Some tools: Prolog, SPIKE, ELAN, ACL2,SMT provers like Z3, CVC, Yice, Alt-ergo, etc...



Interactive Proof Systems

. . . ou Proof Assistants

Favours: logical expressibility (generally, higher order logic)

Advantages: Complex properties / proofs need such expressivity.Reasoning close to standard Mathematical reasoning

Drawbacks: undecidability of the underlying logic =⇒ need userintervention to perform proofs.

Some tools: Coq, PVS, DECLARE, HOL, ISABELLE



Model checking

Alternative approach to Theorem Provers, with a large amount ofsuccessful case studies.

Specification principles: again, ICS as a transition system (graph,Petri nets, automata, etc.)

The intended properties are expressed in a temporal logic

Verification principle: proofs = a given graph/transition systemtraversal



Model Checking

Advantages: Automatic demonstrationoutput a counter-example in case of error (e.g. the pathto an erroneous state)

Drawbacks: State space explosion problem (the transition systemgrows exponentially w.r.t. the size of the modelledsystem)cannot handle easily with infinite states

Some tools: SMV, Murphy, SPIN, Kronos, Design/CPN, UPPAAL, etc. . .



Program annotation and Hoare Logic

Consists of

Logical annotations (as special comments) in the source program(pre/post conditions, invariants, variants).

automatic construction of a model w.r.t. source language axiomaticsemantic (implementation −→ model, and not the opposite)

provide support for the demonstration of expected properties(delegation of the proof to specialized proof tools, like SMT solvers,model checkers or proof systems)

Highlight :the source code can be obtained by traditional software engineering processesthe annotation can be manually introduced, or derived from protectionprofiles, or systematically derived from a ICS requirement analysis.



Program annotation and Hoare Logic

. . . or design by contracts

Advantages: Democratization of the formal verification process.

Formal verification along with traditional ICS design andengineering.can be easily integrated with other program analysistools (e.g Frama-C)

Drawbacks: Finding good/accurate annotations can be challenging(elitist democratization :) )

Some Tools: Strongly tied to source languagesC: (ACSL), Frama-C, caduceus, VCC,

Java: (JML), LOOP tool, ESC/JAVA, Krakatoa, Key Tools,Bandera, Jive, Jack etc...

C]: Spec]ADA: Spark, RavenSpark



Program Static Analysis

Principles: Based on Programming Language semantics andApproximation Theory like Asbtract Interpretation.

Advantages:

When conveniently set up, powerful and automaticanalysis.Aim at detect statically potential errors.Successful industrial case studies.

Drawbacks: Specialized analysis. Parametrization, deployment need areal expertise.

Some tools: Astree, PolySpace Verifier, Terminator, etc...


A Guided Tour Specification and Synthesis

Specification and Synthesis

FM Second central sub problem

Relating/Synthesizing an implementation from an approved model

Solutions?

The specification languages is executable (or a programminglanguage) =⇒ Q.E.D.

Refinement

Extraction




Refinement

Technique that allow a step-by-step implementation synthesis from amodel

1 step = 1 design/implementation choice (e.g. a set by a linked-list,an ordering by the quick-sort algorithm, etc. . . )

each step must be formally justified (e.g. do not alter the behaviouri.e. still compliant with the previously proved properties)

Some tools: Z, VDM, B, SPECWARE



Refinement in a simple example

MACHINE Set1(maxelem)CONSTRAINTS maxelem ∈ N1

VARIABLES setINVARIANT

set ⊆ N∧card(set) ≤ maxelem

INITIALISATION set := ∅OPERATIONS

add(n) ,PRE n ∈ N− set∧card(set) < maxelem

THEN set := set ∪ {n}END

END;

REFINEMENT Set2REFINES Set1VARIABLES tab, indexINVARIANT

index ∈ 0..maxelem,∧tab ∈ 1..index � N∧ran(tab) = set

INITIALISATION index , tab := 0, ∅OPERATIONS

add(n) ,PRE n ∈ N− ran(tab) ∧ index < maxelemTHEN index := index + 1||tab(index + 1) := nEND

END;




Extraction

the underlying logic of several proof assistants = (high order) intuitionistlogic =⇒ Curry-Howard Isomorphism

Curry-Howard Isomorphism

λ-calculus logic programming

type formula specification

term proof program




Extraction

Principles: Let be T the theorem

∀(a, b) ∈ N2.b > 0, ∃(q, r) ∈ N2.(a = (q × b + r) ∧ r < b)

In intuitionist logic and using the Curry-Howard Isomorphism,a proof of T is a function that, for a given (a, b), computes(q, r) which witnesses the validity of T . This is then afunction provably correct by definition =⇒ Q.E.D.

Some tools: COQ, Agda.



Extraction in a picture


A Guided Tour Specification and Transformation

Specification and Transformation

Model abstraction and specialization

The situation in ”model engineering”: need for models transformationmechanism (e.g. for the definition of a variation, asimplification, an extension or a specialization, etc...) =⇒complex but modular proofs in large specification, etc...

Example: Model Abstraction to focus on a particular specificationbehaviour (that need to be proved). For instance, typeabstraction when proving the absence of typing errors.

Some tools: ASF+SDF, JaKarTa, Astree, AiT (for timing properties)


A Guided Tour Specification and Transformation

Specification and Transformation

The need for combinations

there is no tool that solve the whole FM central problem globally andsatisfactorily

⇓the need for collaborative platforms


Conclusion

Table of Contents

1 Preliminaries

2 A Guided Tour

3 Conclusion


Conclusion

Some successful case studies

numerous examples, for instance:

Garbage Collection, Operating System Modules, Communication andCryptographic Protocols, Circuits and Hardware, Execution Platforms,Programming Language (semantics and methodologies), Compilers,Information Systems, etc... (see famous FM surveys for details)

Application area (mostly safety critical systems):

Avionic and Aerospace (NASA, FAA, ARIANE, etc...),Railways (subway, etc...)Nuclear SystemsMedical Systems(Real-Time) Embedded Systems


Conclusion

Some successful case studies

A quite old: The formal verification of the CISC project from IBM (HuxleyPark- UK & Oxford): Update of an Information System.

800 000 lines of code. 268 000 were rewritten, 37 00 via the Z FormalMethod (only Formal Spec. without proofs)

results:

Development costs: −9%2.5 times fewer bugs, and the detected bugs were qualified as minor.(imply lower maintenance cost)


Conclusion

A formal development example done in B

First real success was Meteor line 14 driverless metro in Paris:Over 110 000 lines of B models were written, generating 86 000lines of Ada. No bugs were detected after the proofs, neither atthe functional validation, at the integration validation, at on-sitetest, nor since the metro lines operate (October 1998). Thesafety-critical software is still in version 1.0 in year 2007, withoutany bug detected so far.

In Formal Methods in Safety-Critical Railway Systems, Thierry Lecomte,Thierry Servat, Guilhem Pouzancre.


Conclusion

ASTREE Success story (excerpt from its web-site)

The development of ASTREE started from scratch in Nov. 2001. Two years later, the mainapplications have been the static analysis of synchronous, time-triggered, real-time, safetycritical, embedded software written or automatically generated in the C programming language.ASTREE has achieved the following unprecedented results:

In Nov. 2003, ASTREE was able to prove completely automatically the absence of anyRTE in the primary flight control software of the Airbus A340 fly-by-wire system, aprogram of 132,000 lines of C analyzed in 1h20 on a 2.8 GHz 32-bit PC using 300 Mb ofmemory (and 50mn on a 64-bit AMD Athlon 64 using 580 Mb of memory).

From Jan. 2004 on, ASTREE was extended to analyze the electric flight control codesthen in development and test for the A380 series. The operational application by AirbusFrance at the end of 2004 was just in time before the A380 maiden flight on Wednesday,27 April, 2005.

In April 2008, ASTREE was able to prove completely automatically the absence of anyRTE in a C version of the automatic docking software of the Jules Vernes AutomatedTransfer Vehicle (ATV) enabling ESA to transport payloads to the International SpaceStation.


Conclusion

COQ and Common Criteria (excerpt from the officialannouncements)

September 2007: a big step in program certification in the real world: TheTechnology and Innovation group at Gemalto has successfully completed aCommon Criteria (CC) evaluation on a Java Card based commercial product. Thisevaluation is the world’s first CC certificate of a Java product involving EAL7components

Trusted Logic announces (press release of November 18th, 2003) that the DCSSIhas successfully evaluated its security methodology applied to the Java CardSystem at the Common Criteria EAL7 level, in a report published earlier this year.Coq is the proof engine used by Trusted Logics, and was chosen for itsexpressiveness. As a part of the certification process, it is being acknowledged astrustworthy by the DCSSI.


Conclusion

Certified Compilation (excerpt from the compcert website)

Compcert is a compiler that generates PowerPC assembly code from Clight, a largesubset of the C programming language. The particularity of this compiler is that it iswritten mostly within the specification language of the Coq proof assistant, and itscorrectness — the fact that the generated assembly code is semantically equivalent toits source program — was entirely proved within the Coq proof assistant.A high-level overview of the Compcert compiler and its proof of correctness can befound in the following papers:

Xavier Leroy, Formal certification of a compiler back-end, or: programming acompiler with a proof assistant. Proceedings of the POPL 2006 symposium.

Sandrine Blazy, Zaynah Dargaye and Xavier Leroy, Formal verification of a Ccompiler front-end. Proceedings of Formal Methods 2006, LNCS 4085.


Conclusion

Certified Cryptography

Correctness of RSA Algorithm, by Jose C. Almeida (DIUM), LaurentThery

Certifying Prime Number with the Coq prover. CoqPrime is a librarybuilt on top of the Coq proof system to certify primality usingPocklington certificate and Elliptic Curve Certificate.

SCALP Project: Security of Cryptographic ALgorithms withProbabilities. Probabilistic language and semantics for cryptographicproofs, Formalization of random generators, Proof theory for:High-level reasoning about distributions defined by probabilisticprograms, Semantic preserving program transformations,Cryptography-based program transformations, Asymptotic reasoning.


Conclusion

Certified Operating Systems or Virtual Machines

Java Card in COQ

Formal verification of the Java-Card Platform in COQ (joint work with G. Barthe, G.Dufay)

1 a specification and prototype of JavaCard Execution Platform and

2 the proof that (Milner citation)

Well-typed (JavaCard) Programs cannot go wrong

3 A provably correct implementation of the ByteCode Verifier (BCV), a crucialsecurity module based on static program analysis.

SEL4

The L4.verified project, A Formally Correct Operating System Kernel (Gerwin Klein etal.)


Conclusion

Concluding Remarks

Un peu de programmation eloigne de la logique mathematique;beaucoup de programmation y ramene.

Xavier Leroy.

(a bit of programming move the programmer away to logic, a lot ofprogramming gets back to it)


Documents

Rigorous Software Development Concepts, Techniques and ...desousa/2012-2013/CF/RSD_chap2_tour.pdf · transformations Turing-equivalent Existing implementations: ASM Gopher, B Method