Formal Specification Thomas Alspaugh ICS Nov 7

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)

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

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?

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

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

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

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!

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

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

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

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

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

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

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

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

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