1. SD3049 Formal Methods Module Leader Dr Aaron Kans Module website www.homepages.uel.ac.uk/A.Kans/sd3049

2. What is this module about? Developing software like an ENGINEER

3. High Integrity Software Development By the end of this lecture you should be able to: define the term high integrity software; distinguish between different types of critical software; identify the weaknesses of testing as an approach to software verification; identify the weaknesses of natural language specifications; distinguish between formal and informal methods of software development; describe what is meant by the term lightweight formal methods.

4. Introduction Often software is integrated into a mechanical or electronic system Such software is known as embedded software Costs of software failure in these systems can be dangerously high Require a higher degree of confidence in the correctness of the software. Such software is known as HIGH INTEGRITY SOFTWARE.

5. Critical Software business critical software mission critical software safety critical software

6. Integrity Levels Integrity level 5 Integrity level 1

7. Some high profile examples of high integrity software failures The loss of NASA’s Mars Climate Orbitor in November 1999 The crash of the European space agencies Ariane5 rocket in July 1996 Radiation overdoses administered by the Therac-25 machine in the USA during the 1980’s.

8. CLIENT DEVELOPER FINAL APPLICATION TESTING SPECIFICATION The importance of the specification

9. Limitations of Testing 1.Testing cannot take place until some implementation is available. 2.Testing can only help to uncover errors - it cannot guarantee the absence of them. 3.Testing is always carried out with respect to requirements as laid down in the specification.

10. UML: a review The Unified Modelling Language (UML) notation is used to specify and design systems according to the principles of object-oriented development BankAccount accountNumber: String accountName: String balance: Real deposit (Real) withdraw (Real) : Boolean currentBalance(): Real

11. Weakness of natural language specifications Withdraw: “Receives a requested amount to withdraw from the bank account and, if there are sufficient funds in the account, meets the request. Returns a boolean value indicating success or failure of the attempt to withdraw money from the account.” Natural language descriptions do not have a fixed meaning, they are ambiguous. These notations do not have a fixed semantics

12. Incomplete specifications A specification can be considered incomplete when the behaviour is not completely defined. Withdraw: “Receives a requested amount to withdraw from the bank account and, if there are sufficient funds in the account, meets the request. Returns a boolean value indicating success or failure of the attempt to withdraw money from the account.”

13. Inconsistent specifications A specification is inconsistent when it contains within it contradictions. Withdraw: “Receives a requested amount to withdraw from the bank account and, if there are sufficient funds in the account, meets the request. Returns a boolean value indicating success or failure of the attempt to withdraw money from the account.” OVERDRAFT?

14. Formal languages It is desirable to use a specification notation with a fixed, unambiguous, semantics. Notations that have a fixed semantics are known as formal notations, or formal languages. A fixed semantics is achieved by defining a language in a completely unambiguous way using a mathematical framework.

15. Formal Methods initial formal specification 1st transformation 2nd transformation nth transformation final program A formal method includes a proof system for demonstrating that each transformation preserves the formal meaning captured in the previous step.

16. Advantages of formal methods formal specifications can help considerably in generating suitable test cases; the discipline required in producing a formal specification allows for feedback on system specifications at early development stages, increasing confidence that the specification accurately captures the real system requirements; important properties of the initial specification can be checked mathematically and incorporated as run-time checks in the final program; proofs can help uncover design errors as soon as they are made, rather than having to wait for testing of the final implementation; a proof of program correctness can be constructed that is a much more robust method of achieving program correctness than is testing alone.

17. Classifying formal methods AlgebraicModel-based Sequential systems Larch Vienna Development Method (VDM) Z B Concurrent Systems Calculus of Communicating Systems (CCS) OBJ Prototype Verification System (PVS) Concurrent Sequential Processes (CSP)

18. Lightweight Formal Methods INFORMAL SPECIFICATION (UML class diagram) FORMAL SPECIFICATION (VDM specification) IMPLEMENTATION (Java class)