Re: [gmt-dev] UMLX pages and new UMLX paper

["Jorn Bettin" <jorn.bettin@xxxxxxxxxxxxxxxx>]

Hi Ed,

Further to my previous note, here are additional thoughts on the graphical
notation.

The reason why UML class diagrams are quite popular and practial is that
they have a good balance of graphical to textual syntax, i.e. the user can
choose the terse textual notation where appropriate, and the user
consciously chooses to use graphical notation where this is better suited to
indicate important links between model elements to human readers. In
particular "containment"  is often better modelled by simply drawing some
kind of a box around the contained elements, and not by focing the user to
have one box for each element and explicitly showing each containment
relationship as a link between boxes. Evidence of this approach is evident
througout in UML class diagrams:

(1) The class "box" aggregates various sections and types of information:
operations, attributes, abstraction indicator, stereotype, tagged values...
and I've possibly missed a few.
(2) Within the class box, the box containment technique is carried further.
The parameters of operation are contained by a "box" of brackets, which I
think is very elegant and clear syntax in this case, especially as the
brackets don't nest. Even if we don't count sections or sets as explict
levels, one class box in UML can capture three levels of containment: class,
operation, parameter.

Beyond the "one box contains three levels of containment" approach, UML uses
simple textual syntax to annotate contained elements with properties such as
visibility etc.

If UML class diagrams would not allow this type of syntax, hardly anyone
would bother drawing UML class diagrams. In fact UML interaction diagrams
use the same technique of optionally allowing the user to specify complete
operation signatures in compact textual syntax.

Check out http://www.cis.uab.edu/info/OOPSLA-DSVL2/Papers/Bettin.pdf (or the
white paper on the SoftMetaWare web site for the long version). The paper
shows that the naive use of UML modelling as it is typically performed in
most organisations, does not provide any speed advantage over manual coding.
On the contray, UML drawings beyond simple paper sketches can slow down a
fast-paced project, as people loose time by putting artistic effort in
arranging elements in UML  diagrams.

When developing a concrete syntax for model transformations we have to learn
from what works in practice. Ideally we can develop a concrete syntax that
provides intelligent/economical means to indicate simple containment along
the lines we see it in UML class diagrams. If, beyond that, we manage to
introduce a simple textual template language to transform contained elements
in the input model into contained elements in the output model, then I think
we arrive at a syntax appropriate for "industrial use".

A template language approach also means that we have to think about a useful
textual language for contained elements on the left-hand-side, because it
will not always be UML operations or attributes! This textual language has
to be quite simple, otherwise it only creates a new transformation problem
;-) Perhaps a comma delimited list with [possibly] nesting via brackets does
the trick? Ideally we would give users the choice to either use all elements
of the graphical syntax proposed by your current UMLX, or to resort to
textual notation for specific elements where the the graphical notation
amounts to overkill.

Thoughts?

In your practical experiments with UMLX, have you come across any issues
with the underlying abstract syntax? It looks complete to me, but I have not
verified it.

Regards,
Jorn

Jorn Bettin
jorn.bettin@xxxxxxxxxxxxxxxx
www.softmetaware.com
Tel  +64 9 372 3073 | Mobile +64 27 448 3507 | Fax +64 9 372 3534