When it comes to good OO design, keep it simple

Feature-rich OO design tools fail where simple solutions succeed

A former student of mine once blurted out the preposterous statement, "I can't possibly do object-oriented (OO) design; I don't have the money!" Inquiring further, it turned out that, in his mind, OO design required a product called Rational Rose, which at the time cost about ,500.00 per seat. In his mind, without Rational Rose, design wasn't possible. Unfortunately, this sort of balderdash is widespread; too many people think OO is a high-tech process requiring high-tech tools. In practice, exorbitantly priced tools sit unused on the shelf (or are vastly underused).

With that in mind, in this article I discuss various OO design tools, how they work, and why I think they're not useful. I also explain how I work, and what does prove useful (at least to me; you're welcome to disagree).

The tools don't guide you through the process

Every successful OO design I've come up with has followed roughly the same process:

  • Learn about the problem domain (accounting, lesson planning, etc.)
  • Develop, in close consultation with a live user, a problem statement that exhaustively describes the user's problem, as well as any domain-level solutions. This document does not describe a computer program.
  • Perform a formal use-case analysis, in which I determine the tasks required to solve the user's problem, again, working closely with a real end user. Typically I create a UML (Unified Modeling Language) activity diagram for every nontrivial use case. (UML is a symbolic representation of the software as a picture.)
  • Start building the dynamic model showing the objects in the system, and the messages those objects send to one another, while a particular use case is being acted out. I use a UML sequence diagram for this purpose.
  • I simultaneously capture useful information on the static-model diagram. Note: I never do the static model (class diagram) first. I've thrown away too many static models that turned out to be useless once I started to do the dynamic model. I'm no longer willing to waste the time required to do the static model in a vacuum.
  • The aforementioned steps typically yield two or three use cases, after which I begin coding, fixing the model if necessary.
  • Lastly, I work on another use case as described, refactoring the design and the code as necessary to accommodate the new case.

None of today's design tools guide you through this process. For the most part, they're over-priced drawing programs that don't work particularly well, even as drawing tools. (Rational Rose, which I consider one of the least capable of the lot, doesn't even support all of UML.)

Round-trip engineering is a fundamentally flawed process

Not only do these tools not work well, the one trick these tools do perform -- generate code -- is worthless. Almost all OO design tools follow the notion of round-trip engineering in which you begin in a design tool by specifying your design in UML. You create two essential sets of diagrams: the static model showing the classes in the design, their relationships to each other, and the methods they contain; and the dynamic model, which is a stack of diagrams that show the objects in the system performing various tasks at runtime.

Once you complete the model, you hit a magic button, and the tool generates code. However, the tool-generated code isn't particularly good for two reasons: First, in many tools, skeletons for the class definitions are created, but the methods are simply empty stubs -- the dynamic model is ignored. Second, no tools fully support UML, primarily because none can. UML is a language in its own right, which encourages improvisation, and much of the actual design content is expressed in comments typically ignored by the design tool.

As a result, you hack up the generated code (most shops really do hack it). Within a few weeks, the code typically has little or nothing to do with the original design. In fact, you effectively throw away your design and fall back into the WHISKY syndrome (Why isn't someone "koding" yet?). Years and years of failed programs prove to me that coding without a design increases overall development time by at least a factor of three, and results in much buggier code.

Now comes the round-trip process: You open your tool, push the magic button, and import the code, theoretically rebuilding the design so that it reflects the actual state of the code. Such reverse engineering doesn't work, though. The tools typically create new class diagrams, but never update the dynamic model. Since the dynamic model is central to the process, your design is now worthless unless you go back and update it by hand, something rarely done.

At the risk of repeating myself, the round-trip process encourages programmers to ignore the design entirely and just code, then reverse engineer the code into pictures every so often. In this situation, however, the programmers aren't designing; they're hacking code, then creating pictures of the resulting mess. Hacking doesn't equal design.

While design is indeed an iterative process (the design changes as the code is developed), you should start an iteration by modifying the design first, then refactoring the code to reflect the new design. To do this, you'd have to be able to specify the entire software product within the tool (when you pushed the magic button, a fully-functional program would be output) and the process would be one-way without a reverse-engineering mechanism.

The CASE tools

CASE (computer-aided software engineering) tools like Rational Rose typically put round-trip engineering at the product's core. However, since the round-trip engineering doesn't do anything useful, many developers use the tools as expensive drawing programs. Of the tools available, I think three are worth considering (though I don't use any of them):

  • The free, open source ArgoUML tool, written in Java, does a reasonably good job of UML diagramming. The latest version even attempts to guide you through the process (with marginal success so far, but it's a good start).
  • Embarcadero's GDPro, formerly distributed by Advanced Software, offers good support for a group working on a single software design, but also has deficiencies in this department. For example, a designer can't check out a dynamic model diagram while automatically locking the classes associated with objects on the dynamic model.
  • TogetherSoft's Together ControlCenter sidesteps the reverse-trip problem by not doing it. The code and the design appear on the screen simultaneously, and when you change one, the other changes automatically. Together ControlCenter doesn't support groups of programmers well, though.
  • I should also mention Microsoft's Visio briefly. Visio is a drawing program that does support UML after a fashion, but its support mimics Rational Rose's miserable UI. Various drawing templates for UML shapes in Visio work better than the built-in UML support, including one in the "Goodies" section of my Website.

So, if I think so poorly of these tools, what do I use? By far the most productive OO-design tools are a whiteboard (a room with wall-to-wall, floor-to-ceiling whiteboards is ideal) and flip-chart-sized Post-it pads, sheets of which you can peel off and stick on the wall. I've used these to design significant projects with great success. Moreover, working on a whiteboard consumes vastly less time than wrestling with an OO CASE tool.

The only difficulty with the whiteboard approach is capturing the information on the board. Whiteboards that print do exist, but they're expensive, ungainly, and too small. One neat hardware product that tracks the movement of a pen across a whiteboard and captures the pen strokes in the computer. Other whiteboards work like giant digitizer tablets. However, these solutions prove too limiting; design takes place simultaneously on whiteboards in several offices, on napkins, on scraps of paper, and so on. You can't carry a 300-pound printing whiteboard to the local cafe.

So what works

So what's a mother to do? How do you capture these artifacts to archive them within the computer so they will make reasonable documentation as they stand, without having to transfer them to a drawing program?

The solution:

  1. A digital camera
  2. A wonderful software product called Whiteboard Photo from Pixid

A digital photo, unfortunately, frequently produces images unsatisfactory for documentation. To compensate, Whiteboard Photo turns digital pictures into something useful. Pictures are really worth a thousand words, here. Figure 1 shows a typical digital photo of a whiteboard.

Figure 1. A digital photo of a whiteboard. Click on thumbnail to view full-size image.

Figure 2 illustrates another example.

Figure 2. Another digital photo of a whiteboard. Click on thumbnail to view full-size image.

Figure 3 shows how Whiteboard Photo transforms Figure 1.

Figure 3. Whiteboard Photo transforms the photo from Figure 1. Click on thumbnail to view full-size image.

And here's how Figure 2 looks after Whiteboard Photo did its magic.

Figure 4. Whiteboard Photo's representation of Figure 2's photo. Click on thumbnail to view full-size image.

As the images show, the difference is amazing. To tranform the original image into the cleaned-up version, I simply hit Ctrl-L. The software automatically found the whiteboard's boundaries, corrected for the distortion caused by taking the picture from an angle (necessary to avoid the glare from the flash), picked out the design's lines, and drew them. All the product needs to achieve perfection is hand-writing recognition, but I'm tickled pink with it as it stands. I can now produce documentation-quality drawings directly from the original whiteboard, without wasting hours entering the drawing into some lame excuse for a CASE tool.

Keep it simple

In my experience, when it comes to OO design, low-tech tools work best. Indeed, they're faster, easier to use, and perform well in collaborative environments. So far, I've found that the combination of a whiteboard, a digital camera, and Whiteboard Photo offers the best method to get program designs into a machine.

Allen Holub provides consulting services, training, and mentoring in OO design, OO process, and Java programming. He regularly presents an intensive OO design workshop for those interested in quickly developing their OO skills. (Find more information at http://www.holub.com.) Allen has worked in the computer industry since 1979, most recently as chief technology officer at NetReliance, Inc. He is widely published in magazines (Dr. Dobb's Journal, Programmers Journal, Byte, and MSJ, among others). Allen has eight books to his credit, the latest of which -- Taming Java Threads (APpress, 2000; ISBN: 1893115100) -- covers the traps and pitfalls of Java threading. He teaches OO design and Java for the University of California, Berkeley Extension (since 1982).

Learn more about this topic