Slashdot Mirror
Java Modeling In Color With UML
Background Back in my wild college days (ok, so maybe they weren't that wild ...), my introduction to object-think and object-speak came through two main conduits: Smalltalk, and Peter Coad. His Object-Oriented Programming helped teach me how to think natively in objects, and gave me my share of vending-machine problems. When I learned that he had come out with a new book, I knew I had to get it and see how his views had developed in the era of Java and UML. This was not what I had in mind. The Scenario
This book is mainly divided into three parts. Part one is composed of chapter 1, where the authors describe the concept of modeling with color. It's an excellent idea, really, color coding class design to distinguish the parts the objects play. Color coding has the advantage of adding another dimension of information to a diagram without clogging the diagram with more words. The chapter also includes a discussion of the "domain-neutral component," the fitting together of archetypes into standard patterns. This is the basis for part two, comprised of chapters 2-5. Part two is basically a series of object models strung together with a bit of text to describe each of them. Various views of the model, including UML activity diagrams, are shown. Finally, part three is composed of chapter 6, where the authors describe the concept of Feature-Driven Development, that is developing software in narrow slivers, thus maximizing deliverables and customer satisfaction.
What's Bad?A dangerous question to ask about this book. I approached this book looking for something that would teach me about patterns, what they do, some examples, and ways to use them in my work. What I got was a pattern dictionary with no instruction in their use. Since I get paid to design and write Java, and since I have some formal training in OO, I like to think that I have some sort of clue about this stuff. Unfortunately, this book still didn't make any sense to me, and still didn't seem useful at all. Why do I want 20 pages of manufacturing models? How did they come about? Why would I want to do it that way? How else could I do it? What the heck is going on with this model? It's like trying to expand your vocabulary by reading the dictionary, with no example sentences to guide you.
The other parts are mildly interesting, but not special in and of themselves. The color idea is nice, if you design like Coad. If you don't, I have to wonder how usful they would be. Feature-driven development has been expressed in other ways before, but this book does not address a major problem with the concept: how can you develop narrowly when you need a broad backing for the application? In other words, it's all well and good to get one feature out at a time, but if you have to write half the middle-tier and all the back-end for that one feature, have you really bought yourself anything? I don't mean to settle the debate here, only point out that an entire book could be written on that concept (and in the case of Extreme Programming, has been), and one chapter does not do it justice. In many ways, it seems tacked on.
What's Good?Well, as I said, the first and last chapters have some promise. If you read the comments on Fatbrain and Amazon, the opinions seem to be strongly divided. People either love or hate this book. If you need these models, and can intuit a lot from the diagrams, this book could be very useful to you. If you're anything less than an expert, though, I doubt what you will be able to get much from this book.
So What's In It For Me?I'm currently ordering Applying UML and Patterns, as that has been highly recommended to me as an intro patterns book. I'll let you know how that turns out. I do believe in the pattern concept, as that is exactly how the other engineering disciplines work. I truly hope we can make it work for software engineering.
Table of Contents- Preface
- About the Authors
- Archetypes, Color, and the Domain-Neutral Component
- Make of Buy
- Sell
- Relate
- Coordinate and Support
- Feature-Driven Development
- Appendix A: Archetypes in Color
- Appendix B: Modeling Tips
- Appendix C: Notation
- Index
This book is available at Fatbrain.
GOF = "Gang of Four"
Gamma, Vlissides, Johnson and Helm
The book is called Design Patterns : Elements of Reusable Object-Oriented Software .
Our dept. actually had Peter Coad come up and give us a seminar. It was actually really cool. His idea of adding colors to plain UML is nice and easily adds another dimension of description to plain diagrams. It also gets you thinking in terms of descriptors, and actions, and business processes, etc. He just seems like a really cool guy. And his Together products are really sweet. Except for the latest one where I can't figure out how to create a global class diagram for a package hierarchy.
It's 10 PM. Do you know if you're un-American?
Chapter 1 is the concept he's describing, modeling in color. Coad defines four archetypes, and associates a color with each. He gives examples of how to classify your classes according to these archetypes, and works into thinking in terms of them. He then introduces another abstraction, the "domain-neutral component," which is a large diagram template which can be customized to fit your particular situation(s). I had a bit more of an issue with this one. It seems useful, but I'm not sure that it doesn't stunt your thinking.
Chapters 2-5 are examples, in gory detail. He and his coauthors have defined 61! different domain-neutral components (which I honestly would call domain specializations of his overall Domain-Neutral Component). It's a catalogue, with fair descriptions, but I wouldn't put this into the category of Design Patterns, quite... I'm really not sure how to classify these things. (Have to think about that some more.) If you're familiar with OO, reading through this will educate you on the thought processes used to generate these things, and if you happen to have a problem that has pieces that fall into these 61 bins, you're set!
Chapter 6 is a departure. Feature-Driven Development is a "how to build what you've designed" process, and really doesn't fit the tone of the rest of the book. I found it useful (as I've posted elsewhere), but it's a jarring departure from the monotony of reading the catalogue of components. Well worth reading on its own - but not worth the cost of the book.
Appendices have large (readable) versions of the archetypes, and modeling tops.
Now - a bonus tip from Me to You. Go to Coad's company's web site ( Togethersoft ) and download their modeling tool (IMHO, beats the tar out of Rational Rose). Then, ask them nicely for a 30-day evaluation license, and do their tutorials. The tool does these components, and GOF Patterns, and lots of other fun things, and has a tutorial and examples of the Modeling in Color (although not Feature-Driven Development) from much of the book. Save your cash and do it in software :-).
I love vegetarians - some of my favorite foods are vegetarians.
I think the academic pressure to create something novel is what has fueled this UML-addon nonsense, things like JUML and others.
-ryan
"Any way you look at it, all the information that a person accumulates in a lifetime is just a drop in the bucket."
UML in Color is about the four archetypes of classes. These archetypes are Moment-Itervals (Something happening in time), Person/Place/Thing (Something in space), Role (an iteraction between a M-I and a PPT, and Description (meta data on a group of PPT objects).
The color helps to distinguish between each of the various archetypes (Pink for MI, Green for PPT, Yellow for Roles, and Blue for Descriptions). With the colors, UML diagrams become much more readable. Normally you end up with a backbone of pink MIs, representing the transactions that the system has to perform. The handfull of PPT objects interact along the way via the yellow Roles they can fulfill. Blues pop up when there are several PPTs that share the same characteristics. It works remarkably well.
While I found that the subject of the book (the archetypes and using color to represent them) very enlightening, the presentation was poor. The whole book comes accross as two or three magazine articles mashed together with a catalog of class diagrams. The most important information in the book is in the first chapter or two. Coad had posted most of it on the web at one point, I don't know if they are still there. Try at http://www.togethersoft.com
There does seem to be a paradigm switch involved. I found the technique immediately helpful. Others have a much harder time seeing how the archetypes are applicable to their problems (sometimes it is not). If you are an Object-Oriented designer, read the first chapter and file it away into your set of techniques. You can never have too many tools.
gwonkIts definitely true that you get more out of UML the more diagrams you use, and I think we agree that its a reasonable way to communicate a view of a project.
There's an AC post attached to mine that should really have been moderated up, pointing out that Christopher Alexander (on whose architecture work Design Patterns are based) made a distinction between formal and functional description, where the formal description describes what was done, and the functional description says why. I think this is important here: UML is a formal description. It needs to be accompanied by functional description to make useful sense.
Peter Coad loves to talk objects with anyone and is excellent at explaining himself. He had a 1999 JavaOne talk dedicated to this "UML Modeling in Color" idea and it was very informative and approachable.
Slashdot should conduct an "Ask Peter Coad anything" interview and give him the chance to clarify stuff in his book.
Also, since most IT development people are male, we have a much higher percentage of color-blind people amongst us than the general population. I personally know three other developers just in my circle of peers who are completely, if not partially color-blind.
It's fine if you can read and understand a diagramming method, but what about the person who ineviably must follow in your footsteps? We ought to try to always consider the person following in our footsteps, because most of the time, we are following someone else ourselves.
I saw this written somewhere: "I always try to write my code as if the guy who has to maintain it is a psychotic axe-murderer who has my name and address." - the same approach should be taken to documentation.
--
NO TOUCH MONKEY!
For UML, I prefer the UML Modeling Language User Guide by Booch, Rumbaugh, and Jacobson (Addison Wesley). More than other references, this book stresses constructs that you are likely to use most often.
The ideas in "Refactoring" by Fowler (Addison Wesley) seem almost entirely self-evident. Nevertheless, by reading this book, I improved my coding habits immediately. This book shows how to evolve a design as you code.
(Reality reasserts itself sooner or later.)
So what is color modeling? The review seemed to indicate that there might be something to this idea but didn't give out much details, or even a brief description, what it is.
I have my crayons right here with my UML diagrams. Should I just start slapping colors around everywhere, or is there a sort of a systematic way of adding colors?
Are different patterns displayed in different colors? Different class types? What?
I own this book, and I was honestly disappointed. I'd like to see this combined with "Java Design" and given some more fundamentals-of-OO/UML, maybe a sprinkling of component-based architecture, and then I think he'd have a heck of a book. On its own - it's thin.
I love vegetarians - some of my favorite foods are vegetarians.
My first out-of-college job was writing Ada on an Air Force contract, where the requirement was to write code that could be maintained by airmen with a 7th grade reading level. Ever tried to describe generics to someone at the 7th grade reading level? How about nexted SQL selects? Some parts of our software had three and four times the lines of comments as lines of code (plus all the USAF's required MIL-STD 2167A documentation).
I love vegetarians - some of my favorite foods are vegetarians.
Instead of it, we have now a "yet another book about the UML" syndrome, and it is worse: It was easy to say: "I'm using the foo methodology" (Booch, OMT, Objectory, Coad&Yourdon, Shlaer&Mellor, Martin&Odell...). It is now very difficult to explain: "I'm using the UML notation (as the UML is only a notation and not a method[ology]) with the foo development process (Coad's Feature Driven Process, Rational "Unified" Process, CISI Process...)".
The main problem is: each author uses the UML notation in his own way, especially the methodologists who jumped lately in the UML bandwagon. They cannot agree even on the use of the core concepts of the UML.
Fortunately, the Software Process Engineering Management Request For Proposition of the OMG and the UML Profiles mechanisms (see this OMG white paper ) should address this concern: It should allow to describe a development process in a little more rigorous way than the current informality and to precise the particular usage of each construct of the UML notation (or extensions of this core notation) in the context of a given development process.
A book exposing Coad's point of view on the UML will be a "good thing"(tm) only when we'll have such conceptual tools at our disposal. Before this moment, it only adds to the confusion of the newcomers to the UML.
Concerning the patterns, I think that the "Design Patterns" book (ISBN: 0-201-63361-2) of the so-called "Gang of Four" (Gamma, Helm, Johnson & Vlissides) is still the best book about patterns you can read. Each pattern is described by an OMT class diagram and C++ code but the translation into UML and Java is mostly straightforward.So much for the notion that the Slashdot book reviews always give good scores!
Christopher A. Bohn
cb
Oooh! What does this button do!?
This is one of those books which really should come with a prerequisite reading list. This book is not meant for someone trying to start learning about patterns. The reviewer should come back to it after reading Java Design (also by Coad) as well as at least one pattern book. I would recommend Mark Grand's Design Patterns in Java as a good place to start. The reviewer may also want to pick up some generic OO Design books.
The splintering of reviews on Amazon further reflects this required background. See the reviews of Coad's Java Design on Amazon for a further example of a mis-marketed book.
The author has a very good point about this book. It has absolutely no context on its own. However, If read and used in conjunction with "Java Design" also by Peter Coad et al, the design patterns described begin to be meaningful.
"Java Design" has the added advantage of some very amusing diagrams.
If someone would have given Judge Kaplan this book, it would have been clear that programming is an artistic expression.
I need a TiVo for my car. Pause live traffic now.
I thought you were subtracting arrays.
0x0D 0x0A
Naturally, all reviews end up being the reviewers opinion, even some may claim otherwise. So from that point it may have been a valid review.
However I think it would have been more interesting to read a review by someone that is knowledgeable about UML modelling and patterns. I got the feeling that there was some bitterness behind the review which made it less objective than they usually are.
I haven't read the book however, so I will not comment on it. Furthermore I found the UML Modelling book I have read (Using UML, Perdita Stevens, R. Pooley.) incredibly dull, although the concept is neat.
When most people talk about using the UML, they are referring to a class diagram. That, in itself, only begins to describe the project: it is enough for someone to go code up the data and members of the various classes, and not much more.
However, if you use the sequence, interaction, instance, and use cases, you get more brushstrokes on the canvas, and the thing actually begins looking like a real project.
I guess the idea I'm trying to get at is that each diagram attempts to communicate a different relationship. Some overlap, but for the most part it's true.
Some examples:
Dont underestimate the use of pictures. If they are truly worth a thousand words apiece, then imagine how much happier someone is going to be to look at the diagrams instead of reading ream upon ream of dry detail-filled dead tree pieces.
Even so, UML won't present a complete view of the project -- and people won't understand it just by looking at the "pretty pictures." However, if it manages to clearly convey even 80% of the scope of the project (which I feel is an attainable goal given intelligent application of the UML), just think about how many fewer questions you'll have to answer later.
-f
IMHO, IANAL, and all the standard disclaimers.
UML is a way to obtain an overview of a system. A few pages of UML are useful. If you're accumulating binders full of UML diagrams, it's probably not doing much for you.
My experience with UML is that the diagrams do not serve much useful purpose on their own. They almost always need to be accompanied by a verbal explanation of the problem being solved and the type of solution employed before they start to make sense. Possibly this is why this book does not go across very well. I do not see the addition of colour helping very much.
At best these kinds of diagrams and things are an aid to communication, but they are not a substitute for it, and they certainly are not a substitute for design. There seems to be quite a common belief that the existence of UML diagrams somehow implies that the design they represent is well thought through, or even coherent. It does not.