CSci 581: Obj.-Oriented Design & Programming
Spring Semester 1999
Lecture Notes

Object-Oriented Design (Budd's UOOPJ, Ch. 3)

This is a set of "slides" to accompany chapter 3 of Timothy Budd's textbook Understanding Object-Oriented Programming with Java (Addison-Wesley, 1998).

Responsibility Driven Design (RDD)

Design technique that:

• Focuses on system behavior (i.e., actions) initially

• Can deal with ambiguous and incomplete specifications

• Flows from analysis to implemented solution in a "natural" way

• Integrates various aspects of software development

Directed Evolution

Take specifications as they occur in nature

• imprecise

• ambiguous

• unclear

Evolve the specification in concert with the design.

The Interactive Intelligent Kitchen Helper (IIKH)

Suppose you are the chief software architect in a major computing firm.

The president of the firm rushes into your office with a specification for the next PC-based product. It is drawn on the back of a dinner napkin.

Briefly, the Interactive Intelligent Kitchen Helper (IIKH) will replace the box of index cards of recipes in the average kitchen.

Your job is to develop the software that will implement the IIKH.

Capabilities of the IIKH

With the IIKH a user can:

• Browse database of recipes

• Add new recipes to database

• Edit or annotate existing recipes

• Plan meals consisting of several courses

• Scale recipes for any number of servings

• Plan a longer period, say a week

• Generate grocery list for all items in all menus for period

Characterization by Behavior

In using Responsibility Driven Design (RDD) we first characterize the application by behavior:

1. Capture behavior of entire application

2. Refine into behavioral descriptions of subsystems

3. Refine behavioral descriptions into code

This is the fundamental aspect of object-oriented programming.

Working Through Scenarios

The specification may be ambiguous.

Walk through application scenarios to uncover the desired behavior:

• Pretend already have working application

• Walk through the various uses of system

• Establish "look and feel" of system

• Make sure all intended uses are revealed

• Develop descriptive documentation

• Create the high level software design

Software Components

Software component:

an abstract design entity with which we can associate responsibilities for different tasks

May eventually be a class, function, module, etc.

A component:

• Must have a small, well-defined, cohesive set of responsibilities

• Should interact with other components as little as possible (i.e., have minimal coupling)

CRC Cards

Components are easily described using CRC cards.

CRC -- Component (class name), Responsibilities, Collaborators

• Use index cards: inexpensive, erasable, physical, small

The Greeter Component

First component defined is the Greeter

Writes a welcome message on the screen at startup

Offers the user a choice of actions:

• Browse database of recipes

• Add a new recipe

• Edit or annotate a recipe

• Review an existing plan for several meals

• Create a new plan of meals

Many details on how these are done can be ignored for now.

The Greeter CRC Card

The Recipe Database Manager Component

Ignoring the planning of meals for now, your team next explores the recipe database component.

• Must maintain database of recipes

• Must permit browsing of database

• Must permit editing or annotating existing recipes

• Must permit adding new recipes

Postponing Decisions

Many decisions (e.g., method of browsing) can be ignored for now.

They are encapsulated within the recipe database component -- do not effect other components.

• Scroll bars and windows?

• Virtual "book" with thumb-holes and flipping pages?

• Keywords and phrases?

Only need to note that somehow user can manipulate database to select recipe

The Recipe Component

Make recipe itself an active data structure -- maintains information, also performs tasks:

• Maintains list of ingredients and transformation algorithm

• Can edit these data values

• Can interactively display itself on screen

• Can print itself

We can extend to other actions later (ability to scale, produce grocery list, etc.)

The Plan Manager Component

Return to the Greeter, start different scenario

Identify the Plan Manager which:

• Permits selecting sequence of dates for planning

• Permits editing existing plan

• Associates with Date object

The Date Component

The Date component holds sequence of meals for sequence of dates

• Editing specific meals

• Annotating information about dates -- e.g., "Conrad's Birthday", "Thanksgiving Dinner", etc.

• Printing grocery list for entire set of meals

The Meal Component

The Meal component holds information about a single meal

• Allows user to select individual recipes from database

• Automatically scales recipe to user-supplied number of servings

• Produces grocery list for meal, combining grocery lists from individual scaled recipes

The Six Components

Having walked through the various scenarios, your team eventually decides everything can be accomplished using only six software components.

1. Greeter

2. Database Manager

3. Plan Manager

4. Recipe

5. Date

6. Meal

Figure 3.4 on page 40 of the Budd textbook pictures the communication patterns among the components.

Interaction Diagrams

An interaction diagram shows dynamic interactions during execution of a scenario:

• Labeled vertical line for each component

• Time increases from top to bottom

• Horizontal arrow for message sent (i.e., method call) from component at base to component at head

• Reversed horizontal arrow for return of control and/or data

• Commentary to explain interaction for an arrow

Figure 3.5 on page 41 of the Budd textbook pictures shows the beginning of an interaction diagram for the IIKH.

Instances and Classes

There are likely many instances of recipe, but they will all behave in the same way.

We say the behavior is common to the class of recipes.

Since earlier our goal was to identify behavior, we ignored this distinction and concentrated on prototypical objects.

Next Step -- Formalize the Interface

Formalize the channels of communication between the components

• Identify general structure of each component

• Make components with only one behavior into a procedure

• Implement components with many behaviors as classes

• Name each responsibility -- eventually become a procedure

• Assign information to each component

• Identify preconditions and postconditions for each responsibility and appropriate invariants for each class

• Replay scenarios to ensure all data is available

Coming Up with Names

The selection of names is an important task. Give it sufficient time and thought.

• Names should be evocative in the context of the problem.

• Names should be short.

• Names should be pronounceable (read them out loud).

• Names should be consistent within the project.

• Names should not have multiple interpretations. Use abbreviations with care.

• Names should use capitalization and underscores, but avoid digits.

• Names of booleans should indicate meaning of true value.

Documentation

In addition to CRC cards, develop other documentation from the project's beginning.

The two most important documents are:

• user manual

• system design documentation

User Manual

The user manual describes the application as seen by the user.

• Does not depend upon implementation -- can be developed before implementation

• Can naturally flow from walking through scenarios

• Can ensure the users and implementors have the same ideas

Quality

Always remember:

The primary measure of quality is the degree to which your customers (clients) are satisfied with your product.

• Be aware customers often unsure of exactly what they want

• Work with clients early in design to ensure development of "right" product

• Write user manual before software -- share it with the clients

System Design Documentation

Record the decisions made during system design.

• Record arguments for/against major decisions and the rationale for final choices

• Record CRC cards for the major components

• Maintain a log or diary of the project schedule

• Produce documentation immediately -- don't wait until major details forgotten

• Do not rely exclusively on code -- it records final outcomes, not factors leading up to decisions

• Keep documentation up-to-date and consistent as product evolves

Preparing for Change

Change is inevitable!

User requirements evolve, host platforms change, user organizations restructure, government regulations change, organizational missions shift, market expands (becomes global), etc.

• Design cohesive abstractions

• Try to predict most likely sources of change and isolate the effect

  Common changes include user interfaces, file formats, communication protocols

• Isolate interfaces to hardware and system software

• Reduce dependency of one software component on another

• Accurately document the rationale for major decisions

Next Step -- Select Representations for Subsystems

Select the internal representation for each component:

• Use knowledge of classic data structures of computing science

• Use knowledge of classic algorithms of computing science

• Use knowledge of available libraries

Step -- Implement and Test Subsystems

• Apply RDD recursively until subsystems sufficiently small and simple

• Use classic techniques (e.g., stepwise refinement) to design and implement internal representation of small, simple subsystems

• Refine preconditions, postconditions, and invariants for subsystem as needed

• Validate the subsystems in isolation:

  • Informally prove component is correct -- postconditions established, invariants preserved, preconditions of called components satisfied

  • Make sure error conditions handled safely

  • Use software testing to build confidence and test pragmatic considerations

  • Test subsystem using stubs for other subsystems -- i.e., unit testing

Step -- Integration and Testing

Carefully and incrementally integrate components into completed system -- i.e., integration testing:

• Use stubs for unimplemented components to perform testing throughout integration

• Test partially integrated system

• When errors discovered, make appropriate changes to subsystems, revalidate each, and repeat testing

• Replace a stub by another completed subsystem and repeat integration testing

Maintenance and Evolution

Software does not remain fixed after the first working version is released.

• Errors or bugs discovered -- must be corrected

• Requirements may change -- e.g., as a result of government regulations or standardization among similar products

• Hardware or operating systems may change

• Users expectations may change -- demand greater functionality, more features -- because of competition from similar products

• Better documentation may be required

A good design recognizes the inevitability of change -- plans for it from the beginning.

Common Design Flaws

Direct modification:

Classes that directly modify data in other classes violate encapsulation.

Such coupling results in inflexible designs.

Too much responsibility:

Classes with too much responsibility are difficult to understand and use.

Responsibility should be broken into smaller meaningful packages and distributed.

No responsibility:

Classes with no responsibility serve no purpose.

This often arises when designers equate physical existence with logical design existence.

Classes with unused responsibility:

Usually the result of designing software components without thinking about how they will be used.

Misleading names:

Names should be short and should unambiguously indicate which responsibility is involved.

Inappropriate inheritance:

This occurs when subclassing is used in situations where the concepts do not share an is-a relationship.

Acknowledgement

This Web document was based on a set of "slides" created by the instructor for use in the Fall 1997 offering of the object-oriented design and programming course. That set was, in turn, based on a set of slides created by Timothy Budd to supplement chapter 2 of his textbook An Introduction to Object-Oriented Programming, Second Edition (Addison-Wesley, 1997). The textbook for the current offering of the course is Budd's Understanding Object-Oriented Programming with Java (Addison-Wesley, 1998), which is an expanded, Java-specific variant of the earlier book.

UP to CSCI 581 Lecture Notes root document?