This document discusses formal methods in software engineering. It begins by defining formal methods as mathematically-based techniques for specifying, developing, and verifying systems properties in a systematic way. The document then provides an example of using formal methods to specify the behavior of a cooling water tank system. Key steps include: 1) defining types and functions mathematically, 2) stating properties to check, 3) attempting to verify properties through proof, 4) finding a counter-example, and 5) correcting flaws in the specification.

1. FORMAL METHODS IN SOFTWARE
ENGINEERING
NDZE REGINA KUKIWIN
Uba20S0900
FS, Math and C.S
CSCS5102 – Software Engineering 2

2. FORMAL METHOD DEFINITION
• 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.

3. FORMAL METHOD CHARACTERISTICS
• Correctness, the property that an abstract model fulfills a set of
well defined requirements.
• Consistency, to be consistent, facts stated in one place in a
specification should not be contradicted in another place.
• Used to specify programs, what the system is suppose to do.
• Used for constructing programs.
• Used to verify the program.

4. WHY FORMAL METHODS ARE REQUIRED
⚫History of software
⚫Softwares encountered notorious bugs that were the
cause of financial lose and deaths of many people.
⚫Famous bugs are
⚫Therac-25
⚫ Computerized radiation therapy machine called the Therac-25. Killed
many people, controller could not stop radiation due to software bug.
⚫AT & T long distance breakdown bug 1990
⚫ Ill placed break statement in the code, caused the 1/3rd of entire
American network to go down for 9 hours.

5. WHY FORMAL METHODS ARE REQUIRED
– Patriot Missile Failure Gulf war
• This missile hit the own American troops a software
defect in 1991. Killing 28 people and many injured
– Pentium bug
• Software error in microcode of Pentium
microprocessor, which resulted in error of floating point
calculation problems. Intel had to take back all the
Pentiums, and it caused huge loss.

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

7. TESTING
• Black box testing
– Test input versus output
– Input
• Two numbers
– Output
• average
• White box testing
– Test the structure of program.
• Loops testing, condition testing

8. "TESTING CAN SHOW THE PRESENCE OF ERRORS,
BUT NOT THEIR ABSENCE."
- Edsger Dijkstra

9. TESTING
CONTD..
• In testing we develop test cases and define
scenarios, it is not possible to have all
scenarios .
• Program to show equalness of two strings.
• isEqual(“cat”,”dog”) expected false
• isEqual(“testing”,”testing”) expected true
• isEqual(“house”,”home”) expected false
• isEqual(“house”,”mouse”) expected false.

10. 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,….

11. EXAMPLES OF FORMAL AND SEMI-
FORMAL MODELS
Formal Models:
State Machines: A formal model that represents the
behavior of a system through a set of states and transitions
between them. State machines can be represented using
formal languages like Finite State Machines (FSM) or Petri
Nets.
Mathematical Logic: Formal models using mathematical
logic, such as propositional logic, predicate logic, or
temporal logic, to specify properties, constraints, and
relationships within a system.

12. EXAMPLES OF FORMAL AND SEMI-
FORMAL MODELS
Semi-Formal Models:
Use Case Diagrams: A semi-formal model used in software engineering
to represent the interaction between system components and external
actors. Use case diagrams provide a high-level view of system
functionality and user interactions.
Entity-Relationship (ER) Diagrams: Used in database design to
represent the relationships between entities and their attributes. ER
diagrams help visualize the structure and dependencies within a
database.
Data Flow Diagrams (DFD): Used to represent the flow of data within a
system. DFDs show how data is input, processed, and output by
different system components, helping to identify potential bottlenecks or
inefficiencies.
UML Class Diagrams: Used in object-oriented design to represent the
structure and relationships between classes in a system. Class
diagrams depict the attributes, methods, and associations between
classes, aiding in system understanding and design.

13. FORMAL METHOD
STEPS
Problem Identification: The first step is to clearly define the problem or
objective for which formal methods will be applied. This involves
understanding the requirements, constraints, and desired properties of the
system or software being developed.
Formal Specification: A formal model or specification is created to describe
the behavior, structure, or properties of the system. This can involve using
formal languages, mathematical logic, or other formalisms to precisely define
the system's characteristics.
Verification: Once the formal specification is established, verification
techniques are applied to ensure that the system or software meets its
specified requirements. This can involve various methods such as model
checking, theorem proving, or static analysis to formally verify properties like
correctness, safety, or reliability.
Validation: In addition to verification, validation aims to assess the suitability
and correctness of the formal model in capturing the intended system
behavior..

14. FORMAL METHOD
STEPS CONT..
Refinement: In this step, the formal model may undergo refinement to
address any issues or gaps identified during verification or validation.
Code Generation: Once the formal model is refined and validated, code
generation may be performed to transform the formal model into executable
code eg with Alloy.
Implementation and Testing: The generated code is implemented and
integrated into the target system or software. This is followed by rigorous
testing to validate the behavior and functionality of the implemented system,
ensuring it aligns with the formal specifications.
Maintenance and Evolution: After the system is deployed, ongoing
maintenance and evolution are necessary to address any issues, incorporate
updates or changes, and ensure the continued correctness and reliability of
the system.

15. 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.
e F

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

17. FUNCTION DESCRIPTION
• The primMaertyhordesquxirementis 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.

18. 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
e

19. PROPERTIES (CONTINUED)
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)

20. ANALYSIS BY PROOF
• Property: “5” FORALL levels Lvl (Lvl <= 1) IMPLIES THAT
(0 <= Lvl + 9) AND (Lvl + 9 <= 10)
• Proof:
1. Lvl+9 >= 0 because Lvl >= 0 (and the sum of any two numbers greater than
zero is greater than zero)
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)
The following statements constitute an informal proof that the first
FORALL statement (statement 5) is true

21. VERIFICATION OF PROPERTY #6?
• Proof Attempts Fails!
• Counter-example*
– Consider the case when Lvl is 9:
Lvl + fill(Lvl) - 1 = Lvl + Lvl -1 = 9+9-1 = 17
• Property “6” FORALL levels Lvl
(0 <= Lvl + fill(Lvl) - usage) AND
(Lvl + fill(Lvl) - usage <= 10)
(which is not <= 10)
• The specification is flawed and must be corrected.
e Formal Me ample

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