Parent-child relationships are
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
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
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
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
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
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
and makes the the reverse relationship
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
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
Preferred Identifier to formalize the reverse relationship
The only perceived disadvantage here is the addition of the new
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.
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
isn't defined as a base attribute of
Object in the
Information Model subsystem.
Object is a
Entity which defines
Name as a base attribute.
This indirection performs a similar role as the
in approach D.
However, adding a
above a parent is not a general solution to the problem which is why it's not given as an approach here.