 | 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.
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.
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.
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?
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!).
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:
- Learn about the problem domain.
- Interview the users and determine their needs and goals.
- Develop the problem statement.
- Design the user interface.
- Develop the use cases.
- Rough out a draft static model.
- Develop the dynamic model while refining the static model.
- 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.
Resources - Check out
Succeeding with Objects: Decision Frameworks for Project Management
by Adele Goldberg and Kenneth Rubin, a stunningly good book for managers who want to move their shops into an OO environment.
- RUP (the Rational Unified Process) is described by Ivar Jacobson, Grady Booch, and James Rumbaugh in
The
Unified Software Development Process
.
- XP (Extreme Programming) is described by Kent Beck in
Extreme
Programming Explained: Embrace Change
. XP is controversial, but I expect that a lot
of the controversy comes from people making assumptions as to what Beck is talking about without having first read his book. XP and RUP actually integrate quite nicely, as described by Grady Booch in a draft chapter of his new OO-Design book, found at www.objectmentor.com (PDF).
The ObjectMentor
Web site also has a wealth of useful material on this topic.
- You can get a copy of my UML templates for Visio from the Goodies section of my Web site.
- Read more about design and architecture in
A
Pattern Language: Towns, Buildings, Construction
by Christopher Alexander, Sara Ishikawa, and Murray Silverstein.
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 www.holub.com. |
Rate this page
| |
