• Aucun résultat trouvé

An Introduction to Formal Methods in Software Engineering.

N/A
N/A
Protected

Academic year: 2022

Partager "An Introduction to Formal Methods in Software Engineering."

Copied!
35
0
0

Texte intégral

(1)

An Introduction to Formal Methods in Software Engineering.

PhD student:

Vincent Iampietro

PhD supervisors:

David Andreu, David Delahaye

December 4, 2019

(2)

Definitions.

Formal Methods.

Formal methods are techniques used to modelsystemsas mathematical entities.

Systems can be

I Digital architectures

I Physical/Biological phenomenons I Social interaction schemes I and. . .

(3)

Definitions.

Formal Methods.

Formal methods are techniques used to modelsystemsas mathematical entities.

Systems can be

I Digital architectures

I Physical/Biological phenomenons I Social interaction schemes I and. . .softwares!

1 / 11

(4)

Formal methods: perks and drawbacks.

Perks.

Mathematical approaches to modelsoftwares: I Improve the precision of the design.

I Enable proofs of correctness.

I Permit the extraction of properties.

Overall reliability of the software

(5)

Formal methods: perks and drawbacks.

Drawbacks.

I Conception time increases dramatically.

I Models are simpler than real softwares.

I Lack of qualified workforce.

Time & money spent to build a software

2 / 11

(6)

Formal methods: when do we need them?

I Development of safety-critical systems:

Avionics

Medicine

Automotive

Nuclear

. . .

I Risks:

Loss of life/lives

Loss of resources (financial, natural. . . )

(7)

Formal methods: when do we need them?

I Development of safety-critical systems:

Avionics

Medicine

Automotive

Nuclear

. . . I Risks:

Loss of life/lives

Loss of resources (financial, natural. . . )

3 / 11

(8)

Formal methods: when do we need them?

Critical bugs are real!

I Therac-25 radiation therapy, excessive quantities of beta radiation (1980s).

I Patriot Missile, floating point rounding error (1991).

I Ariane 5 failure, conversion from 64-bit floating to 16-bit signed (1996).

I Hitomi astronomical satellite destruction, thruster orientation bug (2016).

I See P.G.Neumann’s list of Computer-related Risks [Neumann, 1995].

(9)

What is bug?

(baby don’t hurt me. . . )

Context.

TheAirsafecompany orders an autopilot program to its developer teamto control the Swiss new aircraft fleet.

I Airsafe: “I want an autopilot program that avoid plane crashes.”

I Result: the plane never leaves the ground!

I Question: Is it a bug?

4 / 11

(10)

What is bug?

Context.

TheAirsafecompany orders an autopilot program to its developer teamto control the Swiss new aircraft fleet.

I Airsafe: “I want an autopilot program that avoid plane crashes.”

I Result: the plane never leaves the ground!

I Question: Is it a bug?

(11)

What is bug?

Context.

TheAirsafecompany orders an autopilot program to its developer teamto control the Swiss new aircraft fleet.

I Airsafe: “I want an autopilot program that avoid plane crashes.”

I Result: the plane never leaves the ground!

I Question: Is it a bug?

4 / 11

(12)

What is bug?

Context.

TheAirsafecompany orders an autopilot program to its developer teamto control the Swiss new aircraft fleet.

I Airsafe: “I want an autopilot program that avoid plane crashes.”

I Result: the plane never leaves the ground!

I Question: Is it a bug?

(13)

What is bug?

Definition of a bug (failure).

“an undesired effect observed in the software’s delivered service”, [Abran, 2004].

Remark.

A bug is always related to the softwarespecification.

4 / 11

(14)

About Specification.

Specificationexpressed in natural language can be:

I incomplete (e.g, the autopilot program).

I ambiguous: “I want an autopilot program that avoid plane crashes on the ground.”

(15)

About Specification.

Formal specification.

I Removes the ambiguity.

I Limits: never sure about completeness.

Formal specification formats.

I Unified Modelling Language (UML).

I First Order Logic (FOL).

I Petri nets.

I Any formal languages. . .

5 / 11

(16)

Formal method techniques.

I Model checking.

I Automatic theorem proving.

I Deductive methods I . . .

Deductive methods.

Proof of soundness/completeness between SPEC. and IMPL.

PROGRAM IMPL. FORMAL SPEC.

(17)

Formal method techniques.

I Model checking.

I Automatic theorem proving.

I Deductive methods.

I . . .

Deductive methods.

Proof of soundness/completeness between SPEC. and IMPL.

PROGRAM IMPL. FORMAL SPEC.

6 / 11

(18)

Formal method techniques.

Deductive methods.

Proof of soundness/completeness between SPEC. and IMPL.

PROGRAM IMPL.

FORMAL SPEC.

(19)

Formal method techniques.

Deductive methods.

Proof of soundness/completeness between SPEC. and IMPL.

PROGRAM IMPL.

FORMAL SPEC.

Human-executed although mechanized

6 / 11

(20)

An example of program.

Natural language specification.

A bank:

“I want a program that debits a non-negative amount from an account if there’s enough money in the account.”

(21)

An example of program.

Natural language specification.

A bank:

“I want a program thatdebits anon-negative amountfrom an account if there’senough money in the account.”

7 / 11

(22)

An example of program.

Formal specification.

Debit∈Z→Z→(Z ∪ Err)→ {>,⊥} ≡

∀acc,amnt ∈Z,

|acc ≥amnt >0⇒Debit(acc,amnt,acc−amnt)

|amnt ≤0⇒Debit(acc,amnt,Err)

|amnt >acc ⇒Debit(acc,amnt,Err)

(23)

An example of program.

Formal specification.

Debit∈Z→Z→(Z ∪ Err)→ {>,⊥} ≡

∀acc,amnt ∈Z,

|acc ≥amnt >0⇒Debit(acc,amnt,acc−amnt)

|amnt ≤0⇒Debit(acc,amnt,Err)

|amnt >acc ⇒Debit(acc,amnt,Err)

Program implementation.

∀acc,amnt ∈Z,

debit impl(acc,amnt) =

(acc −amnt if (acc ≥amnt >0)

Err otherwise

7 / 11

(24)

An example of program.

Proofs.

I Soundness:

∀acc,amnt ∈Z,acc0 ∈Z∪Err,

debit impl(acc,amnt) =acc0 ⇒Debit(acc,amnt,acc0). I Completeness:

∀acc,amnt ∈Z,acc0 ∈Z∪Err

Debit(acc,amnt,acc0)⇒debit impl(acc,amnt) =acc0.

(25)

An example of program.

Proofs.

I Soundness:

∀acc,amnt ∈Z,acc0∈Z∪Err,

debit impl(acc,amnt) =acc0 ⇒Debit(acc,amnt,acc0).

I Completeness:

∀acc,amnt ∈Z,acc0 ∈Z∪Err

Debit(acc,amnt,acc0)⇒debit impl(acc,amnt) =acc0.

7 / 11

(26)

An example of program.

Proofs.

I Soundness:

∀acc,amnt ∈Z,acc0∈Z∪Err,

debit impl(acc,amnt) =acc0 ⇒Debit(acc,amnt,acc0).

I Completeness:

∀acc,amnt ∈Z,acc0∈Z∪Err

Debit(acc,amnt,acc0)⇒debit impl(acc,amnt) =acc0.

(27)

Another example of program.

Formal specification

Sum∈N→N∈ {>,⊥} ≡ ∀n,m∈N, m= n(n+1)2 ⇒Sum(n,m) Program implementation.

∀n∈N, sumf(n) =

(0 if (n = 0) n+sumf(n−1) otherwise

8 / 11

(28)

Another example of program.

Formal specification

Sum∈N→N∈ {>,⊥} ≡ ∀n,m∈N, m= n(n+1)2 ⇒Sum(n,m) or

∀n,m∈N, Sum(n,m)≡m= n(n+1)2 Program implementation.

∀n∈N, sumf(n) =

(0 if (n = 0) n+sumf(n−1) otherwise

(29)

The Coq proof assistant.

Coq is one formal proof verifier among many (Isabelle, HOL, PVS. . . ).

FORMAL SPEC.

PROGRAM IMPL.

Proof of soundness/completeness between SPEC. and IMPL.

language for SPEC. (Gallina)

language for IMPL. (Gallina)

language for PROOF. (Tactics)

Coq proof assistant

Use cases [Leroy, 2014].

I Basic mathematics theories (geometry, algebra. . . ): e.g,Four Color Theorem proof [Gonthier, 2008]. I Complex algorithms, and protocols verification:

e.g,Boyer-Moore majority vote algorithm, formalized by C.Paulin-Mohring.

I Program verification (written in Coq!).

9 / 11

(30)

The Coq proof assistant.

Coq is one formal proof verifier among many (Isabelle, HOL, PVS. . . ).

Use cases [Leroy, 2014].

I Basic mathematics theories (geometry, algebra. . . ):

e.g,Four Color Theorem proof [Gonthier, 2008].

I Complex algorithms, and protocols verification:

e.g,Boyer-Moore majority vote algorithm, formalized by C.Paulin-Mohring.

I Program verification (written in Coq!).

(31)

Coq demo.

10 / 11

(32)

Conclusion.

I Real need for formal methods for safety-critical softwares (especially as software complexity increases).

I Adoption of formal methods, a 2-axis process: 1. Training aqualified workforce.

2. Helping uninitiated developers (automatic theorem proversfor main-stream programming languages).

e.g theFrama-C framework [Cuoq et al., 2012]. I Formal methods are not only for software engineering!

e.g. Applications to digital architecture design.

(33)

Conclusion.

I Real need for formal methods for safety-critical softwares (especially as software complexity increases).

I Adoption of formal methods, a 2-axis process:

1. Training aqualified workforce.

2. Helping uninitiated developers (automatic theorem proversfor main-stream programming languages).

e.g theFrama-C framework [Cuoq et al., 2012].

I Formal methods are not only for software engineering! e.g. Applications to digital architecture design.

11 / 11

(34)

Conclusion.

I Real need for formal methods for safety-critical softwares (especially as software complexity increases).

I Adoption of formal methods, a 2-axis process:

1. Training aqualified workforce.

2. Helping uninitiated developers (automatic theorem proversfor main-stream programming languages).

e.g theFrama-C framework [Cuoq et al., 2012].

I Formal methods are not only for software engineering!

e.g. Applications to digital architecture design.

(35)

Bibliography.

Abran, A., editor (2004).

Guide to the software engineering body of knowledge, 2004 version: SWEBOK ; a project of the IEEE Computer Society Professional Practices Committee.

IEEE Computer Society, Los Alamitos, Calif.

OCLC: 934432015.

Cuoq, P., Kirchner, F., Kosmatov, N., Prevosto, V., Signoles, J., and Yakobowski, B. (2012).

Frama-C.

In Eleftherakis, G., Hinchey, M., and Holcombe, M., editors,Software Engineering and Formal Methods, Lecture Notes in Computer Science, pages 233–247, Berlin, Heidelberg. Springer.

Gonthier, G. (2008).

The Four Colour Theorem: Engineering of a Formal Proof.

In Kapur, D., editor,Computer Mathematics, Lecture Notes in Computer Science, pages 333–333, Berlin, Heidelberg. Springer.

Leroy, X. (2014).

Spcification et vrification formelles avec l’assistant la preuve Coq.

Neumann, P. (1995).

Computer-related risks.

ACM Press ; Addison-Wesley, New York, New York : Reading, Mass.

Références

Documents relatifs

• bitstream stored in a flash memory and automatically loaded when powering

His proof involves a generalization of Gel’fond’s method to several variables and yields a general transcendence criterion for functions satisfying differential equations with

The Coral team has not published precise benchmarks describing their engine’s performance for variable numbers and types of policies (and for variable numbers of transmission

The article is structured in the following way: section 2 discusses the application of qualitative and quantitative methods, and establishes as a starting point, a possible

Tsy misotro rano ianao You don’t drink water Tsy tia koka izy He doesn’t like coke tsy Negative.. Tsy faly izy She is

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des

To the best of our knowledge this paper presents the first application of the Doobs-Kolmogorov Inequality to software reliability and the first generic formal developpment able

(g) Forward feedback signal defined as the maximum of the sum of the two coplanar OFs measured (horizontal OF sensors = yellow; vertical OF sensors = magenta).. agent to