Dependency vs. association ?

[Jim Janssens]

My definition:

A dependency is used when the referenced class is not directly used inside the referencing class, but only passes trough the class. For example:

A customerDAO would have a dependency to a customerTO, since the DAO uses to TO to store it in database, but it has no direct association with the TO (the TO is not a instance variable of the DAO).

In the assumption this is more or less correct, I have a question about this:

Supose I have an SSB forwarding requests to another class (called 'Processor'), and that particular class is being looked up by a factory pattern. But since the class diagram is high level, I do not want to draw the factory pattern. So I have only two classes , the SSB and the Processor class (which is an interface). Now, should I draw a association or a dependency between the SSB and that class ?

I feel like drawing a dependency, since an association would tell that the SSB has the processor as an instance variable. This is rather strange since the Processor class is an interface. Further more, its not said that at the end the SSB will have the real class (ProcessorImpl for example) as an instance variable. It might as well have the factory as instance variable and lookup the ProcessorImpl class in each method using the factory instance variable (asuming the factory has a caching mechanism or something)....

Any suggestions ?

[Stan James]

When and why is the distinction between dependency and association important to you? It usually isn't to me, but that doesn't mean it won't be critical to you at some point.

I'm most concerned about communicating compile time dependencies. It sounds like SSB has a strong compile time dependency on the interface. The interface must be known and present to compile. Dependency on stable, abstract classes is a good thing and interfaces improve your odds of stability and abstraction.

For high level diagrams, I'd leave the factory out, too. That's an implementation detail, important if you have a cold hand-off from designer to coder, but less important if they have a short conversation and say "Hey, were do I get the concrete object for this interface?", "Oh, from a factory like the one we used last week."

[Jim Janssens]

Ok, but when would you chose a dependency over an association, or the other way around ? An assocciation tells much more about the 'link' . Tells something about the cardinality, navigateability, the type of association (aggregation, composition) a dependency does not give that information really...

Therefore I was asking myself the question; if the SSB uses a component (which is an interface, the actual implementation will be looked up using a factory) do I use dependency or assocication ?

With the association I feel uncomfortable, since I do not want specify how many objects the SSB will refer to (1-1 or 1-1..* etc) .

I also feel a difference between the conceptual domain model and the more technical classes. For example: such conceptual model for a school might imply a student being enrolled in one or more courses. The diagram will look like: student[0..*] ----- [0..*] courses. This indicates that a student may be enrolled in many courses and that a course can have many students. Further more, you can get the courses for a particular student and the students enrolled for a particular course. This all makes sense.

However, an SSB pointing to an interface (possibly some helper object) is a more non-conceptual thing, its not related to the domain model and is technical perception.

So, my questions:

1. how does a dependency relate to an assocation, when do you use either them ?

2. When you specify a directed assocation without cardinality, what is the difference with a dependency ?

[Edwin Keeton]

The distinction between the concepts of an association and a dependency tends to blur depending on the context. In a general, abstract way, you can say that ClassA depends on ClassB if a change to ClassB somehow affects ClassA. In the continuum from analysis to design, this definition is probably most useful towards the analysis end. Here also the distinction between dependency and association overlap and blur, and are essentially not important.

When you shift focus to the design end, associations represent structural links (object references) and dependencies represent any remaining non-structural, temporary links such as method argument classes.

This is a lot easier to accept if you let the "U" in UML stand for Useful, but not necessarily rigorous.