Grady Booch

There are too many books about methodologies and very few good ones that describe the design process for real world applications.
For this reason the "applications" word in the title of this book is very appealing to me and I guess to most software designers.
So the first big disappointment is that of the about 700 pages of this book only 200 pages cover the "applications" aspect.
Other disappointment is that almost 200 pages are bibliographic references in different forms !! !!
The final 300 pages, that are the first part of the book, are mostly a personal view of the authors (I guess Booch is the author of this section) about complexity and object oriented modeling methodology. I say just modeling and not design or analysis because there is no description in the book of a true analysis or design process but rather of a methodology to model an existing design using OOP and UML.
The author point of view is that there is an "object oriented methodology" that is completely self contained in the use of strongly typed OOP and UML notation, this is THE methodology, all the rest is accessory or maybe alternative (but suboptimal). In my opinion the book is in a certain sense very good at proofing the contrary, that object orientation "alone" is not enough, but the diatribe on methods and frameworks is a never ending argument. For those who are interested on the "analysis methods" topic I would suggest books of David C.Hay (a very interesting paper on the subject of this book is here: http://www.essentialstrategies.com/documents/ooa.pdf) or Martin Fowler, Analysis Patterns book.

Let's go back to the "applications" section of the book.
The 5 examples described in the 200 pages are all very different in complexity but the problem is that some of them generate an outcome that is different from what the reader would expect given the title of the book, unless we suppose this book was targeted to newbies or graduate students.
The result is that the 5 examples together are not able to convey the idea of object orientation as a framework that per se can drive and fullfill the processes of analysis and design.
In some of the examples object orientation just looks like a graphical view of the author solution to the described problem, just a way to braindump an implementation in form of diagrams. And some of the 5 examples describe systems that are so complex that even just a description of the final design would be unrealistic in only 30/40 pages.
Another issue are the biblical bibliographic references, too many and many of these are outdated for a 2007 edition of the book, for example one of the 5 applications turns all around the blackboard design pattern and the author doesn't make any reference at all to the PoSA book but rather references an old paper from 60's :(.

Final issue that is quite serious for me is in the diagramming styles, there are at least 4 different UML styles, from black and white clean diagrams to diagrams in shades of gray generated by some programming IDE to diagrams to others that are sketched using other diagramming tool and so on, some of the diagrams also have lack of UML style, with arrows pointing in any possible direction, etc.
That's not acceptable for a 70$ book about software design.… (altro)