[Bluej-discuss] Uses arrows in BlueJ class diagrams

[Charles Pecheur]

Hello again,

Michael, I basically agree with all your suggestions and remarks.

I think it is very desirable to avoid, as much as possible, opening  
the UML Pandora's box. The idea should be that the class diagram uses  
(a subset of) *UML* conventions to show *Java*, *syntax*-level (vs.  
*design*, *semantic*-level) structure. If that misses some of the  
underlying design logic, that's unfortunate, but I would rather have  
that with a crystal-clear meaning than a fancier interpretation which  
will inevitably be harder to interpret (not to mention explain or  
teach).

>   - 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.

This is, in my opinion, the main shortfall.  One way to provide this  
is to (optionally) display the ancestor chain of every class, with  
applicable association links, but that is another can of worms to  
open...  If not, so be it.  After all, the inheritance arrows to  
external classes don't appear either.

I am teaching the "uses" relation as part of my course, so I am  
really looking forward for this.

	Charles

On 22 Jan 2007, at 22:48, Michael Kölling wrote:

> 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
> _______________________________________________
> mailing list bluej-discuss at bluej.org
> To unsubscribe or change your preferences, go to
> http://lists.bluej.org/mailman/listinfo/bluej-discuss