[Bluej-discuss] removing arrows: a proposition

[Jan Derriks]

Do you recognize this one:
"Sir, how can you say my UML model sucks if I BlueJ generated it!?"
(But Insert Your Favorite Reverse Engineering Tool for BlueJ if you like)

My 2 cents:
Most people agree that the model must be generated from the code.
*  I agree, but think that if model "editing" or fine-tuning is needed (like 
adding assoc arity) then this must be done by anotations or special 
BlueJ-comments in the java code to keep the source in sync with the model. * 
Model annotations could be used for:
- marking object variables as associations, with a given arity like 1..2 and 
direction (oneway/twoway)
- marking variables or method calls as "uses" relations.
* The default generated class model without the annotations will have NO 
assoc/uses relations, only inheritance and implements relations (since these 
are easier to extract from the source code correctly without the need for 
model-annotations). Attributes and methods in class diagram should follow 
UML syntax.
* The model should be exportable to a picture or printable and usable in 
documentation.
* Model annotations can be syntax-checked (eg. classname in an assoc 
annotation should exist)
* an option "no model features" will keep BlueJ as simple as ever (even 
simpler with the arrow buttons removed). The option can even be left out: no 
annotations in the code = no advanced model.

The advantage our students will have is:
1.  that the don't need to use VISIO, WordART or an UML tool to draw the 
models from their code like we ask them now
2. a change in the code can quickly be propagated into the corresponing 
model (doing that in wordart or Visio is a pain in the neck).
3. students learn that the model is THEIR responsibility to keep correct, 
not BlueJ's
4. the magically generated "uses" arrows is gone and has a "tag" in the 
code.
5. relation between code and model is more clear
6. finally the BlueJ models get some use and students can use it to show 
their model skills!
7. BlueJ can not be abused as a reverse-engineering UML tool since it only 
generates relations the author has put in (if the model sucks it's the 
student's fault, not BlueJ).

The disadvantages I think of are:
1. annotations or special comment syntax are an extra language to learn (but 
learning Visio-UML is just as bad)
2. BlueJ becomes an UML drawing tool? Lets keep it to class diags with 
implements, inheritance, uses, directed/undirected associations and 
multiplicity none, 1, *, n..m, rolename=attribute name, assoc name. No 
derived assocs, aggerations or compositions etc...
3. a lot of work for the BlueJ team to build it?

Greetings,
Jan