Formal Methods in Software Engineering A Short Course

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 n Foundations, Part 1 ¨ ¨ n Foundations, Part 2 ¨ ¨ n Where are the quill pens and chalkboards? (basic tools) How do I get a computer to do this? (IDE) Application, Part 4 ¨ ¨ n What is this Greek? (notation) Why can’t I just code? (methods) Tools, Part 3 ¨ ¨ n Introduction to the 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, I 5 semester, year 20022003, ENSEIRB %%% and Paul Y Gloess %%% 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 (tau 1, tau 2: (monotonic? [T])): tau 1 <= tau 2 IMPLIES mu(tau 1) <= mu(tau 2)) ; OR(ts 1, ts 2: [T-> bool]) % simply set union. : [T ->bool] = (LAMBDA (t: T): ts 1(t) OR ts 2(t)) ; OR(tau 1, tau 2: [[T -> bool] -> [T -> bool]]) : [[T -> bool] -> [T -> bool]] = (LAMBDA (ts: [T-> bool]): tau 1(ts) OR tau 2(ts)) ; OR_monotonic: JUDGEMENT OR(tau 1, tau 2: (monotonic? [T])) HAS_TYPE (monotonic? [T]) ; BEGIN <=(tau 1, tau 2: [[T -> bool] -> [T -> bool]]) : bool = (FORALL (ts: [T -> bool]): tau 1(ts) <= tau 2(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 n Most formal methods are done with pencil and paper, or more apropos, a “chalkboard” n We’ve talked about epistemology, rigor, myths, notation, symbology, and even calculi, but these come near the end of a formal methods specification n Remember this from the first session, Foundations 1? © Quantum Solutions, 1995 -2002 4

Levels of Rigor of Formal Methods n n 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 n 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 n Tablet and stylus systems exist, but are very expensive and don’t do a good job of capturing the notations n 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} | : == : == i. e. binding is universal : : == © 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 co-domain is mapped to by exactly one element of the domain. ) A bijective function is a © Quantum Solutions, 1995 -2002 bijection (one-to-one correspondence). 8

Course Outline n Foundations, Part 1 ¨ ¨ n Foundations, Part 2 ¨ ¨ n Where are the quill pens and chalkboards? (basic tools) How do I get a computer to do this? (IDE) Application, Part 4 ¨ ¨ n What is this Greek? (notation) Why can’t I just code? (methods) Tools, Part 3 ¨ ¨ n Introduction to the 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 n n 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 j. Edit 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 n n 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: ¨ ¨ ¨ n 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 (Sy. Spect) Oldenburg, Germany © Quantum Solutions, 1995 -2002 14

New work in combination of notations n 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 Pro. Co. S (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 ¨ n These notations/tools are available from multiple public sources © Quantum Solutions, 1995 -2002 15

ACL 2: A Computational Logic for Applicative Common Lisp Nqthm has been used to check proofs of over 16, 000 theorems! © Quantum Solutions, 1995 -2002 NQTH M! 16

ACL 2 n ACL 2 is a direct descendent of the Boyer-Moore theorem prover, intended for large scale verification projects. ACL 2 was created by Matt Kaufmann and J Moore, working from a kernel developed by Boyer and Moore. The key ideas in ACL 2 are The logic supported by 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. ¨ n ACL 2 is quite young by Nqthm's standards. The ACL 2 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 JEM 1, 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 (Nu. SRS) Tampere University of Technology (TUT) , Findland Dis. Co (Distributed Co-operation) System © Quantum Solutions, 1995 -2002 18

Prototype Verification System (PVS) © Quantum Solutions, 1995 -2002 19

PVS from SRI n n PVS is a mechanized environment 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