(this file is in presentation format; view it in Adobe Acrobat Reader DC, not in browser and not in Adobe Touch)

Formal Software Development

Adrian Zidaritz

zidaritz berkeley.edu

March 8, 2011
Introduction

This is an overview of the ‘Formal Software Development’ program. It is

written for software professionals, and as such, it assumes some familiarity
with symbolic manipulation.

In this overview, we:

Explain what a mathematical formal system is

Show why formal systems are the foundation of software
Give some concrete examples of formal software development
Present the structure and the goals of the program

Formal Software Development Program Overview March 8, 2011 2 / 187

Introduction
ip be
d
sk ay
pe
m

Some slides are marked with this gray sticker; they con-
tain some fairly elementary mathematical concepts, es-
sentially induction. These slides may be skipped.
ip be
d
sk ay

Other slides are marked with this red sticker; they as-
pe
m

sume knowledge of higher level algebra and treat induc-

tion at a more advanced level. These slides may also
be skipped.

We include these optional slides because the program itself is a progression

from basic concepts to more advanced ones, and we want to give all
prospective students a bird’s-eye view of the entire program and a roadmap
to follow. Moreover, induction is the central proof technique of the program.

Formal Software Development Program Overview March 8, 2011 3 / 187

 What is formal software development

1 What is formal software development

2 Implementing formal systems

3 When are proofs used

4 What formal software development is not

5 Formal verification of programs

6 Mathematics and Software

7 Concrete examples of what we do in the program

8 Program goals and course structure

Formal Software Development Program Overview March 8, 2011 4 / 187
 What is formal software development Mathematics as foundation

The use of mathematical logic

Formal Software Development Program Overview March 8, 2011 5 / 187

 What is formal software development Mathematics as foundation

The use of mathematical logic

Formal software development is the use of mathematical logic to specify,

design, build, analyze and test software.

Formal Software Development Program Overview March 8, 2011 5 / 187

 What is formal software development Mathematics as foundation

What does it mean to use mathematical logic?

Formal Software Development Program Overview March 8, 2011 6 / 187

 What is formal software development Mathematics as foundation

What does it mean to use mathematical logic?

It means that one has to

Formal Software Development Program Overview March 8, 2011 6 / 187

 What is formal software development Mathematics as foundation

What does it mean to use mathematical logic?

It means that one has to

study mathematical logic

Formal Software Development Program Overview March 8, 2011 6 / 187

 What is formal software development Mathematics as foundation

What does it mean to use mathematical logic?

It means that one has to

study mathematical logic

study the tools that implement various logics

Formal Software Development Program Overview March 8, 2011 6 / 187

 What is formal software development Mathematics as foundation

What does it mean to use mathematical logic?

It means that one has to

study mathematical logic

study the tools that implement various logics
understand how to apply these tools to software engineering

Formal Software Development Program Overview March 8, 2011 6 / 187

 What is formal software development Mathematics as foundation

How much mathematical logic?

Formal Software Development Program Overview March 8, 2011 7 / 187

 What is formal software development Mathematics as foundation

How much mathematical logic?

Mathematical logic is a large field in itself; it consists of proof theory,

model theory, and recursive functions (=computability); set theory is
regarded by many as belonging to logic too

Formal Software Development Program Overview March 8, 2011 7 / 187

 What is formal software development Mathematics as foundation

How much mathematical logic?

Mathematical logic is a large field in itself; it consists of proof theory,

model theory, and recursive functions (=computability); set theory is
regarded by many as belonging to logic too
Logic is also the basis of many fields of computer science: type theory,
specification languages, theory of computation, term rewriting, various
program logics, automatic and interactive provers, etc . . .

Formal Software Development Program Overview March 8, 2011 7 / 187

 What is formal software development Mathematics as foundation

How much mathematical logic?

Mathematical logic is a large field in itself; it consists of proof theory,

model theory, and recursive functions (=computability); set theory is
regarded by many as belonging to logic too
Logic is also the basis of many fields of computer science: type theory,
specification languages, theory of computation, term rewriting, various
program logics, automatic and interactive provers, etc . . .
Formal software development needs results from all these subfields of
mathematical logic and from many of its applications to computer science

Formal Software Development Program Overview March 8, 2011 7 / 187

 What is formal software development Mathematics as foundation

How much mathematical logic?

Mathematical logic is a large field in itself; it consists of proof theory,

model theory, and recursive functions (=computability); set theory is
regarded by many as belonging to logic too
Logic is also the basis of many fields of computer science: type theory,
specification languages, theory of computation, term rewriting, various
program logics, automatic and interactive provers, etc . . .
Formal software development needs results from all these subfields of
mathematical logic and from many of its applications to computer science
So the answer to the title question would be: an awful lot

Formal Software Development Program Overview March 8, 2011 7 / 187

 What is formal software development Mathematics as foundation

How much mathematical logic?

Mathematical logic is a large field in itself; it consists of proof theory,

model theory, and recursive functions (=computability); set theory is
regarded by many as belonging to logic too
Logic is also the basis of many fields of computer science: type theory,
specification languages, theory of computation, term rewriting, various
program logics, automatic and interactive provers, etc . . .
Formal software development needs results from all these subfields of
mathematical logic and from many of its applications to computer science
So the answer to the title question would be: an awful lot
Part of the motivation behind this overview is to show you the program’s
road map through this large body of knowledge, a road that should lead
to significant applications in software development

Formal Software Development Program Overview March 8, 2011 7 / 187

 What is formal software development Mathematics as foundation

How much mathematical logic?

Mathematical logic is a large field in itself; it consists of proof theory,

model theory, and recursive functions (=computability); set theory is
regarded by many as belonging to logic too
Logic is also the basis of many fields of computer science: type theory,
specification languages, theory of computation, term rewriting, various
program logics, automatic and interactive provers, etc . . .
Formal software development needs results from all these subfields of
mathematical logic and from many of its applications to computer science
So the answer to the title question would be: an awful lot
Part of the motivation behind this overview is to show you the program’s
road map through this large body of knowledge, a road that should lead
to significant applications in software development
At the core of this use of logic are the formal systems

Formal Software Development Program Overview March 8, 2011 7 / 187

 What is formal software development Mathematics as foundation

What is a mathematical formal system?

Formal Software Development Program Overview March 8, 2011 8 / 187

 What is formal software development Mathematics as foundation

What is a mathematical formal system?

A (mathematical) formal system is a language and a set of rules

Formal Software Development Program Overview March 8, 2011 8 / 187

 What is formal software development Mathematics as foundation

What is a mathematical formal system?

A (mathematical) formal system is a language and a set of rules

The word ‘formal’ is meant to embody the rigidity and the precision of
language and rules

Formal Software Development Program Overview March 8, 2011 8 / 187

 What is formal software development Mathematics as foundation

What is a mathematical formal system?

A (mathematical) formal system is a language and a set of rules

The word ‘formal’ is meant to embody the rigidity and the precision of
language and rules
. . . in opposition to ‘informal’ systems based on natural languages, which
are flexible and ambiguous

Formal Software Development Program Overview March 8, 2011 8 / 187

 What is formal software development Mathematics as foundation

What is a mathematical formal system?

A (mathematical) formal system is a language and a set of rules

The word ‘formal’ is meant to embody the rigidity and the precision of
language and rules
. . . in opposition to ‘informal’ systems based on natural languages, which
are flexible and ambiguous
You may think of a formal system as a recipe, to be applied mechanically,
without any creative thinking

Formal Software Development Program Overview March 8, 2011 8 / 187

 What is formal software development Mathematics as foundation

What is a mathematical formal system?

A (mathematical) formal system is a language and a set of rules

The word ‘formal’ is meant to embody the rigidity and the precision of
language and rules
. . . in opposition to ‘informal’ systems based on natural languages, which
are flexible and ambiguous
You may think of a formal system as a recipe, to be applied mechanically,
without any creative thinking
So by itself, a formal system is inert, it does not do anything

Formal Software Development Program Overview March 8, 2011 8 / 187

 What is formal software development Mathematics as foundation

What is a mathematical formal system?

A (mathematical) formal system is a language and a set of rules

The word ‘formal’ is meant to embody the rigidity and the precision of
language and rules
. . . in opposition to ‘informal’ systems based on natural languages, which
are flexible and ambiguous
You may think of a formal system as a recipe, to be applied mechanically,
without any creative thinking
So by itself, a formal system is inert, it does not do anything
We are not concerned for now with a specific meaning of such a system

Formal Software Development Program Overview March 8, 2011 8 / 187

 What is formal software development Mathematics as foundation

What can we do with such a system?

Formal Software Development Program Overview March 8, 2011 9 / 187

 What is formal software development Mathematics as foundation

What can we do with such a system?

We can reason based on the rules

Formal Software Development Program Overview March 8, 2011 9 / 187

 What is formal software development Mathematics as foundation

What can we do with such a system?

We can reason based on the rules

Reason means nothing but the blind application of the rules to sentences
of the language in order to derive other sentences

Formal Software Development Program Overview March 8, 2011 9 / 187

 What is formal software development Mathematics as foundation

What can we do with such a system?

We can reason based on the rules

Reason means nothing but the blind application of the rules to sentences
of the language in order to derive other sentences
We begin with a look at a simple formal system

Formal Software Development Program Overview March 8, 2011 9 / 187

 What is formal software development Mathematics as foundation

What can we do with such a system?

We can reason based on the rules

Reason means nothing but the blind application of the rules to sentences
of the language in order to derive other sentences
We begin with a look at a simple formal system
The concepts introduced while looking at this simple system are the nuts
and bolts of the program

Formal Software Development Program Overview March 8, 2011 9 / 187

 What is formal software development Mathematics as foundation

What can we do with such a system?

We can reason based on the rules

Reason means nothing but the blind application of the rules to sentences
of the language in order to derive other sentences
We begin with a look at a simple formal system
The concepts introduced while looking at this simple system are the nuts
and bolts of the program
Try to understand this simple system as much as possible

Formal Software Development Program Overview March 8, 2011 9 / 187

 What is formal software development Mathematics as foundation

What can we do with such a system?

We can reason based on the rules

Reason means nothing but the blind application of the rules to sentences
of the language in order to derive other sentences
We begin with a look at a simple formal system
The concepts introduced while looking at this simple system are the nuts
and bolts of the program
Try to understand this simple system as much as possible
Otherwise parts of the overview will sound gibberish

Formal Software Development Program Overview March 8, 2011 9 / 187

 What is formal software development Example: a simple formal system

Example of a formal system

Formal Software Development Program Overview March 8, 2011 10 / 187

 What is formal software development Example: a simple formal system

Example of a formal system

The language

Formal Software Development Program Overview March 8, 2011 10 / 187

 What is formal software development Example: a simple formal system

Example of a formal system

The language

The alphabet of our language consists of three symbols: a, b, and *.

Formal Software Development Program Overview March 8, 2011 10 / 187

 What is formal software development Example: a simple formal system

Example of a formal system

The language

The alphabet of our language consists of three symbols: a, b, and *.

Symbol combinations are called formulas.

Formal Software Development Program Overview March 8, 2011 10 / 187

 What is formal software development Example: a simple formal system

Example of a formal system

The language

The alphabet of our language consists of three symbols: a, b, and *.

Symbol combinations are called formulas.
So ab, baa*, **a*bbb are examples of formulas.

Formal Software Development Program Overview March 8, 2011 10 / 187

 What is formal software development Example: a simple formal system

Example of a formal system

The language

The alphabet of our language consists of three symbols: a, b, and *.

Symbol combinations are called formulas.
So ab, baa*, **a*bbb are examples of formulas.
A language has a grammar: a way to specify which formulas are accept-
able; the technical term is well-formed formulas, wffs in short.

Formal Software Development Program Overview March 8, 2011 10 / 187

 What is formal software development Example: a simple formal system

Example of a formal system

The language

The alphabet of our language consists of three symbols: a, b, and *.

Symbol combinations are called formulas.
So ab, baa*, **a*bbb are examples of formulas.
A language has a grammar: a way to specify which formulas are accept-
able; the technical term is well-formed formulas, wffs in short.
The rules of the grammar are known as formation rules, as opposed to
the rules of system, which are known as rules of inference.

Formal Software Development Program Overview March 8, 2011 10 / 187

 What is formal software development Example: a simple formal system

The grammar

Formal Software Development Program Overview March 8, 2011 11 / 187

 What is formal software development Example: a simple formal system

The grammar

The grammar (or, the formation rules):

Formal Software Development Program Overview March 8, 2011 11 / 187

 What is formal software development Example: a simple formal system

The grammar

The grammar (or, the formation rules):

1 * is a wff

Formal Software Development Program Overview March 8, 2011 11 / 187

 What is formal software development Example: a simple formal system

The grammar

The grammar (or, the formation rules):

1 * is a wff
2 if X and Y are formulas containing no *, then X*Y is a wff

Formal Software Development Program Overview March 8, 2011 11 / 187

 What is formal software development Example: a simple formal system

The grammar

The grammar (or, the formation rules):

1 * is a wff
2 if X and Y are formulas containing no *, then X*Y is a wff
3 no other formulas are wffs

Formal Software Development Program Overview March 8, 2011 11 / 187

 What is formal software development Example: a simple formal system

The grammar

The grammar (or, the formation rules):

1 * is a wff
2 if X and Y are formulas containing no *, then X*Y is a wff
3 no other formulas are wffs

Formal Software Development Program Overview March 8, 2011 11 / 187

 What is formal software development Example: a simple formal system

The grammar

The grammar (or, the formation rules):

1 * is a wff
2 if X and Y are formulas containing no *, then X*Y is a wff
3 no other formulas are wffs

The symbols X and Y do not belong to the language, they are just
placeholders for arbitrary formulas. We’ll talk about them later.

Formal Software Development Program Overview March 8, 2011 11 / 187

 What is formal software development Example: a simple formal system

The grammar

The grammar (or, the formation rules):

1 * is a wff
2 if X and Y are formulas containing no *, then X*Y is a wff
3 no other formulas are wffs

The symbols X and Y do not belong to the language, they are just
placeholders for arbitrary formulas. We’ll talk about them later.

For example, if X stands for a and Y for b, since neither X nor Y contain
a *, then by the second formation rule, a*b is a wff

Formal Software Development Program Overview March 8, 2011 11 / 187

 What is formal software development Example: a simple formal system

The grammar

The grammar (or, the formation rules):

1 * is a wff
2 if X and Y are formulas containing no *, then X*Y is a wff
3 no other formulas are wffs

The symbols X and Y do not belong to the language, they are just
placeholders for arbitrary formulas. We’ll talk about them later.

For example, if X stands for a and Y for b, since neither X nor Y contain
a *, then by the second formation rule, a*b is a wff
Similarly, aa*bb, aba*bbbbb, baba*abab are wffs (think of what X and
Y are in these cases)

Formal Software Development Program Overview March 8, 2011 11 / 187

 What is formal software development Example: a simple formal system

The grammar

The grammar (or, the formation rules):

1 * is a wff
2 if X and Y are formulas containing no *, then X*Y is a wff
3 no other formulas are wffs

The symbols X and Y do not belong to the language, they are just
placeholders for arbitrary formulas. We’ll talk about them later.

For example, if X stands for a and Y for b, since neither X nor Y contain
a *, then by the second formation rule, a*b is a wff
Similarly, aa*bb, aba*bbbbb, baba*abab are wffs (think of what X and
Y are in these cases)
Whereas **, *aba*, a*b*b are not wffs, because we cannot find any X
and Y to fit the grammar requirements
Formal Software Development Program Overview March 8, 2011 11 / 187
 What is formal software development Example: a simple formal system

Rules of inference, in general

Formal Software Development Program Overview March 8, 2011 12 / 187

 What is formal software development Example: a simple formal system

Rules of inference, in general

The rules of inference dictate how a new wff, called a conclusion, can be
deduced (or inferred) from a set (possibly empty) of other wffs, called
premises.

Formal Software Development Program Overview March 8, 2011 12 / 187

 What is formal software development Example: a simple formal system

Rules of inference, in general

The rules of inference dictate how a new wff, called a conclusion, can be
deduced (or inferred) from a set (possibly empty) of other wffs, called
premises.
A rule with an empty set of premises is called an axiom.

Formal Software Development Program Overview March 8, 2011 12 / 187

 What is formal software development Example: a simple formal system

Rules of inference, in general

The rules of inference dictate how a new wff, called a conclusion, can be
deduced (or inferred) from a set (possibly empty) of other wffs, called
premises.
A rule with an empty set of premises is called an axiom.
It is helpful to make this distinction because axioms are what get the
system up and going, i.e. you have to start the deduction process some-
where.

Formal Software Development Program Overview March 8, 2011 12 / 187

 What is formal software development Example: a simple formal system

Rules of inference, in general

The rules of inference dictate how a new wff, called a conclusion, can be
deduced (or inferred) from a set (possibly empty) of other wffs, called
premises.
A rule with an empty set of premises is called an axiom.
It is helpful to make this distinction because axioms are what get the
system up and going, i.e. you have to start the deduction process some-
where.
Otherwise, axioms are nothing but special rules.

Formal Software Development Program Overview March 8, 2011 12 / 187

 What is formal software development Example: a simple formal system

Rules of inference, in general

The rules of inference dictate how a new wff, called a conclusion, can be
deduced (or inferred) from a set (possibly empty) of other wffs, called
premises.
A rule with an empty set of premises is called an axiom.
It is helpful to make this distinction because axioms are what get the
system up and going, i.e. you have to start the deduction process some-
where.
Otherwise, axioms are nothing but special rules.

Formal Software Development Program Overview March 8, 2011 12 / 187

 What is formal software development Example: a simple formal system

Rules of inference, in general

The rules of inference dictate how a new wff, called a conclusion, can be
deduced (or inferred) from a set (possibly empty) of other wffs, called
premises.
A rule with an empty set of premises is called an axiom.
It is helpful to make this distinction because axioms are what get the
system up and going, i.e. you have to start the deduction process some-
where.
Otherwise, axioms are nothing but special rules.

A finite sequence of deductions is called a proof. If a proof uses no premises

other than axioms, then every wff in the sequence of the proof is a theorem.
In particular, axioms are theorems, their proofs being sequences of length 1.
Although the rules can be used to build proofs from any premises, we will
not be using this facility in these slides. For us, proofs begin with axioms
and dish out theorems.

Formal Software Development Program Overview March 8, 2011 12 / 187

 What is formal software development Example: a simple formal system

The rules of our system

Formal Software Development Program Overview March 8, 2011 13 / 187

 What is formal software development Example: a simple formal system

The rules of our system

Our system has the following rules:

Formal Software Development Program Overview March 8, 2011 13 / 187

 What is formal software development Example: a simple formal system

The rules of our system

Our system has the following rules:

(r1) we can always deduce *

Formal Software Development Program Overview March 8, 2011 13 / 187

 What is formal software development Example: a simple formal system

The rules of our system

Our system has the following rules:

(r1) we can always deduce *

(r2) from X we can deduce Xb

Formal Software Development Program Overview March 8, 2011 13 / 187

 What is formal software development Example: a simple formal system

The rules of our system

Our system has the following rules:

(r1) we can always deduce *

(r2) from X we can deduce Xb
(r3) from X*Yb we can deduce aX*Yb

Formal Software Development Program Overview March 8, 2011 13 / 187

 What is formal software development Example: a simple formal system

The rules of our system

Our system has the following rules:

(r1) we can always deduce *

(r2) from X we can deduce Xb
(r3) from X*Yb we can deduce aX*Yb
(r4) from Xa*bY we can deduce X*Y

Formal Software Development Program Overview March 8, 2011 13 / 187

 What is formal software development Example: a simple formal system

The rules of our system

Our system has the following rules:

(r1) we can always deduce *

(r2) from X we can deduce Xb
(r3) from X*Yb we can deduce aX*Yb
(r4) from Xa*bY we can deduce X*Y

Formal Software Development Program Overview March 8, 2011 13 / 187

 What is formal software development Example: a simple formal system

The rules of our system

Our system has the following rules:

(r1) we can always deduce *

(r2) from X we can deduce Xb
(r3) from X*Yb we can deduce aX*Yb
(r4) from Xa*bY we can deduce X*Y

Since it has no premises, rule 1 is an axiom. You can apply the rules in any
order you wish, you do not have to go 2-3-4. This feature of formal systems
is called nondeterminism; we’ll review nondeterminism later, and a few
proofs that we build will also emphasize it.

Formal Software Development Program Overview March 8, 2011 13 / 187

 What is formal software development Example: a simple formal system

The rules of our system

Our system has the following rules:

(r1) we can always deduce *

(r2) from X we can deduce Xb
(r3) from X*Yb we can deduce aX*Yb
(r4) from Xa*bY we can deduce X*Y

Since it has no premises, rule 1 is an axiom. You can apply the rules in any
order you wish, you do not have to go 2-3-4. This feature of formal systems
is called nondeterminism; we’ll review nondeterminism later, and a few
proofs that we build will also emphasize it. We’ll call our example formal
system DANS.

Formal Software Development Program Overview March 8, 2011 13 / 187

 What is formal software development Example: a simple formal system

Proving theorems with our formal system

Formal Software Development Program Overview March 8, 2011 14 / 187

 What is formal software development Example: a simple formal system

Proving theorems with our formal system

Let’s look at some proofs in DANS; we’ll number the steps of a proof as #1,
#2, and so on. Each step will contain the theorem proved at that step and,
in parentheses, how we proved it (which must be a rule applied to previously
proved steps).

Formal Software Development Program Overview March 8, 2011 14 / 187

 What is formal software development Example: a simple formal system

Proving theorems with our formal system

Let’s look at some proofs in DANS; we’ll number the steps of a proof as #1,
#2, and so on. Each step will contain the theorem proved at that step and,
in parentheses, how we proved it (which must be a rule applied to previously
proved steps).

Theorem: a*bb

Formal Software Development Program Overview March 8, 2011 14 / 187

 What is formal software development Example: a simple formal system

Proving theorems with our formal system

Let’s look at some proofs in DANS; we’ll number the steps of a proof as #1,
#2, and so on. Each step will contain the theorem proved at that step and,
in parentheses, how we proved it (which must be a rule applied to previously
proved steps).

Theorem: a*bb

Proof.
#1: * (r1)

Formal Software Development Program Overview March 8, 2011 14 / 187

 What is formal software development Example: a simple formal system

Proving theorems with our formal system

Let’s look at some proofs in DANS; we’ll number the steps of a proof as #1,
#2, and so on. Each step will contain the theorem proved at that step and,
in parentheses, how we proved it (which must be a rule applied to previously
proved steps).

Theorem: a*bb

Proof.
#1: * (r1)
#2: *b (#1,r2)

Formal Software Development Program Overview March 8, 2011 14 / 187

 What is formal software development Example: a simple formal system

Proving theorems with our formal system

Let’s look at some proofs in DANS; we’ll number the steps of a proof as #1,
#2, and so on. Each step will contain the theorem proved at that step and,
in parentheses, how we proved it (which must be a rule applied to previously
proved steps).

Theorem: a*bb

Proof.
#1: * (r1)
#2: *b (#1,r2)
#3: a*b (#2,r3)

Formal Software Development Program Overview March 8, 2011 14 / 187

 What is formal software development Example: a simple formal system

Proving theorems with our formal system

Let’s look at some proofs in DANS; we’ll number the steps of a proof as #1,
#2, and so on. Each step will contain the theorem proved at that step and,
in parentheses, how we proved it (which must be a rule applied to previously
proved steps).

Theorem: a*bb

Proof.
#1: * (r1)
#2: *b (#1,r2)
#3: a*b (#2,r3)
#4: a*bb (#2,r2)

Formal Software Development Program Overview March 8, 2011 14 / 187

 What is formal software development Example: a simple formal system

Proof objects

Formal Software Development Program Overview March 8, 2011 15 / 187

 What is formal software development Example: a simple formal system

Proof objects
This form of a proof is known as a proof object.

Formal Software Development Program Overview March 8, 2011 15 / 187

 What is formal software development Example: a simple formal system

Proof objects
This form of a proof is known as a proof object. So

{#1: * (r1); #2: *b (#1,r2); #3: a*b (#2,r3); #4: a*bb (#2,r2)}

is a proof object.

Formal Software Development Program Overview March 8, 2011 15 / 187

 What is formal software development Example: a simple formal system

Proof objects
This form of a proof is known as a proof object. So

{#1: * (r1); #2: *b (#1,r2); #3: a*b (#2,r3); #4: a*bb (#2,r2)}

is a proof object. Proof objects are important because anyone who is given
the language and rules of DANS could verify the steps of the proof.

Formal Software Development Program Overview March 8, 2011 15 / 187

 What is formal software development Example: a simple formal system

Proof objects
This form of a proof is known as a proof object. So

{#1: * (r1); #2: *b (#1,r2); #3: a*b (#2,r3); #4: a*bb (#2,r2)}

is a proof object. Proof objects are important because anyone who is given
the language and rules of DANS could verify the steps of the proof. Let’s
remark that a theorem can have many proofs; we could have proved a*bb
with this proof object:

{#1: * (r1); #2: *b (#1,r2);#3: *bb (#2,r2); #4: a*bb (#2,r3)}

Formal Software Development Program Overview March 8, 2011 15 / 187

 What is formal software development Example: a simple formal system

Proof objects
This form of a proof is known as a proof object. So

{#1: * (r1); #2: *b (#1,r2); #3: a*b (#2,r3); #4: a*bb (#2,r2)}

is a proof object. Proof objects are important because anyone who is given
the language and rules of DANS could verify the steps of the proof. Let’s
remark that a theorem can have many proofs; we could have proved a*bb
with this proof object:

{#1: * (r1); #2: *b (#1,r2);#3: *bb (#2,r2); #4: a*bb (#2,r3)}

A more complete description of a proof would include not just the proof
object, but the entire formal system attached. This is sometimes called a
proof certificate.

Formal Software Development Program Overview March 8, 2011 15 / 187

 What is formal software development Example: a simple formal system

Proof objects
This form of a proof is known as a proof object. So

{#1: * (r1); #2: *b (#1,r2); #3: a*b (#2,r3); #4: a*bb (#2,r2)}

is a proof object. Proof objects are important because anyone who is given
the language and rules of DANS could verify the steps of the proof. Let’s
remark that a theorem can have many proofs; we could have proved a*bb
with this proof object:

{#1: * (r1); #2: *b (#1,r2);#3: *bb (#2,r2); #4: a*bb (#2,r3)}

A more complete description of a proof would include not just the proof
object, but the entire formal system attached. This is sometimes called a
proof certificate. So {[DANS] #1: * (r1); #2: *b (#1,r2); #3: a*b
(#2,r3); #4: a*bb (#2,r2)} would be a proof certificate. If you emailed me
this proof certificate, I would know exactly what you proved.

Formal Software Development Program Overview March 8, 2011 15 / 187

 What is formal software development Example: a simple formal system

Proof objects
This form of a proof is known as a proof object. So

{#1: * (r1); #2: *b (#1,r2); #3: a*b (#2,r3); #4: a*bb (#2,r2)}

is a proof object. Proof objects are important because anyone who is given
the language and rules of DANS could verify the steps of the proof. Let’s
remark that a theorem can have many proofs; we could have proved a*bb
with this proof object:

{#1: * (r1); #2: *b (#1,r2);#3: *bb (#2,r2); #4: a*bb (#2,r3)}

A more complete description of a proof would include not just the proof
object, but the entire formal system attached. This is sometimes called a
proof certificate. So {[DANS] #1: * (r1); #2: *b (#1,r2); #3: a*b
(#2,r3); #4: a*bb (#2,r2)} would be a proof certificate. If you emailed me
this proof certificate, I would know exactly what you proved. But most of
the time, the formal system is part of the discourse, so proof objects are
sufficient.
Formal Software Development Program Overview March 8, 2011 15 / 187
 What is formal software development Metamathematics

Moving up a level

Formal Software Development Program Overview March 8, 2011 16 / 187

 What is formal software development Metamathematics

Moving up a level
We now know how to do proofs (in other words, how to reason within
the system)

Formal Software Development Program Overview March 8, 2011 16 / 187

 What is formal software development Metamathematics

Moving up a level
We now know how to do proofs (in other words, how to reason within
the system)
There is a large variety of such formal systems

Formal Software Development Program Overview March 8, 2011 16 / 187

 What is formal software development Metamathematics

Moving up a level
We now know how to do proofs (in other words, how to reason within
the system)
There is a large variety of such formal systems
Most of the mathematics you ever learned can be cranked out by such
formal systems (see mizar.org)

Formal Software Development Program Overview March 8, 2011 16 / 187

 What is formal software development Metamathematics

Moving up a level
We now know how to do proofs (in other words, how to reason within
the system)
There is a large variety of such formal systems
Most of the mathematics you ever learned can be cranked out by such
formal systems (see mizar.org)
The foundations of software can also be cranked out by formal systems,
as we’ll see soon

Formal Software Development Program Overview March 8, 2011 16 / 187

 What is formal software development Metamathematics

Moving up a level
We now know how to do proofs (in other words, how to reason within
the system)
There is a large variety of such formal systems
Most of the mathematics you ever learned can be cranked out by such
formal systems (see mizar.org)
The foundations of software can also be cranked out by formal systems,
as we’ll see soon
Now comes a big switch of perspective . . .

Formal Software Development Program Overview March 8, 2011 16 / 187

 What is formal software development Metamathematics

Moving up a level
We now know how to do proofs (in other words, how to reason within
the system)
There is a large variety of such formal systems
Most of the mathematics you ever learned can be cranked out by such
formal systems (see mizar.org)
The foundations of software can also be cranked out by formal systems,
as we’ll see soon
Now comes a big switch of perspective . . .
These formal systems have some important properties, which can be
studied with the use of mathematics

Formal Software Development Program Overview March 8, 2011 16 / 187

 What is formal software development Metamathematics

Moving up a level
We now know how to do proofs (in other words, how to reason within
the system)
There is a large variety of such formal systems
Most of the mathematics you ever learned can be cranked out by such
formal systems (see mizar.org)
The foundations of software can also be cranked out by formal systems,
as we’ll see soon
Now comes a big switch of perspective . . .
These formal systems have some important properties, which can be
studied with the use of mathematics
This study comes with a grand name: metamathematics, i.e. the study
of mathematics itself

Formal Software Development Program Overview March 8, 2011 16 / 187

 What is formal software development Metamathematics

Moving up a level
We now know how to do proofs (in other words, how to reason within
the system)
There is a large variety of such formal systems
Most of the mathematics you ever learned can be cranked out by such
formal systems (see mizar.org)
The foundations of software can also be cranked out by formal systems,
as we’ll see soon
Now comes a big switch of perspective . . .
These formal systems have some important properties, which can be
studied with the use of mathematics
This study comes with a grand name: metamathematics, i.e. the study
of mathematics itself
We’ll do a lot of metamathematics in this program

Formal Software Development Program Overview March 8, 2011 16 / 187

 What is formal software development Metamathematics

Moving up a level
We now know how to do proofs (in other words, how to reason within
the system)
There is a large variety of such formal systems
Most of the mathematics you ever learned can be cranked out by such
formal systems (see mizar.org)
The foundations of software can also be cranked out by formal systems,
as we’ll see soon
Now comes a big switch of perspective . . .
These formal systems have some important properties, which can be
studied with the use of mathematics
This study comes with a grand name: metamathematics, i.e. the study
of mathematics itself
We’ll do a lot of metamathematics in this program
And metasoftware, if you wish

Formal Software Development Program Overview March 8, 2011 16 / 187

 What is formal software development Metamathematics

Moving up a level
We now know how to do proofs (in other words, how to reason within
the system)
There is a large variety of such formal systems
Most of the mathematics you ever learned can be cranked out by such
formal systems (see mizar.org)
The foundations of software can also be cranked out by formal systems,
as we’ll see soon
Now comes a big switch of perspective . . .
These formal systems have some important properties, which can be
studied with the use of mathematics
This study comes with a grand name: metamathematics, i.e. the study
of mathematics itself
We’ll do a lot of metamathematics in this program
And metasoftware, if you wish
Meta just means ‘outside’ or ‘about’
Formal Software Development Program Overview March 8, 2011 16 / 187
 What is formal software development Metamathematics

Meta level and object level

Formal Software Development Program Overview March 8, 2011 17 / 187

 What is formal software development Metamathematics

Meta level and object level

To distinguish it from metamathematics, mathematics inside the formal

system is called object level mathematics; the language of the formal system
is the object language.

Formal Software Development Program Overview March 8, 2011 17 / 187

 What is formal software development Metamathematics

Meta level and object level

To distinguish it from metamathematics, mathematics inside the formal

system is called object level mathematics; the language of the formal system
is the object language. We’ll use mostly informal language when working at
the meta level in this overview.

Formal Software Development Program Overview March 8, 2011 17 / 187

 What is formal software development Metamathematics

Meta level and object level

To distinguish it from metamathematics, mathematics inside the formal

system is called object level mathematics; the language of the formal system
is the object language. We’ll use mostly informal language when working at
the meta level in this overview. But keep in mind that some of the tools we
study are able to do metamathematics formally, i.e. we can create and
analyze formal systems within another formal system.

Formal Software Development Program Overview March 8, 2011 17 / 187

 What is formal software development Metamathematics

Meta level and object level

To distinguish it from metamathematics, mathematics inside the formal

system is called object level mathematics; the language of the formal system
is the object language. We’ll use mostly informal language when working at
the meta level in this overview. But keep in mind that some of the tools we
study are able to do metamathematics formally, i.e. we can create and
analyze formal systems within another formal system. The ML (Meta
Language) programming language was created precisely for the purpose of
doing metamathematics. OCaml and F# are its descendants.

Formal Software Development Program Overview March 8, 2011 17 / 187

 What is formal software development Metamathematics

Meta level and object level

To distinguish it from metamathematics, mathematics inside the formal

system is called object level mathematics; the language of the formal system
is the object language. We’ll use mostly informal language when working at
the meta level in this overview. But keep in mind that some of the tools we
study are able to do metamathematics formally, i.e. we can create and
analyze formal systems within another formal system. The ML (Meta
Language) programming language was created precisely for the purpose of
doing metamathematics. OCaml and F# are its descendants. We’ll study
them in the ‘ML Languages and Provers’ course.

Formal Software Development Program Overview March 8, 2011 17 / 187

 What is formal software development Metamathematics

Meta level and object level

To distinguish it from metamathematics, mathematics inside the formal

system is called object level mathematics; the language of the formal system
is the object language. We’ll use mostly informal language when working at
the meta level in this overview. But keep in mind that some of the tools we
study are able to do metamathematics formally, i.e. we can create and
analyze formal systems within another formal system. The ML (Meta
Language) programming language was created precisely for the purpose of
doing metamathematics. OCaml and F# are its descendants. We’ll study
them in the ‘ML Languages and Provers’ course. So let’s get used to some
of this ‘meta’ terminology:

Formal Software Development Program Overview March 8, 2011 17 / 187

 What is formal software development Metamathematics

Meta level and object level

To distinguish it from metamathematics, mathematics inside the formal

system is called object level mathematics; the language of the formal system
is the object language. We’ll use mostly informal language when working at
the meta level in this overview. But keep in mind that some of the tools we
study are able to do metamathematics formally, i.e. we can create and
analyze formal systems within another formal system. The ML (Meta
Language) programming language was created precisely for the purpose of
doing metamathematics. OCaml and F# are its descendants. We’ll study
them in the ‘ML Languages and Provers’ course. So let’s get used to some
of this ‘meta’ terminology:
metalanguage (the language in which we reason about the formal system)

Formal Software Development Program Overview March 8, 2011 17 / 187

 What is formal software development Metamathematics

Meta level and object level

To distinguish it from metamathematics, mathematics inside the formal

system is called object level mathematics; the language of the formal system
is the object language. We’ll use mostly informal language when working at
the meta level in this overview. But keep in mind that some of the tools we
study are able to do metamathematics formally, i.e. we can create and
analyze formal systems within another formal system. The ML (Meta
Language) programming language was created precisely for the purpose of
doing metamathematics. OCaml and F# are its descendants. We’ll study
them in the ‘ML Languages and Provers’ course. So let’s get used to some
of this ‘meta’ terminology:
metalanguage (the language in which we reason about the formal system)
metavariables (variables that do not belong to the object language)

Formal Software Development Program Overview March 8, 2011 17 / 187

 What is formal software development Metamathematics

Meta level and object level

To distinguish it from metamathematics, mathematics inside the formal

system is called object level mathematics; the language of the formal system
is the object language. We’ll use mostly informal language when working at
the meta level in this overview. But keep in mind that some of the tools we
study are able to do metamathematics formally, i.e. we can create and
analyze formal systems within another formal system. The ML (Meta
Language) programming language was created precisely for the purpose of
doing metamathematics. OCaml and F# are its descendants. We’ll study
them in the ‘ML Languages and Provers’ course. So let’s get used to some
of this ‘meta’ terminology:
metalanguage (the language in which we reason about the formal system)
metavariables (variables that do not belong to the object language)
metatheorem (a theorem about the system, not a theorem of the system)

Formal Software Development Program Overview March 8, 2011 17 / 187

 What is formal software development Metamathematics

Meta level and object level

To distinguish it from metamathematics, mathematics inside the formal

system is called object level mathematics; the language of the formal system
is the object language. We’ll use mostly informal language when working at
the meta level in this overview. But keep in mind that some of the tools we
study are able to do metamathematics formally, i.e. we can create and
analyze formal systems within another formal system. The ML (Meta
Language) programming language was created precisely for the purpose of
doing metamathematics. OCaml and F# are its descendants. We’ll study
them in the ‘ML Languages and Provers’ course. So let’s get used to some
of this ‘meta’ terminology:
metalanguage (the language in which we reason about the formal system)
metavariables (variables that do not belong to the object language)
metatheorem (a theorem about the system, not a theorem of the system)
metamathematics (study of formal systems themselves, from the outside)

Formal Software Development Program Overview March 8, 2011 17 / 187

 What is formal software development Metamathematics

The first big metamathematical question: Consistency

Formal Software Development Program Overview March 8, 2011 18 / 187

 What is formal software development Metamathematics

The first big metamathematical question: Consistency

Let’s do some metamathematics.

Formal Software Development Program Overview March 8, 2011 18 / 187

 What is formal software development Metamathematics

The first big metamathematical question: Consistency

Let’s do some metamathematics. Let’s say that all the wffs of a formal
system are theorems.

Formal Software Development Program Overview March 8, 2011 18 / 187

 What is formal software development Metamathematics

The first big metamathematical question: Consistency

Let’s do some metamathematics. Let’s say that all the wffs of a formal
system are theorems. In this case the formal system is worthless, the rules do
not accomplish anything useful.

Formal Software Development Program Overview March 8, 2011 18 / 187

 What is formal software development Metamathematics

The first big metamathematical question: Consistency

Let’s do some metamathematics. Let’s say that all the wffs of a formal
system are theorems. In this case the formal system is worthless, the rules do
not accomplish anything useful. So a formal system is said to be consistent
if not all wffs are theorems.

Formal Software Development Program Overview March 8, 2011 18 / 187

 What is formal software development Metamathematics

The first big metamathematical question: Consistency

Let’s do some metamathematics. Let’s say that all the wffs of a formal
system are theorems. In this case the formal system is worthless, the rules do
not accomplish anything useful. So a formal system is said to be consistent
if not all wffs are theorems.

Metatheorem: DANS is a consistent system

Formal Software Development Program Overview March 8, 2011 18 / 187

 What is formal software development Metamathematics

The first big metamathematical question: Consistency

Let’s do some metamathematics. Let’s say that all the wffs of a formal
system are theorems. In this case the formal system is worthless, the rules do
not accomplish anything useful. So a formal system is said to be consistent
if not all wffs are theorems.

Metatheorem: DANS is a consistent system

Proof. We show that b* is not a theorem. The axiom * has no b on the left.
No rules allow the introduction of a b on the left of the *.

Formal Software Development Program Overview March 8, 2011 18 / 187

 What is formal software development Metamathematics

Decidability of grammar and rules

Formal Software Development Program Overview March 8, 2011 19 / 187

 What is formal software development Metamathematics

Decidability of grammar and rules

Let’s look at the grammar and the inference rules of our example

Formal Software Development Program Overview March 8, 2011 19 / 187

 What is formal software development Metamathematics

Decidability of grammar and rules

Let’s look at the grammar and the inference rules of our example
We see that the grammar is decidable, i.e. there is an algorithm that,
given a formula, it will answer YES if the formula is a wff and NO if it
is not

Formal Software Development Program Overview March 8, 2011 19 / 187

 What is formal software development Metamathematics

Decidability of grammar and rules

Let’s look at the grammar and the inference rules of our example
We see that the grammar is decidable, i.e. there is an algorithm that,
given a formula, it will answer YES if the formula is a wff and NO if it
is not
Here is the grammar algorithm: given a formula X, count the number of
*. If the count is 1, answer YES, otherwise answer NO.

Formal Software Development Program Overview March 8, 2011 19 / 187

 What is formal software development Metamathematics

Decidability of grammar and rules

Let’s look at the grammar and the inference rules of our example
We see that the grammar is decidable, i.e. there is an algorithm that,
given a formula, it will answer YES if the formula is a wff and NO if it
is not
Here is the grammar algorithm: given a formula X, count the number of
*. If the count is 1, answer YES, otherwise answer NO.
The inference rules are also rigged in this special way, i.e. they are also
decidable

Formal Software Development Program Overview March 8, 2011 19 / 187

 What is formal software development Metamathematics

Decidability of grammar and rules

Let’s look at the grammar and the inference rules of our example
We see that the grammar is decidable, i.e. there is an algorithm that,
given a formula, it will answer YES if the formula is a wff and NO if it
is not
Here is the grammar algorithm: given a formula X, count the number of
*. If the count is 1, answer YES, otherwise answer NO.
The inference rules are also rigged in this special way, i.e. they are also
decidable
By this we mean that for each rule, there is an algorithm that, given a
finite set of wffs, it will answer YES if the rule is applicable to them and
NO if it is not

Formal Software Development Program Overview March 8, 2011 19 / 187

 What is formal software development Metamathematics

Decidability of grammar and rules

Let’s look at the grammar and the inference rules of our example
We see that the grammar is decidable, i.e. there is an algorithm that,
given a formula, it will answer YES if the formula is a wff and NO if it
is not
Here is the grammar algorithm: given a formula X, count the number of
*. If the count is 1, answer YES, otherwise answer NO.
The inference rules are also rigged in this special way, i.e. they are also
decidable
By this we mean that for each rule, there is an algorithm that, given a
finite set of wffs, it will answer YES if the rule is applicable to them and
NO if it is not
For example, the algorithm for rule 4 is: find *. If we can find an a on
its left and a b on its right, then the answer is YES, otherwise it is NO.

Formal Software Development Program Overview March 8, 2011 19 / 187

 What is formal software development Metamathematics

Decidability of grammar and rules

Let’s look at the grammar and the inference rules of our example
We see that the grammar is decidable, i.e. there is an algorithm that,
given a formula, it will answer YES if the formula is a wff and NO if it
is not
Here is the grammar algorithm: given a formula X, count the number of
*. If the count is 1, answer YES, otherwise answer NO.
The inference rules are also rigged in this special way, i.e. they are also
decidable
By this we mean that for each rule, there is an algorithm that, given a
finite set of wffs, it will answer YES if the rule is applicable to them and
NO if it is not
For example, the algorithm for rule 4 is: find *. If we can find an a on
its left and a b on its right, then the answer is YES, otherwise it is NO.
Only one thing is left unclear: what exactly is an algorithm?

Formal Software Development Program Overview March 8, 2011 19 / 187

 What is formal software development Metamathematics

What is an algorithm?

Formal Software Development Program Overview March 8, 2011 20 / 187

 What is formal software development Metamathematics

What is an algorithm?
Informally we know it is something that can be expressed in a finite
number of steps, some sort of program maybe containing loops

Formal Software Development Program Overview March 8, 2011 20 / 187

 What is formal software development Metamathematics

What is an algorithm?
Informally we know it is something that can be expressed in a finite
number of steps, some sort of program maybe containing loops
Other informal ways to describe algorithms: computable or, the original
term used by Hilbert, finitary

Formal Software Development Program Overview March 8, 2011 20 / 187

 What is formal software development Metamathematics

What is an algorithm?
Informally we know it is something that can be expressed in a finite
number of steps, some sort of program maybe containing loops
Other informal ways to describe algorithms: computable or, the original
term used by Hilbert, finitary
It took a lot of work to come up with a convincing formal definition

Formal Software Development Program Overview March 8, 2011 20 / 187

 What is formal software development Metamathematics

What is an algorithm?
Informally we know it is something that can be expressed in a finite
number of steps, some sort of program maybe containing loops
Other informal ways to describe algorithms: computable or, the original
term used by Hilbert, finitary
It took a lot of work to come up with a convincing formal definition
The astonishing thing is that many alternative definitions kept coming,
and . . .

Formal Software Development Program Overview March 8, 2011 20 / 187

 What is formal software development Metamathematics

What is an algorithm?
Informally we know it is something that can be expressed in a finite
number of steps, some sort of program maybe containing loops
Other informal ways to describe algorithms: computable or, the original
term used by Hilbert, finitary
It took a lot of work to come up with a convincing formal definition
The astonishing thing is that many alternative definitions kept coming,
and . . .
All formal definitions of ‘algorithm’ were proven to be equivalent!

Formal Software Development Program Overview March 8, 2011 20 / 187

 What is formal software development Metamathematics

What is an algorithm?
Informally we know it is something that can be expressed in a finite
number of steps, some sort of program maybe containing loops
Other informal ways to describe algorithms: computable or, the original
term used by Hilbert, finitary
It took a lot of work to come up with a convincing formal definition
The astonishing thing is that many alternative definitions kept coming,
and . . .
All formal definitions of ‘algorithm’ were proven to be equivalent!
This equivalence theorem is one of the great accomplishments of the
20th century mathematics

Formal Software Development Program Overview March 8, 2011 20 / 187

 What is formal software development Metamathematics

What is an algorithm?
Informally we know it is something that can be expressed in a finite
number of steps, some sort of program maybe containing loops
Other informal ways to describe algorithms: computable or, the original
term used by Hilbert, finitary
It took a lot of work to come up with a convincing formal definition
The astonishing thing is that many alternative definitions kept coming,
and . . .
All formal definitions of ‘algorithm’ were proven to be equivalent!
This equivalence theorem is one of the great accomplishments of the
20th century mathematics
The best known definitions are: Gödel’s recursive functions, Turing ma-
chines and Church’s Lambda Calculus

Formal Software Development Program Overview March 8, 2011 20 / 187

 What is formal software development Metamathematics

What is an algorithm?
Informally we know it is something that can be expressed in a finite
number of steps, some sort of program maybe containing loops
Other informal ways to describe algorithms: computable or, the original
term used by Hilbert, finitary
It took a lot of work to come up with a convincing formal definition
The astonishing thing is that many alternative definitions kept coming,
and . . .
All formal definitions of ‘algorithm’ were proven to be equivalent!
This equivalence theorem is one of the great accomplishments of the
20th century mathematics
The best known definitions are: Gödel’s recursive functions, Turing ma-
chines and Church’s Lambda Calculus
I Turing machines led to imperative languages like C, Java, C#

Formal Software Development Program Overview March 8, 2011 20 / 187

 What is formal software development Metamathematics

What is an algorithm?
Informally we know it is something that can be expressed in a finite
number of steps, some sort of program maybe containing loops
Other informal ways to describe algorithms: computable or, the original
term used by Hilbert, finitary
It took a lot of work to come up with a convincing formal definition
The astonishing thing is that many alternative definitions kept coming,
and . . .
All formal definitions of ‘algorithm’ were proven to be equivalent!
This equivalence theorem is one of the great accomplishments of the
20th century mathematics
The best known definitions are: Gödel’s recursive functions, Turing ma-
chines and Church’s Lambda Calculus
I Turing machines led to imperative languages like C, Java, C#
I Church’s Lambda Calculus led to functional languages like Lisp,

ML, Haskell
Formal Software Development Program Overview March 8, 2011 20 / 187
 What is formal software development Metamathematics

The Church-Turing thesis

Formal Software Development Program Overview March 8, 2011 21 / 187

 What is formal software development Metamathematics

The Church-Turing thesis

The above equivalent formal definitions capture the informal notion of

computability or algorithm.

Formal Software Development Program Overview March 8, 2011 21 / 187

 What is formal software development Metamathematics

The Church-Turing thesis

The above equivalent formal definitions capture the informal notion of

computability or algorithm.

This is not a theorem, it is a thesis, so there is no question of proving it. It

captures the belief that humanity has nailed the concept of computability,
that there exists no other mechanism that deserves to be called an algorithm.

Formal Software Development Program Overview March 8, 2011 21 / 187

 What is formal software development Metamathematics

Formal systems are rigged in a very special way

Formal Software Development Program Overview March 8, 2011 22 / 187

 What is formal software development Metamathematics

Formal systems are rigged in a very special way

This overview is not the place to describe any of the above formal defi-
nitions of computability

Formal Software Development Program Overview March 8, 2011 22 / 187

 What is formal software development Metamathematics

Formal systems are rigged in a very special way

This overview is not the place to describe any of the above formal defi-
nitions of computability
(we’ll cover this in the ‘Logic and Computation’ course)

Formal Software Development Program Overview March 8, 2011 22 / 187

 What is formal software development Metamathematics

Formal systems are rigged in a very special way

This overview is not the place to describe any of the above formal defi-
nitions of computability
(we’ll cover this in the ‘Logic and Computation’ course)
All we need to know for now is that such a rigorous definition exists

Formal Software Development Program Overview March 8, 2011 22 / 187

 What is formal software development Metamathematics

Formal systems are rigged in a very special way

This overview is not the place to describe any of the above formal defi-
nitions of computability
(we’ll cover this in the ‘Logic and Computation’ course)
All we need to know for now is that such a rigorous definition exists
Therefore, decidability, which lacked the rigorous definition of algorithm,
is now rigorously defined

Formal Software Development Program Overview March 8, 2011 22 / 187

 What is formal software development Metamathematics

Formal systems are rigged in a very special way

This overview is not the place to describe any of the above formal defi-
nitions of computability
(we’ll cover this in the ‘Logic and Computation’ course)
All we need to know for now is that such a rigorous definition exists
Therefore, decidability, which lacked the rigorous definition of algorithm,
is now rigorously defined
For all formal systems, the grammar is always rigged so that it is decidable

Formal Software Development Program Overview March 8, 2011 22 / 187

 What is formal software development Metamathematics

Formal systems are rigged in a very special way

This overview is not the place to describe any of the above formal defi-
nitions of computability
(we’ll cover this in the ‘Logic and Computation’ course)
All we need to know for now is that such a rigorous definition exists
Therefore, decidability, which lacked the rigorous definition of algorithm,
is now rigorously defined
For all formal systems, the grammar is always rigged so that it is decidable
The inference rules are also rigged so that they are decidable

Formal Software Development Program Overview March 8, 2011 22 / 187

 What is formal software development Metamathematics

Formal systems are rigged in a very special way

This overview is not the place to describe any of the above formal defi-
nitions of computability
(we’ll cover this in the ‘Logic and Computation’ course)
All we need to know for now is that such a rigorous definition exists
Therefore, decidability, which lacked the rigorous definition of algorithm,
is now rigorously defined
For all formal systems, the grammar is always rigged so that it is decidable
The inference rules are also rigged so that they are decidable
In one sentence, formal systems have computability built-in

Formal Software Development Program Overview March 8, 2011 22 / 187

 What is formal software development Metamathematics

The power of formal systems

Formal Software Development Program Overview March 8, 2011 23 / 187

 What is formal software development Metamathematics

The power of formal systems

Not only do they have computability built-in

Formal Software Development Program Overview March 8, 2011 23 / 187

 What is formal software development Metamathematics

The power of formal systems

Not only do they have computability built-in

They do not have any more computational power than Turing machines
have, they are yet another formalism equivalent to the other three

Formal Software Development Program Overview March 8, 2011 23 / 187

 What is formal software development Metamathematics

The power of formal systems

Not only do they have computability built-in

They do not have any more computational power than Turing machines
have, they are yet another formalism equivalent to the other three
Just as in the case of Turing machines, nondeterminism does not add
to this power, i.e. you can build an equivalent deterministic system that
produces the same theorems

Formal Software Development Program Overview March 8, 2011 23 / 187

 What is formal software development Metamathematics

The power of formal systems

Not only do they have computability built-in

They do not have any more computational power than Turing machines
have, they are yet another formalism equivalent to the other three
Just as in the case of Turing machines, nondeterminism does not add
to this power, i.e. you can build an equivalent deterministic system that
produces the same theorems

Formal Software Development Program Overview March 8, 2011 23 / 187

 What is formal software development Metamathematics

The power of formal systems

Not only do they have computability built-in

They do not have any more computational power than Turing machines
have, they are yet another formalism equivalent to the other three
Just as in the case of Turing machines, nondeterminism does not add
to this power, i.e. you can build an equivalent deterministic system that
produces the same theorems

So, for any theory that can be described algorithmically (and that’s all we
really need, but that’s philosophy), whether a mathematical theory, a
software theory, a physics theory, etc . . . , there is a formal system that can
describe it.

Formal Software Development Program Overview March 8, 2011 23 / 187

 What is formal software development Metamathematics

Back to our formal system

Formal Software Development Program Overview March 8, 2011 24 / 187

 What is formal software development Metamathematics

Back to our formal system

Because DANS has computability built in, we can do two things

Formal Software Development Program Overview March 8, 2011 24 / 187

 What is formal software development Metamathematics

Back to our formal system

Because DANS has computability built in, we can do two things

We can design a mechanical strategy that builds all the theorems of the
system, one after the other (exercise)

Formal Software Development Program Overview March 8, 2011 24 / 187

 What is formal software development Metamathematics

Back to our formal system

Because DANS has computability built in, we can do two things

We can design a mechanical strategy that builds all the theorems of the
system, one after the other (exercise)
We can design a mechanical strategy that, given a proof, answers YES
if the proof is correct, NO otherwise (exercise)

Formal Software Development Program Overview March 8, 2011 24 / 187

 What is formal software development Metamathematics

Back to our formal system

Because DANS has computability built in, we can do two things

We can design a mechanical strategy that builds all the theorems of the
system, one after the other (exercise)
We can design a mechanical strategy that, given a proof, answers YES
if the proof is correct, NO otherwise (exercise)
Notice that our formal system produces an infinite number of theorems,
so the procedure above potentially produces all the theorems, we can
never have all the theorems collected together as that set would be an
actual infinity, which is impossible to reach computationally

Formal Software Development Program Overview March 8, 2011 24 / 187

 What is formal software development Metamathematics

Back to our formal system

Because DANS has computability built in, we can do two things

We can design a mechanical strategy that builds all the theorems of the
system, one after the other (exercise)
We can design a mechanical strategy that, given a proof, answers YES
if the proof is correct, NO otherwise (exercise)
Notice that our formal system produces an infinite number of theorems,
so the procedure above potentially produces all the theorems, we can
never have all the theorems collected together as that set would be an
actual infinity, which is impossible to reach computationally
In formal systems, the infinite is always understood as this potential, not
actual, representation

Formal Software Development Program Overview March 8, 2011 24 / 187

 What is formal software development Metamathematics

Back to our formal system

Because DANS has computability built in, we can do two things

We can design a mechanical strategy that builds all the theorems of the
system, one after the other (exercise)
We can design a mechanical strategy that, given a proof, answers YES
if the proof is correct, NO otherwise (exercise)
Notice that our formal system produces an infinite number of theorems,
so the procedure above potentially produces all the theorems, we can
never have all the theorems collected together as that set would be an
actual infinity, which is impossible to reach computationally
In formal systems, the infinite is always understood as this potential, not
actual, representation
If this sounds difficult, think of the way natural numbers or lists are in-
troduced in your favorite functional language. The constructors embody
this potential infinity.

Formal Software Development Program Overview March 8, 2011 24 / 187

 What is formal software development Decidability

Decidability of our example

Formal Software Development Program Overview March 8, 2011 25 / 187

 What is formal software development Decidability

Decidability of our example

If we have a wff, how can we tell if it is a theorem or not?

Formal Software Development Program Overview March 8, 2011 25 / 187

 What is formal software development Decidability

Decidability of our example

If we have a wff, how can we tell if it is a theorem or not?

Does DANS have an algorithm that answers YES or NO to such a ques-
tion?

Formal Software Development Program Overview March 8, 2011 25 / 187

 What is formal software development Decidability

Decidability of our example

If we have a wff, how can we tell if it is a theorem or not?

Does DANS have an algorithm that answers YES or NO to such a ques-
tion?
This is a big fork in the road for the formal systems we study in the
program

Formal Software Development Program Overview March 8, 2011 25 / 187

 What is formal software development Decidability

Decidability of our example

If we have a wff, how can we tell if it is a theorem or not?

Does DANS have an algorithm that answers YES or NO to such a ques-
tion?
This is a big fork in the road for the formal systems we study in the
program
Some systems do admit such an algorithm (called a decision procedure),
others don’t

Formal Software Development Program Overview March 8, 2011 25 / 187

 What is formal software development Decidability

Decidability of our example

If we have a wff, how can we tell if it is a theorem or not?

Does DANS have an algorithm that answers YES or NO to such a ques-
tion?
This is a big fork in the road for the formal systems we study in the
program
Some systems do admit such an algorithm (called a decision procedure),
others don’t
Finding a decision procedure for a useful formal system (not a toy like
DANS) is a non-trivial effort

Formal Software Development Program Overview March 8, 2011 25 / 187

 What is formal software development Decidability

Decidability of our example

If we have a wff, how can we tell if it is a theorem or not?

Does DANS have an algorithm that answers YES or NO to such a ques-
tion?
This is a big fork in the road for the formal systems we study in the
program
Some systems do admit such an algorithm (called a decision procedure),
others don’t
Finding a decision procedure for a useful formal system (not a toy like
DANS) is a non-trivial effort
The more expressive the system (i.e. the more powerful its language and
rules of inference are), the less likely it is that it has such a procedure

Formal Software Development Program Overview March 8, 2011 25 / 187

 What is formal software development Decidability

DANS is decidable
ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 26 / 187

 What is formal software development Decidability

DANS is decidable
ip be
d
sk ay
pe
m

Metatheorem: Dans is a decidable system

The proof is by induction. Proofs by induction are typical of the

metamathematics of formal systems, that’s why we include one here. They
will be seen over and over during the program. Those unfamiliar with
mathematical induction may skip the proof.

We treat induction at length in the course ‘Formal semantics of

programming languages’. We also give a more detailed presentation of
induction and recursion, as they relate to categories, in a more advanced
section of this overview. For those who need a quick brush-up, we include
the definition of mathematical induction and one typical example of its use.

Formal Software Development Program Overview March 8, 2011 26 / 187

 What is formal software development Decidability

Mathematical Induction
ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 27 / 187

 What is formal software development Decidability

Mathematical Induction
ip be
d
sk ay
pe
m

Mathematical Induction

Let P(n) be a predicate on the set N of natural numbers. Then

(P(0) ∧ (∀k ∈ N.P(k) → P(k + 1))) → ∀n ∈ N.P(n)

Formal Software Development Program Overview March 8, 2011 27 / 187

 What is formal software development Decidability

A typical proof by mathematical induction

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 28 / 187

 What is formal software development Decidability

A typical proof by mathematical induction

The sum of the first n natural numbers is given by
ip be
d
sk ay
pe
m

n
n(n + 1)
∑i= 2
(1)
i=0

Formal Software Development Program Overview March 8, 2011 28 / 187

 What is formal software development Decidability

A typical proof by mathematical induction

The sum of the first n natural numbers is given by
ip be
d
sk ay
pe
m

n
n(n + 1)
∑i= 2
(1)
i=0
Proof:

Formal Software Development Program Overview March 8, 2011 28 / 187

 What is formal software development Decidability

A typical proof by mathematical induction

The sum of the first n natural numbers is given by
ip be
d
sk ay
pe
m

n
n(n + 1)
∑i= 2
(1)
i=0
Proof:
1 Let P(n) be the property given by (1)

Formal Software Development Program Overview March 8, 2011 28 / 187

 What is formal software development Decidability

A typical proof by mathematical induction

The sum of the first n natural numbers is given by
ip be
d
sk ay
pe
m

n
n(n + 1)
∑i= 2
(1)
i=0
Proof:
1 Let P(n) be the property given by (1)
0(0 + 1)
2 P(0) is true, because 0 =
2

Formal Software Development Program Overview March 8, 2011 28 / 187

 What is formal software development Decidability

A typical proof by mathematical induction

The sum of the first n natural numbers is given by
ip be
d
sk ay
pe
m

n
n(n + 1)
∑i= 2
(1)
i=0
Proof:
1 Let P(n) be the property given by (1)
0(0 + 1)
2 P(0) is true, because 0 =
2
k
k(k + 1)
3 Assume P(k) is true, i.e. ∑i=
i=0 2

Formal Software Development Program Overview March 8, 2011 28 / 187

 What is formal software development Decidability

A typical proof by mathematical induction

The sum of the first n natural numbers is given by
ip be
d
sk ay
pe
m

n
n(n + 1)
∑i= 2
(1)
i=0
Proof:
1 Let P(n) be the property given by (1)
0(0 + 1)
2 P(0) is true, because 0 =
2
k
k(k + 1)
3 Assume P(k) is true, i.e. ∑i=
i=0 2
k+1
k(k + 1) k(k + 1) + 2(k + 1) (k + 1)(k + 2)
4 Then ∑i= + (k + 1) = =
i=0 2 2 2

Formal Software Development Program Overview March 8, 2011 28 / 187

 What is formal software development Decidability

A typical proof by mathematical induction

The sum of the first n natural numbers is given by
ip be
d
sk ay
pe
m

n
n(n + 1)
∑i= 2
(1)
i=0
Proof:
1 Let P(n) be the property given by (1)
0(0 + 1)
2 P(0) is true, because 0 =
2
k
k(k + 1)
3 Assume P(k) is true, i.e. ∑i=
i=0 2
k+1
k(k + 1) k(k + 1) + 2(k + 1) (k + 1)(k + 2)
4 Then ∑i= + (k + 1) = =
i=0 2 2 2
k+1
(k + 1)(k + 2)
5 But ∑i= is exactly P(k + 1)
i=0 2

Formal Software Development Program Overview March 8, 2011 28 / 187

 What is formal software development Decidability

A typical proof by mathematical induction

The sum of the first n natural numbers is given by
ip be
d
sk ay
pe
m

n
n(n + 1)
∑i= 2
(1)
i=0
Proof:
1 Let P(n) be the property given by (1)
0(0 + 1)
2 P(0) is true, because 0 =
2
k
k(k + 1)
3 Assume P(k) is true, i.e. ∑i=
i=0 2
k+1
k(k + 1) k(k + 1) + 2(k + 1) (k + 1)(k + 2)
4 Then ∑i= + (k + 1) = =
i=0 2 2 2
k+1
(k + 1)(k + 2)
5 But ∑i= is exactly P(k + 1)
i=0 2
6 By mathematical induction, the formula (1) is true for all n ∈ N
Formal Software Development Program Overview March 8, 2011 28 / 187
 What is formal software development Decidability

Proof that DANS is decidable

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 29 / 187

 What is formal software development Decidability

Proof that DANS is decidable

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 29 / 187

 What is formal software development Decidability

Proof that DANS is decidable

ip be
d
sk ay
pe
m

Proof.
Let’s consider the wffs having the property (called P) that they contain

Formal Software Development Program Overview March 8, 2011 29 / 187

 What is formal software development Decidability

Proof that DANS is decidable

ip be
d
sk ay
pe
m

Proof.
Let’s consider the wffs having the property (called P) that they contain
I a single *

Formal Software Development Program Overview March 8, 2011 29 / 187

 What is formal software development Decidability

Proof that DANS is decidable

ip be
d
sk ay
pe
m

Proof.
Let’s consider the wffs having the property (called P) that they contain
I a single *
I only a’s on the left, only b’s on the right

Formal Software Development Program Overview March 8, 2011 29 / 187

 What is formal software development Decidability

Proof that DANS is decidable

ip be
d
sk ay
pe
m

Proof.
Let’s consider the wffs having the property (called P) that they contain
I a single *
I only a’s on the left, only b’s on the right
I less a’s than b’s

Formal Software Development Program Overview March 8, 2011 29 / 187

 What is formal software development Decidability

Proof that DANS is decidable

ip be
d
sk ay
pe
m

Proof.
Let’s consider the wffs having the property (called P) that they contain
I a single *
I only a’s on the left, only b’s on the right
I less a’s than b’s
We will prove that all theorems have this property. The metaproof is by
induction on the length of the object proof.

Formal Software Development Program Overview March 8, 2011 29 / 187

 What is formal software development Decidability

Proof that DANS is decidable

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 30 / 187

 What is formal software development Decidability

Proof that DANS is decidable

ip be
d
sk ay
pe
m

If the proof has length 1, then the theorem must be * and this has the
property P

Formal Software Development Program Overview March 8, 2011 30 / 187

 What is formal software development Decidability

Proof that DANS is decidable

ip be
d
sk ay
pe
m

If the proof has length 1, then the theorem must be * and this has the
property P
Assume all theorems whose proofs have length smaller or equal to n have
this property P

Formal Software Development Program Overview March 8, 2011 30 / 187

 What is formal software development Decidability

Proof that DANS is decidable

ip be
d
sk ay
pe
m

If the proof has length 1, then the theorem must be * and this has the
property P
Assume all theorems whose proofs have length smaller or equal to n have
this property P
Let p1 , . . . , pn+1 be a proof of length n + 1. Then pn+1 must have been
deduced from pn by one of the rules 2,3, or 4. Now since the proof of pn
has length n, by the induction hypothesis, pn has property P. But then
pn+1 must also have property P because rules 2,3, and 4 all preserve this
property.

Formal Software Development Program Overview March 8, 2011 30 / 187

 What is formal software development The central role of induction

The central role of induction

Formal Software Development Program Overview March 8, 2011 31 / 187

 What is formal software development The central role of induction

The central role of induction

The most important proof technique of metamathematics

Formal Software Development Program Overview March 8, 2011 31 / 187

 What is formal software development The central role of induction

The central role of induction

The most important proof technique of metamathematics

(we already saw some of its uses)

Formal Software Development Program Overview March 8, 2011 31 / 187

 What is formal software development The central role of induction

The central role of induction

The most important proof technique of metamathematics

(we already saw some of its uses)
Induction itself can be formalized, for example, inside one of the most
basic formal systems, Primitive Recursive Arithmetic (PRA), a sublogic
of the better-known Peano Arithmetic

Formal Software Development Program Overview March 8, 2011 31 / 187

 What is formal software development The central role of induction

The central role of induction

The most important proof technique of metamathematics

(we already saw some of its uses)
Induction itself can be formalized, for example, inside one of the most
basic formal systems, Primitive Recursive Arithmetic (PRA), a sublogic
of the better-known Peano Arithmetic
We study PRA in the ‘Main Concepts of Logic’ course

Formal Software Development Program Overview March 8, 2011 31 / 187

 What is formal software development The central role of induction

The central role of induction

Formal Software Development Program Overview March 8, 2011 32 / 187

 What is formal software development The central role of induction

The central role of induction

Induction is so ubiquitous in our program because

Formal Software Development Program Overview March 8, 2011 32 / 187

 What is formal software development The central role of induction

The central role of induction

Induction is so ubiquitous in our program because

I the formation rules are defined inductively

Formal Software Development Program Overview March 8, 2011 32 / 187

 What is formal software development The central role of induction

The central role of induction

Induction is so ubiquitous in our program because

I the formation rules are defined inductively
I the inference rules are defined inductively

Formal Software Development Program Overview March 8, 2011 32 / 187

 What is formal software development The central role of induction

The central role of induction

Induction is so ubiquitous in our program because

I the formation rules are defined inductively
I the inference rules are defined inductively
I the grammar of programing languages is defined inductively

Formal Software Development Program Overview March 8, 2011 32 / 187

 What is formal software development The central role of induction

The central role of induction

Induction is so ubiquitous in our program because

I the formation rules are defined inductively
I the inference rules are defined inductively
I the grammar of programing languages is defined inductively
I algebraic data is defined inductively (and it is known that any com-
putational form of data can be described algebraically)

Formal Software Development Program Overview March 8, 2011 32 / 187

 What is formal software development The central role of induction

So should we pick PRA as the base logic and be done?

Formal Software Development Program Overview March 8, 2011 33 / 187

 What is formal software development The central role of induction

So should we pick PRA as the base logic and be done?

We will also see in the section on code verification, that the main method of
verification is using an axiomatic semantics of the programming language to
do induction over the structure of the program.

Formal Software Development Program Overview March 8, 2011 33 / 187

 What is formal software development The central role of induction

So should we pick PRA as the base logic and be done?

We will also see in the section on code verification, that the main method of
verification is using an axiomatic semantics of the programming language to
do induction over the structure of the program. So if induction is so
important for both the study of formal systems themselves and their
applications to software verification, why not do everything with an inductive
prover?

Formal Software Development Program Overview March 8, 2011 33 / 187

 What is formal software development The central role of induction

So should we pick PRA as the base logic and be done?

We will also see in the section on code verification, that the main method of
verification is using an axiomatic semantics of the programming language to
do induction over the structure of the program. So if induction is so
important for both the study of formal systems themselves and their
applications to software verification, why not do everything with an inductive
prover?
Some software development can indeed be based on PRA and inductive
provers

Formal Software Development Program Overview March 8, 2011 33 / 187

 What is formal software development The central role of induction

So should we pick PRA as the base logic and be done?

We will also see in the section on code verification, that the main method of
verification is using an axiomatic semantics of the programming language to
do induction over the structure of the program. So if induction is so
important for both the study of formal systems themselves and their
applications to software verification, why not do everything with an inductive
prover?
Some software development can indeed be based on PRA and inductive
provers
We study them in the ‘Lisp and Inductive Provers’ course

Formal Software Development Program Overview March 8, 2011 33 / 187

 What is formal software development The central role of induction

So should we pick PRA as the base logic and be done?

We will also see in the section on code verification, that the main method of
verification is using an axiomatic semantics of the programming language to
do induction over the structure of the program. So if induction is so
important for both the study of formal systems themselves and their
applications to software verification, why not do everything with an inductive
prover?
Some software development can indeed be based on PRA and inductive
provers
We study them in the ‘Lisp and Inductive Provers’ course
Best known such prover: ACL2

Formal Software Development Program Overview March 8, 2011 33 / 187

 What is formal software development The central role of induction

Choose the right prover for the job

Formal Software Development Program Overview March 8, 2011 34 / 187

 What is formal software development The central role of induction

Choose the right prover for the job

But we need a larger set of provers, some more automatic, some more
interactive

Formal Software Development Program Overview March 8, 2011 34 / 187

 What is formal software development The central role of induction

Choose the right prover for the job

But we need a larger set of provers, some more automatic, some more
interactive
This is an engineering job, look at many provers and decide what you
need

Formal Software Development Program Overview March 8, 2011 34 / 187

 What is formal software development The central role of induction

Choose the right prover for the job

But we need a larger set of provers, some more automatic, some more
interactive
This is an engineering job, look at many provers and decide what you
need
There are big differences between them

Formal Software Development Program Overview March 8, 2011 34 / 187

 What is formal software development The central role of induction

Choose the right prover for the job

But we need a larger set of provers, some more automatic, some more
interactive
This is an engineering job, look at many provers and decide what you
need
There are big differences between them
FOL Provers: more automatic, many efficient decision procedures can
be added

Formal Software Development Program Overview March 8, 2011 34 / 187

 What is formal software development The central role of induction

Choose the right prover for the job

But we need a larger set of provers, some more automatic, some more
interactive
This is an engineering job, look at many provers and decide what you
need
There are big differences between them
FOL Provers: more automatic, many efficient decision procedures can
be added
HOL provers: powerful, but require more trust and more theory

Formal Software Development Program Overview March 8, 2011 34 / 187

 What is formal software development The central role of induction

Choose the right prover for the job

But we need a larger set of provers, some more automatic, some more
interactive
This is an engineering job, look at many provers and decide what you
need
There are big differences between them
FOL Provers: more automatic, many efficient decision procedures can
be added
HOL provers: powerful, but require more trust and more theory
Type theory provers: even more powerful, but require even more trust
and theory

Formal Software Development Program Overview March 8, 2011 34 / 187

 What is formal software development The central role of induction

Choose the right prover for the job

But we need a larger set of provers, some more automatic, some more
interactive
This is an engineering job, look at many provers and decide what you
need
There are big differences between them
FOL Provers: more automatic, many efficient decision procedures can
be added
HOL provers: powerful, but require more trust and more theory
Type theory provers: even more powerful, but require even more trust
and theory
(why is trust an issue? Because the more powerful the logic, the easier
it is to become inconsistent)

Formal Software Development Program Overview March 8, 2011 34 / 187

 What is formal software development The central role of induction

Other terms used for formal systems

Formal Software Development Program Overview March 8, 2011 35 / 187

 What is formal software development The central role of induction

Other terms used for formal systems

In papers, books, www, etc . . . the terms formal system, logic system,
logic calculus, logic are used interchangeably (e.g., lambda calculus, but
combinatory logic). We’ll follow this loose tradition.

Formal Software Development Program Overview March 8, 2011 35 / 187

 What is formal software development The central role of induction

Other terms used for formal systems

In papers, books, www, etc . . . the terms formal system, logic system,
logic calculus, logic are used interchangeably (e.g., lambda calculus, but
combinatory logic). We’ll follow this loose tradition.

Formal Software Development Program Overview March 8, 2011 35 / 187

 What is formal software development The central role of induction

Other terms used for formal systems

In papers, books, www, etc . . . the terms formal system, logic system,
logic calculus, logic are used interchangeably (e.g., lambda calculus, but
combinatory logic). We’ll follow this loose tradition. On the other hand
the term theory is generally used in a more precise sense; namely it
is a specification of a special set of symbols (called a signature) and
additional rules, on top of a base formal system.

Formal Software Development Program Overview March 8, 2011 35 / 187

 What is formal software development The central role of induction

Other terms used for formal systems

In papers, books, www, etc . . . the terms formal system, logic system,
logic calculus, logic are used interchangeably (e.g., lambda calculus, but
combinatory logic). We’ll follow this loose tradition. On the other hand
the term theory is generally used in a more precise sense; namely it
is a specification of a special set of symbols (called a signature) and
additional rules, on top of a base formal system.
Often a logic includes a meaning for the language (i.e. a semantics); our
formal systems don’t.

Formal Software Development Program Overview March 8, 2011 35 / 187

 What is formal software development The central role of induction

Other terms used for formal systems

In papers, books, www, etc . . . the terms formal system, logic system,
logic calculus, logic are used interchangeably (e.g., lambda calculus, but
combinatory logic). We’ll follow this loose tradition. On the other hand
the term theory is generally used in a more precise sense; namely it
is a specification of a special set of symbols (called a signature) and
additional rules, on top of a base formal system.
Often a logic includes a meaning for the language (i.e. a semantics); our
formal systems don’t.
Sometimes a logic does not include a proof calculus, it includes only a
semantics!

Formal Software Development Program Overview March 8, 2011 35 / 187

 What is formal software development The central role of induction

Other terms used for formal systems

Formal Software Development Program Overview March 8, 2011 36 / 187

 What is formal software development The central role of induction

Other terms used for formal systems

Some people make no difference between metamathematics and mathe-

matical logic; originally, when Hilbert coined the term metamathematics,
the two fields were the same. But right now, most people consider math-
ematical logic to be a much broader field, and metamathematics to be
just the mathematical study of the rules of a formal system.

Formal Software Development Program Overview March 8, 2011 36 / 187

 What is formal software development The central role of induction

Other terms used for formal systems

Some people make no difference between metamathematics and mathe-

matical logic; originally, when Hilbert coined the term metamathematics,
the two fields were the same. But right now, most people consider math-
ematical logic to be a much broader field, and metamathematics to be
just the mathematical study of the rules of a formal system.
By the way, logic for us is always mathematical logic. Otherwise, logic
is a field of philosophy and we have no use for that.

Formal Software Development Program Overview March 8, 2011 36 / 187

 Implementing formal systems

1 What is formal software development

2 Implementing formal systems

3 When are proofs used

4 What formal software development is not

5 Formal verification of programs

6 Mathematics and Software

7 Concrete examples of what we do in the program

8 Program goals and course structure

Formal Software Development Program Overview March 8, 2011 37 / 187
 Implementing formal systems Machines

Machines

language: rules:

Formal Software Development Program Overview March 8, 2011 38 / 187

 Implementing formal systems Machines

Machines

We have learned how to produce

proofs manually
language: rules:

Formal Software Development Program Overview March 8, 2011 38 / 187

 Implementing formal systems Machines

Machines

We have learned how to produce

proofs manually
But a formal system is obviously language: rules:

meant to be used by a machine

Formal Software Development Program Overview March 8, 2011 38 / 187

 Implementing formal systems Machines

Machines

We have learned how to produce

proofs manually
But a formal system is obviously language: rules:

meant to be used by a machine

We now show how to build such a
machine

Formal Software Development Program Overview March 8, 2011 38 / 187

 Implementing formal systems Machines

Machines

We have learned how to produce

proofs manually
But a formal system is obviously language: rules:

meant to be used by a machine

We now show how to build such a
machine
The formal system appears at the
top of the machine

Formal Software Development Program Overview March 8, 2011 38 / 187

 Implementing formal systems Machines

Machines

We have learned how to produce

proofs manually
But a formal system is obviously language: rules:

meant to be used by a machine

We now show how to build such a
machine
The formal system appears at the
top of the machine

Formal Software Development Program Overview March 8, 2011 38 / 187

 Implementing formal systems Machines

Machines

We have learned how to produce

proofs manually
But a formal system is obviously language: rules:

meant to be used by a machine

We now show how to build such a
machine
The formal system appears at the
top of the machine
The output of the machine is also at
the top

Formal Software Development Program Overview March 8, 2011 38 / 187

 Implementing formal systems Machines

Machines

Theorem/proofs here ...

We have learned how to produce

proofs manually
But a formal system is obviously language: rules:

meant to be used by a machine

We now show how to build such a
machine
The formal system appears at the
top of the machine
The output of the machine is also at
the top

Formal Software Development Program Overview March 8, 2011 38 / 187

 Implementing formal systems Machines

Machines

Theorem/proofs here ...

We have learned how to produce

proofs manually
But a formal system is obviously language: rules:

meant to be used by a machine

We now show how to build such a
machine
The formal system appears at the
top of the machine
The output of the machine is also at
the top
The top is the ‘object level’ of the
machine

Formal Software Development Program Overview March 8, 2011 38 / 187

 Implementing formal systems Machines

Building the DANS machine

Formal Software Development Program Overview March 8, 2011 39 / 187

 Implementing formal systems Machines

Building the DANS machine

language: rules:

So let’s take the DANS language (L-

DANS) and the rules (R-DANS) and build
a machine around this formal system.

Formal Software Development Program Overview March 8, 2011 39 / 187

 Implementing formal systems Machines

Building the DANS machine

So let’s take the DANS language (L- language: rules:

DANS) and the rules (R-DANS) and build
a machine around this formal system.

L-DANS R-DANS
... ...

Formal Software Development Program Overview March 8, 2011 39 / 187

 Implementing formal systems Machines

Building the DANS machine

language: rules:
L-DANS R-DANS
So let’s take the DANS language (L-
DANS) and the rules (R-DANS) and build
a machine around this formal system.

Formal Software Development Program Overview March 8, 2011 39 / 187

 Implementing formal systems Machines

Proof checking with the machine

Programming our machine is done

in metalanguage
language: rules:
L-DANS R-DANS

Formal Software Development Program Overview March 8, 2011 40 / 187

 Implementing formal systems Machines

Proof checking with the machine

Programming our machine is done

in metalanguage
We do not specify this metalan- language: rules:
L-DANS R-DANS
guage for now

Formal Software Development Program Overview March 8, 2011 40 / 187

 Implementing formal systems Machines

Proof checking with the machine

Programming our machine is done

in metalanguage
We do not specify this metalan- language: rules:
L-DANS R-DANS
guage for now
(many programming languages
could be used, ML in particular)

Formal Software Development Program Overview March 8, 2011 40 / 187

 Implementing formal systems Machines

Proof checking with the machine

Programming our machine is done

in metalanguage
We do not specify this metalan- language: rules:
L-DANS R-DANS
guage for now
(many programming languages
could be used, ML in particular)
The bottom half is the ‘metalevel’

Formal Software Development Program Overview March 8, 2011 40 / 187

 Implementing formal systems Machines

Proof checking with the machine

Programming our machine is done

in metalanguage
We do not specify this metalan- language: rules:
L-DANS R-DANS
guage for now
(many programming languages
could be used, ML in particular)
The bottom half is the ‘metalevel’
First thing we build is proof checking

Formal Software Development Program Overview March 8, 2011 40 / 187

 Implementing formal systems Machines

Proof checking with the machine

Programming our machine is done

in metalanguage
We do not specify this metalan- language: rules:
L-DANS R-DANS
guage for now
(many programming languages Object Level

could be used, ML in particular) Your proof here ...

The bottom half is the ‘metalevel’ tactics

First thing we build is proof checking checking

default Proof OK?

Meta
Level

Formal Software Development Program Overview March 8, 2011 40 / 187

 Implementing formal systems Machines

Proof checking with the machine

YES

Programming our machine is done

in metalanguage
We do not specify this metalan- language: rules:
L-DANS R-DANS
guage for now
(many programming languages Object Level

could be used, ML in particular) #1: * (r1); #2: *b

(#1,r2); #3: a*b (#2,r3);
The bottom half is the ‘metalevel’ tactics

First thing we build is proof checking checking

default Proof OK?
If we enter the proof object for a*b
and click on the green button, the
machine will check the proof and an- Meta
Level
swer YES

Formal Software Development Program Overview March 8, 2011 40 / 187

 Implementing formal systems Machines

Proof checking algorithms

YES

Notice that the proof checking algo-

rithm is marked default

language: rules:
L-DANS R-DANS

Object Level

#1: * (r1); #2: *b

(#1,r2); #3: a*b (#2,r3);

tactics

checking
default Proof OK?

Meta
Level

Formal Software Development Program Overview March 8, 2011 41 / 187

 Implementing formal systems Machines

Proof checking algorithms

YES

Notice that the proof checking algo-

rithm is marked default
DANS is a very simple system, so
language: rules:
default checking is OK
L-DANS R-DANS

Object Level

#1: * (r1); #2: *b

(#1,r2); #3: a*b (#2,r3);

tactics

checking
default Proof OK?

Meta
Level

Formal Software Development Program Overview March 8, 2011 41 / 187

 Implementing formal systems Machines

Proof checking algorithms

YES

Notice that the proof checking algo-

rithm is marked default
DANS is a very simple system, so
language: rules:
default checking is OK
L-DANS R-DANS

Default checking: for each step, just

Object Level
check that the rule in parentheses
has been applied correctly #1: * (r1); #2: *b
(#1,r2); #3: a*b (#2,r3);

tactics

checking
default Proof OK?

Meta
Level

Formal Software Development Program Overview March 8, 2011 41 / 187

 Implementing formal systems Machines

Proof checking algorithms

YES

Notice that the proof checking algo-

rithm is marked default
DANS is a very simple system, so
language: rules:
default checking is OK
L-DANS R-DANS

Default checking: for each step, just

Object Level
check that the rule in parentheses
has been applied correctly #1: * (r1); #2: *b
(#1,r2); #3: a*b (#2,r3);

For more complicated formal sys- tactics

tems, proof checking is more sophis- checking
ticated default Proof OK?

Meta
Level

Formal Software Development Program Overview March 8, 2011 41 / 187

 Implementing formal systems Machines

Proof checking algorithms

YES

Notice that the proof checking algo-

rithm is marked default
DANS is a very simple system, so
language: rules:
default checking is OK
L-DANS R-DANS

Default checking: for each step, just

Object Level
check that the rule in parentheses
has been applied correctly #1: * (r1); #2: *b
(#1,r2); #3: a*b (#2,r3);

For more complicated formal sys- tactics

tems, proof checking is more sophis- checking
ticated default Proof OK?

Metamathematical studies of the

rules may show that some rules
Meta
are redundant or that more efficient Level
helper rules can be introduced
Formal Software Development Program Overview March 8, 2011 41 / 187
 Implementing formal systems Machines

Proof construction with tactics

YES
Notice the tactics buttons

language: rules:
L-DANS R-DANS

Object Level

#1: * (r1); #2: *b

(#1,r2); #3: a*b (#2,r3);

tactics

checking
default Proof OK?

Meta
Level

Formal Software Development Program Overview March 8, 2011 42 / 187

 Implementing formal systems Machines

Proof construction with tactics

YES
Notice the tactics buttons
Some of the most powerful ma-
chines are used interactively
language: rules:
L-DANS R-DANS

Object Level

#1: * (r1); #2: *b

(#1,r2); #3: a*b (#2,r3);

tactics

checking
default Proof OK?

Meta
Level

Formal Software Development Program Overview March 8, 2011 42 / 187

 Implementing formal systems Machines

Proof construction with tactics

YES
Notice the tactics buttons
Some of the most powerful ma-
chines are used interactively
language: rules:
The built-in tactics help you build L-DANS R-DANS
the proof in the input area
Object Level

#1: * (r1); #2: *b

(#1,r2); #3: a*b (#2,r3);

tactics

checking
default Proof OK?

Meta
Level

Formal Software Development Program Overview March 8, 2011 42 / 187

 Implementing formal systems Machines

Proof construction with tactics

YES
Notice the tactics buttons
Some of the most powerful ma-
chines are used interactively
language: rules:
The built-in tactics help you build L-DANS R-DANS
the proof in the input area
Object Level
These tactics pack a lot of punch
#1: * (r1); #2: *b
(#1,r2); #3: a*b (#2,r3);

tactics

checking
default Proof OK?

Meta
Level

Formal Software Development Program Overview March 8, 2011 42 / 187

 Implementing formal systems Machines

Proof construction with tactics

YES
Notice the tactics buttons
Some of the most powerful ma-
chines are used interactively
language: rules:
The built-in tactics help you build L-DANS R-DANS
the proof in the input area
Object Level
These tactics pack a lot of punch
#1: * (r1); #2: *b
Many provers allow you to write (#1,r2); #3: a*b (#2,r3);

your own tactics in specialized ‘tac- tactics

tics languages’ checking
default Proof OK?

Meta
Level

Formal Software Development Program Overview March 8, 2011 42 / 187

 Implementing formal systems Machines

Proof construction with tactics

YES
Notice the tactics buttons
Some of the most powerful ma-
chines are used interactively
language: rules:
The built-in tactics help you build L-DANS R-DANS
the proof in the input area
Object Level
These tactics pack a lot of punch
#1: * (r1); #2: *b
Many provers allow you to write (#1,r2); #3: a*b (#2,r3);

your own tactics in specialized ‘tac- tactics

tics languages’ checking
default Proof OK?
(instead of writing them in the met-
alanguage)
Meta
Level

Formal Software Development Program Overview March 8, 2011 42 / 187

 Implementing formal systems Machines

Proof construction with tactics

YES
Notice the tactics buttons
Some of the most powerful ma-
chines are used interactively
language: rules:
The built-in tactics help you build L-DANS R-DANS
the proof in the input area
Object Level
These tactics pack a lot of punch
#1: * (r1); #2: *b
Many provers allow you to write (#1,r2); #3: a*b (#2,r3);

your own tactics in specialized ‘tac- tactics

tics languages’ checking
default Proof OK?
(instead of writing them in the met-
alanguage)
We will use this facility when we Meta
Level
study Coq and Isabelle in the ‘In-
teractive Provers’ course
Formal Software Development Program Overview March 8, 2011 42 / 187
 Implementing formal systems Asking the machine if a formula is a theorem

Asking the machine if a formula is a theorem

Formal Software Development Program Overview March 8, 2011 43 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Asking the machine if a formula is a theorem

Can we just enter a wff (not a proof)

in the input area and click some but-
ton that will answer YES if the wff
language: rules:
is a theorem?

Object Level

tactics

checking
Proof OK?

Meta
Level

Formal Software Development Program Overview March 8, 2011 43 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Asking the machine if a formula is a theorem

Can we just enter a wff (not a proof)

in the input area and click some but-
ton that will answer YES if the wff
language: rules:
is a theorem?
The short answer is yes, recall that
Object Level
all formal systems are rigged in a
special way, precisely so that they
can do this by default
tactics

checking
Proof OK?
auto strategy
default Theorem?

Meta
Level

Formal Software Development Program Overview March 8, 2011 43 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Asking the machine if a formula is a theorem

Can we just enter a wff (not a proof)

in the input area and click some but-
ton that will answer YES if the wff
language: rules:
is a theorem?
The short answer is yes, recall that
Object Level
all formal systems are rigged in a
special way, precisely so that they
can do this by default
tactics
The default algorithm for checking checking
whether a wff is a theorem is to let Proof OK?
auto strategy
the machine run and record all the-
default Theorem?
orems; if the wff is a theorem, even-
tually the machine will match it and Meta
Level
output YES

Formal Software Development Program Overview March 8, 2011 43 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Is this default strategy acceptable?

Formal Software Development Program Overview March 8, 2011 44 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Is this default strategy acceptable?

With the default strategy, if a wff is a theorem, we have no clue how

long the machine might take to prove it and . . .

Formal Software Development Program Overview March 8, 2011 44 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Is this default strategy acceptable?

With the default strategy, if a wff is a theorem, we have no clue how

long the machine might take to prove it and . . .
. . . if the wff is not a theorem, the machine will run forever

Formal Software Development Program Overview March 8, 2011 44 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Is this default strategy acceptable?

With the default strategy, if a wff is a theorem, we have no clue how

long the machine might take to prove it and . . .
. . . if the wff is not a theorem, the machine will run forever
The default strategy knows provability but it cannot determine that a
wff is not provable and stop

Formal Software Development Program Overview March 8, 2011 44 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Is this default strategy acceptable?

With the default strategy, if a wff is a theorem, we have no clue how

long the machine might take to prove it and . . .
. . . if the wff is not a theorem, the machine will run forever
The default strategy knows provability but it cannot determine that a
wff is not provable and stop
For certain formal systems, no matter what proving strategy you use,
you cannot avoid this limitation

Formal Software Development Program Overview March 8, 2011 44 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Is this default strategy acceptable?

With the default strategy, if a wff is a theorem, we have no clue how

long the machine might take to prove it and . . .
. . . if the wff is not a theorem, the machine will run forever
The default strategy knows provability but it cannot determine that a
wff is not provable and stop
For certain formal systems, no matter what proving strategy you use,
you cannot avoid this limitation
The reason is that the logic of the system is too powerful to allow us to
handle ‘non-provability’

Formal Software Development Program Overview March 8, 2011 44 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Is this default strategy acceptable?

With the default strategy, if a wff is a theorem, we have no clue how

long the machine might take to prove it and . . .
. . . if the wff is not a theorem, the machine will run forever
The default strategy knows provability but it cannot determine that a
wff is not provable and stop
For certain formal systems, no matter what proving strategy you use,
you cannot avoid this limitation
The reason is that the logic of the system is too powerful to allow us to
handle ‘non-provability’
We say that the system is undecidable; we saw that DANS is a decidable
system, but DANS is simple

Formal Software Development Program Overview March 8, 2011 44 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Undecidability and software

Formal Software Development Program Overview March 8, 2011 45 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Undecidability and software

So there is this teeter-toter between expressiveness (i.e. power of the

formal system) and its decidability

Formal Software Development Program Overview March 8, 2011 45 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Undecidability and software

So there is this teeter-toter between expressiveness (i.e. power of the

formal system) and its decidability
Let’s say you design a very expressive language which would allow you
to prove certain properties of your programs

Formal Software Development Program Overview March 8, 2011 45 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Undecidability and software

So there is this teeter-toter between expressiveness (i.e. power of the

formal system) and its decidability
Let’s say you design a very expressive language which would allow you
to prove certain properties of your programs
Would it be OK for the compiler of this language to hang on certain
programs?

Formal Software Development Program Overview March 8, 2011 45 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Undecidability and software

So there is this teeter-toter between expressiveness (i.e. power of the

formal system) and its decidability
Let’s say you design a very expressive language which would allow you
to prove certain properties of your programs
Would it be OK for the compiler of this language to hang on certain
programs?
This sounds unacceptable, but let’s look at it differently

Formal Software Development Program Overview March 8, 2011 45 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Undecidability and software

So there is this teeter-toter between expressiveness (i.e. power of the

formal system) and its decidability
Let’s say you design a very expressive language which would allow you
to prove certain properties of your programs
Would it be OK for the compiler of this language to hang on certain
programs?
This sounds unacceptable, but let’s look at it differently
I The compiler of a logically-stronger language hangs because it can-
not understand your program

Formal Software Development Program Overview March 8, 2011 45 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Undecidability and software

So there is this teeter-toter between expressiveness (i.e. power of the

formal system) and its decidability
Let’s say you design a very expressive language which would allow you
to prove certain properties of your programs
Would it be OK for the compiler of this language to hang on certain
programs?
This sounds unacceptable, but let’s look at it differently
I The compiler of a logically-stronger language hangs because it can-
not understand your program
I The compiler passes your code in a weaker logic, but the system
crashes in the field

Formal Software Development Program Overview March 8, 2011 45 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Undecidability and software

So there is this teeter-toter between expressiveness (i.e. power of the

formal system) and its decidability
Let’s say you design a very expressive language which would allow you
to prove certain properties of your programs
Would it be OK for the compiler of this language to hang on certain
programs?
This sounds unacceptable, but let’s look at it differently
I The compiler of a logically-stronger language hangs because it can-
not understand your program
I The compiler passes your code in a weaker logic, but the system
crashes in the field

Formal Software Development Program Overview March 8, 2011 45 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Undecidability and software

So there is this teeter-toter between expressiveness (i.e. power of the

formal system) and its decidability
Let’s say you design a very expressive language which would allow you
to prove certain properties of your programs
Would it be OK for the compiler of this language to hang on certain
programs?
This sounds unacceptable, but let’s look at it differently
I The compiler of a logically-stronger language hangs because it can-
not understand your program
I The compiler passes your code in a weaker logic, but the system
crashes in the field
You will hopefully see through examples that undecidable type-checking
in a stronger language is sometimes acceptable (you just press Ctrl-C to
kill the compiler and rethink your code); it’s better if the compiler hangs
than if your code hangs in the field
Formal Software Development Program Overview March 8, 2011 45 / 187
 Implementing formal systems Asking the machine if a formula is a theorem

Automatic provers

Formal Software Development Program Overview March 8, 2011 46 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Automatic provers

Automatic provers have auto strate-

gies that replace the default strategy language: rules:
... FOL

Object Level

tactics

checking
Proof OK?
auto strategy
resolution Theorem?

Meta
Level

Formal Software Development Program Overview March 8, 2011 46 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Automatic provers

Automatic provers have auto strate-

gies that replace the default strategy language: rules:
... FOL
They are based on first-order logic
(FOL) Object Level

tactics

checking
Proof OK?
auto strategy
resolution Theorem?

Meta
Level

Formal Software Development Program Overview March 8, 2011 46 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Automatic provers

Automatic provers have auto strate-

gies that replace the default strategy language: rules:
... FOL
They are based on first-order logic
(FOL) Object Level

These auto strategies use semantics

tactics

checking
Proof OK?
auto strategy
resolution Theorem?

Meta
Level

Formal Software Development Program Overview March 8, 2011 46 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Automatic provers

Automatic provers have auto strate-

gies that replace the default strategy language: rules:
... FOL
They are based on first-order logic
(FOL) Object Level

These auto strategies use semantics

We’ll study FOL and various auto tactics
strategies in the ‘Main Concepts of checking
Logic’ course Proof OK?
auto strategy
resolution Theorem?

Meta
Level

Formal Software Development Program Overview March 8, 2011 46 / 187

 Implementing formal systems Asking the machine if a formula is a theorem

Automatic provers

Automatic provers have auto strate-

gies that replace the default strategy language: rules:
... FOL
They are based on first-order logic
(FOL) Object Level

These auto strategies use semantics

We’ll study FOL and various auto tactics
strategies in the ‘Main Concepts of checking
Logic’ course Proof OK?
auto strategy
Resolution is the most used auto resolution Theorem?

strategy
Meta
Level

Formal Software Development Program Overview March 8, 2011 46 / 187

 Implementing formal systems Decision procedures

Decision procedures

Formal Software Development Program Overview March 8, 2011 47 / 187

 Implementing formal systems Decision procedures

Decision procedures

Let’s look again at the stronger

question: is a wff a theorem or not?

language: rules:

Object Level

tactics

checking
Proof OK?
auto strategy
Theorem?

Meta
Level

Formal Software Development Program Overview March 8, 2011 47 / 187

 Implementing formal systems Decision procedures

Decision procedures

Let’s look again at the stronger

question: is a wff a theorem or not?
A procedure that provides that an-
swer, when it exists, is called a de- language: rules:
cision procedure

Object Level

tactics

checking
Proof OK?
auto strategy
Theorem?

Meta
Level

Formal Software Development Program Overview March 8, 2011 47 / 187

 Implementing formal systems Decision procedures

Decision procedures

Let’s look again at the stronger

question: is a wff a theorem or not?
A procedure that provides that an-
swer, when it exists, is called a de- language: rules:
cision procedure
Mostly very special theories based
Object Level
on FOL admit such procedures

tactics

checking
Proof OK?
auto strategy
Theorem?
decision proc
... Theorem?
(Y/N) Meta
Level

Formal Software Development Program Overview March 8, 2011 47 / 187

 Implementing formal systems Decision procedures

Decision procedures

Let’s look again at the stronger

question: is a wff a theorem or not?
A procedure that provides that an-
swer, when it exists, is called a de- language: rules:
cision procedure
Mostly very special theories based
Object Level
on FOL admit such procedures
Decision procedures are the ba-
sis of Satisfiability Modulo Theories tactics

(SMT) solvers checking

Proof OK?
auto strategy
Theorem?
decision proc
... Theorem?
(Y/N) Meta
Level

Formal Software Development Program Overview March 8, 2011 47 / 187

 Implementing formal systems Decision procedures

Decision procedures

Let’s look again at the stronger

question: is a wff a theorem or not?
A procedure that provides that an-
swer, when it exists, is called a de- language: rules:
cision procedure
Mostly very special theories based
Object Level
on FOL admit such procedures
Decision procedures are the ba-
sis of Satisfiability Modulo Theories tactics

(SMT) solvers checking

Proof OK?
Although SMT solvers are very pow- auto strategy
Theorem?
erful . . . decision proc
... Theorem?
(Y/N) Meta
Level

Formal Software Development Program Overview March 8, 2011 47 / 187

 Implementing formal systems Decision procedures

Decision procedures

Let’s look again at the stronger

question: is a wff a theorem or not?
A procedure that provides that an-
swer, when it exists, is called a de- language: rules:
cision procedure
Mostly very special theories based
Object Level
on FOL admit such procedures
Decision procedures are the ba-
sis of Satisfiability Modulo Theories tactics

(SMT) solvers checking

Proof OK?
Although SMT solvers are very pow- auto strategy
Theorem?
erful . . . decision proc
... Theorem?
Meta
. . . these special theories are not suf- (Y/N)
Level
ficiently expressive to cover all the
software development needs
Formal Software Development Program Overview March 8, 2011 47 / 187
 Implementing formal systems The question of meaning

The question of meaning

Formal Software Development Program Overview March 8, 2011 48 / 187

 Implementing formal systems The question of meaning

The question of meaning

So, are formal systems just meaningless games?

Formal Software Development Program Overview March 8, 2011 48 / 187

 Implementing formal systems The question of meaning

The question of meaning

So, are formal systems just meaningless games?

Yes (meaning is a separate issue)

Formal Software Development Program Overview March 8, 2011 48 / 187

 Implementing formal systems The question of meaning

The question of meaning

So, are formal systems just meaningless games?

Yes (meaning is a separate issue)
But formal systems are rarely born as meaningless games

Formal Software Development Program Overview March 8, 2011 48 / 187

 Implementing formal systems The question of meaning

The question of meaning

So, are formal systems just meaningless games?

Yes (meaning is a separate issue)
But formal systems are rarely born as meaningless games
All important formal systems were obtained by abstracting rules from
meaningful domains

Formal Software Development Program Overview March 8, 2011 48 / 187

 Implementing formal systems The question of meaning

The question of meaning

So, are formal systems just meaningless games?

Yes (meaning is a separate issue)
But formal systems are rarely born as meaningless games
All important formal systems were obtained by abstracting rules from
meaningful domains
All important formal systems have an intended interpretation/model

Formal Software Development Program Overview March 8, 2011 48 / 187

 Implementing formal systems The question of meaning

The question of meaning

So, are formal systems just meaningless games?

Yes (meaning is a separate issue)
But formal systems are rarely born as meaningless games
All important formal systems were obtained by abstracting rules from
meaningful domains
All important formal systems have an intended interpretation/model
Arithmetic, set theory, all sorts of geometries,. . .

Formal Software Development Program Overview March 8, 2011 48 / 187

 Implementing formal systems The question of meaning

What about DANS?

Formal Software Development Program Overview March 8, 2011 49 / 187

 Implementing formal systems The question of meaning

What about DANS?

I had an intended interpretation (model) in mind

Formal Software Development Program Overview March 8, 2011 49 / 187

 Implementing formal systems The question of meaning

What about DANS?

I had an intended interpretation (model) in mind

When I was a young boy, there were always more girls than boys at a
dance club (DANS is a misspelling of dance)

Formal Software Development Program Overview March 8, 2011 49 / 187

 Implementing formal systems The question of meaning

What about DANS?

I had an intended interpretation (model) in mind

When I was a young boy, there were always more girls than boys at a
dance club (DANS is a misspelling of dance)
(apparently, things have changed quite a bit)

Formal Software Development Program Overview March 8, 2011 49 / 187

 Implementing formal systems The question of meaning

What about DANS?

I had an intended interpretation (model) in mind

When I was a young boy, there were always more girls than boys at a
dance club (DANS is a misspelling of dance)
(apparently, things have changed quite a bit)
So, * is the door to the dance floor, a is a girl, b is a boy

Formal Software Development Program Overview March 8, 2011 49 / 187

 Implementing formal systems The question of meaning

What about DANS?

I had an intended interpretation (model) in mind

When I was a young boy, there were always more girls than boys at a
dance club (DANS is a misspelling of dance)
(apparently, things have changed quite a bit)
So, * is the door to the dance floor, a is a girl, b is a boy
The formation rules say that boys must line up on the left, girls on the
right, no mix up in the lines

Formal Software Development Program Overview March 8, 2011 49 / 187

 Implementing formal systems The question of meaning

What about DANS?

I had an intended interpretation (model) in mind

When I was a young boy, there were always more girls than boys at a
dance club (DANS is a misspelling of dance)
(apparently, things have changed quite a bit)
So, * is the door to the dance floor, a is a girl, b is a boy
The formation rules say that boys must line up on the left, girls on the
right, no mix up in the lines
The first rule says that an empty club is OK

Formal Software Development Program Overview March 8, 2011 49 / 187

 Implementing formal systems The question of meaning

What about DANS?

I had an intended interpretation (model) in mind

When I was a young boy, there were always more girls than boys at a
dance club (DANS is a misspelling of dance)
(apparently, things have changed quite a bit)
So, * is the door to the dance floor, a is a girl, b is a boy
The formation rules say that boys must line up on the left, girls on the
right, no mix up in the lines
The first rule says that an empty club is OK
The second rule says that boys can arrive at anytime, third rules ensures
that there is at least a boy waiting when a girl arrives

Formal Software Development Program Overview March 8, 2011 49 / 187

 Implementing formal systems The question of meaning

What about DANS?

I had an intended interpretation (model) in mind

When I was a young boy, there were always more girls than boys at a
dance club (DANS is a misspelling of dance)
(apparently, things have changed quite a bit)
So, * is the door to the dance floor, a is a girl, b is a boy
The formation rules say that boys must line up on the left, girls on the
right, no mix up in the lines
The first rule says that an empty club is OK
The second rule says that boys can arrive at anytime, third rules ensures
that there is at least a boy waiting when a girl arrives
The fourth rule says . . . well, she accepted the invitation

Formal Software Development Program Overview March 8, 2011 49 / 187

 Implementing formal systems The question of meaning

The balancing act of the rules

Formal Software Development Program Overview March 8, 2011 50 / 187

 Implementing formal systems The question of meaning

The balancing act of the rules

DANS is very simple, anything more complicated would have lenghtened

this overview

Formal Software Development Program Overview March 8, 2011 50 / 187

 Implementing formal systems The question of meaning

The balancing act of the rules

DANS is very simple, anything more complicated would have lenghtened

this overview
You should pick up some situation that interests you and try to make a
formal system for it

Formal Software Development Program Overview March 8, 2011 50 / 187

 Implementing formal systems The question of meaning

The balancing act of the rules

DANS is very simple, anything more complicated would have lenghtened

this overview
You should pick up some situation that interests you and try to make a
formal system for it
Don’t choose only rules that make longer sentences, have some shorten-
ing rules too

Formal Software Development Program Overview March 8, 2011 50 / 187

 Implementing formal systems The question of meaning

The balancing act of the rules

DANS is very simple, anything more complicated would have lenghtened

this overview
You should pick up some situation that interests you and try to make a
formal system for it
Don’t choose only rules that make longer sentences, have some shorten-
ing rules too
What makes a system interesting is the delicate balance between the two
kinds of rules

Formal Software Development Program Overview March 8, 2011 50 / 187

 Implementing formal systems The question of meaning

The balancing act of the rules

DANS is very simple, anything more complicated would have lenghtened

this overview
You should pick up some situation that interests you and try to make a
formal system for it
Don’t choose only rules that make longer sentences, have some shorten-
ing rules too
What makes a system interesting is the delicate balance between the two
kinds of rules
You will see how hard it is to come up with an interesting system

Formal Software Development Program Overview March 8, 2011 50 / 187

 Implementing formal systems The question of meaning

The balancing act of the rules

DANS is very simple, anything more complicated would have lenghtened

this overview
You should pick up some situation that interests you and try to make a
formal system for it
Don’t choose only rules that make longer sentences, have some shorten-
ing rules too
What makes a system interesting is the delicate balance between the two
kinds of rules
You will see how hard it is to come up with an interesting system
You will see that it is easier to cook up a system if you have an intended
interpretation

Formal Software Development Program Overview March 8, 2011 50 / 187

 Implementing formal systems The question of meaning

The balancing act of the rules

Formal Software Development Program Overview March 8, 2011 51 / 187

 Implementing formal systems The question of meaning

The balancing act of the rules

It is easier if you pick a property of the formulas that does not change
as rules get applied

Formal Software Development Program Overview March 8, 2011 51 / 187

 Implementing formal systems The question of meaning

The balancing act of the rules

It is easier if you pick a property of the formulas that does not change
as rules get applied
That property will give you a decision procedure

Formal Software Development Program Overview March 8, 2011 51 / 187

 Implementing formal systems The question of meaning

The balancing act of the rules

It is easier if you pick a property of the formulas that does not change
as rules get applied
That property will give you a decision procedure
Warning: games are difficult, try them only after you gain some experi-
ence

Formal Software Development Program Overview March 8, 2011 51 / 187

 Implementing formal systems The question of meaning

The balancing act of the rules

It is easier if you pick a property of the formulas that does not change
as rules get applied
That property will give you a decision procedure
Warning: games are difficult, try them only after you gain some experi-
ence
Alternative: take DANS and make it more interesting, by adding more
language and more rules

Formal Software Development Program Overview March 8, 2011 51 / 187

 Implementing formal systems The question of meaning

An extension of our view of a formal system

Formal Software Development Program Overview March 8, 2011 52 / 187

 Implementing formal systems The question of meaning

An extension of our view of a formal system

We defined a formal system as a language and a set of rules of inference

for defining a subset of sentences, the theorems

Formal Software Development Program Overview March 8, 2011 52 / 187

 Implementing formal systems The question of meaning

An extension of our view of a formal system

We defined a formal system as a language and a set of rules of inference

for defining a subset of sentences, the theorems
We saw that a formal system may admit a decision procedure

Formal Software Development Program Overview March 8, 2011 52 / 187

 Implementing formal systems The question of meaning

An extension of our view of a formal system

We defined a formal system as a language and a set of rules of inference

for defining a subset of sentences, the theorems
We saw that a formal system may admit a decision procedure
A metamathematical proof that a decision procedure exists is highly non-
trivial

Formal Software Development Program Overview March 8, 2011 52 / 187

 Implementing formal systems The question of meaning

An extension of our view of a formal system

We defined a formal system as a language and a set of rules of inference

for defining a subset of sentences, the theorems
We saw that a formal system may admit a decision procedure
A metamathematical proof that a decision procedure exists is highly non-
trivial
The decision procedure can decide if a sentence is provable or not by
analyzing its structure, not by actually proving it

Formal Software Development Program Overview March 8, 2011 52 / 187

 Implementing formal systems The question of meaning

An extension of our view of a formal system

We defined a formal system as a language and a set of rules of inference

for defining a subset of sentences, the theorems
We saw that a formal system may admit a decision procedure
A metamathematical proof that a decision procedure exists is highly non-
trivial
The decision procedure can decide if a sentence is provable or not by
analyzing its structure, not by actually proving it
It is helpful sometimes to raise the profile of this decision procedure and
have the proof calculus recede in the background

Formal Software Development Program Overview March 8, 2011 52 / 187

 Implementing formal systems The question of meaning

An extension of our view of a formal system

We defined a formal system as a language and a set of rules of inference

for defining a subset of sentences, the theorems
We saw that a formal system may admit a decision procedure
A metamathematical proof that a decision procedure exists is highly non-
trivial
The decision procedure can decide if a sentence is provable or not by
analyzing its structure, not by actually proving it
It is helpful sometimes to raise the profile of this decision procedure and
have the proof calculus recede in the background
So we will sometimes look at a formal system as consisting of language
and a decision procedure (without a proof calculus necessarily present)

Formal Software Development Program Overview March 8, 2011 52 / 187

 Implementing formal systems The question of meaning

Review of form versus meaning

Formal Software Development Program Overview March 8, 2011 53 / 187

 Implementing formal systems The question of meaning

Review of form versus meaning

Simply put, syntax is form and semantics is meaning

Formal Software Development Program Overview March 8, 2011 53 / 187

 Implementing formal systems The question of meaning

Review of form versus meaning

Simply put, syntax is form and semantics is meaning

Warning: more formal definitions of syntax and semantics vary, depend-
ing on where the emphasys is:

Formal Software Development Program Overview March 8, 2011 53 / 187

 Implementing formal systems The question of meaning

Review of form versus meaning

Simply put, syntax is form and semantics is meaning

Warning: more formal definitions of syntax and semantics vary, depend-
ing on where the emphasys is:
1 Emphasys is on linguistics (the study of natural language, we don’t
touch this)

Formal Software Development Program Overview March 8, 2011 53 / 187

 Implementing formal systems The question of meaning

Review of form versus meaning

Simply put, syntax is form and semantics is meaning

Warning: more formal definitions of syntax and semantics vary, depend-
ing on where the emphasys is:
1 Emphasys is on linguistics (the study of natural language, we don’t
touch this)
2 Emphasys is on mathematical logic

Formal Software Development Program Overview March 8, 2011 53 / 187

 Implementing formal systems The question of meaning

Review of form versus meaning

Simply put, syntax is form and semantics is meaning

Warning: more formal definitions of syntax and semantics vary, depend-
ing on where the emphasys is:
1 Emphasys is on linguistics (the study of natural language, we don’t
touch this)
2 Emphasys is on mathematical logic
3 Emphasys is on programming languages

Formal Software Development Program Overview March 8, 2011 53 / 187

 Implementing formal systems The question of meaning

Review of form versus meaning

Simply put, syntax is form and semantics is meaning

Warning: more formal definitions of syntax and semantics vary, depend-
ing on where the emphasys is:
1 Emphasys is on linguistics (the study of natural language, we don’t
touch this)
2 Emphasys is on mathematical logic
3 Emphasys is on programming languages

For us, both 2 and 3 are important, so our definitions account for this
need

Formal Software Development Program Overview March 8, 2011 53 / 187

 Implementing formal systems The question of meaning

Review of form versus meaning

Simply put, syntax is form and semantics is meaning

Warning: more formal definitions of syntax and semantics vary, depend-
ing on where the emphasys is:
1 Emphasys is on linguistics (the study of natural language, we don’t
touch this)
2 Emphasys is on mathematical logic
3 Emphasys is on programming languages

For us, both 2 and 3 are important, so our definitions account for this
need
To begin with, for us syntax = language, and nothing else, i.e.:

Formal Software Development Program Overview March 8, 2011 53 / 187

 Implementing formal systems The question of meaning

Review of form versus meaning

Simply put, syntax is form and semantics is meaning

Warning: more formal definitions of syntax and semantics vary, depend-
ing on where the emphasys is:
1 Emphasys is on linguistics (the study of natural language, we don’t
touch this)
2 Emphasys is on mathematical logic
3 Emphasys is on programming languages

For us, both 2 and 3 are important, so our definitions account for this
need
To begin with, for us syntax = language, and nothing else, i.e.:
1 A lexical structure

Formal Software Development Program Overview March 8, 2011 53 / 187

 Implementing formal systems The question of meaning

Review of form versus meaning

Simply put, syntax is form and semantics is meaning

Warning: more formal definitions of syntax and semantics vary, depend-
ing on where the emphasys is:
1 Emphasys is on linguistics (the study of natural language, we don’t
touch this)
2 Emphasys is on mathematical logic
3 Emphasys is on programming languages

For us, both 2 and 3 are important, so our definitions account for this
need
To begin with, for us syntax = language, and nothing else, i.e.:
1 A lexical structure
2 A grammatical structure

Formal Software Development Program Overview March 8, 2011 53 / 187

 Implementing formal systems The question of meaning

A formal system does not include a semantics

Formal Software Development Program Overview March 8, 2011 54 / 187

 Implementing formal systems The question of meaning

A formal system does not include a semantics

As we said earlier, a formal system is a language (syntax) and a set of

rules for establishing the subset of provable sentences (the theorems)

Formal Software Development Program Overview March 8, 2011 54 / 187

 Implementing formal systems The question of meaning

A formal system does not include a semantics

As we said earlier, a formal system is a language (syntax) and a set of

rules for establishing the subset of provable sentences (the theorems)
A formal system does not require a specific meaning to be associated
with a provable sentence

Formal Software Development Program Overview March 8, 2011 54 / 187

 Implementing formal systems The question of meaning

A formal system does not include a semantics

As we said earlier, a formal system is a language (syntax) and a set of

rules for establishing the subset of provable sentences (the theorems)
A formal system does not require a specific meaning to be associated
with a provable sentence
Since specific meaning = semantics, this implies that a formal system
does not include a semantics explicitly

Formal Software Development Program Overview March 8, 2011 54 / 187

 Implementing formal systems The question of meaning

A formal system does not include a semantics

As we said earlier, a formal system is a language (syntax) and a set of

rules for establishing the subset of provable sentences (the theorems)
A formal system does not require a specific meaning to be associated
with a provable sentence
Since specific meaning = semantics, this implies that a formal system
does not include a semantics explicitly
The rules can be a proof calculus or a YES/NO decision procedure

Formal Software Development Program Overview March 8, 2011 54 / 187

 Implementing formal systems The question of meaning

Semantics is specific meaning

Formal Software Development Program Overview March 8, 2011 55 / 187

 Implementing formal systems The question of meaning

Semantics is specific meaning

On the other hand, a semantics associates a specific meaning to a subset

of sentences

Formal Software Development Program Overview March 8, 2011 55 / 187

 Implementing formal systems The question of meaning

Semantics is specific meaning

On the other hand, a semantics associates a specific meaning to a subset

of sentences
So, just like a formal system, a semantics also separates out a subset of
sentences; they are called the ‘valid’ sentences

Formal Software Development Program Overview March 8, 2011 55 / 187

 Implementing formal systems The question of meaning

Semantics is specific meaning

On the other hand, a semantics associates a specific meaning to a subset

of sentences
So, just like a formal system, a semantics also separates out a subset of
sentences; they are called the ‘valid’ sentences
The question of whether the rules of inference and the semantics deter-
mine the same subset of sentences is a central one (when this is the case
we say that the system is sound (all theorems are valid) and complete
(all valid sentences are theorems)

Formal Software Development Program Overview March 8, 2011 55 / 187

 Implementing formal systems The question of meaning

Semantics is specific meaning

On the other hand, a semantics associates a specific meaning to a subset

of sentences
So, just like a formal system, a semantics also separates out a subset of
sentences; they are called the ‘valid’ sentences
The question of whether the rules of inference and the semantics deter-
mine the same subset of sentences is a central one (when this is the case
we say that the system is sound (all theorems are valid) and complete
(all valid sentences are theorems)
There are two major types of semantics we are interested in this program

Formal Software Development Program Overview March 8, 2011 55 / 187

 Implementing formal systems The question of meaning

Semantics is specific meaning

On the other hand, a semantics associates a specific meaning to a subset

of sentences
So, just like a formal system, a semantics also separates out a subset of
sentences; they are called the ‘valid’ sentences
The question of whether the rules of inference and the semantics deter-
mine the same subset of sentences is a central one (when this is the case
we say that the system is sound (all theorems are valid) and complete
(all valid sentences are theorems)
There are two major types of semantics we are interested in this program

I Proof semantics (meaning of language is given by the use of the

rules; the meaning of a sentence is its proof; not all systems have
such a semantics)

Formal Software Development Program Overview March 8, 2011 55 / 187

 Implementing formal systems The question of meaning

Semantics is specific meaning

On the other hand, a semantics associates a specific meaning to a subset

of sentences
So, just like a formal system, a semantics also separates out a subset of
sentences; they are called the ‘valid’ sentences
The question of whether the rules of inference and the semantics deter-
mine the same subset of sentences is a central one (when this is the case
we say that the system is sound (all theorems are valid) and complete
(all valid sentences are theorems)
There are two major types of semantics we are interested in this program

I Proof semantics (meaning of language is given by the use of the

rules; the meaning of a sentence is its proof; not all systems have
such a semantics)
I Model semantics (meaning of language is through the ‘real’ things
that it represents)

Formal Software Development Program Overview March 8, 2011 55 / 187

 Implementing formal systems The question of meaning

Formal systems and their semantics

lexical grammar
language

proof calculus decision proc.

model semantics proof semantics

Formal Software Development Program Overview March 8, 2011 56 / 187

 Implementing formal systems The question of meaning

Formal systems and their semantics

Formal Software Development Program Overview March 8, 2011 57 / 187

 Implementing formal systems The question of meaning

Formal systems and their semantics

Formal system at top, its se-

mantics at bottom

lexical language grammar

proof calculus decision proc.

model semantics proof semantics

Formal Software Development Program Overview March 8, 2011 57 / 187

 Implementing formal systems The question of meaning

Formal systems and their semantics

Formal system at top, its se-

mantics at bottom
Again, formal system = lan-
guage + proof calculus

lexical language grammar

proof calculus decision proc.

model semantics proof semantics

Formal Software Development Program Overview March 8, 2011 57 / 187

 Implementing formal systems The question of meaning

Formal systems and their semantics

Formal system at top, its se-

mantics at bottom
Again, formal system = lan-
guage + proof calculus
Proof semantics extract
meaning from the execution lexical language grammar
of the rules themselves
proof calculus decision proc.

model semantics proof semantics

Formal Software Development Program Overview March 8, 2011 57 / 187

 Implementing formal systems The question of meaning

Formal systems and their semantics

Formal system at top, its se-

mantics at bottom
Again, formal system = lan-
guage + proof calculus
Proof semantics extract
meaning from the execution lexical language grammar
of the rules themselves
proof calculus decision proc.
A subtler kind of meaning,
takes a bit getting used to

model semantics proof semantics

Formal Software Development Program Overview March 8, 2011 57 / 187

 Implementing formal systems The question of meaning

Formal systems and their semantics

Formal system at top, its se-

mantics at bottom
Again, formal system = lan-
guage + proof calculus
Proof semantics extract
meaning from the execution lexical language grammar
of the rules themselves
proof calculus decision proc.
A subtler kind of meaning,
takes a bit getting used to
Important when we look at
model semantics proof semantics
the semantics of program-
ming languages

Formal Software Development Program Overview March 8, 2011 57 / 187

 Implementing formal systems The question of meaning

Formal systems and their semantics

Formal system at top, its se-

mantics at bottom
Again, formal system = lan-
guage + proof calculus
Proof semantics extract
meaning from the execution lexical language grammar
of the rules themselves
proof calculus decision proc.
A subtler kind of meaning,
takes a bit getting used to
Important when we look at
model semantics proof semantics
the semantics of program-
ming languages
An interpreter gives a ‘proof
semantics’ to your program

Formal Software Development Program Overview March 8, 2011 57 / 187

 Implementing formal systems The question of meaning

Soundness and completeness

Formal Software Development Program Overview March 8, 2011 58 / 187

 Implementing formal systems The question of meaning

Soundness and completeness

The essential question again:

does the proof calculus de-
scribe the models soundly
and completely?

lexical language grammar

proof calculus decision proc.

model semantics proof semantics

Formal Software Development Program Overview March 8, 2011 58 / 187

 Implementing formal systems The question of meaning

Soundness and completeness

The essential question again:

does the proof calculus de-
scribe the models soundly
and completely?
Sometimes it does, many
times it does not
lexical language grammar

proof calculus decision proc.

model semantics proof semantics

Formal Software Development Program Overview March 8, 2011 58 / 187

 Implementing formal systems The question of meaning

Soundness and completeness

The essential question again:

does the proof calculus de-
scribe the models soundly
and completely?
Sometimes it does, many
times it does not
lexical language grammar
Many times the class of mod-
els has to be enlarged beyond proof calculus decision proc.

‘ordinary’ sets to categories

model semantics proof semantics

Formal Software Development Program Overview March 8, 2011 58 / 187

 Implementing formal systems The question of meaning

Soundness and completeness

The essential question again:

does the proof calculus de-
scribe the models soundly
and completely?
Sometimes it does, many
times it does not
lexical language grammar
Many times the class of mod-
els has to be enlarged beyond proof calculus decision proc.

‘ordinary’ sets to categories

One reason why you’ll hear
category theory so much in model semantics proof semantics
this program

Formal Software Development Program Overview March 8, 2011 58 / 187

 Implementing formal systems The question of meaning

Soundness and completeness

The essential question again:

does the proof calculus de-
scribe the models soundly
and completely?
Sometimes it does, many
times it does not
lexical language grammar
Many times the class of mod-
els has to be enlarged beyond proof calculus decision proc.

‘ordinary’ sets to categories

One reason why you’ll hear
category theory so much in model semantics proof semantics
this program
This picture of the two basic
semantics is good to keep in
mind
Formal Software Development Program Overview March 8, 2011 58 / 187
 Implementing formal systems Model Checking

Model Checking

Formal Software Development Program Overview March 8, 2011 59 / 187

 Implementing formal systems Model Checking

Model Checking
Model checking is a special decision procedure that is extracted from a
model semantics

Formal Software Development Program Overview March 8, 2011 59 / 187

 Implementing formal systems Model Checking

Model Checking
Model checking is a special decision procedure that is extracted from a
model semantics
Model checking produces counterexamples for a formula that is not a
theorem

Formal Software Development Program Overview March 8, 2011 59 / 187

 Implementing formal systems Model Checking

Model Checking
Model checking is a special decision procedure that is extracted from a
model semantics
Model checking produces counterexamples for a formula that is not a
theorem
Some formal systems have both a proof calculus and such a decision
procedure

Formal Software Development Program Overview March 8, 2011 59 / 187

 Implementing formal systems Model Checking

Model Checking
Model checking is a special decision procedure that is extracted from a
model semantics
Model checking produces counterexamples for a formula that is not a
theorem
Some formal systems have both a proof calculus and such a decision
procedure
This the best of worlds, because you can switch between proof search
and counterexample search

Formal Software Development Program Overview March 8, 2011 59 / 187

 Implementing formal systems Model Checking

Model Checking
Model checking is a special decision procedure that is extracted from a
model semantics
Model checking produces counterexamples for a formula that is not a
theorem
Some formal systems have both a proof calculus and such a decision
procedure
This the best of worlds, because you can switch between proof search
and counterexample search
It is the interaction between the two that makes things interesting

Formal Software Development Program Overview March 8, 2011 59 / 187

 Implementing formal systems Model Checking

Model Checking
Model checking is a special decision procedure that is extracted from a
model semantics
Model checking produces counterexamples for a formula that is not a
theorem
Some formal systems have both a proof calculus and such a decision
procedure
This the best of worlds, because you can switch between proof search
and counterexample search
It is the interaction between the two that makes things interesting
Just like in informal mathematics, you need to acquire a feel of when to
look for a proof and when to look for a counterexample

Formal Software Development Program Overview March 8, 2011 59 / 187

 Implementing formal systems Model Checking

Model Checking
Model checking is a special decision procedure that is extracted from a
model semantics
Model checking produces counterexamples for a formula that is not a
theorem
Some formal systems have both a proof calculus and such a decision
procedure
This the best of worlds, because you can switch between proof search
and counterexample search
It is the interaction between the two that makes things interesting
Just like in informal mathematics, you need to acquire a feel of when to
look for a proof and when to look for a counterexample
Most of formal software development is a continuous back-and-forth be-
tween theorem proving and model checking

Formal Software Development Program Overview March 8, 2011 59 / 187

 Implementing formal systems Model Checking

Model Checking
Model checking is a special decision procedure that is extracted from a
model semantics
Model checking produces counterexamples for a formula that is not a
theorem
Some formal systems have both a proof calculus and such a decision
procedure
This the best of worlds, because you can switch between proof search
and counterexample search
It is the interaction between the two that makes things interesting
Just like in informal mathematics, you need to acquire a feel of when to
look for a proof and when to look for a counterexample
Most of formal software development is a continuous back-and-forth be-
tween theorem proving and model checking
In the program, we will develop some engineering experience allowing us
to decide when to switch from one to the other
Formal Software Development Program Overview March 8, 2011 59 / 187
 Implementing formal systems Model Checking

Model Checking

Formal Software Development Program Overview March 8, 2011 60 / 187

 Implementing formal systems Model Checking

Model Checking

Many times it is easier to infer properties of the language directly from

the models

Formal Software Development Program Overview March 8, 2011 60 / 187

 Implementing formal systems Model Checking

Model Checking

Many times it is easier to infer properties of the language directly from

the models
Model checking is a sort of proving, but based on a terminating, deter-
ministic set of rules

Formal Software Development Program Overview March 8, 2011 60 / 187

 Implementing formal systems Model Checking

Model Checking

Many times it is easier to infer properties of the language directly from

the models
Model checking is a sort of proving, but based on a terminating, deter-
ministic set of rules
‘Model calculus’ versus ‘proof calculus’ if you wish

Formal Software Development Program Overview March 8, 2011 60 / 187

 Implementing formal systems Model Checking

Model Checking

Many times it is easier to infer properties of the language directly from

the models
Model checking is a sort of proving, but based on a terminating, deter-
ministic set of rules
‘Model calculus’ versus ‘proof calculus’ if you wish
Model checking works only for finite models, or models that can use
predicate abstraction to obtain a simulating finite model

Formal Software Development Program Overview March 8, 2011 60 / 187

 Implementing formal systems Model Checking

Model Checking

Many times it is easier to infer properties of the language directly from

the models
Model checking is a sort of proving, but based on a terminating, deter-
ministic set of rules
‘Model calculus’ versus ‘proof calculus’ if you wish
Model checking works only for finite models, or models that can use
predicate abstraction to obtain a simulating finite model
So, model checking cannot handle inductive data and recursive functions

Formal Software Development Program Overview March 8, 2011 60 / 187

 Implementing formal systems Model Checking

Model Checking

Many times it is easier to infer properties of the language directly from

the models
Model checking is a sort of proving, but based on a terminating, deter-
ministic set of rules
‘Model calculus’ versus ‘proof calculus’ if you wish
Model checking works only for finite models, or models that can use
predicate abstraction to obtain a simulating finite model
So, model checking cannot handle inductive data and recursive functions
Suffers from state space explosion

Formal Software Development Program Overview March 8, 2011 60 / 187

 Implementing formal systems Model Checking

Model Checking

Many times it is easier to infer properties of the language directly from

the models
Model checking is a sort of proving, but based on a terminating, deter-
ministic set of rules
‘Model calculus’ versus ‘proof calculus’ if you wish
Model checking works only for finite models, or models that can use
predicate abstraction to obtain a simulating finite model
So, model checking cannot handle inductive data and recursive functions
Suffers from state space explosion
Concurrency models are finite and model checking them is very useful

Formal Software Development Program Overview March 8, 2011 60 / 187

 Implementing formal systems Model Checking

Model Checking

Many times it is easier to infer properties of the language directly from

the models
Model checking is a sort of proving, but based on a terminating, deter-
ministic set of rules
‘Model calculus’ versus ‘proof calculus’ if you wish
Model checking works only for finite models, or models that can use
predicate abstraction to obtain a simulating finite model
So, model checking cannot handle inductive data and recursive functions
Suffers from state space explosion
Concurrency models are finite and model checking them is very useful
We dedicate a course to it: ‘Model Checking and Concurrency’

Formal Software Development Program Overview March 8, 2011 60 / 187

 Implementing formal systems Nondeterminism again

Nondeterminism of proof calculus

Formal Software Development Program Overview March 8, 2011 61 / 187

 Implementing formal systems Nondeterminism again

Nondeterminism of proof calculus

Proof calculi of formal systems are nondeterministic, the rules can be

applied in any order, and even the same rule can match a wff in different
ways

Formal Software Development Program Overview March 8, 2011 61 / 187

 Implementing formal systems Nondeterminism again

Nondeterminism of proof calculus

Proof calculi of formal systems are nondeterministic, the rules can be

applied in any order, and even the same rule can match a wff in different
ways
aaa*bbbb can become aaaa*bbbb, or aaa*bbbbb, or aa*bbb

Formal Software Development Program Overview March 8, 2011 61 / 187

 Implementing formal systems Nondeterminism again

Nondeterminism of proof calculus

Proof calculi of formal systems are nondeterministic, the rules can be

applied in any order, and even the same rule can match a wff in different
ways
aaa*bbbb can become aaaa*bbbb, or aaa*bbbbb, or aa*bbb
The DANS system does not demand that the pair closest to the door
must go dancing

Formal Software Development Program Overview March 8, 2011 61 / 187

 Implementing formal systems Nondeterminism again

Nondeterminism of proof calculus

Proof calculi of formal systems are nondeterministic, the rules can be

applied in any order, and even the same rule can match a wff in different
ways
aaa*bbbb can become aaaa*bbbb, or aaa*bbbbb, or aa*bbb
The DANS system does not demand that the pair closest to the door
must go dancing
The system says that they could, but the girl can potentially refuse all
night long, while more boys and girls swell up the lines

Formal Software Development Program Overview March 8, 2011 61 / 187

 Implementing formal systems Machines for mathematics and software

Mathematics is founded on formal systems

Formal Software Development Program Overview March 8, 2011 62 / 187

 Implementing formal systems Machines for mathematics and software

Mathematics is founded on formal systems

Are there formal systems that could

potentially output all of mathemat-
ics?
language: rules:

Object Level

tactics

checking
default Proof OK?
auto strategy
default Theorem?

Meta
Level

Formal Software Development Program Overview March 8, 2011 62 / 187

 Implementing formal systems Machines for mathematics and software

Mathematics is founded on formal systems

essentially all mathematics are here

Are there formal systems that could

potentially output all of mathemat-
ics?
language: rules:
Yes, essentially all of mathematics! L-ZFC ZFC

Object Level

tactics

checking
... Proof OK?
auto strategy
... Theorem?

Meta
Level

Mizar
Formal Software Development Program Overview March 8, 2011 62 / 187
 Implementing formal systems Machines for mathematics and software

Mathematics is founded on formal systems

thm#xxxx: Prime factorization theorem

Are there formal systems that could

potentially output all of mathemat-
ics?
language: rules:
Yes, essentially all of mathematics! L-ZFC ZFC

One such system, for classical math-

Object Level
ematics, is an axiomatization of
set theory called Zermelo-Fraenkel-
with-Choice (ZFC)
tactics

checking
... Proof OK?
auto strategy
... Theorem?

Meta
Level

Mizar
Formal Software Development Program Overview March 8, 2011 62 / 187
 Implementing formal systems Machines for mathematics and software

Mathematics is founded on formal systems

thm#xxxx: Fundamental theorem of alge-

bra
Are there formal systems that could
potentially output all of mathemat-
ics?
language: rules:
Yes, essentially all of mathematics! L-ZFC ZFC

One such system, for classical math-

Object Level
ematics, is an axiomatization of
set theory called Zermelo-Fraenkel-
with-Choice (ZFC)
tactics
The Mizar project formalized a sig- checking
nificant ammount of known mathe- ... Proof OK?
auto strategy
matics ... Theorem?

Meta
Level

Mizar
Formal Software Development Program Overview March 8, 2011 62 / 187
 Implementing formal systems Machines for mathematics and software

Mathematics is founded on formal systems

thm#xxxx: Four color theorem

Are there formal systems that could

potentially output all of mathemat-
ics?
language: rules:
Yes, essentially all of mathematics! L-CIC CIC

One such system, for classical math-

Object Level
ematics, is an axiomatization of
set theory called Zermelo-Fraenkel-
with-Choice (ZFC)
tactics
The Mizar project formalized a sig- checking
nificant ammount of known mathe- ... Proof OK?
auto strategy
matics ... Theorem?

Other systems, based on type the- Meta

ory, can output more than classical Level

mathematics Coq
Formal Software Development Program Overview March 8, 2011 62 / 187
 Implementing formal systems Machines for mathematics and software

Software is founded on formal systems

Formal Software Development Program Overview March 8, 2011 63 / 187

 Implementing formal systems Machines for mathematics and software

Software is founded on formal systems

language: rules:
... ZFC
Refining requirements analysis your model

Object Level

tactics

checking
... Proof OK?
auto strategy
... Theorem?

Meta
Level

Event-B
Formal Software Development Program Overview March 8, 2011 63 / 187
 Implementing formal systems Machines for mathematics and software

Software is founded on formal systems

language: rules:
... rewriting logic
Refining requirements analysis your model

Object Level
Building executable models

tactics

checking
... Proof OK?
auto strategy
... Theorem?

Meta
Level

Maude
Formal Software Development Program Overview March 8, 2011 63 / 187
 Implementing formal systems Machines for mathematics and software

Software is founded on formal systems

language: rules:
... temporal logic
Refining requirements analysis your model

Object Level
Building executable models
Building a concurrent model
tactics

checking
... Proof OK?
auto strategy
... Theorem?
decision proc
... Theorem?
(Y/N) Meta
Level

SPIN
Formal Software Development Program Overview March 8, 2011 63 / 187
 Implementing formal systems Machines for mathematics and software

Software is founded on formal systems

language: rules:
... CIC + C semantics
Refining requirements analysis your program

Object Level
Building executable models
Building a concurrent model
tactics
Verify total correctness
checking
... Proof OK?
auto strategy
... Theorem?

Meta
Level
Coq
Formal Software Development Program Overview March 8, 2011 63 / 187
 Implementing formal systems Machines for mathematics and software

Software is founded on formal systems

language: rules:
... HOL + C semantics
Refining requirements analysis your program

Object Level
Building executable models
Building a concurrent model
tactics
Verify total correctness
checking
Verify safety properties ... Proof OK?
auto strategy
... Theorem?

Meta
Level

Isabelle
Formal Software Development Program Overview March 8, 2011 63 / 187
 When are proofs used

1 What is formal software development

2 Implementing formal systems

3 When are proofs used

4 What formal software development is not

5 Formal verification of programs

6 Mathematics and Software

7 Concrete examples of what we do in the program

8 Program goals and course structure

Formal Software Development Program Overview March 8, 2011 64 / 187
 When are proofs used Ideally, all the time

When are proofs used in software development?

Formal Software Development Program Overview March 8, 2011 65 / 187

 When are proofs used Ideally, all the time

When are proofs used in software development?

Proofs may be used during all phases of the software waterfall model:

Formal Software Development Program Overview March 8, 2011 65 / 187

 When are proofs used Ideally, all the time

The earlier, the better

Formal Software Development Program Overview March 8, 2011 66 / 187

 When are proofs used Ideally, all the time

The earlier, the better

Formalism is especially effective during requirements and design!

Formal Software Development Program Overview March 8, 2011 66 / 187

 When are proofs used Ideally, all the time

The earlier, the better

Formalism is especially effective during requirements and design!
Many faults appear in systems that perform as specified!; the earlier we
use these methods the better (e.g. requirements analysis): we prove that
we build the correct system (validation), not that we build the system
correctly (verification).

Formal Software Development Program Overview March 8, 2011 66 / 187

 When are proofs used Ideally, all the time

The earlier, the better

Formalism is especially effective during requirements and design!
Many faults appear in systems that perform as specified!; the earlier we
use these methods the better (e.g. requirements analysis): we prove that
we build the correct system (validation), not that we build the system
correctly (verification).
For many projects, requirements and design are the only parts of the
development that are formal (i.e. no formal verification of the code)

Formal Software Development Program Overview March 8, 2011 66 / 187

 When are proofs used Ideally, all the time

The earlier, the better

Formalism is especially effective during requirements and design!
Many faults appear in systems that perform as specified!; the earlier we
use these methods the better (e.g. requirements analysis): we prove that
we build the correct system (validation), not that we build the system
correctly (verification).
For many projects, requirements and design are the only parts of the
development that are formal (i.e. no formal verification of the code)
We can develop an early mathematical model of the system being built,
with no code in sight yet

Formal Software Development Program Overview March 8, 2011 66 / 187

 When are proofs used Ideally, all the time

The earlier, the better

Formalism is especially effective during requirements and design!
Many faults appear in systems that perform as specified!; the earlier we
use these methods the better (e.g. requirements analysis): we prove that
we build the correct system (validation), not that we build the system
correctly (verification).
For many projects, requirements and design are the only parts of the
development that are formal (i.e. no formal verification of the code)
We can develop an early mathematical model of the system being built,
with no code in sight yet
This requirements model is usually based on axiomatic set theory, which
we saw that it is a particular formal system

Formal Software Development Program Overview March 8, 2011 66 / 187

 When are proofs used Ideally, all the time

The earlier, the better

Formalism is especially effective during requirements and design!
Many faults appear in systems that perform as specified!; the earlier we
use these methods the better (e.g. requirements analysis): we prove that
we build the correct system (validation), not that we build the system
correctly (verification).
For many projects, requirements and design are the only parts of the
development that are formal (i.e. no formal verification of the code)
We can develop an early mathematical model of the system being built,
with no code in sight yet
This requirements model is usually based on axiomatic set theory, which
we saw that it is a particular formal system
Communications between parts of the model are specified during design;
a different kind of formal system is used here: temporal logic

Formal Software Development Program Overview March 8, 2011 66 / 187

 When are proofs used Ideally, all the time

The earlier, the better

Formalism is especially effective during requirements and design!
Many faults appear in systems that perform as specified!; the earlier we
use these methods the better (e.g. requirements analysis): we prove that
we build the correct system (validation), not that we build the system
correctly (verification).
For many projects, requirements and design are the only parts of the
development that are formal (i.e. no formal verification of the code)
We can develop an early mathematical model of the system being built,
with no code in sight yet
This requirements model is usually based on axiomatic set theory, which
we saw that it is a particular formal system
Communications between parts of the model are specified during design;
a different kind of formal system is used here: temporal logic
The implementation and testing phases can also be treated formally,
using a variety of other formal systems
Formal Software Development Program Overview March 8, 2011 66 / 187
 When are proofs used Ideally, all the time

Conceptual integrity

Formal Software Development Program Overview March 8, 2011 67 / 187

 When are proofs used Ideally, all the time

Conceptual integrity

A software project’s aims are stated in a few sentences. Everyone fully

understands those sentences.

Formal Software Development Program Overview March 8, 2011 67 / 187

 When are proofs used Ideally, all the time

Conceptual integrity

A software project’s aims are stated in a few sentences. Everyone fully

understands those sentences. Reality?

Formal Software Development Program Overview March 8, 2011 67 / 187

 When are proofs used Ideally, all the time

Conceptual integrity

A software project’s aims are stated in a few sentences. Everyone fully

understands those sentences. Reality?
How many projects have you worked on where the project’s goals could
not be stated in a few sentences?

Formal Software Development Program Overview March 8, 2011 67 / 187

 When are proofs used Ideally, all the time

Conceptual integrity

A software project’s aims are stated in a few sentences. Everyone fully

understands those sentences. Reality?
How many projects have you worked on where the project’s goals could
not be stated in a few sentences?
How many times has the project acquired collateral goals or simply de-
generated into something else?

Formal Software Development Program Overview March 8, 2011 67 / 187

 When are proofs used Ideally, all the time

Conceptual integrity

A software project’s aims are stated in a few sentences. Everyone fully

understands those sentences. Reality?
How many projects have you worked on where the project’s goals could
not be stated in a few sentences?
How many times has the project acquired collateral goals or simply de-
generated into something else?
Think about all the methodologies and the processes you learned in the
past. Have they helped with maintaining conceptual integrity?

Formal Software Development Program Overview March 8, 2011 67 / 187

 When are proofs used Ideally, all the time

Formalization underlines conceptual integrity

Formal Software Development Program Overview March 8, 2011 68 / 187

 When are proofs used Ideally, all the time

Formalization underlines conceptual integrity

Because it supports a gradual refinement and reevaluation of the require-

ments within a rigorous frame. At the end of the formalized requirements
we have not only a correct spec but a clearer spec.

Formal Software Development Program Overview March 8, 2011 68 / 187

 When are proofs used Ideally, all the time

Formalization underlines conceptual integrity

Because it supports a gradual refinement and reevaluation of the require-

ments within a rigorous frame. At the end of the formalized requirements
we have not only a correct spec but a clearer spec.
You cannot deviate from the goals because logic will simply not allow
it; if you state a theorem, the proof must prove that theorem, not other
theorems. Moreover, the proof will be better received if it shows a ‘nec-
essary’ progression from the project axioms, axioms that everyone should
be comfortable with

Formal Software Development Program Overview March 8, 2011 68 / 187

 When are proofs used Ideally, all the time

Formalization underlines conceptual integrity

Because it supports a gradual refinement and reevaluation of the require-

ments within a rigorous frame. At the end of the formalized requirements
we have not only a correct spec but a clearer spec.
You cannot deviate from the goals because logic will simply not allow
it; if you state a theorem, the proof must prove that theorem, not other
theorems. Moreover, the proof will be better received if it shows a ‘nec-
essary’ progression from the project axioms, axioms that everyone should
be comfortable with
Because it supports clearer advancement from requirements to design
and implementation, again within rigorous frames

Formal Software Development Program Overview March 8, 2011 68 / 187

 When are proofs used Ideally, all the time

Formalization underlines conceptual integrity

Because it supports a gradual refinement and reevaluation of the require-

ments within a rigorous frame. At the end of the formalized requirements
we have not only a correct spec but a clearer spec.
You cannot deviate from the goals because logic will simply not allow
it; if you state a theorem, the proof must prove that theorem, not other
theorems. Moreover, the proof will be better received if it shows a ‘nec-
essary’ progression from the project axioms, axioms that everyone should
be comfortable with
Because it supports clearer advancement from requirements to design
and implementation, again within rigorous frames
Because conceptual integrity correlates to a higher level of abstraction,
which formalism also supports

Formal Software Development Program Overview March 8, 2011 68 / 187

 When are proofs used Ideally, all the time

Formalization underlines higher quality

Formal Software Development Program Overview March 8, 2011 69 / 187

 When are proofs used Ideally, all the time

Formalization underlines higher quality

Formal Software Development Program Overview March 8, 2011 69 / 187

 When are proofs used Ideally, all the time

Formalization underlines higher quality

Imagine a different source-control system:

Formal Software Development Program Overview March 8, 2011 69 / 187

 When are proofs used Ideally, all the time

Formalization underlines higher quality

Imagine a different source-control system:

Each component checked in has one or more proofs attached, preferably

in different formalisms

Formal Software Development Program Overview March 8, 2011 69 / 187

 When are proofs used Ideally, all the time

Formalization underlines higher quality

Imagine a different source-control system:

Each component checked in has one or more proofs attached, preferably

in different formalisms
The checkin is not accepted otherwise

Formal Software Development Program Overview March 8, 2011 69 / 187

 When are proofs used Ideally, all the time

Formalization underlines higher quality

Imagine a different source-control system:

Each component checked in has one or more proofs attached, preferably

in different formalisms
The checkin is not accepted otherwise
After check-out, you may choose to verify any one of these proofs based
on your knowledge of the formalism

Formal Software Development Program Overview March 8, 2011 69 / 187

 When are proofs used Ideally, all the time

Formalization underlines higher security

Formal Software Development Program Overview March 8, 2011 70 / 187

 When are proofs used Ideally, all the time

Formalization underlines higher security

Formal Software Development Program Overview March 8, 2011 70 / 187

 When are proofs used Ideally, all the time

Formalization underlines higher security

Imagine using the web differently:

Formal Software Development Program Overview March 8, 2011 70 / 187

 When are proofs used Ideally, all the time

Formalization underlines higher security

Imagine using the web differently:

Downloaded executable code has one or more associated proof objects

(or certificates)

Formal Software Development Program Overview March 8, 2011 70 / 187

 When are proofs used Ideally, all the time

Formalization underlines higher security

Imagine using the web differently:

Downloaded executable code has one or more associated proof objects

(or certificates)
Your computer reads the specification (=theorem) and accepts that spec-
ification

Formal Software Development Program Overview March 8, 2011 70 / 187

 When are proofs used Ideally, all the time

Formalization underlines higher security

Imagine using the web differently:

Downloaded executable code has one or more associated proof objects

(or certificates)
Your computer reads the specification (=theorem) and accepts that spec-
ification
Your computer verifies that the code is a proof of that specification

Formal Software Development Program Overview March 8, 2011 70 / 187

 When are proofs used Ideally, all the time

Formalization underlines higher security

Imagine using the web differently:

Downloaded executable code has one or more associated proof objects

(or certificates)
Your computer reads the specification (=theorem) and accepts that spec-
ification
Your computer verifies that the code is a proof of that specification
If such proof objects are absent, your computer transforms the down-
loaded code into semantically equivalent functional snippets which are
subsequently compared with a list of known threats

Formal Software Development Program Overview March 8, 2011 70 / 187

 When are proofs used Ideally, all the time

Formalization underlines higher security

Imagine using the web differently:

Downloaded executable code has one or more associated proof objects

(or certificates)
Your computer reads the specification (=theorem) and accepts that spec-
ification
Your computer verifies that the code is a proof of that specification
If such proof objects are absent, your computer transforms the down-
loaded code into semantically equivalent functional snippets which are
subsequently compared with a list of known threats
Not a database of syntactic signatures, which can easily be (and often
is) circumvented

Formal Software Development Program Overview March 8, 2011 70 / 187

 When are proofs used Why is mathematics so important in software?

Why is it so important that we use formal methods in

software engineering?

Formal Software Development Program Overview March 8, 2011 71 / 187

 When are proofs used Why is mathematics so important in software?

Why is it so important that we use formal methods in

software engineering?

All engineering disciplines use mathematics, but traditionally they do not

use formal methods

Formal Software Development Program Overview March 8, 2011 71 / 187

 When are proofs used Why is mathematics so important in software?

Why is it so important that we use formal methods in

software engineering?

All engineering disciplines use mathematics, but traditionally they do not

use formal methods
So, why are formal methods so important in software engineering?

Formal Software Development Program Overview March 8, 2011 71 / 187

 When are proofs used Why is mathematics so important in software?

Why is it so important that we use formal methods in

software engineering?

All engineering disciplines use mathematics, but traditionally they do not

use formal methods
So, why are formal methods so important in software engineering?
The main reason is that all the tools used in software, from the computer,
to operating system, to the compiler, to other applications, are essentially
formal systems, i.e. specialized languages to be used according to set
rules. So it is the very essence of software that calls for the use of formal
methods.

Formal Software Development Program Overview March 8, 2011 71 / 187

 When are proofs used Why is mathematics so important in software?

More engineering participation

Technologies to achieve quality and security are already known

Formal Software Development Program Overview March 8, 2011 72 / 187

 When are proofs used Why is mathematics so important in software?

More engineering participation

Technologies to achieve quality and security are already known

Some are not mature enough, and they probably won’t be until YOU get
interested

Formal Software Development Program Overview March 8, 2011 72 / 187

 When are proofs used Why is mathematics so important in software?

More engineering participation

Technologies to achieve quality and security are already known

Some are not mature enough, and they probably won’t be until YOU get
interested
Academia and industrial research have been interested for a long time,
but that’s not sufficient

Formal Software Development Program Overview March 8, 2011 72 / 187

 When are proofs used Models versus programs

Models versus programs

Formal Software Development Program Overview March 8, 2011 73 / 187

 When are proofs used Models versus programs

Models versus programs

Models are developed at a higher level of abstraction

Formal Software Development Program Overview March 8, 2011 73 / 187

 When are proofs used Models versus programs

Models versus programs

Models are developed at a higher level of abstraction

In functional, not imperative languages

Formal Software Development Program Overview March 8, 2011 73 / 187

 When are proofs used Models versus programs

Models versus programs

Models are developed at a higher level of abstraction

In functional, not imperative languages
There are logical tools available for building executable models

Formal Software Development Program Overview March 8, 2011 73 / 187

 When are proofs used Models versus programs

Models versus programs

Models are developed at a higher level of abstraction

In functional, not imperative languages
There are logical tools available for building executable models
They can prove that these models implement the system specification

Formal Software Development Program Overview March 8, 2011 73 / 187

 When are proofs used Models versus programs

Models versus programs

Models are developed at a higher level of abstraction

In functional, not imperative languages
There are logical tools available for building executable models
They can prove that these models implement the system specification
They deepen our understanding of the problem that we want to solve

Formal Software Development Program Overview March 8, 2011 73 / 187

 When are proofs used Models versus programs

Models versus programs

Models are developed at a higher level of abstraction

In functional, not imperative languages
There are logical tools available for building executable models
They can prove that these models implement the system specification
They deepen our understanding of the problem that we want to solve
Many times it is not even necessary to translate from a model to an
imperative program

Formal Software Development Program Overview March 8, 2011 73 / 187

 When are proofs used Models versus programs

Models versus programs

Models are developed at a higher level of abstraction

In functional, not imperative languages
There are logical tools available for building executable models
They can prove that these models implement the system specification
They deepen our understanding of the problem that we want to solve
Many times it is not even necessary to translate from a model to an
imperative program
More time should be spent with models than with programs

Formal Software Development Program Overview March 8, 2011 73 / 187

 When are proofs used Models versus programs

Some soft reasons why we do formal development

Formal Software Development Program Overview March 8, 2011 74 / 187

 When are proofs used Models versus programs

Some soft reasons why we do formal development

We also use formal methods because . . .

. . . The subject is beautiful and fun

Formal Software Development Program Overview March 8, 2011 74 / 187

 When are proofs used Models versus programs

Some soft reasons why we do formal development

We also use formal methods because . . .

. . . The subject is beautiful and fun

. . . We feel that there is more to developing software, in particular that
there should be a scientific basis to it

Formal Software Development Program Overview March 8, 2011 74 / 187

 When are proofs used Models versus programs

Some soft reasons why we do formal development

We also use formal methods because . . .

. . . The subject is beautiful and fun

. . . We feel that there is more to developing software, in particular that
there should be a scientific basis to it
. . . We get a clarification of many difficult subjects

Formal Software Development Program Overview March 8, 2011 74 / 187

 When are proofs used Models versus programs

Some soft reasons why we do formal development

We also use formal methods because . . .

. . . The subject is beautiful and fun

. . . We feel that there is more to developing software, in particular that
there should be a scientific basis to it
. . . We get a clarification of many difficult subjects
. . . We don’t need any more development methodologies and processes

Formal Software Development Program Overview March 8, 2011 74 / 187

 When are proofs used Why use formal methods now?

Why use formal methods now?

Formal Software Development Program Overview March 8, 2011 75 / 187

 When are proofs used Why use formal methods now?

Why use formal methods now?

Enough success stories

Formal Software Development Program Overview March 8, 2011 75 / 187

 When are proofs used Why use formal methods now?

Why use formal methods now?

Enough success stories

Momentum in academia and research centers

Formal Software Development Program Overview March 8, 2011 75 / 187

 When are proofs used Why use formal methods now?

Why use formal methods now?

Enough success stories

Momentum in academia and research centers
Cost of buggy software increasing, despite increased spending on testing

Formal Software Development Program Overview March 8, 2011 75 / 187

 When are proofs used Why use formal methods now?

Why use formal methods now?

Enough success stories

Momentum in academia and research centers
Cost of buggy software increasing, despite increased spending on testing
Formal methods are incorporated into standards

Formal Software Development Program Overview March 8, 2011 75 / 187

 When are proofs used Why use formal methods now?

Why use formal methods now?

Enough success stories

Momentum in academia and research centers
Cost of buggy software increasing, despite increased spending on testing
Formal methods are incorporated into standards
Companies need to prepare for the future

Formal Software Development Program Overview March 8, 2011 75 / 187

 When are proofs used Why use formal methods now?

Why use formal methods now?

Enough success stories

Momentum in academia and research centers
Cost of buggy software increasing, despite increased spending on testing
Formal methods are incorporated into standards
Companies need to prepare for the future
Many government contracts are requiring formal development

Formal Software Development Program Overview March 8, 2011 75 / 187

 When are proofs used We have enough success stories

Remarkable success story: seL4

Formal Software Development Program Overview March 8, 2011 76 / 187

 When are proofs used We have enough success stories

Remarkable success story: seL4

A full microkernel has been verified:

(find complete info at http://www.nicta.com.au/news/)

Formal Software Development Program Overview March 8, 2011 76 / 187

 When are proofs used We have enough success stories

Remarkable success story: seL4

A full microkernel has been verified:

(find complete info at http://www.nicta.com.au/news/)
Verified 7,500 lines of C code

Formal Software Development Program Overview March 8, 2011 76 / 187

 When are proofs used We have enough success stories

Remarkable success story: seL4

A full microkernel has been verified:

(find complete info at http://www.nicta.com.au/news/)
Verified 7,500 lines of C code
Proved over 10,000 intermediate theorems in over 200,000 lines of formal
proof.

Formal Software Development Program Overview March 8, 2011 76 / 187

 When are proofs used We have enough success stories

Remarkable success story: seL4

A full microkernel has been verified:

(find complete info at http://www.nicta.com.au/news/)
Verified 7,500 lines of C code
Proved over 10,000 intermediate theorems in over 200,000 lines of formal
proof.
The proof was checked with Isabelle (we will study Isabelle in the ‘Inter-
active Provers’ course)

Formal Software Development Program Overview March 8, 2011 76 / 187

 When are proofs used We have enough success stories

Remarkable success story: seL4

A full microkernel has been verified:

(find complete info at http://www.nicta.com.au/news/)
Verified 7,500 lines of C code
Proved over 10,000 intermediate theorems in over 200,000 lines of formal
proof.
The proof was checked with Isabelle (we will study Isabelle in the ‘Inter-
active Provers’ course)
One of the largest machine-checked proofs ever done.

Formal Software Development Program Overview March 8, 2011 76 / 187

 When are proofs used We have enough success stories

Remarkable success story: seL4

‘ Formal proofs for specific properties have been conducted for smaller
kernels, but what we have done is a general, functional correctness
proof which has never before been achieved for real-world, high-
performance software of this complexity or size. ’

– Gerwin Klein, NICTA

‘ It is hard to comment on this achievement without resorting to

clichés. Proving the correctness of 7,500 lines of C code in an oper-
ating system’s kernel is a unique achievement, which should eventu-
ally lead to software that meets currently unimaginable standards of
reliability. ’

– Lawrence Paulson, Cambridge University Computer Laboratory

Formal Software Development Program Overview March 8, 2011 77 / 187

 When are proofs used We have enough success stories

High complexity: the seL4 function call graph

Vertices in the graph
represent functions
in the kernel

Edges between
vertices are function
calls

An abstract func-
tional specification
of seL4 is given

The C implemen-
tation is proven to
satisfy this specifi-
cation

http://ertos.
nicta.com.au/
research/
Formal Software Development Program Overview March 8, 2011 78 / 187
 When are proofs used The Robbins conjecture

The Robbins conjecture

Formal Software Development Program Overview March 8, 2011 79 / 187

 When are proofs used The Robbins conjecture

The Robbins conjecture

Theorem: every Robbins algebra is a

Boolean algebra

In 1996, a most important success

of computer-based theorem proving
language: rules:
... Equational Logic

Object Level

tactics

checking
... Proof OK?
auto strategy
McCune Theorem?

Meta
Level
EQP
Formal Software Development Program Overview March 8, 2011 79 / 187
 When are proofs used The Robbins conjecture

The Robbins conjecture

Theorem: every Robbins algebra is a

Boolean algebra

In 1996, a most important success

of computer-based theorem proving
language: rules:
A problem that was open for 60 ... Equational Logic
years is solved by a theorem prover
Object Level

tactics

checking
... Proof OK?
auto strategy
McCune Theorem?

Meta
Level
EQP
Formal Software Development Program Overview March 8, 2011 79 / 187
 When are proofs used The Robbins conjecture

The Robbins conjecture

Theorem: every Robbins algebra is a

Boolean algebra

In 1996, a most important success

of computer-based theorem proving
language: rules:
A problem that was open for 60 ... Equational Logic
years is solved by a theorem prover
Object Level
So the solution came from a pro-
gram that was designed to reason,
in equational logic, not a program
tactics
designed for this specific problem
checking
... Proof OK?
auto strategy
McCune Theorem?

Meta
Level
EQP
Formal Software Development Program Overview March 8, 2011 79 / 187
 When are proofs used The Robbins conjecture

The Robbins conjecture

Theorem: every Robbins algebra is a

Boolean algebra

In 1996, a most important success

of computer-based theorem proving
language: rules:
A problem that was open for 60 ... Equational Logic
years is solved by a theorem prover
Object Level
So the solution came from a pro-
gram that was designed to reason,
in equational logic, not a program
tactics
designed for this specific problem
checking
(it took about 8 days on an RS/6000 ... Proof OK?
auto strategy
processor)
McCune Theorem?

Meta
Level
EQP
Formal Software Development Program Overview March 8, 2011 79 / 187
 When are proofs used The Robbins conjecture

The Robbins conjecture

Theorem: every Robbins algebra is a

Boolean algebra

In 1996, a most important success

of computer-based theorem proving
language: rules:
A problem that was open for 60 ... Equational Logic
years is solved by a theorem prover
Object Level
So the solution came from a pro-
gram that was designed to reason,
in equational logic, not a program
tactics
designed for this specific problem
checking
(it took about 8 days on an RS/6000 ... Proof OK?
auto strategy
processor)
McCune Theorem?

Formulate in your own words an ex-

Meta
planation of what this might mean Level
EQP
Formal Software Development Program Overview March 8, 2011 79 / 187
 When are proofs used Formal methods and standards

Example: Formal methods are incorporated into standards

Formal Software Development Program Overview March 8, 2011 80 / 187

 When are proofs used Formal methods and standards

Example: Formal methods are incorporated into standards

Common Criteria (an international standard since 1999) is a framework for

providing assurance that the process of specification, implementation and
evaluation of a computer security product has been conducted in a rigorous
and standard manner. Namely:

Formal Software Development Program Overview March 8, 2011 80 / 187

 When are proofs used Formal methods and standards

Example: Formal methods are incorporated into standards

Common Criteria (an international standard since 1999) is a framework for

providing assurance that the process of specification, implementation and
evaluation of a computer security product has been conducted in a rigorous
and standard manner. Namely:
Users can specify their security functional and assurance requirements

Formal Software Development Program Overview March 8, 2011 80 / 187

 When are proofs used Formal methods and standards

Example: Formal methods are incorporated into standards

Common Criteria (an international standard since 1999) is a framework for

providing assurance that the process of specification, implementation and
evaluation of a computer security product has been conducted in a rigorous
and standard manner. Namely:
Users can specify their security functional and assurance requirements
Vendors can implement and/or make claims about the security attributes
of their products

Formal Software Development Program Overview March 8, 2011 80 / 187

 When are proofs used Formal methods and standards

Example: Formal methods are incorporated into standards

Common Criteria (an international standard since 1999) is a framework for

providing assurance that the process of specification, implementation and
evaluation of a computer security product has been conducted in a rigorous
and standard manner. Namely:
Users can specify their security functional and assurance requirements
Vendors can implement and/or make claims about the security attributes
of their products
Testing laboratories can evaluate the products to determine if they ac-
tually meet the claims

Formal Software Development Program Overview March 8, 2011 80 / 187

 When are proofs used Formal methods and standards

Formal methods are incorporated into standards (cont’d)

Formal Software Development Program Overview March 8, 2011 81 / 187

 When are proofs used Formal methods and standards

Formal methods are incorporated into standards (cont’d)

Assurance levels specified by Common Criteria

Formal Software Development Program Overview March 8, 2011 81 / 187

 When are proofs used Formal methods and standards

Formal methods are incorporated into standards (cont’d)

Assurance levels specified by Common Criteria

I EAL1: Functionally Tested

Formal Software Development Program Overview March 8, 2011 81 / 187

 When are proofs used Formal methods and standards

Formal methods are incorporated into standards (cont’d)

Assurance levels specified by Common Criteria

I EAL1: Functionally Tested
I EAL2: Structurally Tested

Formal Software Development Program Overview March 8, 2011 81 / 187

 When are proofs used Formal methods and standards

Formal methods are incorporated into standards (cont’d)

Assurance levels specified by Common Criteria

I EAL1: Functionally Tested
I EAL2: Structurally Tested
I EAL3: Methodically Tested and Checked

Formal Software Development Program Overview March 8, 2011 81 / 187

 When are proofs used Formal methods and standards

Formal methods are incorporated into standards (cont’d)

Assurance levels specified by Common Criteria

I EAL1: Functionally Tested
I EAL2: Structurally Tested
I EAL3: Methodically Tested and Checked
I EAL4: Methodically Designed, Tested, and Reviewed

Formal Software Development Program Overview March 8, 2011 81 / 187

 When are proofs used Formal methods and standards

Formal methods are incorporated into standards (cont’d)

Assurance levels specified by Common Criteria

I EAL1: Functionally Tested
I EAL2: Structurally Tested
I EAL3: Methodically Tested and Checked
I EAL4: Methodically Designed, Tested, and Reviewed
I EAL5: Semi formally Designed and Tested

Formal Software Development Program Overview March 8, 2011 81 / 187

 When are proofs used Formal methods and standards

Formal methods are incorporated into standards (cont’d)

Assurance levels specified by Common Criteria

I EAL1: Functionally Tested
I EAL2: Structurally Tested
I EAL3: Methodically Tested and Checked
I EAL4: Methodically Designed, Tested, and Reviewed
I EAL5: Semi formally Designed and Tested
I EAL6: Semi formally Verified Design and Tested

Formal Software Development Program Overview March 8, 2011 81 / 187

 When are proofs used Formal methods and standards

Formal methods are incorporated into standards (cont’d)

Assurance levels specified by Common Criteria

I EAL1: Functionally Tested
I EAL2: Structurally Tested
I EAL3: Methodically Tested and Checked
I EAL4: Methodically Designed, Tested, and Reviewed
I EAL5: Semi formally Designed and Tested
I EAL6: Semi formally Verified Design and Tested
I EAL7: Formally Verified Design and Tested

Formal Software Development Program Overview March 8, 2011 81 / 187

 When are proofs used Formal methods and standards

Formal methods are incorporated into standards (cont’d)

Assurance levels specified by Common Criteria

I EAL1: Functionally Tested
I EAL2: Structurally Tested
I EAL3: Methodically Tested and Checked
I EAL4: Methodically Designed, Tested, and Reviewed
I EAL5: Semi formally Designed and Tested
I EAL6: Semi formally Verified Design and Tested
I EAL7: Formally Verified Design and Tested
Formal requirements are present in levels 5 to 7

Formal Software Development Program Overview March 8, 2011 81 / 187

 When are proofs used Formal methods and standards

Formal methods are incorporated into standards (cont’d)

Assurance levels specified by Common Criteria

I EAL1: Functionally Tested
I EAL2: Structurally Tested
I EAL3: Methodically Tested and Checked
I EAL4: Methodically Designed, Tested, and Reviewed
I EAL5: Semi formally Designed and Tested
I EAL6: Semi formally Verified Design and Tested
I EAL7: Formally Verified Design and Tested
Formal requirements are present in levels 5 to 7
This (formal methods in security apps) is just an example of international
awareness of the need for formal methods

Formal Software Development Program Overview March 8, 2011 81 / 187

 When are proofs used Formal methods and standards

Formal methods are incorporated into standards (cont’d)

Assurance levels specified by Common Criteria

I EAL1: Functionally Tested
I EAL2: Structurally Tested
I EAL3: Methodically Tested and Checked
I EAL4: Methodically Designed, Tested, and Reviewed
I EAL5: Semi formally Designed and Tested
I EAL6: Semi formally Verified Design and Tested
I EAL7: Formally Verified Design and Tested
Formal requirements are present in levels 5 to 7
This (formal methods in security apps) is just an example of international
awareness of the need for formal methods
If this example interests you, see http://www.commoncriteriaportal.
org/cc/

Formal Software Development Program Overview March 8, 2011 81 / 187

 When are proofs used Formal methods and standards

Assurance levels in the world

Formal Software Development Program Overview March 8, 2011 82 / 187

 When are proofs used Formal methods and standards

Assurance levels in the world

Shlumberger and Trusted Logic took 3 years to develop a completely

formalized model of the execution environment for the JavaCard language
and VM

Formal Software Development Program Overview March 8, 2011 82 / 187

 When are proofs used Formal methods and standards

Assurance levels in the world

Shlumberger and Trusted Logic took 3 years to develop a completely

formalized model of the execution environment for the JavaCard language
and VM
Regarded as a major work in security and the first I believe to receive
EAL7 certification for some parts

Formal Software Development Program Overview March 8, 2011 82 / 187

 When are proofs used Formal methods and standards

Assurance levels in the world

Shlumberger and Trusted Logic took 3 years to develop a completely

formalized model of the execution environment for the JavaCard language
and VM
Regarded as a major work in security and the first I believe to receive
EAL7 certification for some parts
Just to realize the scope of this achievement of formal methods in the
security area, the JavaCard development was done in 121000 lines of
Coq spread over 278 modules (we study Coq in the ‘Interactive Provers’
course).

Formal Software Development Program Overview March 8, 2011 82 / 187

 When are proofs used Formal methods and standards

Assurance levels in the world

Shlumberger and Trusted Logic took 3 years to develop a completely

formalized model of the execution environment for the JavaCard language
and VM
Regarded as a major work in security and the first I believe to receive
EAL7 certification for some parts
Just to realize the scope of this achievement of formal methods in the
security area, the JavaCard development was done in 121000 lines of
Coq spread over 278 modules (we study Coq in the ‘Interactive Provers’
course).
More on JavaCard formalization at http://www.commoncriteriaportal.
org/iccc/9iccc/pdf/B2404.pdf

Formal Software Development Program Overview March 8, 2011 82 / 187

 When are proofs used Formal methods and standards

Assurance levels in the world

Shlumberger and Trusted Logic took 3 years to develop a completely

formalized model of the execution environment for the JavaCard language
and VM
Regarded as a major work in security and the first I believe to receive
EAL7 certification for some parts
Just to realize the scope of this achievement of formal methods in the
security area, the JavaCard development was done in 121000 lines of
Coq spread over 278 modules (we study Coq in the ‘Interactive Provers’
course).
More on JavaCard formalization at http://www.commoncriteriaportal.
org/iccc/9iccc/pdf/B2404.pdf
Australia, august 2009, NICTA’s Secure Embedded L4 (seL4) microker-
nel was certified EAL7

Formal Software Development Program Overview March 8, 2011 82 / 187

 When are proofs used Formal methods and standards

Assurance levels in US

Formal Software Development Program Overview March 8, 2011 83 / 187

 When are proofs used Formal methods and standards

Assurance levels in US

November 2008, National Security Agency (NSA) certified Green Hills

Software’s Integrity operating system at EAL6+. First deployed in the
B1B bomber in 1997, today runs in military and commercial aircraft,

Formal Software Development Program Overview March 8, 2011 83 / 187

 When are proofs used Formal methods and standards

Assurance levels in US

November 2008, National Security Agency (NSA) certified Green Hills

Software’s Integrity operating system at EAL6+. First deployed in the
B1B bomber in 1997, today runs in military and commercial aircraft,
I including the Airbus 380 and Boeing 787 airplanes

Formal Software Development Program Overview March 8, 2011 83 / 187

 When are proofs used Formal methods and standards

Assurance levels in US

November 2008, National Security Agency (NSA) certified Green Hills

Software’s Integrity operating system at EAL6+. First deployed in the
B1B bomber in 1997, today runs in military and commercial aircraft,
I including the Airbus 380 and Boeing 787 airplanes
I and the F-16, F-22, and F-35 military jets

Formal Software Development Program Overview March 8, 2011 83 / 187

 When are proofs used Formal methods and standards

Assurance levels in US

November 2008, National Security Agency (NSA) certified Green Hills

Software’s Integrity operating system at EAL6+. First deployed in the
B1B bomber in 1997, today runs in military and commercial aircraft,
I including the Airbus 380 and Boeing 787 airplanes
I and the F-16, F-22, and F-35 military jets
Read more at http://www.integrityglobalsecurity.com/

Formal Software Development Program Overview March 8, 2011 83 / 187

 When are proofs used Formal methods and standards

Assurance levels in US

November 2008, National Security Agency (NSA) certified Green Hills

Software’s Integrity operating system at EAL6+. First deployed in the
B1B bomber in 1997, today runs in military and commercial aircraft,
I including the Airbus 380 and Boeing 787 airplanes
I and the F-16, F-22, and F-35 military jets
Read more at http://www.integrityglobalsecurity.com/
Windows and Linux can be run under Integrity, virtualized as guest OSs

Formal Software Development Program Overview March 8, 2011 83 / 187

 When are proofs used Formal methods and standards

Assurance levels in US

November 2008, National Security Agency (NSA) certified Green Hills

Software’s Integrity operating system at EAL6+. First deployed in the
B1B bomber in 1997, today runs in military and commercial aircraft,
I including the Airbus 380 and Boeing 787 airplanes
I and the F-16, F-22, and F-35 military jets
Read more at http://www.integrityglobalsecurity.com/
Windows and Linux can be run under Integrity, virtualized as guest OSs
Windows and Linux are EAL 4+

Formal Software Development Program Overview March 8, 2011 83 / 187

 When are proofs used Why teach formal software through an extension program?

Why do this program at the UC Extension?

Formal Software Development Program Overview March 8, 2011 84 / 187

 When are proofs used Why teach formal software through an extension program?

Why do this program at the UC Extension?

Your experience as active professionals is essential

Formal Software Development Program Overview March 8, 2011 84 / 187

 When are proofs used Why teach formal software through an extension program?

Why do this program at the UC Extension?

Your experience as active professionals is essential

Your frustration with ever buggy software is a motivating factor

Formal Software Development Program Overview March 8, 2011 84 / 187

 When are proofs used Why teach formal software through an extension program?

Why do this program at the UC Extension?

Your experience as active professionals is essential

Your frustration with ever buggy software is a motivating factor
Your computational intuition is needed, especially for concurrent systems

Formal Software Development Program Overview March 8, 2011 84 / 187

 When are proofs used Why teach formal software through an extension program?

Why do this program at the UC Extension?

Your experience as active professionals is essential

Your frustration with ever buggy software is a motivating factor
Your computational intuition is needed, especially for concurrent systems
We need to accumulate more experience on how these logical methods
fit into an industrial setting

Formal Software Development Program Overview March 8, 2011 84 / 187

 When are proofs used Why teach formal software through an extension program?

Why do this program at the UC Extension?

Your experience as active professionals is essential

Your frustration with ever buggy software is a motivating factor
Your computational intuition is needed, especially for concurrent systems
We need to accumulate more experience on how these logical methods
fit into an industrial setting
CS departments teach formal methods in bits and pieces, they have plenty
of other material to worry about

Formal Software Development Program Overview March 8, 2011 84 / 187

 When are proofs used Why teach formal software through an extension program?

Why do this program at the UC Extension?

Your experience as active professionals is essential

Your frustration with ever buggy software is a motivating factor
Your computational intuition is needed, especially for concurrent systems
We need to accumulate more experience on how these logical methods
fit into an industrial setting
CS departments teach formal methods in bits and pieces, they have plenty
of other material to worry about
Specialized conferences cater to specialists/implementers, not much to
software engineers

Formal Software Development Program Overview March 8, 2011 84 / 187

 When are proofs used Why teach formal software through an extension program?

Why do this program at the UC Extension?

Your experience as active professionals is essential

Your frustration with ever buggy software is a motivating factor
Your computational intuition is needed, especially for concurrent systems
We need to accumulate more experience on how these logical methods
fit into an industrial setting
CS departments teach formal methods in bits and pieces, they have plenty
of other material to worry about
Specialized conferences cater to specialists/implementers, not much to
software engineers
Not everyone has NASA’s budget to afford training of their staff

Formal Software Development Program Overview March 8, 2011 84 / 187

 When are proofs used Why teach formal software through an extension program?

Why do this program at the UC Extension?

Your experience as active professionals is essential

Your frustration with ever buggy software is a motivating factor
Your computational intuition is needed, especially for concurrent systems
We need to accumulate more experience on how these logical methods
fit into an industrial setting
CS departments teach formal methods in bits and pieces, they have plenty
of other material to worry about
Specialized conferences cater to specialists/implementers, not much to
software engineers
Not everyone has NASA’s budget to afford training of their staff
We might get your organization interested in customizing/improving
these (mostly open-source) tools

Formal Software Development Program Overview March 8, 2011 84 / 187

 What formal software development is not

1 What is formal software development

2 Implementing formal systems

3 When are proofs used

4 What formal software development is not

5 Formal verification of programs

6 Mathematics and Software

7 Concrete examples of what we do in the program

8 Program goals and course structure

Formal Software Development Program Overview March 8, 2011 85 / 187
 What formal software development is not Some controversy

Some controversy about applicability

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 86 / 187
e scie
 What formal software development is not Some controversy

Some controversy about applicability

The use of formal methods in software development has been controver-

sial

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 86 / 187
e scie
 What formal software development is not Some controversy

Some controversy about applicability

The use of formal methods in software development has been controver-

sial
When foundations were laid out in the 60’s and 70’s, industry reacted
with enthusiasm

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 86 / 187
e scie
 What formal software development is not Some controversy

Some controversy about applicability

The use of formal methods in software development has been controver-

sial
When foundations were laid out in the 60’s and 70’s, industry reacted
with enthusiasm
In the 80’s and 90’s, although important advances were made, few of
them saw practical applications, and the enthusiasm in the industry went
down

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 86 / 187
e scie
 What formal software development is not Some controversy

Some controversy about applicability

The use of formal methods in software development has been controver-

sial
When foundations were laid out in the 60’s and 70’s, industry reacted
with enthusiasm
In the 80’s and 90’s, although important advances were made, few of
them saw practical applications, and the enthusiasm in the industry went
down
Computer-generated proofs were viewed suspiciously both by mathemati-
cians and by software engineers, for different reasons:

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 86 / 187
e scie
 What formal software development is not Some controversy

Some controversy about applicability

The use of formal methods in software development has been controver-

sial
When foundations were laid out in the 60’s and 70’s, industry reacted
with enthusiasm
In the 80’s and 90’s, although important advances were made, few of
them saw practical applications, and the enthusiasm in the industry went
down
Computer-generated proofs were viewed suspiciously both by mathemati-
cians and by software engineers, for different reasons:
I By mathematicians: obstacles were attributed to the theoretical
limitations imposed by the incompleteness theorems of mathemat-
ical logic

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 86 / 187
e scie
 What formal software development is not Some controversy

Some controversy about applicability

The use of formal methods in software development has been controver-

sial
When foundations were laid out in the 60’s and 70’s, industry reacted
with enthusiasm
In the 80’s and 90’s, although important advances were made, few of
them saw practical applications, and the enthusiasm in the industry went
down
Computer-generated proofs were viewed suspiciously both by mathemati-
cians and by software engineers, for different reasons:
I By mathematicians: obstacles were attributed to the theoretical
limitations imposed by the incompleteness theorems of mathemat-
ical logic
I By software engineers: the tools required too much specialized
knowledge and were only useful for small applications Not
just
y. Not ut
odolog
t ju st a meth a dogma. B
o
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 86 / 187
e scie
 What formal software development is not Some controversy

Nevertheless, formal methods kept making steady progress

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 87 / 187
e scie
 What formal software development is not Some controversy

Nevertheless, formal methods kept making steady progress

During the 80’s and 90’s perceived downtime, many people ignored the
lack of enthusiasm for formalism and developed efficient algorithms for
high-complexity problems, that performed remarkably well in practical
situations

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 87 / 187
e scie
 What formal software development is not Some controversy

Nevertheless, formal methods kept making steady progress

During the 80’s and 90’s perceived downtime, many people ignored the
lack of enthusiasm for formalism and developed efficient algorithms for
high-complexity problems, that performed remarkably well in practical
situations
Many of the most successful logical frameworks were born in this period

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 87 / 187
e scie
 What formal software development is not Some controversy

Nevertheless, formal methods kept making steady progress

During the 80’s and 90’s perceived downtime, many people ignored the
lack of enthusiasm for formalism and developed efficient algorithms for
high-complexity problems, that performed remarkably well in practical
situations
Many of the most successful logical frameworks were born in this period
This not-so-visible successes led to the current revival of formal methods
in software development

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 87 / 187
e scie
 What formal software development is not Some controversy

Nevertheless, formal methods kept making steady progress

During the 80’s and 90’s perceived downtime, many people ignored the
lack of enthusiasm for formalism and developed efficient algorithms for
high-complexity problems, that performed remarkably well in practical
situations
Many of the most successful logical frameworks were born in this period
This not-so-visible successes led to the current revival of formal methods
in software development
We are at the beginning of a forceful and active period of formal software
development

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 87 / 187
e scie
 What formal software development is not Engineering or science?

Engineering or science?

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 88 / 187
e scie
 What formal software development is not Engineering or science?

Engineering or science?

It’s been said that ‘Software engineering is not computer science’

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 88 / 187
e scie
 What formal software development is not Engineering or science?

Engineering or science?

It’s been said that ‘Software engineering is not computer science’

Fair enough: engineering, period . . . is not science, period

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 88 / 187
e scie
 What formal software development is not Engineering or science?

Engineering or science?

It’s been said that ‘Software engineering is not computer science’

Fair enough: engineering, period . . . is not science, period
That does not imply that there must not be a scientific basis to software

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 88 / 187
e scie
 What formal software development is not Engineering or science?

Engineering or science?

It’s been said that ‘Software engineering is not computer science’

Fair enough: engineering, period . . . is not science, period
That does not imply that there must not be a scientific basis to software
Chemical engineers need to know a science called chemistry

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 88 / 187
e scie
 What formal software development is not Engineering or science?

Engineering or science?

It’s been said that ‘Software engineering is not computer science’

Fair enough: engineering, period . . . is not science, period
That does not imply that there must not be a scientific basis to software
Chemical engineers need to know a science called chemistry
Nuclear engineers need to know a science called physics

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 88 / 187
e scie
 What formal software development is not Engineering or science?

Engineering or science?

It’s been said that ‘Software engineering is not computer science’

Fair enough: engineering, period . . . is not science, period
That does not imply that there must not be a scientific basis to software
Chemical engineers need to know a science called chemistry
Nuclear engineers need to know a science called physics
What is the science that software engineers need to know?

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 88 / 187
e scie
 What formal software development is not Engineering or science?

Engineering AND science!

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 89 / 187
e scie
 What formal software development is not Engineering or science?

Engineering AND science!

Software engineering made huge advances, without waiting for the sci-
ence

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 89 / 187
e scie
 What formal software development is not Engineering or science?

Engineering AND science!

Software engineering made huge advances, without waiting for the sci-
ence
It’s been one of the most astonishing engineering disciplines of our time

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 89 / 187
e scie
 What formal software development is not Engineering or science?

Engineering AND science!

Software engineering made huge advances, without waiting for the sci-
ence
It’s been one of the most astonishing engineering disciplines of our time
We can’t say ‘Stop, you have to learn formal systems before you write
one more line of C code’

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 89 / 187
e scie
 What formal software development is not Engineering or science?

Engineering AND science!

Software engineering made huge advances, without waiting for the sci-
ence
It’s been one of the most astonishing engineering disciplines of our time
We can’t say ‘Stop, you have to learn formal systems before you write
one more line of C code’
What we do say is that some training in formal systems is becoming
necessary

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 89 / 187
e scie
 What formal software development is not Engineering or science?

Engineering AND science!

Software engineering made huge advances, without waiting for the sci-
ence
It’s been one of the most astonishing engineering disciplines of our time
We can’t say ‘Stop, you have to learn formal systems before you write
one more line of C code’
What we do say is that some training in formal systems is becoming
necessary
For critical software, this has been clear for some time

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 89 / 187
e scie
 What formal software development is not Engineering or science?

Engineering AND science!

Software engineering made huge advances, without waiting for the sci-
ence
It’s been one of the most astonishing engineering disciplines of our time
We can’t say ‘Stop, you have to learn formal systems before you write
one more line of C code’
What we do say is that some training in formal systems is becoming
necessary
For critical software, this has been clear for some time
But the benefits of formal systems are that they lead to a different way
of thinking about software, any software, not just critical software

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 89 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

Are formal methods providing certainty?

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 90 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

Are formal methods providing certainty?

Formal software development is many times wrongly associated with an

absolute ‘certainty that there are no faults’

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 90 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

Are formal methods providing certainty?

Formal software development is many times wrongly associated with an

absolute ‘certainty that there are no faults’
This is not so and cannot be so

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 90 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

Are formal methods providing certainty?

Formal software development is many times wrongly associated with an

absolute ‘certainty that there are no faults’
This is not so and cannot be so
We can never be certain of our formal systems themselves; this is actually
a theorem of metamathematics, not an ideological position

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 90 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

Are formal methods providing certainty?

Formal software development is many times wrongly associated with an

absolute ‘certainty that there are no faults’
This is not so and cannot be so
We can never be certain of our formal systems themselves; this is actually
a theorem of metamathematics, not an ideological position
We cannot prove that ZFC is consistent without using principles that are
outside of ZFC, we just have enough evidence that it is

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 90 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

Are formal methods providing certainty?

Formal software development is many times wrongly associated with an

absolute ‘certainty that there are no faults’
This is not so and cannot be so
We can never be certain of our formal systems themselves; this is actually
a theorem of metamathematics, not an ideological position
We cannot prove that ZFC is consistent without using principles that are
outside of ZFC, we just have enough evidence that it is
We can prove ZFC consistency in a more powerful system than ZFC
(which by the way is not finitary anymore), and then this system needs
a proof of consistency in a still more powerful system, in a never ending
chain.

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 90 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

Are formal methods providing certainty?

Formal software development is many times wrongly associated with an

absolute ‘certainty that there are no faults’
This is not so and cannot be so
We can never be certain of our formal systems themselves; this is actually
a theorem of metamathematics, not an ideological position
We cannot prove that ZFC is consistent without using principles that are
outside of ZFC, we just have enough evidence that it is
We can prove ZFC consistency in a more powerful system than ZFC
(which by the way is not finitary anymore), and then this system needs
a proof of consistency in a still more powerful system, in a never ending
chain.
We cannot bootstrap this process.
Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 90 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

If we cannot do that, what can we do?

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 91 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

If we cannot do that, what can we do?

What we can and do achieve with formalism is proving correctness relative to

a given formal system, i.e. relative to a set of rules, and under a set of
assumptions that we need to fully spell out.

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 91 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

If we cannot do that, what can we do?

What we can and do achieve with formalism is proving correctness relative to

a given formal system, i.e. relative to a set of rules, and under a set of
assumptions that we need to fully spell out.

That’s all, and that’s all we’ll ever get.

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 91 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

If we cannot do that, what can we do?

What we can and do achieve with formalism is proving correctness relative to

a given formal system, i.e. relative to a set of rules, and under a set of
assumptions that we need to fully spell out.

That’s all, and that’s all we’ll ever get. But this is also all that we need to
get!

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 91 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

If we cannot do that, what can we do?

What we can and do achieve with formalism is proving correctness relative to

a given formal system, i.e. relative to a set of rules, and under a set of
assumptions that we need to fully spell out.

That’s all, and that’s all we’ll ever get. But this is also all that we need to
get! This qualified claim of correctness is based on a chain of trust, shown in
the following slide.

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 91 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

Relative correctness

The chain of trust

Assuming that:
the hardware and the OS work properly
the compiler of your logical tool works properly
the logic behind the tool is consistent
the tool implements the logic correctly
your theory is consistent with the logic
your proof is checked by the logical tool
then
your proof is correct.
Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 92 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

Strongest claim we can make

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 93 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

Strongest claim we can make

This relative correctness is the strongest claim we can make

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 93 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

Strongest claim we can make

This relative correctness is the strongest claim we can make

No other approach to software development can give stronger assurances

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 93 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

Strongest claim we can make

This relative correctness is the strongest claim we can make

No other approach to software development can give stronger assurances
The most likely failure would be that your theory is not consistent with
the prover’s logic

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 93 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

Strongest claim we can make

This relative correctness is the strongest claim we can make

No other approach to software development can give stronger assurances
The most likely failure would be that your theory is not consistent with
the prover’s logic
If the hardware fails, all hell breaks loose

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 93 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

Strongest claim we can make

This relative correctness is the strongest claim we can make

No other approach to software development can give stronger assurances
The most likely failure would be that your theory is not consistent with
the prover’s logic
If the hardware fails, all hell breaks loose
(formal hardware verification uses some of the same provers we study)

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 93 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

Strongest claim we can make

This relative correctness is the strongest claim we can make

No other approach to software development can give stronger assurances
The most likely failure would be that your theory is not consistent with
the prover’s logic
If the hardware fails, all hell breaks loose
(formal hardware verification uses some of the same provers we study)
If the compiler or the logical tool fail, the failure will likely show up in
more obvious places

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 93 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

Strongest claim we can make

This relative correctness is the strongest claim we can make

No other approach to software development can give stronger assurances
The most likely failure would be that your theory is not consistent with
the prover’s logic
If the hardware fails, all hell breaks loose
(formal hardware verification uses some of the same provers we study)
If the compiler or the logical tool fail, the failure will likely show up in
more obvious places
(much work is done in formal compiler and tool verification)

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 93 / 187
e scie
 What formal software development is not Are formal methods providing certainty?

Strongest claim we can make

This relative correctness is the strongest claim we can make

No other approach to software development can give stronger assurances
The most likely failure would be that your theory is not consistent with
the prover’s logic
If the hardware fails, all hell breaks loose
(formal hardware verification uses some of the same provers we study)
If the compiler or the logical tool fail, the failure will likely show up in
more obvious places
(much work is done in formal compiler and tool verification)
The correctness of a tool’s implementation is a subject of much research
Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 93 / 187
e scie
 What formal software development is not Not just another development methodology

Not just another methodology or process

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 94 / 187
e scie
 What formal software development is not Not just another development methodology

Not just another methodology or process

We have had many methodologies: structured, object-oriented, extreme,

test-driven, . . .

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 94 / 187
e scie
 What formal software development is not Not just another development methodology

Not just another methodology or process

We have had many methodologies: structured, object-oriented, extreme,

test-driven, . . .
Formal development is not just another methodology!

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 94 / 187
e scie
 What formal software development is not Not just another development methodology

Not just another methodology or process

We have had many methodologies: structured, object-oriented, extreme,

test-driven, . . .
Formal development is not just another methodology!
(chemistry is not just a methodology to be used by chemical engineers)

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 94 / 187
e scie
 What formal software development is not Not just another development methodology

Not just another methodology or process

We have had many methodologies: structured, object-oriented, extreme,

test-driven, . . .
Formal development is not just another methodology!
(chemistry is not just a methodology to be used by chemical engineers)
There is of course some methodology and process associated with formal
methods

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 94 / 187
e scie
 What formal software development is not Not just another development methodology

Not just another methodology or process

We have had many methodologies: structured, object-oriented, extreme,

test-driven, . . .
Formal development is not just another methodology!
(chemistry is not just a methodology to be used by chemical engineers)
There is of course some methodology and process associated with formal
methods
We will actually spend some time looking at formal methodology and
process

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 94 / 187
e scie
 What formal software development is not Not just another development methodology

Not just another methodology or process

We have had many methodologies: structured, object-oriented, extreme,

test-driven, . . .
Formal development is not just another methodology!
(chemistry is not just a methodology to be used by chemical engineers)
There is of course some methodology and process associated with formal
methods
We will actually spend some time looking at formal methodology and
process
But the main point is that formal systems are the scientific basis of
software

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 94 / 187
e scie
 What formal software development is not Not just another development methodology

Are there two kinds of software?

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 95 / 187
e scie
 What formal software development is not Not just another development methodology

Are there two kinds of software?

It is said that formal methods are too expensive

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 95 / 187
e scie
 What formal software development is not Not just another development methodology

Are there two kinds of software?

It is said that formal methods are too expensive

. . . and are only used in ‘critical software’

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 95 / 187
e scie
 What formal software development is not Not just another development methodology

Are there two kinds of software?

It is said that formal methods are too expensive

. . . and are only used in ‘critical software’
In other words, we have 2 kinds of software

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 95 / 187
e scie
 What formal software development is not Not just another development methodology

Are there two kinds of software?

It is said that formal methods are too expensive

. . . and are only used in ‘critical software’
In other words, we have 2 kinds of software
I The kind that is not OK to fail

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 95 / 187
e scie
 What formal software development is not Not just another development methodology

Are there two kinds of software?

It is said that formal methods are too expensive

. . . and are only used in ‘critical software’
In other words, we have 2 kinds of software
I The kind that is not OK to fail
I The kind that is OK to fail

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 95 / 187
e scie
 What formal software development is not Not just another development methodology

Are there two kinds of software?

It is said that formal methods are too expensive

. . . and are only used in ‘critical software’
In other words, we have 2 kinds of software
I The kind that is not OK to fail
I The kind that is OK to fail

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 95 / 187
e scie
 What formal software development is not Not just another development methodology

Are there two kinds of software?

It is said that formal methods are too expensive

. . . and are only used in ‘critical software’
In other words, we have 2 kinds of software
I The kind that is not OK to fail
I The kind that is OK to fail

It this true?

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 95 / 187
e scie
 What formal software development is not Not just another development methodology

Are there two kinds of software?

It is said that formal methods are too expensive

. . . and are only used in ‘critical software’
In other words, we have 2 kinds of software
I The kind that is not OK to fail
I The kind that is OK to fail

It this true? Of course it is true, and if we base our value judgements on

testing, software will always fall into the second category, regardless of when
the testing is done or how good it is. Quite often, decision makers are not
even aware that there is an alternative.

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 95 / 187
e scie
 What formal software development is not Not just another development methodology

The hype issue

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 96 / 187
e scie
 What formal software development is not Not just another development methodology

The hype issue

On Wikipedia, the ‘hype curve’ is defined as a ‘graphic representation of the

maturity, adoption and social application of specific technologies’. It
matches quite well with the trajectory of many technologies that were used
for software development.

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 96 / 187
e scie
 What formal software development is not Not just another development methodology

The hype issue

On Wikipedia, the ‘hype curve’ is defined as a ‘graphic representation of the

maturity, adoption and social application of specific technologies’. It
matches quite well with the trajectory of many technologies that were used
for software development.

It has also been mentioned in the context of formal methods. But formal
methods are not just a technology. Their scientific component has Not just
y. Not ut
continuously advanced upward, as any science does. odolog
t ju st a meth a dogma. B
N o t e. . No ind soft
war
Formal Software Development Program Overview process8,n2011
a March ce beh 96 / 187
e scie
 What formal software development is not Not just another development methodology

Not just software with math but also math with software

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 97 / 187
e scie
 What formal software development is not Not just another development methodology

Not just software with math but also math with software

Our definition shows a one-way dependency of formal software develop-

ment on mathematics

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 97 / 187
e scie
 What formal software development is not Not just another development methodology

Not just software with math but also math with software

Our definition shows a one-way dependency of formal software develop-

ment on mathematics
(this fits our purpose)

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 97 / 187
e scie
 What formal software development is not Not just another development methodology

Not just software with math but also math with software

Our definition shows a one-way dependency of formal software develop-

ment on mathematics
(this fits our purpose)
However, software engineering also has an increasing impact on mathe-
matics

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 97 / 187
e scie
 What formal software development is not Not just another development methodology

Not just software with math but also math with software

Our definition shows a one-way dependency of formal software develop-

ment on mathematics
(this fits our purpose)
However, software engineering also has an increasing impact on mathe-
matics
I Some important math has been done and is being done with soft-
ware systems

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 97 / 187
e scie
 What formal software development is not Not just another development methodology

Not just software with math but also math with software

Our definition shows a one-way dependency of formal software develop-

ment on mathematics
(this fits our purpose)
However, software engineering also has an increasing impact on mathe-
matics
I Some important math has been done and is being done with soft-
ware systems
I Despite a barrage of limiting results from mathematics in the 1930’s,
efficient algorithms and structures have been developed for very
hard problems

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 97 / 187
e scie
 What formal software development is not Not just another development methodology

Not just software with math but also math with software

Our definition shows a one-way dependency of formal software develop-

ment on mathematics
(this fits our purpose)
However, software engineering also has an increasing impact on mathe-
matics
I Some important math has been done and is being done with soft-
ware systems
I Despite a barrage of limiting results from mathematics in the 1930’s,
efficient algorithms and structures have been developed for very
hard problems
I The extreme cases that are behind those limiting results of mathe-
matics rarely pop up in practical situations (the kind we encounter
in software development)
Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 97 / 187
e scie
 What formal software development is not Not just another development methodology

Proofs do not replace engineering

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 98 / 187
e scie
 What formal software development is not Not just another development methodology

Proofs do not replace engineering

As we have said already, proofs are relative to a specified formal system

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 98 / 187
e scie
 What formal software development is not Not just another development methodology

Proofs do not replace engineering

As we have said already, proofs are relative to a specified formal system

They are not a reflection of reality

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 98 / 187
e scie
 What formal software development is not Not just another development methodology

Proofs do not replace engineering

As we have said already, proofs are relative to a specified formal system

They are not a reflection of reality
Whether the formal system captures the form of an intended reality is a
different issue

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 98 / 187
e scie
 What formal software development is not Not just another development methodology

Proofs do not replace engineering

As we have said already, proofs are relative to a specified formal system

They are not a reflection of reality
Whether the formal system captures the form of an intended reality is a
different issue
That issue is important though, and only our engineering expertize can
address it

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 98 / 187
e scie
 What formal software development is not Not just another development methodology

Proofs do not replace engineering

As we have said already, proofs are relative to a specified formal system

They are not a reflection of reality
Whether the formal system captures the form of an intended reality is a
different issue
That issue is important though, and only our engineering expertize can
address it
So, engineering expertize is essential for the effective applicability of
formal methods

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 98 / 187
e scie
 What formal software development is not Not just another development methodology

Proofs do not replace engineering

As we have said already, proofs are relative to a specified formal system

They are not a reflection of reality
Whether the formal system captures the form of an intended reality is a
different issue
That issue is important though, and only our engineering expertize can
address it
So, engineering expertize is essential for the effective applicability of
formal methods
Very likely that engineering expertize could also help with the effort to
produce a more usable formalization of mathematics itself

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 98 / 187
e scie
 What formal software development is not Not just another development methodology

Proofs do not replace engineering

As we have said already, proofs are relative to a specified formal system

They are not a reflection of reality
Whether the formal system captures the form of an intended reality is a
different issue
That issue is important though, and only our engineering expertize can
address it
So, engineering expertize is essential for the effective applicability of
formal methods
Very likely that engineering expertize could also help with the effort to
produce a more usable formalization of mathematics itself
The same way that the engineering of the Large Hadron Collider is helping
physicists do their work t No
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 98 / 187
e scie
 What formal software development is not Not just another development methodology

Do formal methods eliminate the need for informal testing?

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 99 / 187
e scie
 What formal software development is not Not just another development methodology

Do formal methods eliminate the need for informal testing?

Absolutely not!

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 99 / 187
e scie
 What formal software development is not Not just another development methodology

Do formal methods eliminate the need for informal testing?

Absolutely not!
Any link in the chain of trust can fail!

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 99 / 187
e scie
 What formal software development is not Not just another development methodology

Do formal methods eliminate the need for informal testing?

Absolutely not!
Any link in the chain of trust can fail!
Informal testing needs to exclude common-sense faults . . .

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 99 / 187
e scie
 What formal software development is not Not just another development methodology

Do formal methods eliminate the need for informal testing?

Absolutely not!
Any link in the chain of trust can fail!
Informal testing needs to exclude common-sense faults . . .
There are various estimates for the radius of the universe. One of the
original formulas for such a radius was a beautiful one and had a beautiful
proof. It took years before someone bothered to plug in all the numbers
and do the calculation.

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 99 / 187
e scie
 What formal software development is not Not just another development methodology

Do formal methods eliminate the need for informal testing?

Absolutely not!
Any link in the chain of trust can fail!
Informal testing needs to exclude common-sense faults . . .
There are various estimates for the radius of the universe. One of the
original formulas for such a radius was a beautiful one and had a beautiful
proof. It took years before someone bothered to plug in all the numbers
and do the calculation. It came to about 4 inches.

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process8,n2011
a March ce beh 99 / 187
e scie
 What formal software development is not Not just another development methodology

Should everyone use formal methods?

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process
aMarch nce beh 100 / 187
8,ie2011
e sc
 What formal software development is not Not just another development methodology

Should everyone use formal methods?

Every organization would benefit from a gradual introduction of formal

methods

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process
aMarch nce beh 100 / 187
8,ie2011
e sc
 What formal software development is not Not just another development methodology

Should everyone use formal methods?

Every organization would benefit from a gradual introduction of formal

methods
What about the good software that has been developed without any
formalism? Quick example: STL and Boost C++ libraries

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process
aMarch nce beh 100 / 187
8,ie2011
e sc
 What formal software development is not Not just another development methodology

Should everyone use formal methods?

Every organization would benefit from a gradual introduction of formal

methods
What about the good software that has been developed without any
formalism? Quick example: STL and Boost C++ libraries
These libraries have some mathematical background, giving guarantees
of performance for the algorithms

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process
aMarch nce beh 100 / 187
8,ie2011
e sc
 What formal software development is not Not just another development methodology

Should everyone use formal methods?

Every organization would benefit from a gradual introduction of formal

methods
What about the good software that has been developed without any
formalism? Quick example: STL and Boost C++ libraries
These libraries have some mathematical background, giving guarantees
of performance for the algorithms
These guarantees are not formal though, there is no proof

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process
aMarch nce beh 100 / 187
8,ie2011
e sc
 What formal software development is not Not just another development methodology

Should everyone use formal methods?

Every organization would benefit from a gradual introduction of formal

methods
What about the good software that has been developed without any
formalism? Quick example: STL and Boost C++ libraries
These libraries have some mathematical background, giving guarantees
of performance for the algorithms
These guarantees are not formal though, there is no proof
Imagine libraries that can give formal guarantees, with proofs that can
be independently verified

Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process
aMarch nce beh 100 / 187
8,ie2011
e sc
 What formal software development is not Not just another development methodology

Should everyone use formal methods?

Every organization would benefit from a gradual introduction of formal

methods
What about the good software that has been developed without any
formalism? Quick example: STL and Boost C++ libraries
These libraries have some mathematical background, giving guarantees
of performance for the algorithms
These guarantees are not formal though, there is no proof
Imagine libraries that can give formal guarantees, with proofs that can
be independently verified
Once more, the benefits of formal systems are that they lead to a different
way of thinking about software, any software, not just critical software
Not
t just
gy. No
a m et hodolo ma. But
o t ju st a d o g
N . Not ind software.
Formal Software Development Program Overview process
aMarch nce beh 100 / 187
8,ie2011
e sc
 Formal verification of programs

1 What is formal software development

2 Implementing formal systems

3 When are proofs used

4 What formal software development is not

5 Formal verification of programs

6 Mathematics and Software

7 Concrete examples of what we do in the program

8 Program goals and course structure

Formal Software Development Program Overview March 8, 2011 101 / 187
 Formal verification of programs

Formal verification of programs

Formal Software Development Program Overview March 8, 2011 102 / 187

 Formal verification of programs

Formal verification of programs

In a sense narrower than formal software development, formal software

verification is the use of mathematical techniques to prove properties of
programs: correctness, termination, deadlock-freedom, etc . . .

Formal Software Development Program Overview March 8, 2011 102 / 187

 Formal verification of programs

Formal verification of programs

In a sense narrower than formal software development, formal software

verification is the use of mathematical techniques to prove properties of
programs: correctness, termination, deadlock-freedom, etc . . .
Very often, when people talk about formal software, they mean formal
verification of programs

Formal Software Development Program Overview March 8, 2011 102 / 187

 Formal verification of programs

Formal verification of programs

In a sense narrower than formal software development, formal software

verification is the use of mathematical techniques to prove properties of
programs: correctness, termination, deadlock-freedom, etc . . .
Very often, when people talk about formal software, they mean formal
verification of programs
We repeat that, for many projects, requirements and specifications are
the only parts of the development that are formal, because faulty speci-
fications are more expensive than faulty programs

Formal Software Development Program Overview March 8, 2011 102 / 187

 Formal verification of programs

Formal verification of programs

In a sense narrower than formal software development, formal software

verification is the use of mathematical techniques to prove properties of
programs: correctness, termination, deadlock-freedom, etc . . .
Very often, when people talk about formal software, they mean formal
verification of programs
We repeat that, for many projects, requirements and specifications are
the only parts of the development that are formal, because faulty speci-
fications are more expensive than faulty programs
So, although the topic of this section is formal program verification, we
always keep the entire formal development cycle in mind

Formal Software Development Program Overview March 8, 2011 102 / 187

 Formal verification of programs Imperative versus functional

Verification of functional and imperative programs

Formal Software Development Program Overview March 8, 2011 103 / 187

 Formal verification of programs Imperative versus functional

Verification of functional and imperative programs

Functional languages begin high on the abstraction level, staying close

to our thinking, and our mathematics; they emphasize expressiveness

Formal Software Development Program Overview March 8, 2011 103 / 187

 Formal verification of programs Imperative versus functional

Verification of functional and imperative programs

Functional languages begin high on the abstraction level, staying close

to our thinking, and our mathematics; they emphasize expressiveness
Imperative languages begin low on the abstraction level, staying close to
the machine; they emphasize efficiency

Formal Software Development Program Overview March 8, 2011 103 / 187

 Formal verification of programs Imperative versus functional

Verification of functional and imperative programs

Functional languages begin high on the abstraction level, staying close

to our thinking, and our mathematics; they emphasize expressiveness
Imperative languages begin low on the abstraction level, staying close to
the machine; they emphasize efficiency
The two paradigms are complementary

Formal Software Development Program Overview March 8, 2011 103 / 187

 Formal verification of programs Imperative versus functional

Verification of functional and imperative programs

Functional languages begin high on the abstraction level, staying close

to our thinking, and our mathematics; they emphasize expressiveness
Imperative languages begin low on the abstraction level, staying close to
the machine; they emphasize efficiency
The two paradigms are complementary
We need to understand how to verify both types of programs

Formal Software Development Program Overview March 8, 2011 103 / 187

 Formal verification of programs Imperative versus functional

Verification of functional and imperative programs

Functional languages begin high on the abstraction level, staying close

to our thinking, and our mathematics; they emphasize expressiveness
Imperative languages begin low on the abstraction level, staying close to
the machine; they emphasize efficiency
The two paradigms are complementary
We need to understand how to verify both types of programs
We begin by looking at functional programs first

Formal Software Development Program Overview March 8, 2011 103 / 187

 Formal verification of programs Imperative versus functional

Simple functional programs are proofs

Formal Software Development Program Overview March 8, 2011 104 / 187

 Formal verification of programs Imperative versus functional

Simple functional programs are proofs

Simple functional models of computation are structurally indistinguishable

from certain deductive systems of logic. This correspondence, known as the
Curry-Howard correspondence, is a pillar of our program.

Formal Software Development Program Overview March 8, 2011 104 / 187

 Formal verification of programs Imperative versus functional

Simple functional programs are proofs

Simple functional models of computation are structurally indistinguishable

from certain deductive systems of logic. This correspondence, known as the
Curry-Howard correspondence, is a pillar of our program.

The correspondence has an equational content, an application of category

theory. We say more about this need for category theory later, for now let’s
note that the correspondence gives us a dictionary from functional
programming practice to theory:

Formal Software Development Program Overview March 8, 2011 104 / 187

 Formal verification of programs Imperative versus functional

Simple functional programs are proofs

Simple functional models of computation are structurally indistinguishable

from certain deductive systems of logic. This correspondence, known as the
Curry-Howard correspondence, is a pillar of our program.

The correspondence has an equational content, an application of category

theory. We say more about this need for category theory later, for now let’s
note that the correspondence gives us a dictionary from functional
programming practice to theory:
Program specifications (types) are theorems (formulas)

Formal Software Development Program Overview March 8, 2011 104 / 187

 Formal verification of programs Imperative versus functional

Simple functional programs are proofs

Simple functional models of computation are structurally indistinguishable

from certain deductive systems of logic. This correspondence, known as the
Curry-Howard correspondence, is a pillar of our program.

The correspondence has an equational content, an application of category

theory. We say more about this need for category theory later, for now let’s
note that the correspondence gives us a dictionary from functional
programming practice to theory:
Program specifications (types) are theorems (formulas)
Programs are proofs

Formal Software Development Program Overview March 8, 2011 104 / 187

 Formal verification of programs Imperative versus functional

Simple functional programs are proofs

Simple functional models of computation are structurally indistinguishable

from certain deductive systems of logic. This correspondence, known as the
Curry-Howard correspondence, is a pillar of our program.

The correspondence has an equational content, an application of category

theory. We say more about this need for category theory later, for now let’s
note that the correspondence gives us a dictionary from functional
programming practice to theory:
Program specifications (types) are theorems (formulas)
Programs are proofs
Functions between types are logical implications between formulas

Formal Software Development Program Overview March 8, 2011 104 / 187

 Formal verification of programs Imperative versus functional

Proving properties of imperative programs

Formal Software Development Program Overview March 8, 2011 105 / 187

 Formal verification of programs Imperative versus functional

Proving properties of imperative programs

For us imperative programming means programming in C/Java/C#.

Formal Software Development Program Overview March 8, 2011 105 / 187

 Formal verification of programs Imperative versus functional

Proving properties of imperative programs

For us imperative programming means programming in C/Java/C#.

We saw that simple functional programs are already proofs (Curry-Howard
correspondence)

Formal Software Development Program Overview March 8, 2011 105 / 187

 Formal verification of programs Imperative versus functional

Proving properties of imperative programs

For us imperative programming means programming in C/Java/C#.

We saw that simple functional programs are already proofs (Curry-Howard
correspondence)
It is much harder to prove properties of imperative programs.

Formal Software Development Program Overview March 8, 2011 105 / 187

 Formal verification of programs Imperative versus functional

Proving properties of imperative programs

For us imperative programming means programming in C/Java/C#.

We saw that simple functional programs are already proofs (Curry-Howard
correspondence)
It is much harder to prove properties of imperative programs.
We study a few approaches to the verification of imperative programs;
all approaches transform the program or parts of it to semantically equiv-
alent functional programs, relative to a fixed logical framework:

Formal Software Development Program Overview March 8, 2011 105 / 187

 Formal verification of programs Imperative versus functional

Proving properties of imperative programs

For us imperative programming means programming in C/Java/C#.

We saw that simple functional programs are already proofs (Curry-Howard
correspondence)
It is much harder to prove properties of imperative programs.
We study a few approaches to the verification of imperative programs;
all approaches transform the program or parts of it to semantically equiv-
alent functional programs, relative to a fixed logical framework:
1 Using the axiomatic semantics of the programming language (prob-
ably the most intuitive approach)

Formal Software Development Program Overview March 8, 2011 105 / 187

 Formal verification of programs Imperative versus functional

Proving properties of imperative programs

For us imperative programming means programming in C/Java/C#.

We saw that simple functional programs are already proofs (Curry-Howard
correspondence)
It is much harder to prove properties of imperative programs.
We study a few approaches to the verification of imperative programs;
all approaches transform the program or parts of it to semantically equiv-
alent functional programs, relative to a fixed logical framework:
1 Using the axiomatic semantics of the programming language (prob-
ably the most intuitive approach)
2 Using other semantics

Formal Software Development Program Overview March 8, 2011 105 / 187

 Formal verification of programs Imperative versus functional

Proving properties of imperative programs

For us imperative programming means programming in C/Java/C#.

We saw that simple functional programs are already proofs (Curry-Howard
correspondence)
It is much harder to prove properties of imperative programs.
We study a few approaches to the verification of imperative programs;
all approaches transform the program or parts of it to semantically equiv-
alent functional programs, relative to a fixed logical framework:
1 Using the axiomatic semantics of the programming language (prob-
ably the most intuitive approach)
2 Using other semantics
3 Using effect types

Formal Software Development Program Overview March 8, 2011 105 / 187

 Formal verification of programs Imperative versus functional

Proving properties of imperative programs

For us imperative programming means programming in C/Java/C#.

We saw that simple functional programs are already proofs (Curry-Howard
correspondence)
It is much harder to prove properties of imperative programs.
We study a few approaches to the verification of imperative programs;
all approaches transform the program or parts of it to semantically equiv-
alent functional programs, relative to a fixed logical framework:
1 Using the axiomatic semantics of the programming language (prob-
ably the most intuitive approach)
2 Using other semantics
3 Using effect types
4 Using monads (another reason for us to study category theory, this
being the more general approach; the other methods can be de-
scribed through monads)

Formal Software Development Program Overview March 8, 2011 105 / 187

 Formal verification of programs Imperative versus functional

Why don’t we just switch to functional languages?

Formal Software Development Program Overview March 8, 2011 106 / 187

 Formal verification of programs Imperative versus functional

Why don’t we just switch to functional languages?

Because the hardware matches imperative languages better

Formal Software Development Program Overview March 8, 2011 106 / 187

 Formal verification of programs Imperative versus functional

Why don’t we just switch to functional languages?

Because the hardware matches imperative languages better

There are yet no Intel or NVIDIA chips based on lambda-calculus; they
would need specialized stacks, very fast and very large

Formal Software Development Program Overview March 8, 2011 106 / 187

 Formal verification of programs Imperative versus functional

Why don’t we just switch to functional languages?

Because the hardware matches imperative languages better

There are yet no Intel or NVIDIA chips based on lambda-calculus; they
would need specialized stacks, very fast and very large
And functional languages do not support concurrency well; the fact that
referential transparency leads to the possibility of concurrency is not
really useful. We still need to support explicit concurrency, in the hands
of the programmer.

Formal Software Development Program Overview March 8, 2011 106 / 187

 Formal verification of programs Imperative versus functional

Why don’t we just switch to functional languages?

Because the hardware matches imperative languages better

There are yet no Intel or NVIDIA chips based on lambda-calculus; they
would need specialized stacks, very fast and very large
And functional languages do not support concurrency well; the fact that
referential transparency leads to the possibility of concurrency is not
really useful. We still need to support explicit concurrency, in the hands
of the programmer.
Gödel himself was not convinced that his theory of recursive functions
or Church’s lambda calculus captured the concept of computability until
Turing proposed his machine; imperative models are usually more con-
vincing.

Formal Software Development Program Overview March 8, 2011 106 / 187

 Formal verification of programs Imperative versus functional

Impact of concurrency

sequential
log
ic
ge
ts
functional ha imperative
rde
r

concurrent

Formal Software Development Program Overview March 8, 2011 107 / 187

 Formal verification of programs Imperative versus functional

Solution: program transformations

sequential
p
(se rogr
ma am
functional nti tr imperative
cal ans
ly fom
eq a
uiv tio
ale n
nt)
concurrent

Formal Software Development Program Overview March 8, 2011 108 / 187

 Formal verification of programs Imperative versus functional

Correctness properties

Formal Software Development Program Overview March 8, 2011 109 / 187

 Formal verification of programs Imperative versus functional

Correctness properties

What properties do we verify?

Formal Software Development Program Overview March 8, 2011 109 / 187

 Formal verification of programs Imperative versus functional

Correctness properties

What properties do we verify? At the high end sits the total correctness of
the program relative to a specification.

Formal Software Development Program Overview March 8, 2011 109 / 187

 Formal verification of programs Imperative versus functional

Correctness properties

What properties do we verify? At the high end sits the total correctness of
the program relative to a specification.

We will study ways to produce programs that are correct-by-construction,

meaning that the code and the proof of total correctness are developed at
the same time. This correctness-by-construction is usually accomplished for
functional programs only.

Formal Software Development Program Overview March 8, 2011 109 / 187

 Formal verification of programs Imperative versus functional

Correctness properties

What properties do we verify? At the high end sits the total correctness of
the program relative to a specification.

We will study ways to produce programs that are correct-by-construction,

meaning that the code and the proof of total correctness are developed at
the same time. This correctness-by-construction is usually accomplished for
functional programs only.

Total correctness is composed of two properties that can be proven

separately:

Formal Software Development Program Overview March 8, 2011 109 / 187

 Formal verification of programs Imperative versus functional

Correctness properties

What properties do we verify? At the high end sits the total correctness of
the program relative to a specification.

We will study ways to produce programs that are correct-by-construction,

meaning that the code and the proof of total correctness are developed at
the same time. This correctness-by-construction is usually accomplished for
functional programs only.

Total correctness is composed of two properties that can be proven

separately:
Partial correctness (if delivered, results are correct)

Formal Software Development Program Overview March 8, 2011 109 / 187

 Formal verification of programs Imperative versus functional

Correctness properties

What properties do we verify? At the high end sits the total correctness of
the program relative to a specification.

We will study ways to produce programs that are correct-by-construction,

meaning that the code and the proof of total correctness are developed at
the same time. This correctness-by-construction is usually accomplished for
functional programs only.

Total correctness is composed of two properties that can be proven

separately:
Partial correctness (if delivered, results are correct)
Termination (results are delivered)

Formal Software Development Program Overview March 8, 2011 109 / 187

 Formal verification of programs Imperative versus functional

Safety and liveness properties

Formal Software Development Program Overview March 8, 2011 110 / 187

 Formal verification of programs Imperative versus functional

Safety and liveness properties

Partial correctness relative to a specification and termination are not the

only important properties. We will see that many other desirable properties
of programs can be formally verified:

Formal Software Development Program Overview March 8, 2011 110 / 187

 Formal verification of programs Imperative versus functional

Safety and liveness properties

Partial correctness relative to a specification and termination are not the

only important properties. We will see that many other desirable properties
of programs can be formally verified:

General safety: no arithmetic overflow, no buffer overflow, no null pointer

dereferencing, no division by zero

Formal Software Development Program Overview March 8, 2011 110 / 187

 Formal verification of programs Imperative versus functional

Safety and liveness properties

Partial correctness relative to a specification and termination are not the

only important properties. We will see that many other desirable properties
of programs can be formally verified:

General safety: no arithmetic overflow, no buffer overflow, no null pointer

dereferencing, no division by zero
Heap safety: no dereferencing of deallocated heap, no memory leaks

Formal Software Development Program Overview March 8, 2011 110 / 187

 Formal verification of programs Imperative versus functional

Safety and liveness properties

Partial correctness relative to a specification and termination are not the

only important properties. We will see that many other desirable properties
of programs can be formally verified:

General safety: no arithmetic overflow, no buffer overflow, no null pointer

dereferencing, no division by zero
Heap safety: no dereferencing of deallocated heap, no memory leaks
Liveness (program does not terminate)

Formal Software Development Program Overview March 8, 2011 110 / 187

 Formal verification of programs Imperative versus functional

Concurrency properties

Formal Software Development Program Overview March 8, 2011 111 / 187

 Formal verification of programs Imperative versus functional

Concurrency properties

Proving concurrency properties of imperative programs is very laborious. We

will attack such properties only after you have accumulated enough
experience with proofs of sequential properties. In order of difficulty, we will
look at proofs of:

Formal Software Development Program Overview March 8, 2011 111 / 187

 Formal verification of programs Imperative versus functional

Concurrency properties

Proving concurrency properties of imperative programs is very laborious. We

will attack such properties only after you have accumulated enough
experience with proofs of sequential properties. In order of difficulty, we will
look at proofs of:
Interference freedom (needed if the program uses shared variables)

Formal Software Development Program Overview March 8, 2011 111 / 187

 Formal verification of programs Imperative versus functional

Concurrency properties

Proving concurrency properties of imperative programs is very laborious. We

will attack such properties only after you have accumulated enough
experience with proofs of sequential properties. In order of difficulty, we will
look at proofs of:
Interference freedom (needed if the program uses shared variables)
Deadlock freedom (needed if the program uses synchronization objects)

Formal Software Development Program Overview March 8, 2011 111 / 187

 Formal verification of programs Imperative versus functional

Concurrency properties

Proving concurrency properties of imperative programs is very laborious. We

will attack such properties only after you have accumulated enough
experience with proofs of sequential properties. In order of difficulty, we will
look at proofs of:
Interference freedom (needed if the program uses shared variables)
Deadlock freedom (needed if the program uses synchronization objects)
Fairness (needed to ensure that all components that are ready for exe-
cution do indeed get a chance to execute)

Formal Software Development Program Overview March 8, 2011 111 / 187

 Formal verification of programs The role of assertions

Debug assertions

Formal Software Development Program Overview March 8, 2011 112 / 187

 Formal verification of programs The role of assertions

Debug assertions

We saw that imperative programs are harder to reason about. Assertions are
one of the more intuitive ways to reason about imperative programs.

Formal Software Development Program Overview March 8, 2011 112 / 187

 Formal verification of programs The role of assertions

Debug assertions

We saw that imperative programs are harder to reason about. Assertions are
one of the more intuitive ways to reason about imperative programs.

Assertions are not exactly new to software engineers

Formal Software Development Program Overview March 8, 2011 112 / 187

 Formal verification of programs The role of assertions

Debug assertions

We saw that imperative programs are harder to reason about. Assertions are
one of the more intuitive ways to reason about imperative programs.

Assertions are not exactly new to software engineers

We use debug assertions to validate our understanding of what the run-
ning state should be at some control point

Formal Software Development Program Overview March 8, 2011 112 / 187

 Formal verification of programs The role of assertions

Debug assertions

We saw that imperative programs are harder to reason about. Assertions are
one of the more intuitive ways to reason about imperative programs.

Assertions are not exactly new to software engineers

We use debug assertions to validate our understanding of what the run-
ning state should be at some control point
We set debugger breakpoints at control points to confirm a certain sce-
nario. These scenarios are in fact implicit assertions, many times includ-
ing logical connectives, assertions which the debugger may or may not
confirm; the scenarios are mostly based on informal API documentation.

Formal Software Development Program Overview March 8, 2011 112 / 187

 Formal verification of programs The role of assertions

Assertions moved to compile time

Formal Software Development Program Overview March 8, 2011 113 / 187

 Formal verification of programs The role of assertions

Assertions moved to compile time

Essentially what we do when formally verifying imperative programs is move

assertions from run time to compile time.

Formal Software Development Program Overview March 8, 2011 113 / 187

 Formal verification of programs The role of assertions

Assertions moved to compile time

Essentially what we do when formally verifying imperative programs is move

assertions from run time to compile time.

Now we must make the assertions explicit and attach them to critical
control points in the code with the understanding that they must be valid
for all the states that may reach that control point.

Formal Software Development Program Overview March 8, 2011 113 / 187

 Formal verification of programs The role of assertions

Assertions moved to compile time

Essentially what we do when formally verifying imperative programs is move

assertions from run time to compile time.

Now we must make the assertions explicit and attach them to critical
control points in the code with the understanding that they must be valid
for all the states that may reach that control point.
Some of these assertions are pre-conditions and post-conditions that we
attach to all the function definitions in our code.

Formal Software Development Program Overview March 8, 2011 113 / 187

 Formal verification of programs The role of assertions

Assertions moved to compile time

Essentially what we do when formally verifying imperative programs is move

assertions from run time to compile time.

Now we must make the assertions explicit and attach them to critical
control points in the code with the understanding that they must be valid
for all the states that may reach that control point.
Some of these assertions are pre-conditions and post-conditions that we
attach to all the function definitions in our code.
The verifying compiler (a smarter compiler, backed by a logical tool)
combines these assertions with the formal semantics of the program-
ming language being used and obtains formulas (i.e. theorems) which
its logical back-end must subsequently prove.

Formal Software Development Program Overview March 8, 2011 113 / 187

 Formal verification of programs The role of assertions

Axiomatic semantics

Formal Software Development Program Overview March 8, 2011 114 / 187

 Formal verification of programs The role of assertions

Axiomatic semantics
One of the most intuitive and most used formal semantics for imperative
programming languages. Your program s is a composition of various
commands written in the language. Then its behavior can be viewed as a
state (or predicate) transformer:

{P} s {Q}
where P is a pre-condition (a predicate on the state of the system) and Q is
the post-condition (another predicate on the state of the system).

Formal Software Development Program Overview March 8, 2011 114 / 187

 Formal verification of programs The role of assertions

Axiomatic semantics
One of the most intuitive and most used formal semantics for imperative
programming languages. Your program s is a composition of various
commands written in the language. Then its behavior can be viewed as a
state (or predicate) transformer:

{P} s {Q}
where P is a pre-condition (a predicate on the state of the system) and Q is
the post-condition (another predicate on the state of the system).
Need to have the semantics of each statement in the language

Formal Software Development Program Overview March 8, 2011 114 / 187

 Formal verification of programs The role of assertions

Axiomatic semantics
One of the most intuitive and most used formal semantics for imperative
programming languages. Your program s is a composition of various
commands written in the language. Then its behavior can be viewed as a
state (or predicate) transformer:

{P} s {Q}
where P is a pre-condition (a predicate on the state of the system) and Q is
the post-condition (another predicate on the state of the system).
Need to have the semantics of each statement in the language
Each such semantics is given by a rule

Formal Software Development Program Overview March 8, 2011 114 / 187

 Formal verification of programs The role of assertions

Axiomatic semantics
One of the most intuitive and most used formal semantics for imperative
programming languages. Your program s is a composition of various
commands written in the language. Then its behavior can be viewed as a
state (or predicate) transformer:

{P} s {Q}
where P is a pre-condition (a predicate on the state of the system) and Q is
the post-condition (another predicate on the state of the system).
Need to have the semantics of each statement in the language
Each such semantics is given by a rule
Then use induction on the structure of the program s to prove that if the
state of the system satisfies P and s is executed, then upon termination of
s, the state of the system satisfies Q. This is partial correctness, because
we still need to separately prove that s does indeed terminate.

Formal Software Development Program Overview March 8, 2011 114 / 187

 Formal verification of programs The role of assertions

Assertions for verification, assertions for development

Formal Software Development Program Overview March 8, 2011 115 / 187

 Formal verification of programs The role of assertions

Assertions for verification, assertions for development

Verification means attaching assertions to existing code

Formal Software Development Program Overview March 8, 2011 115 / 187

 Formal verification of programs The role of assertions

Assertions for verification, assertions for development

Verification means attaching assertions to existing code

But assertions could be attached while writing the code: JML, Spec#

Formal Software Development Program Overview March 8, 2011 115 / 187

 Formal verification of programs The role of assertions

Assertions for verification, assertions for development

Verification means attaching assertions to existing code

But assertions could be attached while writing the code: JML, Spec#
When used this way, assertions are called code contracts; it started with
Eiffel

Formal Software Development Program Overview March 8, 2011 115 / 187

 Formal verification of programs The role of assertions

Assertions for verification, assertions for development

Verification means attaching assertions to existing code

But assertions could be attached while writing the code: JML, Spec#
When used this way, assertions are called code contracts; it started with
Eiffel
Having to attach these assertions to code means that we have to under-
stand the code at the time the code is written, not later in the debugger

Formal Software Development Program Overview March 8, 2011 115 / 187

 Formal verification of programs The role of assertions

Assertions for verification, assertions for development

Verification means attaching assertions to existing code

But assertions could be attached while writing the code: JML, Spec#
When used this way, assertions are called code contracts; it started with
Eiffel
Having to attach these assertions to code means that we have to under-
stand the code at the time the code is written, not later in the debugger
So assertions force the writing of better code

Formal Software Development Program Overview March 8, 2011 115 / 187

 Formal verification of programs The role of assertions

Assertions as a form of literate programming

Formal Software Development Program Overview March 8, 2011 116 / 187

 Formal verification of programs The role of assertions

Assertions as a form of literate programming

You may view assertions as a natural progression of the idea that comments
come first (because code is written for people just as much as it it written
for machines):

Formal Software Development Program Overview March 8, 2011 116 / 187

 Formal verification of programs The role of assertions

Assertions as a form of literate programming

You may view assertions as a natural progression of the idea that comments
come first (because code is written for people just as much as it it written
for machines):

1 Kernighan & Ritchie: write good comments, i.e. comments that explain
the intent of the code

Formal Software Development Program Overview March 8, 2011 116 / 187

 Formal verification of programs The role of assertions

Assertions as a form of literate programming

You may view assertions as a natural progression of the idea that comments
come first (because code is written for people just as much as it it written
for machines):

1 Kernighan & Ritchie: write good comments, i.e. comments that explain
the intent of the code
2 Knuth’s literate programming: reverse the order of importance, com-
ments come first, code is the comment

Formal Software Development Program Overview March 8, 2011 116 / 187

 Formal verification of programs The role of assertions

Assertions as a form of literate programming

You may view assertions as a natural progression of the idea that comments
come first (because code is written for people just as much as it it written
for machines):

1 Kernighan & Ritchie: write good comments, i.e. comments that explain
the intent of the code
2 Knuth’s literate programming: reverse the order of importance, com-
ments come first, code is the comment
3 Assertions are the best comments, they represent the logic behind the
program

Formal Software Development Program Overview March 8, 2011 116 / 187

 Formal verification of programs The role of assertions

What about assertions attached to API functions?

Formal Software Development Program Overview March 8, 2011 117 / 187

 Formal verification of programs The role of assertions

What about assertions attached to API functions?

This is clearly an important issue since it may very well be that your code
calls more operating-system or platform (Java/.NET) API functions than
functions that are defined in your program (and to which you can add as
many assertions as you need). These user-mode APIs have complicated
semantics. So, are such pre-conditions, post-conditions and invariants being
developed for operating-system or platform APIs?

Formal Software Development Program Overview March 8, 2011 117 / 187

 Formal verification of programs The role of assertions

What about assertions attached to API functions?

This is clearly an important issue since it may very well be that your code
calls more operating-system or platform (Java/.NET) API functions than
functions that are defined in your program (and to which you can add as
many assertions as you need). These user-mode APIs have complicated
semantics. So, are such pre-conditions, post-conditions and invariants being
developed for operating-system or platform APIs?

1 Yes (but not enough), we’ll look at some solutions for Linux and Java

Formal Software Development Program Overview March 8, 2011 117 / 187

 Formal verification of programs The role of assertions

What about assertions attached to API functions?

This is clearly an important issue since it may very well be that your code
calls more operating-system or platform (Java/.NET) API functions than
functions that are defined in your program (and to which you can add as
many assertions as you need). These user-mode APIs have complicated
semantics. So, are such pre-conditions, post-conditions and invariants being
developed for operating-system or platform APIs?

1 Yes (but not enough), we’ll look at some solutions for Linux and Java
2 Yes (but not enough), we’ll look at some solutions for Windows and
.NET

Formal Software Development Program Overview March 8, 2011 117 / 187

 Formal verification of programs The role of assertions

User-mode APIs have complicated semantics

Unix/Linux example:

(This example uses traditional System V semaphores, a Posix semaphore would have a similarly complicated semantics.)

NAME int semget(key t key, int nsems, int semflg);

DESCRIPTION This function returns the semaphore set identifier associated with the argument key. A new set of
nsems semaphores is created if key has the value IPC PRIVATE or if no existing semaphore set is
associated to key and IPC CREAT is asserted in semflg (i.e. semflg & IPC CREAT isn’t zero). The
presence in semflg of the fields IPC CREAT and IPC EXCL plays the same role, with respect to the
existence of the semaphore set, as the presence of O CREAT and O EXCL in the mode argument
of the open(2) system call: i.e. the semget function fails if semflg asserts both IPC CREAT and
IPC EXCL and a semaphore set already exists for key. Upon creation, the low-order 9 bits of the
argument semflg define the access permissions (for owner, group and others) for the semaphore set.
These bits have the same format, and the same meaning, as the mode argument in the open(2)
or creat(2) system calls (though the execute permissions are not meaningful for semaphores, and
write permissions mean permission to alter semaphore values).
When creating a new semaphore set, semget initializes the semaphore set’s associated data struc-
ture semid ds as follows:
sem perm.cuid and sem perm.uid are set to the effective user-ID of the calling process. sem perm.cgid
and sem perm.gid are set to the effective group-ID of the calling process. The low-order 9 bits of
sem perm.mode are set to the low-order 9 bits of semflg. sem nsems is set to the value of nsems.
sem otime is set to 0. sem ctime is set to the current time. The argument nsems can be 0 (a
don’t care) when a semaphore set is not being created. Otherwise nsems must be greater than 0
and less than or equal to the maximum number of semaphores per semaphore set (SEMMSL).
If the semaphore set already exists, the access permissions are verified.

Formal Software Development Program Overview March 8, 2011 118 / 187

 Formal verification of programs The role of assertions

User-mode APIs have complicated semantics

RETURN VALUE If successful, the return value will be the semaphore set identifier (a nonnegative integer), otherwise
-1 is returned, with errno indicating the error. ERRORS On failure errno will be set to one of
the following: EACCES A semaphore set exists for key, but the calling process does not have
permission to access the set. EEXIST A semaphore set exists for key and semflg was asserting
both IPC CREAT and IPC EXCL. ENOENT No semaphore set exists for key and semflg wasn’t
asserting IPC CREAT. EINVAL nsems is less than 0 or greater than the limit on the number of
semaphores per semaphore set (SEMMSL), or a semaphore set corresponding to key already exists,
and nsems is larger than the number of semaphores in that set. ENOMEM A semaphore set has
to be created but the system has not enough memory for the new data structure. ENOSPC A
semaphore set has to be created but the system limit for the maximum number of semaphore sets
(SEMMNI), or the system wide maximum number of semaphores (SEMMNS), would be exceeded.

Formal Software Development Program Overview March 8, 2011 119 / 187

 Formal verification of programs The role of assertions

User-mode APIs have complicated semantics

Windows example:

Syntax HANDLE WINAPI CreateSemaphore( in opt LPSECURITY ATTRIBUTES lpSemaphoreAttributes,

in LONG lInitialCount, in LONG lMaximumCount, in opt LPCTSTR lpName );

Parameters lpSemaphoreAttributes [in, optional] A pointer to a SECURITY ATTRIBUTES structure. If this

parameter is NULL, the handle cannot be inherited by child processes.
The lpSecurityDescriptor member of the structure specifies a security descriptor for the new
semaphore. If this parameter is NULL, the semaphore gets a default security descriptor. The
ACLs in the default security descriptor for a semaphore come from the primary or impersonation
token of the creator.
lInitialCount [in] The initial count for the semaphore object. This value must be greater than or
equal to zero and less than or equal to lMaximumCount. The state of a semaphore is signaled
when its count is greater than zero and nonsignaled when it is zero. The count is decreased by
one whenever a wait function releases a thread that was waiting for the semaphore. The count is
increased by a specified amount by calling the ReleaseSemaphore function.
lMaximumCount [in] The maximum count for the semaphore object. This value must be greater
than zero.
lpName [in, optional] The name of the semaphore object. The name is limited to MAX PATH
characters. Name comparison is case sensitive.
If lpName matches the name of an existing named semaphore object, this function requests
the SEMAPHORE ALL ACCESS access right. In this case, the lInitialCount and lMaximum-
Count parameters are ignored because they have already been set by the creating process. If the
lpSemaphoreAttributes parameter is not NULL, it determines whether the handle can be inherited,
but its security-descriptor member is ignored.
If lpName is NULL, the semaphore object is created without a name.
...

Formal Software Development Program Overview March 8, 2011 120 / 187

 Formal verification of programs The role of assertions

User-mode APIs have complicated semantics

Return Value If the function succeeds, the return value is a handle to the semaphore object. If the named
semaphore object existed before the function call, the function returns a handle to the existing
object and GetLastError returns ERROR ALREADY EXISTS.
If the function fails, the return value is NULL. To get extended error information, call GetLastError.
Remarks The handle returned by CreateSemaphore has the SEMAPHORE ALL ACCESS access right; it can
be used in any function that requires a handle to a semaphore object, provided that the caller has
been granted access. If an semaphore is created from a service or a thread that is impersonating
a different user, you can either apply a security descriptor to the semaphore when you create it, or
change the default security descriptor for the creating process by changing its default DACL. For
more information, see Synchronization Object Security and Access Rights.
Any thread of the calling process can specify the semaphore-object handle in a call to one of the
wait functions. The single-object wait functions return when the state of the specified object is
signaled. The multiple-object wait functions can be instructed to return either when any one or
when all of the specified objects are signaled. When a wait function returns, the waiting thread is
released to continue its execution.
The state of a semaphore object is signaled when its count is greater than zero, and nonsignaled
when its count is equal to zero. The lInitialCount parameter specifies the initial count. Each time
a waiting thread is released because of the semaphore’s signaled state, the count of the semaphore
is decreased by one. Use the ReleaseSemaphore function to increment a semaphore’s count by a
specified amount. The count can never be less than zero or greater than the value specified in the
lMaximumCount parameter.
Multiple processes can have handles of the same semaphore object, enabling use of the object for
interprocess synchronization. The following object-sharing mechanisms are available:
A child process created by the CreateProcess function can inherit a handle to a semaphore object
if the lpSemaphoreAttributes parameter of CreateSemaphore enabled inheritance. A process can
specify the semaphore-object handle in a call to the DuplicateHandle function to create a duplicate
handle that can be used by another process.
...

Formal Software Development Program Overview March 8, 2011 121 / 187

 Formal verification of programs The role of assertions

Microkernels and hypervisors

Formal Software Development Program Overview March 8, 2011 122 / 187

 Formal verification of programs The role of assertions

Microkernels and hypervisors

Verification of microkernels and hypervisors is far more doable, the semantics

of their internal APIs is simpler and is available to the team doing the
verification.

Formal Software Development Program Overview March 8, 2011 122 / 187

 Formal verification of programs The role of assertions

Microkernels and hypervisors

Verification of microkernels and hypervisors is far more doable, the semantics

of their internal APIs is simpler and is available to the team doing the
verification.

1 the microkernel seL4 has about 7,500 lines of C code; proof obligations
discharged with Isabelle

Formal Software Development Program Overview March 8, 2011 122 / 187

 Formal verification of programs The role of assertions

Microkernels and hypervisors

Verification of microkernels and hypervisors is far more doable, the semantics

of their internal APIs is simpler and is available to the team doing the
verification.

1 the microkernel seL4 has about 7,500 lines of C code; proof obligations
discharged with Isabelle
2 the hypervisor Hyper-V has 60,000 lines of C; a lot of work using VCC,
proof obligations discharged mostly with Z3

Formal Software Development Program Overview March 8, 2011 122 / 187

 Formal verification of programs The role of assertions

Microkernels and hypervisors

Verification of microkernels and hypervisors is far more doable, the semantics

of their internal APIs is simpler and is available to the team doing the
verification.

1 the microkernel seL4 has about 7,500 lines of C code; proof obligations
discharged with Isabelle
2 the hypervisor Hyper-V has 60,000 lines of C; a lot of work using VCC,
proof obligations discharged mostly with Z3
3 we’ll learn in the program the VCC tool used for the verification of Hyper-
V

Formal Software Development Program Overview March 8, 2011 122 / 187

 Formal verification of programs Static code analysis

Static code analysis

Formal Software Development Program Overview March 8, 2011 123 / 187

 Formal verification of programs Static code analysis

Static code analysis

There are other useful ways to ‘reason’ about programs, besides theorem
proving and model checking

Formal Software Development Program Overview March 8, 2011 123 / 187

 Formal verification of programs Static code analysis

Static code analysis

There are other useful ways to ‘reason’ about programs, besides theorem
proving and model checking
By ‘reason’ we mean a wider form of arguments; practically, a formal
method should present the engineer with evidence that a program or a
property of a program is either correct or is an error:

Formal Software Development Program Overview March 8, 2011 123 / 187

 Formal verification of programs Static code analysis

Static code analysis

There are other useful ways to ‘reason’ about programs, besides theorem
proving and model checking
By ‘reason’ we mean a wider form of arguments; practically, a formal
method should present the engineer with evidence that a program or a
property of a program is either correct or is an error:
Rice’s theorem, applied to programming languages: every interesting
property of programs (in a Turing-complete PL, which most PLs are) is
undecidable (interesting means that there are programs that have the
property and others that don’t have it)

Formal Software Development Program Overview March 8, 2011 123 / 187

 Formal verification of programs Static code analysis

Static code analysis

There are other useful ways to ‘reason’ about programs, besides theorem
proving and model checking
By ‘reason’ we mean a wider form of arguments; practically, a formal
method should present the engineer with evidence that a program or a
property of a program is either correct or is an error:
Rice’s theorem, applied to programming languages: every interesting
property of programs (in a Turing-complete PL, which most PLs are) is
undecidable (interesting means that there are programs that have the
property and others that don’t have it)
So, all we can do is build decidable approximations of solutions to inter-
esting problems

Formal Software Development Program Overview March 8, 2011 123 / 187

 Formal verification of programs Static code analysis

Static code analysis

There are other useful ways to ‘reason’ about programs, besides theorem
proving and model checking
By ‘reason’ we mean a wider form of arguments; practically, a formal
method should present the engineer with evidence that a program or a
property of a program is either correct or is an error:
Rice’s theorem, applied to programming languages: every interesting
property of programs (in a Turing-complete PL, which most PLs are) is
undecidable (interesting means that there are programs that have the
property and others that don’t have it)
So, all we can do is build decidable approximations of solutions to inter-
esting problems
I There are both theoretical and engineering challenges

Formal Software Development Program Overview March 8, 2011 123 / 187

 Formal verification of programs Static code analysis

Static code analysis

There are other useful ways to ‘reason’ about programs, besides theorem
proving and model checking
By ‘reason’ we mean a wider form of arguments; practically, a formal
method should present the engineer with evidence that a program or a
property of a program is either correct or is an error:
Rice’s theorem, applied to programming languages: every interesting
property of programs (in a Turing-complete PL, which most PLs are) is
undecidable (interesting means that there are programs that have the
property and others that don’t have it)
So, all we can do is build decidable approximations of solutions to inter-
esting problems
I There are both theoretical and engineering challenges
I Good approximation algorithms give useful answers often enough

(and false positives rare enough)

Formal Software Development Program Overview March 8, 2011 123 / 187

 Formal verification of programs Static code analysis

Static code analysis

There are other useful ways to ‘reason’ about programs, besides theorem
proving and model checking
By ‘reason’ we mean a wider form of arguments; practically, a formal
method should present the engineer with evidence that a program or a
property of a program is either correct or is an error:
Rice’s theorem, applied to programming languages: every interesting
property of programs (in a Turing-complete PL, which most PLs are) is
undecidable (interesting means that there are programs that have the
property and others that don’t have it)
So, all we can do is build decidable approximations of solutions to inter-
esting problems
I There are both theoretical and engineering challenges
I Good approximation algorithms give useful answers often enough

(and false positives rare enough)

Our program is obviously more focussed on theorem proving and model
checking than static analysis
Formal Software Development Program Overview March 8, 2011 123 / 187
 Formal verification of programs Static code analysis

Static code analysis

Formal Software Development Program Overview March 8, 2011 124 / 187

 Formal verification of programs Static code analysis

Static code analysis

Quite a large and heterogeneous collection of theory and tools: we study

some of them briefly in the two verification courses

Formal Software Development Program Overview March 8, 2011 124 / 187

 Formal verification of programs Static code analysis

Static code analysis

Quite a large and heterogeneous collection of theory and tools: we study

some of them briefly in the two verification courses
Some lightweight static code analysis is already woven into the compiler

Formal Software Development Program Overview March 8, 2011 124 / 187

 Formal verification of programs Static code analysis

Static code analysis

Quite a large and heterogeneous collection of theory and tools: we study

some of them briefly in the two verification courses
Some lightweight static code analysis is already woven into the compiler
Static code analysis is a formal method though, it uses some mathe-
matical techniques (lattice theory, lambda calculus, . . . ) in all forms of
analysis (look these terms up on Wikipedia, we have no space here):

Formal Software Development Program Overview March 8, 2011 124 / 187

 Formal verification of programs Static code analysis

Static code analysis

Quite a large and heterogeneous collection of theory and tools: we study

some of them briefly in the two verification courses
Some lightweight static code analysis is already woven into the compiler
Static code analysis is a formal method though, it uses some mathe-
matical techniques (lattice theory, lambda calculus, . . . ) in all forms of
analysis (look these terms up on Wikipedia, we have no space here):
I Data flow and control flow analysis

Formal Software Development Program Overview March 8, 2011 124 / 187

 Formal verification of programs Static code analysis

Static code analysis

Quite a large and heterogeneous collection of theory and tools: we study

some of them briefly in the two verification courses
Some lightweight static code analysis is already woven into the compiler
Static code analysis is a formal method though, it uses some mathe-
matical techniques (lattice theory, lambda calculus, . . . ) in all forms of
analysis (look these terms up on Wikipedia, we have no space here):
I Data flow and control flow analysis
I Interprocedural analysis

Formal Software Development Program Overview March 8, 2011 124 / 187

 Formal verification of programs Static code analysis

Static code analysis

Quite a large and heterogeneous collection of theory and tools: we study

some of them briefly in the two verification courses
Some lightweight static code analysis is already woven into the compiler
Static code analysis is a formal method though, it uses some mathe-
matical techniques (lattice theory, lambda calculus, . . . ) in all forms of
analysis (look these terms up on Wikipedia, we have no space here):
I Data flow and control flow analysis
I Interprocedural analysis
I Shape and pointer analysis

Formal Software Development Program Overview March 8, 2011 124 / 187

 Formal verification of programs Static code analysis

Static code analysis

Quite a large and heterogeneous collection of theory and tools: we study

some of them briefly in the two verification courses
Some lightweight static code analysis is already woven into the compiler
Static code analysis is a formal method though, it uses some mathe-
matical techniques (lattice theory, lambda calculus, . . . ) in all forms of
analysis (look these terms up on Wikipedia, we have no space here):
I Data flow and control flow analysis
I Interprocedural analysis
I Shape and pointer analysis
I Type analysis

Formal Software Development Program Overview March 8, 2011 124 / 187

 Formal verification of programs Static code analysis

Static code analysis

Quite a large and heterogeneous collection of theory and tools: we study

some of them briefly in the two verification courses
Some lightweight static code analysis is already woven into the compiler
Static code analysis is a formal method though, it uses some mathe-
matical techniques (lattice theory, lambda calculus, . . . ) in all forms of
analysis (look these terms up on Wikipedia, we have no space here):
I Data flow and control flow analysis
I Interprocedural analysis
I Shape and pointer analysis
I Type analysis
I Widening and narrowing

Formal Software Development Program Overview March 8, 2011 124 / 187

 Formal verification of programs Static code analysis

Static code analysis

Quite a large and heterogeneous collection of theory and tools: we study

some of them briefly in the two verification courses
Some lightweight static code analysis is already woven into the compiler
Static code analysis is a formal method though, it uses some mathe-
matical techniques (lattice theory, lambda calculus, . . . ) in all forms of
analysis (look these terms up on Wikipedia, we have no space here):
I Data flow and control flow analysis
I Interprocedural analysis
I Shape and pointer analysis
I Type analysis
I Widening and narrowing
There is a large step when moving from static code analysis to theorem
proving/model checking

Formal Software Development Program Overview March 8, 2011 124 / 187

 Mathematics and Software

1 What is formal software development

2 Implementing formal systems

3 When are proofs used

4 What formal software development is not

5 Formal verification of programs

6 Mathematics and Software

7 Concrete examples of what we do in the program

8 Program goals and course structure

Formal Software Development Program Overview March 8, 2011 125 / 187
 Mathematics and Software How they evolved

The evolution of mathematics

Formal Software Development Program Overview March 8, 2011 126 / 187

 Mathematics and Software How they evolved

The evolution of mathematics

It continuously grows upwards,

drawing on existing body of knowl-
edge

Formal Software Development Program Overview March 8, 2011 126 / 187

 Mathematics and Software How they evolved

The evolution of mathematics

It continuously grows upwards,

drawing on existing body of knowl-
edge

Formal Software Development Program Overview March 8, 2011 126 / 187

 Mathematics and Software How they evolved

The evolution of mathematics

It continuously grows upwards,

drawing on existing body of knowl-
edge

Formal Software Development Program Overview March 8, 2011 126 / 187

 Mathematics and Software How they evolved

The evolution of mathematics

It continuously grows upwards,

drawing on existing body of knowl-
edge
It continuously grows side-ways,
finding more and more fields of ap-
plication

Formal Software Development Program Overview March 8, 2011 126 / 187

 Mathematics and Software How they evolved

The evolution of mathematics

It continuously grows upwards,

drawing on existing body of knowl-
edge
It continuously grows side-ways,
finding more and more fields of ap-
plication

Formal Software Development Program Overview March 8, 2011 126 / 187

 Mathematics and Software How they evolved

The evolution of mathematics

It continuously grows upwards,

drawing on existing body of knowl-
edge
It continuously grows side-ways,
finding more and more fields of ap-
plication

Around 1900: Oops, there are diffi-

culties! We now have to go deeper!

Formal Software Development Program Overview March 8, 2011 126 / 187

 Mathematics and Software How they evolved

The evolution of mathematics

It continuously grows upwards,

drawing on existing body of knowl-
edge
It continuously grows side-ways,
finding more and more fields of ap-
plication

Around 1900: Oops, there are diffi-

culties! We now have to go deeper!

Formal Software Development Program Overview March 8, 2011 126 / 187

 Mathematics and Software How they evolved

The evolution of mathematics

It continuously grows upwards,

drawing on existing body of knowl-
edge
It continuously grows side-ways,
finding more and more fields of ap-
plication

Around 1900: Oops, there are diffi-

culties! We now have to go deeper!

. . . and what do we find?

Formal Software Development Program Overview March 8, 2011 126 / 187

 Mathematics and Software How they evolved

The evolution of mathematics

It continuously grows upwards,

drawing on existing body of knowl-
edge
It continuously grows side-ways,
finding more and more fields of ap-
plication

Around 1900: Oops, there are diffi-

culties! We now have to go deeper!

. . . and what do we find?

Formal Software Development Program Overview March 8, 2011 126 / 187

 Mathematics and Software How they evolved

The evolution of software

Formal Software Development Program Overview March 8, 2011 127 / 187

 Mathematics and Software How they evolved

The evolution of software

It continuously grows upwards,

drawing on existing body of knowl-
edge

Formal Software Development Program Overview March 8, 2011 127 / 187

 Mathematics and Software How they evolved

The evolution of software

It continuously grows upwards,

drawing on existing body of knowl-
edge

Formal Software Development Program Overview March 8, 2011 127 / 187

 Mathematics and Software How they evolved

The evolution of software

It continuously grows upwards,

drawing on existing body of knowl-
edge

Formal Software Development Program Overview March 8, 2011 127 / 187

 Mathematics and Software How they evolved

The evolution of software

It continuously grows upwards,

drawing on existing body of knowl-
edge
It continuously grows side-ways,
finding more and more fields of ap-
plication

Formal Software Development Program Overview March 8, 2011 127 / 187

 Mathematics and Software How they evolved

The evolution of software

It continuously grows upwards,

drawing on existing body of knowl-
edge
It continuously grows side-ways,
finding more and more fields of ap-
plication

Formal Software Development Program Overview March 8, 2011 127 / 187

 Mathematics and Software How they evolved

The evolution of software

It continuously grows upwards,

drawing on existing body of knowl-
edge
It continuously grows side-ways,
finding more and more fields of ap-
plication

Around 1960: Oops, there are diffi-

culties! We now have to go deeper!

Formal Software Development Program Overview March 8, 2011 127 / 187

 Mathematics and Software How they evolved

The evolution of software

It continuously grows upwards,

drawing on existing body of knowl-
edge
It continuously grows side-ways,
finding more and more fields of ap-
plication

Around 1960: Oops, there are diffi-

culties! We now have to go deeper!

Formal Software Development Program Overview March 8, 2011 127 / 187

 Mathematics and Software How they evolved

The evolution of software

It continuously grows upwards,

drawing on existing body of knowl-
edge
It continuously grows side-ways,
finding more and more fields of ap-
plication

Around 1960: Oops, there are diffi-

culties! We now have to go deeper!

. . . and what do we find?

Formal Software Development Program Overview March 8, 2011 127 / 187

 Mathematics and Software How they evolved

The evolution of software

It continuously grows upwards,

drawing on existing body of knowl-
edge
It continuously grows side-ways,
finding more and more fields of ap-
plication

Around 1960: Oops, there are diffi-

culties! We now have to go deeper!

. . . and what do we find?

Formal Software Development Program Overview March 8, 2011 127 / 187

 Mathematics and Software Common roots

Common roots

Formal Software Development Program Overview March 8, 2011 128 / 187

 Mathematics and Software Common roots

Common future

A machine-checked, mathematican- A machine-checked, engineer-friendly, li-

friendly, library of formalized mathematics brary of formalized software here . . .
here . . .

language: rules: language: rules:

... ZFC/HOL/CIC ... ZFC/HOL/CIC
... a math theory ... a prog. lang.

Object Level Object Level

theorem/proof specification/program

tactics tactics

checking checking
Proof OK? Proof OK?
auto strategy auto strategy
Theorem? Theorem?
decision proc decision proc
Theorem? Theorem?
(Y/N) Meta (Y/N) Meta
Level Level

Formal Software Development Program Overview March 8, 2011 129 / 187

 Mathematics and Software Common roots

A quote of a quote

‘ But this self-examination (my note: of mathematics by mathematical means) did have
wonderful and totally unexpected consequences in an area far re-
moved from its original goals. It played a big role in the development
of the most successful technology of our age, the computer, which
after all is just a mathematical machine, a machine for doing mathe-
matics. As E.T. Bell put it, the attempt to soar above mathematics
ended in the bowels of a computer! ’

– Gregory Chaitin, The Unknowable, 1999.

Formal Software Development Program Overview March 8, 2011 130 / 187

 Mathematics and Software Common roots

Mathematicians and software engineers

Since we refer to these professions often, and ignore all others, we need some
clarification. It’s easier to define what a mathematician does: mathematics.
With software the situation is more complicated, as there are: software
engineers, computer systems analysts, developers, programmers, QA
engineers, software managers, database designers, etc . . . All of them do
software, and with formal methods in mind, these distinctions get in the way.

Formal Software Development Program Overview March 8, 2011 131 / 187

 Mathematics and Software Common roots

Mathematicians and software engineers

Since we refer to these professions often, and ignore all others, we need some
clarification. It’s easier to define what a mathematician does: mathematics.
With software the situation is more complicated, as there are: software
engineers, computer systems analysts, developers, programmers, QA
engineers, software managers, database designers, etc . . . All of them do
software, and with formal methods in mind, these distinctions get in the way.

So when we refer to ‘software engineers’ we include all these software

professionals. On the other hand, computer scientists and actuaries are
included in the mathematicians group. There are many common
characteristics between the two professions, some of which are the reasons
why they have been ranked in the top 10 best jobs in the past few years.

Formal Software Development Program Overview March 8, 2011 131 / 187

 Mathematics and Software Common roots

Mathematicians and software engineers

Since we refer to these professions often, and ignore all others, we need some
clarification. It’s easier to define what a mathematician does: mathematics.
With software the situation is more complicated, as there are: software
engineers, computer systems analysts, developers, programmers, QA
engineers, software managers, database designers, etc . . . All of them do
software, and with formal methods in mind, these distinctions get in the way.

So when we refer to ‘software engineers’ we include all these software

professionals. On the other hand, computer scientists and actuaries are
included in the mathematicians group. There are many common
characteristics between the two professions, some of which are the reasons
why they have been ranked in the top 10 best jobs in the past few years.

But the most interesting common factor is their foundation.

Formal Software Development Program Overview March 8, 2011 131 / 187

 Mathematics and Software Common roots

Common roots, but different perspectives

Formal Software Development Program Overview March 8, 2011 132 / 187

 Mathematics and Software Common roots

Common roots, but different perspectives

Valid argument coming from the mathematical side: Why don’t engineers
use the logical tools produced in academia/industrial research centers?

Formal Software Development Program Overview March 8, 2011 132 / 187

 Mathematics and Software Common roots

Common roots, but different perspectives

Valid argument coming from the mathematical side: Why don’t engineers
use the logical tools produced in academia/industrial research centers?

Valid argument coming from the engineering side: Why are the logical tools
so unfriendly, unpolished, and under-performing? Why should we trust a tool
that proves concurrency theorems when the tool itself does not use
concurrency?

Formal Software Development Program Overview March 8, 2011 132 / 187

 Mathematics and Software Common roots

Common roots, but different perspectives

Valid argument coming from the mathematical side: Why don’t engineers
use the logical tools produced in academia/industrial research centers?

Valid argument coming from the engineering side: Why are the logical tools
so unfriendly, unpolished, and under-performing? Why should we trust a tool
that proves concurrency theorems when the tool itself does not use
concurrency?
When mathematicians look at the output of a logical tool, they gasp: It
looks like code!

Formal Software Development Program Overview March 8, 2011 132 / 187

 Mathematics and Software Common roots

Common roots, but different perspectives

Valid argument coming from the mathematical side: Why don’t engineers
use the logical tools produced in academia/industrial research centers?

Valid argument coming from the engineering side: Why are the logical tools
so unfriendly, unpolished, and under-performing? Why should we trust a tool
that proves concurrency theorems when the tool itself does not use
concurrency?
When mathematicians look at the output of a logical tool, they gasp: It
looks like code!
When engineers look at the output of a logical tool, they gasp: It looks
like math!

Formal Software Development Program Overview March 8, 2011 132 / 187

 Mathematics and Software How do we bridge the gap?

How do we bridge the gap?

Formal Software Development Program Overview March 8, 2011 133 / 187

 Mathematics and Software How do we bridge the gap?

How do we bridge the gap?

Let’s look at numbers, estimating roughly

Formal Software Development Program Overview March 8, 2011 133 / 187

 Mathematics and Software How do we bridge the gap?

How do we bridge the gap?

Let’s look at numbers, estimating roughly

Estimated number of software engineers: 30 million worldwide

Formal Software Development Program Overview March 8, 2011 133 / 187

 Mathematics and Software How do we bridge the gap?

How do we bridge the gap?

Let’s look at numbers, estimating roughly

Estimated number of software engineers: 30 million worldwide
Estimated number of mathematicians: 300,000 worldwide.

Formal Software Development Program Overview March 8, 2011 133 / 187

 Mathematics and Software How do we bridge the gap?

How do we bridge the gap?

Let’s look at numbers, estimating roughly

Estimated number of software engineers: 30 million worldwide
Estimated number of mathematicians: 300,000 worldwide.
(only very small percentages on either side are working with formalized
knowledge, but let’s say that the percentages are the same)

Formal Software Development Program Overview March 8, 2011 133 / 187

 Mathematics and Software How do we bridge the gap?

How do we bridge the gap?

Let’s look at numbers, estimating roughly

Estimated number of software engineers: 30 million worldwide
Estimated number of mathematicians: 300,000 worldwide.
(only very small percentages on either side are working with formalized
knowledge, but let’s say that the percentages are the same)
The estimated ratio would be 1:100

Formal Software Development Program Overview March 8, 2011 133 / 187

 Mathematics and Software How do we bridge the gap?

How do we bridge the gap?

Let’s look at numbers, estimating roughly

Estimated number of software engineers: 30 million worldwide
Estimated number of mathematicians: 300,000 worldwide.
(only very small percentages on either side are working with formalized
knowledge, but let’s say that the percentages are the same)
The estimated ratio would be 1:100
If we are to make significant progress, we must make the effort to bridge
this gap from the engineering side

Formal Software Development Program Overview March 8, 2011 133 / 187

 Mathematics and Software How do we bridge the gap?

How do we bridge the gap?

Let’s look at numbers, estimating roughly

Estimated number of software engineers: 30 million worldwide
Estimated number of mathematicians: 300,000 worldwide.
(only very small percentages on either side are working with formalized
knowledge, but let’s say that the percentages are the same)
The estimated ratio would be 1:100
If we are to make significant progress, we must make the effort to bridge
this gap from the engineering side
There just isn’t enough population on the mathematical side

Formal Software Development Program Overview March 8, 2011 133 / 187

 Mathematics and Software How do we bridge the gap?

Formalization is far more important for software

Formal Software Development Program Overview March 8, 2011 134 / 187

 Mathematics and Software How do we bridge the gap?

Formalization is far more important for software

It is unlikely that if we do not formalize mathematics,

Formal Software Development Program Overview March 8, 2011 134 / 187

 Mathematics and Software How do we bridge the gap?

Formalization is far more important for software

It is unlikely that if we do not formalize mathematics,

Airplanes will flip upside down when they cross the equator

Formal Software Development Program Overview March 8, 2011 134 / 187

 Mathematics and Software How do we bridge the gap?

Formalization is far more important for software

It is unlikely that if we do not formalize mathematics,

Airplanes will flip upside down when they cross the equator
Wrong doses of radiation will be administered to cancer patients

Formal Software Development Program Overview March 8, 2011 134 / 187

 Mathematics and Software How do we bridge the gap?

Formalization is far more important for software

It is unlikely that if we do not formalize mathematics,

Airplanes will flip upside down when they cross the equator
Wrong doses of radiation will be administered to cancer patients
Expensive space exploration missions will fail

Formal Software Development Program Overview March 8, 2011 134 / 187

 Mathematics and Software How do we bridge the gap?

Formalization is far more important for software

It is unlikely that if we do not formalize mathematics,

Airplanes will flip upside down when they cross the equator
Wrong doses of radiation will be administered to cancer patients
Expensive space exploration missions will fail
Servers or entire networks will go down under targeted attacks

Formal Software Development Program Overview March 8, 2011 134 / 187

 Mathematics and Software How do we bridge the gap?

Four views on the gap situation

Formal Software Development Program Overview March 8, 2011 135 / 187

 Mathematics and Software How do we bridge the gap?

Four views on the gap situation

There are four views about the state of software engineers’ mathematical
knowledge:

Formal Software Development Program Overview March 8, 2011 135 / 187

 Mathematics and Software How do we bridge the gap?

Four views on the gap situation

There are four views about the state of software engineers’ mathematical
knowledge:
1 Hopeless

Formal Software Development Program Overview March 8, 2011 135 / 187

 Mathematics and Software How do we bridge the gap?

Four views on the gap situation

There are four views about the state of software engineers’ mathematical
knowledge:
1 Hopeless
2 Bad, but it could be fixed

Formal Software Development Program Overview March 8, 2011 135 / 187

 Mathematics and Software How do we bridge the gap?

Four views on the gap situation

There are four views about the state of software engineers’ mathematical
knowledge:
1 Hopeless
2 Bad, but it could be fixed
3 Bad, but it must be fixed

Formal Software Development Program Overview March 8, 2011 135 / 187

 Mathematics and Software How do we bridge the gap?

Four views on the gap situation

There are four views about the state of software engineers’ mathematical
knowledge:
1 Hopeless
2 Bad, but it could be fixed
3 Bad, but it must be fixed
4 Not bad

Formal Software Development Program Overview March 8, 2011 135 / 187

 Mathematics and Software How do we bridge the gap?

Four views on the gap situation

There are four views about the state of software engineers’ mathematical
knowledge:
1 Hopeless
2 Bad, but it could be fixed
3 Bad, but it must be fixed
4 Not bad

Formal Software Development Program Overview March 8, 2011 135 / 187

 Mathematics and Software How do we bridge the gap?

Four views on the gap situation

There are four views about the state of software engineers’ mathematical
knowledge:
1 Hopeless
2 Bad, but it could be fixed
3 Bad, but it must be fixed
4 Not bad
My personal experience agrees with item 4. But regardless of my views, the
point is that we cannot conceivably accept either 1 or 2; even if they were
true, we have to turn things around and move 1 and 2 towards 3 and then
on towards 4. The stakes are too high. This program is a small step.

Formal Software Development Program Overview March 8, 2011 135 / 187

 Mathematics and Software How do we bridge the gap?

What lessons have we learned so far

Formal Software Development Program Overview March 8, 2011 136 / 187

 Mathematics and Software How do we bridge the gap?

What lessons have we learned so far

Engineers like tools

Formal Software Development Program Overview March 8, 2011 136 / 187

 Mathematics and Software How do we bridge the gap?

What lessons have we learned so far

Engineers like tools

Engineers like lab work

Formal Software Development Program Overview March 8, 2011 136 / 187

 Mathematics and Software How do we bridge the gap?

What lessons have we learned so far

Engineers like tools

Engineers like lab work
Engineers do not care for long-winded theory; we’ll have to approach
theory differently

Formal Software Development Program Overview March 8, 2011 136 / 187

 Mathematics and Software How do we bridge the gap?

What lessons have we learned so far

Engineers like tools

Engineers like lab work
Engineers do not care for long-winded theory; we’ll have to approach
theory differently
Engineers do not learn by listening and imitating; they learn by doing

Formal Software Development Program Overview March 8, 2011 136 / 187

 Mathematics and Software How do we bridge the gap?

What lessons have we learned so far

Engineers like tools

Engineers like lab work
Engineers do not care for long-winded theory; we’ll have to approach
theory differently
Engineers do not learn by listening and imitating; they learn by doing
Relevance to the real world and impact on careers is important

Formal Software Development Program Overview March 8, 2011 136 / 187

 Mathematics and Software How do we bridge the gap?

What lessons have we learned so far

Engineers like tools

Engineers like lab work
Engineers do not care for long-winded theory; we’ll have to approach
theory differently
Engineers do not learn by listening and imitating; they learn by doing
Relevance to the real world and impact on careers is important
Big problem: many Computer Science/Computer Engineeering degrees
do not include math requirements for admission and many CS/CE depts
do not make up for this during undergraduate studies. The emphasis has
been traditionally on the continuous and not on the discrete (because
the objective was physics).

Formal Software Development Program Overview March 8, 2011 136 / 187

 Mathematics and Software How do we bridge the gap?

There is a way: learn math via logic and computation

Formal Software Development Program Overview March 8, 2011 137 / 187

 Mathematics and Software How do we bridge the gap?

There is a way: learn math via logic and computation

Maybe math is not properly taught

Formal Software Development Program Overview March 8, 2011 137 / 187

 Mathematics and Software How do we bridge the gap?

There is a way: learn math via logic and computation

Maybe math is not properly taught

Students still have a hard time with proofs, because proofs are given
informally; they look arbitrary no matter how much the ε − δ definition
of limits is being drilled

Formal Software Development Program Overview March 8, 2011 137 / 187

 Mathematics and Software How do we bridge the gap?

There is a way: learn math via logic and computation

Maybe math is not properly taught

Students still have a hard time with proofs, because proofs are given
informally; they look arbitrary no matter how much the ε − δ definition
of limits is being drilled
Situation has a known remedy, but it’s not consistently applied

Formal Software Development Program Overview March 8, 2011 137 / 187

 Mathematics and Software How do we bridge the gap?

There is a way: learn math via logic and computation

Maybe math is not properly taught

Students still have a hard time with proofs, because proofs are given
informally; they look arbitrary no matter how much the ε − δ definition
of limits is being drilled
Situation has a known remedy, but it’s not consistently applied
Define proofs for what they really are, i.e. deductions in a formal system,
and perception changes dramatically

Formal Software Development Program Overview March 8, 2011 137 / 187

 Mathematics and Software How do we bridge the gap?

There is a way: learn math via logic and computation

Maybe math is not properly taught

Students still have a hard time with proofs, because proofs are given
informally; they look arbitrary no matter how much the ε − δ definition
of limits is being drilled
Situation has a known remedy, but it’s not consistently applied
Define proofs for what they really are, i.e. deductions in a formal system,
and perception changes dramatically
Software engineers have strong computational intuitions, so proofs done
as mechanical computations feel more natural

Formal Software Development Program Overview March 8, 2011 137 / 187

 Mathematics and Software How do we bridge the gap?

There is a way: learn math via logic and computation

Maybe math is not properly taught

Students still have a hard time with proofs, because proofs are given
informally; they look arbitrary no matter how much the ε − δ definition
of limits is being drilled
Situation has a known remedy, but it’s not consistently applied
Define proofs for what they really are, i.e. deductions in a formal system,
and perception changes dramatically
Software engineers have strong computational intuitions, so proofs done
as mechanical computations feel more natural
This has already been done with great success in CS courses (nothing
new here): Knuth, Dijkstra, Gries, ...

Formal Software Development Program Overview March 8, 2011 137 / 187

 Mathematics and Software How do we bridge the gap?

There is a way: learn math via logic and computation

Maybe math is not properly taught

Students still have a hard time with proofs, because proofs are given
informally; they look arbitrary no matter how much the ε − δ definition
of limits is being drilled
Situation has a known remedy, but it’s not consistently applied
Define proofs for what they really are, i.e. deductions in a formal system,
and perception changes dramatically
Software engineers have strong computational intuitions, so proofs done
as mechanical computations feel more natural
This has already been done with great success in CS courses (nothing
new here): Knuth, Dijkstra, Gries, ...
Following their lead, the program includes a course in ‘Discrete Mathe-
matics via Equational Logic’

Formal Software Development Program Overview March 8, 2011 137 / 187

 Mathematics and Software How do we bridge the gap?

And use a computer algebra system

Formal Software Development Program Overview March 8, 2011 138 / 187

 Mathematics and Software How do we bridge the gap?

And use a computer algebra system

Secondly, we will combine theorem proving with a computer algebra

system; this must be necessarily a patchy job since no available system
does both well, yet

Formal Software Development Program Overview March 8, 2011 138 / 187

 Mathematics and Software How do we bridge the gap?

And use a computer algebra system

Secondly, we will combine theorem proving with a computer algebra

system; this must be necessarily a patchy job since no available system
does both well, yet
With theorem proving and computer algebra combined, you can see a
dazzling display of cooperation between math and software

Formal Software Development Program Overview March 8, 2011 138 / 187

 Mathematics and Software How do we bridge the gap?

And use a computer algebra system

Secondly, we will combine theorem proving with a computer algebra

system; this must be necessarily a patchy job since no available system
does both well, yet
With theorem proving and computer algebra combined, you can see a
dazzling display of cooperation between math and software
We will do this in the ‘Computer Algebra Systems’ course

Formal Software Development Program Overview March 8, 2011 138 / 187

 Mathematics and Software How do we bridge the gap?

We need them, they need us

Formal Software Development Program Overview March 8, 2011 139 / 187

 Mathematics and Software How do we bridge the gap?

We need them, they need us

As we said before, the dependency between software and mathematics is

not one way

Formal Software Development Program Overview March 8, 2011 139 / 187

 Mathematics and Software How do we bridge the gap?

We need them, they need us

As we said before, the dependency between software and mathematics is

not one way
Projects that attempted the formalization of mathematics moved slowly

Formal Software Development Program Overview March 8, 2011 139 / 187

 Mathematics and Software How do we bridge the gap?

We need them, they need us

As we said before, the dependency between software and mathematics is

not one way
Projects that attempted the formalization of mathematics moved slowly
Clearly engineering experience would have been useful

Formal Software Development Program Overview March 8, 2011 139 / 187

 Mathematics and Software How do we bridge the gap?

We need them, they need us

As we said before, the dependency between software and mathematics is

not one way
Projects that attempted the formalization of mathematics moved slowly
Clearly engineering experience would have been useful
Especially when it came to library design, backward compatibility, . . .

Formal Software Development Program Overview March 8, 2011 139 / 187

 Mathematics and Software How do we bridge the gap?

We need them, they need us

As we said before, the dependency between software and mathematics is

not one way
Projects that attempted the formalization of mathematics moved slowly
Clearly engineering experience would have been useful
Especially when it came to library design, backward compatibility, . . .
Tools are still not friendly towards mathematicians’ view of proofs (re-
member: ‘looks like code!’)

Formal Software Development Program Overview March 8, 2011 139 / 187

 Mathematics and Software How do we bridge the gap?

We need them, they need us

As we said before, the dependency between software and mathematics is

not one way
Projects that attempted the formalization of mathematics moved slowly
Clearly engineering experience would have been useful
Especially when it came to library design, backward compatibility, . . .
Tools are still not friendly towards mathematicians’ view of proofs (re-
member: ‘looks like code!’)
User interfaces could use expertize from people who specialize in usability

Formal Software Development Program Overview March 8, 2011 139 / 187

 Mathematics and Software How do we bridge the gap?

We need them, they need us

As we said before, the dependency between software and mathematics is

not one way
Projects that attempted the formalization of mathematics moved slowly
Clearly engineering experience would have been useful
Especially when it came to library design, backward compatibility, . . .
Tools are still not friendly towards mathematicians’ view of proofs (re-
member: ‘looks like code!’)
User interfaces could use expertize from people who specialize in usability
If the gap is closed, mathematics and software engineering can together
lead to better and more powerful tools, which in turn can support more
powerful theories, either in mathematics or in software development

Formal Software Development Program Overview March 8, 2011 139 / 187

 Mathematics and Software What is the appropriate level of mathematics

In this program, should we dial down the level of

mathematics?

Formal Software Development Program Overview March 8, 2011 140 / 187

 Mathematics and Software What is the appropriate level of mathematics

In this program, should we dial down the level of

mathematics?

Let’s look at an example

Formal Software Development Program Overview March 8, 2011 140 / 187

 Mathematics and Software What is the appropriate level of mathematics

In this program, should we dial down the level of

mathematics?

Let’s look at an example

One of the most most important concepts to emerge in computation has
been the concept of a monad

Formal Software Development Program Overview March 8, 2011 140 / 187

 Mathematics and Software What is the appropriate level of mathematics

In this program, should we dial down the level of

mathematics?

Let’s look at an example

One of the most most important concepts to emerge in computation has
been the concept of a monad
Now a monad is a mathematical object, right at the core of category
theory

Formal Software Development Program Overview March 8, 2011 140 / 187

 Mathematics and Software What is the appropriate level of mathematics

In this program, should we dial down the level of

mathematics?

Let’s look at an example

One of the most most important concepts to emerge in computation has
been the concept of a monad
Now a monad is a mathematical object, right at the core of category
theory
The first practical language that introduced them was Haskell. Many
tutorials explain by different means what a monad is (a container, a
computation, etc...) because the thinking is that monads are too math-
ematical and students won’t get them.

Formal Software Development Program Overview March 8, 2011 140 / 187

 Mathematics and Software What is the appropriate level of mathematics

In this program, should we dial down the level of

mathematics?

Let’s look at an example

One of the most most important concepts to emerge in computation has
been the concept of a monad
Now a monad is a mathematical object, right at the core of category
theory
The first practical language that introduced them was Haskell. Many
tutorials explain by different means what a monad is (a container, a
computation, etc...) because the thinking is that monads are too math-
ematical and students won’t get them.
This is not something to be quickly dismissed. Twisting an abstract
mathematical object into something easier to use in engineering is a
good intention.

Formal Software Development Program Overview March 8, 2011 140 / 187

 Mathematics and Software What is the appropriate level of mathematics

We cannot dial down the level of mathematics

Formal Software Development Program Overview March 8, 2011 141 / 187

 Mathematics and Software What is the appropriate level of mathematics

We cannot dial down the level of mathematics

We cannot do that in this program, we have to learn mathematics as it

is

Formal Software Development Program Overview March 8, 2011 141 / 187

 Mathematics and Software What is the appropriate level of mathematics

We cannot dial down the level of mathematics

We cannot do that in this program, we have to learn mathematics as it

is
Why? First of all, recall the definition of formal software development,
it’s the use of mathematics

Formal Software Development Program Overview March 8, 2011 141 / 187

 Mathematics and Software What is the appropriate level of mathematics

We cannot dial down the level of mathematics

We cannot do that in this program, we have to learn mathematics as it

is
Why? First of all, recall the definition of formal software development,
it’s the use of mathematics
More specifically, concepts like monads are at the core of what we do;
one way of handling imperative programs is to transform them into se-
mantically equivalent functional programs, which logical tools can handle
easier; monads allow this transformation.

Formal Software Development Program Overview March 8, 2011 141 / 187

 Mathematics and Software What is the appropriate level of mathematics

We cannot dial down the level of mathematics

We cannot do that in this program, we have to learn mathematics as it

is
Why? First of all, recall the definition of formal software development,
it’s the use of mathematics
More specifically, concepts like monads are at the core of what we do;
one way of handling imperative programs is to transform them into se-
mantically equivalent functional programs, which logical tools can handle
easier; monads allow this transformation.

Formal Software Development Program Overview March 8, 2011 141 / 187

 Mathematics and Software What is the appropriate level of mathematics

We cannot dial down the level of mathematics

We cannot do that in this program, we have to learn mathematics as it

is
Why? First of all, recall the definition of formal software development,
it’s the use of mathematics
More specifically, concepts like monads are at the core of what we do;
one way of handling imperative programs is to transform them into se-
mantically equivalent functional programs, which logical tools can handle
easier; monads allow this transformation.

We not only cannot avoid categories, we have to embrace them. We do that

in the advanced sequence of the program, but the basic definitions and
examples will be introduced very early. Following is a set of slides that
explain this need to become comfortable with categories. They are intended
for people who have some familiarity with abstract algebra. Others can
safely skip these slides, nothing else in the overview depends on them.

Formal Software Development Program Overview March 8, 2011 141 / 187

 Mathematics and Software Induction explained by category theory

The equational content of formal systems

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 142 / 187

 Mathematics and Software Induction explained by category theory

The equational content of formal systems

ip be
d
sk ay
pe
m

First of all, categories are special formal systems in which only the
equational aspects matter, i.e.

Formal Software Development Program Overview March 8, 2011 142 / 187

 Mathematics and Software Induction explained by category theory

The equational content of formal systems

ip be
d
sk ay
pe
m

First of all, categories are special formal systems in which only the
equational aspects matter, i.e.
the proofs of the same theorem are indistinguishable

Formal Software Development Program Overview March 8, 2011 142 / 187

 Mathematics and Software Induction explained by category theory

The equational content of formal systems

ip be
d
sk ay
pe
m

First of all, categories are special formal systems in which only the
equational aspects matter, i.e.
the proofs of the same theorem are indistinguishable
only the fact that there exists such a proof matters

Formal Software Development Program Overview March 8, 2011 142 / 187

 Mathematics and Software Induction explained by category theory

The equational content of formal systems

ip be
d
sk ay
pe
m

First of all, categories are special formal systems in which only the
equational aspects matter, i.e.
the proofs of the same theorem are indistinguishable
only the fact that there exists such a proof matters

Formal Software Development Program Overview March 8, 2011 142 / 187

 Mathematics and Software Induction explained by category theory

The equational content of formal systems

ip be
d
sk ay
pe
m

First of all, categories are special formal systems in which only the
equational aspects matter, i.e.
the proofs of the same theorem are indistinguishable
only the fact that there exists such a proof matters

Removing the operational aspects of a formal system leaves us with an

algebraic content that can be studied independently and leads to useful
classifications of such systems. Even though these classifications may not
give us deep insights into a particular formal system, they give us a very
effective way to organize our knowledge so we don’t have to keep repeating
the same constructions over and over. You may think of categories as the
ultimate pattern recognition tool.

Formal Software Development Program Overview March 8, 2011 142 / 187

 Mathematics and Software Induction explained by category theory

Higher level of abstraction

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 143 / 187

 Mathematics and Software Induction explained by category theory

Higher level of abstraction

ip be
d
sk ay
pe
m

Categorial arguments raise the abstraction level

Formal Software Development Program Overview March 8, 2011 143 / 187

 Mathematics and Software Induction explained by category theory

Higher level of abstraction

ip be
d
sk ay
pe
m

Categorial arguments raise the abstraction level

So category theory should feel natural to software engineers . . .

Formal Software Development Program Overview March 8, 2011 143 / 187

 Mathematics and Software Induction explained by category theory

Higher level of abstraction

ip be
d
sk ay
pe
m

Categorial arguments raise the abstraction level

So category theory should feel natural to software engineers . . .
. . . because of its high power of abstraction, not despite of it

Formal Software Development Program Overview March 8, 2011 143 / 187

 Mathematics and Software Induction explained by category theory

Higher level of abstraction

ip be
d
sk ay
pe
m

Categorial arguments raise the abstraction level

So category theory should feel natural to software engineers . . .
. . . because of its high power of abstraction, not despite of it
Half-jokingly, the following is referred to as the ‘fundamental theorem
of software engineering’: when things get difficult, raise the abstraction
level (term attributed to Koenig)

Formal Software Development Program Overview March 8, 2011 143 / 187

 Mathematics and Software Induction explained by category theory

More reasons why we need categories

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 144 / 187

 Mathematics and Software Induction explained by category theory

More reasons why we need categories

ip be
d
sk ay
pe

1 We have already mentioned the Curry-Howard-Lambek correspondence

m

Formal Software Development Program Overview March 8, 2011 144 / 187

 Mathematics and Software Induction explained by category theory

More reasons why we need categories

ip be
d
sk ay
pe

1 We have already mentioned the Curry-Howard-Lambek correspondence

m

2 Can this correspondence be extended to reason about imperative pro-

grams? Not directly, but with the use of monads.

Formal Software Development Program Overview March 8, 2011 144 / 187

 Mathematics and Software Induction explained by category theory

More reasons why we need categories

ip be
d
sk ay
pe

1 We have already mentioned the Curry-Howard-Lambek correspondence

m

2 Can this correspondence be extended to reason about imperative pro-

grams? Not directly, but with the use of monads.
I Monads encapsulate imperative features inside functional languages

Formal Software Development Program Overview March 8, 2011 144 / 187

 Mathematics and Software Induction explained by category theory

More reasons why we need categories

ip be
d
sk ay
pe

1 We have already mentioned the Curry-Howard-Lambek correspondence

m

2 Can this correspondence be extended to reason about imperative pro-

grams? Not directly, but with the use of monads.
I Monads encapsulate imperative features inside functional languages
3 We need to understand the syntax/semantics pair from an algebraic view-
point

Formal Software Development Program Overview March 8, 2011 144 / 187

 Mathematics and Software Induction explained by category theory

More reasons why we need categories

ip be
d
sk ay
pe

1 We have already mentioned the Curry-Howard-Lambek correspondence

m

2 Can this correspondence be extended to reason about imperative pro-

grams? Not directly, but with the use of monads.
I Monads encapsulate imperative features inside functional languages
3 We need to understand the syntax/semantics pair from an algebraic view-
point
4 To understand the algebraic semantics of programming languages, we
need to understand initiality, induction and recursion

Formal Software Development Program Overview March 8, 2011 144 / 187

 Mathematics and Software Induction explained by category theory

More reasons why we need categories

ip be
d
sk ay
pe

1 We have already mentioned the Curry-Howard-Lambek correspondence

m

2 Can this correspondence be extended to reason about imperative pro-

grams? Not directly, but with the use of monads.
I Monads encapsulate imperative features inside functional languages
3 We need to understand the syntax/semantics pair from an algebraic view-
point
4 To understand the algebraic semantics of programming languages, we
need to understand initiality, induction and recursion
5 We need to understand the difficulties surrounding the logical quantifiers
and how to handle quantifiers algebraically

Formal Software Development Program Overview March 8, 2011 144 / 187

 Mathematics and Software Induction explained by category theory

More reasons why we need categories

ip be
d
sk ay
pe

1 We have already mentioned the Curry-Howard-Lambek correspondence

m

2 Can this correspondence be extended to reason about imperative pro-

grams? Not directly, but with the use of monads.
I Monads encapsulate imperative features inside functional languages
3 We need to understand the syntax/semantics pair from an algebraic view-
point
4 To understand the algebraic semantics of programming languages, we
need to understand initiality, induction and recursion
5 We need to understand the difficulties surrounding the logical quantifiers
and how to handle quantifiers algebraically

Formal Software Development Program Overview March 8, 2011 144 / 187

 Mathematics and Software Induction explained by category theory

More reasons why we need categories

ip be
d
sk ay
pe

1 We have already mentioned the Curry-Howard-Lambek correspondence

m

2 Can this correspondence be extended to reason about imperative pro-

grams? Not directly, but with the use of monads.
I Monads encapsulate imperative features inside functional languages
3 We need to understand the syntax/semantics pair from an algebraic view-
point
4 To understand the algebraic semantics of programming languages, we
need to understand initiality, induction and recursion
5 We need to understand the difficulties surrounding the logical quantifiers
and how to handle quantifiers algebraically
In this overview we can only pick one of these items and give some
motivation. We pick ‘initiality, induction and recursion’ because we bump
into this in one of the early core courses: ‘Formal Semantics of Programming
Languages’.
Formal Software Development Program Overview March 8, 2011 144 / 187
 Mathematics and Software Induction explained by category theory

Graphs
ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 145 / 187

 Mathematics and Software Induction explained by category theory

Graphs
ip be

Categories are special proof calculi and proof calculi are special
d
sk ay
pe
m

directed graphs. Directed graphs should be more familiar (and proof calculi,
after reading so far) .

Formal Software Development Program Overview March 8, 2011 145 / 187

 Mathematics and Software Induction explained by category theory

Graphs
ip be

Categories are special proof calculi and proof calculi are special
d
sk ay
pe
m

directed graphs. Directed graphs should be more familiar (and proof calculi,
after reading so far) .

graph

A directed graph is a set of vertices A, B, C, . . . and a set of edges f , g, h, . . .,

with two functions from edges to vertices, called source and target. If A is
source(f ) and B is target(f ), we denote the edge as

f :A→B

Formal Software Development Program Overview March 8, 2011 145 / 187

 Mathematics and Software Induction explained by category theory

Graphs
ip be

Categories are special proof calculi and proof calculi are special
d
sk ay
pe
m

directed graphs. Directed graphs should be more familiar (and proof calculi,
after reading so far) .

graph

A directed graph is a set of vertices A, B, C, . . . and a set of edges f , g, h, . . .,

with two functions from edges to vertices, called source and target. If A is
source(f ) and B is target(f ), we denote the edge as

f :A→B

Source is also called domain, and target codomain. An example of a directed

graph:

Formal Software Development Program Overview March 8, 2011 145 / 187

 Mathematics and Software Induction explained by category theory

An example of a directed graph

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 146 / 187

 Mathematics and Software Induction explained by category theory

An example of a directed graph

ip be

h
d
sk ay
pe
m

B
f k

g
A C

n i
D

p l
m

Formal Software Development Program Overview March 8, 2011 146 / 187

 Mathematics and Software Induction explained by category theory

Proof calculi are special graphs

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 147 / 187

 Mathematics and Software Induction explained by category theory

Proof calculi are special graphs

ip be
d
sk ay
pe
m

With proof calculi, the terminology changes, vertices are formulas and
edges are proofs.

proof calculus

A proof calculus is a graph satisfying two conditions

for each formula A there is a special proof 1A : A → A
any two proofs f : A → B and g : B → C can be combined into a proof
g◦f : A → C

Formal Software Development Program Overview March 8, 2011 147 / 187

 Mathematics and Software Induction explained by category theory

Rules of inference
ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 148 / 187

 Mathematics and Software Induction explained by category theory

Rules of inference
ip be
d
sk ay
pe
m

These conditions can be written as rules of inference (this explains why they
are called ‘proof calculi’):

rlIdentity
1A : A → A

f :A→B g:B→C
rlModusPonens
g◦f : A → C

Formal Software Development Program Overview March 8, 2011 148 / 187

 Mathematics and Software Induction explained by category theory

Categories are special proof calculi

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 149 / 187

 Mathematics and Software Induction explained by category theory

Categories are special proof calculi

With categories the terminology changes again, formulas are objects
ip be
d

and proofs are morphisms.

sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 149 / 187

 Mathematics and Software Induction explained by category theory

Categories are special proof calculi

With categories the terminology changes again, formulas are objects
ip be
d

and proofs are morphisms.

sk ay
pe
m

category

A category is a proof calculus where composition of morphisms satisfies two

laws
For all f : A → B, g : B → C, h : C → D

h ◦ (g ◦ f ) = (h ◦ g) ◦ f rlAssociativity

For all f : A → B
f ◦ 1A = 1B ◦ f = f rlUnit

Formal Software Development Program Overview March 8, 2011 149 / 187

 Mathematics and Software Induction explained by category theory

Categories are special proof calculi

With categories the terminology changes again, formulas are objects
ip be
d

and proofs are morphisms.

sk ay
pe
m

category

A category is a proof calculus where composition of morphisms satisfies two

laws
For all f : A → B, g : B → C, h : C → D

h ◦ (g ◦ f ) = (h ◦ g) ◦ f rlAssociativity

For all f : A → B
f ◦ 1A = 1B ◦ f = f rlUnit

With categories the perspective also changes, and the emphasis is now on
the equations introduced by the associativity and the unit rules. The only
example of a category that we need here: Sets, with sets as objects and
functions as morphisms (verify that all the rules apply).
Formal Software Development Program Overview March 8, 2011 149 / 187
 Mathematics and Software Induction explained by category theory

Commutative diagrams
ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 150 / 187

 Mathematics and Software Induction explained by category theory

Commutative diagrams
ip be
d
sk ay
pe
m

In categories, equations are represented pictorially as commutative

diagrams. A diagram is commutative if for any two objects in the diagram,
all paths leading from one object to the other are equal. For example, the
associativity and unit equations are represented by the commutativity of the
following two diagrams:

Formal Software Development Program Overview March 8, 2011 150 / 187

 Mathematics and Software Induction explained by category theory

Commutative diagrams
ip be
d
sk ay
pe
m

In categories, equations are represented pictorially as commutative

diagrams. A diagram is commutative if for any two objects in the diagram,
all paths leading from one object to the other are equal. For example, the
associativity and unit equations are represented by the commutativity of the
following two diagrams:

f 1A
A B A A

g f
g◦f h◦g f f

h 1B
C D B B
rlAssociativity rlUnit

Formal Software Development Program Overview March 8, 2011 150 / 187

 Mathematics and Software Induction explained by category theory

Functors
ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 151 / 187

 Mathematics and Software Induction explained by category theory

Functors
ip be
d

Since the perspective now is algebraic, we need to define what sort of

sk ay
pe
m

maps between categories work well with their algebraic structure.

Formal Software Development Program Overview March 8, 2011 151 / 187

 Mathematics and Software Induction explained by category theory

Functors
ip be
d

Since the perspective now is algebraic, we need to define what sort of

sk ay
pe
m

maps between categories work well with their algebraic structure.

functor
A functor F between categories C and D is a map F : C → C taking objects of
C to objects of D and morphisms f : A → B of C to morphisms Ff : FA → FB
of D, such that

F(g ◦ f ) = Fg ◦ Ff

F(1A ) = 1FA

A functor from a category to itself is called an endofunctor.

Formal Software Development Program Overview March 8, 2011 151 / 187

 Mathematics and Software Induction explained by category theory

Polynomial endofunctors
ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 152 / 187

 Mathematics and Software Induction explained by category theory

Polynomial endofunctors
ip be
d
sk ay
pe
m

For two sets A and B, their product A × B is defined as the set of

pairs (x, y) with x ∈ X and y ∈ Y. Their sum A + B is defined as the disjoint
union {(x, 1)|x ∈ A} ∪ {(y, 2)|y ∈ B}.

Formal Software Development Program Overview March 8, 2011 152 / 187

 Mathematics and Software Induction explained by category theory

Polynomial endofunctors
ip be
d
sk ay
pe
m

For two sets A and B, their product A × B is defined as the set of

pairs (x, y) with x ∈ X and y ∈ Y. Their sum A + B is defined as the disjoint
union {(x, 1)|x ∈ A} ∪ {(y, 2)|y ∈ B}.

The × and + operations can be defined more generally for objects A and B
of any category through certain ‘universal properties’ which do not concern
us here, except that these universal properties give us two functors:
X → A × X and X → A + X for some fixed A; the values on morphisms is
given correspondingly. This allows us to build polynomial endofunctors on
the category Sets:

Formal Software Development Program Overview March 8, 2011 152 / 187

 Mathematics and Software Induction explained by category theory

Polynomial endofunctors
ip be
d
sk ay
pe
m

For two sets A and B, their product A × B is defined as the set of

pairs (x, y) with x ∈ X and y ∈ Y. Their sum A + B is defined as the disjoint
union {(x, 1)|x ∈ A} ∪ {(y, 2)|y ∈ B}.

The × and + operations can be defined more generally for objects A and B
of any category through certain ‘universal properties’ which do not concern
us here, except that these universal properties give us two functors:
X → A × X and X → A + X for some fixed A; the values on morphisms is
given correspondingly. This allows us to build polynomial endofunctors on
the category Sets:

F(X) = C0 + C1 × X + C2 × X 2 + . . . , where Cn are fixed sets

Formal Software Development Program Overview March 8, 2011 152 / 187

 Mathematics and Software Induction explained by category theory

Algebraic structures as polynomial endofunctors

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 153 / 187

 Mathematics and Software Induction explained by category theory

Algebraic structures as polynomial endofunctors

ip be
d
sk ay
pe
m

Let’s look at monoids, sets with a binary associative multiplication

and an identity element. We focus on the signature of the monoid structure,
ignoring the monoid axioms. The signature consists of one constant, the
unit, and one binary function, the multiplication, which, if X is a set with a
monoid structure, can be written as

Formal Software Development Program Overview March 8, 2011 153 / 187

 Mathematics and Software Induction explained by category theory

Algebraic structures as polynomial endofunctors

ip be
d
sk ay
pe
m

Let’s look at monoids, sets with a binary associative multiplication

and an identity element. We focus on the signature of the monoid structure,
ignoring the monoid axioms. The signature consists of one constant, the
unit, and one binary function, the multiplication, which, if X is a set with a
monoid structure, can be written as

u
1 X
m
X ×X X

Formal Software Development Program Overview March 8, 2011 153 / 187

 Mathematics and Software Induction explained by category theory

Algebraic structures as polynomial endofunctors

ip be
d
sk ay
pe
m

Let’s look at monoids, sets with a binary associative multiplication

and an identity element. We focus on the signature of the monoid structure,
ignoring the monoid axioms. The signature consists of one constant, the
unit, and one binary function, the multiplication, which, if X is a set with a
monoid structure, can be written as

u
1 X
m
X ×X X

In the category Sets, the object 1 stands for a one-element set, {∗}. (By the
way, monoids are themselves categories, and the collection of all monoids is also a
category, a sign of how broad the concept of category is)

Formal Software Development Program Overview March 8, 2011 153 / 187

 Mathematics and Software Induction explained by category theory

Algebraic structures as polynomial endofunctors

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 154 / 187

 Mathematics and Software Induction explained by category theory

Algebraic structures as polynomial endofunctors

ip be
d
sk ay
pe
m

Instead of looking at these functions individually, we collect them all

together into one morphism 1 + X 2 → X in the category Sets and therefore
obtain that the monoid structure is captured by the polynomial functor:

Fmonoid (X) = 1 + X 2

Formal Software Development Program Overview March 8, 2011 154 / 187

 Mathematics and Software Induction explained by category theory

Algebraic structures as polynomial endofunctors

ip be
d
sk ay
pe
m

Instead of looking at these functions individually, we collect them all

together into one morphism 1 + X 2 → X in the category Sets and therefore
obtain that the monoid structure is captured by the polynomial functor:

Fmonoid (X) = 1 + X 2

Similarly, the following structures are given by their corresponding functors:

Formal Software Development Program Overview March 8, 2011 154 / 187

 Mathematics and Software Induction explained by category theory

Algebraic structures as polynomial endofunctors

ip be
d
sk ay
pe
m

Instead of looking at these functions individually, we collect them all

together into one morphism 1 + X 2 → X in the category Sets and therefore
obtain that the monoid structure is captured by the polynomial functor:

Fmonoid (X) = 1 + X 2

Similarly, the following structures are given by their corresponding functors:

algebraic structure polynomial endofunctor

semigroup Fsemigroup (X) = X 2
monoid Fmonoid (X) = 1 + X 2
group Fgroup (X) = 1 + X + X 2
ring Fring (X) = 2 + X + 2 × X 2

Formal Software Development Program Overview March 8, 2011 154 / 187

 Mathematics and Software Induction explained by category theory

F-algebras
ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 155 / 187

 Mathematics and Software Induction explained by category theory

F-algebras
ip be
d
sk ay

F-algebra
pe
m

If F is an endofunctor on a category C, an F-algebra is a pair (A, α) where A

is an object of C and α is a morphism

α : FA → A

Formal Software Development Program Overview March 8, 2011 155 / 187

 Mathematics and Software Induction explained by category theory

F-algebras
ip be
d
sk ay

F-algebra
pe
m

If F is an endofunctor on a category C, an F-algebra is a pair (A, α) where A

is an object of C and α is a morphism

α : FA → A

A morphism h : (A, α) → (B, β ) of F-algebras is a morphism h : A → B in C

making the following diagram commute

Formal Software Development Program Overview March 8, 2011 155 / 187

 Mathematics and Software Induction explained by category theory

F-algebras
ip be
d
sk ay

F-algebra
pe
m

If F is an endofunctor on a category C, an F-algebra is a pair (A, α) where A

is an object of C and α is a morphism

α : FA → A

A morphism h : (A, α) → (B, β ) of F-algebras is a morphism h : A → B in C

making the following diagram commute

Fh
FA FB
α β
h
A B

Formal Software Development Program Overview March 8, 2011 155 / 187

 Mathematics and Software Induction explained by category theory

F-algebras
ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 156 / 187

 Mathematics and Software Induction explained by category theory

F-algebras
ip be
d
sk ay
pe
m

It is easy to see that F-algebras form a category of their own. Once

you defined an F-algebra this way (and we now know the motivation for
defining it this way), it is very natural to see what the morphisms should be;
remember that everything in category theory is defined by commutative
diagrams, just put two F-algebras side by side and the commutative diagram
will suggest itself quite naturally:

Formal Software Development Program Overview March 8, 2011 156 / 187

 Mathematics and Software Induction explained by category theory

F-algebras
ip be
d
sk ay
pe
m

It is easy to see that F-algebras form a category of their own. Once

you defined an F-algebra this way (and we now know the motivation for
defining it this way), it is very natural to see what the morphisms should be;
remember that everything in category theory is defined by commutative
diagrams, just put two F-algebras side by side and the commutative diagram
will suggest itself quite naturally:

FA FB
α β

A B

Formal Software Development Program Overview March 8, 2011 156 / 187

 Mathematics and Software Induction explained by category theory

F-algebras
ip be
d
sk ay
pe
m

It is easy to see that F-algebras form a category of their own. Once

you defined an F-algebra this way (and we now know the motivation for
defining it this way), it is very natural to see what the morphisms should be;
remember that everything in category theory is defined by commutative
diagrams, just put two F-algebras side by side and the commutative diagram
will suggest itself quite naturally:

FA FB
α β
h
A B

Formal Software Development Program Overview March 8, 2011 156 / 187

 Mathematics and Software Induction explained by category theory

F-algebras
ip be
d
sk ay
pe
m

It is easy to see that F-algebras form a category of their own. Once

you defined an F-algebra this way (and we now know the motivation for
defining it this way), it is very natural to see what the morphisms should be;
remember that everything in category theory is defined by commutative
diagrams, just put two F-algebras side by side and the commutative diagram
will suggest itself quite naturally:
Fh
FA FB
α β
h
A B

Formal Software Development Program Overview March 8, 2011 156 / 187

 Mathematics and Software Induction explained by category theory

Initial and final objects in a category

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 157 / 187

 Mathematics and Software Induction explained by category theory

Initial and final objects in a category

ip be
d
sk ay
pe
m

initial and final objects

An object I of a category C is called initial if for any object A of C there

exists a unique morphism I → A. An object T is final if for any object A of C
there exists a unique morphism A → T.

Formal Software Development Program Overview March 8, 2011 157 / 187

 Mathematics and Software Induction explained by category theory

Initial and final objects in a category

ip be
d
sk ay
pe
m

initial and final objects

An object I of a category C is called initial if for any object A of C there

exists a unique morphism I → A. An object T is final if for any object A of C
there exists a unique morphism A → T.

A category may have neither an initial object nor a final one

Formal Software Development Program Overview March 8, 2011 157 / 187

 Mathematics and Software Induction explained by category theory

Initial and final objects in a category

ip be
d
sk ay
pe
m

initial and final objects

An object I of a category C is called initial if for any object A of C there

exists a unique morphism I → A. An object T is final if for any object A of C
there exists a unique morphism A → T.

A category may have neither an initial object nor a final one

Any two initial objects, when they exist, are isomorphic and any two final
objects are isomorphic (easy to check)

Formal Software Development Program Overview March 8, 2011 157 / 187

 Mathematics and Software Induction explained by category theory

Initial and final objects in a category

ip be
d
sk ay
pe
m

initial and final objects

An object I of a category C is called initial if for any object A of C there

exists a unique morphism I → A. An object T is final if for any object A of C
there exists a unique morphism A → T.

A category may have neither an initial object nor a final one

Any two initial objects, when they exist, are isomorphic and any two final
objects are isomorphic (easy to check)
Examples: In Sets, the empty set is an initial object and any set con-
sisting of just one element is a final object

Formal Software Development Program Overview March 8, 2011 157 / 187

 Mathematics and Software Induction explained by category theory

Initial and final objects in a category

ip be
d
sk ay
pe
m

initial and final objects

An object I of a category C is called initial if for any object A of C there

exists a unique morphism I → A. An object T is final if for any object A of C
there exists a unique morphism A → T.

A category may have neither an initial object nor a final one

Any two initial objects, when they exist, are isomorphic and any two final
objects are isomorphic (easy to check)
Examples: In Sets, the empty set is an initial object and any set con-
sisting of just one element is a final object
Most important data types have semantics as initial or final objects
in the appropriate category

Formal Software Development Program Overview March 8, 2011 157 / 187

 Mathematics and Software Induction explained by category theory

Why are initial algebras important?

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 158 / 187

 Mathematics and Software Induction explained by category theory

Why are initial algebras important?

ip be
d
sk ay
pe
m

Recursive definitions of functions and inductive proofs of their

properties are two of the most important concepts in the formalization of
software.

What is the relationship between the two? What do they really mean?
Initiality, a categorial concept, gives us the answer. This is a typical example
of why we lean on categories: our program is large and we would not have
the time to motivate recursion and induction many times over. We do it
once, at the most abstract, conceptual level.

Specifically, the fact that a data type admits an initial algebra semantics
means exactly that we can define functions on it recursively and we can
prove things about these functions inductively. Let’s look at the simplest
case, the data type of natural numbers.

Formal Software Development Program Overview March 8, 2011 158 / 187

 Mathematics and Software Induction explained by category theory

Example: natural numbers as a data type

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 159 / 187

 Mathematics and Software Induction explained by category theory

Example: natural numbers as a data type

ip be
d
sk ay
pe
m

The data type of natural numbers, Nat, is defined as follows (we use
Haskell syntax, but any other functional language would do):

data Nat = Zero | S Nat

Formal Software Development Program Overview March 8, 2011 159 / 187

 Mathematics and Software Induction explained by category theory

Example: natural numbers as a data type

ip be
d
sk ay
pe
m

The data type of natural numbers, Nat, is defined as follows (we use
Haskell syntax, but any other functional language would do):

data Nat = Zero | S Nat

The type has a signature consisting of the constant Zero and the unary
operation S. This structure is embodied by the endofunctor Fnat (X) = 1 + X.

Formal Software Development Program Overview March 8, 2011 159 / 187

 Mathematics and Software Induction explained by category theory

Example: natural numbers as a data type

ip be
d
sk ay
pe
m

The data type of natural numbers, Nat, is defined as follows (we use
Haskell syntax, but any other functional language would do):

data Nat = Zero | S Nat

The type has a signature consisting of the constant Zero and the unary
operation S. This structure is embodied by the endofunctor Fnat (X) = 1 + X.
Let’s look at the set of natural numbers N, with the constant 0 ∈ N and
function s : N → N given by s(n) = n + 1, in other words we look at the
Fnat -algebra (N, (0, s)).

Formal Software Development Program Overview March 8, 2011 159 / 187

 Mathematics and Software Induction explained by category theory

Example: natural numbers as a data type

ip be
d
sk ay
pe
m

The data type of natural numbers, Nat, is defined as follows (we use
Haskell syntax, but any other functional language would do):

data Nat = Zero | S Nat

The type has a signature consisting of the constant Zero and the unary
operation S. This structure is embodied by the endofunctor Fnat (X) = 1 + X.
Let’s look at the set of natural numbers N, with the constant 0 ∈ N and
function s : N → N given by s(n) = n + 1, in other words we look at the
Fnat -algebra (N, (0, s)).

Say f : X → X is a function on an arbitrary set X. Fix an a ∈ X which is the

same thing as fixing a unary function u : 1 → X where u(∗) = a. In other
words, we have a pair (X, (u, f ) : 1 + X → X), i.e. another Fnat -algebra.

Formal Software Development Program Overview March 8, 2011 159 / 187

 Mathematics and Software Induction explained by category theory

Example: natural numbers as a data type

ip be
d
sk ay
pe
m

The data type of natural numbers, Nat, is defined as follows (we use
Haskell syntax, but any other functional language would do):

data Nat = Zero | S Nat

The type has a signature consisting of the constant Zero and the unary
operation S. This structure is embodied by the endofunctor Fnat (X) = 1 + X.
Let’s look at the set of natural numbers N, with the constant 0 ∈ N and
function s : N → N given by s(n) = n + 1, in other words we look at the
Fnat -algebra (N, (0, s)).

Say f : X → X is a function on an arbitrary set X. Fix an a ∈ X which is the

same thing as fixing a unary function u : 1 → X where u(∗) = a. In other
words, we have a pair (X, (u, f ) : 1 + X → X), i.e. another Fnat -algebra. Let’s
see what it means that (N, (0, s)) is an initial Fnat -algebra.

Formal Software Development Program Overview March 8, 2011 159 / 187

 Mathematics and Software Induction explained by category theory

Example: the initial algebra for natural numbers

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 160 / 187

 Mathematics and Software Induction explained by category theory

Example: the initial algebra for natural numbers

ip be
d
sk ay
pe
m

To say that (N, (0, s)) is the initial object in the category of
Fnat -algebras means, according to the definitions of F-algebras and initiality,
that there exists a unique h : N → X that makes the following diagram
commute:
Fnat (h)
1+N 1+X

(0, s) (u, f )

h
N X

Formal Software Development Program Overview March 8, 2011 160 / 187

 Mathematics and Software Induction explained by category theory

Example: natural numbers

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 161 / 187

 Mathematics and Software Induction explained by category theory

Example: natural numbers

ip be
d
sk ay
pe
m

By looking at the previous diagram, we see that initiality of (N, (0, s))
means two things:

Formal Software Development Program Overview March 8, 2011 161 / 187

 Mathematics and Software Induction explained by category theory

Example: natural numbers

ip be
d
sk ay
pe
m

By looking at the previous diagram, we see that initiality of (N, (0, s))
means two things:
(Existence) There exists a function h : N → X such that h(0) = a and
h(S(n)) = f (h(n))

Formal Software Development Program Overview March 8, 2011 161 / 187

 Mathematics and Software Induction explained by category theory

Example: natural numbers

ip be
d
sk ay
pe
m

By looking at the previous diagram, we see that initiality of (N, (0, s))
means two things:
(Existence) There exists a function h : N → X such that h(0) = a and
h(S(n)) = f (h(n))
(Uniqueness) If a function g : N → X is such that g(0) = a and g(S(n)) =
f (g(n)), then this function must be h

Formal Software Development Program Overview March 8, 2011 161 / 187

 Mathematics and Software Induction explained by category theory

Example: natural numbers

ip be
d
sk ay
pe
m

By looking at the previous diagram, we see that initiality of (N, (0, s))
means two things:
(Existence) There exists a function h : N → X such that h(0) = a and
h(S(n)) = f (h(n))
(Uniqueness) If a function g : N → X is such that g(0) = a and g(S(n)) =
f (g(n)), then this function must be h

Formal Software Development Program Overview March 8, 2011 161 / 187

 Mathematics and Software Induction explained by category theory

Example: natural numbers

ip be
d
sk ay
pe
m

By looking at the previous diagram, we see that initiality of (N, (0, s))
means two things:
(Existence) There exists a function h : N → X such that h(0) = a and
h(S(n)) = f (h(n))
(Uniqueness) If a function g : N → X is such that g(0) = a and g(S(n)) =
f (g(n)), then this function must be h
So, the existence part of initiality expresses definition by recursion while the
uniqueness part of initiality expresses proof by induction.

Formal Software Development Program Overview March 8, 2011 161 / 187

 Mathematics and Software Induction explained by category theory

Example: natural numbers

ip be
d
sk ay
pe
m

By looking at the previous diagram, we see that initiality of (N, (0, s))
means two things:
(Existence) There exists a function h : N → X such that h(0) = a and
h(S(n)) = f (h(n))
(Uniqueness) If a function g : N → X is such that g(0) = a and g(S(n)) =
f (g(n)), then this function must be h
So, the existence part of initiality expresses definition by recursion while the
uniqueness part of initiality expresses proof by induction. There is no better
way to understand induction and recursion than through initiality.

Formal Software Development Program Overview March 8, 2011 161 / 187

 Mathematics and Software Induction explained by category theory

Example: natural numbers

ip be
d
sk ay
pe
m

By looking at the previous diagram, we see that initiality of (N, (0, s))
means two things:
(Existence) There exists a function h : N → X such that h(0) = a and
h(S(n)) = f (h(n))
(Uniqueness) If a function g : N → X is such that g(0) = a and g(S(n)) =
f (g(n)), then this function must be h
So, the existence part of initiality expresses definition by recursion while the
uniqueness part of initiality expresses proof by induction. There is no better
way to understand induction and recursion than through initiality.

Having said that, note that the terms induction and recursion are often
interchanged: data can be called inductive or recursive, functions can be
called inductive or recursive, etc...

Formal Software Development Program Overview March 8, 2011 161 / 187

 Mathematics and Software Algebraic data types

Algebraic data types have initial algebra semantics

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 162 / 187

 Mathematics and Software Algebraic data types

Algebraic data types have initial algebra semantics

ip be
d
sk ay
pe
m

The type List A with signature consisting of constant [], and unary cons,
has initial algebra semantics, with F(X) = 1 + A × X.

Formal Software Development Program Overview March 8, 2011 162 / 187

 Mathematics and Software Algebraic data types

Algebraic data types have initial algebra semantics

ip be
d
sk ay
pe
m

The type List A with signature consisting of constant [], and unary cons,
has initial algebra semantics, with F(X) = 1 + A × X.
I We have a very pleasant explanation of why lists are so important
in software, their functor is the linear function!

Formal Software Development Program Overview March 8, 2011 162 / 187

 Mathematics and Software Algebraic data types

Algebraic data types have initial algebra semantics

ip be
d
sk ay
pe
m

The type List A with signature consisting of constant [], and unary cons,
has initial algebra semantics, with F(X) = 1 + A × X.
I We have a very pleasant explanation of why lists are so important
in software, their functor is the linear function!
I If we take A to be 1, we recover the fact that the natural numbers
are lists over the set with one element: 0=[]; 1=[*]; 2=[**] . . .

Formal Software Development Program Overview March 8, 2011 162 / 187

 Mathematics and Software Algebraic data types

Algebraic data types have initial algebra semantics

ip be
d
sk ay
pe
m

The type List A with signature consisting of constant [], and unary cons,
has initial algebra semantics, with F(X) = 1 + A × X.
I We have a very pleasant explanation of why lists are so important
in software, their functor is the linear function!
I If we take A to be 1, we recover the fact that the natural numbers
are lists over the set with one element: 0=[]; 1=[*]; 2=[**] . . .
The type Tree (unlabeled binary tree) with signature consisting of con-
stant Leaf, and binary Branch, has initial algebra semantics, with F(X) =
1 + X2.

Formal Software Development Program Overview March 8, 2011 162 / 187

 Mathematics and Software Algebraic data types

Algebraic data types have initial algebra semantics

ip be
d
sk ay
pe
m

The type List A with signature consisting of constant [], and unary cons,
has initial algebra semantics, with F(X) = 1 + A × X.
I We have a very pleasant explanation of why lists are so important
in software, their functor is the linear function!
I If we take A to be 1, we recover the fact that the natural numbers
are lists over the set with one element: 0=[]; 1=[*]; 2=[**] . . .
The type Tree (unlabeled binary tree) with signature consisting of con-
stant Leaf, and binary Branch, has initial algebra semantics, with F(X) =
1 + X2.
The type Tree A (labeled binary tree with leaves of type A) with signature
consisting of constant Leaf A, and binary Branch, has initial algebra
semantics, with F(X) = A + A × X 2 .

Formal Software Development Program Overview March 8, 2011 162 / 187

 Mathematics and Software Algebraic data types

Algebraic data types have initial algebra semantics

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 163 / 187

 Mathematics and Software Algebraic data types

Algebraic data types have initial algebra semantics

ip be
d
sk ay
pe

Let’s note the difference between a data type and its semantics, i.e.
m

the type of natural numbers, Nat, and its model (N, 0, s). One belongs to a
programming language, the other is a mathematical object. Part of our work
on formalizing software is to make these distinctions clear.

Formal Software Development Program Overview March 8, 2011 163 / 187

 Mathematics and Software Algebraic data types

Algebraic data types have initial algebra semantics

ip be
d
sk ay
pe

Let’s note the difference between a data type and its semantics, i.e.
m

the type of natural numbers, Nat, and its model (N, 0, s). One belongs to a
programming language, the other is a mathematical object. Part of our work
on formalizing software is to make these distinctions clear.

We can regard Nat as a theory in the logic of the compiler/interpreter. Let’s

do this in Maude, since its semantics are formal (do not worry about ‘sort’
for now):

Formal Software Development Program Overview March 8, 2011 163 / 187

 Mathematics and Software Algebraic data types

Algebraic data types have initial algebra semantics

ip be
d
sk ay
pe

Let’s note the difference between a data type and its semantics, i.e.
m

the type of natural numbers, Nat, and its model (N, 0, s). One belongs to a
programming language, the other is a mathematical object. Part of our work
on formalizing software is to make these distinctions clear.

We can regard Nat as a theory in the logic of the compiler/interpreter. Let’s

do this in Maude, since its semantics are formal (do not worry about ‘sort’
for now):

sort Nat .
op zero : → Nat .
op s : Nat → Nat .

Formal Software Development Program Overview March 8, 2011 163 / 187

 Mathematics and Software Algebraic data types

Algebraic data types have initial algebra semantics

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 164 / 187

 Mathematics and Software Algebraic data types

Algebraic data types have initial algebra semantics

ip be
d
sk ay
pe
m

We can extend the Nat theory by adding addition and multiplication

to arrive at (the Peano) arithmetic. So we can express arithmetic as a theory
in Maude. We can add other functions using recursion. Then we can prove
certain properties of these theories using induction.

Formal Software Development Program Overview March 8, 2011 164 / 187

 Mathematics and Software Algebraic data types

Algebraic data types have initial algebra semantics

ip be
d
sk ay
pe
m

We can extend the Nat theory by adding addition and multiplication

to arrive at (the Peano) arithmetic. So we can express arithmetic as a theory
in Maude. We can add other functions using recursion. Then we can prove
certain properties of these theories using induction.

So data together with function definitions also form a theory, expressed in

the language of Maude. The Maude interpreter calculates (reduces) a
program (term) that is expressed in such a theory (which is itself an
extension of Maude’s equational logic). This view of data and functions as a
theory is very useful, not just in Maude but in general.

Formal Software Development Program Overview March 8, 2011 164 / 187

 Mathematics and Software Algebraic data types

Example: initial algebra semantics in Maude

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 165 / 187

 Mathematics and Software Algebraic data types

Example: initial algebra semantics in Maude

ip be
d
sk ay
pe
m

A Maude functional module defines

a theory T in equational logic
language: rules:
... Equational Logic
... functional module

Object Level

tactics

checking
... Proof OK?
auto strategy
... Theorem?

Meta
Level

Maude
Formal Software Development Program Overview March 8, 2011 165 / 187
 Mathematics and Software Algebraic data types

Example: initial algebra semantics in Maude

ip be
d
sk ay
pe
m

A Maude functional module defines

a theory T in equational logic
language: rules:
Such a theory admits an initial se- ... Equational Logic
mantic algebra; it is formed by tak- ... functional module

ing the equivalence classes of terms Object Level

provably equal in the theory

tactics

checking
... Proof OK?
auto strategy
... Theorem?

Meta
Level

Maude
Formal Software Development Program Overview March 8, 2011 165 / 187
 Mathematics and Software Algebraic data types

Example: initial algebra semantics in Maude

ip be
d
sk ay
pe
m

A Maude functional module defines

a theory T in equational logic
language: rules:
Such a theory admits an initial se- ... Equational Logic
mantic algebra; it is formed by tak- ... functional module

ing the equivalence classes of terms Object Level

provably equal in the theory

This construction of the initial alge-
tactics
bra of a theory is encountered many
checking
times in our program ... Proof OK?
auto strategy
... Theorem?

Meta
Level

Maude
Formal Software Development Program Overview March 8, 2011 165 / 187
 Mathematics and Software Algebraic data types

Example: initial algebra semantics in Maude

ip be
d
sk ay
pe
m

A Maude functional module defines

a theory T in equational logic
language: rules:
Such a theory admits an initial se- ... Equational Logic
mantic algebra; it is formed by tak- ... functional module

ing the equivalence classes of terms Object Level

provably equal in the theory

This construction of the initial alge-
tactics
bra of a theory is encountered many
checking
times in our program ... Proof OK?
auto strategy
(The initial algebra model of propo- ... Theorem?
sitional calculus is the two-valued
Boolean algebra) Meta
Level

Maude
Formal Software Development Program Overview March 8, 2011 165 / 187
 Mathematics and Software Algebraic data types

Algebraic semantics and operational semantics agree

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 166 / 187

 Mathematics and Software Algebraic data types

Algebraic semantics and operational semantics agree

ip be
d
sk ay
pe
m

Those terms that cannot be simpli-

fied further through the use of the
theory are called canonical terms.
language: rules:
... Equational Logic
... functional module

Object Level

tactics

checking
... Proof OK?
auto strategy
... Theorem?

Meta
Level

Maude
Formal Software Development Program Overview March 8, 2011 166 / 187
 Mathematics and Software Algebraic data types

Algebraic semantics and operational semantics agree

ip be
d
sk ay
pe
m

Those terms that cannot be simpli-

fied further through the use of the
theory are called canonical terms.
Under certain technical conditions language: rules:
on the theory, these terms exist ... Equational Logic
... functional module
(their collection forms the canonical
Object Level
term algebra)

tactics

checking
... Proof OK?
auto strategy
... Theorem?

Meta
Level

Maude
Formal Software Development Program Overview March 8, 2011 166 / 187
 Mathematics and Software Algebraic data types

Algebraic semantics and operational semantics agree

ip be
d
sk ay
pe
m

Those terms that cannot be simpli-

fied further through the use of the
theory are called canonical terms.
Under certain technical conditions language: rules:
on the theory, these terms exist ... Equational Logic
... functional module
(their collection forms the canonical
Object Level
term algebra)
Maude reduces a term to its canon-
ical form, this is proof-theoretic se- tactics
mantics checking
... Proof OK?
auto strategy
... Theorem?

Meta
Level

Maude
Formal Software Development Program Overview March 8, 2011 166 / 187
 Mathematics and Software Algebraic data types

Algebraic semantics and operational semantics agree

ip be
d
sk ay
pe
m

Those terms that cannot be simpli-

fied further through the use of the
theory are called canonical terms.
Under certain technical conditions language: rules:
on the theory, these terms exist ... Equational Logic
... functional module
(their collection forms the canonical
Object Level
term algebra)
Maude reduces a term to its canon-
ical form, this is proof-theoretic se- tactics
mantics checking
... Proof OK?
These two semantics agree, i.e. the auto strategy
two algebras are isomorphic ... Theorem?

Meta
Level

Maude
Formal Software Development Program Overview March 8, 2011 166 / 187
 Mathematics and Software Algebraic data types

Algebraic semantics and operational semantics agree

ip be
d
sk ay
pe
m

Those terms that cannot be simpli-

fied further through the use of the
theory are called canonical terms.
Under certain technical conditions language: rules:
on the theory, these terms exist ... Equational Logic
... functional module
(their collection forms the canonical
Object Level
term algebra)
Maude reduces a term to its canon-
ical form, this is proof-theoretic se- tactics
mantics checking
... Proof OK?
These two semantics agree, i.e. the auto strategy
two algebras are isomorphic ... Theorem?

These two kinds of semantics are ba- Meta

Level
sic to everything we do in the pro-
Maude
gram
Formal Software Development Program Overview March 8, 2011 166 / 187
 Mathematics and Software Algebraic data types

State transitions with category theory

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 167 / 187

 Mathematics and Software Algebraic data types

State transitions with category theory

ip be
d
sk ay
pe

So far everything has been about inductively defined data and

m

operations on this data. In other words, functional programming. The main

characteristic of imperative programs (one that functional programs do not
have) is the notion of state. State transitions of systems can be also be
described with category theory. Endofunctors F are used here, but in a dual
fashion. We do not have the space to introduce duality, suffice it to say that
F − coalgebras are the dual notion to F − algebras, ‘finality’ is dual to
‘initiality’, and the semantics of state transitions can be given with final
F − coalgebras. So, with duality taken for granted:

Formal Software Development Program Overview March 8, 2011 167 / 187

 Mathematics and Software Algebraic data types

State transitions with category theory

ip be
d
sk ay
pe

So far everything has been about inductively defined data and

m

operations on this data. In other words, functional programming. The main

characteristic of imperative programs (one that functional programs do not
have) is the notion of state. State transitions of systems can be also be
described with category theory. Endofunctors F are used here, but in a dual
fashion. We do not have the space to introduce duality, suffice it to say that
F − coalgebras are the dual notion to F − algebras, ‘finality’ is dual to
‘initiality’, and the semantics of state transitions can be given with final
F − coalgebras. So, with duality taken for granted:
data and operations on data have initial algebra semantics

Formal Software Development Program Overview March 8, 2011 167 / 187

 Mathematics and Software Algebraic data types

State transitions with category theory

ip be
d
sk ay
pe

So far everything has been about inductively defined data and

m

operations on this data. In other words, functional programming. The main

characteristic of imperative programs (one that functional programs do not
have) is the notion of state. State transitions of systems can be also be
described with category theory. Endofunctors F are used here, but in a dual
fashion. We do not have the space to introduce duality, suffice it to say that
F − coalgebras are the dual notion to F − algebras, ‘finality’ is dual to
‘initiality’, and the semantics of state transitions can be given with final
F − coalgebras. So, with duality taken for granted:
data and operations on data have initial algebra semantics
systems and their state transitions have final coalgebra semantics

Formal Software Development Program Overview March 8, 2011 167 / 187

 Mathematics and Software Algebraic data types

State transitions with category theory

ip be
d
sk ay
pe

So far everything has been about inductively defined data and

m

operations on this data. In other words, functional programming. The main

characteristic of imperative programs (one that functional programs do not
have) is the notion of state. State transitions of systems can be also be
described with category theory. Endofunctors F are used here, but in a dual
fashion. We do not have the space to introduce duality, suffice it to say that
F − coalgebras are the dual notion to F − algebras, ‘finality’ is dual to
‘initiality’, and the semantics of state transitions can be given with final
F − coalgebras. So, with duality taken for granted:
data and operations on data have initial algebra semantics
systems and their state transitions have final coalgebra semantics

Formal Software Development Program Overview March 8, 2011 167 / 187

 Mathematics and Software Algebraic data types

State transitions with category theory

ip be
d
sk ay
pe

So far everything has been about inductively defined data and

m

operations on this data. In other words, functional programming. The main

characteristic of imperative programs (one that functional programs do not
have) is the notion of state. State transitions of systems can be also be
described with category theory. Endofunctors F are used here, but in a dual
fashion. We do not have the space to introduce duality, suffice it to say that
F − coalgebras are the dual notion to F − algebras, ‘finality’ is dual to
‘initiality’, and the semantics of state transitions can be given with final
F − coalgebras. So, with duality taken for granted:
data and operations on data have initial algebra semantics
systems and their state transitions have final coalgebra semantics
The algebraic study of software will only increase. One major piece that is
still missing is a convincing algebraic description of the notion of
concurrency.

Formal Software Development Program Overview March 8, 2011 167 / 187

 Mathematics and Software Algebraic data types

Construction versus observation

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 168 / 187

 Mathematics and Software Algebraic data types

Construction versus observation

ip be
d
sk ay
pe

It is easier if you look at algebraic types as data, but look at

m

coalgebraic types as systems. So a stream would be a system. We can

construct data but we cannot construct systems, we just observe systems.
We cannot construct a stream, we can just observe it (by observing the head
of the stream). We can reason inductively about data but have to reason
coinductively about systems. The table below shows this duality.

data and functions systems and transitions

algebraic type coalgebraic type
(=inductive type) (=coinductive type)
(=recursive type) (=corecursive type)
definition by recursion definition by corecursion
proof by induction proof by coinduction
type is constructed type is observed

Formal Software Development Program Overview March 8, 2011 168 / 187

 Mathematics and Software Algebraic data types

Why all this algebra language?

ip be
d
sk ay
pe
m

Formal Software Development Program Overview March 8, 2011 169 / 187

 Mathematics and Software Algebraic data types

Why all this algebra language?

ip be
d
sk ay

This mention of algebra, coalgebra, categories, etc . . . should not give

pe
m

you the impression that, in the advanced sequence of the program, we’ll
chase unnecessarily abstract mathematics at the expense of practical
applications. Quite the contrary, we need to find a way to speed up towards
engineering goals. The truth is that while these applications of category
theory are not particularly deep, they do establish a very effective vocabulary
for us to use.

Formal Software Development Program Overview March 8, 2011 169 / 187

 Mathematics and Software Algebraic data types

Why all this algebra language?

ip be
d
sk ay

This mention of algebra, coalgebra, categories, etc . . . should not give

pe
m

you the impression that, in the advanced sequence of the program, we’ll
chase unnecessarily abstract mathematics at the expense of practical
applications. Quite the contrary, we need to find a way to speed up towards
engineering goals. The truth is that while these applications of category
theory are not particularly deep, they do establish a very effective vocabulary
for us to use.

But there is a stronger reason to use categories. Objects of categories can be

thought of as ‘variable sets’. The mathematics you learned in high-school
used set theory and because of this familiarity, it would be nice if we could
base everything on ordinary (=constant) sets. It turns out that many formal
systems that are needed in software cannot be modeled with ordinary sets:
e.g. lambda calculus, polymorphism, higher order logic, . . . As it was
mentioned earlier, our working (but untested) assumption is that using a
higher level of abstraction would eventually feel natural to software engineers.

Formal Software Development Program Overview March 8, 2011 169 / 187

 Concrete examples of what we do in the program

1 What is formal software development

2 Implementing formal systems

3 When are proofs used

4 What formal software development is not

5 Formal verification of programs

6 Mathematics and Software

7 Concrete examples of what we do in the program

8 Program goals and course structure

Formal Software Development Program Overview March 8, 2011 170 / 187
 Concrete examples of what we do in the program Lab sessions

My setup for lectures

Guest machine: Ubuntu 10.4 64-bit

Proof General (needs GNU Emacs)
Maude (logical platform)
Coq (logical platform)
Isabelle (logical platform)
SPIN (model checker)
LAMP (Apache, MySql and PHP)

Host machine: Windows 7 64-bit

SWI-Prolog, GHC (Glasgow Haskell Compiler)
Rodin (platform for Event-B modeling)
Visual Studio 10

Formal Software Development Program Overview March 8, 2011 171 / 187

 Concrete examples of what we do in the program Lab sessions

About labs

During the lectures, when you see the following picture . . .

. . . it means that we are branching out of the slide presentation and into a
computer session on either Linux or Windows. We call these branch-outs
‘labs’.

What follows here is a set of very quick labs (less than 5 minutes each) to
give you an idea of the sort of tools that we use in this program and why we
use them.

Formal Software Development Program Overview March 8, 2011 172 / 187

 Concrete examples of what we do in the program Lab sessions

Labs: Examples of formal software development

Refining requirements with Event-B

Formal Software Development Program Overview March 8, 2011 173 / 187

 Concrete examples of what we do in the program Lab sessions

Labs: Examples of formal software development

Refining requirements with Event-B

Building a model of a concurrent system
with SPIN

Formal Software Development Program Overview March 8, 2011 173 / 187

 Concrete examples of what we do in the program Lab sessions

Labs: Examples of formal software development

Refining requirements with Event-B

Building a model of a concurrent system
with SPIN
Building an executable model with Maude

Formal Software Development Program Overview March 8, 2011 173 / 187

 Concrete examples of what we do in the program Lab sessions

Labs: Examples of formal software development

Refining requirements with Event-B

Building a model of a concurrent system
with SPIN
Building an executable model with Maude
Building a certified program with Coq

Formal Software Development Program Overview March 8, 2011 173 / 187

 Concrete examples of what we do in the program Lab sessions

Labs: Examples of formal software development

Refining requirements with Event-B

Building a model of a concurrent system
with SPIN
Building an executable model with Maude
Building a certified program with Coq
Solve logical problems with Prolog

Formal Software Development Program Overview March 8, 2011 173 / 187

 Concrete examples of what we do in the program Lab sessions

Labs: Examples of formal software development

Verify C programs with Why/Frama-C

Formal Software Development Program Overview March 8, 2011 174 / 187

 Concrete examples of what we do in the program Lab sessions

Labs: Examples of formal software development

Verify C programs with Why/Frama-C

Verify Java programs with Why/Frama-C

Formal Software Development Program Overview March 8, 2011 174 / 187

 Concrete examples of what we do in the program Lab sessions

Labs: Examples of formal software development

Verify C programs with Why/Frama-C

Verify Java programs with Why/Frama-C
Program/Verify C# programs with
Spec#/Boogie/Z3 tool chain

Formal Software Development Program Overview March 8, 2011 174 / 187

 Concrete examples of what we do in the program Lab sessions

Labs: Examples of formal software development

Verify C programs with Why/Frama-C

Verify Java programs with Why/Frama-C
Program/Verify C# programs with
Spec#/Boogie/Z3 tool chain
Verify concurrent C programs with
VCC/Boogie/Z3 tool chain

Formal Software Development Program Overview March 8, 2011 174 / 187

 Concrete examples of what we do in the program Lab sessions

Labs: Examples of formal software development

Verify C programs with Why/Frama-C

Verify Java programs with Why/Frama-C
Program/Verify C# programs with
Spec#/Boogie/Z3 tool chain
Verify concurrent C programs with
VCC/Boogie/Z3 tool chain
Static Analysis of Java programs with ESC

Formal Software Development Program Overview March 8, 2011 174 / 187

 Concrete examples of what we do in the program Lab sessions

Labs: Examples of formal software development

Verify C programs with Why/Frama-C

Verify Java programs with Why/Frama-C
Program/Verify C# programs with
Spec#/Boogie/Z3 tool chain
Verify concurrent C programs with
VCC/Boogie/Z3 tool chain
Static Analysis of Java programs with ESC
Static Analysis of C programs with PREfast

Formal Software Development Program Overview March 8, 2011 174 / 187

 Concrete examples of what we do in the program Lab sessions

Labs: Examples of formal software development

Verify C programs with Why/Frama-C

Verify Java programs with Why/Frama-C
Program/Verify C# programs with
Spec#/Boogie/Z3 tool chain
Verify concurrent C programs with
VCC/Boogie/Z3 tool chain
Static Analysis of Java programs with ESC
Static Analysis of C programs with PREfast
Model checking Linux drivers with BLAST

Formal Software Development Program Overview March 8, 2011 174 / 187

 Concrete examples of what we do in the program Lab sessions

Labs: Examples of formal software development

Verify C programs with Why/Frama-C

Verify Java programs with Why/Frama-C
Program/Verify C# programs with
Spec#/Boogie/Z3 tool chain
Verify concurrent C programs with
VCC/Boogie/Z3 tool chain
Static Analysis of Java programs with ESC
Static Analysis of C programs with PREfast
Model checking Linux drivers with BLAST
Model checking Windows drivers with
SLAM

Formal Software Development Program Overview March 8, 2011 174 / 187

 Program goals and course structure

1 What is formal software development

2 Implementing formal systems

3 When are proofs used

4 What formal software development is not

5 Formal verification of programs

6 Mathematics and Software

7 Concrete examples of what we do in the program

8 Program goals and course structure

Formal Software Development Program Overview March 8, 2011 175 / 187
 Program goals and course structure Goals and expectations

Understand the main concepts of formal software

One goal is for you to understand most of the concepts of formal software
development in about 3 years.

Formal Software Development Program Overview March 8, 2011 176 / 187

 Program goals and course structure Goals and expectations

Understand the main concepts of formal software

One goal is for you to understand most of the concepts of formal software
development in about 3 years.
After that period, you should be able to:

Formal Software Development Program Overview March 8, 2011 176 / 187

 Program goals and course structure Goals and expectations

Understand the main concepts of formal software

One goal is for you to understand most of the concepts of formal software
development in about 3 years.
After that period, you should be able to:

Understand where a certain problem belongs

Formal Software Development Program Overview March 8, 2011 176 / 187

 Program goals and course structure Goals and expectations

Understand the main concepts of formal software

One goal is for you to understand most of the concepts of formal software
development in about 3 years.
After that period, you should be able to:

Understand where a certain problem belongs

Read research papers

Formal Software Development Program Overview March 8, 2011 176 / 187

 Program goals and course structure Goals and expectations

Understand the main concepts of formal software

One goal is for you to understand most of the concepts of formal software
development in about 3 years.
After that period, you should be able to:

Understand where a certain problem belongs

Read research papers
Use the latest versions of the tools

Formal Software Development Program Overview March 8, 2011 176 / 187

 Program goals and course structure Goals and expectations

Understand the main concepts of formal software

One goal is for you to understand most of the concepts of formal software
development in about 3 years.
After that period, you should be able to:

Understand where a certain problem belongs

Read research papers
Use the latest versions of the tools
Understand the trends

Formal Software Development Program Overview March 8, 2011 176 / 187

 Program goals and course structure Goals and expectations

Understand the main concepts of formal software

One goal is for you to understand most of the concepts of formal software
development in about 3 years.
After that period, you should be able to:

Understand where a certain problem belongs

Read research papers
Use the latest versions of the tools
Understand the trends
Develop working relationships with teams around the globe

Formal Software Development Program Overview March 8, 2011 176 / 187

 Program goals and course structure Goals and expectations

Understand the main concepts of formal software

One goal is for you to understand most of the concepts of formal software
development in about 3 years.
After that period, you should be able to:

Understand where a certain problem belongs

Read research papers
Use the latest versions of the tools
Understand the trends
Develop working relationships with teams around the globe
Become an active participant in the improvement of various tools

Formal Software Development Program Overview March 8, 2011 176 / 187

 Program goals and course structure Goals and expectations

Understand the main concepts of formal software

One goal is for you to understand most of the concepts of formal software
development in about 3 years.
After that period, you should be able to:

Understand where a certain problem belongs

Read research papers
Use the latest versions of the tools
Understand the trends
Develop working relationships with teams around the globe
Become an active participant in the improvement of various tools
Introduce formal thinking (and pilot projects) in your organization

Formal Software Development Program Overview March 8, 2011 176 / 187

 Program goals and course structure Goals and expectations

Judge the effectiveness of various tools

Formal Software Development Program Overview March 8, 2011 177 / 187

 Program goals and course structure Goals and expectations

Judge the effectiveness of various tools

Many of the tools we study are complex systems that have at least a
syntactical front-end and a logical back-end implementing a certain logic.
You will learn to judge the effectiveness of these tools, their tradeoffs and
their suitability for certain practical applications. There are many questions
to ask when contemplating formal software development with a specific tool.

Formal Software Development Program Overview March 8, 2011 177 / 187

 Program goals and course structure Goals and expectations

Judge the effectiveness of various tools

Many of the tools we study are complex systems that have at least a
syntactical front-end and a logical back-end implementing a certain logic.
You will learn to judge the effectiveness of these tools, their tradeoffs and
their suitability for certain practical applications. There are many questions
to ask when contemplating formal software development with a specific tool.
General questions:

Formal Software Development Program Overview March 8, 2011 177 / 187

 Program goals and course structure Goals and expectations

Judge the effectiveness of various tools

Many of the tools we study are complex systems that have at least a
syntactical front-end and a logical back-end implementing a certain logic.
You will learn to judge the effectiveness of these tools, their tradeoffs and
their suitability for certain practical applications. There are many questions
to ask when contemplating formal software development with a specific tool.
General questions:

What other industrial-sized applications were developed with the tool?

Formal Software Development Program Overview March 8, 2011 177 / 187

 Program goals and course structure Goals and expectations

Judge the effectiveness of various tools

Many of the tools we study are complex systems that have at least a
syntactical front-end and a logical back-end implementing a certain logic.
You will learn to judge the effectiveness of these tools, their tradeoffs and
their suitability for certain practical applications. There are many questions
to ask when contemplating formal software development with a specific tool.
General questions:

What other industrial-sized applications were developed with the tool?

How user-friendly is its interface?

Formal Software Development Program Overview March 8, 2011 177 / 187

 Program goals and course structure Goals and expectations

Judge the effectiveness of various tools

Many of the tools we study are complex systems that have at least a
syntactical front-end and a logical back-end implementing a certain logic.
You will learn to judge the effectiveness of these tools, their tradeoffs and
their suitability for certain practical applications. There are many questions
to ask when contemplating formal software development with a specific tool.
General questions:

What other industrial-sized applications were developed with the tool?

How user-friendly is its interface?
How configurable is the tool as a whole (front-end and back-end)?

Formal Software Development Program Overview March 8, 2011 177 / 187

 Program goals and course structure Goals and expectations

Judge the effectiveness of various tools

Many of the tools we study are complex systems that have at least a
syntactical front-end and a logical back-end implementing a certain logic.
You will learn to judge the effectiveness of these tools, their tradeoffs and
their suitability for certain practical applications. There are many questions
to ask when contemplating formal software development with a specific tool.
General questions:

What other industrial-sized applications were developed with the tool?

How user-friendly is its interface?
How configurable is the tool as a whole (front-end and back-end)?
Can the tool support the development of a model during requirements
analysis and design?

Formal Software Development Program Overview March 8, 2011 177 / 187

 Program goals and course structure Goals and expectations

Judge the effectiveness of various tools

Formal Software Development Program Overview March 8, 2011 178 / 187

 Program goals and course structure Goals and expectations

Judge the effectiveness of various tools

Questions specific to the logical back-end:

Formal Software Development Program Overview March 8, 2011 178 / 187

 Program goals and course structure Goals and expectations

Judge the effectiveness of various tools

Questions specific to the logical back-end:

How automatic is the logical back-end, i.e. what is the percentage of

proofs it discharges automatically?

Formal Software Development Program Overview March 8, 2011 178 / 187

 Program goals and course structure Goals and expectations

Judge the effectiveness of various tools

Questions specific to the logical back-end:

How automatic is the logical back-end, i.e. what is the percentage of

proofs it discharges automatically?
How powerful is the logical back-end (how big and how complex are the
formulas it can prove)?

Formal Software Development Program Overview March 8, 2011 178 / 187

 Program goals and course structure Goals and expectations

Judge the effectiveness of various tools

Questions specific to the logical back-end:

How automatic is the logical back-end, i.e. what is the percentage of

proofs it discharges automatically?
How powerful is the logical back-end (how big and how complex are the
formulas it can prove)?
Can it prove concurrency properties, for example interference freedom,
deadlock freedom or fairness?

Formal Software Development Program Overview March 8, 2011 178 / 187

 Program goals and course structure Goals and expectations

Judge the effectiveness of various tools

Questions specific to the logical back-end:

How automatic is the logical back-end, i.e. what is the percentage of

proofs it discharges automatically?
How powerful is the logical back-end (how big and how complex are the
formulas it can prove)?
Can it prove concurrency properties, for example interference freedom,
deadlock freedom or fairness?
Can it prove liveness or termination?

Formal Software Development Program Overview March 8, 2011 178 / 187

 Program goals and course structure Goals and expectations

Judge the effectiveness of various tools

Questions specific to the logical back-end:

How automatic is the logical back-end, i.e. what is the percentage of

proofs it discharges automatically?
How powerful is the logical back-end (how big and how complex are the
formulas it can prove)?
Can it prove concurrency properties, for example interference freedom,
deadlock freedom or fairness?
Can it prove liveness or termination?
Can it find powerful invariants on its own?

Formal Software Development Program Overview March 8, 2011 178 / 187

 Program goals and course structure Goals and expectations

Judge the effectiveness of various tools

Questions specific to the logical back-end:

How automatic is the logical back-end, i.e. what is the percentage of

proofs it discharges automatically?
How powerful is the logical back-end (how big and how complex are the
formulas it can prove)?
Can it prove concurrency properties, for example interference freedom,
deadlock freedom or fairness?
Can it prove liveness or termination?
Can it find powerful invariants on its own?
If a proof cannot be found automatically, does the system have a fallback
proof assistant?

Formal Software Development Program Overview March 8, 2011 178 / 187

 Program goals and course structure Goals and expectations

Judge the effectiveness of various tools

Questions specific to the logical back-end:

How automatic is the logical back-end, i.e. what is the percentage of

proofs it discharges automatically?
How powerful is the logical back-end (how big and how complex are the
formulas it can prove)?
Can it prove concurrency properties, for example interference freedom,
deadlock freedom or fairness?
Can it prove liveness or termination?
Can it find powerful invariants on its own?
If a proof cannot be found automatically, does the system have a fallback
proof assistant?
How complicated are the logical foundations of this proof assistant?

Formal Software Development Program Overview March 8, 2011 178 / 187

 Program goals and course structure Goals and expectations

Expected classroom participation

Formal Software Development Program Overview March 8, 2011 179 / 187

 Program goals and course structure Goals and expectations

Expected classroom participation

Your work experience will play an essential role in understanding some of the
engineering aspects of formal software development. In this process, it is the
feedback you will provide during and after classes that will contribute to the
program’s strength.

Formal Software Development Program Overview March 8, 2011 179 / 187

 Program goals and course structure Goals and expectations

Expected classroom participation

Your work experience will play an essential role in understanding some of the
engineering aspects of formal software development. In this process, it is the
feedback you will provide during and after classes that will contribute to the
program’s strength.
Consequently, you are expected to:

Formal Software Development Program Overview March 8, 2011 179 / 187

 Program goals and course structure Goals and expectations

Expected classroom participation

Your work experience will play an essential role in understanding some of the
engineering aspects of formal software development. In this process, it is the
feedback you will provide during and after classes that will contribute to the
program’s strength.
Consequently, you are expected to:

Participate in group discussions

Formal Software Development Program Overview March 8, 2011 179 / 187

 Program goals and course structure Goals and expectations

Expected classroom participation

Your work experience will play an essential role in understanding some of the
engineering aspects of formal software development. In this process, it is the
feedback you will provide during and after classes that will contribute to the
program’s strength.
Consequently, you are expected to:

Participate in group discussions

Install and evaluate programming systems and logical tools between
classes

Formal Software Development Program Overview March 8, 2011 179 / 187

 Program goals and course structure Goals and expectations

Expected classroom participation

Your work experience will play an essential role in understanding some of the
engineering aspects of formal software development. In this process, it is the
feedback you will provide during and after classes that will contribute to the
program’s strength.
Consequently, you are expected to:

Participate in group discussions

Install and evaluate programming systems and logical tools between
classes
Read additional papers before class

Formal Software Development Program Overview March 8, 2011 179 / 187

 Program goals and course structure Goals and expectations

Expected classroom participation

Your work experience will play an essential role in understanding some of the
engineering aspects of formal software development. In this process, it is the
feedback you will provide during and after classes that will contribute to the
program’s strength.
Consequently, you are expected to:

Participate in group discussions

Install and evaluate programming systems and logical tools between
classes
Read additional papers before class
Occasionally make group presentations on selected topics

Formal Software Development Program Overview March 8, 2011 179 / 187

 Program goals and course structure Goals and expectations

Learn to estimate the effort to formalize

Formal Software Development Program Overview March 8, 2011 180 / 187

 Program goals and course structure Goals and expectations

Learn to estimate the effort to formalize

Learn to estimate the effort to program in JML or Spec#, rather than Java
or C#. Learn to estimate the effort to add verification of safety properties
(buffer overflow, arithmetic overflow, null pointer dereference, division by
zero) to a C program. Learn to estimate the effort to design a concurrent
model of the system that is being built. A example of such estimate would
be:

N = lines of code
theorems = 2 × N
proof lines = 20 × theorems

Formal Software Development Program Overview March 8, 2011 180 / 187

 Program goals and course structure Goals and expectations

Build a wide formal platform

Formal Software Development Program Overview March 8, 2011 181 / 187

 Program goals and course structure Goals and expectations

Build a wide formal platform

Build a formal platform, an ongoing project:

Formal Software Development Program Overview March 8, 2011 181 / 187

 Program goals and course structure Goals and expectations

Build a wide formal platform

Build a formal platform, an ongoing project:

This platform will include all of the tools we study

Formal Software Development Program Overview March 8, 2011 181 / 187

 Program goals and course structure Goals and expectations

Build a wide formal platform

Build a formal platform, an ongoing project:

This platform will include all of the tools we study

You will learn to mix and match various tools

Formal Software Development Program Overview March 8, 2011 181 / 187

 Program goals and course structure Goals and expectations

Build a wide formal platform

Build a formal platform, an ongoing project:

This platform will include all of the tools we study

You will learn to mix and match various tools
You will learn to transform the output of a tool so that it can be verified
by another

Formal Software Development Program Overview March 8, 2011 181 / 187

 Program goals and course structure Goals and expectations

Build a wide formal platform

Build a formal platform, an ongoing project:

This platform will include all of the tools we study

You will learn to mix and match various tools
You will learn to transform the output of a tool so that it can be verified
by another
One goal of the program is to encourage you to participate in the devel-
opment of this platform

Formal Software Development Program Overview March 8, 2011 181 / 187

 Program goals and course structure Goals and expectations

Build a wide formal platform

Build a formal platform, an ongoing project:

This platform will include all of the tools we study

You will learn to mix and match various tools
You will learn to transform the output of a tool so that it can be verified
by another
One goal of the program is to encourage you to participate in the devel-
opment of this platform
In terms of program verification, the platform will use multiple front-ends
for C/Java/C#

Formal Software Development Program Overview March 8, 2011 181 / 187

 Program goals and course structure Goals and expectations

Build a wide formal platform

Build a formal platform, an ongoing project:

This platform will include all of the tools we study

You will learn to mix and match various tools
You will learn to transform the output of a tool so that it can be verified
by another
One goal of the program is to encourage you to participate in the devel-
opment of this platform
In terms of program verification, the platform will use multiple front-ends
for C/Java/C#
The platform will include multiple model checkers

Formal Software Development Program Overview March 8, 2011 181 / 187

 Program goals and course structure Structure

Program Structure

Formal Software Development Program Overview March 8, 2011 182 / 187

 Program goals and course structure Structure

Program Structure

Program is divided into four sequences:

Formal Software Development Program Overview March 8, 2011 182 / 187

 Program goals and course structure Structure

Program Structure

Program is divided into four sequences:

Foundation sequence (courses contain basic material that is needed through-
out the program)

Formal Software Development Program Overview March 8, 2011 182 / 187

 Program goals and course structure Structure

Program Structure

Program is divided into four sequences:

Foundation sequence (courses contain basic material that is needed through-
out the program)
Core sequence (courses that cover the essential material needed for doing
formal software development)

Formal Software Development Program Overview March 8, 2011 182 / 187

 Program goals and course structure Structure

Program Structure

Program is divided into four sequences:

Foundation sequence (courses contain basic material that is needed through-
out the program)
Core sequence (courses that cover the essential material needed for doing
formal software development)
Implementation sequence (how the logical tools are built)

Formal Software Development Program Overview March 8, 2011 182 / 187

 Program goals and course structure Structure

Program Structure

Program is divided into four sequences:

Foundation sequence (courses contain basic material that is needed through-
out the program)
Core sequence (courses that cover the essential material needed for doing
formal software development)
Implementation sequence (how the logical tools are built)
Advanced sequence (a deeper understanding of the theory)

Formal Software Development Program Overview March 8, 2011 182 / 187

 Program goals and course structure Structure

Program Structure
Term
Lisp and Higher
Logic Rewriting
Inductive Order
with C++
Provers Logic Logic and
Compu-
tation

ML Category
implemen- Theory
Languages advanced
tation
and sequence Type
sequence
Provers Systems

Reasoning
Formal
Formal Software with
Semantics
Computer Development Models
Algebra Concurrency
Systems and Model
Checking

Discrete basics Verification

core
Mathe- sequence sequence Interactive
of Con-
matics via Main Provers
current
Equational Concepts Programs
Logic of Logic Boolean
Verification Satisfi-
Haskell ability
of Se-
Logic and Logic with SMT
quential
Monads Prolog Solvers
Programs

Formal Software Development Program Overview March 8, 2011 183 / 187

 Program goals and course structure Recommended books

Recommended books I

Jean-Raymond Abrial
Modeling in Event-B System and Software Engineering
Cambridge University Press, 2010.

Manuel Clavel, Francisco Durán, Steven Eker, Patrick Lincoln, Narciso

Martı́-Oliet, José Meseguer, Carolyn Talcott
All About Maude - A High-Performance Logical Framework
Springer-Verlag, 2007.

Yves Bertot, Pierre Castéran

Interactive Theorem Proving and Program Development: Coq’Art: The
Calculus of Inductive Constructions
Springer-Verlag, 2010.

Formal Software Development Program Overview March 8, 2011 184 / 187

 Program goals and course structure Recommended books

Recommended books II

John Harrison
Handbook Of Practical Logic And Automated Reasoning
Springer-Verlag, 2009.

Gerard J. Holzmann
The SPIN Model Checker: Primer and Reference Manual
Addison-Wesley, 2004.

Tobias Nipkow, Lawrence C. Paulson, and Markus Wenzel

Isabelle/HOL: A Proof Assistant for Higher-Order Logic
Springer-Verlag, 2002.

Krzysztof R. Apt, Frank S. Boer, Ernst-Rüdiger Olderog

Verification of Sequential and Concurrent Programs
Springer-Verlag, 2009.

Formal Software Development Program Overview March 8, 2011 185 / 187

 Program goals and course structure Not just the correct, but also the most fascinating way

A big investment on your part

Formal Software Development Program Overview March 8, 2011 186 / 187

 Program goals and course structure Not just the correct, but also the most fascinating way

A big investment on your part

Formal software development is a huge subject

Formal Software Development Program Overview March 8, 2011 186 / 187

 Program goals and course structure Not just the correct, but also the most fascinating way

A big investment on your part

Formal software development is a huge subject

It requires a considerable commitment

Formal Software Development Program Overview March 8, 2011 186 / 187

 Program goals and course structure Not just the correct, but also the most fascinating way

A big investment on your part

Formal software development is a huge subject

It requires a considerable commitment
These are exciting times, a beehive of activity

Formal Software Development Program Overview March 8, 2011 186 / 187

 Program goals and course structure Not just the correct, but also the most fascinating way

A big investment on your part

Formal software development is a huge subject

It requires a considerable commitment
These are exciting times, a beehive of activity
Everywhere: US, Europe, Japan, China, India, . . .

Formal Software Development Program Overview March 8, 2011 186 / 187

 Program goals and course structure Not just the correct, but also the most fascinating way

A big investment on your part

Formal software development is a huge subject

It requires a considerable commitment
These are exciting times, a beehive of activity
Everywhere: US, Europe, Japan, China, India, . . .
Things are falling into place, as mathematicians and software engineers
work from both ends

Formal Software Development Program Overview March 8, 2011 186 / 187

 Program goals and course structure Not just the correct, but also the most fascinating way

A big investment on your part

Formal software development is a huge subject

It requires a considerable commitment
These are exciting times, a beehive of activity
Everywhere: US, Europe, Japan, China, India, . . .
Things are falling into place, as mathematicians and software engineers
work from both ends
It is up to you how quickly they fall into place!

Formal Software Development Program Overview March 8, 2011 186 / 187

 Program goals and course structure Not just the correct, but also the most fascinating way

A big investment on your part

Formal software development is a huge subject

It requires a considerable commitment
These are exciting times, a beehive of activity
Everywhere: US, Europe, Japan, China, India, . . .
Things are falling into place, as mathematicians and software engineers
work from both ends
It is up to you how quickly they fall into place!
Great time to produce machine-proven software

Formal Software Development Program Overview March 8, 2011 186 / 187

 Program goals and course structure Not just the correct, but also the most fascinating way

A big investment on your part

Formal software development is a huge subject

It requires a considerable commitment
These are exciting times, a beehive of activity
Everywhere: US, Europe, Japan, China, India, . . .
Things are falling into place, as mathematicians and software engineers
work from both ends
It is up to you how quickly they fall into place!
Great time to produce machine-proven software
I . . . and machine-proven mathematics!

Formal Software Development Program Overview March 8, 2011 186 / 187

 Program goals and course structure Not just the correct, but also the most fascinating way

Conclusion

The goals of our program are:

To begin thinking of software in formal terms

To deepen our understanding of logic and computation
To know and use powerful logic tools
To actively participate in their improvement

Software is . . . stating the right theorems and proving them

Formal Software Development Program Overview March 8, 2011 187 / 187