1 Observations on Pre-OO Programming Languages

1.1 The Roots of OOP

• OO programming and design have their roots in simulation.

• Simula (1967) programming language introduced objects & classes to describe the physical world being simulated.

OO programming and design have their roots in simulation. In the late 1960’s, the population of programmers was dominated by people who had switched fields, typically from the mathematics or physical sciences, rather than people who had originally trained in computer science. Indeed, academic programs in computer science were far less common than they are today, and tended to treat CS as more of a tool to be applied to application areas rather than as a field of study in its own right. Commonly, a CS degree program would offer two tracks - business programming and scientific programming.

One of the more active and exciting application areas at the time was simulation. Programmers in this area began to recognize common patterns arising over and over in their code. A number of code libraries were designed and distributed that attempted to capture and simplify these common simulation tasks. Eventually, special-purpose simulation programming languages were developed.

There was ample precedence for this kind of specialization. The dominant languages of the time were generally perceived as tailored to specific applications: FORTRAN and APL for science applications, COBOL for business, LISP for A.I., SNOBOL for text/string processing, etc. Any of these languages could have been used for other kinds of applications, but it was certainly easier to work with a language that matched well with the application area.

1.2 Tension in Pre-OO Programming Languages

The history of programming languages and of design can be viewed as a continual contest against increasing complexity of software systems:

Meanwhile, back in the “main stream” of programming language development, one of the main historic trends has always been trying to keep programs well organized even as programs get larger and larger.

2 Pre-OO Design Techniques

Observations

OK, let’s agree that a good ADT is a wonderful thing. Just where do good ADTs come from? Or, to put it another way, when you are designing a program, how do you figure out which ADTs you should use?

If you search the web for the term “abstract data type”, you will find lots of examples of things you might pull out of a library of data structures: stacks, queues, lists, etc. It’s easy to get the impression that an ADT is something that someone else provides for you as a convenient little package of code.

But that misses the point that “abstract data type” is an organizing principle for your own programs. ADTs for general purpose data structures are all very nice, but how do you come up with the special-purpose ADTs that organize your program in a way that is specific to the problem it solves?

Pre-OO design techniques were oriented towards functions performed by the program. For example, if you were working on automating the management of book handling in a typical library, you might start by dividing the system into major subsystems such as RecordStorage, CheckInOut, AccountMgmt, and InventoryMgmt. Under each subsystem, you would group functions to be performed, such as CheckOutBook, CheckInBook, and RenewBook under the CheckInOut subsystem, or addBook, removeBook, and transferToBranch under InventoryMgmt.

2.1 Stepwise Refinement & Top-Down Design

• The most fundamental design technique

  • Uses pseudocode

• Start with a single statement describing the desired behavior

• Repeatedly
  • Select a pseudocode statement that is too vague to be coded
  • Replace that single statement with two or more, slightly more detailed, statements that accomplish the same thing.

2.1.1 Stepwise Refinement Example

Automating book handling in a library:

• Might start by dividing the system into major subsystems such as RecordStorage, CheckInOut, AccountMgmt, and InventoryMgmt.

• Under each subsystem, you would group functions to be performed, such as

  • CheckOutBook, CheckInBook, and RenewBook under the CheckInOut subsystem, or
  • addBook, removeBook, and transferToBranch under InventoryMgmt.

If pre-OO designers were asked to design one of these functions, say, addBook, they would probably do so by “stepwise refinement”, a.k.a. “top-down design”.

Getting Started

Suppose we wanted to design the function to add a new book to the library’s collection.

• Designers would try to write out the simplest set of abstract steps that match their idea of what it means to “add a book”.

• For the purposes of this example, they might reason that this function must both update the electronic card catalog so that the book can be found, and must also record that the book is present in the inventory of a particular branch.

  Expressed as pseudocode:

function addBook (book, branchName)
{
  bookInfo = getBookInfo(book);
  record branchName as location in bookInfo;
  addToCardCatalog (bookInfo);
  addToInventory (bookInfo, branchName);
}

2.1.2 Refine One Thing

Next the designers would pick one of those rather vaguely understood lines of code in that function body and expand it, either in place or as a separate function. For example:

function addBook (book, branchName)
{
  bookInfo = getBookInfo(book);
  record branchName as location in bookInfo;
  // addToCardCatalog (bookInfo)
  add to AuthorIndex (bookInfo);
  add to SubjectIndex (bookInfo);
  add to TitleIndex (bookInfo);
  cardCatalog.addToAuthorIndex
  addToInventory (bookInfo, branchName);
}

The crucial idea here is that these new lines, taken together, add up to a method of achieving this line, the one we chose to expand.

We are not simply adding code. We are refining or expanding an abstract step into a series of somewhat more detailed ones.

If you, or another reader, do not believe that these lines add up to a procedure for achieving this line, then its time to stop and gp back. You’re doing something wrong.

2.1.3 Repeat

Moving on, we would againpick a vaguely understood line and expand it.

function addBook (book, branchName)
{
  bookInfo = getBookInfo(book);
  record branchName as location in bookInfo;
  // addToCardCatalog (bookInfo)
  //   add to AuthorIndex (bookInfo);
  authorList = bookInfo.getAuthors();
  for each author au in authorList {
    catalog.authorIndex.addByAuthor (au, bookInfo);
  }
  add to SubjectIndex (bookInfo);
  add to TitleIndex (bookInfo);
  cardCatalog.addToAuthorIndex
  addToInventory (bookInfo, branchName);
}

• The process of “pick something vague and expand it” continues until the desired level of detail has been reached.

3 Where are All the ADTs?

Stepwise refinement was certainly not the only pre-OO design technique, though it was probably the best known and most widely used.

However, nearly all pre-OO design approaches focused on behavior and functionality and on how to break those down into smaller pieces.

And that remained a problem, because ADTs are not so much about breaking behavior down as they are about gathering related behaviors together.

• In this example, we have mentioned nearly a dozen functions. None of them have been associated with an ADT.

• An experienced designer might spot some ADT candidates: Book, BranchLibrary, CardCatalog, etc.

• But there’s nothing in the step-wise refinement process that encourages or supports this.

Now, stepwise refinement is a valuable technique. It’s still probably the technique of choice for low-level design (the design of an algorithm for a single function). But it’s not nearly so useful as a technique for high-level design (the separation fo a large problem into separate modules). Consider that, at this point in our example, we have mentioned about a dozen different function names. None of them have been associated with an ADT. What are the odds that any of them would wind up inside an ADT? Pretty slim, usually.

An experienced designer might take note that the above process gives some hints as to some potential ADTs (Book, branchLibrary, CardCatalog, etc.). But this insight is pretty much separate from the design process itself. A designer has to be somewhat schizoid, actively participating in the design while simultaneously standing aside as a detached observer, watching for hints of possible ADTs.

When we move to Object Oriented Analysis and Design, our challenge will be to move the ADTs to the front of the process, to shift the focus away from functions and towards the data.

Does this men that we will never worry about designing single functions? No, of course not. ADTs have function members, and those will eventually need to be designed. But the emphasis will be on getting the ADTs first, and then starting on the design of the individual function members.

To put it another way,

• High Level Design is the division of a program into modules (ADTs).

  • This is where we will apply OOAD.

• Low Level Design is the design of a single ADT – its underlying data members and the bodies of its function members.

  • Here we can combine stepwise refinement for the function member bodies with the techniques you may have already learned in CS361 or other Data Structures classes to select appropriate data structures.