Rating: 
Summary: Terrific, high-level reference
Review: 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.
Rating: 
Summary: quite unhappy
Review: I first read this book in December '99...since that time I have referred to it dozens of times as I explain the use of Color Archetypes as an incredibly valuable visual extension to UML. I also refer to it frequently today as I help domain analysts create business models not from scratch but from business component archetypes that "more or less" fit the environment - this saves teams countless hours as they "just try to get started." And finally, this book is the current definitive published word on Feature Driven Development, an Agile process. Thank you Peter, Jeff and Eric for your work...please update it soon!
Rating: 
Summary: A partial Rosseta stone and many many Tablets
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!
Rating:
Summary: Nice concept, but too limited to have <b>staying power</b>
Review: I often test the utility of a book by one of two ways:
1) Did it expand my thinking?
2) Do I constantly refer to it after reading it the first time?
The seminal patterns book, Design Patterns - by Gamma et al, (also known as the GOF) passes both tests. This book does not. I haven't had much use for this book since purchasing it in 1999. It seems Ironic, somehow, since enjoyed the Togethersoft UML refresher training I received in 2000.
Together/J, supports the UML methodology, and also supports for the these models outlined in the book. That said, it's worth borrowing a copy to see for yourself. I'd also recommend downloading the current 'whiteboard' edition from Togethersoft. Jeff Grayson borrowed my copy when he was working on a project to improve VIANT's software development methodology with the Rosetta project.
Rating:
Summary: Buy this book if you need some modelling ideas
Review: I reviewed this book in January this year and haven't opened it since, until today. Looking through it, I noticed something blindingly obvious that I had entirely missed before: There is no Java code anywhere in the book! (There is a single Javadoc example [of a non-standard Javadoc tag they've proposed] on page 5 but no explanation of what use to make of it.) What about the subtitle - "Enterprise Components and Process"? To me that means there'll be mention of clients and servers, or networks or the internet or the web. Nothing. What is an Enterprise Component or Process? You'll never know since it's never mentioned inside the book. What does that leave? Given that colour is only discussed in Chapter 2. Basically, it is a book showing what they've done with UML with little or no information on how you can do it too.
Rating: 
Summary: Not a book on Java and UML!
Review: If you are looking for a book on Java and UML or a book that is about UML and uses Java examples; This IS NOT THE right book. The authors give you their way of patterns or archetypes that they call it. If you already know UML and what to see if there is other techniques or ways of extending UML this is the right book for you. Another thins about the colors, The idea is new but not a very good one. Often you tend to print you diagrams and show to other people. If you depend on their way of modeling you'll have to get a color printer and since there are text in the colored areas you'll need an expensive printer.
Rating:
Summary: This book advocates but doesn't teach.
Review: 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!
Rating: 
Summary: Don't Be Fooled
Review: 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.
Rating:
Summary: Deep
Review: 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.
Rating:
Summary: Ignore the Java
Review: Though "Java" is in the title, this book is not limited to Java, and, indeed, there are no Java code examples. Usage of UML, however is extensive. The book presents an approach to generalizing business components (modelliing patterns - referred to as archetypes) that really helps one to understand the structure and interaction of business components. I use this book as a regular reference. It includes a near-complete business component model through 12 compound components.
| 
