下面是从网上搜集的一些看法：
---------
1.
---------
Dependency Relationship
Draw a dependency relationship between two classes, or between a
class and an interface, to show that the client class depends on the
supplier class/interface to provide certain services, such as:
?The client class accesses a value (constant or variable) defined in the supplier class/interface.
?Operations of the client class invoke operations of the supplier class/interface.
?Operations of the client class have signatures whose return class
or arguments are instances of the supplier class/interface.
A dependency relationship is a dotted line with an arrowhead at one end:The arrowhead points to the supplier class.
Association Relationship
An association provides a pathway for communication. The
communication can be between use cases and actors, between two classes
or between a class and an interface. Associations are the most general
of all relationships and consequentially the most semantically weak.
If two objects are usually considered independently, the relationship is
an association
---------
2.
---------
Martin Fowler
If you have an association from Class A to Class B then that means
every instance of class A has some kind of link to class B. Now exactly
what people mean by "some kind of link" varies, it may be a conceptual
link, a method of the form getA or a field inside class A. But the usual
notion is that the link exists at all times (although if the lower
bound is 0 it may be empty). This link can be used by any method of A
and, if exposed, by other classes too.
With a parameter the connection between A and B only exists within
the scope of the method that took the parameter. No other method can use
the connection. As such that, for most people I come across, means that
it is not an association.
The dependency means that if you change the interface of B then you
may have to change A. An association usually implies a dependency, but
not vice-versa, as the parameter example suggests.
---------
3.
---------
Robert C. Martin
However, association is not free of semantics. An association is a
data relationship. i.e. the implementation must use some sort of data
variable to implement it. Typically this is done with some kind of
member variable or instance variable that refers to the associate. In
C++ we might create a pointer variable, in Java a reference variable.
Or we might use some kind of string that represents the associate in a
dictionary somewhere.
In order for a message to be send between two objects, an
association must exist between their two classes; and that association
must be navigable in the direction that the message was sent.
---------
4.
---------
quote:
>What is the difference between Association and Dependency?
>My understanding so far was:
>If an object of class A has a reference to an object of class B in its
>attribute structure, it is association.
Robert C. Martin's answer:
Er, well, uh -- hmmm.
That's as good a definition as any I suppose. There are so many
different colloquialisms and slangs for UML that I guess it hardly
matters any more.
There was a time when an association was the channel between classes
over which messages were sent. No message, no association. But that
rule has been relaxed by so much conventional usage that I don't think
it can hold any more.
Nowadays we seem to use association and aggregation interchangeably
to represent a data field (except, of course, that everybody has their
own private definition for what the white diamond means.) Dependency
if very commonly used to represent an argument passed to a function.
This was not the original intent of UML, but it's the way things have
turned out.
There was a time when dependency meant that a class knew about
another, but did not send messages. Data structures had dependencies on
their members because they didn't send them messages, whereas classes
had associations with their members because they did send them
messages. But that nice separation has gotten so badly muddled that it
has become useless.
Perhaps you can read from my tone that I'm pretty disillusioned with
UML. Too bad. It could have been a standard. Now, I think its just
going to be a confusing compendium of confounding conventions.
---------
5.
---------
//
From UML 2.0 Superstructure Final Adopted Specification:
"An association describes a set of tuples whose values refer to typed instances." (p. 97)
"A dependency is a relationship that signifies that a single or a
set of model elements requires other model elements for their
specification or implementation." (p. 124)
---------
6.
---------
依赖是比关联弱的关系，关联代表一种结构化的关系，体现在生成的代码中，以java为例：
若类A单向关联指向类B，则在类A中存在一个属性B b。
若类A依赖类B，则不会有这个属性，类B的实例可能存在于某个方法调用的参数中，或某个方法的局部变量中。
---------
7.
---------
关联有双向与单向之分，类A与类B双向关联可以是A与B相互可以作为对方的一个attribute，单向的话，就指其中一个类作为另一个类中的
attribute；依赖就只有单向的，不存在attribute的问题，例如类A依赖类B，表示在类A中有三种类B的使用方法：一是类B是全局的，二是
类B在类A中实例化，三是类B作为参数被传递
---------
8.
---------
关联是一种结构关系，表现为一个对象能够获得另一个对象的实例引用并调用它的服务（即使用它）；依赖是一种使用关系，表现为一个对象仅仅是调用了另一个对象的服务