Associations vs Dependencies

[Bill Egge]

Can anyone explain the difference between an association and a dependency?

Here are some problems:

I am diagramming a business process.  Its actually just a secratary doing a mail merge and the mail merge creates documents in a file system directory.

I am confused about the difference between an association and a dependency.  It seems to me that the Word Macro is dependent on the output directory, but instead I have only shown it as an association.

Here is the image

[thomaskilian]

In short: an association is stronger than a dependency.
UML 2.0 definitions:

Association
An association describes a set of tuples whose values refers to typed instances. An instance of an association is called a link.
Description
An association specifies a semantic relationship that can occur between typed instances. It has at least two ends represented by
properties, each of which is connected to the type of the end. More than one end of the association may have the same type.
When a property is owned by an association it represents a non-navigable end of the association. In this case the property does
not appear in the namespace of any of the associated classifiers. When a property at an end of an association is owned by one
of the associated classifiers it represents a navigable end of the association. In this case the property is also an attribute of the
associated classifier. Only binary associations may have navigable ends.

Dependency
Description
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. This means that the complete semantics of the depending elements is either semantically or
structurally dependent on the definition of the supplier element(s).

[SF_lt]

not very descriptive UML2 definitions As most standards or proposals.

In both cases: association & dependency object uses another object - and if this object changes, then changes must reflect on the first object too.

I either can't say, what are (main) differences between association & dependency; use association in all cases ;-)

Have tried to search the net for good explanation, but haven't found :-/

[sargasso]

An association is always structural.  In particular, as per the definition:

It has at least two ends represented by properties, each of which is connected to the type of the end.

As thomas says, an association is stronger than a dependency.  We may use (structural) dependency links to indicate exactly that.  For example, "I know that there is a relationship between this object and that object, but at this point in the development of the model I'm d*mned if I know what the relationship is".  IOW:

[dependent_object] - - - - - - - - - - - - > [supplier_object]

highlights the fact that the relationship has not (yet) been fully defined in the model.  On the other hand:

[dependent_object] ------------------------- [supplier_object]

does not immediately impress that idea of uncertainty to the casual viewer.

Also dependencies do not have to be structural.  

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.

Specifically , we can also use dependencies to show that a specific class will rely operationally on another class.  For example, a "LoginUI" class may depend on a "Logger" class:

[LoginUI] - - - - -<<use>> - - - - - - >[Logger]

IOW this can denote the fact that the implementation of the LoginUI class dependent on the implementation of the [Logger] class in some operational way.

hth
bruce

[SF_lt]

sargasso, could you explain, what do mean by saying, that  association is always structural?

An association is always structural.  In particular, as per the definition:
 
Quote:It has at least two ends represented by properties, each of which is connected to the type of the end.  
 

dependency also has two ends - as association (except N-association) do. About what properties? can't understand meening of the sentence end - every end is connected to something, there can't by free flying end or link not connected to anything.

[thomaskilian]

You could take the translation of the words literally. A dependency just gives you an idea that the connected elements depend on each other (as the direction will tell you). This dependency can be used in modelling classes at an early stage or (also in later stages) that packages depenend on each other. An association on the other hand clearly states that you have some link (a variable, an object pointer, something "material") stating the existence of the associated element in the associating element. This is what you call structure.

[sargasso]

Yep, that's what I meant.  Structure vs. behaviour.

Even though we use associations willy-nilly in almost all diagrams, their formal high-church-of-UML definition is that of a structural design component.

Edit: On reflection, this does not answer your question.  In the sentence quoted from the standard, they say that each of the ends is represented by a property - that is to my thinking shortspeak for an "end" of an association is characterised by a property of the element on that end.

[  Class   ]
[_______]
[prop:int ]---------------------                        (! a one ended association )
[----------]
[_______]

So in the above, the LH end of the association could be characterised by the property prop and ergo, is structural.
The corollary is: You cannot characterise the end of an association as a method

Turning to the "two ends" question, you have to realise that although we on this planet only ever "see" links such as dependencies and associations in the context of a connection between elements, those on the OMG planet both see and write about links as if they can exist by themselves.  Thus a specific link definition may talk about it being 2-ended or n-ended.  So, for associations, they talk about "at least two ends"  whereas here, we just add an association diamond and cease to think about it.

hth
bruce

[Paolo F Cantoni]

Hi all,

The issue is further compounded by the fact that the UML2
Infrastructure document specifically states (correctly) that a
navigable association with a role IS an attribute.  (Geoffrey,
did you see this?)

At our site, which currently uses another tool, we have created
our own generators.  We have created composite associations
(with stereotype: <<attributive>>)for each attribute that
references another class (as opposed to a simple datatype).  
Multiplicity is set appropriately at both ends.

Further, to aid visualization and to cross check the model, we
create a dependency (stereotype: <<attributive>>) between the
dependent (home) class and the independent (referenced) class.
We set the multiplicity of the dependency to the number of
attributes that reference the class, and the name of the
dependency (not normally used) to the list of names of the
attributes implying this dependency.

By automating this process and then automatically creating
automata that traversed the model and drew diagrams under our
control we were able to "see" the model in new ways.

Once we started doing this, anomalies in the model suddenly
started to be "in your face"!

Paolo

[shnplr]

I'm new to UML (a book is on its way), still using the trial-version and my company has purchased licences for EA

I'll be posting my own questions shortly...however reading this thread I dont see the question answered (unless I'm reading too literally).  Is Word to FileDir an association or a dependancy (or something else perhaps)?

maybe if the 'relationship' is not obvious, the answer is in the model (whats being related) not the uml. I would show the secretary as an actor, and perhaps change the FileDir to something more generic (or remove it)

Perhaps the storing and retrieving of documents is a factor in this design...(it may be a separate use case), but at this level I'd just show an association between the wp and output (with a note saying where the macro should save to.)

Edit: cause I'm new!

[Paolo F Cantoni]

I am diagramming a business process.  Its actually just a secretary doing a mail merge and the mail merge creates documents in a file system directory.

Bill, sorry for getting back to this so late, but as shnplr has correctly said, we haven't answered your original question.  One of the reasons is that, I believe, the basis of your original diagram is incorrect.

It isn't, and can't be, a diagram of a business process - because it has NO behavioural elements.  It may be a diagram of a set of structural elements involved in a particular business process.

If I understand your intent, the secretary runs the macro which, either automagically or by user input, locates the Excel data source, takes that data and (again, either automagically or by user input) locates an output file directory and generates a set of TermLetters.

Assuming that is the case, then MSWord accesses the XCellDataSource (an association), it references the FileSystemDir (another association) and it generates TermLetters (a third association).  It is run by Secretary (another association - but reversed in direction from yours).  FileSystemDir contains TermLetter (a composite aggregation association - because if you delete FileSystemDir, the included TermLetters are destroyed).

As far as I can see, as Bruce (Sargasso) pointed out, there are only structural relationships here.  No behavioural (dependency) ones.

Does that help?

Paolo

[thomaskilian]

shnlpr,

Is Word to FileDir an association or a dependancy (or something else perhaps)?

MY intepretation (which is probably not the editors intention) is that Word depends on FileDir (existence assumed, not a real association) while Word is associated with XCellDataSource (in the form that the Cell is used in Word). Vice versa you could state that FileDir is associated with word (as existing object within FileDir; but that's likely out of scope).

maybe if the 'relationship' is not obvious, the answer is in the model (whats being related) not the uml. I would show the secretary as an actor, and perhaps change the FileDir to something more generic (or remove it)
 

Also MY interpretation: the class diagram is mixing information that ought to be stored in a use case diagram (the "Runs macro"). And yes, I'd also use the Actor stereotype here. Going on a step further you could associate Word with the Macro (another class), instead.

You can turn the coin as you like. It's always a lot of interpretation. The editor builds an abstract picture of what he wants to show us. It is much dependant on the editor (artist) whether he fails or succeeds in showing us his thoughts (be it Rembrandt, Picasso or an amateur).