1 / 17

Formal Specification

Formal Specification. Thomas Alspaugh ICS 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) ...

olathe
Download Presentation

Formal Specification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related