Customer Reviews

A UML Pattern Language (Software Engineering)

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

 

 

This book starts as very legible and even enjoyable prose. However, when the author gets into the real material it is pretty hard to follow for somebody who does not have a great background in OOAD, patterns and UML. This is not a beginners book. However, try reading it, since it is very good material.

Be aware, however, of very technical sentences like: "Containment and visibility are key characteristics of model elements in packages. Packages encapsulate the model elements htey contain and define their visibility as private, protected, or public." Certainly for somebody with a good understanding of OOAD can discern what is going on, but you will find that many, maybe too many, are written in this way.

It is with astonishment that I marveled at the degree to which this book was just a hodge podge of widely divergent ideas, thrown together under a moniker that is only really apt for a small portion of what is here. That said, I give it four stars because amidst the mess, there are some really good ideas, and also, this is one of the more literate books I've come across (meaning that the author is drawing on a wide range of other books and for the most part, intelligently condensing some of the ideas that run through them).

In the same way that it amazes me that Rational presumes to tell developers how they should develop software while their own software is a buggered up mess of different pieces that don't work well together (and companies a fraction of their size are now competing with them favorably), it is a little surprising to see how poor the organization of this book is and how many times you see a subject in a chapter or section heading and expect a serious drive, but end up with another little chip shot. The last chapter of the book (putting the pieces together [A for originality]) is almost a joke, but endemic: the author just summarizes the work of another guy, making a couple little points and quoting liberally. Methinks he was huffing and puffing by this point in his little journey.

If you are buying this for the 'patterns' be forewarned: a. there are precious few of them, and b. as is so often the case, everything down to a design tip qualifies as a pattern in this guy's mind. 'Seven Plus or Minus Two' is one of his patterns. It basically means people are only capable of keeping between 5 and 9 concepts in play at once. Ok, good thing to stress, but is this a pattern?

In reality, this book is good for one thing primarily: spurring you to consider some things that you probably had not considered before. For instance, there is a good discussion of the difference between business modeling and domain modeling, that considers also the role of vision in modeling (which is rare), and overall that is very useful. The chapter on Product (focusing design on product more so than on just managing tasks) started out very promising and ended up being just a couple of ideas. If you are a person who looks to a book to just turn over practical, useable nuggets and get out of the way, this one is not for you.

This is a spectacularly interesting and useful book. No, it's not for beginners, but some of us already know something about patterns, OO, and UML, and we need advanced material to go even further. This book may be primarily aimed at designers, architects, and managers, but in my mind every software engineer worth that title should find the discussions in this book thrilling. Organized around the design pattern paradigm, each topic is short and pithy; so much so that often, after reading one, I have to stop and go apply the lesson to my product, project, or organization. I loved this book.

Normally, responding to a review is a waste of an author's time. However, the way reviews are organized here (chronologically) makes the last review the most important. So I am responding to Edward Nq's "review". He clearly has not read the important parts of my book, which explain the context and history of patterns and why they can work (and also fail) as a way of understanding the UML. I clearly establish why I don't address "Design Patterns" and why, for example, I use a pattern form which is the other accepted form in the pattern community. My book is NOT about Design Patterns, except to the extent they're one form of pattern found in the IT world. Rather the book is about patterns as a literary exercise, one of the fundamental starting points for patterns, and how to read them regardless of format. Anyone wanting a rehash of the excellent material in the original Design Patterns book has any number of books and articles available. My intention was to put patterns into a context, something which seems to have escaped Mr Ng altogether. I suspect he skimmed the patterns themselves and avoided the hard work the other reviewers comment on - reviewers who sadly preceded him and so must be read after him. Given the lack of graciousness in his review, I would also suggest, based on it, that he lacks the basic literacy needed to critique the book. The book is still selling, after too many years. I would suggest potential readers looking for an idea of what it is about should consult all the reader reviews before making a judgement.

Software Design Patterns is something to do with your coding - at least according to the classical design pattern book by "The Gang of Four". According to that particular book, a pattern has a name for recognition, a problem domain and solution.

Basically this book did not address software design patterns. It does employ a similar "writing architecture" from the gang of four book - Problem Context, Solution and so on, but it focuses mainly on other aspects instead of real "software design patterns".

To make it clear, say for example, we have a Singleton software pattern which there exist no more famous pattern. How does UML address this design pattern? God knows, from this book. What it address - for example, section 5.5: "Where can a UML model hold the business rules that guide system operation? Specifically, how can rules that describe fundamental knowledge in the domain be explicitly documented?"

This makes the book totally back to the UML problem doamin - how to use UML as a modelling tool, instead of "converging UML and Design Pattern", the book objective.

Even worse, Section 5.6 titled "Dynamic Object Types" and the problem is "An object must change types by representing different but similar things at different times." What it means is nothing more than "object inheritance", one of the basic object oriented programming knowledges. It simply makes things more complicated than it has to be.

To conclude, by turning over this book for 5 minutes I bet a real reader would close it and find another.