Updates
Latest Tweet
What's New?
Check out for latest innovation, a computer based training video collection
Like this Page
A UML Pattern Language (The Mtp Software Engineering Series) Review by R. Williams
Shoemaker's Son
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.