Lecture 3
HO 3
-1-
Formal Methods
Formal Methods through an Introduction to Z
A notation for formal specification
of systems and a formal tool for
precise design of software
Z (pronounced Zed), uses mostly familiar
mathematical notation and properties to
precisely specify the system under
description
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
-2-
Formal Methods
Formal Methods (in the plural), is a collective term applied to
mathematical methods and techniques used to specify, design
and verify systems. Their use has been prevalent in software
and complex electronic hardware development.
A formal method (in the singular), is a coherent set of such
mathematical techniques and notations used as a methodology
to specify, design and/or verify a system. Zed is one such
formal method.
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
-3-
Formal Methods
Formal Methods come under multiple scopes and uses:
Level 0: Formal Specification. This is when mathematical
rigor is used to only specify the requirements of a system
Level 1: Formal Specification and Derivation. This is when
mathematical rigor is used to not only specify a system but
also used that specification to derive mathematically, that is,
translate the specification to a program
Level 2: Fully Formal. This is when the derivation (as per a
level 1 method) is proven for correctness against the original
specification.
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
-4-
Formal Methods
Formal methods may be grouped into three general categories:
Axiomatic Methods: where the system is specified in terms of
state changes defined in terms of pre- and post-conditions,
variants and invariants. Propositional and predicate logic are an
important feature of such methods. Z belongs to this category.
Operational Methods: where the operation of the system is
formally specified as a sequence of operations.
Denotational Methods: where the system is specified using
domain theory.
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
-5-
Z Specification
As all other formal methods, Z uses the powerful notion of
abstraction.
Z specifies a system using:
Mathematically defined data types
and
Decompositions called Schemas
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
-6-
Z Specification
A schema describes both the static and the dynamic aspects of
a system.
Static
Individual states
Invariants maintained
ECSE 6780- Software Engineering 1I
Dynamic
State Transitions
Events (operations)
Transformations
(relationship of input to
output)
© HY 2012
Lecture 3
HO 3
-7-
Z Specification
The Z language also allows us to combine and relate separately
defined schemas in a mathematically logical fashion.
Z also permits a progression of decomposition. We can construct
a progression of related specifications that eventually arrives at
the API or the equivalent of the API of an implementation
façade.
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
-8-
Z Specification
To learn how to speak any language, we first need to learn some
vocabulary and some simple rules of grammar. Both the vocabulary
and the grammar of Z should be largely familiar to you. Over the
next few pages, we will cover some of these (without necessarily
going into the details and subtleties of their definitions and uses).
Some of these symbols and concepts are unique to Z but most are
in general use elsewhere in mathematics.
In this treatment we use the ObjectZ dialect of Z, one that allows
for the notion of class, inheritance and a few other OO “nice to
have”s.
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
-9-
Z Specification
Sets and Types
data type ::=m1|m2|…..|mn
[X]
Type X
X==Y
Y stands for X
N
Set of natural numbers (0)
N1
Set of positive integers (1)
t S
t is an element of set S
t S
t is not an element of set S
S T
S is contained in T
ECSE 6780- Software Engineering 1I
Z Set of Integers
© HY 2012
Lecture 3
HO 3
- 10 -
Z Specification
ST
S is strictly contained in T (ST)
S T
S is not contained in T
S T
Set of intersection of S and T
S T
Set of the union of S and T
PS
Powerset of S: the set of all subsets of S
FS
Finite powerset of S: the set of all finite subsets of S
SS
The distributed intersection of all sets in SS
SS
The distributed union of all sets in SS
 Or { }
The null or empty set
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
- 11 -
Z Specification
S\T
Difference: elements that are in S but not in T
#S
Size or cardinality: number of elements in S
{D|p.t}
Set of t’s such that given declaration D, P holds
disjoint Sq
the sets in the sequence sq are disjoint
sq partition S the sets in sq partition the set S
Logic
true, false
logical constants
P
not P
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
- 12 -
Z Specification
PQ
conjunction: “P and Q”
PQ
disjunction: “P or Q”
PQ
implication: “If P then Q”
PQ
equivalence: : “If P then Q and if Q then P”
t=r
term t is equal to term r
tr
term t is not equal to term r, that is: (t=r)
Predicates:
x:T.P
for all x of type T, P holds
x: T.P
there exists an x of type T, for which P holds
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
- 13 -
Z Specification
Relations:
XY
the set of ordered pairs of X’s and Y’s
XY
the set of relations from X to Y; = =P(XY)
xRy
x is related to y by R; (x,y) R
dom R
the domain of relation R; = ={x:X | (x:X . x R y) . x}
ran R
the range of a relation R; = ={y:Y | (x:X . x R y) . y}
SR
the relation R is domain restricted to S
RS
the relation R is range restricted to S
R~
the inverse of R
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
- 14 -
Z Specification
Functions:
XY
the set of partial functions from X to Y
= ={f:XY | (x:X | x dom f. (1y:Y.x f y))}
X Y
the set of total functions from X to Y
= ={f: X  Y| dom f = X.f}
fx or f(x)
function f is applied to x
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
- 15 -
Z Specification
Sequences:
seq X
the set of sequences with elements drawn from X
= ={S:N X | dom S= 1…#S}
seq1 X
set of non-empty sequences of X
iseq X
set of non-duplicate sequences of X
#S
the length of sequence X
<>
the empty sequence
<x1,…xn>
the sequence of x1 through to xn
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
- 16 -
Z Specification
<x1,…xn>^<y1,…yn>
concatenation
= = <x1,…xn,y1,…yn>
head S
==S1
last S
= = S #S
tail S^S1
==S
frontS^<x>
= = S where <x>= =last S
rev S
the sequence S in reverse order
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
- 17 -
Z Specification
Schemas:
Class Schema:
Class Name[generic parameter]
inherited classes
type definitions
constant definitions
state schema
initial state schema
operation schemas
history invariant
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
- 18 -
Z Specification
State Schema
items: seq T
#items  max
declaration
ECSE 6780- Software Engineering 1I
predicate
© HY 2012
Lecture 3
HO 3
- 19 -
Z Specification
Initial State Schema:
INIT
items = = < >
Operational schemas
Operation name
declarations
predicates
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
- 20 -
Z Specification
Schema decorations:
| name: T
name is a constant of type T
item ?: T
item is an input or accepts input
item !: T
item is an output or holds an output
item’
new state of item after change
(item)
the schema effects change on item
Ξ(item)
item is left unchanged by schema
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
- 21 -
Z Specification
A simple case example will help bring these concepts together
We will develop a specification for a very
simple library management system. In this
system, each book will be assigned to a shelf
location, designated by a number. A shelf
location of course may house many books.
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
- 22 -
A Library System
We introduce the types we need: [BOOK], [SHELF]
We do not for the moment specify what exact type the book
variable would be. The book may be identified by an
alphanumeric string, such as by the book title; alphabetic, such as
by author’s name; numeric, such as by ISBN, etc. It does not
matter for the moment.
The shelf we decide is simply numbered from 1 to whatever.
[SHELF], SHELF ::=N1
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
- 23 -
A Library System
So now we can think of an ordered pair of [BOOK,SHELF] which
is generic in with respect to BOOK and specified wrt SHELF. This
renders the whole ordered pair structure generic, in that it would
have to be set to a type (book has to be set to a type) before it can
be instantiated.
Now we can create a simple class, let us call it Library. We do so by
creating a class schema:
Library
onshelf : P BOOK
location: BOOK  SHELF
onshelf =dom location
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
- 24 -
A Library System
Note that we have not placed a limit on the number of records
that may be stored nor the order in which they are to be stored.
Because location is in a functional relationship with onshelf,
there will always be only one location for a book but many
books may be placed on the same shelf.
But what can this simple system do? How about adding a
book/location pair?
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
- 25 -
A Library System
AddtoLibrary
 Library
abook?: BOOK
aspot? : SHELF
abook?  onshelf
location’ = location  {abook?  aspot?}
We have read two variables abook and aspot and
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
- 26 -
A Library System
A bit of proof (you probably don’t need to do this but it is a good simple demonstration
of the proof capability of Z):
Prove that onshelf’ = onshelf  {abook?}
Proof:
onshelf’ = dom location’
= dom (location  {abook?  aspot?}
[by invariant after]
[Spec of
AddtoLibrary]
= dom location  dom{abook?  aspot?} [fact about dom]
= dom location  {abook?}
[fact about functions]
= onshelf  {abook?}
[invariant before}
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
- 27 -
A Library System
Let’s add another operation:
Add an operation that given the name of a book, it finds its shelf
FindLocation
Ξ Library
abook?: BOOK
aspot! : SHELF
abook?  onshelf
aspot! = location(abook?)
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
- 28 -
A Library System
The new symbol Ξ indicates that the operation FindLocation has
induced no change of state. It is in this sense mathematically
equivalent to:
(onshelf’ = onshelf)  (location’ = location)
Which due to rules of precedence of symbols may be written as:
(onshelf’ = onshelf)  (location’ = location)
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 3
HO 3
- 29 -
A Library System
Another operation may be to find the contents of a shelf. That is,
given the number of the shelf, find out what books are on that shelf.
ShelfContents
Ξ Library
ashelf?: SHELF
books! : BOOK
ashelf?  dom location
books! = {n: onshelf | location(n) = ashelf?}
ECSE 6780- Software Engineering 1I
© HY 2012