Lecture 1: Course Introduction

Formal Methods of S/W Development

Dr. Saif U. R. Malik

Assistant Professor
Formal Methods (FMs)
 What are Formal Methods?
Rigorous mathematically-based techniques and tools for
the specification, development, and verification of software
and hardware systems.

 Why Formal Methods?

 They lead to zero defect software… NO!
 They are better than testing… NO!
 They prove that computer scientists are highly skilled
mathematicians… NO!
2
The Myths
 Hence you should know the myths1:
1. FMs can guarantee software is perfect
2. FMs are all about program proving
3. FMs are only useful for safety-critical systems
4. FMs require highly trained mathematicians
5. FMs increase the cost of development
6. FMs are unacceptable to users
7. FMs are not used on real, large scale software

3
1. Anthony Hall ‘90, Seven Myths of Formal Methods
The Reality
Very Low Defect Rates (But Not Zero)

4
1. Anthony Hall ‘05, Realizing the Benefits of Formal Methods
The Reality (cont’d)
cost of correcting a requirements defect according
to the stage at which it is discovered

5
The Reality (cont’d)
 Fallible
 Proofs are no more a guarantee of correctness than
testing, in many cases far less of one.

 Cost Effective
 Lead to early error discovery… How?
 This reduces the overall costs… again How?

 Straightforward Math
 To write a formal specification in Z requires basic
knowledge of set theory and logic… (high-school)
6
Software Development
 Definition (Process)
 The process by which user needs are translated into a
software product. This involves translating user needs
into software requirements, transforming the software
requirements into design, implementing the design in
code, and testing the code2. (5/5 points)

 Key Activities: Reqs. Analysis, Design, Implementation,

Validation & Verification (V&V)
Each produces an artifact (i.e., document, code, or data)
7
2. IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology
Requirements Analysis
 Studying user needs to arrive at a definition of system,
hardware, or software requirements2.

 Describes the functionality of the software, and constraints

(non-functional) on its operation

 Strives to create a description of the system that is correct,

complete, consistent, unambiguous, and verifiable.

 Artifact:
 Requirements Specification
8
Design
 Defining the architecture, components, interfaces, and
other characteristics of the system2.

 Aims to produce a solution to the problem, using the

requirements specification as input.

 Involves evaluating different options (trade-offs) and

looking at different views (models) of the system

 Artifact:
 Design Specification
9
Implementation
 Coding… i.e., transforming the logic and data from the
design specification into a programming language.

 OO transformations include mapping:

 class associations to source code using references
 contracts to exception raising/handling mechanisms
 entity objects to tables in relational databases.

 Artifact:
 Source Code
10
Validation & Verification (V&V)
 Validation: evaluating a system/component during or at
the end of the development process to determine whether
or not it satisfies specified (user) requirements.

 Verification: evaluating a system/component to determine

whether the products of a given development phase satisfy
the conditions imposed at the start of that phase

 Artifacts (Data):
 Testing: Test Cases (Item Pass/Fail and Code Coverage)
 Model Checking: Properties (Witness/Counterexample)
11
Software Process Models
 Activities may overlap depending on process model:

 Waterfall
 V-Model
 Spiral Model
 Incremental Development
 Unified Software Development Process (USDP)

12
Waterfall Model (Royse ‘70)

Requirements
Definition
System and
software design
Implementation
and unit testing
Integration and
system testing

Operation and
maintenance

13
V-Model (Jenson & Tonies ‘79)
Requirements Acceptance
Specification test

System and
System design
integration test

Detailed Design Unit Test

Horizontal lines denote

The information flow
Implementation
between activities at the
same abstraction level.
14
15
Incremental (Mills ‘80)

Define outline Assign requirements Design system

requirements to increments architecture

Develop system Validate Integrate Validate

increment increment increment system
Final
system
System incomplete

16
Spiral Model (Boehm ‘87)
Design objectives, Evaluate alternatives,
alternatives, & constraints identify & resolve risks
Risk
analysis

Risk
analysis
Risk
analysis
Prototype
3
Prototype
Prototype Not shown
2
1
Requirements Concept of in detail
plan operation S/w Detailed
Sys.
Reqs. Design
Product
Design
Development Reqs.
Plan Validation Code

Integration Design
Unit Test
Plan Validation

Integration
Acceptance & Test
Test
Plan next phase Develop & verify
next level product
17
Unified Software Development Process

System
Development

Analysis model
specified by Process is use
case driven!
realized by Design model

Use case
distributed by
model Deployment model
All models are related
implemented by through traceability
Implementation
model dependencies.
Requirements verified by
captured as a
set of use Test model
cases. 18
What to Expect…
 In this course you will be exposed to:
 Formal Specification
 Formal Verification
 Using Formalisms to Support Design and Testing

 Reading Assignment
 A. Hall – Seven Myths of Formal Methods

19