Finding a Way-Navigation

---

Finding a Way—Navigation

Whenever you associate two classes, you are indicating that instances of these classes can “see” and communicate with each other. That means you can navigate from one side of an association (the source) to the other side (the target). An association is navigable in both directions if the objects involved invoke operations (in which an object sends a message to another object to ask the second object to perform some specific behavior) on each other. If you have objects involved in an association and they can navigate in both directions, then each object can serve as both a source and a target.

You may only need to navigate an association in one direction during runtime. To show this navigation constraint, you place an arrow on the association line to indicate the direction of the invocation—from the source object toward the target object. We generally use navigation arrows during design time. If an association has no arrow, then (normally) it’s okay to implement the association in both directions. If an association has an arrow, then you program the association only in the direction of the arrow—and not the other direction.

In Figure 4-16, the arrow on the rents association line indicates that an instance of Client can invoke methods of CrashDummy objects at runtime. However, an instance of CrashDummy cannot see (and thus cannot navigate to) instances of the Client class, as it would have to do in order to invoke behavior on instances of Client.

Figure 4-16: Using the navigation-arrow symbol.

---