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

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• About the author
• Comments

Next steps from IBM

Spring, JRuby, and Ajax development is easier with WebSphere Application Server - a smart Java 5 and J2EE Web services-based application server.

---

• Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby.
• Article: The article leverage the Spring Framework and the WebSphere Application Server to improve your J2EE project productivity.
• Tutorial: See how the free WebSphere Application Server and XML can improve the efficiency of your JRuby on Rails and Ajax development.
• Buy: WebSphere Application Server - Express

My developerWorks community

Dig deeper into Rational on developerWorks

Try Rational System Architect

See how this fully integrated collection of models and documents can help you better align your IT systems and infrastructure to simplify business processes

Special offers