html5-img
1 / 30

Formal Methods

Formal Methods. A Library System Specification (Continued) From Specification to Design. A Library System. We now add a few features to complete and strengthen our specification. Question: In what state does the system start?

keefer
Download Presentation

Formal Methods

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Formal Methods A Library System Specification (Continued) From Specification to Design

  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 =

  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.

  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.

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

  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

  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

  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

  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?

  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.

  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.

  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.

  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;

  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.

  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)

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

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

  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?

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

  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:

  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?} = onshelf {name?} [from Link1] = dom location  {name?} [invariant before]

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

  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

  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.

  25. A Library System Similarly and without proof: FindLocationImp ΞLibraryImp abook?: BOOK aspot! : SHELF i: 1…used abook? = books(i)  aspot! = shelves(i) 

  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;

  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.

  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

  29. A Library System Inheritance Library Type definitions onshelf : P BOOK location: SHELF Constants State Schema location: BOOK SHELF Initialization Schema INIT onshelf = AddtoLibrary Operations go here: XXXXXX Etc. Class/History Invariant XXXXXX onshelf =dom location

  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.

More Related