object databases

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.

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!

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.