The single most useful book on modeling I've ever read. This is not a java design pattern book, there really isn't any java in it at all. This is less a cookbook than a book on the theory of cooking.

The central idea in this book is the 'Domain Neutral' design pattern. Read until you understand that, and then read again while you apply the idea a couple times in real life. Then you will be in awe. If you are looking for the answer to 'how do I model a shopping cart step by step' this is not the book for you. If you are a working designer who faces new domains every few days and needs a sharp utility knife in your toolkit this is it.

8 years later I'm still referring to this book occasionally and practice it's ideas constantly. I can't say that about any other technical book I own besides richie/kernighan's classic.

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.

This is an excellent book. It is, however, terse and has taken me a long time to get to grips with its content and language. I have had to read several of the Coad books to 'get it' but it's finally coming together. I would recommend you read it in conjunction with (or maybe after reading) "Streamlined Object Modeling" by Jill Nicola (and would love to see her do a follow-up book). To those that say there is no Java in the title: look at the CD.
To be honest I think all the Coad books are good (the "Java Design" book is really good too and was my first contact with Coad's books), some are dated but still stand up. They do take a lot of the guesswork out of modelling.

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.

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.

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.

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.

The text walkthroughs for each UML diagram (which is most of the book) is practically useless since it mostly only reiterates what one obviously sees on the diagram. I wished at least one set of these diagrams was carefully explained, then I might have gotten something out of it. You can read the book many times as I have, but I don't think it will really help you with addressing one or more modelling challenges you might have.

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!

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!

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.

In my point of view the only thing that is nice in this book are the free business models that you get on the CD. They can offer you some insights about how to model roles, parties in a business relationships. The book itself is a puzzle for a software engeneer has I am. I more often have to model low level things has database access, and workflow events than business requisites. This book does not explain how we can complement the business models that are presented with more lower level object interactions. I could not deliver my developers any of these models becouse from the technical point of view they would not know what to do with it. After reading the book and strugling to find the most effective path in the puzzle I realize that this book is not for software developers but more for business modelers that worry about details. But if you want to impress a customer with colorful diagrams describing the requirements that were discussed in the last meeting this is the book for you. On the other hand, why waste the time ...?

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.

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.

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!

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design

ISBN: 0137488807

The reviews are much better than this one.

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.

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.

Placing this coloring book on equal ground with 'Design Patterns' is like saying a serious treatises on painting techniques is comparable to a paint-by-numbers pamphlet. This one is not worth your time.

Probably one of the best books I've read since the 'Design Patterns'. The FDD design process is quite unique and solid. The book lacks cohesiveness at places, but makes up for it by providing good modelling examples. I would strongly recommend this book.

How could such little design effort have gone into a book about design techniques?

Don't waste your time and money on this poorly written and "amateurish" (as another reader points out) coverage of an important subject. The brief first chapter another reviewer considers a stand alone book could easily be condensed into a few pages. The thin coverage this book gives to an important topic is a real disappointment. It seems simply to be a book whose selling point is that names of hot topic are in the title. This book is clearly not a reference like 'Design Patterns'. I agree with the previous reviews who find some of the 5-star reviews to suspicious.

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 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 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.

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?

This book claims to teach you how to produce better models, faster - and it does!

I went for a job interview. The interviewer asked me to model a payroll system and gave me an hour to work it out while he observed. So I built a model using pink moment-intervals, yellow roles, green things, and blue descriptions--classes, attributes, links, methods, interactions. After 25 minutes the interviewer stopped me, saying I had already gone well beyond what others struggle to do in a full hour! So my recommendation is: read this book! It's made me, a better modeler and I'm sure it will do the same for you.

Another great innovation in this book, is Feature Driven Development. Its been used on a huge Java project. I am currently trying it on a medium sized eCommerce project which is Object-Relational and uses Java and PL/SQL and it works equally well.

The key to FDD is that it is a low overhead method which was designed by developers for development. It scales easily from large to small projects , in a remarkably linear fashion, whilst providing the finest grained and most accurate project tracking and reporting that I have ever seen in almost 18 years in the business.