SWSE 623: Home Work Assignment 1
Initial Opinion of Formal Methods: A Discussion
Susan L. Fisher
September 14, 2000
Overview
This paper is a discussion of my initial feelings and understandings about formal methods. My initial opinion on formal methods is one of cautious optimism. At first glance, formal methods seem to be the extreme in one direction with all of its mathematical symbolism. It appears to be complex and cryptic how do you translate a requirement into a mathematical formula and how do other team members understand it? Yet my experience with trying to develop applications based on vague requirements is an extreme in the other direction. The time consuming reworking of code during system testing is a constant reminder that there must be a better way to crystallize the main requirements before coding begins. I formed my initial opinion primarily on the assigned readings, [1] and [2], and my hesitation is based on my experience as a software application developer. The articles I read are dated 1990, yet their relevance still apply ten years later. In Seven Myths of Formal Methods Anthony Hall is trying to dispel the "exaggerated beliefs" or myths for reasons to not use formal methods using a case study. J Wing in A Specifier's Introduction to Formal Methods provides an overview of formal methods from a specifiers point of view. She also provides some examples comparing some of the methods. I begin my discussion of formal methods by defining what they are from my understanding culled from the articles. From the readings, there were numerous benefits and limitations, some of which were of great interest to me, so I have included two brief sections on those subjects. As I read these articles, numerous questions came up and I have included some of these in this paper as well. I conclude this paper with my final ―initial‖ thoughts of formal methods.
What is Formal Methods?
Formal Methods are mathematically sound methods that use symbols (or objects) and rules (or relationships) to translate natural-language specifications into precise mathematical statements. The application of a formal method is really the mathematical modeling of a computer system. Engineers use mathematical models to assist them in studying a building or a bridge before actual construction takes place. Hall, in his article, argues that software engineers should undertake similar activities of creating a mathematical model of a computer system. I’m not sure if I completely agree with his analogy. How do you handle the complexity of the computer environment, the hardware? Operating systems vary greatly – for Windows 2000 I discovered the need to install a service pack on a client’s computer before my application would run properly, which I developed and tested in Windows NT 4.0 (service pack 4) operating environment. A formal method can be applied at any stage of a system's lifecycle. Benefits of using formal methods early in the development of a system is that potential problems and conflicts with requirements can be revealed when it is easier and cheaper to make a fix. Using formal methods during testing and verification help confirm that the system performs as intended. Are formal methods flexible enough to withstand constantly evolving (changing) requirements that occur as everyone involved with the project begins to understand the system? Statements are made in the articles about that development of specifications is an iterative process doesn’t adequately address this issue for me. Perhaps requirements should be tight and finalized before coding begins, but if that was the case would DOS even be available now?
Benefits
Both articles discuss the benefits of using formal methods. The benefits that appeal most to me are: They provide a framework that encourages a systematic approach for developing systems. They reveal missing, incomplete, conflicting and vague requirements. They uncover design flaws. They verify the ―correctness‖ of a computer system. They produce a precise set of requirements.
Given these benefits, I am optimistic about the use of formal methods, especially during the requirements phase and the verification phase. I hope that this semester I will learn more about how to answer the following questions: How can I apply a formal methodology to my work? How quick or easy would it be to use? How do I explain the resulting formal specification to the client?
For the last question, in his paper, Hall states ―A mathematical specification must be accompanied by a natural-language description‖. I agree with Hall’s discussion that it is essential to have narrative accompany the formal specification. Along with some diagrams, this would be key to explaining to a client my understanding of what the system is to do. For the first two questions, neither article was of real help. I'm afraid that the real downfall of formal methods is the application to a real world client/server application. Although Hall came close with his case study, it was to limited to be of help to me. I would need more complete examples before I would be comfortable going "solo" on any projects at work.
Limitations
Some of the limitations of formal methods were brought forth primarily in Hall's article. In his attempt to dispel what he calls the ―myths‖ of formal methods he reveals some of the limitations of formality. The limitations that concerned me most: Lack of examples. It is math. Little automated tool support. Sophistication of modeling techniques.
These limitations are the initial concerns that I have with formal methods. Again, I have some questions that I am hoping will be answered to some degree this semester. Some of my questions are: How do you turn vague customer requirements into a formalized mathematical statement? Do examples exist relevant to the type of applications that I design and develop? What automated tools exist that could aid me in this quest of translating and managing these formal specifications?
I have found (in many cases) that vague requirements tend to be that way because they are trying to say multiple things at once. The process of clarifying and simplifying requirements is of considerable value regardless of what method is used. However, a formal method provides a methodical process of analyzing requirements that result in clear and precise requirements — in mathematical statements. Statements that need to be accompanied by natural language text.
Conclusion
From the high rate of cost over run, schedule delays, and failures, it is apparent that whatever current methodology is being used to develop applications is failing to work. The less than formal method of developing a system needs overhauling. Will formal methods do this? I’m not so sure. A methodology is valuable in that it provides a framework for the methodical process of specifying requirements, developing a design, coding and testing. Although formal methods provide such a framework, being based on sound mathematics, formal methods have a very academic flavor. So, no — I don't think the common programmer will use formal methods.
References
[1] J. M Wing. A Specifier's introduction to formal methods. IEEE Computer, pages 8 - 24, September 1990. [2] A. Hall. Seven Myths of formal methods. IEEE Computer, pages 11 - 19, September 1990.