[Bluej-discuss] the "uses" arrow

[Axel Schmolitzky]

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

I must partly apologize for my enthusiasm yesterday, as it made me write 
my answer a little too fast. I wrote that a star would look nice in the 
class diagram of the clock display; actually a star would be wrong. In 
that diagram an arity of 2 would be correct, as a ClockDisplay holds 
exactly two references to instances of NumberDisplay.

I now tend to favor the simplest approach, i. e. without multiplicities. 
But I still think that it would be very useful if the diagram showed the 
difference between a directed association (solid line, open arrow head) 
for instance variables and a mere dependency (dashed line, open arrow 
head) for the other cases. I would not include any further 
differentiation between associations. I agree with a previous posting 
that any more means entering a mine field.
> 
> 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 :-)

As BlueJ doesn't show nested classes (which I think is a good design 
decision), the diagram should also not show dependencies of instance 
variables of nested classes.

>    o Apart from specialization/generalization, there are
>      two standard relations between classes: association
>      and aggregation/decomposition. The latter defines a
>      hierarchical relation between classes, the aggregate
>      class (whole) and the component class (part).  In UML
>      these relations are termed aggregation and composition
>      with the latter being the strongest (if I remember
>      correctly).  Filled and unfilled diamond. Association,
>      on the other hand, is a dynamic relation between equal
>      classes (no hierarchy).

According to Fowler's "UML Destilled, 3rd Ed." there are two relations 
beside specialization/generalization, namely association and dependency.
- Associations are always shown with solid lines and have a multitude of 
options: no/one/both ends with arrow head, heads that mean aggregation 
(empty) or composition (filled), arities, role names, even association 
classes. And they can just be used to depict a structural directed 
relation, i.e. a field of an object type.
- Dependencies are shown with dashed lines and are always directed. They 
are often used to illustrate transient relationships (parameter, local 
variable, etc.).

>    o The naming issue could be solved by asking the user to
>      supply a name (dialog box).  The name supplied buy the
>      user can be used as identifier for a new private field
>      variable. In principle, the name could also be used as
>      role descriptor on the arrow in the diagram, but that
>      is probably not a good idea.  At least it should be
>      possible to switch this on and off as with the arity/
>      multiplicity option.

The dialog and making the field private by default sounds good to me.

I would also stick with just one arrow between two classes (if the 
relation is not cyclic). As long as there are just dependencies (no 
fields) it is dashed; with at least one field it gets solid.

Michael also asked what to do in case an arrow is removed. As one arrow 
can be there for several reasons, there is no easy answer. The 
implication for me is: Don't allow arrow removal. I guess nobody would 
miss it.

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

That is ok, as that reflects the static structure. That the reference is 
stored in a field is a dynamic property not to be shown in a class 
diagram (as that can easily change at runtime).

Is all this consistent now? I hope so.

Cheers,
	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