[Table of Contents] [Previous] [Next] [Object Central Home]

The Essence of Object-Oriented Programming

Copyright © 1998, Bruce E. Wampler

    3.1  Introduction to Software Engineering
    3.2  OO Methodologies
    3.3  Why does OO work?
    3.4  Chapter Summary


Chapter 3
Object-Oriented Software Engineering

This chapter will provide a general introduction to software engineering. Some of the traditional software engineering methodologies will be discussed, followed by a more complete summary of object-oriented software engineering. This chapter is presently under construction, so is incomplete. Nevertheless, the information presented here is still relevant.

3.1  Introduction to Software Engineering

Most traditional software engineering methodologies start with an initial feasibility study, followed by an analysis phase, followed by a design phase, followed by implementation and testing. Figure 3.1 shows the basic waterfall software development life cycle, which form the basis for most software development methodologies in use today.


Figure 3.1: The Waterfall Software Life Cycle

In the classic waterfall model, each step or phase of the development process is carried out sequentially: first the feasibility, then the analysis, then the design, and so on. Over time, modifications to this strict sequential process have been developed. Almost all methodologies are some variant of these steps.

Small or large, every software development project will benefit by having an analysis and design effort before writing and testing any code.

3.2  OO Methodologies

Object-oriented methodologies include more or less the same steps as the classic waterfall life cycle, but typically have more overlapping of the steps, especially during the analysis and design phases. For smaller projects, it is often difficult to distinguish the analysis and design steps.

In addition, OO methodologies allow you to carry out the whole development process in a more piecewise fashion. Once you have identified an object, you can often complete the design, implementation, and testing of that object separately from other parts of the system. And once object have been implemented, they often can be reused in new systems. Reusing objects is much easier than reusing functions or modules from non-OO systems.

There are several object-oriented methodologies in use today for performing analysis and design. Each methodology has its own vocabulary, notation, graphical icons, and detail. Even so, all these methodologies tend to unify their notation for both analysis and design, and each uses the basic object-oriented approach described in the last chapter.

Some object-oriented methodologies include:

Booch
One of the better known and most complete notations. Objects and classes are represented by clouds, and there are many special symbols to represent different relationships1.

Coad-Yourdon
An elegant, simple notation. Analysis and design notation are identical2.

CRC
CRC is an acronym for ``class-responsibility-communication.'' Objects are documented on cards that address the CRC of each object3.

Design Patterns
Especially useful for designing object-oriented frameworks. Uses Object Model Notation4.

Firesmith
An elaborate notation with separate icons to represent a variety of different categories of objects such as sequential, concurrent, concrete, and abstract abstract5.

Jacobson
A notation where different kinds of objects such as entity, interface, or control objects have their own icons6.

Object Model Notation
A notation similar to Coad-Yordon7.

While these methodologies have different notations, most share many basic concepts for doing object-oriented analysis and design. Rather than trying to weigh all the pros and cons of the different methodologies, we pick one to discuss in some detail. This book uses a simplified version of the Coad-Yourdon methodology for object-oriented analysis and design.

Of all of the OO methodologies in use, Coad-Yourdon is one of the simplest. One big advantage is that it uses exactly the same graphical notation for both analysis and design. The other methodologies add at least some new symbols for design. As always, there are pros and cons, but we will opt for simplicity, which allows us to focus on the analysis and design and not the notation.

3.3  Why does OO work?

Structured Design tends to be done in terms or concepts of sequence. First, do this, then do that, and so on. OOD is done in terms of objects, their state, their behavior, and their interaction with other objects. The thought process is not the same. You can still use structured techniques for designing the implementation of the various methods, but that must come after the overall object design is completed.

If done right, an OO design is produced first. If your design gets close to having the right objects and interactions, you've already partitioned the problem into very natural and understandable parts. At this stage, it is much easier to deal with the details of each class and object. It is possible to concentrate on one class at a time. It is acceptable to lose sight of the big picture when doing this. In contrast, you must always keep the big picture in mind when using structured design and programming techniques.

3.4  Chapter Summary


[Table of Contents] [Previous] [Next] [Object Central Home]

Visits:


Footnotes:

1 Grady Booch, Object-Oriented Analysis and Design with Applications, Second Edition, (Benjamin/Cummings Publishing Company, Inc., 1994).

2 Peter Coad and Edward Yourdon, Object-Oriented Analysis, 2nd ed. (Yourdon Press/Prentice Hall, 1990); and Edward Yourdon, Object-Oriented System Design, An Integrated Approach (Yourdon Press/Prentice Hall, 1994, ISBN 0-13-636325-3).

3 The notation was developed by Ward Cunningham. See Beck, Kent, and Ward Cunningham, ``A Laboratory for Teaching Object-Oriented Thinking,'' OOPSLA '89 Conference Proceedings, 1989.

4 Wolfgang Pree, Design Patterns for Object-Oriented Software Development, (Addison-Wesley, 1995).

5 Donald G. Firesmith, Object-Oriented Requirements Analysis and Design: A Software Engineering Approach (John Wiley and Sons, 1993).

6 Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgarrd, Object-Oriented Software Engineering: A Use Case Driven Approach (Addison-Wesley, 1992).

7 James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen, Object-Oriented Modeling and Design (Prentice Hall, 1992).