CS 228 meeting -*- Outline -*-

* Correctness of ADT implementations (HR 9.3)

** overview

	Imagine we implement IntSet using a singly-linked list of ints.

*** abstraction maps
------------------------------------------
        THE  ABSTRACTION MAP
 RELATES REPRESENTATION TO ABSTRACT VALUES

// IntStack.h
class IntStack {
public:
  // ABSTRACTLY: a sequence of ints,
  // written <3,4,5>, with 3 the top

  // ...
#include "IntStack.pri"
};

// IntStack.pri
private:
   struct ElemNode {
     int val;
     ElemNode *link;
   };
   ElemNode *top;

   // ABSTRACTION MAP: the abstract value
   // is the sequence formed from the list
   // in order starting from *top.

		PICTURE

abstract value:

concrete rep:



------------------------------------------
	draw picture of the sequence <5, 2, 3>
	and the list in order (5, 2, 3)

*** model pictures of operations in abstract and concrete views
------------------------------------------
 ABSTRACT AND CONCRETE VIEW OF OPERATIONS

            IntStack();
     s:    ------------>  s: <>





            s.Push(3)
      s: <> ----------->  s: <3>






------------------------------------------
	draw the concrete pictures underneath
		can label the arrows with IntStack::Stack()
			and IntStack::Push(3)

	note how this allows you to reason abstractly

------------------------------------------
         FOR YOU TO DO

Complete the following:
 
             s.Pop()
      s: <3> ----------->  s: <>






              s.Top()
      s: <3> ----------->  s: <3>
                           FCTVAL: 3




------------------------------------------

*** predicate pictures of operations in abstract and concrete

	instead of a specific example, we specify for the general case

	requires some vocabulary for manipulating the abstract values

------------------------------------------
 ABSTRACT AND CONCRETE VIEW OF SPECS

            IntStack();
     true  ----------->  self == <>





             Push(n)
self isn't  ---------->  self ==
   full           AppendFront(self<entry>)






------------------------------------------
	write the concrete specs underneath;
		use LISP notation for the abstract values of lists

         IntStack::Push(n)
  room on ----------> top == cons(n, top<entry>)
free store

	Discuss how these relate:
		want the concrete postcondition to imply the abstract
		in the sense that:
		 IF self == A(top) && self<entry> == A(top<entry>)
		 THEN top == cons(n, top<entry>) ==> self == n || self<entry>

		want the abstract precondition to to imply the concrete
		in the sense that:
		 IF self == A(top)
		 THEN self isn't full ==> room on free store

	Summarize by drawing in the implication arrows
		note how this allows you to reason abstractly

------------------------------------------
         FOR YOU TO DO

Complete the following:
 
               Pop()
 self isn't ------------> self ==
   empty          RemoveFront(self<entry>)





             Top()
 self isn't -------> FCTVAL == Front(self)
   empty     




------------------------------------------

*** remarks on invariants

	Q: What's the use of having an abstract invariant for a class?
		tells what's true of abstract values,
		gives subset of what otherwise would be a larger domain
			(e.g., limit to finite integers)

	Q: What's the use of having a concrete invariant for a class?
		documents what properties are true of the reps
		gives the domain of the abstraction map (draw picture)

	Q: If we implemented IntSet with a singly-linked list,
		what might be a useful concrete invariant?
		discuss implications for efficiency if time

** examples (HR 9.7 and 9.8, see also HR 9.3-6)

------------------------------------------
   RING BUFFER IMPLEMENTATION OF QUEUE

Pictures:


------------------------------------------
	draw it as a straight array, with front and rear,
	and also as a circle

	Then work the example on-line, filling in:
		the domain
		the data members,
		the rep invariant,
		the abstraction map
		the concrete specs
		the implementation

	If time, do it as a linked list (HR 9.8), same way