[Bluej-discuss] the "uses" arrow

[Paul McCard]

We need to be careful that, while the BlueJ class diagram may not be a 
fully-featured UML diagram, it does not start to infer semantics which 
are not explicit in the code.  The "dependency" (dotted line, open 
arrowhead) relation currently represented is correct but very unspecific 
- i.e. many of these dependencies are more speicifically associations 
(solid line, open arrowhead) because they have an instance variable at 
the source end.  This could be automatically distinguished from other 
forms of dependency (static, local, parameter etc. as Stephen says). 

However, the refinements of association into aggregation (solid line, 
white diamond at target end) or composition (solid line, black diamond 
at target end) cannot be automatically determined because to do so 
demands not just syntactic analysis but a semantic understanding of the 
relationship.  (Indeed, OO designers often dispute the applications of 
these refinements).  However, even if something is arguably an 
aggregation or composition it is not incorrect to show it as a simple 
association, merely less specific.  There is a hierarchy of "strength" 
of relationship from dependency through simple association and 
aggregation to composition.

It's fine for the BlueJ class diagram to omit detail we might include in 
a hand-crafted diagram, since UML specifically allows this flexibility 
to "supress", but we must be very careful that we do not inadvertantly 
make it at odds with correct UML.  In particular (and here I'm at odds 
with Stephen) an instance variable does not automatically imply a 
composition (solid diamond).

It's a minefield!

Paul.

Stephen Bloch wrote:

>I agree with the posts thus far: I have had no use for the "uses" 
>arrow as it currently exists.  To make it useful, several things 
>should be done (in priority order):
>
>1) make it accurately and automagically reflect the code, as the 
>"extends/implements" arrow does (which probably means getting rid of 
>the "insert 'uses' arrow" button);
>
>2) allow it to be shown or hidden, independently of the 
>"extends/implements" arrow (already done);
>
>3) distinguish between "X has an instance variable of type Y", and "X 
>mentions Y, either as a static reference or as the type of a 
>parameter or local variable" (these, too, should be independently
>shown/hidden);
>
>4) use more standard UML notation, e.g. the "solid lollipop" for the 
>former and (IIRC) an "open arrow" for the latter.
>
>In re (3), there are some non-obvious cases.  What about an instance
>variable in an inner class?  What if the inner class is static?  But I'm
>sure the programming-languages geeks can resolve these :-)
>
>  
>