[Skip Navigation] [CSUSB] / [CNS] / [CSE] / [R J Botting] /[CS320 Course Materials] /14.html [14.txt(Text)] [Search ]
Tue May 7 17:00:59 PDT 2013
[Schedule] [Syllabi] [Text] [Labs] [Projects] [Resources] [Grading] [Contact]
Notes: [01] [02] [03] [04] [05] [06] [07] [08] [09] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]

Contents


    CS320/14 Data Abstraction


      Table
      Prev 13Functional ProgrammingChapter 15 not section 8lab13 LISP103
      14 Data AbstractionChapter 2 section 14 + Chapter 11lab14 C/C++ ADTs
      Next **Project Deadline Phase 2Phase 2 due in: changed EBNF and draft UML (10pts)
      Next 15OO Programming and JavaChapter 2 section 17 + Java Handout + Chapter 12 lab15 Java101

      (Close Table)

      Preparation

    1. Study Chapter 2 Setction 14 on Ada.
    2. Study the Supplement below
    3. Study Chapter 11 on Data Abstraction
    4. Answer the review questions at the end of chapter 11.
    5. Hand in 2 questions.

      Supplement

        The Stack ADT

        [ stacks ]

        Ada

        The complete definition of Ada 83 -- the Language Reference Manual ( LRM) is on file at [ lrm ] There are many samples of Ada code in [ http://cse.csusb.edu/dick/cs320/ada/ ] The Gnu C++ and C compiler suite includes Gnat compiler for Ada -- but I don't think we have implemented it, yet. There is a compiler for Ada that produces WWW Applets. I have a CDROM advert for it.

        Interface, Implementation, Abstract, Concrete

        I will use the term interface for a completely abstract description of a data type with all implementation details hidden. This means an API (Application Programmer Interface). In essence an interface is a list of function prototypes or subprogram protocols. It states the operations that can be invoked. An interface is an inter-face: a layer separating two components. One side of an interface is the implementation. On the other side are the pieces of code (clients) that make use of the interface. never forget that there are two sides to every interface: provider and requirer.

        Notice that if an object is in a class that implements an interface then the compiler can make sure that all the operations applied to the object are in the interface. The actual class of the object does not matter.... all that matters is that the object's class fits the interface. This is like a modular phone jack!

        There are many ways to implement the same interface. Each implementation completes the function/operation/subprogram definitions in a special way.

        An abstraction has some details hidden (to-be-announced) and some defined.

        An abstract subprogram, function, or operation has no body. An abstract class has a mixture of defined functions, abstract functions, and variables.

        There are many ways to implement (completely define) an abstraction. The defined parts provide a framework. The undefined parts are places to plug in specific pieces of code into the framework. An example would be a class that defines a 'sort' function but does not define a function that tests if two objects are in order. By supplying the definition of this function you can plug-in your own sort order.

        A concrete module has all its details defined. There is enough information available for objects of a concrete class to be constructed. As a result you can do any of the defined operations with objects that have a concrete type.

        Abstraction and Interfaces in C++

        [ 14interfaces.cpp ]

        Abstraction and Interfaces in the UML

        UML has several notations concerned with data abstraction. It defines the stereotype <<interface>> and the constraint {abstract}.

        A dotted or dashed open arrow joins an implementation to its abstractions. A closed dotted arrow shows that a class uses an interface to access an implementation. There is a special "lollipop" notation indicating a piece of code that implements an interface. Or you can add <<interface>> as a stereotype to a class box.

        Interfaces in UML

        In UML 2.0 the arrow and lollipop notation has become a "cup-and-ball" notation.

        Here is an example, in Java we may want to create a class that is an Applet in a web page, and also reacts to what the user does with mouse, and is also multithreaded. The diagram shows the Java Virtual Machine using our class via two interfaces:

        ThreadMouseListener is an Applet that is threaded and listens for mouse events

        Describing Interfaces

        An interface is a collection of functions, operations, and perhaps constants. Many just use their favorite syntax for classes. It is harder to express the meaning of the operations. The best technique is to describe a set of contract that holds between the client of the interface and its implementor. Contracts have pre-conditions and post-conditions.

        Client programmer: I don't worry about how you code it as long as

        • I guarantee the pre-conditions will be true when I call this function.
        • (so you don't have to test them).
        • I assume that the post-conditions will be true after it finishes.
        • (so I don't have to test them).
        Implementor: I don't worry about how you use my function as long as
        • I assume that the preconditions will be true when the function is called.
        • (I don't have to test them).
        • I guarantee that the post-conditions will be true just before I return control.
        • (so you don't have to test them).

      . . . . . . . . . ( end of section Supplement) <<Contents | End>>

    Class Work

    [ 14q.html ]

    Lab Work -- Spot the ADT

    [ lab/14.html ]

    Next -- OO and Java

    [ 15.html ]

( End of document ) <<Contents | Top