Formal Specification

Lecture 3A of Systems:

Dr. R. Mall
 Organization of this Lecture:
 Introduction
 General concepts
 Formal vs. Informal
specifications
 Axiomatic specification
 Algebraic specification
 Summary
 Requirements Analysis and
Specification

 An important life cycle phase

 Consists of two distinct activities
 Requirements gathering and
analysis
 Requirements specification
 Output of Requirements Analysis and
Specification Stage

 Software Requirements
Specification (SRS) Document:
 serves as contract between the
customer and the developers.
 The SRS Document

 Even after taking all care

 some subtle problems may remain
in the SRS document
 inconsistency, incompleteness, and
ambiguity
 SRS Document

 For many types of projects subtle

problems are acceptable
 though might lead to later rework
 For one class of projects called as
safety-critical projects
 even minor problems are not
acceptable
 Formal Specification

 Any failure of a safety-critical

product
 might result in loss of life and
property
 How can we ensure that
specification is trouble free?
 formal specification
Introduction-Formal Specification
Technique

 Formal specification
techniques enable us to:
 precisely specify a system
 verify that a system is
correctly implemented.
 Introduction
 We say a system is
correctly implemented:
 when it satisfies its
specification.
 Introduction
 We will first discuss some
important concepts in formal
methods:
 next we will examine the merits
and limitations of formal
techniques.
 What is a Formal Technique?

 A formal technique is a
mathematical method.
 How is a formal technique useful?

 Formal techniques can be

used:
 to specify a hardware
and/or software system.
 How is a formal technique useful?

 Formal techniques can also be

used to:
 verify whether a specification is
realizable,
 verify that an implementation satisfies
its specification,
 prove properties of a system without
necessarily running the system, etc.
 System development life-cycle

 The generally accepted

paradigm for system
development:
 through a hierarchy of
abstractions.
 Formal Methods
 Each stage in Specification

this hierarchy:
 an implementation Specification
Implementation

of its preceding stage.

 a specification of the Implementation
succeeding stage. Specification

Implementation
Specification
Implementation
 Life cycle model
 The different stages:
 requirements specification,
 design,
 coding,
 testing, etc.
 Formal Methods
 Formal techniques can be
used:
 at every stage of the system
development activity.
 Formal Methods
 The mathematical basis of a formal
method
 provided by its specification language.
 A formal specification language consists
of:
 two sets syn and sem, and
 a relation sat between them.
Syntax and Semantics
Syntax and Semantics

Swahili
(?)

English
 Formal Methods
 The set syn
 is called the syntactic domain,
 The set sem
 is called the semantic domain
 The relation sat
 is called the satisfaction relation.
 Formal Methods
 For a given specification syn,
and model of the system sem, if
sat(syn, sem):
 syn is said to be the specification
of sem
 sem is the specificand of syn
 Syntactic Domains
 The syntactic domain of a formal
specification language consists of:
 an alphabet of symbols
 a set of formation rules to construct well-
formed formulas.
 The well-formed formulas are used to
specify a system.
 Semantic Domains
 Formal techniques can have
different semantic domains:
 Abstract data type specification
languages
 languages for specification of
concurrent/distributed systems,etc.
 Semantic Domains

 Concurrent and distributed system

specification languages are used to
specify:
 state-transition sequences,
 event sequences,
 synchronization trees, partial orders,
etc.
 Satisfaction Relation
 Given the model of a system,
it is important to determine:
 whether an element of the
semantic domain satisfies the
specifications.
 Model versus Property-Oriented Methods

 Formal methods are usually

classified into two broad
categories:
 model-oriented approach
 property-oriented approach
 Model-Oriented Style
 System specified by constructing
its model:
 in terms of mathematical
structures:
tuples, relations, functions, sets,
sequences, etc.
Also, state machines, Petri nets, etc.
 Model-Oriented Style
 Well known model-oriented
specification techniques are:
Z
 CSP
 VDM
 Property-oriented style
 The system's behavior is defined
indirectly:
 by stating its properties:
usually in the form of a set of
axioms.
Examples: logic-based, algebraic
specification, etc.
Example: producer/ consumer system
 List the properties of the system:
 the consumer can start consuming
only after the producer has produced
an item,
 the producer starts to produce an item
only after the consumer has consumed
the last item.
 Property-oriented specification

 Producing ==> No items exist for

consumption
 consuming ==> Item exists for
consumption
Example: producer/ consumer system

 In a model-oriented approach:
 Define the basic operations, p
(produce) and c (consume).
 Then state that
S ==>S1+p,
S1 ==> S+c.
 Model-oriented approach

 Model-oriented approaches
 specify a program by writing
another simpler program.
 Comparison
 Property-oriented approaches
are suitable for requirements
specification:
 model-oriented approaches are
more suited to use in later phases
of life cycle.
 Comparison
 Property-oriented approaches
specify a system:
 as a conjunction of axioms,
 make it easier to alter/augment
specifications at a later stage.
 Comparison
 Model-oriented methods do not
support logical conjunctions (and)
and disjunctions (or):
 even minor changes to a specification
may lead to drastic changes to the
entire specification.
 Operational Semantics
 Operational semantics of a
formal method:
 the way it represents
computations:
i.e. the exact sequence in which the
different computations are carried
out
 Operational Semantics
 There are different types of
operational semantics:
 according to what is meant by a single
run of the system
 how the runs are grouped together to
describe the behavior of the system.
 Linear semantics
 A run of a system:
 described by a sequence (possibly
infinite) of events or states.
 The concurrent activities are
represented by non-deterministic
interleavings of the atomic
actions.
 Linear semantics - Example
 A concurrent activity a parallel b
 represented by the set of
sequential activities a;b and b;a.
 This is simple:
 but rather unnatural
representation of concurrency.
 Branching semantics
 The behavior of a system can be
represented by a directed
graph:
 Nodes of the graph represent
the possible states in the
evolution of a system.
Branching semantics
 Branching semantics

 The descendants of each node

of the graph:
 represent states which can be
generated by any of the atomic
actions enabled at that state.
 Maximally parallel semantics
 All concurrent actions enabled at
any state
 are assumed to be taken
together.
 This is also not a natural model
of concurrency.
 Partial order semantics

 Structure of states:
 satisfying a partial order relation
among the states (events).
 Partial order semantics
 The partial order represents a
precedence ordering among
events:
 constrains some events to occur only
after some other events have
occurred;
 while the occurrence of other events
is considered to be incomparable.
Partial order semantics
 Merits of Formal Methods

 Facilitates precise formulation of

specifications
 Formal specifications encourage
rigor.
 the process of developing rigorous
specification is often more important
than specification.
 Merits of Formal Methods

 Construction of a rigorous
specification clarifies several
aspects of system behavior:
 which are not obvious in an
informal specification.
 Merits of Formal Methods

 It is actually cost-effective to spend

more effort at the specification
stage.
 Otherwise many flaws that go
unnoticed will appear at later stages
of software development.
 Merits of Formal Methods

 For large and complex systems like

real-time systems:
 80% of project costs and most of cost
overruns result from iterative changes
required due to improper
requirements specification.
 Merits of Formal Methods

 Additional effort required to

construct a rigorous formal
specification:
 often well worth the trouble.
 Merits of Formal Methods

 Formal methods usually have a

well-founded mathematical
basis.
 formal specifications are precise
 can be used to mathematically
reason about the properties of a
specification
 Merits of Formal Methods

 Informal specifications are useful in

understanding a system and its
documentation:
 but they cannot serve as a basis of
verification.
 Even carefully written informal
specifications are prone to ambiguity
and error.
 Merits of Formal Methods

 Formal methods have well-

defined semantics.
 Ambiguity in specifications is
automatically avoided when one
formally specifies a system.
 Merits of Formal Methods

 Formal methods have mathematical

basis:
 scope for automating analysis of
specifications.
 Automatic verification:
one of the most important advantages of
formal methods.
 Merits of Formal Methods

 Formal specifications can be

executed:
 provide immediate feedback on
features of the specified system.
 The concept of executable
specification is related to rapid
prototyping.
 Limitations of Formal Methods

 Formal methods are difficult to

learn and use.
 While using formal specifications
 engineers tend to lose the overall
perspective and get lost in the
details.
 Limitations of Formal Methods

 The basic incompleteness results

of first-order logic (Gödel)
suggest:
 it is impossible to check absolute
correctness of systems using
theorem proving techniques.
 Limitations of Formal Methods

 Formal techniques are not able to handle

complex problems.
 even moderately complicated problems
blow up the complexity of formal
specification and their analysis.
 Also, a large unstructured set of
mathematical formulas is difficult to
understand.
 Formal vs. Informal specification Methods

 Formal specifications:
 do not replace informal
descriptions
 but complement them.
Formal vs. Informal specification Methods

 Comprehensibility of formal
specifications is greatly
enhanced:
 when accompanied by an
informal description.
Formal vs. Informal specification Methods

 General recommendation:
 Mixed approach
 use formal techniques as a
broad guideline for use of
informal techniques.
 Mixed Approach

 Formal method is used to identify

verification steps:
 but it is legitimate to apply informal
reasoning in correctness arguments.
 Any doubt or query relating to an
informal argument is resolved by
formal proofs.
Property-oriented Specifications

 Can be divided into two

categories:
 axiomatic specifications
 algebraic specifications
 Axiomatic Specifications
 Use first order logic:
 write pre-conditions and
post-conditions to specify
operations
 Axiomatic Specification of a Function

 Pre-conditions:
 What are the requirements on the
parameters of the function?
 Post-conditions:
 What are the requirements when
the function is completed?
 Axiomatic Specification of a Function

 Domain:
 What sort of things it acts upon?
 Co-domain (range):
 What sort of answer does it give?
 How to develop axiomatic specifications?

Establish the range of input

values over which the function
should behave correctly:
establish input parameter
constraints as a predicate.
 How to develop axiomatic specifications?

 Specify a predicate defining

the condition:
 which must hold on the output
of the function if it behaved
properly.
 How to develop axiomatic specifications?

 Establish what changes are made

to the function’s input parameters:
 pure mathematical functions should
not change its inputs e.g. f(a,b,c)
 programming languages allow function
inputs to be modified by passing them
as reference.
 How to develop axiomatic specifications?

 Combine all of the above:

 into pre and post conditions of
the function.
 Axiomatic Specification: Example

 f(x:real) : real
 Pre: x R
 Post: {x<100 ^ (f(x)=x/2)} v
R

{x>100 ^ (f(x)=2*x)}
 Example: Axiomatic Specification

 Consider a function search:

 accepts parameters:
an array of integers
an integer key
 returns array index of the number
in array whose value equals key:
original input array is unchanged
 Example: Axiomatic Specification

 Function search(X: Integer Array;

key: Integer): Integer
 pre: exists i in X’First …X’last:
x(i)=key
 post: X”(search(X,key))=key and
X=X”
 Error: search(X,key)=X’last+1
 Algebraic Specification

 An object class (or type) is

specified in terms of:
 relations existing between the
operations defined on that
type.
 Algebraic Specification

 It was first brought into prominence

by Guttag:
 used for specification of abstract data
types.
 Various notations of algebraic
specifications have evolved,
including OBJ and Larch.
 Algebraic Specification

 Essentially algebraic specifications:

 define a system as a
heterogeneous algebra; i.e
 a collection of different sets on
which several operations are
defined.
 Traditional Algebra
 Traditional algebra are
homogeneous.
 A homogeneous algebra:
 consists of a single set and
several operations;
e.g. { I, +, -, *, / }.
 Algebraic Specification
 In contrast, consider:
 alphabetic strings with operations:
concatenation and length,
 not homogeneous algebra,
 range of the length operation is
the set of integers.
 Algebraic Specification

 The collection of sets that form

the heterogeneous algebra:
 is called its signature.
 For example consider
{S,I,len,concat}
 SXI is the signature
 Algebraic Specification

 To define a heterogeneous
algebra, we need to specify:
 its signature,
 the involved operations, and their
domains and ranges.
 Algebraic Specification

 Algebraic specifications consist

of two important parts:
 syntactic part
 semantic part
 Syntactic part
 Names of different data types
involved are listed
 Names of operators and their
domains (signature) listed
 Exception Section

 Under normal conditions

 the result of an operation may be of
some sort.
 Under some exceptional conditions,
the results may be something else.
 Equations Section

 Defines a set of rewrite rules:

 meaning of interface procedures in
terms of each other.
 Specifies what is always true
about the behavior of operations.
Algebraic Specification
 By convention:
 each equation is implicitly
universally quantified over all
possible values of the variables.
 In simple words, holds good for
all values of variables.
 Algebraic Specification
 Names not mentioned in the
syntax section:
 such 'r' or 'e' are variable.
 Algebraic Specification

 Using algebraic specification:

 the meaning of a set of
interface procedures is
defined by using equations.
 Algebraic Specification
 Algebraic specifications are usually
presented in four parts:
 types section
 exceptions section
 signature section
 rewrite rules section
 Types Section
 Types Section Lists:
 sorts (or types) being specified
 sorts being imported
 Importing a sort:
makes it available in specification.
 Exception Section
 Lists names of exceptional
conditions used in later
sections:
 under exceptional conditions error
should be indicated.
 Signature Section

 Defines signatures of interface

procedures:
 e.g. PUSH takes a stack and an
element and returns a new stack.
 push:
stack element stack
 Rewrite rules section
 Lists the properties of the
operators:
 In the form of a set of axioms or
rewrite rules.
allowed to have conditional
expressions
 Developing Algebraic Specification

 The first step in defining an

algebraic specification:
 identify the set of required
operations.
 e.g. for string identify operations:
create, compare, concatenate,
length, etc.
 Developing Algebraic Specification

 Generally operations fall into 2

classes:
 Constructor Operations :
 Operations which create or modify
entities of the sort e.g., create,
update, add, etc.
 Developing Algebraic Specification

 Inspection Operations :
 Operations which evaluate
attributes of the sort, e.g.,
eval, get, etc.
 Developing Algebraic Specification

 A rule of thumb for writing

algebraic specifications:
 first establish constructor
and inspection operations
Developing Algebraic Specifications

 Next, write down axioms:

 compose each inspection
operator over each
constructor operator.
Developing Algebraic Specifications

 If there are m constructors and

n inspection operators:
 we should normally have m*n
axioms.
 However, an exception to this rule
exists.
Developing Algebraic Specifications

 If a constructor operation can be

defined using other
constructors:
 we need to define inspection
operations using only primitive
constructors.
 Example: Stack
 Let us specify an unbounded
stack supporting:
 push,
 pop,
 newstack,
 top,
 empty.
 Example: Stack
 Types:
 defines stack
 uses boolean, element
 Exception:
 underflow, novalue
 Example: stack
 Syntax:
 push:
 stack element stack
 pop:
 stack stack+{underflow}
 Example: stack
 top:
 stack element+{novalue}
 empty:
 stack boolean
 newstack:
stack

 Equations: stack
 pop(newstack)=underflow
 pop(push(s,e))=s
 top(newstack)=novalue
 top(push(s,e))=e
 empty(newstack)=true
 empty(push(s,e))=false
 Rewrite rules
 Rewrite rules let you
determine:
 the meaning of any sequence
of calls on the stack functions.
 Rewrite rules
 Empty(push(pop(push(newstack
,e1)),e2)):
 you can eliminate the call on pop
by observing:
it is of the form pop(push(s,e)).
 Rewrite rules

 After simplification:
 empty(push(newstack,e1))
 false
 Two important questions
 Finite termination property:
 Does application of rewrite rules
terminate after a finite number of
steps?
 We might endlessly go on applying
rewrite rules without coming to any
conclusion?
 Two important questions
 Unique termination property:
 Can different sequence in application
of the rewrite rules always give the
same answer?
 If we choose to simplify different
terms of the expression in different
experiments:
shall we always get the same answer?
 Algebraic Specification
 For arbitrary algebraic
equations:
 convergence is undecidable.
 If the r.h.s. of each rewrite rule
has fewer terms than the left:
 rewrite process must terminate.
 Auxiliary Functions
 Sometimes development of a
specification requires:
 extra functions not part of the
system:
to define the meaning of some
interface procedures.
Auxiliary Functions: Example
 To specify bounded stacks:
 need to add a depth function:
push returns either a stack or
an exception “overflow” when
depth is exceeded.
 Bounded stack
 In order to specify a bounded
stack:
 we need to make changes to
different sections to include
auxiliary functions.
 Auxiliary Functions
 Syntax:
 push:
 stack element ==> stack
 depth:
 stack integer
 Auxiliary Functions
 Equations:
 depth(newstack)=0
 depth(push(s,e))=depth(s)+1
 push(s,e)=overflow if depth(s)
>= Max
 Example 2: coord

 Types:
 sort coord
 imports integer, boolean
 Example: coord
 Signature:
 create(integer,integer) coord
 X(coord) integer
 Y(coord) integer
 Eq(coord,coord) boolean
 Example: coord
 Rewrite rules:
 X(create(x,y))=x
 Y(create(x,y))=y
 Eq(create(x1,y1),create(x2,y2))
= ((x1=x2) and (y1=y2))
 Structured Specifications
 Writing formal specifications is time
consuming.
 To reduce effort, we need to reuse
specifications:
 instantiation of generic specifications
 incremental development of
specifications
 Specification Instantiation
 Take an existing
specification:
 specified with some generic
parameter
 Instantiate with some sort
 Incremental Development
 Develop specifications for
simple sorts:
 using these specify more
complex entities.
 Pros and Cons
 Algebraic specifications have
a strong mathematical basis:
 can be viewed as
heterogeneous algebra.
 Pros and Cons
 An important shortcoming of
algebraic specifications:
 cannot deal with side effects
 difficult to use with common
programming languages.
 Pros and Cons
 Algebraic specifications are hard
to understand:
 also changing a single property of
the system
may require changing several
equations.
 Summary

 We started by discussing some

general concepts in
 formal specification
techniques.
 Summary
 Formal specifications have
several positive characteristics.
 the major shortcoming of formal
techniques is that they are hard to
use.
 Summary
 It is possible that formal
techniques will become more
usable in future:
 with the development of suitable
front-ends.
 Summary
 We discussed two sample
specification techniques,
 axiomatic specification
 algebraic specification
 give us a flavor of the issues
involved in formal specification.