Formal Methods in Software Engineering

3.3.1 Overview

Formal methods are mathematically-based languages, techniques and tools for specifying and verifying software/hardware systems. The goal of using formal methods is to enable developers to construct software/hardware systems that operate (comparatively) reliably. The demand for higher-quality software is always escalating. Formal methods have already demonstrated enormous success in safety-critical software developments. They may be used to create conceptual models in different phases of the software engineering life cycle: analysis, specification, architectural design, verification, prototyping and testing (Tremblay 2000). There are more than fifty formal methods available. Some formal methods use a model-based approach for sequential systems (e.g. VDM, Z, Larch (FME 2006)), some use algebraic relationships (e.g. OBJ (FME 2006)), some are designed for object oriented modelling (e.g. Z++, Object-Z, VDM++ (Lano et al. 1996)),

and some are useful for concurrent systems (e.g. CSP, CCP (FME 2006)). It is essential to select the right method for the right application. The Z notation is based on Zermelo- Fraenkel set theory and first-order predicate calculus. For example, Figure 3.1 gives a part of formal specification in Z language for Credit card application. The Object-Z specification for the same problem is given in Duke et al. (2000). In the late 1970s, the

Programming Research Group at the Oxford University Computing Laboratory started the process of developing Z (Bowen 1994). It is one of the most widely used formal method notation in industry for software specification. Moreover, it is also standardised.

Although formal methods are used in various tasks, such as software/hardware specification, verification (model checking and theorem proofing) and animation, the key notion of formal methods is clearly formal specification, which is the foundation on which all further development processes are continued (Tremblay 2000). The tangible benefits of using formal specification in software development processes include: (a) design flaws, inconsistencies, ambiguities, and incompleteness can be discovered easily in the early stages; (b) reliable systems may be developed in less time and with less cost; (c) test-suits may be created easily; (d) code may be verified automatically; and (e) code may be generated automatically. An important intangible benefit is gaining a deeper understanding of the system being specified.

Figure 3.1 Example: Z Specification for Credit Card Application

withdraw CreditCard

Being a mathematical notation, formal methods cannot be applied to large-scale software developments without appropriate tool support (Craigen et al. 1993). As the role of formal

methods becomes important in all the phases of the software development process, the tools and methods used in this process should ensure seamless transition between different phases. Usually, a formal specification document contains formal expressions with informal annotations, based on (typed) set theory and predicate logic.

There are more than one hundred tools available for various formal methods. About thirty of them were created for the Z notation alone (Steggles et al. 1994) Almost all of them

provide a syntax directed editing facility in order that a specification document may be created or easily edited in the environment. These tools can provide help with language syntax in batch mode or on-line. Symbols may be inserted by selecting icons or using tags For example, Figure 3.2 gives an interface of a formal method tool Z/EVES (Saaltink 1997). Documents may be viewed in LATEX or some other suitable form, and may be printed in graphical notation (pretty printing). Consistency checking and type checking may be performed in batch-mode. Some tools provide cross-links and expand/contract points for easy browsing. Others include querying facilities so that a user can find out the static semantics of a specification item. Many tools provide libraries and support multi- user projects. Advanced tools support refinement, that is, specification can be refined to executable code in steps. Some tools support verification via theorem proving (Steggles et al. 1994). None of these types of tools have any direct pedagogical components attached

to them.

Formalizer (Flynn et al. 1989), for example, is a syntax-directed editor, browser and type

checker for Z notation. It does not have a proof or refinement facility and at the most, from a pedagogical point of view, it gives short error reports (Figure 3.3). Almost all the other tools intended for Z notation are similar to Formalizer. A detailed comparison can be seen in Steggles (1994) or the FME Tools Database (FME 2006). The following tools are notably different from others since they claim to be designed as teaching aids: Zbrowser (Mikusiak et al. 1995), VisualiZer (Yap 1999), ZTC/ZANS (Jia 1995b, a) and

ZED/ZAL (Morrey et al. 1993). A detailed discussion on these tools is included in

Figure 3.2 Z-EVES environment, a formal method tool

3.3.3 Teaching and Learning Formal Methods

Generally, the subject ‘formal methods’ is taught in universities in three different disciplines; Mathematics, Computer Science and Software Engineering. Tremblay (2000) maintains that formal methods is not a mathematical subject. Jonathan Bowen, a formal methods expert, suggests, from his experience in teaching formal methods to undergraduate courses, that the specification aspects of the formal method should be emphasised in the initial stage and the analytical aspects may be introduced later, if necessary (Bowen 2000). He also states that using computer based tools gives better results than a traditional paper-pencil approach (ibid.). At Massey University, New

Zealand, formal methods are taught primarily to Software Engineering students.

There are many reports in the literature that reveal the various experiences of educators and researchers in teaching formal methods at tertiary level and for software practitioners. Jonathan Bowen’s experience speaks for the integration of computerised tools in his courses (Bowen 2000). In their edited book, Dean et al. (1996) explain their role-play

approach to teaching formal methods. Gibson et al. describe their case-study approach as, “Rather than concentrating on one particular method, we advocate working on a set of small case studies, using the mathematics in a flexible and intuitive manner, where the students can appreciate the need for formality. Each case study should illustrate, in turn, the need for some fundamental formalism” (Gibson et al. 1998, pg. 1).

The following are some of the reasons stated in the literature relating to students’ difficulties in learning formal methods:

• Insufficient mathematical ability • Complex notation and structure

• Lack of motivation (at the beginning) (Mikusiak et al. 1995)

• Inability to abstract details (Duke et al. 2000)

The last three difficulties may be alleviated by using appropriate artefacts in a CBL system. More on this issue will be discussed in Chapter 6.