The revised edition of Using UML will reflect this. In brief, though, UML intends that the associations between classes describe the non-local static data structure of the system: if there is an association between classes A and B, navigable from A to B, then an implementation of class A should include a slot for (a reference to) an object of class B. According to this view, it is not true to say, as we do, that A and B are associated whenever an object of class A sends a message to an object of class B. For example, such a message send may also occur when the object of class B is a global object, or the value of a local variable in a method of A, or a parameter to an operation of B; none of these necessarily correspond to associations in UML's interpretation according to Rumbaugh.
However, in such cases it is clear that class A depends on class B in some way; if B changes A may have to change. This dependency may be shown as such (using a dashed arrow) in the class diagram; but this does not adequately show the "association-like" character of the dependency; dependencies between classes are supposed to be between the classes themselves rather than between their instances, which isn't really the case here.
This conflict is reflected in UML by the fact that it defines stereotypes of association to record these other kinds of association-like dependency - even though they are not actually associations!! For example, the stereotype << global >> on an association "Specifies that the target is a global element known to all elements, rather than an actual association".
This seems unfortunate; for it means that a use of a stereotype becomes essential to the correctness of a model, rather than giving extra information about it. Perhaps a future release of UML can resolve the issue.