Presentation on theme: "Formal Methods. Introduction Today's software comes with extensive documentation: –user guides, reference, manuals, and design documents. –There are on-line."— Presentation transcript:
Introduction Today's software comes with extensive documentation: –user guides, reference, manuals, and design documents. –There are on-line help systems, interactive tutorials, and user friendly. Yet the behavior of software is often a surprise to users and designers. –Components interact and interfere, undesirable properties emerge, and systems fail to meet their requirements.
Introduction The more spectacular consequences make the headlines: –aircraft crash, trains collide, people receive fatal doses of radiation, and emergency telephone services are withdrawn. The less spectacular we face every day: –time is wasted, effort is expended to no avail, important projects are scrapped, and our health is damaged by sheer frustration.
Introduction There are many explanations for this: –the requirements upon a piece of software are hard to define –the ways in which a system may be used are hard to anticipate –there is always a demand for additional functionality. –Indeed, the fact that many pieces of software actually work, and work well, is some indication of the skill of those whose job it is to develop them.
Introduction One way to improve the quality of software is to change the way in which software is documented: –at the design stage, during development, and after release. Existing methods of documentation offer large amounts of text, pictures, and diagrams, but these are often imprecise and ambiguous. Important information is hidden amongst irrelevant detail, and design flaws are discovered too late, making them expensive or impossible to correct.
Formal Methods Formal methods, based upon elementary mathematics, can be used to produce precise, unambiguous documentation, in which information is structured and presented at an appropriate level of abstraction. This documentation can be used to support the design process, and as a guide to subsequent development, testing, and maintenance.
Formal Methods The mathematical basis is different from that of civil or mechanical engineering, but it has the same purpose: –to add precision, to aid understanding, and to reason about properties of a design. Whatever the discipline, the use of mathematics can be expensive, but it can actually reduce costs.
Formal Methods Existing applications of formal methods include: –the use of probability theory in performance modeling –the use of context-free grammars in compiler design –the use of the relational calculus in database theory The formal method has been used in the specification and design of large software systems.
The course: Z Module Descriptor Formal methods: what they’re used for and why it’s important Two great inventions of the last 4000 years: logic and set theory Basic vocabulary: relations, functions, sequences, bags, schemas Structure of a specification Things to do to your spec: refinement and decomposition Things to get from your spec: prototype implementation from specifications The Z Specification Language
The Z module: learning outcomes Fluently express yourself in Z. Fluently translate conversation into and out of Z. Reason about Z specifications. Look at a Z specification and say ‘yes, that’s right’ or ‘no, that’s wrong
References Material E. Currie “The essence of Z J. Jacky “The way of Z”. D. Lightfoot “Formal Specification Using Z” M. Spivey “Understanding Z”
Software Crisis We don’t know how to write software. Lot’s of really bad software gets written — not all of it by incompetents though they do their fair share. There are many reasons for this. It’s economically advantageous to ship buggy software today rather than flawless software tomorrow. The manager of the software team is a class A idiot. What you’re trying to program is actually impossible. We must conform to poor standards (i.e. bugs in Internet Explorer). We don’t know what we’re writing.
We don’t know what we’re writing?? It’s just hard to specify unambiguously what we want, and even harder to specify how we should make sure it happens.
Example: the flag on the 14th of August Put a flag up outside your home on the 14th August. Looks pretty simple, doesn’t it?
The flag on the 14th of August Does that mean midnight to midnight, or just during the day? Do you mean exactly midnight to midnight, at least midnight to midnight, or at most midnight to midnight — or dawn to dusk — or dawn to dawn? What if you put it up and the flag falls down? Does that count? Are you authorised to put the flag up twice (e.g. if it fell down)?
The flag on the 14th of August What does ‘your home’ mean? What if you have two homes? What if your home is being redecorated and you’re in a hotel? Do you put flags in all your homes, or just your one? Do you have to do it, or can your spouse do it for you?
The flag on the 14th of August Suppose you have a flag up all year. Do you have to take it down so you can put it up?
The flag on the 14th of August What is a flag anyway? What size? What if the colors are faded, or it’s muddy? Does it have to be somewhere people can see it? Does it have to be a Pakistan flag, or will any flag do? An Indonesian Flag? A Russian flag? A flag you made up yourself?
The flag on the 14th of August What if you steal a flag? Does that count? What if you have bought the house but you have not yet signed the completion. Who’s responsible for the flag: the seller or the buyer?
The problem of specification You are a professional programmer instructed to “write a program to put up a flag outside the customer’s house on the 14th of August”. Do you have enough information? You have bought a software library. Documentation states “this procedure puts up a flag outside the customer’s house on the 14th of August”. Can you use this procedure without reading its code? You are managing a software project. Legacy code states “this procedure puts a flag outside the customer’s house on the 14th of August”. You want to update this to account for time zones across the world. Do you have enough information to proceed?
We Need a Solution! Sorry, there is no solution. Z is not the solution, it is an attempt at a partial solution. The Z specification language helps us specify these things exactly. In this course you will learn to write specifications.
What is a specification? For this talk, a specification is a formal statement of something. “You should put a flag up outside your home on the 14th August” is not a formal specification. Different levels of abstraction are possible, obviously. The more detailed they are, the more of the pedantic questions they answer. The most detailed specification is the (arguably) the program itself A formal specification of our problem can be something like: –“Breathe in... breathe out... take the key from near the back door... use it to open the shed in the garden... take the flag from the metal cupboard on the left... etcetera.”
Logic A proposition is a statement to which we can assign truth-value. There are just two truth-values: –true (written T) and –false (written F).
Example non-propositions Questions: Is it raining? Commands: Breathe in... breathe out! Instructions: x := x + 1. Numbers: 2. Nonsense jumble of letters: All your base are belong to us. Oxford is a worthwhile university.
Combining propositions What if you want to say more than one thing??? For example, suppose that you want a proposition to express: –It’s raining, and –There exists a species of flightless bird.
Warning: things get tricky here. Remember that propositions get assigned truth-values. –When is P ^ Q assigned truth-value true? –When is P _ Q assigned truth-value true? –... and so on. The truth-values depend on the truth- values of P and Q: