MEETINGS

DJUG LINKS

WIKI QUICK LINKS

Book Reviews

This book review was submitted by a DenverJUG member as part of the Book Review Program.

BOOK DETAILS

REVIEWER

Raj Chaubal works as a Systems Analyst in Loveland, Colo. In the evenings (and through some nights with enough coffee) he works towards a masters degree in Computer Information Systems from Regis University. His hobbies include reading pulp fiction thrillers and visiting amusement parks.

REVIEW

The author reveals his desire in the preface: It’s to thrill Java programmers. These are folks who actually create Java software products. How will UML thrill them? Hello! Aren't they expected to know UML, OO concepts, and Java? Haven't they read the Martin Fowler and the Craig Larman books?

Yes, but thrills this book will deliver nonetheless. It will do so to its niche audience of intermediate to expert Java programmers. Additionally, the book will provide important information to others:

• Beginner Java programmers can use the book to gauge their progress.
• Business analysts and project managers will realize what's important to the programmers (just from reading Chapters 1, 2, 5, and 7). A cautionary note: the book leans strongly towards agile programming methods.
• Code maintainers, testers, and quality assurors will learn to refuse truckloads of nonsensical UML drawings and documents. Furthermore, they may start requesting pertinent UML drawings and documentation generated from code.

So, how will this book provide a thrill to Java programmers? Well, in two ways.

First, the book is not a didactic text. In fact it reads more like a pulp fiction thriller!

The plot moves quickly with crisp dialog, weaving UML 1 and 2, Java code, and OO principles. Real-world programs leap out from the dark. Bad UML elements, like dashed-lines, "has a" and "is a" are eliminated. Good UML 1.0 elements, such as half-arrowheads to denote asynchronous messages, are rescued. Each chapter is concluded to twist the plot deviously. Illustrations provide low-key humor. It’s based on a true story!

To fully savor the thriller, follow these guidelines:

• Read the chapters sequentially.
• Read at your own pace - based on your skill and experience in Java programming.
• Refer to other UML books, if necessary.
• Read each figure with its accompanying code. Go back and forth as necessary.

Second, reading the book will feel like spending a day in the amusement park!

Chapter 1 (Overview) will start your day with breakfast in the park. You will be shown why conceptual models don't jibe with code. You have to focus on specification and implementation level diagrams. You will be handed an informative pamphlet on key UML diagrams: class, object, sequence, collaboration, and state diagrams.

Chapter 2 will begin your morning stroll. You will learn answers to questions like: Why model? It's only to find out if something will work. When to draw? Use UML for communication. But, use code for algorithms -- it's easier to read. Why use CASE tools? These are expensive and mostly produce clutter. Invest in white boards, not in shelf ware. How to evolve UML diagrams? Start with behavior. How to keep drawings and documentation comprehensive? Practice minimalism by deferring these until the end of the project. Use JavaDocs.

Chapter 3 (Class Diagrams) will put you on a roller coaster. You will understand association, composition, and deep-copy. You will realize why aggregation is futile! An ATM class diagram with a code snippet will enrich you. Henceforth, your UML class diagrams will be sub-zoned properly. You will depict associations horizontally and inheritance vertically. Figure 3-20 may mesmerize you. It's on association stereotypes: create, local, parameter, and delegate. If you grok it, you may have a future as a Java programmer. Otherwise, your career is elsewhere! Those on the fence may hear muffled voices. Something like, "Aren't anonymous inner classes aggregation?" or "Isn't it composition if MyClass constructs YourClass?" Go over this chapter again, until you hush up.

Chapter 4 (Sequence Diagrams) will juice-up the roller coaster. You will first learn to sequence diagram, and the do’s and don'ts of it. (A typo on page 48: Read "nil" as "null." ) For example, don't make them complex. Don't create one for each and every use-case scenario. Next, in small doses you will be subjected to loops, race conditions, asynchronous messages (events), multiple threads, and active objects. The simple code in Listings 4-5 and 4-6, and Figure 4-13 will test your understanding of threads and JUnit. You may have cravings for odd things -- like sequence diagrams of design patterns, persistence, and transactions.

Chapter 5 (Use Cases) will soothe your nerves, but not the cravings. You will be shown use cases in a new light. You will see that use-case descriptions are important, but use-case diagrams and use-case relationships are time-consuming and useless.

Chapter 6 is time for lunch. You will visit OOD principles. Read the open-closed principle. Follow the code, particularly if you work with MVC and GUI components. There will be other specials: Liskov substitution principle, dependency inversion principle, and interface segregation principle. These form the foundation for good UML and Java (visit the author's web site for the acronym SOLID).

Chapter 7 will begin your afternoon adventures. You will discover a new dX methodology (visual pun of XP upside down). You will tour several XP/agile-like scenarios: customer stories, open-office environment, iterative development, unit tests; paired development, refactoring, and continual integration.

Chapter 8 (Packages) will raise your pulse again. You will discover how UML Package diagrams relate to Java packages, and UML Component diagrams to JAR files. You also will be introduced to five principles of package design. All except the Acyclic Dependency Principle are simple heuristics; cyclic dependency between packages cause build failures. You may walk out a tad better at organizing large-scale Java applications.

Chapters 9 (Object Diagrams) will put you on a new ride: the terror-dome. Once again, active objects and threads will be brought in. You will see that object diagrams are better than class diagrams for following multiple threads. You may recall from Chapter 4 that this was also the case with sequence diagrams.

Chapter 10 (State Diagrams) is the terror-dome on full throttle. You will experience super-, sub-, and pseudo-states. You will envision event-action pairs and reflexive transition. You will develop a fear for state-transition diagrams. State-transition tables will become safer bets.

Chapter 11 is time for cocktails. You will be shown a wrong and a right way to design. You will be shown how to design software by focusing on the essence of a problem. You will be shown that nouns, like boilers, valves, heaters, and sensors, have little meaning outside English, such as in designing software to control a coffee maker. You may begin to seek out designated UML experts to drive you home safely.

Chapter 12 is the grand finale -- dinner and smooth jazz. You will be served a full-blown case study: 3,000 lines of code including unit tests, with text and UML diagrams as sides.

Finally, you may wish to shut your eyes and relax a bit. But they want you out! It is 2 a.m. and the bookstore is closing! So hustle and buy this thriller! It could be your season ticket to the amusement park!