Friday, 4 June 2010
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 Object and 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 R2 using 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 R6:
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.
