ECSE 6780- Software Engineering 1I - 1 - HO 4 © HY 2012 Lecture 4 Formal Methods A Library System Specification (Continued) From Specification to Design

ECSE 6780- Software Engineering 1I

- 1 -HO 4

© HY 2012

Lecture 4

Formal Methods

A Library System Specification(Continued)

From Specification to Design


- 2 -HO 4

© HY 2012

Lecture 4

A Library SystemWe 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.

INITLibraryLibrary

onshelf =


- 3 -HO 4

© HY 2012

Lecture 4

A Library SystemThis 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.


- 4 -HO 4

© HY 2012

Lecture 4

A Library SystemWe 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.


- 5 -HO 4

© HY 2012

Lecture 4

A Library SystemLet us try the first solution. Let us for example add this functionality to AddtoLibrary:

Here is the original:

Library

abook? onshelflocation’ = location {abook? aspot?}

abook?: BOOKaspot? : SHELF

AddtoLibrary


- 6 -HO 4

© HY 2012

Lecture 4

(abook? onshelf location’ = location {abook? aspot?} result! = ok) (abook? onshelf location’ =location result! = alreadythere)

A Library SystemHere is the modified version

Libraryabook?: BOOKaspot? : SHELFResult!:REPORT

AddtoLibrary

Where: REPORT ::= ok | alreadythere | notknown


- 7 -HO 4

© HY 2012

Lecture 4

A Library SystemOr, we can write three small operations: Success, AlreadyThere, and NotKnown.

Successresult! : REPORT

result! = ok

Ξ Library

abook? onshelfresult! = alreadythere

abook?: BOOKresult! : REPORT

AlreadyThere


- 8 -HO 4

© HY 2012

Lecture 4

Ξ Library

abook? onshelfresult! = notknown

abook?: BOOKresult! : REPORT

A Library SystemNotKnown

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) AlreadyThereRFindLocation = (FindLocation Success) NotKnownRShelfContents = ShelfContents Success


- 9 -HO 4

© HY 2012

Lecture 4

Exercise:

Specify operations: Out, a book is borrowedReturned, 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?

A Library System


- 10 -HO 4

© HY 2012

Lecture 4

A Library System

From Specification to DesignThe 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.


- 11 -HO 4

© HY 2012

Lecture 4

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.


- 12 -HO 4

© HY 2012

Lecture 4

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.

A Library System


- 13 -HO 4

© HY 2012

Lecture 4

A Library SystemFirst, 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;


- 14 -HO 4

© HY 2012

Lecture 4

A Library SystemThe 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.

€

⊕


- 15 -HO 4

© HY 2012

Lecture 4

A Library SystemWe write a new class LibraryImp, as below:

LibraryImpbooks : N1 BOOKshelves: N1 SHELFused:N

i,j : 1..used ij books(i) books(j)

Α

The predicate says that there are no repetitions among the elements books(1)…..books(used)


- 16 -HO 4

© HY 2012

Lecture 4

A Library System

Link1LibraryLibraryImp

i : 1..used location(books(i)) = shelves(i)

Α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:

onshelf ={i:1...used books(i)}


- 17 -HO 4

© HY 2012

Lecture 4

A Library SystemNow we are ready to translate the operations of Library fro abstract to concrete state space.

used’ =used+1(books’ =books {used’ abook?} shelves’ = shelves {used’ aspot?}

LibraryImpabook?: BOOKaspot? : SHELF

AddtoLibraryImp

i : 1..used abook? books(i)

Α

€

⊕

€

⊕


- 18 -HO 4

© HY 2012

Lecture 4

A Library SystemProof:

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?


- 19 -HO 4

© HY 2012

Lecture 4

A Library SystemThe 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.

Α


- 20 -HO 4

© HY 2012

Lecture 4

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:


- 21 -HO 4

© HY 2012

Lecture 4

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?}

= onshelf {name?} [from Link1]

= dom location {name?} [invariant before]

€

⊕


- 22 -HO 4

© HY 2012

Lecture 4

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) [from Link1’] = shelves(i) [from above] = location(books(i)) [from Link1]


- 23 -HO 4

© HY 2012

Lecture 4

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


- 24 -HO 4

© HY 2012

Lecture 4

A Library SystemImplementation

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.


- 25 -HO 4

© HY 2012

Lecture 4

A Library SystemSimilarly and without proof:

Ξ LibraryImp

i: 1…used abook? = books(i) aspot! = shelves(i)

abook?: BOOKaspot! : SHELF

FindLocationImp


- 26 -HO 4

© HY 2012

Lecture 4

A Library SystemAnd 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;


- 27 -HO 4

© HY 2012

Lecture 4

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.


- 28 -HO 4

© HY 2012

Lecture 4

Class Name[generic parameter]inherited classes

type definitions

constant definitions

state schema

initial state schema

operation schemas

history invariant

A Library System

A reminder of the structure of a class schema


- 29 -HO 4

© HY 2012

Lecture 4

Library

onshelf : P BOOKlocation: SHELF

onshelf =dom location

A Library SystemInheritanceType definitionsConstants

location: BOOK SHELFState Schema

INITonshelf =

Initialization Schema

Operations go here: XXXXXX

AddtoLibrary

Etc.XXXXXXClass/History

Invariant


- 30 -HO 4

© HY 2012

Lecture 4

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.

Documents

ECSE 6780- Software Engineering 1I - 1 - HO 4 © HY 2012 Lecture 4 Formal Methods A Library System Specification (Continued) From Specification to Design