2008 Spring

Software Special
p Development
p 1

Introduction to Formal Methods

P
Part I : FFormall S
Specification
ifi i

JUNBEOM YOO
[email protected]
Reference

• “AS
Specifier’s
ifi ’ IIntroduction
d i to FFormall M
Methods
h d ”
– Jeannette M. Wing, Carnegie Mellon University
– IEEE COMPUTER, 1990

Konkuk University 2
Contents

• Overview
O i off FFormall M
Methods
h d
• Formal Specification Language
• Pragmatics
• Some Examples
• Bounds of Formal Methods
• Concluding Remarks

Konkuk University 3
Overview of Formal Methods

- Definition
- Features
- Applying Scope
- P
Pragmatic
ti C
Considerations
id ti

Konkuk University 4
Definition

• Formall M
F Methods
h d
– Mathematically based techniques for describing system properties
• Have a sound mathematical basis
• Typically given by a formal specification language

– Provide frameworks for systematically

y y
• Specifying,
• Developing, and
• Verifying systems

Konkuk University 5
Features

• F
Formal
l methods
h d provide
id means off precisely
i l d defining
fi i notions
i lik
like
– Completeness
– Consistency
– Specification
– Implementation
– Correctness

• Formal methods address a number of pragmatic considerations

– Who
– What
– When
– How it is used?
– ex) System designers use a formal method to specify a system’s desired
behavioral and structural properties.

Konkuk University 6
Applying Scope

• A stage off system d

Any development
l can make
k use off fformall methods
h d
1. Initial statement of a customer’s requirements
2. System design
3. Implementation
4. Testing
5. Debugging
6. Maintenance
7. Verification
8. Evaluation

• When used early,

– Can reveal design
g flaws
• When used later,
– Can help determine the correctness of a system implementation
– Can help determine the equivalence of different implementations

Konkuk University 7
Pragmatic Considerations

• P
Pragmatic
i considerations
id i
– A set of guidelines
– Formal methods should tell the user
1. Circumstances under which the method should and can be applied
2. How it can be applied most effectively

• Formal Specification
– One tangible product of applying formal methods
– More precise and concise than informal specifications
– A formal method’s specification language may have Tool Supports
1. Syntax analysis
2. Semantic analysis with machine aids

Formal Specification :
Use mathematics to specify the desired properties of a computer
system with support of automatic tools

Konkuk University 8
Formal Specification Language

- Definition
- S t ti D
Syntactic Domains
i
- Semantics Domains
- Satisfies Relation
- P
Properties
ti off S
Specifications
ifi ti
- Proving Properties of Specificands

Konkuk University 9
Definition

• F
Formal
l specification
ifi i llanguage:
< Syn, Sem, Sat >, where
y : syntactic
• Syn y domain
• Sem : semantic domain
• Sat : Sat ⊆ Syn ⅹ Sem
– syn is a specification of sem
– sem is a specificand of syn

• Considerations
– In principle, a formal method is based on some well-defined formal
specification language
– Formal specification language provides a formal method’s mathematical basis
– Formal methods differ because their specification languages have different
syntactic and/or semantic domains

Konkuk University 10
Syntactic Domains

• Syn
– a set of symbols
• Constants
• Variables
V i bl
• Logical connectives
– a set of grammatical rules for combining symbols into well-formed sentences
(semantics)
• Ex) ∀x.P(x) ⇒ Q(x) : correct!!
∀x.⇒ P(x) ⇒ Q(x) : wrong!!

– Visual Specification : Graphical elements are also available

• boxes, circles
• lines, arrows

– called Specification

Konkuk University 11
Semantic Domains

• S
Sem
– Formal specification languages differ most in their choice of
semantic domains (Specificand) such as:
• Ab
Abstract-data-type
t td t t specification
ifi ti llanguages
– algebra, theory, program
• Concurrent and distributed systems specification languages
– state sequence, event sequence, state and transition sequence
– stream, synchronization tree, partial order
– state machine
• Programming languages
– function from input to output, computation
– predicate transformation
– relation, machine instruction
– called Implementation

Konkuk University 12
Satisfies Relation

• S
Sat
– Specifies different aspects of a single specificand using different specification
languages:
1
1. Behavioral
B h i l specification
ifi ti aspectt
– Constraints on observable behavior of specificands
– System‘s required functionality (mapping from inputs to outputs)
– Others: fault tolerance, safety, security, response time, space efficiency
2. Structural specification aspect
– Constraints on the internal composition of specificands
– Various hierarchical and uses relations
– Call graph, data-dependency diagram, definition-use chain

Konkuk University 13
Properties of Specifications

• S
Specification
ifi i llanguage should
h ld bbe d
defined
fi d as
1. Unambiguous
• If and only if it has exactly one meaning
• Any
A natural
t l llanguages and d graphs
h are nott fformall iinherently
h tl
2. Consistent
• If and only if its specificand set is non-empty
• Cannot derive anything contradictory from the specification
• There is some implementation that will satisfy the specification
3. Complete
• Need not be complete in the sense used in mathematical logic
• Relatively-completeness properties might be desirable
• In practice, we must usually deal with incomplete specifications

• A specification has implementation bias if it places unnecessary constraints

on its specificand

Konkuk University 14
Proving Properties of Specifications

• M
Most fformall specification
ifi i llanguages h
have logical
l i l iinference
f systems
– Can prove properties from the specification about specificands
– Can predict system’s behavior without executing or building the system
– Can be mechanized
• Theorem proving
• Model checking
• called
ll d Formal
F lVVerification
ifi ti (P
(Partt II)

Konkuk University 15
 Pragmatics

Users
Uses
Characteristics

Konkuk University 16
Users

• 5 ki
kind
d off users
1. Specifier : write, evaluate, analyze, and
refine specifications
2 Customer
2. C t : hi
hired
d th
the specifiers
ifi
3. Implementer : realize a specification
4. Client : use a specified system
5. Verifier
f : prove the h correctness off implementations
l

• A formal method’s guidelines should identify

1. Different types of users the method is targeted for
2. Capabilities
p the users should have
3. Application domain of the method

Konkuk University 17
Uses

• Th greatest b
The benefit
fi comes
– from the process of formalizing
– rather than the end result

• Can apply formal methods in all phases of SW development

1. Requirements
q analysis
y
2. System design
3. System verification
4. System validation
5. System documentation
6. System analysis and evaluation

• These applications should be considered as an integral one, framework

Konkuk University 18
Uses 1 R
1. Requirements
i A
Analysis
l i

• F
Formal
l methods
h d hhelp
l clarify
l if customer’s
’ iinformally
f ll stated
d requirements
i
– Crystallize customer’s vague ideas
– Reveal
• Contradictions,
• Ambiguities, and
• Incompleteness in the requirements

• On the specification, both customers and specifiers can see

– Whether
h h iit reflects
fl customer’s iintuition
ii
– Whether specificand set has desired set of properties

Konkuk University 19
Uses 2 S
2. System D
Design
i

• T
Two iimportant activities
i i i during
d i d
design
i
1. Decomposition
2. Refinement

• Decomposition
– Process of partitioning a system into smaller modules
– Interface specifications specify interfaces between modules

• Refinement
e e e t
– Process of refining modules at one level to modules at a lower level
– Each refinement step should prove that a specification(program) at one level
satisfies a higher
g level specifications
p
• Program transformation, Program synthesis, Inferential programming
– Formal methods and formal specification languages can state proof
obligations(assumptions) precisely

Konkuk University 20
Uses 3 S
3. System V
Verification
ifi i

• S
System verification
ifi i
– Showing that a system satisfies its specification

• Formal Verification
– Using formal specifications to verify a system
– Cannot completely
p y verifyy an entire system,
y ,
– But can certainly verify smaller and critical part of system.
• Gypsy, HDM(Hierarchical Development Method), FDM(Formal Development Method)
• M-EVES(Environment for Verifying and Emulating Software)
• HOL(Higher Order Logic)

• Difficulties in formal system

y verification
– Should state explicitly assumptions about its environment : Not easy!
– “Bounds of Formal Methods”

Konkuk University 21
Uses 4 S
4. System V
Validation
lid i

• F
Formal
l methods
h d can aid
id iin system testing
i and
d debugging
d b i

• Specification
p alone :
– Used to generate test cases for black-box testing
– For boundary condition tests

• Specification along with implementation

– Used to generate test cases
– Additionally,
Additionally can be used for testing analysis
• Path testing
• Unit testing
• g
Integration testing
g
• Etc.

Konkuk University 22
Uses 5 S
5. System D
Documentation
i

• FFormall specification
ifi i
– Captures “What” rather than “How”
– Serves as a communication medium between
• Clients and Specifiers
• Specifiers and Implementers
• Among members of an implementation team

Konkuk University 23
Uses 6 S
6. System A
Analysis
l i and
dEEvaluation
l i

• S
System analysis
l i and
d evaluation
l i
– After system has been built and tested,
– Critical analysis of its functionality and performance should be done
• Does the system do what the customer wants?
• Does it do it fast enough?
– Formal method used in the development can help formulate and answer
these questions

• Most formal methods have not yet been applied to specifying large-
scale software and hardware systems
– Size of the specification
– Complexity of the specificand
• IInternal
t l complexity
l it
• Interface complexity

Konkuk University 24
Characteristics

• FFormall method’s
h d’ characteristics
h i i iinfluence
fl the
h style
l iin which
hi h a user applies
li
it
– Whether its language is graphical or textual
– Whether its underlying logic is first-order or high-order
– Etc.

• Formal method reflects a combination of many different characteristics:

1. Model-oriented vs. Property-oriented
2. Visual languages
3. Executable
4. Tool-supported
pp

Konkuk University 25
Characteristics 1 M
1. Model-oriented
d l i d vs. P
Property-oriented
i d

• M d l i
Model-oriented
d methods
h d
– Define system’s behavior directly by constructing a model of the system
1. For sequential systems
• Parnas’ statemechines, VDM, Z, SCR, NuSCR
2. For concurrent and distributed systems
• Petri Nets, CCS, Hoare’s CSP, Unity, I/O automata
• Temporal
T l llogic,
i Lamport’s
L t’ transition
t iti axiom
i method,
th d LOTOS

• P
Property-oriented
t i t d methods
th d
– Define system’s behavior indirectly by stating a set of properties using axioms
1. Axiomatic methods
• Iota, OBJ, Anna, Larch
2. Algebraic methods Algebraic specification of abstract data types can handle :
- Error values
• Act One - Nondeterminism
-pparameterization

Konkuk University 26
Characteristics 2 Vi
2. Visuall LLanguages

• Vi
Visual
l specification
ifi i llanguages
– Any one who contains graphical elements in their syntactic domains

• Many examples
– Petri nets : for concurrent systems
– Statecharts : for specifying state transitions in reactive systems

• Semiformal
Se o a methods
et ods
– Multiple interpretations or text attached
– Jackson’s method (UML)
– SASD OOD
SASD,
– Requirements Engineering Methodology

Konkuk University 27
Characteristics 3 E
3. Executable
bl

• E
Executable
bl SSpecification
ifi i
– Can run on a computer

• Specifiers can use executable specifications

– To gain immediate feedback about the specification itself.
– To do rapid prototyping
– To test a specificand through symbolic execution of the specification

• Many examples
– Statecharts
– OBJ
– Prolog, Paisley
– Most recent ones

Konkuk University 28
Characteristics 4 Tool-supported
4. T l d

• M d l Ch ki
Model-Checking tools
l
– Let users construct a finite-state model of the system
– Then show a property holds in each state or state transition of the system
– EMC, SMV, SPIN

• Proof-checking tools
– Let users treat algebraic specifications as rewrite rules
• Larch Prover, Affirm, Reve
– Handling first-order logic
• Boyer-Moore Theorem Prover, FDM, HDM, m-EVES
– Handling higher-order logic
• HOL, LCF, OBJ

Konkuk University 29
 Some Examples

Abstract Data Type: Z, VDM, Larch

Concurrency: Temporal Logic, CSP, Transition Axioms

Konkuk University 30
Some Examples

• 6 well-known
ll k fformall methods
h d (i
(in 1990
1990s))
– Abstract data type : Z, VDM, Larch
• Symbol table example
– Concurrency
C :T
Temporall LLogic,
i CSP
CSP, T
Transition
ii A
Axioms
i
• Unbounded buffer example

• When specifying the same problem with different methods, they look
– Remarkably similar
– Or totally different
– Due to
• Nature of the specificand
• Simplicity of the specificand
• Methods themselves

Konkuk University 31
Abstract Data Type: Z
Z, VDM
VDM, Larch

• 3 diff
different specifications
ifi i ffor a symbol
b l table
bl
Larch
Z
VDM

Konkuk University 32
Abstract Data Type: Z
Z, VDM
VDM, Larch

Z (1988) VDM (1986) Larch (1985)

Model-oriented
Base Model-oriented Property-oriented
(Also property-oriented)

Readability Good Normal Bad

Specifiability Bad Normal Good

Size Normal Compact Long

Syntax Analyzer
Tool-Support
Tool Support Proof Checker B N/A
L h Prover
Larch P

Konkuk University 33
Concurrency:
Temporal Logic, CSP, Transition Axioms
• 3 diff
different specifications
ifi i ffor an unbounded
b d dbbuffer
ff

Transition Axioms
Temporal Logic

CSP

Konkuk University 34
Concurrency:
Temporal Logic, CSP, Transition Axioms

T
Temporal
lLLogic
i (1980) CSP (1985) T
Transition
iti A i
Axioms (1983)

Model-oriented (for specifying) Model-oriented (for specifying)

Base Property-oriented
Property-oriented (for proving) Property-oriented (for proving)

Readability Normal Normal Good

Specifiability Bad Bad Good

Size Compact Compact Long

Tool-Support Many related tools Proof Checker B N/A

Konkuk University 35
 Bounds of Formal Methods

Between the Ideal and Real Worlds

Assumptions about the Environment

Konkuk University 36
Between the Ideal and Real Worlds

• F
Formal
l methods
h d are
– Based on mathematics
– But not entirely mathematical

• Two important boundaries between the mathematical and the real world

Konkuk University 37
Assumptions about the Environment

• There is a boundary between a real system and its environment

– Environment is out of the scope of formal specifications (Open System)
– Except, Gist specification language
• Environment ⇒ System
• Environment is a set of assumptions
• System is a set of constraints on its behaviors placed by specifiers
– Implicit
I li it assumptions
ti iin programmingi llanguage areas
– Specifiers should make explicit as many assumptions as possible.

• Hazard Analysis
– Identify a system’s safety-critical components
• FTA, FMEA, HAZOP
– A complementary technique to formal methods

Konkuk University 38
 Concluding Remarks

Formal Methods
Challenges

Konkuk University 39
Formal Methods

• I a strict
In i mathematical
h i l sense,
– Formal methods differ greatly from one another
• In a practical sense,
– Formal methods do not differ radically from one another

• Formal methods can be used

1. Identify
• Deficiencies in informal requirements
• Discrepancies between a specification and an implementation
• Errors in existing programs and systems
2. Specify
• Medium-sized and nontrivial problems
• Functional behavior
3. Provide
• Deeper understanding of the behavior of systems

Konkuk University 40
Challenges

1 Specifying
1. S if i nonfunctional
f i lbbehavior
h i
– Reliability, safety, real-time, performance, human factors
2. Combining different methods
– Domain specific + General
– Formal + Informal
3. Building
g more usable and robust tools
– Can manage large specifications
– Can perform more complicated semantic analysis
4 Building specification libraries
4.
– Reuse in general or domain-specific purpose
5. Formal methods based software development
6 Scale
6. S l up existing
i ti ttechniques
h i
7. Educating and training

Konkuk University 41