Book: “Objects, Components, and Frameworks with UML”, Fedmond F. D`Souza

This is a book about Catalysis, an OO methodology. I read this book some time ago (like years…). It is a quite complex book. If you don’t like methodologists, it will easily put you to sleep. But if you stay awake, it is worth it.

It is strange how this book crystallized one concept for me: the definition of an interface. An interface is not just the sum of the signatures of the methods. It is a conceptual framework. The only way to fully describe it is to describe in a formal way this conceptual framework. For example without further specification it is impossible to know how to use this interface:

interface IBook() {

  void AddPage(IPage p);


What happens when you add a page? Will it add it at the end of the book? At the start? What happens if you call the method twice? Will the pages be in order? Will they be in the same section? Is there a concept of a section?

There are ways to make explicit the implicit model beyond an interface: the one that I’ve commonly seen being used is documentation. The book argues for formal contracts (preconditions, postconditions, invariants). The latter is certainly more formal, but to use it you need to describe formally what is the state beyond the interface and how the different methods affect this state. It is a lot of work.

Is it worth the effort? I guess it depends on a zillion things like: the type of project, the people involved, … I don’t think anybody is actually doing it, but it is still a good conceptual framework to keep in mind when you define your interfaces: it is not enough to write down the signature methods, you have somehow to expose the conceptual framework (where somehow means more or less formally).

Skip to main content