Formalizing Reverse Parent-Child Relationships

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 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:

1. 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,
2. 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.

Both choices still require careful coding when determining preferred identifiers and setting them.

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.

Attribute Classification

The attribute classification hierarchy in OOA88 and OOA91 is shown below:

Attribute

1. 1.
   • Descriptive Attribute
   • Naming Attribute
   • Referential Attribute


2. 2.
   • Identifying Attribute
   • Non-Identifying Attribute

The attribute classification hierarchy in OOA09 is shown below:

Attribute

1. 1.
   • True Attribute
     
     
     • Base Attribute
       
       
       1. 1.
          • Simple Attribute
          • Arbitrary ID Attribute
          • Mathematically Dependent Attribute (Derived Attribute in Executable UML)
       
       
       2. 2.
          • Descriptive Attribute
          • Naming Attribute
     
     
     • Referential Attribute
   
   
   • Polymorphic Attribute


2. 2.
   • Identifying Attribute
   • Non-Identifying Attribute

In the above classifications, a numbered list represents an and hierarchy while a plain list represents an or hierarchy, e.g. an attribute is true or polymorphic and identifying or non-identifying. Attributes can also be classified according to their associated data type. However, data type hierarchies will not be discussed here.

OOA96 introduced mathematically dependent attributes which are discussed in [31May08].

OOA09 introduces polymorphic and arbitrary ID attributes. Polymorphic attributes (and true attributes) are discussed in [26May08]. A detailed discussion on arbitrary ID attributes will be published soon. OOA09 also introduces base attributes (and simple attributes) because all referential attributes must resolve to a single base attribute (see [29May08]) and all base attributes are descriptive or naming attributes.

Arbitrary ID attribute could be merged with simple attribute except that it has a very different lifecycle. Although arbitrary ID attributes can be assigned values like simple attributes, any assigned values are temporary in nature since the allocation of arbitrary ID values is platform controlled not user controlled. Anyone who assigns a value to an arbitrary ID attribute needs to understand how long that value will persist (arbitrary ID types provide some control here but not complete control). For ordinal arbitrary ID values, the user is rarely interested in the exact value, only it's ordering relative to other object instances. For non-ordinal arbitrary ID values, the user is almost never interested in the exact value. Furthermore, the user may never actually need to access such values at all, i.e. the arbitrary ID attribute may only exist in the information model to formalize one or more relationships.

Naming attributes are those representing arbitrary names and labels. Most but not all arbitrary ID attributes are naming attributes. Mathematically dependent attributes are often used to create formatted names and labels from more primitive naming attributes. The distinction between descriptive and naming attributes is not essential for code generation purposes and many information models will ignore this classification defining all base attributes as descriptive attributes.

Identifying attributes are central to the idea that relationships should be formalized in information model specific terms allowing constraints between relationships to be clearly specified. However, the object identities defined by identifying attributes are not fixed and may change frequently depending on the number and nature of the identifying attributes that compose each identifier. The reason that mathematically dependent, referential and polymorphic attributes may be identifying attributes is that the implementation of object identity within Action Language code is normally based on object instance references (or handles). It only appears within an information model that object identity is implemented using identifying attributes. Of course, this appearance was reinforced in OOA91 because Lifecycle Model directed events carry identifying attributes to reference destination object instances. This is no longer the case in OOA09.

Some would argue that a software architecture should be free to choose how it implements object identity. However, the reality is that you can only use mathematically dependent, referential and polymorphic attributes as identifying attributes on secondary identifiers unless you use some concept of object instance reference. And even if you do stick to simple attributes for identifying attributes, you still need to be able to handle changes to those attributes. You can of course, use identifying attributes to find object instances (using a select statement) when those object instances are known to be consistent. However, in most cases, object instances are found by navigating relationships and relationship instances are best realized using object instance references (not identifying attributes).

Loop Dependent Relationships

Relationship 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.

OOA08 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. OOA08 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. OOA08 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.

Participant Roles

Binary relationships and subtype-supertype relationships are defined between participant objects in information models. Binary relationships have two main participants and one optional associative participant. The associative participant object can't be either of the main participant objects in a binary relationship. However, the main participant objects may be the same object, i.e. when the binary relationship is a reflexive relationship (discussed in OOA96). Subtype-supertype relationships have one supertype participant and two or more subtype participants. A specific object can't participate more than once in a subtype-supertype relationship.

To identify a particular participant you need the relationship and object involved. However, you also need additional information to distinguish between the main participant objects in a reflexive relationship. The verb phrases associated with the main participants can be used to distinguish between them in a asymmetric reflexive relationship. However, verb phrases can't be used to distinguish between main participants in a symmetric reflexive relationship (introduced in OOA96). Several existing action languages use verb phrases to help identify participants in relationship navigation expressions. Obviously, this is not sufficient for symmetric reflexive relationships.

OOA08 formalizes the concept of participant role so that verb phrases don't need to be used to help identify participants. Participant roles include first, second, associative, supertype, and subtype. The first and second roles arbitrarily denote the main participants in a binary relationship. The associative role denotes an associative participant. The supertype and subtype roles denote a supertype and subtype participant respectively.

OOA08 initially defined all of these roles as literal values. However, the first and second roles can now be changed allowing short role names to be associated with the main participants of a binary relationship. In practice, participant roles are only used with reflexive relationships. In asymmetric reflexive relationships, the roles should be self evident, e.g. the roles client and server are used in the reflexive relationship between Domain objects formalized by the associative Bridge object (from OOA of OOA). In symmetric reflexive relationships, the default first and second roles should be used.

Attribute Conditionality

OOA91 requires all attributes associated with an object instance to have one and only one value (see first rule of attribution on page 19). However, OOA91 allows these values to be accumulated over time in a lifecycle model (see page 61). Thus, some attributes may not have a value at certain points in time. OOA08 formalizes this property of attributes as conditionality. An attribute must always have a value if it is not conditional, whereas, an attribute may or may not have a value if it is conditional. A (1c) suffix may be used to label attributes which are conditional.

A simple attribute is conditional only if the attribute is explicitly made conditional by the analyst, i.e. by setting Manual Conditional status. Obviously, a simple attribute with an initial value that is final is never conditional. A mathematically dependent attribute is conditional if its value calculation code is not guaranteed to calculate a value or if the attribute is explicitly made conditional by the analyst. A referential attribute is conditional if its associated base attribute is conditional, or if all navigation paths from the referential attribute to the base attribute are conditional or if the attribute is explicitly made conditional by the analyst. Obviously, a referential attribute with a literal value is never conditional. A polymorphic attribute is conditional if any of its true attributes are conditional or if the attribute is explicitly made conditional by the analyst.

Associating an initial value with a conditional attribute still makes sense since OOA08 allows a conditional attribute to be cleared. An attribute with no current value contains a special UNDEFINED (but typed) value. A non-conditional attribute with no associated initial value will be initialized with the default value (if there is one) of the attribute's associated data type when an object instance is created. A conditional attribute with no associated initial value will not be initialized even if there is a default value.

OOA08 (and OOA Tool) requires all Action Language code to strictly obey conditionality constraints. When an object instance is created, all non-conditional attributes must be assigned a value within the enclosing action (if they don't have an initial or default value). If the enclosing action is modelled using a process model then all non-conditional attributes must be assigned a value within the enclosing accessor process (an accessor can access multiple objects in OOA08). This is a much stricter requirement than OOA91 which allows conditionality constraints to be satisfied within actions triggered by events sent from the original enclosing action. The problem with OOA91 is that there is no easy way to determine when conditionality constraints are broken. OOA08 takes the view that conditionality constraints are only useful if they are enforceable.

Mathematical Dependence

OOA96 added the concept of mathematical dependence and mathematically dependent attributes to information modelling. Such attributes are annotated with an (M) suffix and are known as derived attributes in most other object-oriented methods (including Executable UML). Although the term mathematically dependent is a mouthful and the alternative term derived is much easier to use, it does allow us to distinguish between the analysis and design/implementation concept of derived.

When mathematically dependent attributes are calculated depends on the software architecture. They may be calculated on demand, i.e. whenever their value is accessed. Alternatively, they may be calculated whenever their dependent attributes change and then cached for instant access when needed. However, Recursive Design in OOA08 allows attribute updated mappings to be created in bridges that execute action language code whenever an attribute changes. If such a mapping is made from a particular mathematically dependent attribute then the second approach must be implemented for that attribute.

OOA08 also allows mathematically dependent relationships which are a new type of binary relationship formalized using action language code. Code needs to be provided for navigation in both directions. This code is given an instance of the source participant and returns a set of corresponding instances of the target participant. Using mathematically dependent relationships, analysts can now define composed relationships of the form R1 = R2 - R3 etc.

Referential Attributes

Referential attributes are used to formalize binary and associative relationships. All objects should have one or more identifiers each of which is composed of one or more identifying attributes. Any attribute on an object can be identifying. It is common for identifiers to be composed of more than one identifying attribute. Some analysts get lazy and create arbitrary ID identifiers everywhere but I try to avoid them whenever possible. To formalize a one-to-one or one-to-many binary relationship between two objects (or participants), a target identifier is chosen on one object and a set of referential attributes are chosen (or added) to the other object where each referential attribute is mapped to an identifying attribute of the target identifier. These referential attributes can't be set directly by the analyst, they exist only as a by product of a relationship instance existing. A referential attribute may be used in many participant mappings each of which is annotated in the referential suffix.

OOA08 (and OOA Tool) fully supports the use of referential attributes to formalize binary and associative relationships. However, OOA08 requires all referential attributes be resolvable to a single base attribute (non-referential and non-polymorphic). This wasn't an explicit requirement in OOA91 or OOA96. An analyst could keep a model consistent by using the same data type (or attribute domain) for overlapping referential attributes. However, in my experience it is always possible to resolve overlapping referential attributes to a single base attribute and the resulting model is always more complete.

As a result of this requirement, all referential attributes have a base attribute status of either:

• Unresolved indicating that there is no path from the referential attribute to any base attribute,
• Partially Resolved indicating that there is a path from the referential attribute to a base attribute but that there are also other non-circular paths which don't lead to a base attribute yet,
• Fully Resolved indicating that all paths from the referential attribute lead to a single base attribute (ignoring circular references),
• Incompatible indicating that one or more paths from the referential attribute lead to a base attribute with a data type that doesn't match the manual data type associated with this attribute (which can't happen if a manual data type is not specified),
• Multiple Base Attributes indicating that one or more paths from the referential attribute lead to multiple base attributes (whether they have the same data type is not relevant in OOA08),
• and Only Circular References indicating that all paths from the referential attribute are circular in nature.

The example above should help illustrate the different base attribute statuses. Attribute A1 is Unresolved since it is declared as referential but doesn't appear in any participant mappings. Attribute A2 is Unresolved since although it references Attribute B1, that attribute is Unresolved. Attribute A3 is Partially Resolved since although it references Attribute B2 which is a base attribute, it also references Attribute C1 which is Unresolved. Attribute A4 is Fully Resolved since it only references Attribute D1 which is a base attribute. If Attribute A4 had a manual data type of Integer and Attribute D1 had a manual data type of String then Attribute A4 would have an Incompatible status instead. If Attribute C1 was a base attribute rather than a referential attribute then Attribute A3 would have a Multiple Base Attributes status instead. If Attribute B1 formalized relationship R4 then both Attribute A2 and Attribute B1 would have a Only Circular References status.

Circular references are common when composed identifiers are used, i.e. the identifiers for a set of related objects may all have a common identifying attribute. Having circular references is not a problem unless there are only circular references. However, once a referential attribute with this problem has been identified, it can normally be easily fixed, i.e. a set of related objects with a common identifying attribute implies a relationship should exist to an object defining the common attribute as a base attribute. There are situations that appear to be correct but which still have referential attributes with only circular references, i.e. when an identifying attribute which should have been a base attribute has become a referential attribute. However, an analyst should always be able to determine the home object of a referential attribute and if that attribute is not a base attribute, the analyst should make it a base attribute by separating the referential duties off into another attribute and noting the constraint.

The algorithm for resolving base attributes is highly iterative because referential attribute mappings form arbitrary graphs which may be cyclic, i.e. they may include circular paths. The algorithm is briefly outlined below:

1. Add all referential attributes to a set of unresolved referential attributes
2. Loop thru the set of unresolved referential attributes until a complete iteration occurs without resolving a single referential attribute
   • Attempt to resolve the base attribute and base attribute status of each referential attribute using previously resolved referential attributes (or previously determined true attributes for polymorphic attributes) while checking for error conditions at the same time
   • If any unresolved referential attributes are referenced by this attribute then skip the resolution of this attribute for now
   • A base attribute status can be resolved if all references from this attribute are non-referential attributes, previously resolved referential attributes or if an error condition can be detected without the need to completely resolve all references from this attribute, e.g. for Incompatible or Multiple Base Attributes error conditions
   • If a base attribute status can be resolved then remove this attribute from the set and perform another complete iteration of the unresolved referential attributes after this iteration completes
3. If the set still contains unresolved referential attributes then a final iteration thru the set is made re-enter the above loop, except that references to unresolved referential attributes are treated as circular references and ignored
4. Any unresolved referential attributes after this final iteration are all given the base attribute status of Only Circular References

The data type of a referential attribute is determined from the resolved base attribute. However, a manual data type can be specified for a referential attribute for consistency checking purposes. An error condition will be flagged if the resolved base attribute's data type doesn't match the manual data type.

The conditionality of the referential attribute is determined from the resolved base attribute's conditionality along with the navigation conditionality across all the paths to the resolved base attribute. This can also be weakened by specifying a manual conditionality for the referential attribute. Further discussion of attribute conditionality will be left for another day.

Polymorphic Attributes

Polymorphic attributes are new to OOA08 and have only really become useful since OOA96 introduced mathematically dependent (i.e. derived) attributes. Previously, if a common non-identifying attribute was defined in most (not necessarily all) subtypes of a subtype-supertype relationship, it would be abstracted into the supertype object. This would only cause a problem if the attribute was referential in any of the subtype objects. In which case, the analyst would have to leave the referential attributes where they were and decide whether having a copy of the attribute in the supertype object was still beneficial. OOA96 introduced the concept of a constrained referential attribute and this could be used to constrain any referential attributes left in subtypes after a common attribute is abstracted into a supertype object. This situation does not happen often in my experience. However, with the introduction of mathematically dependent attributes, abstracting common attributes of mixed type becomes much more difficult. How do you abstract a common attribute which is a simple attribute in one subtype and a mathematically dependent attribute in another subtype? The answer is a polymorphic attribute.

Polymorphic attributes are similar to polymorphic events (which were also introduced in OOA96) in that polymorphic attributes in a supertype object are mapped to true attributes in subtype objects. An analyst associates a subtype-supertype relationship with a polymorphic attribute and then selects a subtype attribute in each of the relationship's subtype objects. Subtype attributes may themselves be polymorphic attributes. When we refer to true attributes we mean non-polymorphic attributes with any intermediate polymorphic attributes flattened out. Obviously, the object containing the polymorphic attribute must be the relationship's supertype object. It is rare for there to be more than one choice of subtype-supertype relationship, i.e. multiple supertype objects are rare.

Polymorphic attributes and their corresponding true attributes do not have to have the same name but they must have the same data type. However, OOA Tool can pre-select subtype attributes that have the same name and data type. This makes the creation of a polymorphic attribute a 2 second job in most cases. The conditionality of a polymorphic attribute is the weakest conditionality of any of it's true attributes, i.e. the polymorphic attribute is conditional (1c) if any true attribute is conditional. Furthermore, an analyst can make a polymorphic attribute conditional even if none of it's true attributes are conditional. One could argue that the data type of a polymorphic attribute should be the weakest data type of any of it's true attributes. However, to keep things simple, the data types of all true attributes must match in OOA08.

The example above shows a typical polymorphic attribute with a true attribute defined in each of the subtype objects. The attribute suffix of a polymorphic attribute begins with 'P' and includes the associated subtype-supertype relationship ID, e.g. (P-R1). Using the relationship ID is important since the associated relationship may be defined in another subsystem and thus may not be shown on a particular diagram. The attribute suffix (P) is used if there is no associated relationship at present. In the example above the true attributes are simple, mathematically dependent and referential.

Polymorphic Attribute above could be replaced by Other Attribute if the associated calculation code performed a simple switch on the supertype's current subtype returning the appropriate true attribute value. This would be unthinkable in an object-oriented programming language. However, in Shlaer-Mellor OOA, a subtype-supertype relationship is complete in the sense that all subtypes are identified by the analyst in the information model. Therefore, the switch code for Other Attribute would also be complete. OOA Tool will inform an analyst if a subtype switch statement is no longer complete, e.g. when a new subtype object is added. The disadvantage of using this approach is that the polymorphic relationship is hidden in Other Attribute's calculation code.

The diagram above shows how polymorphic attributes can be used to create interface like objects without having to create additional redundant relationships or use arbitrary IDs. Main ID and Parent ID in Interface would normally have to be referential attributes but that would require some form of relationship to Parent to resolve the referential attributes (OOA08 requires all referential attributes to resolve to a single base attribute). Alternatively, an arbitrary ID could be added to Interface and then used in Child B and Child C. Making these attributes polymorphic means that they can resolve downwards in R3 while the matching attributes in Child B and Child C reference upwards to formalize R3. This works because the matching attributes in Child B and Child C have an alternative path to their base attributes in Parent and Main. How referential attributes are resolved to base attributes and why they should all resolve to a single base attribute will be discussed another day.