Formal Specification

1. Formal Specification Thomas AlspaughICS 2212002 Nov 7

2. What is formal specification? • The broad view: • Any use of discrete mathematics … • that involves modelling and analysis … • underpinned by mathematically-precise model • And the narrow view: • A use of a formal language (syntax) ... • with formal reasoning about its formulae (semantics)

3. What sorts of “things” can be formal specifications? • Operational • The specification is executable • Examples: Scheme, Prolog, Smalltalk • State-based • Arbitrarily-complex state (value of a data structure) • Operations that change the state • Example: Z • Algebraic • Language of formulae • Operations that convert one formula to another • Example: Larch

4. What sort of decisions and operations are involved? • Example: propositional logic • we have primitives (var’s, brackets, const’s) • we have connectives (and, or, not) • we have quantifiers (existential, universal) • we have deduction rules • Expressions, open (?) or closed (tt or ff) • Have to take it “all the way down” to do anything • Quantified over what universe? • What is the denotation? • What do tt and ff mean?

5. What would we do with formal specification? • We show two specifications are consistent (identical, or one a refinement of the other) • We show a specification has some property • We show a specification is complete (with respect to some criterion) • We show a specification is self-consistent • We show a specification is well-formed

6. What is the landscape in which formal specifications fit? • We have: • the real world (domain properties D) • the statement of the problem (requirements R) • the specification of the solution (S) • the implementation of the solution (program P) • the system the software runs on (computer) • Verification: correctness • of solution S against problem R • of implementation P against specification S • and ...

7. What about validation? • More useful than correctness • Of system P+C against world D+R • Of R -- completeness (all important requirements) • Of D -- completeness(all relevant domain properties) • We are usually (no, always) operating with incomplete information

8. What kinds of things do we say? • D = Domain properties • R = Requirements • S = Specification -- bridge between D,R and P,C • P = Program properties • C = Computer (hardware) properties • Assuming C, then S + D imply R • we hope!

9. What are examples of R, D, S? • Requirement R: • “Reverse thrust shall only be enabled when the aircraft is moving on the ground.” • Domain properties D: • Wheel pulses are present iff wheels are turning • Wheels are turning iff plane is moving on ground • Specification S: • Reverse thrust is enabled iff wheel pulses present • S + D imply R • D is weak point

10. What are examples of R, D, S? • R • Database only accessed by authorized persons • D • Authorized persons have passwords • Passwords are never shared with others • S • Access to database shall be granted by password • S + D imply R • Again, D is weak point

11. Where do things go wrong? • The computer is wrong (very rare) • power, chip, OS, device, network, ... • detect with testing, certification through use, ... • The program is wrong (uncommon) • bug, misunderstood spec, poor configuration control • detect with testing to spec, inspection, walkthroughs • The specification is wrong (common) • misunderstood reqs, incomplete, inconsistent • detect with inspection, formal verification, end-to-end testing

12. Where do things go wrong? (ii) • The requirements are wrong (common) • not enough communication with users, not enough analysis, change not handled correctly • detect with inspections, customer reviews, modelling, formal validation, prototyping • The domain properties are wrong (very common) • lack of expertise, unquestioned assumptions, not enough domain analysis • detect with failure analysis, talking to the right experts, testing off-nominal cases

13. How can formality help? • Formalize S • precise baseline to verify P against • we don’t prove correctness unless it’s really really important • as a model to compare against R

14. How can formality help? • Formalize D • reason about completeness • reason about how D affects S • forces us to be precise and explicit

15. How can formality help? • Formalize R • to animate them • to test for consistency and coherence • to test for completeness (against some underlying model)

16. Why don’t we do more of it? • Formal approaches are usually at lower level • too much detail too soon • too many decisions too soon • Concentrate on consistency and completeness • which we usually don’t have

17. Why don’t we do more of it? • Where to use it appropriately? • attached to one tool or language • are we modelling the program or the requirements? • scaleability (of tools) • “It requires more effort” • takes time • takes training • payoff is deferred • Not always appropriate