Formal Specification

Thomas AlspaughICS 221

2002 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