Rating: 
Summary: Content may be there, but it's difficult to tell
Review: 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.
Rating: 
Summary: The method is great the book could be improved
Review: 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
Rating:
Summary: Interesting concepts yet to be refined!
Review: 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.
Rating: 
Summary: Authors show a clean way to model businesses/software/etc.
Review: 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.
Rating: 
Summary: ***** content, *** presentation - Some brilliant stuff here
Review: 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.
Rating: 
Summary: confusing and incoherent
Review: 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.
Rating:
Summary: Best Book on UML and Process
Review: 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.
Rating:
Summary: A bit heavy, but 100% worth the effort!
Review: 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!
Rating:
Summary: A bit heavy, but 100% worth the effort!
Review: 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!
Rating:
Summary: Interesting Concepts, But Overall A Little Disappointing
Review: 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.
| 
