Associations

An association is a structural relationship that specifies that objects of one thing are connected to objects of another [BRJ99]. An association shows that these two classes are connected to each other and navigation from one object to the other should be possible. This navigation is made possible through associations. Figure 4-1 shows an example of association between two classes, Plant and Soil.

Figure 4-1. Example of association between classes Plant and Soil.

Figure 4-1. Example of association between classes Plant and Soil.

An association has a name to describe the meaning of the relationship. Names should be meaningful to present unambiguously the kind of relationship between objects. The association growsln represents the fact that a plant grows in soil. The association defines quite well the role of each of the classes participating in the relationship; plant processes use soil data and soil processes use plant data. Associations enable data transfer and resource sharing among objects. In this case the association is bidirectional; data in class Soil can be accessed from class Plant and data in class Plant can be accessed from class Soil.

Accessibility between classes related with an association, in most of the programming languages, is translated with a reference of the type of the other class involved in the association. For example, access to class Soil from class Plant is possible by defining in class Plant an attribute of type Soil, which will reference the corresponding Soil object. In the same way, class Soil will have an attribute of type Plant pointing to the corresponding Plant object. In cases when both classes in a relationship point to each other, the association is bidirectional.

Although associations may have a name, some designers do not use the names, especially when the relationship between objects becomes obvious. It is recommended that all the information be provided that helps a potential user understand the presented problem.

Classes participating in an association play different roles; therefore, it is a good designing practice to explicitly define the role for each of them. Figure 4-2 shows an example of an association between classes Plant and Soil with roles defined for both classes.

Figure 4-2. Example of an association with roles defined for both classes.

Figure 4-2. Example of an association with roles defined for both classes.

In some cases, such as in the one presented in Figure 4-2 above, it may be redundant to provide both the name of the association and the respective roles of each class. Only the name of the association may be enough to describe the nature of the relationship. The only additional information one may obtain from the names of the roles in Figure 4-2 is that the role names will be used as attribute names in respective classes. Thus, in class Plant, an attribute named theSoil will be declared to reference an object of type Soil (Figure 4-3). The same for the class Soil, an attribute of type Plant will be declared to reference a Plant object (Figure 4-4).

1 package Plant;

2 public class Plant {

3 Soil theSoil;

4 public PlantO {}

Figure 4-3. Attribute soil allows access to object Soil.

1 package Soil;

2 public class Soil {

3 Plant thePlant;

4 public SoilO {}

Figure 4-4. Attribute thePlant allows access to object Plant.

In some scenarios, only one class should have access to the data from the other class of the association. In this case, the association is unidirectional. Figure 4-5 shows an example of a unidirectional association.

Plant

usesWeatherDdta -^

Weather

0 0

Post a comment