Customer Reviews

Java Modeling In Color With UML: Enterprise Components and Process

5 star:		(10)
4 star:		(3)
3 star:		(3)
2 star:		(4)
1 star:		(7)

 

 

The people who trashed this book didn't do much with it, that's clear. When you first go to the book (or if you've seen Coad speak, as I did @ JavaOne), you will think that Mr. Rogers is trying to talk you into teaching you a new way to program w/crayons. I was also struck by the proliferation of classes that Coad advocates. However, I have returned to this book a number of times, in part because Coad's tool Together/J is now the preeminent Java/UML tool, it makes Rational look like a set of tinker toys. This last time, I've become quite enamored with what is going on in here. Here are my suggestions: 1. Really try and understand the DNC (domain neutral component). It is a very good approach to a kind of design completeness theorem that I haven't seen much talk about elsewhere. 2. Look at the diagrams. I look at them over and over again. After going a couple of rounds I found that I was becoming addicted to the visualization process, not merely as a representational apparatus, but as a way of actually doing more work/understanding the work I'd already done.

If you get the 30 day eval of Together/J and you work through understanding the DNC and color, you'll pass into another dimension from which you will not readily want to return. Plain white UML is dimensionless to me now.

All that said, I gave the book a 4 because it really needs an update. The FDD (feature driven development) methodology is not really interesting or appropriate anymore, I think. In the new massively interconnected, distributed component world, features are not what its about anymore, unless you're developing a word processor. Also, the archetypes are based on a non-EJB approach that will change if distributed computing is applied to it, quite significantly. Still this is an important book and combined w/TogetherSoft's tool it's perhaps the best design/UML teaching combo available. There aren't enough books out there that have models for real things in them. This does that and a lot more.

This book is strange in that I can understand the poor ratings it has got and the good ratings. It is like 3 books in one with the middle book being the meat of it. The first book is one chapter on the color and archetypes. This work is fascinating and takes modeling to a new level. Just being introduced to this idea is worthy of 5 stars. The last book is one chapter on process. The ideas presented here are also fascinating, but like the color chapter, it is one chapter only and requires a few reads for it all to sink in. The material and ideas presented are really deep, but are well worth the effort to understand and then learn. This really feels like breakthrough work. The middle chapters are numerous models for different domains using the color and archetypes from chapter one. This is like reference material.

This book is at least 3 books in one. If you are a serious modeler or process person, you must have this book. If you are one of the many who just get by in computing, you'll not understand it and write a very negative review.

I have read many books on OO design and analysis. I have a good theory of how to do OO O&D, but I have not always applied it well. And I have seen very few example of actual systems that were OO and well thought out. What I lack, and what I think many other developers lack, is practice, or examples of good work that can be emulated. I bought this book because I saw it was full of examples that go into great detail.

Unfortunately, I had trouble understanding how the examples were created and whether the results were effective in the real world. Reading the first chapter was like reading the Rosetta stone and it sort of explained what followed. But it wasn't enough! I was left as the archeologist of some very exotic, very interesting sequence diagrams. I had many many questions about how the design was done and for what reasons the authors created certain classes. There were many examples and many of the designs were very surprizing to me (especially the many classes that were "verbal" and the usage of many apparently redundant objects).

After reading this book I am left with as many questions as answers. Is that good or bad? Either way, it was an interesting read. Sadly, I have to give this book 3 starts because though it tantilized me with new ideas, it didn't communicate them to me. It just showed them to me and demanded that I accept them. I need the rest of the Rosetta stone please!

Some interesting ideas are put forward in this book but a lot of it is repetition and padding. There is, for instance, a whole chapter on why the four particular colours used (red, blue, green, yellow) were chosen but the whole edifice falls down when it is admitted that they were the four colours available on the Post-It notes that were initially used.

Overall, there is very little about the use of colour. The book deals primarily with attempting to apply the author's preferred pattern to a limited number of scenarios. Examples are obscure and explanations non-existant. The models are presented as a fait-accompli. This misses the point that if the users were familiar with the way the models were created then they wouldn't need the book!

This book is good for people with little experience in Java modeling. The examples, although incomplete, are good when viewed in this context.

This books presents a modeling method applied to common business subsystems. The method is sound and works. The modeling effort in the examples doesn't go all the way but it's relatively easy to complete most of the models covered.

I used this book to "reengineer" a development team in OOA/OOD and Java, and it worked perfectly. I recommend this book to everyone looking for examples and directions on how to model in Java.

Don't be fooled by the colors and informal communication style. It takes talent to deliver state of the art software development theory in such an easy to understand and practical way.

Consider industry thinking on Business Object Component Architecture. Consider IBM's SanFrancisco project with 4 BOCs completed. This book gives us 12! (My copy accordingly has 12 colorful sticky tags.) If someone has seen a more intuitive, comprehesive set of components, please let me know.

As Dragan's review says, these guys have done the "heavy lifting." Building on this book's BOCA even the poorest programmers will end with superior software.

And anyone who doesn't sense the far reaching implications, as Booch implies, of the colors and the "domain neutral component" either doesn't have the ability to do abstract thinking or just isn't paying attention. I didn't believe it until I added color to my own UML diagram.

I purchased this book after reading Peter Coad's article on the same subject in the March 1999 issue of Software Development magazine. I had high hopes, but when I read the book I was greatly disappointed. The book is basically a repackaged version of the article appended with some component models that are freely available on Web. The layout and formating of the book makes it difficult to read, the flow is choppy, and it appears to have been hastily assembled.

This is unfortunate, because the subject of utilizing fundamental archetypes combined with color coding is an important one. I also agree with another reviewer about the suspicious nature of a reader's 5 star review that is posted on Amazon also appearing on the cover of the book. One more indication of the amateurish nature of this publication.

I think this book shows a very novel way of approaching OO Design work. In teaching OO design at the consulting firm for which I work, I am always looking for good books to point the students at. This one does a fine job of teaching good design practices and shows novel methods for easily determining a class' purpose when a developer glances at a UML diagram. This book, when used in conjunction with the patterns books by Mr. Coad, and the Gang of Four, can help bring a novice OO designer up to speed very quickly.

This book has a high school flavor in a number of ways. First, the book uses a large font and extra wide margins. It has large colorful icons to make sure you are aware of tips or points of interest (sometimes 3 or 4 on a page). I guess having a tip's paragraph start with "Tip." in bold font isn't enough for most people to notice. (The book uses a very small font to list the method names and attributes in the diagrams, so you have to squint to read those. ) Second, and much more disturbing, is that many of the sentences read like they were written by high school students. There are plenty of sentences that aren't sentences, they ramble on referencing 3 or 4 items and quite often each item has an explanation in parenthesis after it, or there is a qualifying exception phrase thrown in to qualify something that has been mention previously, so it difficult to follow what the author is trying to say - kind of like this one. Third, there are meaningless comments from Aerosmith like "Pink is my favorite crayon". Need I say more? Finally, the author uses several pages to point out that color coding makes things stand out. He even admits that someone had to point this out to him!

I read the first two chapters and found myself rereading sentences and explanation over and over trying to decide what the author was trying to say. The explanations are not insightful and the UML is not explained.

One final comment: How is it that the first "customer" review listed below, which rates this book a rediculous 5 stars, ended up on the back cover of the book?

The book's UML diagrams are very necessary for understanding the book but the diagrams are illegible due to the use of miniscule font. The text of the book has a good font but half or more of the pages of the book are UML diagrams.