Level: Introductory Parshu Anantharam, Senior Software Engineer
30 Jan 2004 from The Rational Edge: This review examines a book designed for software engineers seeking to improve their use of Unified Modeling Language (UML)-based tools for designing and developing Java software.
by Robert C. Martin
Prentice Hall, 2003
ISBN: 0-13-142848-9
Cover price: US $39.99
240 pages
|
This book is very practical and highly usable by any software engineers
seeking to improve the manner in which they apply Unified Modeling Language
(UML)-based tools for designing and developing Java software. UML, a graphical
notation for creating diagrams of software concepts, is useful for depicting
a problem domain, a proposed software design, or an already completed
software implementation.
The author has tremendous credibility in the world of object-oriented
design (OOD). The president of a leading consultancy, he has authored
books on software development, C++, and eXtreme Programming, and is a
well-known speaker at international events for developers. His thought
leadership is particularly evident in the book's second chapter,
which represents a major departure from traditional arguments for modeling.
When he asks, "Why model?" his response represents a refreshingly
different viewpoint: "Models help you find out if something will
work." This implies that models must be testable; if you can't
evaluate the model, then it has no value.
The "voice" in this book is like that of a coach providing
guidance on how to use UML to build software, specifically with Java.
Martin describes the features and concepts of UML versions 1 and 2 that
are directly relevant to writing better Java software -- and ignores features
irrelevant to Java developers. He explains what problems UML can and can't
solve, how Java and UML map to each other, and exactly how and when to
apply those mappings.
Rather than covering all the different diagrams in UML, this book discusses
only those that are most useful and that make programming easier. I really
liked this selective aspect of the book; by narrowing his scope, Martin
could focus on both the UML specification and implementation-level use
of UML to communicate precise, unambiguous descriptions of proposed designs
and existing code.
The design guidelines and heuristics in this book are potentially highly
valuable for OO designers. Martin demonstrates that there is much more
to OO design than simply drawing UML diagrams. What matters most is thinking
about the consequences of each design decision. The diagrams make
it easier for designers and programmers to see these consequences
-- if they know what to look for -- and then be able to deal with them.
Here are some highlights from the guidelines that Martin provides throughout
the book, on making effective use of UML for Java programming:
- UML is very good for communicating focused design ideas but not particularly
good for communicating algorithmic detail.
- UML can be useful for creating roadmaps of large software structures.
These roadmaps give developers a quick way to discover class dependencies
and provide a reference to the structure of the whole system.
- The best time to create a design document is at the end of the project,
when the document can accurately reflect the state of the design when
the team "finished" the project. This back-end documentation is useful
to an incoming team, but Martin cautions that such teams will not want
to pore through thousands of sequence diagrams! Rather, they need a
few very salient diagrams that highlight the system's major issues.
- Get into the habit of throwing away your UML diagrams. Better yet,
get into the habit of not creating them on a persistent medium; Martin
suggests putting them on a whiteboard or scraps of paper. However, he
also notes that some diagrams are useful to save: These are the diagrams
that:
- Express a common design solution in the system.
- Record complex protocols that are hard to see in the code.
- Provide roadmaps for areas of the system that are not touched
very often.
- Record designer intent more effectively than code could express
that intent.
- Remember that UML is a tool, not an end in itself. It can help
you think through your designs and communicate them to others. Use
it sparingly, and it will give you great benefit. Overuse it, and
it will waste a lot of your time. When using UML, think small.
The book also contains many examples of Java code alongside the UML
diagrams. In teaching OO design courses to professional software developers
hundreds of times over the past twelve years, Martin observed that most
students tend to make the same types of design mistakes. In one chapter,
he presents a few of the most common errors and discusses how to correct
them. For example, students often forget to use methods. When designers
create diagrams without methods, they may partition the software based
on something other than behavior. Students also tend to create "God"
classes; they concentrate all the intelligence of a system into a single
object or a single function. This violates a goal of OOD, which is to
partition and distribute behavior into many classes and functions.
Case study demonstrates elegant design solution
Finally, the last chapter of the book is a case study that demonstrates
how to solve a design problem in a way that neatly resolves all the design
forces (i.e., all the factors you must consider in creating a design).
How does Martin do it? The trick is to step back and separate the details
from the system's essential nature. The case study is about designing
software to control a simple coffee maker. Begin by forgetting about boilers,
valves, heaters, sensors, and all the little details, he urges, and concentrate
on the underlying problem. What is that problem? In this case it is how
do you make coffee?
How do you make coffee? The simplest and most common solution
to this problem is to pour hot water over coffee grounds, and then collect
the resulting infusion in some kind of vessel. Where do we get the hot
water from? Let's call it a HotWaterSource. Where do we collect the coffee?
Let's call it a ContainmentVessel.
Do these two abstractions represent classes? Does a HotWaterSource have
behavior that can be captured in software? Does a ContainmentVessel do
something that software can control? If we think about the coffee maker,
Martin explains, we can imagine the boiler, valve, and boiler sensor playing
the role of the HotWaterSource. This HotWaterSource would be responsible
for heating the water and running it over the coffee grounds to drip into
the ContainmentVessel. We can also imagine the warmer plate and its sensor
playing the role of the ContainmentVessel. It would be responsible for
keeping the coffee warm, and also for letting us know whether any coffee
is left in the vessel.
How would you capture these qualities and descriptions in a UML diagram?
Figure 1 (based on Martin's figure in the book) shows one possible
schema. HotWaterSource and ContainmentVessel are both represented as classes
that are associated by the flow of coffee.
Figure 1: UML diagram for coffee maker based on physical problem element
This association illustrates an error that OO novices commonly make:
It focuses on a physical element of the problem instead of on the control
of software behavior. The fact that coffee flows from the HotWaterSource
to the ContainmentVessel is completely irrelevant to the association between
those two classes.
For example, what if the software in the ContainmentVessel told the
HotWaterSource when to start and stop the flow of hot water into the vessel?
This might be depicted as shown in Figure 2 below (also based on Martin's
figure in the book).
Figure 2: UML diagram of coffee maker based on software
behavior
As Martin notes, the lesson here is simply this: Associations are the
pathways through which objects send messages. They have nothing
to do with the flow of physical objects. He then goes on describe
how to design the user interface for the coffee maker, walking the reader
through each design step.
This case study is very effective; it is small and easy to understand.
And it shows how you can use the principles of OOD to manage dependencies
and separate concerns.
Overall, the final chapter is a fitting conclusion for this useful,
practical book. I'd recommend it for any Java developer seeking
to learn how to apply UML.
About the author  | | | Parshu Anantharam is currently a senior software engineer at a company in Clayton, MO. He develops and builds test environments consisting of IBM midrange systems and middleware, as well as applications being developed using Java, XML, and Oracle. In addition, he works with IBM Rational Robot to develop and support test automation efforts. He holds a bachelor's degree in computer engineering from an institution in Mumbai, India, and has worked in the software field for the past twelve years. |
Rate this page
| 
