1 / 13

Formal Methods

Formal Methods. Chapter 10. Specification Languages. Specification Languages have emerged over the years (VDM and Z, for instance) with a purpose: Make it possible for people to write testable, checkable specifications.

ian-valentine
Télécharger la présentation

Formal Methods

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 Methods Chapter 10

  2. Specification Languages • Specification Languages have emerged over the years (VDM and Z, for instance) with a purpose: Make it possible for people to write testable, checkable specifications. • Since automatic analysis and checking was a goal, and since analysis and checking methods were mathematically based, the form of these languages has been mathematical. (Remember that “mathematics” has been sometimes defined as “the language of patterns”!)

  3. Enabling human talent • Specification languages target providing humans with a method for describing “patterns” or conditions to which the system must respond, and even patterns in the responses. • This allows human minds to operate at a level of abstraction which is far above the mundane nuts-and-bolts details of the problem set. Typically, the human mind operates quite happily at these lofty levels (and therein lies danger!)

  4. Hard-to-use mathematics • The problem with using the “pattern language” that is provided by specification languages is that they usually presume the user is mathematically adept. • Not all end-users have the necessary training to understand mathematical specifications. In fact, very few do.

  5. First-order Predicate Logic • The common basis for most specification languages is first-order predicate logic: this is the language used by mathematicians in presenting mathematical arguments. • First-order predicate logic allows presentation of formulas that, if syntactically correct, are called “well formed formulas” which can be used to present assertions, etc.

  6. The Controversy Over “Formal Methods” • Sometimes software can be dangerous if it malfunctions. Can formal methods be used to make it safe or safer? • Problems in software detected late in the lifecycle can threaten projects. Can formal methods be used to make projects more predictable?

  7. Dangerous software • Mission critical software can cause the loss of property and lives if it malfunctions: • Medical software • Avionics software • Process control software (refineries, reactors) • Software can also undermine the welfare and well-being of individuals and families if paychecks are late, or too much tax is withheld.

  8. Can formal methods make software safe? • Formal methods allow us to prove some things about the software, but only in the context of the information given. • If an outrageously incorrect set of assertions are given as a starting point for formal specification tools, can the tools do anything other than work with the assertions given? • Regardless, shouldn’t we at least try to do all that we can to make software safer by using formalisms?

  9. Mathematical precision for its own sake • Will mathematical notation force developers to think along logical lines? • Can mathematical notation, by it’s very approach, make it difficult to express incorrect or ambiguous requirements? • Can mathematical notation sharpen thinking?

  10. Mathematical precision for proof • Certainly, mathematical rigor and precision can be used to prove things about the system in question. • Is the system in question stable enough, however, to make the proofs meaningful? What happens when the unexpected happens?

  11. The Formal Methodists' dream • In the instance of expecting the unexpected, we have a circumstance the short-circuits the formal method dream: to provide conclusive evidence about system behavior. • The only way to demonstrate the correct behavior is, in many cases, to run an unfeasible number of tests on the system. Since this is unlikely, does mathematical proof add anything? Certainly. But the cost should be carefully considered.

  12. The “agnostic” position • Do we have to take the whole of mathematical formalism? Certainly not. Engineering allows us to apply the practical aspects of the theoretical, so we may apply as much formalism as is useful and practical. • In short, we can use a ‘shot’ of formalism to easily address some of the day-to-day problems of software engineering, such as testing, for instance.

  13. Formal specifications as automatic oracles • Since we can use formalism to define the ‘form’ of the specification, we could certainly use it to define the ‘form’ of the tests. • Extracting tests systematically from a formal specification allows us to maintain a specification, “push a button” and automatically get a set of tests that represent the current state of the specification. • We have then reduced our dependency on test writers, and can use the engineers to focus on the requirements/specification instead.

More Related