Requirements Modelling and Specification for Service Oriented Architecture

7.9. Associations, Rules and Encapsulation

I have already stated that cyclic associations in the ontology type model imply the presence of latent business rules.

In my formalism, as we have seen, objects encapsulate rulesets along with the usual attributes and methods. In this section we examine the notion of associations and their 'inverses' in some depth and point out some inconsistencies in current terminology within the database community that go back as far as Abrial's work. With the new foundation I then construct, I show how referential integrity rules can be embedded in types rather than attached to external associations, as is the current normal practice. I prove that, to maintain the principle of encapsulation and to represent the integrity of relationships, components must have rulesets; they are not an optional extra. The material is a little technical compared to the remainder of the chapter and the reader may skip it at a first reading.

I think that associations should point in one direction only because to do otherwise violates the principle of encapsulation. Several object-oriented methodologists have argued against my position, saying that you can always add link attributes to an association and create from it an association object type. However, this new object type must retain links to its progenitors. Therefore, if we accept this as a solution, these new relationships must in turn give rise to new association object types. At some point we must stop this process ...