[Bluej-discuss] Uses arrows in BlueJ class diagrams

[Michael Kölling]

Thanks for everyone's comments regarding BlueJ uses arrows.

I largely agree.

We were aware for a while that the handling of the 'uses' arrows is a  
bit of a mess, but we haven't looked into this for some time, largely  
because nobody complained. Can't use that excuse anymore now, I guess...

There are several separate issues here, all with several options for  
treatment.

1. "fake uses relationships"

This is Axel's first point: you can graphically declare a "uses"  
relationship (draw an arrow) that is not in the source. That arrow  
sticks. (This was originally done to enable drawing of diagrams.)

We could change this so that the diagram always reflects the source  
code. As Axel correctly says, we would then have to remove the "New  
Uses Arrow" functionality (button and menu item). Because drawing a  
use arrow would be meaningless, and it would immediately be erased  
again.

We would then be left with just the "Draw inheritance" button. Would  
we want to keep this then? Just one lonely draw button? Why can you  
draw one sort of arrow, and not another?

Or should this go as well? I am not sure. This is one of the most  
annoying details in all this.


2. Distinguishing kinds of "uses"

Axel proposes to distinguish two kinds of dependency: "simple" and  
"structural" (where structural indicates use in an instance field,  
and simple everything else). One arrow is solid, one is dashed. (I am  
not sure how UML-compatible this is. I'd have to look this up. Or  
maybe someone here knows?)

In my personal teaching, I don't talk much about the diagram. I  
always liked the diagram to be very simple, so that I do not need to  
talk about it. But maybe people who like this distinction are in the  
majority. This should be possible. One drawback I see is puzzled  
students who start to wonder why the arrows are different.

But it seems that the benefits might outweigh the drawbacks.

(One of the drawbacks of any interface change like this is always  
that a lot of documentation -- screenshots in books, etc. -- needs to  
be changed. It's a lot of work...)


3. Michael's suggestion of multiplicity. Arrows should indicate a  
collection attribute. I can see how this can be helpful for everyone  
who teachers with a model focus, and probably also in other contexts.  
I am not sure yet about the bafflement/benefit ratio.


Okay, now to a possible solution:

If 1 and 2 were combined, we can almost reintroduce the second "draw  
arrow" button. We would have three kinds of relationship:

  - inheritance
  - aggregation (a.k.a. structural dependency) -- a solid line
  - association ("simple dependency") -- a dashed line

We could keep the "draw inheritance" arrow and also have a "draw  
aggregation" arrow. If the aggregation is drawn, it would insert a  
field declaration into the source code. (I am not sure whether this  
is a good idea. It is tricky: where exactly do you place it? What  
should the field be called?)

Association arrows cannot be drawn and are inferred. (Currently  
arrows are only updated when a source file is saved. This is why they  
can get out-of-date if manually removed. They should also be updated  
on 'compile').

Alternatively, if we do not want to draw aggregations, I am really  
not sure whether we want to keep the inheritance arrow button.


The multiplicity option could be an option: it could selectively be  
switched on and off via a preference setting.

How's that?

Michael