Newsletter sign-up

View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

When it comes to good OO design, keep it simple

Feature-rich OO design tools fail where simple solutions succeed

By Allen Holub, JavaWorld.com, 01/11/02

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.

 

XpoLog Center Correlate application logs with server metrics - XpoLog

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.