Introduction

Formal methods are system design techniques that use rigorously specified mathematical models to
build software and hardware systems. In contrast to other design systems, formal methods use
mathematical proof as a complement to system testing in order to ensure correct behavior. As systems
become more complicated, and safety becomes a more important issue, the formal approach to system
design offers another level of insurance.

Formal methods differ from other design systems through the use of formal verification schemes, the
basic principles of the system must be proven correct before they are accepted [Bowen93]. Traditional
system design has used extensive testing to verify behavior, but testing is capable of only finite
conclusions. Dijkstra and others have demonstrated that tests can only show the situations where a
system won't fail, but cannot say anything about the behavior of the system outside of the testing
scenarios [Bentley89]. In contrast, once a theorem is proven true it remains true.

History of formal method

Formal methods are viewed with a certain degree of suspicion. While formal methods research has been
progressing since 1960's, formal methods are only being slowly accepted by engineers. There are several
reasons for this, but most of the problems seem to be a result of misapplication. Most formal systems
are extremely descriptive and all-encompassing, modeling languages have generally been judged by
their capacity to model anything. Unfortunately, these same qualities make formal methods very
difficult to use, especially for engineers untrained in the type theory needed for most formal systems.

Formal design can be seen as a three-step process:-

Formal Specification: During the formal specification phase, the engineer rigorously defines a system
using a modeling language. Modeling languages are fixed grammars which allow users to model complex
structures out of predefined types. This process of formal specification is similar to the process of
converting a word problem into algebraic notation.

In many ways, this step of the formal design process is similar to the formal software engineering
technique developed by Rumbaugh, Booch and others. At the minimum, both techniques help engineers
to clearly define their problems, goals and solutions. However, formal modeling languages are more
rigorously defined: in a formal grammar, there is a distinction between WFFs (well-formed formulas)
and non-WFFs (syntactically incorrect statements). Even at this stage, the distinction between WFF and
non-WFF can help to specify the design. Several engineers who have used formal specifications say that
the clarity that this stage produces is a benefit in itself [Kling95].

Verification: As stated above, formal methods differ from other specification systems by their heavy
emphasis on provability and correctness. By building a system using a formal specification, the designer
is actually developing a set of theorems about his system. By proving these theorems correct, the formal

Verification is a difficult process, largely because even the simplest system has several dozen theorems,
each of which has to be proven. Even a traditional mathematical proof is a complex affair, Wiles' proof
of Fermat's Last Theorem, for example, took several years after its announcement to be completed.
Given the demands of complexity and Moore's law, almost all formal systems use an automated
theorem proving tool of some form. These tools can prove simple theorems, verify the semantics of
theorems, and provide assistance for verifying more complicated proofs.

Implementation: Once the model has been specified and verified, it is implemented by converting the
specification into code. As the difference between software and hardware design grows narrower,
formal methods for developing embedded systems have been developed.LARCH, for example, has a
VHDL implementation. Similarly, hardware systems such as the VIPER and AAMP5 processors have been
developed using formal approaches.

An alternative to this approach is the lightweight approach to formal design. In a lightweight design,
formal methods are applied sparingly to a system. This approach offers the benefits of formal
specification, but also avoids some of the difficulties.

Conversely, it is apparent that some form of formal specification is necessary: complex systems require
formal models. In addition, the mathematics required for formal methods is becoming a more
prominent fixture of engineering curricula, engineering schools in Europe are already requiring courses
in VDM, Z and similar formal specifications. Ultimately, formal methods will acquire some form of
acceptance, but compromises will be made in both directions: formal methods will become simpler and
formal methods training will become more common.

Key Concepts

Provability And Automated Verification

Formal methods are distinguished from other specification systems by their emphasis on correctness
and proof, which is ultimately another measure of system integrity. Proof is a complement, not a
substitute, for testing. Testing is an important part of guaranteeing any system's fitness, but it is finite.
Testing cannot demonstrate that a system operates properly; it can only demonstrate that the system
works for the tested cases. Because testing cannot demonstrate that the system should work outside
the tested cases, formal proof is necessary.

Formally proving computer systems is not a new idea. Knuth and Dijkstra have written extensively on
the topic, although their methods of proof are based on the traditional mathematical methods. In pure
sciences, proofs are verified through extensive peer review before publication. Such techniques are
time-intensive and less than perfect; it isn't unusual for a published proof to contain a flaw. Given the
cost and time requirements of systems engineering, traditional proving techniques are not really
applicable.

Because of the costs of hand verification, most formal methods use automated theorem proving
systems to verify their designs. Automated theorem provers are best described as mathematical CAD
tools: they can prove simple propositions and automatically and provide assistance for verifying more
complex theorems.
Benefits Of Formal Models

Formal methods offer additional benefits outside of provability, and these benefits do deserve some
mention. However, most of these benefits are available from other systems, and usually without the
steep learning curve that formal methods require.

Discipline: By virtue of their rigor, formal systems require an engineer to think out his design in a more
thorough fashion. In particular, a formal proof of correctness is going to require a rigorous specification
of goals, not just operation. This thorough approach can help identify faulty reasoning far earlier than in
traditional design.[Bowen95]

The discipline involved in formal specification has proved useful even on already existing systems.
Engineers using the PVS system, for example, reported identifying several microcode errors in one of
their microprocessor designs.[Miller95]

Precision: Traditionally, disciplines have moved into jargons and formal notation as the weaknesses of
natural language descriptions become more glaringly obvious. There is no reason that systems
engineering should differ, and there are several formal methods which are used almost exclusively for
notation.[Bowen93]

alterations, modifications of global variables or the like is allowed [Paulson96]. Handling side effects and
other aberrancies are a requirement for any system involving input, network operations or other
systems which require interrupts, meaning that SML's model is, to some extent, broken.

Usability:Traditionally, formal methods have been judged on the richness of their descriptive model.
That is, 'good' formal methods have described a wide variety of systems, and 'bad' formal methods have
been limited in their descriptive capacities. While an all-encompassing formal description is attractive
from a theoretical perspective, it invariably involved developing an incredibly complex and nuanced
description language, which returns to the difficulties of natural language. Case studies of full formal
methods often acknowledge the need for a less all-encompassing approach.[Miller95]

Arguably, many of these failures can be attributed to overreaching on the part of formal methods
advocates. This reasoning has led to the lightweight approach to formal specification.

The Lightweight Approach

The flaws in formal specifications have been heavily focused on in the past few years, leading to several
alternate approaches. The traditional view of formal methods as all-encompassing highly abstracted
schemes has led to formal methods being all-encompassing, extremely rigorous, and very expensive.
While theoretically appealing, formal methods have generally been ignored by engineers in the field.

The lightweight approach to formal design recognizes that formal methods are not a panacea: there are
areas where formal methods are useful, and areas where a formal specification will accomplish nothing.
In a lightweight design, formal methods are used in specific locations, and different formal methods may
be used in different subsystems, ideally playing to the strengths of each method [Easterbrook 98]. In
such a system, Petri Nets might be used to describe the communications protocol, and a LARCH system
might be used to model the data storage. For other parts of the system, formal specifications might be
avoided entirely: for example, the user interface may be refined using a rapid prototyping system and
client interviews.

The lightweight approach is a traditional engineering compromise, and there is a tradeoff. As formal
methods become more common, engineers will have to learn type theory, modern algebra and proof
techniques. Ultimately, engineers will have to think more like mathematicians.

Available tools, techniques, and metrics

Larch:Unlike most formal systems, LARCH provides two levels of specification. A general high-level
modeling language, and a collection of implementation dialects designed to work with specific
programming languages.

SML: Standard Meta-Language is a strongly typed functional programming language originally designed
for exploring ideas in type theory. SML has become the formal methods workhorse because of its strong
typing and provability features.

HOL:HOL, short for Higher Order Logic, is an automated theorem proving system. As with most
automated theorem proving systems, HOL is a computer-aided proof tool: it proves simple theorems
and assists in proving more complicated statements, but is still dependent on interaction with a trained
operator. HOL has been extensively used for hardware verification, the VIPER chip being a good
example.

Petri Nets:Petri Nets are a good example of a very 'light' formal specification. Originally designed for
modeling communications, Petri Nets are a graphically simple model for asynchronous processes.

1. Why formal method

2. When and where to use formal method

When and where to use Formal Methods?

 Introduce FM into existing systems

 Verify critical properties

 Facilitate maintenance and reimplementation

 Introduce FM into new systems

 Capture requirements precisely

 Reduce ambiguity
 Guide software development process

 Basis for testing o Formalize requirements analysis and design

3. What are the advantages of formal method and disadvantages of formal method

Advantages

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).

Disadvantages

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

4.Discusscritical software

Critical Software

Having known the advantages and disadvantages, most clients will see the justification to use formal
methods for critical systems, but this thinking is now slowly fading as most clients realize the important
and cost saving and convenience of having a good specification initially in the SDLC.
There are basically three (3) different types of critical systems;

1. Business Critical System

Business Critical System refers to a system where the honesty and integrity of the business is
paramount. All data kept in the system must be accurate at all times. If a fault is found the entire
process must be stop to allow correction. Most government, business and manufacturing company that
requires payment are business critical.

2. Mission Critical System

Mission Critical System refers to a system where the continuous running of the system is paramount.
Accurate takes a lower priority compare to the running of the system.
Auto Teller Machine, Car ticketing system, Alarm Systems are mission critical.
3. Safety Critical System
Safety Critical System refers to a system where the safety of everyone directly or indirectly affected by
the system is paramount. Functionality and Accurate takes a lower priority compare to the safety of the
users. Most medical, construction and oil rig systems are safety critical system.
Many organizations today require a combination of the above as such you may have a

business mission critical system, a business safety critical system, etc.

5. Discuss the stages in formal method

Stages in Formal Methods

1. Formal Specification

This is where normal system specification is use and translated using a formal language

into a formal specification. There are basically two type of formal language; Model Oriented (VDM, Z,
etc) and Properties Oriented (Algebraic Logic, Temporal Logic, etc). This is the cheapest way to handle
formal method.
The formal specification generally does the following process.

 Get user requirement usually from the specification written in the natural language.

 Clarify the requirement using mathematical approach. This is to remove all ambiguous, incomplete
and inconsistent statement.

 After statements are clearly identified. Then find all assumptions (Things that must be in place before
something can happen) that is state or not stated within the clarified requirement.

 Then expose every possible logic defect (fault) or omission in the clarified requirement.

 Identify what are the exceptions (bad things) that will arise if the defects are not corrected.
 Find a way to test for all the possible each exception. Only when you can test for an exception can you
be able to stop that exception from happening.

2. Formal Proof

This level studies the formal specification and retrieves the goals of the formal specific. Then fixed rules
are created and with these rules step by step instructions are listed to achieve the specified goals. This is
relatively cheaper but there are more task steps.

3. Model Checking
This level studies the formal specification and formal proof deliverables to make sure that the system or
software contains ALL possible properties to be able to handle all possible scenarios that could happen
for a given specification. This stage is beginning to be more expensive.

4. Abstraction

This level uses mathematical and physical models to create a prototype of the entire system for
simulation. This prototype is use to focus on the properties and characteristic of the system. This is the
most expensive formal method.

Integrity Level and Formal Method Stages

The integrity level decided by the organization will determine how deep to go into the Formal Method
stage. Remember that the deeper into the formal method means more time and resources thus more
cost will be incurred.

Reference List

The single best source of formal methods papers and the like is the World Wide Web Virtual Library On
Formal Methods. This page contains pointers to articles, textbooks and tools for formal design and
specification.

[Bowen93] Bowen & Stavridou: "Safety Critical Systems, Formal Methods And Standards.

An introduction to formal methods and their role in industry, and in safety-critical systems. An excellent
introductory paper which touches on most of the applications and controversy surrounding formal
methods.

[Bowen95] Bowen, Jonathan "Seven More Myths Of Formal Methods.

This paper is a review of Hall's paper "Seven Myths Of Formal Methods", with the addition of seven
other myths. Although the paper does not explicitly name it as such, the general design approach given
in this paper is a good description of the lightweight approach to formal methods.

[Easterbrook98] Easterbrook, Steve et al. Experiences Using Formal Methods for Lightweight
Requirements Modelin