Customer Reviews

Analysis Patterns: Reusable Object Models

5 star:		(11)
4 star:		(2)
3 star:		(2)
2 star:		(2)
1 star:		(0)

 

 

This is simply an excellent book; quite possibly the best book I have read on analysis.

Martin Fowler cheats by actually being able to write. He has a very lucid prose style making this a very readable book (a strength that also manifests itself in his book UML Distilled) even though it deals with complex subjects.

The book deals with using patterns to address particular business areas. However, it has a great deal to offer anybody interested in analysis or modelling (whether they are working in the OO world or not) and provides one of the best explanations I have read of the purpose and objectives of modelling.

Each problem area is presented very clearly and a number of different solutions are presented at different levels of abstraction (and hence complexity) with lots of useful insight into the factors that would determine the appropriate model.

Analysis Patterns is a book that bears reading and re-reading. I frequently refer it as an excellent source of interesting ideas on ways of approaching complex modelling & analysis issues. I have never managed to take one of the patterns and apply it as is; however, the ideas and concepts expressed in the book influence many of my models (even when the business problem I am tackling initially appears to be entirely unrelated to any of the patterns).

Frankly, this is a book I wish I had written.

I've got most of the books on patterns and find that this is the one I use the most. The writing is clear, the patterns address problems that I run into, and mostly the solutions are just what I need. This book is great to give to analysts who are having trouble agreeing with each other, because they often are persuaded by the book. It is great to give to analysts who are trying to master OO concepts, or to programmers who don't understand why things have to be so complicated. Everybody I know who has read it likes it. I just wish more people would read it!

The only thing I don't like about the book is the notation. I wish he had used UML. On the other hand, after you spend a few days with it, it isn't hard to understand. It is just one more notation.

I bet you are an object oriented software developer striving to build better applications. If you have not read GoF <i>Design Patterns</i> and followed that with Vlissides's <i>Pattern Hatching</i>, read those first. Follow those with this, Martin Fowler's <i>Analysis Patterns</i>.

As two readings of <i>Design Patterns</i> took my OO knowledge from infancy to adolecence, <i>Analysis Patterns</i> will take you from adolecence to adulthood. Fowler's work does not put together patterns from the <i>Design Patterns</i> book, but takes its time to decompose actual application domain concepts to applicable object models. It will then be up to you to use your knowledge from <i>Design Patterns</i> to create mechanisms that support properly modeled business concepts as <i>Analysis Patterns</i> describes.

If you like OO modeling and design, but are wondering how better to apply your modeling concepts, Fowler's book is something you will definitely benefit from. However, make a pot of coffee per chapter-this book is very dense with concepts.

Fowler ends <i>Analysis Patterns</i> with some more easily read chapters on application design on a larger scale. You've heard of "n-tier," his discussion of the concepts of "n-tier" at the end of the book are possibly worth reading first.

After reading this book-and understanding it's motivations-you will never again be tempted to take "innocent" shortcuts in your application design. You will not be motivated to use "Strings" for "measurements" or "doubles" for "distances." You will look upon your peer's object designs either with a new understanding that they know that going the distance with their object model is worth it-and you won't demand they dumb down their design ever again-and you'll likewise gain intuition about where a simplistic business domain model is going to fail.

The analysis model is often forgotten. Too often designers will do just that -- design, i.e., solve the problem before serious inquiry into requirements analysis. This book addresses that which is between the use-case and detailed design model. It is the domain analysis model. Fowler is an excellent student of M. Odell, and it's high time that Odell's thinking was made accessible to the domain analyst. Fowler's book is general enough to get across the point that it is how we think about the problem that is the important part of modeling, and not some arcane "modelling process" that is significant to methodologists. A note about reusability, as pertains the title: to my mind it is this thinking which Fowler describes that is a part of modelling that is reusable. The output of his thinking, the actual models in his examples deriving largely from the financial domain, could be in fact reused. But it is the thinking that is important. The only bad thing I can say about this book is that I fear, by its title, it may not reach its desired audience of the domain analyst, because these are, quite frankly, the scientist, the doctor, the finance expert, etc. that can really benefit from modelling since they have the in-depth knowledge of the domain. It is the job of whoever reads this book to spread the message. Power to the domain analyst

This is Martin Fowler's first book, published in 1997. The book is divided into two large sections.

The first section details analysis patterns that Fowler has encountered across industries. These chapters cover several common domain patterns including representing organizational hierarchies, inventory, accounting, and others. Fowler approaches these chapters by starting with a simple model and repeatedly expanding on this model to fit more and more complex needs. This section of the book is interesting from an academic and a practical perspective. It was interesting to see how Fowler has approached different domain problems and I expect to reference these chapters as I tackle similar problems in the future.

The second section of the book covers what Fowler calls Support Patterns. In these chapters Fowler discusses tiered architecture, presentation layers, facades, and association patterns. The second section on support patterns is less useful and some chapters are quite dated. While this information may have been useful in 1997, if you are looking for more information on layered architectures read Enterprise Application Architecture - a more recent book by the same author.

I found this book to be quite good. I enjoy Fowler's style of writing and for the most part I found the book easy to follow. However, this is Fowler's first book and it lacks the polish of his more recent other books -- in a few spots it was hard for me to follow the author's train of thought.

This book predates UML and the diagrams used throughout the book take a while to understand. There is a key to the models on the inside cover of the book, but if the diagrams had been updated to UML they would have been easier to understand. If needed, you can find UML diagrams for this book on Martin Fowler's website. I think sample code would have helped clarify some of the models as well, as was used in the "Gang of Four" book.

If you are designing a domain model for a complex business, I think this book would be useful for you. If you are looking for similar books, I would suggest Design Patterns by Gamma, et al. ("Gang of Four" book), Patterns of Enterprise Application Architecture, and Refactoring both by Fowler.

I really do like Martin Fowlers books. He is bright, clear, rigorous and relevant. This is his first book and most difficult to grasp book. I started reading it a few years ago and had to give up: it was too abstract for me to grasp. Now with a few more years of OO and pattern experience it shines at me in all its beauty.
This book condenses so much Analysis/Architecture/Modeling knowledge that it is difficult to come up with an idea to tackle the abstraction problem. Examples might help but how many does one need. I guess far too many.
Still I have a wish: Please write a new edition with UML diagrams and sample code in JAVA.
Then I also do have a big wish: I want more of this topic.

I found this book very hard to work with. I'm convinced that the book's models and ideas have merit once they can be understood but getting that level of understanding is being very difficult. I've had colleagues also attempt to get to grips with this book to see if was just me, but all of us have had the same problem. This book explains scenarios at a reasonably understandable level for each of the examples and then dives very quickly into the abstract without a clear path of how things relate to the original problems. Other issues were the use of smalltalk for examples (smalltalk may be a fine language, but it's hardly intuitive for c,java or vb programmers), and the decision not to use UML for diagrams.

What I am nearly always missing when reading about design (esp. when sifting through design case studies) is the path that lead to a design. The weighing of arguments that made the author/designer choose the solution at hand. The context and the "drivers". Fowler is the only one achieving this: offering different solutions and discussing their advantages and disadvanteges. Yes he dives deep and goes into abstract concepts, but sometimes solutions only differ from an abstract viewpoint. You need quite some understanding of design principles, to (i) understand the book and (ii) be a good designer.

For me this is the book that helped me understand the design process as it should be. And using "analysis patterns" he gives plentiful of concrete examples, sharpening your mind.


One remark to everyone critcizing Fowler for not using UML: This book does not use UML since it dates back to 1996! When UML was not really there. Version 0.9 of the UML came out in the second half of 1996. And btw. Martin Fowler has written the very first -- and still one of the best -- book on UML ("UML Distilled", now in its 3rd edition).

This book is required reading for all Architects and Modelers. It helps one frame how to build reusuable systems not only from the technology perspective but will give you insight into how to structure actual business process. It will encourage you to think in alternative ways.

This is certainly a good book about patterns. I found it clearly written by the author. Also he provided his own graphics symbols on the front and back pages in his book so we can understand the patterns in his book. However, he chose smalltalk to explain his codes. I think most readers are more familiar with C++ or Java than smalltalk. I wish he could provide those sample code on the addison-wesley web site (or his own site) with Java or C++. He promised (in his book, page xix) to put "further materials to keep this book alive". However, I did not see much update on this site or his own home page on this book.