CS 228 meeting -*- Outline -*-

* specification issues (HR 9.9-10)

** primitive models

------------------------------------------
		PROBLEM

English specifications can be ambiguous.

How can they be made less ambiguous?


------------------------------------------
	... use examples
		but do these always give a unique description?

	... so write them using a more mathematical notation

	same reason an architect uses formal pictures
		or a cookbook uses measures, etc.

	Q: What are the parts of an ADT specification?
	Q: How can we formalize each part?
		by defining the domain using some standard ones
		by defining the pre and postconditions using math vocabulary

------------------------------------------
       PRIMITIVE MODELS

Examples:
  - integers
  - Booleans
  - characters
  - sets
  - sequences
  - tuples

def: a *primitive model* is a
    mathematically characterized concept.

These are used to define
------------------------------------------
	... the domain of an ADT
------------------------------------------
It should:
  - be commonly understood
  - have a well-defined notation
------------------------------------------
	... and useful
	it should not be ambiguous

	See HR for details of these

	Another point of view (Larch), is to allow users to define their own
		models when needed.

** levels of abstraction (HR 9.10)

	It's often useful to use abstraction several times to get to
	the desired functionality

------------------------------------------
          LEVELS OF ABSTRACTION

IntSet abstract values:  {3, 4}

list picture:





hardware picture:




------------------------------------------
	you can even go below that to the electrons, physics, etc.

------------------------------------------
         GOING HIGHER

  Map of City:



  Graph:



  Set:



  List:
------------------------------------------