I'm scrapped my previous graphics engine due to bad design. It just became too hard and awkward to add new things, or attempt to fix many of the design problems that I had. So, I've decided that I need to design everything much more so than I did the first time around (note: not at all). I'm doing some UML in dia (winXP), and I found that my UML skills are a little rusty. I have a bunch of classes and I'm wondering when an association should become a dependency, or vice versa. I have the VideoDriver class, which has a dependency to a class that keeps the dimensions of the window because the dimension object is a member variable of the VideoDriver. I have another object of type 'A' which there will be a list of in the VideoDriver class, but the list won't necessarily be used. Is this just an association? Or a dependency?

"Wondering when an association should become a dependency, or vice versa" is wrong.
Aren't you designing a graphics engine? Why should you stop your design activity to bother with UML details?
Since you know what you mean, choose either kind of line for your diagram, which one doesn't matter, optionally add notes or stereotypes to explain what the link stands for, and go ahead. Later in the design cycle, when you have learned more about your design, you can revise previous diagrams.

However, to quote the UML 2 standard,

Quote: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).

Quote:A dependency signifies a supplier/client relationship between model elements where the modification of the supplier may impact the client model elements. A dependency implies the semantics of the client is not complete without the supplier.
The presence of dependency relationships in a model does not have any runtime semantics implications, it is all given in
terms of the model-elements that participate in the relationship, not in terms of their instances.

Quote: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.
An end property of an association that is owned by an end class or that is a navigable owned end of the association
indicates that the association is navigable from the opposite ends, otherwise the association is not navigable from the
opposite ends.

Quote:An association declares that there can be links between instances of the associated types. A link is a tuple with one value
for each end of the association, where each value is an instance of the type of the end.
When one or more ends of the association have isUnique=false, it is possible to have several links associating the same
set of instances. In such a case, links carry an additional identifier apart from their end values.
When one or more ends of the association are ordered, links carry ordering information in addition to their end values.
For an association with N ends, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the association that refer to these specific instances will identify a collection of instances at the other end. The multiplicity of the association end constrains the size of this collection. If the end is marked as ordered, this collection will be ordered. If the end is marked as unique, this collection is a set; otherwise it allows duplicate elements.

Can you show us some diagrams you have created so far? I'm very interested in seeing some examples.