Transcript Formal Methods in Software Engineering

Formal Methods in
Software Engineering
A Short Course on When, Why, and
How to use Formal Methods in
Software Engineering
Richard Wallace
Sr. Partner, Quantum Solutions
© Quantum Solutions, 1995-2002
0
3/5
Course Outline

Foundations, Part 1





Foundations, Part 2



Where are the quill pens and chalkboards? (basic tools)
How do I get a computer to do this? (IDE)
Application, Part 4



What is this Greek? (notation)
Why can’t I just code? (methods)
Tools, Part 3



Introduction to the Introduction
Introduction
Who needs this? (need)
When did this get created? (history)
Military/Aerospace
Communications
Practical Issues, Part 5




Educating Program Managers
Operational Considerations for the Customer
Schedules – or – When is it good enough
Lies, Damn lies, and Formal Methods!
© Quantum Solutions, 1995-2002
1
Basic Tools  Pen & Paper
© Quantum Solutions, 1995-2002
2
In PVS
$$mu_props_extension.pvs
%%%
%%% Author: GL option students, I5 semester, year 20022003, ENSEIRB
%%%
and Paul Y Gloess <[email protected]>
%%%
http://www.enseirb.fr/~gloess/
%%%
%%% Version December 2, 2002
%%% Role: prove some more properties of fixpoints and "mu"
%%%
on top of NASA Bruno Dutertre fixpoint library,
%%%
and Paul Y Gloess Scott library.
%%%
mu_props_extension[T: TYPE]: THEORY
mu_monotonic: THEOREM
(FORALL (tau1, tau2: (monotonic?[T])):
tau1 <= tau2 IMPLIES mu(tau1) <= mu(tau2)) ;
OR(ts1, ts2: [T-> bool])
% simply set union.
: [T ->bool]
= (LAMBDA (t: T): ts1(t) OR ts2(t)) ;
OR(tau1, tau2: [[T -> bool] -> [T -> bool]])
: [[T -> bool] -> [T -> bool]]
= (LAMBDA (ts: [T-> bool]): tau1(ts) OR tau2(ts)) ;
OR_monotonic: JUDGEMENT
OR(tau1, tau2: (monotonic?[T])) HAS_TYPE (monotonic?[T]) ;
BEGIN
<=(tau1, tau2: [[T -> bool] -> [T -> bool]])
: bool
= (FORALL (ts: [T -> bool]): tau1(ts) <= tau2(ts)) ;
%nasa_fixpoints: LIBRARY = "../nasa/fixpoints/"
%IMPORTING nasa_fixpoints@mucalculus_prop %[T]
scott: LIBRARY = "../scott"
IMPORTING scott@induction[T]
"subset_transitive"!
% just for
reflexive?(tau: [[T -> bool] -> [T -> bool]]): bool
= (identity <= tau) ;
CONVERSION K_conversion
refl(tau: [[T -> bool] -> [T -> bool]]): (reflexive?)
= identity OR tau ;
refl_monotonic: JUDGEMENT
refl(tau: (monotonic?[T])) HAS_TYPE (monotonic?[T]) ;
IMPORTING composition_power[[T -> bool]]
mu_refl_power: THEOREM
(FORALL (tau: (monotonic?[T] AND reflexive?), k: posnat):
mu(tau^k) = mu(tau)) ;
END mu_props_extension
© Quantum Solutions, 1995-2002
3
Quill Pens and Chalkboards

Most formal methods are done with pencil and
paper, or more apropos, a “chalkboard”

We’ve talked about epistemology, rigor, myths,
notation, symbology, and even calculi, but these
come near the end of a formal methods
specification

Remember this from the first session,
Foundations 1?
© Quantum Solutions, 1995-2002
4
Levels of Rigor of Formal Methods




Level 0: No use of formal methods
Level 1: Formal specification (using
mathematical logic or a specification language
with formal semantics) of all or part of a system
Level 2: Formal specification at two or more
levels of abstraction and paper-and-pencil
proofs that the detailed specification satisfies
the abstract one
Level 3: Like level 2, except paper-and-pencil
proofs are replaced by formal proofs checked by
a semi-automatic theorem prover
© Quantum Solutions, 1995-2002
5
Quill Pens & Knowledge to Photons

A “chalkboard” is vital when a team is thinking together.
But it doesn't store the ideas well. A printing whiteboard
is best at capturing equations as these can be included
into a Microsoft Visio or Word document. Capturing
knowledge in a formal methods tool is not an effective
method as initial handwritten specifications

Tablet and stylus systems exist, but are very expensive
and don’t do a good job of capturing the notations

Use computerized tools once the ideas are firmed up
and you need to present to other people or store for
future reference
© Quantum Solutions, 1995-2002
6
Quill Pens & Knowledge to Photons
Which has more clarity?
Key:
Which notation caries more semantic
content?
{expression | binding & predicate}
| :== <where>
 :== <totalized> i.e. binding is universal
: :== <element of>
© Quantum Solutions, 1995-2002
7
Semantic Content
In mathematics, injections, surjections and bijections are classes of functions distinguished by the manner in which arguments (input
expressions from the domain) and images (output expressions from the codomain) are related or mapped to each other.
A partial function is a binary relation that associates each element of a set, sometimes called its domain, with at most one element of
another (possibly the same) set, called its codomain. However, not every element of the domain has to be associated with an element
of the codomain.
A function is said to be injective if it maps distinct x in the domain to distinct y in the co-domain, such that f(x) = y.
A function is surjective (onto) if every element of the codomain is mapped to by some element (argument) of the domain; this is
expressed logically by saying that for all y in B.
A function is bijective (one-to-one and onto) if and only if it is both injective and surjective. (Equivalently, every element of the codomain is mapped to by exactly one element of the domain.) A bijective function is a bijection (one-to-one correspondence).
© Quantum Solutions, 1995-2002
8
Course Outline

Foundations, Part 1





Foundations, Part 2



Where are the quill pens and chalkboards? (basic tools)
How do I get a computer to do this? (IDE)
Application, Part 4



What is this Greek? (notation)
Why can’t I just code? (methods)
Tools, Part 3



Introduction to the Introduction
Introduction
Who needs this? (need)
When did this get created? (history)
Military/Aerospace
Communications
Practical Issues, Part 5




Educating Program Managers
Operational Considerations for the Customer
Schedules – or – When is it good enough
Lies, Damn lies, and Formal Methods!
© Quantum Solutions, 1995-2002
9
Community Z tools (CZT)
© Quantum Solutions, 1995-2002
10
CZT Project


The Z specification language was adopted
as an ISO standard in 2002. It can be used
to precisely specify the requirements or
behavior of systems, and analyze that
behavior via proof, animation, test
generation etc. However, one of the biggest
barriers to the widespread use of the Z
specification language seems to be the
issue of tool support.
The software modules include








An XML Schema markup for Z.
Java classes for Z annotated syntax trees
Java classes for converting between XML and
Java AST
Java libraries for the common operations
needed in every Z tool (markup-converters,
parser, type-checker, etc.)
Graphical Z editors, with facilities for easily
entering the special Z Unicode symbols.
Currently we provide jEdit and eclipse plugins.
A Z animation tool called ZLive, with a
customizable graphical user interface.
Export tools, to output Z in other notations or
for other Z tools
Extended versions of the libraries and tools to
support Z extensions such as Object-Z and
CIRCUS
© Quantum Solutions, 1995-2002
11
Z/Eves
© Quantum Solutions, 1995-2002
12
Z/Eves, Best Interface, Poor Adoption


The EVES system was developed over the past ten years (1991-2001) and,
while a technical success it suffered from the “closed source” of Ada and
was only available for a high cost license. Like most provers, EVES
requires a good deal of expertise to use. EVES uses its own specification
language (Verdi) that, while based on ordinary predicate calculus and ZF
set theory, has a syntax that is unfamiliar to users
The Z/EVES project joins the technical power of the EVES system with the
Z notation. The Z notation adds considerable appeal to EVES, and adds
capabilities that were not strongly supported in Verdi. EVES, in turn,
provides powerful analytical capabilities that can be applied to Z
specifications in several ways:






syntax and type checking,
domain checking,
schema expansion,
precondition calculations, and
general theorem proving.
With the closing of the parent company, Odyssey Research Associates,
Ottawa, Canada, and the departure of it’s founder to the Canadian “Spook”
world, only universities are sources for the product
© Quantum Solutions, 1995-2002
13
UML, CSP-OZ-DC w/CZT
Oldenburg University’s System
Specification Tool (SySpect)
Oldenburg, Germany
© Quantum Solutions, 1995-2002
14
New work in combination of notations

UML has the disadvantage that the semantics is not
precise enough to define their effect making it difficult to
prove characteristics of systems. Using UML graphics a
development environment for a formal partial language is
constructed of:





CSP – Communicating Sequential Processes
OZ – Object-Z adds O-O language constructs, most notably,
classes, polymorphism and inheritance to the Z schemas
DC – Duration calculus is a real-time interval logic with an
extensive proof system (calculus) initially developed in the
context of the ProCoS (Provably Correct Systems) project to
describe the behavior of real-time systems. To represent state
variables that change over time
CZT – See slide 11 in this presentation
These notations/tools are available from multiple public
sources
© Quantum Solutions, 1995-2002
15
ACL2:
A Computational Logic for Applicative Common Lisp
Nqthm has been
used to check proofs
of over 16,000
theorems!
© Quantum Solutions, 1995-2002
NQTHM!
16
ACL2

ACL2 is a direct descendent of the Boyer-Moore theorem prover,
intended for large scale verification projects. ACL2 was created by Matt
Kaufmann and J Moore, working from a kernel developed by Boyer and
Moore. The key ideas in ACL2 are




The logic supported by the theorem prover is (an extension of a subset of)
applicative Common Lisp.
The system is coded in its own logic.
The system supports incremental and collaborative proof projects.
ACL2 is quite young by Nqthm's standards. The ACL2 Project was
begun in 1989, NQTHM 1972. But it has been used to do some
impressive things.




The IEEE compliance of the hardware implementing the elementary floating
point operations on the AMD Athlon microprocessor (Russinoff and Flatau,
of AMD),
An executable model of the Rockwell-Collins JEM1, the world's first silicon
Java Virtual Machine (Hardin, Greve, and Wilding, of Rockwell-Collins),
The security model and a formal analysis of the bootstrapping code for the
IBM 4758 secure coprocessor (Austel and Smith, of IBM),
The correctness of a safety-critical compiler ``checker'' for trainborne control
software by Union Switch and Signal (Bertoli and Traverso, of IRST, Italy)
© Quantum Solutions, 1995-2002
17
Systems that use PVS
Department of Nuclear & Quantum
Engineering, Advanced Institute of
Science, Korea
Formal requirements specification
and analysis tool for nuclear
engineering (NuSRS)
Tampere University of Technology (TUT) ,
Findland
DisCo (Distributed Co-operation) System
© Quantum Solutions, 1995-2002
18
Prototype Verification System (PVS)
© Quantum Solutions, 1995-2002
19
PVS from SRI




PVS is a mechanized environment for formal
specification and verification.
It builds on over 25 years experience at SRI in
developing and using tools to support formal
methods.
PVS consists of a specification language, a
number of predefined theories, a type checker,
an interactive theorem prover that supports the
use of several decision procedures and a
symbolic model checker, various utilities
including a code generator and a random
tester, documentation, formalized libraries, and
examples that illustrate different methods of
using the system in several application areas.
By exploiting the synergy between a highly
expressive specification language and powerful
automated deduction, PVS serves as a
productive environment for constructing and
maintaining large formalizations and proofs.
© Quantum Solutions, 1995-2002
20