A notation switchable version of the following technical note can be found here: Technical Note - Formalizing Reverse Parent-Child Relationships.
Parent-child relationships are binary relationships where one participant has some form of ownership over the other. They often appear on information models as defines or contains relationships and on UML models as compositions or aggregations. The parent will normally have a longer lifespan compared to the child and will often be one-to-many but not always. In OOA10, a parent-child relationship can be explicitly formalized by adding an
Arbitrary ID Attribute to the child and then using a
Parent Allocated ID Type to formalize the attribute. The relationship can be ordered by specifying the type as ordinal. Ordinal ID base attributes are normally called
Order in my models while non-ordinal arbitrary ID base attributes are simply called
Arbitrary ID. In either case, OOA Tool automatically annotates the attribute with an "A" suffix (short for arbitrary) followed by the relationship ID of the parent-child relationship (see diagram below for examples).
All of the above is fairly straight-forward. However, there is a complication when creating reverse or secondary parent-child relationships where the child needs to reference it's own parent to formalize a second relationship between the parent and child or where the parent needs to reference a specific child for special treatment. For simplicity I will refer to both types of relationship as reverse relationships from now on. Reverse relationships will normally be one-to-one since parent-child relationships are normally one-to-many. This technical note aims to discuss some issues with formalizing such relationships. A simple example involves the relationships between
Identifier in the OOA of OOA. There are two obvious relationships here, the parent-child relationship defines and the reverse relationship is preferred by. The diagram below illustrates four different ways of formalizing the reverse relationship. To simplify matters, the four approaches were all defined in the same domain so I have had to use object name qualifiers, e.g.
Object A and
Identifier A for approach A, etc.
Starting with approach A which is the obvious approach in OOA91. The parent-child relationship
R1 is formalized using
Identifier A.Object against the preferred identifier of
Object A with
Object A.Name as the base attribute. In OOA91, we could formalize the reverse relationship
Object A.Name and
Object A.Preferred Identifier since we can still manually specify
Name as a base attribute. OOA10 takes this option out of the hands of the modeller to greatly tighten the rigor of information models, i.e. attributes are only base attributes when they are not referential or polymorphic attributes. However, OOA Tool still allows this approach to be captured but both
Object A.Name and
Identifier A.Object are annotated in the OOA Tool browser with the warning "Only circular references" indicating that no base attribute could be found.
Moving onto approach B which replaces
Object A.Preferred Identifier with the referential attribute
Identifier B.Preferred mapped to
Object B.Name. This looks a little weird when you first see it but one must remember that referential attributes are not implementation fields, only a modelling mechanism to formalize relationships. Approach B has the same relationships as approach A but we have moved the formalization from the parent to the child avoiding the problem with base attributes. However, in doing so we have weakened the formalization since
Identifier B could potentially be the preferred identifier of another object entirely which we certainly don't want. In OOA10, we can add a loop constraint to the reverse relationship
R4 to ensure this doesn't happen. This approach works but may confuse some.
Approach C changes
Identifer B.Preferred into the boolean attribute
Identifer C.Preferred and makes the the reverse relationship
R6 a mathematically dependent relationship (added in OOA10). The main problem with this approach is that we need to stop an object having more than one preferred identifier. We have two choices here with regard to the Action Language code formalizing
- we can decide which identifier flagged as preferred is actually the preferred identifier (e.g. first flagged) but we can't use the boolean attribute directly as an indicator,
- or we can determine all preferred identifiers and the modeller can rely on a constraint error being flagged if more than one preferred identifier is set.
The final approach D which is the recommended approach since it has none of the drawbacks of the previous approaches yet it can always be used to formalize reverse relationships. It uses the associative object
Preferred Identifier to formalize the reverse relationship
R8. The only perceived disadvantage here is the addition of the new object. However, this is a modelling mechanism and does not imply any additional implementation code is required. Modellers may try to avoid this approach to reduce clutter but the previous approaches add complexity and additional error possibilities. If an
Identifier D.Preferred boolean attribute is still desirable (perhaps to allow changes to be more easily observable in another domain) then a mathematically dependent attribute can still be added to
Identifier D which checks whether a
Preferred Identifier exists.
As a side note, the OOA of OOA actually uses approach A and is able to do that because
Name isn't defined as a base attribute of
Object in the
Information Model subsystem. Instead
Object is a subtype of
Entity which defines
Name as a base attribute. This indirection performs a similar role as the associative object in approach D. However, adding a subtype-supertype relationship above a parent is not a general solution to the problem which is why it's not given as an approach here.