- Shopping Bag ( 0 items )
From the Publisher"...(an) exceptionally balanced and informative text."
+ Apply the basics of UML to your applications immediately, without having to wade through voluminous documentation
+ Use the simple Internet example as a prototype for developing object-oriented applications of your own
+ Follow a real example of an Intranet sales reporting system written in Java that is used to drive explanations throughout the book
+ Learn from an example application modeled both by hand and with the use of Popkin Software's SA/Object Architect O-O visual modeling tool.
"...a practical introduction providing an overview of the powerful new design notation...teaches java programmers to analyze and design object-oriented applications using the UML notation."
UML, the Unified Modeling Language, is the result of efforts by Booch, Rumbaugh, and Jacobson (aka "The Three Amigos") to combine and distill their individual graphical notations for software design into a single package. UML was adopted as a standard by the Object Management Group in October of 1997.
I approached Paul Harmon and Mark Watson's Understanding UML with the question: "What is UML, and how can I use it to build my engineering software?" I come armed with several years experience developing engineering and scientific applications using object-oriented methods, and I have taught a couple of object-oriented programming courses to engineers.
The production quality of this new text is high: standard glossy cover, with an XOR-ed picture of Stonehenge overlaid on some sort of greyed-out framework. The book is printed on heavy paper, and the layout includes wide margins suitable for notes. Alas, therein ends the positive part of this review.
I expected immediate and total immersion in UML. However, the authors seem to want to cover the entire object waterfront. Chapter 2 introduces "Taylor diagrams" to show how objects encapsulate attributes. In the midst of the chapter, Taylor diagrams are abandoned because "they don't scale up, and are hard to draw." The authors then betray a Java bent in their attempts to trash C++. Another apparent distaste for UML appears in Chapter 7: "There are several popular ways of describing workflows; most are based on some extension of what UML terms an activity diagram. The workflow diagrams we like best are IBM's LOVEM diagrams." So that is what is presented -- LOVEM diagrams.
Consider the table of contents:
2. Vocabulary of Object Technology
3. A Simple Object-Oriented Methodology
4. The UML
5. Coding Applications in Java
6. Development with an Object-Oriented Modeling Tool
7. Business Process Engineering
8. Use Case Diagrams
9. CRC Cards
10. UML Class and Object Diagrams
11. UML Sequence and Collaboration Diagrams
12. UML State and Activity Diagrams
13. Designing an Object-Oriented System
14. Choosing an Object-Oriented Architecture
15. Expanding Your Design
A. Java Example Program
B. UML Job Aid
C. Products Mentioned in this Book
D. Bibliography, Notes, and Web Sites
Two chapters are taken as "breaks" from consideration of UML, and they clearly have nothing to do with the subject. Why? The tip-off is the blow-in. A bookmark provided with the text is a business reply card to Popkin Software requesting an evaluation copy of SA/Object Architect. It cannot be simply a coincidence that SA/OA supports graphical representation for each of the "break" topics. Unfortunately, even in the break chapters, there are errors. The CRC presentation, for example, confuses the difference between classes and instances.
The first 12 chapters have an average length of 19 pages. Looking over the titles of these chapters gives an indication of the depth of treatment; that the presentation is thin is an understatement. Even so, the shallowness is only painful. The agony arises from the authors' many statements of the form "We won't talk about X because Y." Why waste the ink? I would much rather see the effort devoted to adding information than being told I'm not going to be told!
My goal was to reach chapter 13, "Designing an Object-Oriented System." Upon arrival, I found that it contained two diagrams: The first is the familiar Analysis, Design, Code, Test spiral, and the second, a bar graph showing that the design phase is where you should spend the most time in software development. Total length of the chapter? Five pages that wimp out with "Since this book is intended to introduce you to the UML notation, we do not provide a detailed prescription for designing OO applications." Argh!
I wish I had believed the authors in Chapter 2 when they wrote: "Once you have completed this book, you will need to turn to other books if you want to learn a detailed, step-by-step approach to creating a real OO application." Follow their directions now -- skip this half-baked goulash and buy a real book! By the time you read this review, I imagine the texts from Ivarson, Rumbaugh, and Booch will be available.--Dr. Dobb's Electronic Review of Computer Books