8.4 Association Loops


When we build a model with many classes and associations, it is often possible to trace a path from a class, through other associations and classes, back to the class whence we came. This pattern in the graphic is referred to as an association loop.

Definition: An association loop is a set of associations that together make up a path from one class, through other classes, back to the same class.

An association loop sometimes has a meaning separate from the sum of its parts, and sometimes it doesn't. Proper analysis of loops enhances our understanding of the problem and the diverse constraints between the associations in the domain.

In this section, we will examine several types of association loops:

  • Unconstrained association loops, in which the associations mean different things and traversing the associations in different directions leads to different results.

  • Redundant association loops, in which one association merely restates the same facts (and results in the same instances) as associations already on the model.

  • Constrained association loops, in which there are specific domain rules and policies such that sets of associations are interrelated. We describe two commonly occurring constrained associations, the equal set constraint and the subset constraint.

8.4.1 Unconstrained Association Loops

An unconstrained association loop is one in which a path from one class to another in the same loop moving in one direction can lead to completely different sets of instances than going in the other direction.

Consider Figure 8.15, for example.

Figure 8.15. Loop of Unconstrained Associations

graphics/08fig15.gif

Starting from the Parent class, a given parent formerly attended some number of schools. Moving in the other direction from the Parent class, a Parent raises some number of (school-age) children, each of whom attends school. While it is possible that some students attend the same school their parents formerly attended, it is certainly not a requirement. Any matching associations between the set of schools attended by a parent and the set of schools attended by children of those parents is purely coincidental.

The association loop is unconstrained in that examining the set of instances reached by traversing in one direction around the loop does not impose constraints on the set of instances reached by traversing in the other direction.

There are no additional constraints not already described by existing associations, making our job easy. The model in Figure 8.15 is fine as is.

8.4.2 Redundant Associations

If we attempt to model every possible association between classes, some associations may be redundant. Consider Figure 8.16.

Figure 8.16. Redundant Association in a Loop

graphics/08fig16.gif

The RAISES CHILD WHO ATTENDS association is nothing more than the concatenation of the two other associations and captures no new information. The name of the association even reads like a concatenation of two other associations, and the presence of the Child class in the name of the association is an obvious clue to its redundancy. The association is completely redundant and should not be added to the model.

In such cases, the redundant association, R4, should be removed.

8.4.3 Equal Set Constraints

In other situations, domain rules and policies are such that the two sets of associations yield identical sets of instances but mean different things. Figure 8.17 illustrates the case where it is policy that a child can attend a given school only if the child lives in the same district as that school.

Figure 8.17. Loop of Constrained Associations

graphics/08fig17.gif

Figure 8.18 shows how the association description incorporates the real business rule "child can only attend a school in the district where he lives" on the Child class. The constraint can be expressed in OCL, as shown in Figure 8.19.

Figure 8.18. Description of a Constrained Association

graphics/08fig18.gif

Figure 8.19. OCL for the Equal Set Constraint

graphics/08fig19.gif

graphics/exclamation.gif

The same loop constraint can be expressed differently depending on the context of the constraint. In Figure 8.19 and Figure 8.20, the constraint is written from the perspective of the Child class. The constraint could just as well have been written from the perspective of the School:


context School inv
        self.Child -> forAll( s | s.District = Self.District )

stating, in English:

The children who attend the school must all live in the district that administers the school.

Each loop constraint needs to be written only once. We recommend placing the constraint in the context that makes for the simplest constraint expression.

The constraint can also be written as a boolean function in action language. An example for any instance of Child is shown in Figure 8.20.

Figure 8.20. Action Language for the Equal Set Constraint

graphics/08fig20.gif

When the set of instances selected by traversing a loop in one direction has to be the same as the set of instances selected by traversing the loop in the opposite direction, we say that the loop is subject to an equal set constraint. In Figure 8.17, the instances selected by traversing from Child to District directly (R5) has to be the same as the set of instances selected by traversing via the Child class (R1 + R6), according to the rules and policies of the domain.

This commonly occurring constraint can be written on the class diagram as shown in Figure 8.21.

Figure 8.21. Graphical Representation of an Equal Set Constraint

graphics/08fig21.gif

Equal Set Constraints and Redundant Associations

An equal set constraint differs from a set of redundant associations in that the sets of associations mean different things. This cannot be determined by a mere mechanical evaluation of the models; it requires an understanding of the meanings of the associations, typically gained by writing the association descriptions. So write those descriptions!

8.4.4 Subset Constraints

Consider the following: A parent may be a member of the Parent Teacher Association (PTA) only of a school attended by the parent's child. For example, a parent with one child attending school A and another child attending school B could serve on the PTAs of A, B, both, or neither, but that parent cannot serve (as a parent) on the PTA of just any school.

This association loop is constrained so that the set of instances selected by traversing from parent to school directly (R7) has to be a subset of the instances selected by traversing via the Child class (R2 + R1), according to the rules and policies of the domain, as shown in Figure 8.22.

Figure 8.22. Subset Constrained Associations

graphics/08fig22.gif

The association is described in Figure 8.23.

Figure 8.23. Description of a Subset Constrained Association

graphics/08fig23.gif

Loop Constraints with Combined Referential Attributes

The loop constraints for fully and partially constrained associations can be written using referential attributes.

In Shlaer-Mellor, identifiers and referential attributes were the preferred way to formalize relationships and to specify relationship loop constraints. This was based on the notion that one association's instance set (the set of corresponding instances) can be completely determined by the values of the other relationships around the loop. In the case of the Child, School, and District model of Figure 8.17, the associations could be formalized using referential attributes, as shown below:

graphics/08fig21a.gif

In the Child class, the referential attributes residenceDistrict and schoolDistrict had to be the same. These two referential attributes would therefore be combined into a single referential attribute that formalizes both associations.

The OCL is:


Context Parent inv:
         Self.School -> exists( Self.child )

and the action language is:


Select one ptaSchool related by self->School[R7];
select many childSchools related by self->Parent[R7]->Child[R2]->School[R1]
    where selected == ptaSchool;
return not_empty childSchools;

Contrast this with the OCL for the equal set constraint. In Figure 8.19, the predicate stated that two sets must be equal; however, in the example above, the derived association is a subset. One or both parents may serve, but only if one of their children attends that school. The subset constraint is depicted in Figure 8.24.

Figure 8.24. Graphical Representation of a Subset Constraint

graphics/08fig24.gif



Executable UML. A Foundation for Model-Driven Architecture
Executable UML: A Foundation for Model-Driven Architecture
ISBN: 0201748045
EAN: 2147483647
Year: 2001
Pages: 161

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net