1. SD3049 Formal Methods

2. Formal Methods Module Leader Dr Aaron Kans (a.kans@uel.ac.uk)

3. What is this module about?

5. Ariane5 rocket crash

6. What is this module about? Ariane5 rocket crash NASA’s Mars Climate Orbitor November 1999 Total project cost : $327.6 million

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

8. 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;

9. 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.

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

11. Integrity Levels Integrity level 5 Integrity level 1

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

13. 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.

14. UML: a review BankAccount accountNumber: String accountName: String balance: Real deposit (Real) withdraw (Real) : Boolean currentBalance(): Real

15. 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

16. 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.”

17. 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?

18. 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.

19. 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.

20. Advantages of formal methods Generates good test cases; increases confidence that the specification accurately captures the real system requirements; important properties of the initial specification can be checked mathematically; proofs can help uncover design errors as soon as they are made; a proof of program correctness can be constructed.

21. 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)