1. Formal Specification Thomas Alspaugh ICS 221 2002 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