[Bluej-discuss] Uses arrows in BlueJ class diagrams

[Charles Pecheur]

Let the wishing game begin...

I would strongly support this too.  I would expect that few people,  
if any, use the ability to manually modify the current dependency  
arrows.  BlueJ is not the tool of choice for charting UML class  
diagrams.  On the other hand, it is very useful, from both a  
pedagogical and practical standpoint, to have an abstraction of the  
syntactic structure of the program as graphical cues in the class  
diagram.

My suggestions, for what they're worth:

[1] All arrows are automatically generated and maintained in sync  
with the code.

[2] Use solid lines to indicate "usage", i.e. A --> B iff A has an  
instance variable of type B.

[3] Option: creating a new arrow adds the corresponding instance  
variable in the code.

[4] Option: use arity annotations (rather than multiple arrows) when  
several variables of the same type.

[5] Option: use '*' arity for array types, i.e. A -->* B iff A has an  
instance variable of type B[].

[6] Used dashed lines for other dependencies: method parameters and  
results, static variables, etc.  Option: show arities as for usage  
arrows.

[7] Make the display of dependencies optional.  If all dependencies  
are covered, the graph will quickly become quite crowded.  The option  
may be accessible in the preferences or as a toggle in the GUI.

[8] Option: distinguish between different kinds of dependencies  
(parameter vs. class variables vs. ...) and/or provide preferences to  
selectively display the different kinds.  But I'm afraid this is  
already versing into Eclipse-like featurism...

On the other hand, with all due respect, I would reconsider Michael's  
suggestion to use '*' arity for collections.   At the level of  
abstraction of the Java program, a variable of type List<B> in A  
would rather be shown as an arrow A --> List (and then ArrayList -->*  
Object per [5], if these were to be displayed).   Showing this as A -- 
 >* B is an attempt to reverse-engineer the abstract class design  
from the Java code, and seems impossible to do in a uniform general  
way (e.g. supporting custom collection types).   I would rather have  
a strong syntactic meaning in the arrows, hence suggestion [5],  
though the distinction between arrays and other kinds of collections  
is also somewhat arbitrary.

Best wishes to all, long live BlueJ,

	Charles

_________________________________________________________
Pr. Charles Pecheur  –  charles.pecheur (at) uclouvain.be
Université catholique de Louvain, Dept. INGI
place Sainte-Barbe 2, 1348 Louvain-La-Neuve, Belgium
Work : +32-10-47 87 79      Secr : +32-10-47 31 50
Cell : +32-478-51 52 94     Fax  : +32-10-45 03 45


On 19 Jan 2007, at 15:08, Axel Schmolitzky wrote:

> Hello BlueJers,
>
> one of the (very) few things I don't like about BlueJ is the  
> handling of
> the uses arrows in the class diagram of a project.
>
> It is possible in BlueJ to "declare" a uses relation between two  
> classes
> via the uses button. Such an arrow persists, even if there is no
> dependency in the source of the origin class of the connection. It is
> even possible to remove a connecting arrow, even though a source
> dependency exists. A "rebuild package" does not "repair" this. In
> essence this means that the uses arrows in BlueJ can become  
> meaningless
> quite easily.
>
> This is only a problem of the uses arrows. The inheritance arrows are
> automatically kept in sync with the source, in both directions (source
> to diagram and diagram to source), as there is always a unique direct
> mapping.
>
> I would prefer the diagram to be an exact representation of the  
> source,
> also with the uses arrows. This would only be possible if the uses
> button were removed, because for such an action in the diagram  
> there is
> no exact counterpart in the source that the BlueJ system could  
> introduce.
>
> The crucial question is: Is there any BlueJ user out there that would
> miss this functionality? I hope not.
>
> If the button were removed the uses arrows in the diagram could be
> enhanced: a distinction could be made between a simple dependency
> (current dashed line style) and a structural dependency (a solid  
> line).
> The former is used if the origin class declares a parameter or local
> variable of the target class while the latter is used if the origin
> class declares an instance variable of the target class. This is a
> little closer to the UML and would help teaching UML with BlueJ.
>
> I put this request here to see whether there is any chance for a  
> change
> like this.
>
> 	Axel
>
>
> -- 
>
> Dr. Axel Schmolitzky                           Fon: +49 40 42883 2302
> Universität Hamburg                            Fax: +49 40 42883 2303
> MIN-Fakultät, Dep. Informatik     Vogt-Kölln-Str. 30, D-22527 Hamburg
> -   Zentrum für Architektur und Gestaltung von IT-Systemen (AGIS)   -
> AB Softwaretechnik           http://swt-www.informatik.uni-hamburg.de
> _______________________________________________
> mailing list bluej-discuss at bluej.org
> To unsubscribe or change your preferences, go to
> http://lists.bluej.org/mailman/listinfo/bluej-discuss