Lecture 2

SDLC and Formal Methods

Formal Methods of S/W Development

 Quick Revision: Last Lecture

The peculiarity of software systems

Tiny faults can have catastrophic consequences
 Software seems particularly prone to faults:
– Ariane 5
– Mars Climate Orbiter, Mars Sojourner
– London Ambulance Dispatch System
– Denver Airport Luggage Handling System
– Pentium-Bug
– (more at http://www5.in.tum.de/~huckle/bugse.html)

2
 Achieving Reliability in Engineering

Some well-known strategies from civil engineering:

 Precise calculations/estimations of forces, stress, etc.
3  Hardware redundancy (“make it a bit stronger than
 necessary”)
 Robust design (single fault not catastrophic)
 Clear separation of subsystems (any airplane flies with
 dozens of known and minor defects)
 Design follows patterns that are proven to work
Why this does not work for software
 Redundancy as replication doesn’t help against bugs
 Redundant SW development only viable in extreme
cases
 No physical or modal separation of subsystems
 Local failures often affect whole system
 Software designs have very high logic complexity
 Most SW engineers untrained in correctness
 Cost efficiency more important than reliability
 Design practice for reliable software is not yet mature
4
HOW TO ENSURE SOFTWARE CORRECTNESS?

A Central Strategy: Testing

Testing against inherent SW errors (“bugs”)
 Design test configurations that hopefully are representative and
 ensure that the system behaves as intended on them
Testing against external faults
 Inject faults (memory, communication) by simulation or
 Radiation
Limitations of Testing
Testing can show the presence of errors, but not their absence
(exhaustive testing viable only for trivial systems)
Representativeness of test cases/injected faults is subjective
How to test for the unexpected? Rare cases?
Testing is labor intensive, hence expensive

5
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!
6
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

1. Anthony Hall ‘90, Seven Myths of Formal Methods 7

The Reality
Very Low Defect Rates (But Not Zero)

1. Anthony Hall ‘05, Realizing the Benefits of Formal Methods 8

The Reality (cont’d)
cost of correcting a requirements defect according
to the stage at which it is discovered

9
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)
10
Assignment 1
Write brief summary of myths of Formal Methods:
 A. Hall – Seven Myths of Formal Methods
(Handwritten hardcopy submission is required in the
next class.)

11
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 code.

 Key Activities: Reqs. Analysis, Design,

Implementation, Validation & Verification (V&V)

Each produces an artifact (i.e., document, code, or data)

2. IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology 12
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
13
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
14
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
15
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)
16
Software Process Models
 Activities may overlap depending on process model:

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

17
Waterfall Model (Royse ‘70)

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

Operation and
maintenance

18
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.
19
Spiral Model (Boehm ‘87)
Design objectives, Evaluate alternatives,
alternatives, & constraints identify & resolve risks
Risk
analysis

Risk
analysis
Risk
analysis
Prototype
3
Prototype
Prototype
1
2 Not shown
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

Plan next phase Test

Develop & verify
next level product
20
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

21
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. 22
 In this course you will be exposed to:
 Formal Specification
 Formal Verification
 Using Formalisms to Support Design and
Testing

23
What is a Specification?
 Intermediate product of software development process

Two Types of Specifications

Differences?

Specification impacts Design and Implementation

24
Also viewed as a…
 Basis for Ensuring Correctness
 Correctness defined as product satisfies its specification
 Established by V&V, i.e., impacts testing and verification

 Contractual Agreement
 Client signs off on the SRS

 Means of Communicating Ideas

 Provides a high-level description or big picture
 Acts as a reference point for different stakeholders
25
Desirable Features (Content)
The contents of a specification should be:
 Correct – accurately represents the needs of the user

 Consistent – contains and derives no contradictions

 Complete – covers all possible scenarios and error cases

 Unambiguous (Precise) – provides exact descriptions that

have exactly one meaning, neither more nor less.
 Verifiable – allows specification to be checked to determine
whether or not it satisfies (meets) predefined criteria
26
Desirable Features (Content)
Describes software systems and therefore…
 Structural – captures hierarchical and user relationships
 Behavioral – addresses required functionality and non-
functional aspects such as fault tolerance, safety, security

What about the specification language itself?

What are desirable characteristics of a language?
What is the most important characteristic?
27
Desirable Features (Language)
 Understandability – purpose of a language is to facilitate
communication. For software must handle complexity.

Features that make a language (more) understandable?

 Graphical – visual notations such as diagrams
 Hierarchical – different levels of abstraction
 Composable – divide and conquer

 Expressive – powerful and meaningful descriptions

 Analyzable – amenable to machine manipulation

28
Specification Languages
 Specification languages (like all languages) have a
syntax and semantics

 Syntax provides a set of symbols and a set of grammatical

rules for combining those symbols into sentences; while
semantics ascribe meaning to them.

 A specification language may be classified according to its:

 Foundation – basis upon which it was created
 Applicability – expressiveness for different system
types
 Style – format of notation or representations used. 29
Classifications
1. Foundation
 Informal – Natural Language
 Formal – Z, Petri Nets, Temporal Logic
 Semi-Formal – UML Diagrams

2. Applicability
 Sequential – one thread of control
 Concurrent – multiple threads of control
 Real-Time – time critical
 Hybrid – discrete and continuous
30
Classifications (cont’d)
3. Style
 Model-Oriented – explicitly defines states and state
sequences; concrete and useful for implementation
 Property-Oriented – assertions on state sequences
without explicitly writing them out; more abstract

What styles are these:

Z, Finite State Machines, CTL, Petri Nets, LTL

31
 Informal Specification: Natural Language
Example Informal Specification
___________________________ A Better way
________________________
__

______________________________________

32
Formal Methods

33
Formal Specification
 Formal specification is the use of mathematical
notation to precisely describe what properties a system
should have, without unduly constraining how to achieve
them.

 Engineers that use formal specification techniques are

faced with the challenge of developing a “complete”
system description that is free of implementation bias.

 Using mathematical data types for modeling allows the

abstraction away from computer representation,
while providing a rich collection of laws for effectively
reasoning about how the specified system will behave 34
Formal Spec. Languages
 A Formal Specification Language (FSL) provides the
sound mathematical basis for a formal method.

 Definition: An FSL is a triple where,

and are sets and

is a relation between them.

 Syn is the syntactic domain of the language

Sem is the semantic domain and
Sat is its satisfies relation.

Jeannette M. Wing ‘90, A Specifier’s Introduction to Formal Methods 35

Formal Spec. Languages (cont’d)
 FSLs provide a notation (syntactic domain), a universe of
objects (semantic domain), and a precise rule defining which
objects satisfy each specification.

 A specification is a sentence written in terms of the syntax,

and an object satisfying a specification is a specificand.

 Each programming language with a well-defined semantics is an

FSL, but reverse is not true. Why?

 Programmers cannot escape formal methods! Question

is whether they will work with informal requirements and
formal programs, or use formalisms in reqs. specification
36
Examples of FSLs
 Z (pronounced “Zed”) is based on set theory and first-
order predicate logic. Can be used in both model-oriented
and property-oriented styles. Applies to sequential
systems.
 Petri Nets are graphical notations for distributed systems.
They follow a model-oriented style and have operational
semantics (executable). Applicable to concurrent systems.
 Temporal Logic is used to describe and reason about
propositions qualified over time. It is property-oriented,
and highly abstract. Applicable to concurrent systems.
 Others: VDM, Larch, Concurrent Sequential Processes 37
In this segment of the course…
 Z – Under a Model-Oriented Style
 Low-Level Petri Nets – Place Transition Nets
 Computational Tree Logic* – Includes LTL and CTL

Reading Assignment:
 Introduction Chapter
J. Wing – A Specifier’s Introduction to Formal Methods

38