Objects, Components and Frameworks with UML: The Catalysis Approach (OBT) [Paperback]

Every time the authors get into a subject that is interesting and you think they're about to really get to the point, they seem to either change the subject or they show the reader some java code.

The examples in the book are flimsy and there is no thread. There only ever seems to be one example per concept, so if you don't like or understand the one example, you're out of luck. It could use a common business case that runs through the whole book, so you can see a series of component and interface specifications come together.

For example, it would be nice to see a series of types that were developed, and a collaboration diagram that showed collaborations of many types, and how they evolved interfaces from those joint actions, instead of the one little example about a wholesaler and retailer. Maybe it's because I don't buy that joint action = use case...

Anyway, the ideas that can be understood are good, such as the design of interface types and specification types that describe their vocabulary, but overall it's more confusing than anything and leaves me with more questions than when I started, and I'm not a beginner.

I have owned this book for approximately 7 weeks. I have given this 800-page book between 1-4 hours of care, 5-6 days a week since its arrival. In total, I would guess 50-60 hours of reading spent (not counting the 80+ hours of spacing out/absorption). I am versed in UML, Design Patterns, OMT, and all major technologies (excluding SmallTalk). This book has just jumped to the top of my all-time-favorites list... and I almost gave up after the 3rd chapter.

These authors have discovered some key insights that will build upon the calculus of software... if the presentation were tighter, the book would be tied with Design Patterns and the UML guides in importance to our community. Put another way: if the book were more of a encyclopedia and roadmap, and less of a dissertation, the authors could have made a heck of a lot more money. But the brilliance of this book's content (read: the great clarity of insight held by its authors) cannot and will not be denied.

Part of the blame for the excessive read-time was mine, part was the editor's. I have read enough books like these to know that most sentences contain pearls of wisdom, not BS. But I found myself stumbling on paragraphs of definition and example that were built on concepts that are quite difficult to absorb. The book contains only a sparse TOC and glossary, so cross-references are between general sections... very tough to get back on your feet if you slip on Catalysis' sometimes-vague, 'concrete-free' content. My recommendation to readers is to just keep on plugging... the authors usually ram a problem from three or four different angles. (My recommendation to the authors is to develop a full Catalysis glossary with every major term and at least one strong supporting example.)

I nearly gave up after chapter 3, after being slammed by Catalysis' version of OCL invariant/constraint rules, which are meant to provide models with precise language (needed badly!). Knowing 4 programming languages didn't help; I hadn't read OCL, so attribute parameters, set notation, strange message syntax, _and_ Catalysis extensions left me bloody. I'm glad I didn't stop reading; the notation in the rest of the book was much more readable after the first battle. But this is the book's most glaring weakness. Catalysis depends on this precision, but there is no good guide for building Catalysis invariants that I can use out in the field (have to use the appendix, the UML OCL spec, and a bunch of bookmarks throughout Catalysis' chapters).

Chapter 6 made the whole book worth reading. Being able to map from a business model to code while not throwing out all efforts from analysis and design phases? I had no idea this was possible before reading about Catalysis refinement. Worth the entire book.

After Chapter 6 and the early precision-syntax wars, I realized how important this book was becoming to me. Chapter 9 tied together packages, patterns, and collaborations into a very strong argument for building frameworks (a method that will be worthwhile for businesses to explore). Chapter 10 on components is brilliant, especially to those who wish there was a cleaner component middleware on the market; here's a good start (I would read a whole book on this if the authors would write it). Having all diagrams based on UML allows you to focus on the methodology and not the tiny details (although the authors really blew it using bold type borders for minor concepts - it overrides an important aspect of UML).

The last four chapters present dozens of Catalysis "business/software patterns" that, although quite helpful, don't really map cleanly to the foundation in the first 12 chapters (and the first 12 chapters never refer to these patterns). This is symptomatic of the book's lack of cross-referencing, and, in fact, symptomatic of a bigger problem... Finishing the book, I realized that I still hadn't been presented with a 'roadmap' of the Catalysis way. How do I explain the system to my boss, and how do I direct the team (other than give them a copy of the book)?

The Catalysis process is not a rigorous methodology, it is a wise man in text form. Pearls abound, but a bit of digging is required. It is a challenge and a reward, just as any good book should be.

This doesn't mean there isn't room for improvement. Given a knife (and a nice advance) I think I could cut Catalysis down to 200 pages of essentials, and if I can do it... A cliff-notes Catalysis would be a roadmap and an encyclopedia. This current Catalysis book can be the bible, but we need the commandments first - Catalysis as-is is not rigorous enough for us to be able to quote chapter and verse in preaching, in practice, and in defense.

I believe that Catalysis being published under the Addison-Wesley series (same cover as UML guides) gives it the exposure it needs, and the fact that a design/development engineer (me) can work through this book proves that this methodology can reach the masses. It deserves to be read. But the process can be slimmed down.

This seems to be a neglected aspect of software process doumentation - aesthetics. Some processes might have more sucess if they were layed out ina manner that makes them useable quickly.

I've read this book through once and studied certain sections numerous times and still do not get the full picture (at least in the way that the authors seem to). The OPEN process documentation is much better and would lead to me choosing to adopt it rather than Catalysis.

Don't buy this book if you want to practice UML and if you are interested in components then I suggest Clemens Szyperski's book on component software.

That said if you have the time to sift through it then there are some excellent concepts to put into practice.