Lecture 4
HO 4
-1-
Formal Methods
A Library System
Specification
(Continued)
From Specification to
Design
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
-2-
A Library System
We now add a few features to complete and strengthen our
specification.
Question: In what state does the system start?
Answer: “Some” state, if you do not specify which. So we must
specify the starting state of the system. This is so important that Z
requires all states to have an initialization schema.
INITLibrary
Library
onshelf =
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
-3-
A Library System
This schema describes a library in which the set onshelf is empty,
consequently, the function location is also empty.
So, we now have a little specification of a simple library system.
Note that in this system, the data objects are described in terms of
mathematical data types such as sets and functions. The
description of the state space included an invariant relationship
between parts of the state. This is information which would not be
part of a program but is vital in understanding it. The effect of the
operations are described in terms of the relationships which must
hold between input and output, rather than a detailed operational
description of how to generate the output.
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
-4-
A Library System
We can go further. We can add a number of features that would make
for a much stronger specification.
A serious flaw: as soon as someone tries to add a location for a book
already in the system , or tries to find the location of a book that is
not part of the library, the system says nothing about what happens
next. What do we do?
Solution 1: We can go back and revise all the schemas and add a
mechanism to report success in processing entries; or
Solution 2: We can create a small set of operations, and add them to
the overall schema.
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
-5-
A Library System
Let us try the first solution. Let us for example add this
functionality to AddtoLibrary:
Here is the original:
AddtoLibrary
 Library
abook?: BOOK
aspot? : SHELF
abook?  onshelf
location’ = location  {abook?  aspot?}
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
-6-
A Library System
Here is the modified version
AddtoLibrary
 Library
abook?: BOOK
aspot? : SHELF
Result!:REPORT
(abook?  onshelf  location’ = location  {abook?  aspot?}
 result! = ok) 
(abook?  onshelf  location’ =location  result! = alreadythere)
Where: REPORT ::= ok | alreadythere | notknown
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
-7-
A Library System
Or, we can write three small operations: Success, AlreadyThere, and
NotKnown.
Success
result! : REPORT
result! = ok
AlreadyThere
Ξ Library
abook?: BOOK
result! : REPORT
abook?  onshelf
result! = alreadythere
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
-8-
A Library System
NotKnown
Ξ Library
abook?: BOOK
result! : REPORT
abook?  onshelf
result! = notknown
We are not done yet. We now have to combine the schemas to
obtain the robust version (designated by R before their names):
RAddtoLibrary = (AddtoLibrary  Success)  AlreadyThere
RFindLocation = (FindLocation  Success)  NotKnown
RShelfContents = ShelfContents  Success
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
-9-
A Library System
Exercise:
Specify operations:
Out, a book is borrowed
Returned, a borrowed book is now returned, and
Remove, a book is no longer part of the library
Hint: Strictly speaking, only Remove need be written. Why?
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
- 10 -
A Library System
From Specification to Design
The essence here is to take mathematically correct steps to
“translate” the specification into a design that is implementable
in a programming language.
The main idea is to describe the concrete class or classes (often
the latter) which the program will use to represent the structural
model of the specification. We call this activity data refinement.
We often also – in one or several steps - refine the operations and
make them explicit. This we call operational refinement or
algorithm development.
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
- 11 -
A Library System
For simple systems, this is generally done in one step, called direct
refinement. For more complex systems, this is a stepwise process
called deferred refinement.
In deferred refinement, the first refinement cycle will result in a
new – more explicit – specification, which is then further refined
and so on, resulting in a related and provably consequent sequence
of documents finally yielding an implementable design.
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
- 12 -
A Library System
In the next two lectures, we will see an example each of both
approaches.
The first will be a direct refinement of the library system, the
second, deferred refinement is used to show parts of the
implementation of a simple checkpoint-restart mechanism for a
database; perhaps one to be used with our little library system.
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
- 13 -
A Library System
First, the library system:
The data abstraction used in the specification is chosen for clarity
not implementability. Now we have to choose concrete data
structures that may actually be implemented. For now, that would
be a distraction.
For simplicity, we use “infinite” arrays. We could easily add the
bound of the array to the specification in many ways. So, we have:
books : ARRAY [1..] of BOOK;
shelves: ARRAY [1..] of SHELF;
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
- 14 -
A Library System
The array may be modeled by functions from the set of strictly
positive integers to BOOK and SHELF:
books : N1 BOOK

shelves : N1 SHELF
As such, the element books[i] of the array is simply the value
books(i) of the function, and the assignment books[i] := v is
exactly specified as:
books’ = books  {i  v}
This means that the right hand side function takes the same
values everywhere except when i=v.

ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
- 15 -
A Library System
We write a new class LibraryImp, as below:
LibraryImp
books : N1  BOOK
shelves: N1  SHELF
used:N
i,j : 1..used  ij  books(i)  books(j)
Α
The predicate says that there are no repetitions among the
elements books(1)…..books(used)
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
- 16 -
A Library System
The idea is that each book is linked to a shelf in the corresponding
array shelves. We can document this with schema Link1 that
defines the abstraction relation between the abstract state space
Library and the concrete state space LibraryImp:
Link1
Library
LibraryImp
onshelf ={i:1...used  books(i)}
i : 1..used  location(books(i)) = shelves(i)
Α
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
- 17 -
A Library System
Now we are ready to translate the operations of Library fro
abstract to concrete state space.
AddtoLibraryImp
 LibraryImp
abook?: BOOK
aspot? : SHELF
i : 1..used  abook?  books(i)
used’ =used+1
(books’ =books  {used’  abook?}
shelves’ = shelves  {used’  aspot?}
Α

ECSE 6780- Software Engineering 1I

© HY 2012
Lecture 4
HO 4
- 18 -
A Library System
Proof:
The schema just described is a valid and correct translation of
AddtoLibrary because:
1. Wherever AddtoLibrary is legal in some abstract state, the
translation AddtoLibraryImp is legal in a corresponding concrete state.
2. The final state resulting from AddtoLibraryImp represents an
abstract state which AddtoLibrary could produce.
Why are these two statements true?
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
- 19 -
A Library System
The operation AddtoLibrary is legal exactly if its pre-condition
abook?  onshelf is satisfied. If this is so, the predicate in Link1,
onshelf ={i:1...used  books(i)} tells us that abook? Is not one of the
elements names(i):
i : 1..used  abook?  books(i)
Α
This is the precondition for AddtoLibraryImp. So the proof indicates
that as long as the precondition for AddtoLibraryImp is satisfied, so
will the precondition for AddtoLibrary, which is our first
requirement.
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
- 20 -
A Library System
To prove the second fact, we need to think about the concrete
states before and after an execution of AddtoLibraryImp, and the
abstract states they represent according to Link1.
The two concrete states are related bt AddtoLibraryImp, and we
must show that the two abstract states are related as prescribed
by AddtoBirthday:
location’ = location  {abook?  aspot?}
First we have to show that the domains of the two functions
location’ and location are the same. This so, because:
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
- 21 -
A Library System
dom location’ = onshelf’
[invariant after]
onshelf’ ={i:1...used’  books’(i)}
[from Link1’]
={i:1...used  books’(i)}  {books’(used’)} [used’=used+1]
But books’= books  {used’  abook?}
[from AddtoLibraryImp]
then we have: = {{i:1...used  books(i)}  {books?}
  {name?}
= onshelf
[from Link1]
= dom location  {name?}
[invariant before]
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
- 22 -
A Library System
There is no change in the arrays used before the operation, so for
all i in range 1…used;
books’(i) = books(i)  shelves’(i) = shelves(i)
For any i in this range,
location’(books’(i)) = shelves’(i)
= shelves(i)
= location(books(i))
ECSE 6780- Software Engineering 1I
[from Link1’]
[from above]
[from Link1]
© HY 2012
Lecture 4
HO 4
- 23 -
A Library System
For the new book, stored at index used’ = used+1,
location’(abook?) = location’(books’(used’))
= shelves’(used’)
[from Link1’]
= aspot?
[from AddtoLibraryImp]
So the two functions location’ and location  {abook?  aspot?}
are equal and the abstract states before and after the operation are
guaranteed to be related and described by AddtoLibrary.
We have a proof
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
- 24 -
A Library System
Implementation
The description of the concrete operation AddtoLibrary uses only
notation with a direct correspondence in any procedural language. So
we can implement it directly into an operation of the class Library.
procedure AddtoLibrary(abook:BOOK; aspot:SHELF);
begin
used :=used+1;
books[used] := abook;
shelves[used] ;= aspot;
end;
Note: variables used, books, and shelves are already declared in
the class scope. abook and aspot are declared in the procedure. I
will spare you the proof of the adequacy of variable set and scope.
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
- 25 -
A Library System
Similarly and without proof:
FindLocationImp
Ξ LibraryImp
abook?: BOOK
aspot! : SHELF
 i: 1…used  abook? = books(i)  aspot! = shelves(i)
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
- 26 -
A Library System
And the implementation:
procedure FindLocation (abook:BOOK; aspot:SHELF)
var i = INTEGER;
begin
i := 1;
while books[i] != abook do i := i+1;
aspot := shelves[i];
end;
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
- 27 -
A Library System
One last things: Assembly.
We now need to construct two classes. One an abstract class Library
and another, a concrete class LibraryImp.
This is actually very easy; even easier in our case (as there is no
inheritance).
All we have to do is to assemble everything in the class schema.
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
- 28 -
A Library System
A reminder of the structure of a 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 4
HO 4
- 29 -
A Library System
Inheritance
Type definitions
Constants
Library
onshelf : P BOOK
location: SHELF
State Schema
Initialization
Schema
location: BOOK  SHELF
INIT
onshelf =
AddtoLibrary
XXXXXX
Operations
go here:
Class/History
Invariant
Etc.
XXXXXX
onshelf =dom location
ECSE 6780- Software Engineering 1I
© HY 2012
Lecture 4
HO 4
- 30 -
A Library System
Note:
Of course, entities such as BOOK, SHELF, N, N1, ARRAY,
REPORT, etc. are themselves classes and must be either
defined (as part of the system (e.g. BOOK and REPORT) or
imported from a class library (e.g. ARRAY and N1 ) and then
related to the system through type definitions or other means.
ECSE 6780- Software Engineering 1I
© HY 2012