Bidirectional Associations

Bidirectional associations are the default associations between two classes and are represented by a straight line between two classes. Both classes are aware of each other and of their relationship with each other. In the example above, the Car class and RoadTrip class are interrelated. At one end of the line the Car takes on the association of "assignedCar" with the multiplicity value of 0..1 which means that when the instance of RoadTrip exists, it can either have one instance of Car associated with it or no Cars associated with it. In this case, a separate Caravan class with a multiplicity value of 0..* is needed to demonstrate that a RoadTrip could have multiple instances of Cars associated with it. Since one Car instance could have multiple "getRoadTrip" associations-- in other words, one car could go on multiple road trips--the multiplicity value is set to 0..*

Unidirectional Association

A unidirectional association is drawn as a unbroken line with an open arrowhead pointing from the knowing class to the known class. In this case, on your road trip through Arizona you might run across a speed trap where a speed cam records your driving activity, but you won't know about it until you get notification in the mail. It isn't drawn in the image but in this case the multiplicity value would be 0..* depending on how many times you drive by the speed cam.

 

Multiple and Dynamic Classification

Classification refers to the relationship between an object and its type.

Most methods make certain assumptions about this type of relationshipassumptions that are also present in mainstream OO programming languages. These assumptions were questioned by Jim Odell, who felt that they were too restrictive for conceptual modeling. The assumptions are of single, static classification of objects; Odell suggests using multiple, dynamic classification of objects for conceptual models.

In single classification, an object belongs to a single type, which may inherit from supertypes. In multiple classification, an object may be described by several types that are not necessarily connected by inheritance.

Note that multiple classification is different from multiple inheritance. Multiple inheritance says that a type may have many supertypes, but that a single type must be defined for each object. Multiple classification allows multiple types for an object without defining a specific type for the purpose.

For example, consider a person subtyped as either man or woman, doctor or nurse, patient or not (see Figure 6-4). Multiple classification allows an object to have any of these types assigned to it in any allowable combination, without the need for types to be defined for all the legal combinations.

Figure 6-4. Multiple Classification

If you use multiple classification, you need to be sure that you make it clear which combinations are legal. You do this by labeling a generalization line with a discriminator, which is an indication of the basis of the subtyping. Several subtypes can share the same discriminator. All subtypes with the same discriminator are disjoint; that is, any instance of the supertype may be an instance of only one of the subtypes within that discriminator. A good convention is to have all subclasses that use one discriminator roll up to one triangle, as shown in Figure 6-4. Alternatively, you can have several arrows with the same text label.

A useful constraint is to say that any instance of the superclass must be an instance of one of the subtypes of a group. (The superclass is then abstract.) There's some confusion in the standard at the moment, but many people use the constraint {complete} to show this.

To illustrate, note the following legal combinations of subtypes in the diagram: (Female, Patient, Nurse); (Male, Physiotherapist); (Female, Patient); and (Female, Doctor, Surgeon). Note also that such combinations as (Patient, Doctor) and (Male, Doctor, Nurse) are illegal. The first set is illegal because it doesn't include a type from the {complete} Sex discriminator; the second set is illegal because it contains two types from the Role discriminator. Single classification, by definition, corresponds to a single, unlabeled discriminator.

Another question is whether an object may change its type. For example, when a bank account is overdrawn, it substantially changes its behavior. Specifically, several operations (including "withdraw" and "close") get overridden.

Dynamic classification allows objects to change type within the subtyping structure; static classification does not. With static classification, a separation is made between types and states; dynamic classification combines these notions.

Should you use multiple, dynamic classification? I believe it is useful for conceptual modeling. You can do it with specification modeling, but you have to be comfortable with the techniques for implementing it. The trick is to implement in such a way that it looks the same as subclassing from the interface so that a user of a class cannot tell which implementation is being used. (See Fowler 1997 for some techniques.) However, like most of these things, the choice depends on the circumstances, and you have to use your best judgment. The transformation from a multiple, dynamic interface to a single static implementation may well be more trouble than it is worth.

Figure 6-5 shows an example of using dynamic classification for a person's job, which, of course, can change. This can be appropriate, but the subtypes would need additional behavior, instead of being just labels. In these cases, it is often worth creating a separate class for the job and linking the person to it with an association. I wrote a pattern, called Role Models, on this subject; you can find information about this pattern, and other information that supplements my Analysis Patterns book, on my home page.

Figure 6-5. Dynamic Classification

3.4.2 Realizations

A realization from a source element (called the realization element) to a target element (called the specification element) indicates that the source element supports at least all the operations of the target element without necessarily having to support any attributes or associations of the target element. For example, an undifferentiated class or implementation class may play the role defined by a type and may provide the service defined by an interface, if the class supports the operations defined by the type and interface. A realization allows us to reuse the operations of types and interfaces where a realization element is said to realize its specification elements.

A realization is shown as a dashed-line path from the source element to the target element, with a large hollow triangle at the end of the path connected to the target element. When the target element is an interface shown as a small circle, the realization is shown as a solid-line path connecting the source and interface.

3.4.2.1 Undifferentiated classes

Figure 3-29 shows a list of types and interfaces that the Worker class supports. Based on Figure 3-29, Figure 3-34 shows that the Worker class realizes those types and interfaces. The source element is the Worker class, and the other elements are the targets. Figure 3-29 shows how interfaces and types are used in the various associations between the Worker class and other classes, while Figure 3-34 shows that the Worker class explicitly realizes these interfaces and types independent of how they are used in relationships.

Figure 3-34. Realizations for the Worker class

Based on Figure 3-29, Figure 3-35 shows the interfaces work products realize. The source element is the WorkProduct class and the other elements are the targets.

Figure 3-35. Realizations for the WorkProduct class

Because a realization from a source class to a target element indicates that objects of the source class support all the operations of the target element, objects of the source class may be substituted for objects of other classes that also realize the same target element. Therefore, Figure 3-34 shows that a worker object may be substituted for objects of other classes that realize the same types and interfaces as the worker object, and objects of other classes that realize the same types and interfaces as the worker object may be substituted for worker objects. That is, if two objects realize the same type or interface, they may be substituted for one another. Figure 3-35 illustrates this.

3.4.2.2 Implementation classes

Based on Figure 3-27, Figure 3-36 shows that the Worker class may be implemented as an employee table, the WorkProduct class may be implemented as an artifact table, and the UnitOfWork class may be implemented as work order table, if you are to implement your classes in a database management system. This is indicated with the realization relationships between the Employee implementation class realizing the Workerclass, the WorkOrder implementation class realizing the UnitOfWork class, and the Artifact implementation class realizing the WorkProduct class.

Figure 3-36. Realizations of undifferentiated classes by implementation classes

When an implementation class realizes an undifferentiated class, it must also realize the types and interfaces that the undifferentiated class realizes; otherwise, it could not play the roles defined by the undifferentiated class's types and provide the services defined by the undifferentiated class's interfaces.

Based on Figure 3-36 and Figure 3-34, Figure 3-37 shows the types and interfaces the Employee implementation class realizes.

Figure 3-37. Realizations for the Employee implementation class

Based on Figure 3-36 and Figure 3-35, Figure 3-38 shows the interfaces the Artifact implementation class realizes.

Figure 3-38. Realizations for the Artifact implementation class

Because a realization from a source class to a target element indicates that objects of the source class support all the operations of the target element, objects of the source class may be substituted for objects of other classes that also realize the same target element. Therefore, Figure 3-37 shows that an employee object may be substituted for objects of other classes that realize the same types and interfaces as the employee object, and objects of other classes that realize the same types and interfaces as the employee object may be substituted for employee objects. Figure 3-38 shows the same for an artifact object.

3.4.3 Dependencies

A dependency from a source element ( called the client) to a target element (called the supplier) indicates that the source element uses or depends on the target element; if the target element changes, the source element may require a change. For example, a UnitOfWork uses the IConsumableinterface as a consumer and uses the IProducible interface as a producer; if either interface changes, the UnitOfWork may require a change. Figure 3-29 shows the interfaces used by UnitOfWork.

A dependency is shown as a dashed-line path from the source element to the target element. The dependency may be marked with the usekeyword; however, the keyword is often omitted because the meaning is evident from how the dependency is used. Also, notice that a dependency does not have a large hollow triangle at the end of the path, but has an open arrow.

Based on Figure 3-29, Figure 3-39 shows the dependencies between units of work and work products. Notice that a realization may be shown as a dependency marked with the realize keyword, as shown in Figure 3-39 between the WorkProduct class and the IProducible interface.

Figure 3-39. Realizations and dependencies

Figure 3-40 shows the dependencies between the interfaces discussed in this chapter and the parameter and return types for their operations. For example, IProjectManager must depend on Project, because many of its operations take a Project object as a parameter.

Figure 3-40. Dependencies between interfaces and return types