I understood "factoring" with this book.
"Part III factoring models and designs" have good examples of refinements and abstractions.
First, I read this book, I understand nothing.
Then, I read only factoring and refinements.
After that, I read only testing.
But now, I cannot understand which architecure is good or not.
How to measure qualities of architecture, modifiability, portability, buildability, testability on development-time qualities.
How to measure functionality, usability performance, security, reliability and availability , scalability and upgradability on runtime.

This is one of my alltime favorites.
If you always felt annoyed by the lack of coherence in UML, then buy this book to read about a comforting and coherent approach.
If you're looking for a book on applying standard UML diagramming techniques, then you shouldn't buy this book. Catalysis people would probably call this an 'import with modifications'. They modify some of the UML language in order to present you a more coherent way of looking at software and software development.
If you're looking for a book that would help you using your UML tools in a useful way, then you shouldn't read this book. I've never been able to find a tool that supports the Catalysis approach.
If you wonder if Catalysis is still alive, then I'd say: join the crew. There isn't really a living Catalysis community, and the authors seem to have gone numb after writing this book.

This book had the potential to be a 5 star book but alas it comes up short. The concepts that the authors attempt to relate are things that most people could use in their software development: static and behavioral object modeling, abstraction, components, packages, architecture, and frameworks. The problem is the Catalysis Approach. Unfortunately, many of the terms and diagrams used are similar in name but different in meaning from what is typically written in UML. I have numerous other books published by Addison Wesley on object modeling - Design Patterns and Refactoring to name a couple - and they tend to lean more toward the Rational or Unified Process. It is very difficult to take the information that the authors present in Catalysis and see how it relates to the work of the GOF without a lot of translating. This is not to say that there is not room for other processes or methodologies in the software community; however, the average engineer sitting at his desk is going to have a hard time mining the information in this book because of the presentation. Catalysis may be a very effictive process, but it should be examined to see if it can use UML in ways that most software developers are accostumed to seeing.

If you know a lot about UML, don't read this book. If you know nothing about UML, don't read this book. If you have picked up a few UML books but never finished any of them, you won't be able to fininsh this one either. There are use case diagrams that are not UML's use case diagrams. There are static diagrams that are not UML's static diagrams. Joint actions are use cases. Type spec is degenerate collaboration. Collaborations are refinement of use cases...This book is full of this kind of slightly off definitons and NOTHING NEW.

If you know a lot about UML, don't read this book. If you know nothing about UML, don't read this book. If you have picked up a few UML books but never finished any of them, you won't be able to fininsh this one either. There are use case diagrams that are not UML's use case diagrams. There are static diagrams that are not UML's static diagrams. Joint actions are use cases. Type spec is degenerate collaboration. Collaborations are refinement of use cases...This book is full of this kind of slightly off definitons and NOTHING NEW.

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.

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.

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.

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!

Catalysis as a method is very powerful no doubt. Catalysis the book is a different story. I consider myself lucky in the respect that I had a subset of the method taught to me by people that have had some input to the Catalysis method (from University of Brighton, UK). I was also impressed by IS A RUNNING THROUGH EXAMPLE? A case study is desperately needed and it could easily replace some of the other material in the book. I know that if one can apply the techniques described in this book (not necessarily the full set) better more robust software will be the result. It is a shame that you need loads of time to get through the book. Given the choice I would have still bought this book but I believe there is area for improvement in the book not the method. END

This book is superb. I have not seen any other book (UML or otherwise) that provides as thorough and consistent a treatment of the really difficult range of issues from domain modeling through component-based implementation.

The best parts, IMO, are (a) Type Modeling (b) Refinement (c) Package factoring, and (d) Frameworks.

The writing could have been simplified; the (many) valuable insights are not sufficiently highlighted. And the book is not for those who need "Objects 101" or "UML for dummies".

But if you know objects, understand basic modeling, and really want to step up ... get this one and keep it!

I agree with one reviewer that the concepts certainly seem to be HIDDEN in this text. The problem with the book is that it seems somewhat incoherent at times and not very convincing on ideas that most software engineers have an inclination are very useful.

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.

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.

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.

After reading this book a few times, I still feel unfulfilled. There are good ideas in the book but there is no flow. The content seems disjoint and disconnected. I got just about as much out of chapter two, which is an overview of Catalysis, as I did out of the rest of the book.

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.

This is a great book on software development methodology. If you want to go component based, then this should be on your software shopping list. (But beware, this is NOT a beginners-tutorial or an OO-for-dummies-kind of book.)

The book does not only cover the Catalysis methodology. There is a lot of stuff also on architecture, implementation and every other aspect of software development.

A must have for all who consider designing and building software a serious business.

I have just completed this text, having read every word on every page. Now it is my time to give back to the authors; I take this review quite seriously. First, a little context (which most reviewers feel obliged to omit): I am 23, a consultant, and have designed and coded on 3 major systems (10,000+ lines of code, up to 9 months in duration). I have not yet independently led a project, but I will, this year. So I am ahead of the curve in time, but still young with much to learn.

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.