Wednesday, 29 October 2008Relationship loops appear everywhere in information models. Most of these are loops of independent relationships. However, there are times when a loop-closing relationship is dependent on the relationship loop being closed.
OOA91 introduced the concept of a composed relationship (called an equal set constrained relationship in Executable UML) where the loop-closing relationship is equivalent to the composition of the relationships in the rest of the loop. In many cases, composed relationships are redundant and shouldn't be modelled by the analyst. Obviously, a composition containing a single relationship is always redundant and thus is not allowed. However, sometimes the nature of the composed relationship differs from the set of relationships which compose it even though the formalization is determined from those component relationships. The verb phrases used should highlight the differences. Composed relationships shouldn't be composed from other composed relationships. It would be possible to allow this as long as there was no circular compositions. However, such relationships can be difficult to understand and add little value. OOA Tool does not currently allow such relationships.
On a more pragmatic note, composed relationships allow heavily navigated complex relationship chains to be simplified. This technique should be used sparingly since it is a pollution of the information model. However, in some cases, it can significantly improve the readability and maintainability of Action Language code. Note that, composed relationships can be changed later without having to change any such code, e.g. the composition could be changed slightly or the composed relationship could be changed to become a mathematically dependent relationship.
The multiplicity and conditionality of composed relationships is initially determined directly from the component relationships. However, OOA Tool allows this to be changed reflecting the fact that the composed relationship should be modelling new information. The composed relationship can't increase multiplicity or add conditionality to component relationships. This will be flagged as an error in OOA Tool. However, many can be reduced to one and conditional can be changed to mandatory. This allows an additional constraint to be defined in the information model. Whether the final translated system checks this constraint is determined by the software architecture that you use. However, this constraint should be checked automatically by your simulator during testing.
OOA10 goes even further with composed relationships, it allows a participant mapping to be defined which can be used to constrain one or more referential attributes. This participant mapping is never used to navigate the composed relationship and a composed relationship is never created using an Action Language link statement. However, when other relationships are created which share referential attributes with a composed relationship's participant mapping then they can be checked against the composed relationship's navigation results. OOA Tool's tree browser shows referential attribute mappings for composed relationships in gray within referential suffixes.
This mechanism is sometimes useful since referential attributes aren't inherited in subtypes. An attribute may formalize a relationship in a supertype which is also used to formalise another relationship in a subtype. However, only referential attributes which are used as part of the supertype's identifier are 'inherited' in subtypes, i.e. they are used to formalise the subtype to supertype mapping. I have seen models where an analyst has added a common referential attribute to the supertype's identifier so that it can be used in the subtype. Identifier's should never be polluted in this way since the uniqueness constraint imposed by the identifier is always weakened (and sometimes completely broken) when redundant attributes are added.
Another type of loop dependent relationship is the subset constrained relationship. The concept of constrained relationships was introduced in OOA96. It annotates one or more of the referential attributes associated with the participant mapping which formalises the constrained relationship with a small 'c'. However, the concept was developed further in Executable UML [xtUML02] where the relationship label of a subset constrained association is annotated with a subset constraint indicating the relationship loop. OOA10 adopts a combination of the approaches. It annotates the relationship label of a constrained relationship (e.g. R2 ⊆ R3 + R1) and it annotates one or more referential attributes with a small 'c' in the appropriate part of the referential suffix. OOA10 allows simple relationships, associative relationships and mathematically dependent relationships to be constrained. Constrained relationships can constrain other constrained relationships since each constraint is checked independently using underlying relationship formalizations. The relationship loop being constrained may also contain only a single component relationship (unlike composed relationships which must be composed from two or more component relationships).
Below is an example of a constrained relationship in Shlaer-Mellor notation taken from [OOA96] (see page 14):
It uses the constrained relationship to impose the constraint that students can only be advised by a professor on the staff of the department in which the student majors in. This same example is shown below in Executable UML (xtUML) notation:
Note that, constrained referential attributes are not currently marked with a small 'c' in Executable UML class diagrams. However, OOA Tool does mark constrained referential attributes within its tree browser.
OOA Tool allows any referential attribute mappings to be marked as constrained. However, only referential attribute mappings associated with a constrained relationship should be marked as constrained since the flag currently has no meaning in other contexts. OOA Tool highlights informal constrained flags within its tree browser but it will still mark up the appropriate referential suffixes on Object Information Models. OOA Tool will only automatically mark one or more of the referential attributes of a constrained relationship if the analyst hasn't explicitly marked one of them already. This allows an analyst to more explicitly identify which attribute is being constrained. OOA96 only requires a single attribute to be marked. OOA Tool, by default, marks all referential attributes formalizing the constrained relationship except those which also formalise the first or last relationship from the associated relationship loop. However, in practice, this will normally be a single attribute.
The multiplicity and conditionality of a constrained relationship can initially be determined directly from it's dependent loop of component relationships. Obviously, OOA Tool allows this to be changed reflecting the fact that a constrained relationship should be a subset of it's dependent loop. However, a constrained relationship can't increase multiplicity or remove conditionality. This will be flagged as an error in OOA Tool. It can reduce many to one and mandatory to conditional. This differs from a composed relationship which acts like a superset constrained relationship since it allows conditional to be changed to mandatory but not vice versa.