Formal Methods in Software

Engineering
Bilal Khan
Instructions
 What are the formal methods?
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.

OR

What are Formal Methods?

Formal methods are techniques used to model complex systems as mathematical entities. By building a
mathematically rigorous model of a complex system, designers can not only verify the system’s properties in a
more thorough fashion (than they could via empirical testing) but also use mathematical proof as a complement to
system testing so as to ensure correct behavior.
 Formal Method
• Formal method is branch of software engineering, in which we analyze software systems.

• Develop a program in a way that each step leads to a final solution, follow proper method to make sure that
we do not take wrong steps.

• The Encyclopedia of Software Engineering defines formal methods in the following manner:

– 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.
 What are the formal methods? …

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. 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. In contrast, once a theorem is proven true it
remains true.

It is very important to note that formal verification does not avoid the need for testing. Formal verification cannot
fix bad assumptions in the design, but it can help identify errors in reasoning which would otherwise be left
unverified. In several cases, engineers have reported finding flaws in systems once they reviewed their designs
formally.
 What are the formal methods? …

Roughly speaking, formal design can be seen as a three step process, following the outline given here:

1. 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.
 What are the formal methods? …
2 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.

3 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.
 What are the formal methods? …

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.

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.

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.
 Importance of formal methods in Software
This is what we are going to study in formal methods.

 Methods to ensure that software is

 Correct
 Reliable

 These two attributes deal with the software quality.

 To achieve software quality, we apply different techniques.
 Testing
 Verification
 Validation
 Revise Software Development
When creating a software there are few engineering stages that is normally be followed to ensure that they
software is built within the time and budget. These stages collectively are called the software development life
cycle (SDLC).
The SDLC can be divided into seven (7) stages

1. Initial Study
2. Analysis
3. Design
4. Development
5. Testing
6. Implementation
7. Review
 Revise Software Development

1. Initial Study
This is the first time the system development team meets the clients to collective information regarding the
problem. Normally this stage delivers the proposal and quotation to the clients.

2. Analysis
After the client has agreed to the proposal and price, the team will go in and study the current system with the
intention to discover the source of the problem. The System analyst will use diagrams and data collection
techniques (observation, inspections, interview, etc) to aid them. Normally this stage delivers a report stating the
source of the problem and more then one alternative solutions.

3. Design
After the client agrees with the analysis findings, the client will choose one (1) solution. From this one solution the
system designer will create the specification. Take note that different IT section will require different specification.
For the software section, the deliverables will take the form of a screen design, logic design, representation of the
codes, etc.
 Revise Software Development

4. Development
Base on the given specification, the respective IT section will develop the solution. For the software section, the
deliverables will be a full running software program created from the specification.

5. Testing
The test documents (Test Plan and Test Case) are normally created by the System Analyst during the development
stages. The tester (normally a 3rd party) will use the Test Plan and Test Case to complete the testing. The
deliverables will be a letter from the tester stating the outcome of the test.

6. Implementation
At this stage onward the software is no longer a concern, the main objective now will be to prepare the
environment. The implementation plan will list the tasks necessary to prepare the environment to accept new
software, such as installation, training, conversion of data, change over method, etc. There are many deliverables
here depending on what is listed in the implantation plan. For example for user training a user manual is normally
created.

7. Review
This is the final stage where the software user and team will sit down to review the software performance and to
decide negotiate on the maintenance contract. If all goes well normally but not necessary a sign off letter will be
the last deliverables.
 Formal Method
Formal method is a way to takes the specification (written in natural language) and converts it into its
mathematical equivalent. Thus it is normally used in the SDLC Analysis and Design stages. The natural language
usually contains ambiguous, incomplete and inconsistent statement.

Once a specification in English for example is translated to a mathematical form, it will remove all ambiguity and
uncertainty in that statement.

Formal method will also bring to light all different probable perspective to any given variables and functions that
could have been hidden behind the English language.

This can be done using a number of formal languages such as Z notation, VDM, Algebra, Functional Programming,
etc.

Creating software need not use formal method, having said that, having formal method imbedded into the SDLC
does give the software huge advantages and also a new set of disadvantages .
 Formal Method

Advantage of formal method

Formal Method forces the System Analyst and Designer to think carefully about the specification as it enforce
proper engineering approach using discrete mathematics.

Formal Method forces the System Analyst and Designer to see all the different possible states for any given
variables and functions thus will avoid many faults and therefore reduces the bugs and errors from the design
stage onward.

Disadvantage of formal method

Formal Method requires the person to know how to apply discrete mathematics. It will obviously slow down the
analysis and design stage resources and time therefore also the cost of the project.

There are too many different formal methods and most of them are not compatible with each other.

Formal methods do not guarantee that a specification is complete. For each variable and function, it just forces
the System Analyst and Designer to view the specification from a different perspectives but it does not guarantee
that variable and functions will not be left out.
 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

2. Mission Critical System
3. Safety Critical System
 Critical software

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.
 Integrity Level
Integrity level refers to how much cost is an organization is willing to spend and how much risk is an organization is
willing to take when developing software.
 Stages in Formal Method
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.

1. Get user requirement usually from the specification written in the natural language.
2. Clarify the requirement using mathematical approach. This is to remove all ambiguous, incomplete and
inconsistent statement.
3. 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.
4. Then expose every possible logic defect (fault) or omission in the clarified requirement.
5. Identify what are the exceptions (bad things) that will arise if the defects are not corrected.
6. 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.
 Stages in Formal Method

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.
 Problems in Software System
The information technology industry is highly complex, vast and dynamic. Software development is an
integral part of the industry and is directly influenced by several factors, including growing complexities,
market conditions, changing technology trends as well as increasing software development challenges.

Software engineering teams in different domains and business landscapes face varied challenges. For
instance, software development projects are now increasingly governed by the “build once, deploy
everywhere” paradigm where a single application can run across numerous platforms. Further
complicating this issue is the need to integrate different programs and maintain support throughout the
product’s lifecycle. In addition, greater demands have been placed on software developers forcing them
to work within limited timelines and limited budgets.

In order to drive efficiency in your software development projects and enhance the reliability of your
software development initiatives, it is important to understand the major challenges in software
development and devise a systematic roadmap to cope with every challenge.
 Problems in Software System …
1. Incorrect calculations - This is seen in functions such as financial and date calculations. The key
determinant is whenever mathematical functions and mathematical operators are involved.

2. Incorrect data edits - This is when the software does not apply existing data edits correctly. For
example, a data edit may be coded to prohibit the entry of the day of the month greater than "31", but
does not allow for the month. This would allow the entry of February 30 and other invalid dates.

3. Ineffective data edits - This is when data edits are in place and working correctly, yet still fail to
prevent incorrect data from being entered into the system. An example of this is an alphanumeric
address field that allows spaces to be entered before any numbers or letters in the address. Therefore,
when searches or sorts are performed on the address field, the search or sort may not find the intended
address.

4. Incorrect coding/implementation of business rules - This refers to the one of the most common sources of
software problems - the mistakes that occur between what is intended to be developed or implemented and what
is actually delivered. These defects can be traced back to incorrect, missing, or vague system requirements
specifications, or to the misinterpretation of requirements specifications. If you are asking, "What specifications?
What requirements?", the incorrect coding or implementation of business rules is probably a common problem
for you.

5. Inadequate software performance - This refers to slow system response times and transaction throughput
rates.
 Problems in Software System …

6. Confusing or misleading data - This means that the data shown to users may be correct, but the
users might not fully understand how to interpret the data. This is not a trivial problem. Lives have been
lost because of someone's failure to take the correct actions based on the data delivered to them from a
computer system.

7. Software that is difficult to use - Many people have experienced first-hand the frustration of using
software that is cumbersome, difficult to navigate, and requires several steps to perform simple tasks.
This problem relates to a lack of understanding of how humans interact with computers and is also the
result of a history of modifications that are not planned and coordinated to account for ease of use. For
example, the addition of numerous workarounds over a period of time in legacy systems can have the
overall effect of convoluting the original system design.

8. Obsolete software - Software that no longer works due to new hardware or support software changes
- This refers to software that is based on functions found in older versions of databases and operating
systems. An example of this can be found in old COBOL code that will not compile on new compilers due
to the use of verbs that are no longer supported in the compiler. Many vendors try to make new releases
of support software upwardly compatible, but there are usually cases where one minor area of non-
support from the base system can cause a major revision of the system. The only other option is not to
upgrade the support software. This decision can be justified for the short-term, but a point is usually
reached where the software must either be replaced or modified.
 Problems in Software System …

9. Inconsistent processing - Software that only works correctly in one environment – This refers to
software that has been designed for only one environment and cannot be easily transported and used in
another environment. Of course, some software is designed to work in only one environment. However, if
an organization adopts new technology that requires software be portable to new environments, then the
software will need to be modified or replaced if it can't meet the new technical requirements. An example
of this is software that works in an MS-DOS environment, but will not work in a Microsoft Windows
environment.

10. Difficult to maintain and understand - This refers to the ability of a programmer or developer to
maintain the software. To maintain software, the person performing the maintenance must first analyze
and understand the software. Much of the software in existence today was initially written in an
unstructured manner and then patched on an as-needed basic over a long period of time. This type of
software structure results in what is known as "spaghetti code," which is complex and unstructured. To
add to the problem, when changes are made to this kind of software, there is a higher risk of creating
new defects unintentionally.

11. Unreliable results or performance - This means that the software does not deliver consistently
correct results or cannot be depended to work correctly each time it is used.
 Problems in Software System …

12. Inadequate support of business needs or objectives - This refers to software that is inflexible to
meeting business needs. For example, a system may be difficult to modify to meet and organization's
needs or may lack features to allow the users to customize business rules.

13. No longer supported by the vendor - This occurs when a vendor ceases to support a particular
software product. This can occur due to the vendor's decision to no longer support a product, due to the
vendor going out of business, or the vendor selling the product to another vendor.

14. Incorrect or inadequate interfaces with other systems - This means that the software does not
correctly accept input (data, control, parameters, etc.) from other systems or sends incorrect output
(data, control, parameters, print, etc.) to other systems. An example of this is when a system has an
electronic data interfaces (EDI) with external systems, but does not correctly receive or format the
information.

15. Incorrect matching and merging of data - This refers to situations where data is obtained from one
source and matched or merged with data from another source. Examples include sorting multiple files
into a single file or table or matching data from a master file to an ID number entered as a lookup entry.
 Problems in Software System …

16. Data searches that yield incorrect results - This means that a search retrieves incorrect data as
the result of a search. In the worst case situation, the data retrieved appears to be correct in format, but
only by tracing back to source documents and other original data can it be determined that the data is
incorrect for the search criteria. An example of this would be searching for the time worked by a particular
employee in a payroll system. The employee's name at the top of the information may be displayed
correctly, but the detailed time data may belong to another employee. The only ways to verify the
information would be to compare the time worked back to time sheets or to tables that indicate the
employee ID.
17. Incorrect processing of data relationships - This means that data relationships are not created or
maintained correctly between one or more data elements. These data elements can reside on interactive
interfaces, reports, or files. For example, a system may allow a user to incorrectly enter a telephone area
code invalid for the state specified in an address field.
18. Incorrect file and data handling - This refers to the software incorrectly retrieving data from files or
tables. This could include retrieving the wrong data from the right source or the right type of data from the
wrong data source. An example of this would be retrieving data from an old version of a file or table,
thinking the data is being retrieved from the most current version. Another example is the inability of the
software to process empty or full files correctly.
A secondary problem could relate to the software's inability to pass data correctly through the system. An
example of this would be the incorrect processing of transactions, where data is inadvertently dropped
during processing.
 Problems in Software System …
19. Inadequate security controls - This means that unauthorized access to the system is not
adequately controlled and detected. In addition, people may also be able to perform transactions in
excess of the authorization levels appropriate for their job functions. For example, a person without
managerial levels of security access might be able to approve their own overtime. Or, a person not in the
payroll department might be able to view the employee payroll files.

20. Inability to handle production data capacities - This refers to the software's inability to process
data at the level required by the organization. An example of this would be a system that is required to
process financial transactions that exceed $10 million, but the system can only process amounts up to
$9,999,999.99. Another example is the classic case of the Year 2000 computing problem, where dates in
the Year 2000 and beyond are incorrectly recognized as being in the early 1900's.

If you developed test cases to address each of these problems, you would have a huge challenge to
cover all of them completely. Like everything else in testing, looking at relative risk and the situation at
hand will narrow your focus. One approach would be to design a risk questionnaire for each problem
area. Another method would be to interview users to assess the risk impact. A third technique would be to
study past defect reports and correlate them to each of the problem areas, giving the highest priority to
the most troublesome areas.
 How Formal Methods are developed?
• We develop models of system.
• With the help of models we will argue and prove correctness of models.
• What is a model?
– An item, a structure, a style,….
– Lets play Dijkstra’s game to define a model.
 Dijkstra’s Game
 Consider the following game to be played by a single person with an urn/jar and as many w white
balls and b black balls as he needs.
 To begin with, an arbitrary positive number of balls is put into the urn and as long as the urn
contains two or more balls, the player repeats the following moves:
 He shakes the urn and, without looking, he takes two balls from the urn;
 If those two balls have the same color
 he throws one black ball into the urn,
 otherwise he returns one white ball into the urn
 Because each move decreases the total number of balls into the urn by 1, the game is guaranteed to
terminate after a finite number of moves and it is not difficult to see that the game ends with exactly 1 ball in
the urn.
 The question is:
 What can we say about the color of the final ball when we are given the initial contents of the urn?’”
Dijkstra’s Game …
 Dijkstra’s Game …

• What is the color of last ball?

• Difficult to answer
• Lets play the same game with different number of balls.
 Dijkstra’s Game …

• Mathematical models use functions.

• What is a function?
• Putting the balls in jar is a function
 Dijkstra’s Game …

Conclusion from 2 and 3 balls game

• Depends on parity of white balls, even or odd parity.

• Even number of white balls, last ball is black color.
• Odd number of balls, last ball is of white.
• If we play with 100 balls, then can we argue or prove our hypothesis?
• What is the color of last ball, given w white balls and b black balls?
 Dijkstra’s Game …

Mathematical model and its proof

F(b,w)=
2 black out,1 black in b-2+1, (b-1,w)
We reduce the number of black balls by 1 and we maintain the number of white balls.
2 white out,1 black in w-2,b+1
We reduce the number of white balls by 2 and increase the number of black balls by 1.
1 of each out,1 white in b-1,w-1+1,(w)
we reduce the number of black balls by 1 and maintain the number of white balls.
 Total number of balls removed in each move is 1.
 Parity(even/odd number) of whit balls does not change.
 Yes we will say the parity of white balls determine the outcome of the game.
 Hence hypothesis is correct.
 Formal method steps
 We will define state based model for our computer programs using formal methods.
1. Define the specifications of the system(Formal specification).
2. Define abstract model specifications.
 Define the states of system (steps of a model)
 Define invariant(condition)
 Define set of operations for model to function.
 System/model operation is associated with two conditions
 Pre-condition
 Post condition
 Model verification and Implementation
 Make formal model and use tools to prove mechanically that formal execution model satisfies formal
requirements.
Written Requirement
Informal requirements expressed in English:
 A tank of cooling water shall be refilled when its low level sensor comes on. Refilling
consists of adding 9 units of water to the tank.
 Notes:
> The maximum capacity of the tank is 10 units of water.
> From one reading of the water level to the next reading of the water level, 1 unit of water will be used.
> The low level sensor comes on when the tank contains 1 unit of water or less.
 Assigning Types
• The above statement contains several descriptions, including two key notions:

The water level in the tank and the water usage. Formally, these notions can be modeled as follows (statements 1
and 2):

1 level is represented by a restricted integer type: a number between 0 and 10, inclusive

2 usage is represented as the integer constant 1

• That is, level describes an amount of water that the tank may hold at any point in time and usage describes the
amount of water used during one cycle.
Function Description
• The primary requirement is that 9 units of water will be added to the tank whenever the level is less
than or equal to 1. This can be more precisely stated as (statement 3):

3 Function fill takes, as input, a water level and returns, as output, a water level. Given an input of Lvl
units of water, fill returns Lvl +9, if Lvl is one or less, otherwise it returns Lvl.

• That is, we claim that fill(Lvl) accounts for any filling of water in the tank.
 Properties
• A common sense property of this system is that, at the next cycle, the new water level will be the current water
level, plus any amount that was added, minus the amount that was used. That is, given Lvl as the current level of
water, the level at the next cycle should be given by statement 4:

4 level = Lvl + fill(Lvl) - usage

• One approach to checking this specification is to ensure that each reference to a level of water is consistent with
the definition of level, i.e., it should always be a number between 0 and 10. It turns out that the specification for
fill given in 3 above is consistent with the definition of level if the following two logical statements are true:

5 FORALL levels Lvl

(Lvl <= 1) IMPLIES THAT
(0 <= Lvl + 9) AND
(Lvl + 9 <= 10)
6 FORALL levels Lvl
(0 <= Lvl + fill(Lvl) - usage) AND
(Lvl + fill(Lvl) - usage <= 10)
Analysis by Proof
• The following statements (statements 5.1 and 5.2) constitute an informal proof that the first FORALL
statement (statement 5) is true:

• Property: “5” FORALL levels Lvl (Lvl <= 1) IMPLIES THAT

(0 <= Lvl + 9) AND (Lvl + 9 <= 10)

• Proof:
5.1 Lvl+9 >= 0 because Lvl >= 0 (and the sum of any two numbers greater than zero is greater t han zero)

5.2 Lvl+9 <= 10 because Lvl <=1 (and any number less than or equal to 1 plus 9 is less than or equal to 10)
 Verification of Property #6?

• Property “6” FORALL levels Lvl

(0 <= Lvl + fill(Lvl) - usage) AND
(Lvl + fill(Lvl) - usage <= 10)

• Proof Attempts Fails!

• Counter-example*
– Consider the case when Lvl is 9:
Lvl + fill(Lvl) - 1 = Lvl + Lvl -1 = 9+9-1 = 17 (which is not <= 10)
• The specification is flawed and must be corrected.
Correcting the Specification
• Upon closer examination, it is found that statement 4, our expression for the water level at the next
cycle, is in error:
4 level = Lvl + fill(Lvl) - usage (incorrect)

• This statement is inconsistent with the definition of fill because fill returns the new level of water, not
just the amount of water added.
The (corrected) expression for level, denoted by 4', is simply:
4' level = fill(Lvl) - usage (correct)
• The (corrected) FORALL statement (statement 6) is:
6' FORALL levels L:
(0 <= fill(Lvl) - usage) AND
(fill(Lvl) - usage <= 10) (correct)
This Simple Example Illustrates:
• Formal Specification: Modeling informal English statements using mathematical expressions

• Type Checking: Checking that all types of items are used consistently (e.g., level)

• Stating Properties: Identifying and defining expected behavior of the system (e.g., the expected new
level in the tank)

• Proving Logical Conditions: Constructing logical proofs which show that a given condition holds under
all possible situations