IMO a dependency is a fairly uncategorised relationship, albeit one that is supported by a rather large range of standard stereotypes. Typically dependencies are used early in analysis work when the actual relationship is less well defined. For example in our logical design level models we find a lot of <<use>> dependencies between components and between logical classes (or business objects etc).
As design gets more sophisticated these dependencies tend to get replaced by other relationships, as in your example by an object flow.
Having said that....
We see a FAQ at our site regarding control flows vs object flows - when do I use etc. My own interpretation of the answer is as follows - it may not necessarily be "High Church" UML but it works for me, hey!
Both object and control flows are only used between
actionable elements (activities, actions etc) not between actionables and structural elements (objects, components etc). Both flows are visually similar and the distinction can be immaterial to any of the audience. They do, on the other hand, provide a means of distinction for the experienced practicioner - between transfer of control betwen two actionables based purely on an abstract - such as the flow of time say - and transfer based on some physical exchange of an object - say a completed timesheet.
So why distinguish anyway? Purely to avoid having to explicitly include the structural element in the diagram. The name of the object flow defines the object being transferred. Imagine, for the sake of hyperbole, a model diagram of a buiness flow that involved the movement of a business form through, say 30 odd activities. Since the form object can only appear once in the diagram we would end up with 30 dependencies between each activity and the object element. Not so easy to read. Using object flows - each named "form BQZ310" for example, the same information is conveyed in a much conciser format.
Now lets look at the relatioship between an actionable and a structural element - activity A to object D for instance. In the early stages of analysis, all we know is that somehow A depends on D. Cool, bang an unstereotyped dependency link between them - from A to D. Similarly D seems to have come from something to do with B, so bung a dependency between D and B (note reversal of the direction). For the sake of local nomeclature B seems to "produce" D (other places may create it, build it ... whatever) So lets stereotype the D to B dependency as <<produced by>>.
So what have we got? A model expressed from the viewpoint of A that it is dependent on a D thing that is produced by that other famous activity B:
[A] ---<<uses>> -----> {D} -----<<produced by>>---->
(This diagram can of course be simplified if required to:
[A] - - - - - - - >
where the dependency description in the note on the link says "A uses the D object produced by B")
Finally, remember that the choice of digramming style is up to you within the constraint of effectively communicating the issues & answers of your model with your audience. As I said above, this is how we have "standardised" our use of the less well defined depency relationship for modelling at the business or logical level. At deeper design levels, where exact characterisation of the relationships are more important we find the generic dependency is typically not enough and they ar replaced with the more meaningful relationships.
hth
Bruce
