Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Intro to Formal Methods
This material was covered during lectures on April 9, 1997.
Formal methods can be defined as follows (and, are defined in this way in The Encyclopedia of Software Engineering, J. M. Marciniak, ed., Wiley, 1994):
Formal methods used in developing computer systems are mathematically based techniques for describing system properties. Such formal methods provide frameworks within which people can specify, develop, and verify systems in a systematic, rather than ad hoc manner.
A method is formal if it has a sound mathematical basis, typically given by a formal specification language. This basis provides a means of precisely defining notions like consistency and completeness, and, more relevant, specification, implementation, and correctness.
Recent editions of Pressman's Software Engineering: A Practitioner's Approach include a chapter (or large part of a chapter) on formal methods; the fourth edition contains a chapter that appears to have been rewritten and updated extensively.
Sommerville's text includes substantially more material on this subject; the last few editions have contained three chapters on formal methods.
Ian Sommerville,
Software Engineering,
Fifth Edition, Addison-Wesley, 1995
Finally, the following collection of (generally, readable) technical papers includes several papers on formal methods, including tutorial introductions to several of these methods.
R. H. Thayer and A. D. McGettrick,
Software Engineering: A European Perspective
IEEE Computer Society Press, 1993
This collection has been placed on reserve for CPSC 333 in the library.
Most of the following material is taken from Sommerville's text.
Some of the (plausible) advantages of the use of formal methods for software development are as follows.
The development of a formal specification provides insights into and an understanding of the software requirements and software design. This reduces requirements errors and omissions. It provides a basis for an elegant software design.
Indeed, it is sometimes helpful to develop a formal specification of an existing system if that system is complex, and it is to be changed or replaced, since this can detect subtle errors that would otherwise be included in the modified (or new) system. In some editions of his book, Pressman mentions a case involving the development of an operating system. Here at Calgary, this technique has been used to detect errors in VLSI chips before the chips have been fabricated.
Formal software specifications are mathematical entities and may be analysed using mathematical methods. In particular, it may be possible to prove specification consistency and completeness. It may also be possible to prove that an implementation conforms to its specification. The absence of certain classes of errors may be demonstrated. However, program verification is expensive and the ability to reason about the specification itself is probably more significant.
Formal specifications may be automatically processed. Software tools can be built to assist with their development, understanding, and debugging. Sommerville discusses the possibility of ``animating'' formal specifications in order to produce prototypes of systems.
Formal specifications may be used as a guide to the tester of a component in identifying appropriate test cases. For example, a function's preconditions and postconditions can be used to design (black box) tests, and a class invariant can be useful when testing a class in an object-oriented system. These can all be written explicitly in (or deduced from) formal specifications.
Disadvantages include the fact that these methods aren't always appropriate (there are some kinds of requirements that really are more easily, and accurately, specified using pictures with annotations), and involve the difficulty of adopting such methods in industry.
Software management is often conservative and is unwilling to adopt new techniques for which payoff is not obvious. It is difficult to demonstrate that the relatively high cost of developing a formal system specification will reduce overall software development costs. In this respect, the use of mathematics in software engineering is different from in other engineering disciplines: Mathematical analysis of physical structures can result in cost savings in materials and allows cheaper designs to be used.
Some software engineers, particularly those in senior positions, have not been trained in the techniques needed to develop formal software specifications. Developing specifications requires a familiarity with discrete mathematics and logic. Inexperience with these techniques makes the development of formal specifications more difficult than it would be otherwise.
System customers are unlikely to be familiar with formal specification techniques. They may be unwilling to fund development activities that they cannot easily monitor.
Some classes of software system requirements are difficult to specify using existing techniques. In particular, current techniques cannot be used to specify the interactive components of user interfaces. Some classes of parallel processing systems, such as interrupt-driven systems, are difficult to specify.
There is a widespread ignorance of the practicality of current specification techniques and their applicability. The techniques have been used successfully in a significant number of nontrivial development projects.
Most of the effort in specification research has been concerned with the specification of languages and their theoretical underpinnings. Relatively little effort has been devoted to method and tool support.
These are taken from the article
R. Hall
``Seven Myths of Formal Methods''
IEEE Software, September, 1990, pp. 11-19
It will be clear, when you read the following summary, that Hall is an ``advocate'' for the use of formal methods.
You can find this summarized (almost exactly as below) in Sommerville's text; the paper itself is presented in the collection Software Engineering: A European Perspective, that is cited above.
Most of these ``myths'' concern exaggerations of advantages or disadvantages of these methods.
Perfect software results from the use of formal methods. A formal specification is a model of the real world, that may contain misunderstandings, misperceptions, or omissions - just as informal specifications can. However, formal methods generally do make specification errors easier to detect.
Formal methods mean program proving. Proving correctness of programs is only one approach to formal methods. Benefits arising from the formal development and analysis of specifications are (now) generally viewed as more significant.
Formal methods are so expensive that their use can only be justified in safety-critical systems. Hall reports that his company's experience is that development costs for all kinds of systems can be reduced by using formal specifications.
Formal methods require a high level of mathematical skill. Formal methods generally use simple - not advanced - methods. Much of what will be presented in the remaining lectures should be understandable after completion of Math 271 and Phil 279.
Formal methods increase development costs. Hall reports that this isn't generally the case, although more costs are incurred in early development stages (and savings come during later stages). Recall that something similar can be said about the use of virtually any software development methods.
Customers cannot understand formal specifications. Hall suggests that specifications can be understood by customers if you paraphrase them in a natural language (``plain English'') and use specification animation as well, when this is possible. One can, and should, include ``comments'' in formal specifications, so that they can also be read more easily, as well as effectively presented.
Formal specifications have only been used for trivial system development. Hall (and Sommerville) provide references documenting the use of formal methods to specify a software engineering environment, the kernel for a real-time system, an oscilloscope, and part of IBM's CICS system specification.
Another ``myth'' about formal methods might be that they can replace absolutely everything (else) in software development. The following ``Ten Commandments of Formal Methods'' are taken from the article
J. P. Bowan and M. G. Hinchley
``Ten Commandments of Formal Methods''
Technical Report 350, University of Cambridge Computer Laboratory
Cambridge, UK, September, 1994
and are also summarized in Pressman's text.
Thou shalt choose the appropriate notation. In order to choose effectively from the large number of formal specification languages that now exist, a software engineer should consider language vocabulary, the type of the application to be specified, and the breadth of usage of the language.
Thou shalt formalize, but not overformalize. You don't need to apply formal methods to every aspect of a major system. Those components that are safety critical are first choices, followed by components whose failure cannot be tolerated (for business reasons).
Thou shalt estimate costs. Formal methods have high start-up costs. Training of staff, acquisition of support tools, and use of contract consultants result in high first-time costs. These must be considered when examining the return on the investment associated with the introduction of these methods.
Thou shalt have a formal methods guru on call. Expert training and ongoing consulting are essential if these methods are to be used successfully (at least, for the first time).
Thou shalt not abandon thy traditional development methods. It is possible, and in many cases desirable, to integrate formal methods with structured or object-oriented methods.
Thou shalt document sufficiently. It is recommended that comments in a natural language accompany a formal specification in order to reinforce a reader's understanding of the specification.
Thou shalt not compromise thy quality standards. Methods for ``Software Quality Assurance'' haven't been discussed in CPSC 333 (but are described in Pressman's text); formal methods don't replace these.
Thou shalt not be dogmatic. Keep in mind that the use of formal methods isn't a guarantee of correctness. It's likely that a (sufficiently large or complex) final system will still have minor omissions, minor bugs, and other attributes that don't meet expectation, even if formal methods are used. (Again, though, there's some evidence that the correct use of formal methods can tend to reduce these.)
Thou shalt test, test, and test again. Formal methods don't replace well planned, thorough testing.
Thou shalt reuse. Over the long term, the only rational way to reduce software costs and to increase software quality is through reuse. Formal methods don't change this. In fact, it may be that formal methods are an appropriate approach when components for reuse libraries are to be created (and, some of the more advanced and/or theoretical texts on object-oriented development now include discussions of the use for formal methods as part of the process.)
At present, it seems unlikely that formal methods will be as widely (or soon) adopted as some of their advocates once predicted. They aren't quite as easy to use as informal methods generally are, and it isn't clear at all that their use will reduce costs - especially when software failure wouldn't be disastrous.
On the other hand, if a system being developed is
then it's worthwhile to use formal methods (in an appropriate way) in order to ensure that software specifications are complete, and that implementations conform to the specifications. While the number of ``safety-critical'' systems to be developed might not increase drastically in the future, it seems the development and use of ``reusable'' software components will. Thus, it seems likely that it'll be useful to be able to develop - or, at least, to read - formal specifications in the future.
In the remaining lectures (and notes), a brief introduction will be given for a formal specification language - Z - and techniques for ``proving correctness'' of simple programs (written in a suitable programming language) will be described.
Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Intro to Formal Methods