CMIS 240  DE

Week 2


Read chapter 2 this week.

The first section about different views or perspectives of data is a
bit confusing but the library analogy is useful to get an idea of what
the author means:  

Application/user level of data is how the data type might be used in
an application program (e.g. by a programmer using the String ADT
class to declare string variables (aka "objects") to represent names
and then to call functions (aka "methods") that manipulate that data).

Logical/abstract level is what the set of data is (e.g. a String
object is a sequence of characters) and what can be done to it (e.g. a
String object cna be input and output, it has a length, it can be
copied to another String object, etc.).

Implementation level is how the ADT is actually implemented
(e.g. String has an underlying array or linked list [chapter 5]; it's
not built-in to the language like array, struct, and class are).  

You as a programmer may be only a user of the ADT (such as when you
use the built-in array and struct types in C, those ADTs have been
implemented by the compiler writers; or when you use someone else's X
class).  You might be an implementer of an ADT when you create a class
type, such as a String class, in C++.  You or other programmers could
then be users of that class for various applications.

The Abstraction and Built-in Types section discusses familiar arrays
and structs using ADT terminology and the three perspectives.  It
makes the three levels idea more understandable by using something you
already know.  The implementation level of arrays and structs might be
new to you.  An array element is accessed by offsetting from the
memory address of the zeroth element a number of bytes equal to the
size in bytes of an element times the index. 2D arrays are similar but
more complicated, the author has decided you don't need to know how to
do it.  The author uses "cell" for the addressable unit of memory, but
it's synonomous with byte on almost all machines nowadays. Questions
10-12, 14, and 15 on page 98 gives some practice in array element
address calculation.  Question 17 is good for thought.


Higher Level Abstraction and the C++ Class Type introduces the class
type of C++.  Read this carefully, we'll be doing classes for the rest
of the course.  Let's use the DateType class as our first class
example. This chapter is only the introduction to classes and OOP;
we'll learn much more about it as we progress through the course. 
 
Chapter2/ at the class web site has datedr.cpp (main function "driver"
that tests the DateType class; it's scattered in pieces in the book)
and DateType.cpp (implementation of the DateType member functions).
It's conventional to place the class declaration in a .h file with the
same name as the class (this includes the same capitalization) and the
definition of the class function members in a .cpp file with the same
name as the class too.  Download these three files and figure out how
to create a multifile program on your compiler.  I've put a document
on the class site that describes how to do so under Unix, rhide,
DevC++ and VC++.  I've put a Makefile there also.  Other compiler
users will have to read their compiler documentation.  I strongly
recommend reading the chapter on classes of the 140 textbook (or the
relevant chapter from your 140 textbook if you didn't use
Dale/Weems/Headington).  Our book's treatment of classes is too
skimpy, you need to have more information presented to get a good idea
of the syntax and semantics of classes; there's a lot of new material.


The Case Study designs (logical level), implements (implementation
level), and uses (application level) a String class.  The .h and .cpp
files for this class are in the Chapter2/ directory.  I had to fill in
some missing pieces from the book's online code.  This example leaves
something to be desired: there's too much detail about newlines,
non-alphanumeric chars, to skip or not to skip, file or keyboard, the
forest is hidden by these twigs.  The GetStringFile function and its
auxilary functions aren't online.  I don't want to make all those
functions, nor should you, so I've modified the driver program to use
input from the user and not from a file (makes it easier to use the
program too).  Also, GetAlpha() and GetNonWhite() have been commented
out of the implementation StrType.cpp file.

Download all three files: StrType.h, StrType.cpp, and stringdr.cpp.
There's also a Makefilestring if you want it (change its name to
Makefile).  Get the program running on your system.  The practice
exercise (see below) will be to modify this StrType class.

Capitalization is part of the "spelling" of a file name.  For class
declaration and implementation files (i.e. the .h and .cpp files) the
filenames are conventionally the exact same as the class name.  So if
a class is DateType, its declaration file is DateType.h, and its
implementation file is DateType.cpp.  Notice the case of the letters.
Nobody is using DOS, so there's no reason not to have the correct
case of the letters of the filenames.

In general, don't bother too much about the Test Plan sections in the
book.  

**********************************************************************

Practice Exercise, not to be turned in


Questions 24a and 25 of chapter 2.

Use the code I posted as the base that you modify.  Keep all their names
exactly the same.  Don't use any nonstandard features (e.g. conio.h or
dos.h).  Don't make any other changes to the class.

Add to the test driver stringdr.cpp code that finds the "largest"
string in the words array.  By largest I mean the string that is
GREATER than all others, determined by using the ComparedTo function
member, which means alphabetically largest.  This is simply a search
of an array to find the maximum element.

Question 25 illustrates that an implementation of a class can change
without requiring any change in the application using the class.