[Bluej-discuss] Uses arrows in BlueJ class diagrams

[Michael Kölling]

On 22 Jan 2007, at 18:24, Axel Schmolitzky wrote:
>
> I just imagine the class diagram in chapter 3 of OF, in Figure 3.3
> (ClockDisplay and NumberDisplay), as an example; it would look great
> with a star (which would be different from option 4 by Charles, but
> simpler).

Well, this is exactly where the problem starts. I am always a little  
reluctant, since experience has taught me that the devil is always in  
the detail. For example here:

If we follow Michael's approach and annotate essentially collections  
with the *, then this case would not get the star.

In the example you mention, a ClockDisplay has two NumberDisplays.  
But they are not held in a collection, but in two separate instance  
fields. This would NOT get a star. (Or would it?)

It gets dodgy here quite quickly. A Line with two Points as its end  
points - multiplicity? Suddenly the view of the model shown depends  
on implementation detail: stored in an array of size two - it has a  
star. Stored in two fields - no star. I can already hear people  
complaining.

The other thing that always happens is that when you start doing  
things that look like something (UML in this case) people always want  
more. I am certain that we will have the discussions "why the start,  
and no other multiplicity (a 2, for example)?". And the diamonds on  
the arrow starts...

Other details:

  - if we show the * for subclasses of Collections, then arrays would  
not be included. If we make it subtypes of Iterable, then Strings are  
included. Etc...

  - Arrows to other packages are now shown. So, if I have a field of  
a library class type, no arrow. If I have a subclass of that type in  
my project and instantiate it in my client code, it would only get a  
"simple" uses arrow, even though the object is stored in an instance  
field.

  - What if I have two fields of the same class? Only one aggregation  
arrow, I assume.

  - Removing an aggregation arrow then must remove all fields.  
Inserting the arrow again would only re-introduce one field.

  - What if I have a field of a class and a parameter? Do I get both  
types of arrow? Or just one?

The most important thing is that we do not get into terrain where  
semantics are suggested (as Paul has already pointed out). The UML  
aggregation/association distinction is semantic, and cannot be  
automatically inferred. We cannot distinguish those. And I am a  
little worried that some UML enthusiasts will scream as soon as we  
start distinguishing the arrows.

We need to come up with something that is entirely defined  
mechanically by source code (without semantic interpretation) and  
does not contradict UML. (But may be "simplified" UML -- UML  
explicitly allows that.)

Michael