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

ECSE Software Engineering 1I HO 4 © HY 2012 Lecture 4 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 Software Engineering 1I HO 4 © HY 2012 Lecture 4 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 Software Engineering 1I HO 4 © HY 2012 Lecture 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 Software Engineering 1I HO 4 © HY 2012 Lecture 4 A Library System Let us try the first solution. Let us for example add this functionality to AddtoLibrary: Here is the original:  Library abook?  onshelf location’ = location  {abook? aspot?} abook?: BOOK aspot? : SHELF AddtoLibrary 

ECSE Software Engineering 1I HO 4 © HY 2012 Lecture 4 (abook?  onshelf  location’ = location  {abook? aspot?} result! = ok)  (abook?  onshelf  location’ =location  result! = alreadythere) A Library System Here is the modified version  Library abook?: BOOK aspot? : SHELF Result!:REPORT AddtoLibrary   Where: REPORT ::= ok | alreadythere | notknown

ECSE Software Engineering 1I HO 4 © HY 2012 Lecture 4 A Library System Or, we can write three small operations: Success, AlreadyThere, and NotKnown. Success result! : REPORT result! = ok Ξ Library abook?  onshelf result! = alreadythere abook?: BOOK result! : REPORT AlreadyThere

ECSE Software Engineering 1I HO 4 © HY 2012 Lecture 4 Ξ Library abook?  onshelf result! = notknown abook?: BOOK result! : REPORT A Library System 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 Software Engineering 1I HO 4 © HY 2012 Lecture 4 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? A Library System

ECSE Software Engineering 1I HO 4 © HY 2012 Lecture 4 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 Software Engineering 1I 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.

ECSE Software Engineering 1I 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

ECSE Software Engineering 1I HO 4 © HY 2012 Lecture 4 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 Software Engineering 1I HO 4 © HY 2012 Lecture 4 A Library System The array may be modeled by functions from the set of strictly positive integers to BOOK and SHELF: books : N 1  BOOK  shelves : N 1  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 Software Engineering 1I HO 4 © HY 2012 Lecture 4 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 Software Engineering 1I HO 4 © HY 2012 Lecture 4 A Library System Link1 Library LibraryImp 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)}

ECSE Software Engineering 1I HO 4 © HY 2012 Lecture 4 A Library System Now 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?}  LibraryImp abook?: BOOK aspot? : SHELF AddtoLibraryImp  i : 1..used  abook?  books(i) Α 

ECSE Software Engineering 1I HO 4 © HY 2012 Lecture 4 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 Software Engineering 1I HO 4 © HY 2012 Lecture 4 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 Software Engineering 1I 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:

ECSE Software Engineering 1I 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]

ECSE Software Engineering 1I 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]

ECSE Software Engineering 1I 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

ECSE Software Engineering 1I HO 4 © HY 2012 Lecture 4 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 Software Engineering 1I HO 4 © HY 2012 Lecture 4 A Library System Similarly and without proof: Ξ LibraryImp i: 1…used  abook? = books(i)  aspot! = shelves(i) abook?: BOOK aspot! : SHELF FindLocationImp 

ECSE Software Engineering 1I HO 4 © HY 2012 Lecture 4 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 Software Engineering 1I 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.

ECSE Software Engineering 1I 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

ECSE Software Engineering 1I HO 4 © HY 2012 Lecture 4 Library onshelf : P BOOK location: SHELF onshelf =dom location A Library System Inheritance Type definitions Constants location: BOOK  SHELF State Schema INIT onshelf =  Initialization Schema Operations go here: XXXXXX AddtoLibrary Etc. XXXXXX Class/History Invariant

ECSE Software Engineering 1I 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.