(none)

CS205 Notes 8 (4 September 2006)

cs205 Data Abstraction Notes
(Friday 8 September - Monday 11 September)

Upcoming Schedule

Every week: there are scheduled lab hours in Small Hall on: Sundays (7-8pm), Mondays (6-7pm), and Thursdays (5-6pm). I have office hours (in Olsson 236D) on Thursdays, 10:30am-noon.
Monday, 11 September: Finish reading Chapter 5
Wednesday, 13 September: Quiz 2 (originally scheduled for Monday, 11 September)

Data Abstraction

Data abstraction separates what you can do with data from how it is represented.

What are the advantages and disadvantages of using abstract data types?

What are the minimal operations a (useful) data abstraction must provide?

Specifying Data Abstractions

Overview: what does the type represent. Should always include:
- Mutability/Immutability
- Description of an abstract notation for the data abstraction
Operations: specifications for constructors and methods clients use described in terms of abstract notation introduced in overview. There are four different kinds of operations:
- Ways to create objects of the data type
  - Creators: create new objects of the ADT from parameters of other types
  - Producers: create new objects of the ADT from parameters of the ADT type (and other types)
- Ways to observe properties: observers
- Ways to change properties: mutators (mutable data types only)

Is it reasonable for a datatype to have no mutators?

Is it reasonable for a datatype to have no creators?

Is it reasonable for a datatype to have no observers?

public class Set {
   OVERVIEW: A Set is a mutable, unbounded set of objects of
      type T.  A typical Set is {x_1, ..., x_n }.

    public Set()  
       EFFECTS: Initializes this to an empty set: { }.

    public boolean add(T el)
       MODIFIES: this
       EFFECTS: Adds el to the elements of this:
                   this_post = this_pre U { el }
          Returns true iff el was not an element of this_pre.

    public boolean contains(T el)
        EFFECTS:






    public void union(Set<T> t)

What missing operations are needed for an adequate Set datatype?

Is it necessary to provide union?

Implementing Data Abstractions

The most important decision in implementing a data abstraction, is selecting the concrete representation and understanding the mapping between that representation and the abstract values. Abstraction Function

The Abstraction Function maps a concrete state to an abstract state:

AF: C → A

It is a function from concrete representation to the abstract notation introduced in overview specification.

   // AF (c) = { AF_T (c.els[i]) | 0 <= i < c.els.size () }

Representation Invariant

The Representation Invariant expresses properties all legitimate objects of the ADT must satisfy. It is a function from concrete representation to boolean:

I: C → boolean

To check correctness we assume all objects passed in to a procedure satisfy the invariant and prove all objects satisfy the invariant before leaving the implementation code.

public class Set<T> {
   // OVERVIEW: A Set is a mutable, unbounded set of objects of type T.  
   //      A typical Set is {x_1, ..., x_n }.

   // Representation:
   private Vector<T> rep;

   // RepInvariant (c) = c.rep contains no duplicates && c.rep != null
   //                    && all elements of c.rep are of non-null

If we instead used RepInvariant (c) = true which operations would be easier to implement correctly? Which would be harder?

Where can an implementer of a datatype assume the rep invariant is true?

Where must an implementer of a datatype ensure the rep invariant is true?

Graph

Here is the specification for a Graph datatype. It has some similarities to the DirectedGraph datatype from ps2, but some differences also.

public class Graph {
   // OVERVIEW: 
   //      A Graph is a mutable type that represents an undirected
   //      graph.  It consists of nodes that are named by Strings,
   //      and edges that connect a pair of nodes.
   //      A typical Graph is: < Nodes, Edges >
   //       where
   //         Nodes = { n1, n2, , nm }
   //       and 
   //         Edges = { {a_1, b_1}, ..., {a_n, b_n} }
   //         (note that the elements of Edges are unordered sets)

   // Creator
   public Graph () 
      // EFFECTS: Initializes this to a graph
      //      with no nodes or edges: < {}, {} >.

   // Mutators
   public void addNode (String name) throws DuplicateException
      // MODIFIES: this
      // EFFECTS: If name is in Nodes, throws DuplicateException.
      //    Otherwise, adds a node named name to this:
      //     this_post = < Nodes_pre U { name }, Edges_pre >

   public void addEdge (String fnode, String tnode) throws
      NoNodeException, DuplicateException
      // MODIFIES: this
      // EFFECTS: If s and t are not names of nodes in
      //    this, throws NoNodeException.  If there is already an edge
      //    between s and t, throws DuplicateEdgeException.
      //    Otherwise, adds an edge between s and t to this:
      //      this_post = < Nodes_pre, Edges_pre U {fnode, tnode} >

   // Observers
   public boolean hasNode (String node)
      // EFFECTS: Returns true iff node is a node in this.

   Set getNeighbors (String node)
      // REQUIRES: node is a node in this
      // EFFECTS: Returns the set consisting of all nodes in this
      //      that are directly connected to node:
      //         { n | {node, n} is in this.edges }
}

Select a representation for Graph. Consider carefully several different possible representations, and what their advantages and disadvantages will be.
Determine the rep invariant and abstraction function
Implement Graph (), addNode and hasHode
Implement addEdge and getNeighbors