Objects, Components, and Frameworks with UML: The Catalysis(sm) Approach

by Desmond Francis D'Souza

Book Overview

After a quick introduction to the design process Catalysis, this book moves on to carefully defining objects, their attributes, operations, and collaborations. (Generally, Catalysis objects and... This description may be from another edition of this product.

• Format: Paperback
• Language: English
• ISBN: 0201310120
• ISBN13: 9780201310122
• Release Date: January 1998
• Publisher: Addison-Wesley Professional
• Length: 816 Pages
• Weight: 3.05 lbs.
• Dimensions: 1.6" x 7.4" x 9.2"

Customer Reviews

Best Book on UML and Process

IMHO, this one is top of the heap. There are a number of things that set it apart: 1. it is looking at issues that surround the large scale, complex development. When people start to realize that XP doesn't have legs long enough for most projects, this will be a good place for them to turn, 2. A lot of modeling is about structure and these guys talk about structure a lot, and give you lots of ideas about some of the ways structure informs design. For instance, on the component front, they focus on the fact that component architectures are often going to be layered and that the structures are almost fractal. This is one of those books where you realize that they are talking about things that you have often wondered about but never seen covered elsewhere. 3. This books is all about components. XP doesn't even mention components really. Frameworks and components are the future. And not monolithic, swiss army knife components, but interlocking, specifically purposed components. My minor nits: 1. better and more examples, 2. not very visual. I like really using the visual aspect of UML and getting mileage out of it as a means of making the immensely complex more navigable.

This book made me a better developer

Two years after I first read it, it amazes me how often I come back to the ideas in this book. One of the underlying principles of Catalysis is that you use as much or as little rigor as you need. As a consultant, I tend to bounce back and forth between projects that require loads of rigor (documentation) and projects that just want me to hack up a quick fix to a problem. Surprisingly, Catalysis works equally well for both.I was prompted to write this review after performing a recent application optimization that I was particularly proud of. There is no way I would have arrived at such a good solution so quickly had I not internalized some of the ideas in this book. In the end, I think that's the true measure of any tech book, method, product, etc. - does it make me a better developer? I am a much better developer for having read this book.In case you're interested, the optimization I performed involved an application that accessed the database over and over. Any good developer knows that caching that data in memory is the way to speed it up. But the database access was married into the processing all over the place - there was no concept of a database tier. At first I thought I'd have to redesign everything to make it faster, which I simply didn't have time to do. Then I had a "Catalysis moment" when I realized that to the calling code the database itself is just a component that can be replaced. I looked at the way the calling code (lots of it) accessed the database - what parameters did it send into queries, etc. Then I made a component that looked as much as possible like the database, using collection objects (STL in C++) to store the complex network of data. I loaded data into the component at the appropriate start-up point and replaced all the individual database calls with calls to this component, making the app 15 times faster. The important point here is that I never changed the algorithms of the calling code - just one of the "components" that the calling code referred to, so making this change took very little time and solved a serious business problem.Most books on objects just focus on fine-grained objects (person, order, company, etc.). Catalysis also makes you look at large-grained components (OrderManager, "legacy order management system", etc.), even things that you wouldn't at first think of as a component. Thinking of a database or a legacy mainframe system or even a human process as a component part of a larger system makes it just a building block with a defined interface that can be used or replaced as needed. This is an incredibly powerful way of viewing the world. This book is huge - it has a ton of ideas, and it even ties them all together, but this concept was my favorite. Bottom line - Catalysis made me a better developer.

A bit heavy, but 100% worth the effort!

It has been a while since I learnt so much from a "methodology" book. These folks have really worked through some basic problems and come up with a very cohesive solution. I've worked through RUP and, while it has lots of good advice, it lacks the clear foundation this one has. I've heard Platinum (now CA) was working on a CBD/Catalysis process guide and plan to get hold of it.What surprises me is that some concepts, like Refinement, just seemed so natural once I got it. It's like "Oh, of course. That's exactly how it should be." And I wish I was using a language like Eiffel to carry Catalysis models directly into implementation.To the writer of the April 14 posting, did you actually read Ch 6 (Refinement) or Ch 9 (Frameworks)? The key concepts, though they could be better highlighted, should have clicked for you if you have some experience with object modeling. fyi - I have used some of the concepts published by DSouza and Wills in the past.I was a bit disappointed that the case study section does not make good use of the component-modeling concepts described earlier e.g. connectors. After seeing the overviews at the catalysis.org site, I am really looking forward to seeing "Catalysis Distilled" or equivalent!

Authors show a clean way to model businesses/software/etc.

I am a hardware engineer by background, and my interests lie in modelling, protocols, concurrency etc, but from a hardware standpoint. For the past 6 months, I have been hunting for a good book on modelling from the software/database perspective. This is the best I've seen.The authors demonstrate clear thinking and good wisdom about how we model a process or situation. Every chapter has a few pearls of wisdom, some of which took me several years to figure out on my own the hard way. For example, in chapter 2, the authors say that it is rarely possible to describe the behaviour of a system without some (possibly fictitious) notion of its internal state. Yes, it is true that the state is encapsulated and invisible to the user; nonetheless, the user must invent some picture of what's inside, just in order to have a vocabulary for further discourse.I have read some other books on this subject, notably the one on UML modelling by Booch, Rumbaugh and Iverson. I was a little put off by these books. What I was looking for in these modelling books was some philosophy -- a discipline of viewing objects around us (as well as objects in the toy worlds we conjure as engineers). Instead these books spent an inordinate time on irrelevant mechanics -- do I draw a rectangle or an oval? do I adorn the arrow with an apple or a flower? etc. Notation is no doubt important, but first and foremost a book must teach you a clean way of thinking -- and that was precisely what I found missing until I chanced upon D'Souza and Wills' book.