Skip to main content
skip to main content

developerWorks  >  SOA and Web services  >

The OO design process: Getting started

How to prioritize

Document options

Document options requiring JavaScript are not displayed

Rate this page

Help us improve this content

Level: Introductory

Allen Holub, Contributing Editor, JavaWorld

01 Jul 2000

Welcome to the first installment of this online class. My intent with this column is to provide a detailed experience in the object-oriented (OO) design and development process by actually having you do it. This column is more of a journey than an event, as it will take months to get through the entire process. We'll start out with requirements gathering, move through analysis to design, then do a Java implementation of that design. When we're finished, you'll have a complete case history of an OO program, literally from start to finish. I'll talk a lot about the underlying theory, but the central focus will be real examples of how that theory is applied.

Before we get started in earnest next month, I've a few warnings, comments, and observations that will give you a feel for my own prejudices and opinions on the subject of design.

OO isn't about structure

First, at its core, object orientation is not at all about derivation, class hierarchies, UML, Java technology, and so forth. These are tools that the OO designer puts to use in order to structure the analysis, the design, and the implementation, but they aren't central to what makes an OO program object-oriented. I'll certainly use all of these structural parts of object orientation as the process unfolds, but the first few columns in particular may seem mysterious to you if you equate implementation structure with object orientation. The key concept of object orientation is modeling, so before we can do anything, we have to decide what we're going to model. Adele Goldberg (in Succeeding with Objects, see Resources) recounts a story told to the congregation by a rabbi at the start of a new year:

A rabbi boarded a train, one on which he often rode and one whose conductor, therefore, recognized him. The rabbi reached into his coat pocket for his ticket. Not finding it, he began a search of his belongings. The conductor stopped him: "Rabbi, I know you must have the ticket somewhere. Don't bother searching now. You can send it later, when you do find it." But the rabbi kept searching. When approached by the conductor yet again, the rabbi replied: "You do not understand. I know you trust me for the ticket, but -- where am I going?

All too many projects fail because they begin without a clear idea of where they're going. The OO process tries to solve this dilemma by defining the problem to be solved as its first step; it will take me a few columns to do that in sufficient detail so that the actual analysis and design phase can proceed. That is, before you can analyze, you have to have something to analyze.

Back to top

Feel free to customize

Next, the process I'm describing is the one that I use personally. I don't intend these articles to be definitive. It turns out that the way that I work is similar to Booch, Rumbaugh, and Jacobsen's RUP (Rational Unified Process, see Resources), but that's not due to any planning on my part. Things just worked out that way. I also lean in the direction of Kent Beck's so-called Extreme Programming (XP, see Resources) but again, this is just a matter of chance. I'd expect that my processes will have to be personalized by you to make them workable. Given that the literature is singularly devoid of a hands-on discussion of any process whatsoever, it seems that a discussion of any process, even if it's a personal one, will be helpful. Please don't spend time contemplating whether I'm "right" or not; just bear in mind that what I do works for me, and that there's absolutely nothing wrong with changing what I do in a way that works better for you.

Back to top

Tools, or the lack thereof

A note on OO-design tools is also in order. Someone once told me that he couldn't do OO because he couldn't afford it: "Rose costs $2500/seat and you obviously can't do design without Rose!" The "Rose" in question is an OO CASE (Computer-Aided Software Engineering) tool sold by Rational Software. (I may review OO-CASE tools in a future column.) Putting aside the fact that Rose is neither the most cost-effective, nor the most capable, nor the most usable of the tools available, I often work effectively with nothing more hi-tech than a pencil and paper -- no computer at all.

As we'll see in upcoming columns, the process of OO design is really a form of semantic analysis. It has more in common with formal linguistics than traditional procedural-design techniques. I've found that computers often get in the way of this analysis. You spend more time fooling around with the tool than you spend getting work done. To make matters worse, many of these tools (Rose among them) are tied to hideous, draconian license managers that prevent you from running the tool on a laptop that's not connected via a network to the license manager. When I use a computer at all, I typically use a drawing program (Visio), not a CASE tool. (Which is not to say that I think that Visio is a particularly good tool for this purpose, either. I just happen to own a copy. I use my own templates -- see Resources -- not the built-in UML support.)

The point I'm making is that design has nothing to do with tools. Design is a way to crystallize your own thinking on complex topics, it's a way to make sure that you've covered as many bases as possible before you start to code, and it's a way to communicate with other programmers about the code.

Since communication is really central here, any tool that doesn't facilitate communication is virtually worthless. You are not communicating if you are sitting alone in your office in front of a computer-based CASE tool.

The choice of a CASE tool is irrelevant. I don't use any of them on a regular basis, though they can be helpful with larger projects. The downside is that they all generate miserable code, so I don't use the code-generation or "round-trip engineering" features of these tools. In any event, the notion of round-trip engineering -- in which you create a design, generate code, hack up the code, then reverse-engineer the hack back into a "design" is a fundamentally flawed notion. Design is inherently a one-way process. You design, then implement from the design. You modify the design, then implement the modifications. Most of these tools create incorrect designs in any event, because they can't adequately reverse engineer the dynamic behavior of the program simply by looking at the code.

A decent drawing program and a word processor are more than sufficient for our purposes.

Back to top

The design environment and tools

Design is always a group activity. At a minimum, you'll need a programmer, a tester, a customer (or somebody who understands the domain of the problem thoroughly), somebody who writes English excellently, and a UI designer. You'll ideally have some sort of clerical support as well: people to take notes and create transcripts, to enter hand sketches into drawing programs, and so on. You can get by without this level of support, of course, but the design will come together more slowly since the team members won't be able to focus.

All of these people have to be together to work effectively, and all of them have to be present all the time. Design is a full-time activity and nobody can afford to be distracted by other activities if you expect to finish in a timely fashion. (Virtual togetherness, using white-board software and the like, is a possibility, but you'll need video and audio feeds so you can see and hear everybody else, as well as the computer, if you expect to communicate effectively.)

One of the best design tools you can have is a room designed for that purpose. My ideal design room is a pleasant room. It has plenty of windows and light. The walls are covered literally floor to ceiling with white board. (You can buy 4x8 sheets of Melamine at a place like Home Depot and screw them onto the wall yourself if you like.) This is not a conference room -- toss the conference table and hideously uncomfortable chairs (designed, I think, to make conferences as short as possible), and replace them with a comfortable couch and a few armchairs. You'll need a well-stocked fridge and a few small tables that can be moved where they're needed. The main design tool in use will be the white-board marker and eraser, but you'll also want an LCD projector hooked up to a networked machine to make it easy for the group to work together on written documents. Images are transferred from the white board to the computer with a high-res digital camera. In the best of all worlds, you'd combine the design room with an implementation room of the type described by Beck in his XP book -- add a few workstation clusters and some private space for people to be alone when they need to be.

You won't find a space like this in a typical office, so you'll probably have to make one. Get out a screwdriver, rip up the cubes, and put one together. If the facilities people don't like it, tough. What's more important to the success of the company: producing high-quality software or supporting some archaic notion of what a "proper" office should look like?

Back to top

Design and architecture

One of the more heinous crimes perpetrated by Microsoft is the introduction of the verb "to architect" into English. Architects design buildings; they do not "architect" them. The reason I bring up this malapropism is that this specific abuse of the language artificially implies that a building's architect and a computer program's architect are engaged in fundamentally different activities. I strongly believe that architecture is architecture, whether you're designing a building or whether you're designing software. For example, Christopher Alexander -- an architect of buildings -- conceived the notion of a design pattern (see A Pattern Language: Towns, Buildings, Construction in Resources) and design patterns are fundamental to contemporary software architecture.

If you were to walk up to a contractor and say, "I want you to build a house for me; how much will it cost, and when will you have it finished?" he'd look at you as if you were crazy. Programmers definitively answer equally vague questions all the time, however, and people wonder why software is rarely delivered on time and within budget. Moreover, no contractor would even consider starting construction on something as complex as a building without some sort of plan. Plans developed by contractors themselves will typically not yield as nice a building as those developed by architects, however. Contractors will naturally design for ease of construction and low cost, which are not necessarily the best choices for a building that you plan to live in. Programmers, similarly, are typically not the best equipped people for designing programs, since they have different priorities than the end user. This is not to say that a good architect won't know how to construct what he's designing -- I'm convinced that the best software architects are also the best programmers -- but that design and construction are different activities and need not be performed by the same people.

The first step in designing a building is meeting with the client and figuring out how the building is going to be used. Architects are interested in the client's aesthetics, of course, but they ask many other questions. What are your hobbies? (Do you need specialized space for them?) Are there pets? (Do you want a cat-feeding station in the kitchen?) Do you have children? (Do they need a playroom?) How many? (How big should the playroom be?) All of these things influence the design of a building. If an activity that's going to be performed in the building is unfamiliar to the architect, then he or she will have to learn something about that activity to arrive at a satisfactory design. If the client is a koi keeper, for example, the architect is going to have to learn about pond technology -- not at the level of a koi keeper (a "domain expert" in design parlance), but at least at the level of a well informed layperson. Note that the emphasis is on how the building will be used. Construction considerations, though they're always in the back of the architect's mind and do influence the design, are not primary.

The next step is to sketch potential buildings, rooms, grounds, and so forth. Lots of things change at this point -- rooms move around and change shape, fixtures and walls are added and removed. Only when the client's needs are correctly reflected by the sketches will a set of "final" plans be created, but even these plans aren't really final. They're submitted to contractors and engineers, all of whom request changes, all of which (if they're visible, at least, or affect cost or schedule) are run by the client. Only then does construction begin.

The level of detail in the plans is also relevant. Much of the design work is done as the building is being constructed. The architect shows where the walls go, but the contractor figures out the details -- stud placement, framing for the windows and doors, and so on. The architect shows where the electrical outlets go, but the electrician figures out how to route the wires and where the electrical entrance goes. The plans show the drains and plumbing fixtures, but the plumber figures out how to route the pipes and hook up to the water main and sewer. That's not to say that these parts of the building aren't designed, but rather that this part of the design is done by the specialist who's doing the construction. This design work is often done informally -- on the site as work progresses. Moreover, most of the design artifacts, like scraps of paper with drawings on them or sketches made on studs inside the wall, are discarded because they aren't relevant after the object is built. When the specialist needs to do something that affects other specialists or the overall design of the building, then the ball is passed back to the architect, who modifies the master plans (after consulting the client).

Given simple and complex ways to solve the same problem, the simple way is always used provided that it doesn't impact the integrity or aesthetics of the structure. Nonetheless, sometimes the only way to do something is complicated. It's also important to note that the level of detail required before construction begins is a function of the complexity of the structure. You can design a dog house on a napkin. A house requires more detail. In a skyscraper, virtually every pipe and electrical conduit is designed (though the positions of the walls sometimes aren't!).

Back to top

Summing up

The process I just described is essentially the same process that I use to create software, and it's that process that this column will demonstrate piece by piece. Starting next month, I'll go into lots of detail so that the detail can be put into context. Many of these operations actually occur in parallel, and we'll see that in upcoming months:

  1. Learn about the problem domain.
  2. Interview the users and determine their needs and goals.
  3. Develop the problem statement.
  4. Design the user interface.
  5. Develop the use cases.
  6. Rough out a draft static model.
  7. Develop the dynamic model while refining the static model.
  8. Implement.

As I go through these steps, I intend to capture the entire process as it occurs, including the mistakes I make and how I fix them. By the time we're finished, you'll have a complete (and realistic) picture of the design process.

Back to top


Back to top

About the author

Allen Holub has been working in the computer industry since 1979. He is widely published in magazines (Dr. Dobb's Journal, Programmers Journal, Byte, MSJ, among others) and is a Contributing Editor to the online magazine JavaWorld. He has eight books to his credit, the latest of which ( Taming Java Threads ) covers the traps and pitfalls of Java threading. He's been designing and building object-oriented software for longer than he cares to remember. After eight years as a C++ programmer, Allen abandoned C++ for Java programming in early 1996. He's been teaching programming (first C, then C++ and MFC, now OO-Design and Java programming) both on his own and for the University of California Berkeley Extension since 1982. Allen offers both public classes and in-house training in Java technology and object-oriented design topics. He also does object-oriented design consulting and contract Java programming. Visit Allen's Web site at

Back to top

Rate this page

Please take a moment to complete this form to help us better serve you.

YesNoDon't know



Back to top

    About IBMPrivacyContact