Teaching Formal Methods Early In the Software Engineering Curriculum
Hossein Saiedian Univ. of Nebraska At Omaha
Ann E.K. Sobel, Chairman Miami University
[email protected] Allan Stavely New Mexico Tech.
Peter Henderson SUNY at Stony Brook
Topic The necessity of formal methods education has developed from its increasing assimilation into systems development within industry. Organizations responsible for a wide range of applications have found it necessary to find an improved means of intellectual control over their complex system development and that formal methods can meet this need. To this end, the International Survey of Industrial Applications of Formal Methods concluded and recommended: “The current educational base in the US is weak in teaching formal methods in the context of software engineering . . . There is a clear need for improved integration of formal methods techniques with other software engineering practices”[2] There exists a number of articles in the current literature expressing the belief that the current educational program offered for a computer science degree does not stress the fundamental mathematical and engineering principles that should form the basis of software engineering[3,4,5,6]. The theory learned in mathematics and science classes is applied in other engineering classes, but unfortunately has not been applied in software engineering. The inability to apply logic in practical circumstances prevents the student from doing the systematic analysis necessary to solve practical problems. For these reasons, it is desirable to include the definition and application of a formal method into the undergraduate curriculum with the goal of increasing the complex problem solving skills of the software engineer. Formal analysis should be introduced early into the undergraduate curriculum to ensure substantial learning, use, and training in formal methods application.
Position of Saiedian The biggest challenge for teaching and learning formal methods is the mentality of developing an analysis and design model and reasoning about it before rushing to an implementation. Many of our students have gotten used to “reasoning” (finding out) about the correctness of a model by coding and running it and then making corrections until it is satisfactory. Thus the ultimate challenge is to change that mentality and teach our student how to build a model and reason about its correctness, stability, functionality, etc before rushing into an implementation. This is what engineers do. And that is the area where formal methods can play such an important role. Other non-formal or semi-formal methods do not have the expressive power and cannot be used to confidently (mathematically or rigorously) reason about the functionality of a given model. In summary, we have to change the above mentality and teach our students about the importance of abstract models, reasoning, building and analyzing a model, concluding certain properties about a model, etc. and introducing formal methods as a mechanism to achieve such goals.
Position of Stavely It is especially important that we show students how to integrate formal methods into the rest of their work. We must not leave the impression that formal methods are only a research topic, or only usable in academic exercises, or foundation material that only specialists need to know. We must make sure that the methods that we teach are useful in real work, and we must show the students how to use them for real work. Success in applying formal methods has often come, not from using maximal formality at all times, but from being more selective. For example, specification and verification in the Cleanroom method are often only semi-formal and can sometimes be quite informal indeed; good practitioners will know when they have to apply full rigor and when they can claim that a point is obvious and go on. Z and other formal notations are frequently used to write specifications even when the development based on those specifications is not done using any
formal method. Knowing when and how much to be formal is often the key to gaining real benefits from formal methods, and we must make sure that the students see this. In the long run, the important thing will to be to promote the routine use of mathematical concepts and reasoning in software engineering, as in any other form of engineering, rather than any particular "formal method".
Position of Sobel While it is important to teach formal methods, teaching only a single senior level course deprives students of the lessons learned during the experience of application. It is quite difficult to acquire a sufficient knowledge base during a single course to experience a project of any significant size. Even existing undergraduate text books are devoid of substantial exercises so students must rely on their own experiences in application in order to apply formal analysis to real-world problems [1]. Another disadvantage of teaching formal methods late in a student’s academic career stems from the diminished chance of modifying a student’s internalized software development style. The ad-hoc behavior of coding interlaced with frequent compiling is rampant while the process of thinking and formulating a proposed solution is rare. The earlier a student learns to first analyze a problem and the benefits from this analysis, the greater are his chances of adopting this style.
Position of Henderson There seems to be a belief in the CS/SE educational community that entering students are too weak and immature to learn/appreciate mathematics and to think more formally. Engineering students, who eventually design our cars, planes, houses, roads, appliances, etc. take foundational calculus freshman year. Our students, who eventually design most software systems take foundational discrete mathematics much later. Why? We use the term "formal methods" to mean the use of more rigorous, mathematical approaches for designing, developing, testing and reasoning about software systems. There is no equivalent term in the engineering disciplines. Mathematics and formal reasoning are simply understood to be fundamental to the discipline! Partly for this reason, engineering is considered a professional discipline. For the past 15 years, CS and Computer Engineering students at Stony Brook have taken Foundations of Computer Science before CS-I. This course emphasizes problem-solving, discrete math concepts and the important relationships between these and computer science. All the foundational mathematics required for Z and other formal specification techniques are established. Inductive and recursive thinking techniques are stressed. For our alumni survey/comments of this course, see www.sinc.sunysb.edu/cse113/survey. With this background the level of formality in CS-I is significantly increased. In addition to learning CS concepts and programming, students learn to reason about the algorithms and software they develop. Pre and post conditions are expressed more precisely using logic, sets, functions, etc. Mathematical inductive thinking naturally leads to identifying a loop invariant before composing an iteration. Students apply these ideas to demonstrating the correctness of simple algorithms and are briefly introduced to Z. Not all students understand after CS-I; however, with continued reinforcement in subsequent courses eventually most students can learn to think much more formally.
References [1] Clarkson, M. and A.E.K. Sobel, “Large-Scale Formal Methods Application: Some Missing Pieces”, http://www.eas.muohio.edu/san/formal/papers, 1999. [2] Craigen, Dan, Susan Gerhart, and Ted Ralson, "An International Survey of Industrial Applications of Formal Methods", Volume I and II, National Institute of Standards and Technology, GCR 93/626, March 1993. [3] Garlan, D., “Making Formal Methods Education Effective for Professional Software Engineers”, Information and Software Technology, 37(5-6):261-268, May 1995. [4] Jackson, M., “Formal Methods and Traditional Engineering”, Journal of Systems and Software, 40(3):191--194, March 1998. [5] Parnas, D.L., “ 'Formal Methods' Technology Transfer Will Fail”, Journal of Systems and Software, 40(3): 195--198, March 1998. [6] Saiedian, H., “An Invitation to Formal Methods”, Computer, Vol. 29, No. 4, April 1996, pp. 16-30.
