As others have stated, the content of this book is a tremendously important contribution to object-oriented analysis and modeling. The authors have successfully analyzed and pared down OOA to it's very essentials. Until you read this book you will not truly understand the significance of this. They have discovered an amazingly small set of irreducible patterns (not to be confused with design patterns, these are analysis patterns) and rules which can be applied to the modeling of any business domain - large or small, simple or complex. And which, when applied, lead to accurate and consistent models in the most direct and timely manner possible. No matter what methodology you subscribe to, if modeling the domain is one of the practices then this is how the modeling should be done. Study the patterns and rules, internalize them, your productivity will soar, your colleagues and customers will consider you a genius. It should not be hard as the presentation is clear and logical and the patterns and rules themselves have the simple elegance that fundamentally correct solutions usually exhibit. However, the authors are not ivory-tower academics presenting some arcane theory that is purely descriptive. They are practitioners with years of real-world experience, thus they show us the whats AND the hows. And they do not stop at analysis, the authors also do us the great favor of showing us how these patterns and rules actually end up being implemented in real code. This book now sits at my side as an essential reference. I plan to refer to it for my work, of course, but also to 'test' models I come across in other books.
I'm very surprised at the low Amazon.com sales rank of such a unique, insightful, and practical book. With agile and "extreme" methods and practices all the rage you would think a streamlined, dare I say 'agile', approach to modeling would have recieved more attention. I suppose the publisher missed a great opportunity by not putting "Agile" somewhere in the title. Having been the XP 'evangelist' and coach on an XP project I think it even has a place in XP (though purists will argue that point). This is my biggest problem with XP - XP recommends coming up with a "metaphor" for an application which gives the project "conceptual integrity" and will allow the customer and programmers to communicate clearly about the application. In the famous C3 payroll system project the sytem was likened to a manufacturing line in which paychecks were 'assembled' from hour 'parts' and various other 'parts'. Sorry, it may have worked but it is overly contrived and not "the simplest thing that could possibly work and no simpler". The other problem is that Beck himself says that coming up with a useful metaphor cannot be taught and that he can only come up with one on half his projects. So what if, instead of racking your brain to come up with a useful metaphor, which you will only come up with 50% of the time at best, you used a simple-as-possible-but-no-simpler modeling approach to model the *actual* business domain? Wouldn't that model provide the necessary "conceptual integrity" for the system under development and allow the customer and programmers to communicate clearly about the system, and do so *directly*? In the C3 case, paychecks would be paychecks and hours would be hours. No translating back and forth between different domains. I understand the purpose of having a good metaphor - to capture and allow communication of the essential entities and of the essential relationships between those entities. But I think that creating a basic domain model, quickly and iteratively, by applying the patterns, rules and techniques in Streamlined Object Modeling, is a cleaner and more direct practice than metaphors and fits in fine with XP. And creating such a domain model is possible not just 50% of the time, but 100% of the time. (The authors do make certain suggestions and recommendations here and there reflecting their own methodology and implementation preferences which do not always jive with agile and, especially, XP practices. But those are easily identified and agile/XP practitioners should not allowed them to distract from the core of this work.)
In the interest of full disclosure I should state I know and have had the privilege of working with all three of the authors. They gave me an early draft and I did not read it. The book was published and they gave me a copy and I did not read it. Sorry, guys and gal! But finally, this past week, I got around to reading it. Fantastic piece of work. I just wish I would have read it sooner!