[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [gmt-dev] UMLX pages and new UMLX paper
|
Hi Jorn
Verbosity
---------
I mostly agree with you.
Temporary
---------
At the moment I'm trying to keep the syntax small, while I get a core
implemented. I find it very distracting adding support for premature
syntactic sugar.
In due course it should be possible to make some savings. In particular
if GME was more open about its decoration ability it would be possible to
do clever boxes within or on top of boxes. I'm limited to boxes with
intelligent text content for now.
One that struck me this morning is transformation overloading. At the
moment invocation of a family of polymorphic transforms requires them
to be named distinctly and invoked from a dispatcher that enumerates
all known names.
It is of course perfectly reasonable to allow same-signature transforms to
be
chosen by unambiguous LHS match. This should save at least one transform in
the example, and open the way to extensibility. (Signature is transformation
name and port names, which may be annotated as optional/defaulted).
Text
----
Obviously there should be a parallel text concrete syntax, so that for
any transformation the user can choose the most pragmatic syntax, and
possibly even alternate between rival syntaxes.
There is definitely a need for better treatment of text within the graphics,
in the example for name building, more generally for code generation
'templates'.
I'm waiting for inspiration. What's in the example is adequate, but poor
from
the point of view of reversibility.
Precision and Scalability
-------------------------
I think much of the verbosity is necessary,
I reread
> http://www.isis.vanderbilt.edu/OOPSLA2K1/Papers/Bettin.pdf
and this time managed to understand the more important second half.
My previous problems were from failing to spot the "I" in front of
some of the RHS class names. It therefore appeared that there were
multiple relatively arbitrary productions. The lack of description
makes life very hard for the reader.
I considered doing your example in UMLX and realised that it would
be (really) verbose, but mainly through precision and re-use.
Your diagram is an instruction to an intelligent Java programmer who
knows what it means to create a 'set<Xxx>' method for the attribute
Xxx. Unfortunately tools lack this intuition so the gory details of
parameter/return types etc must all be spelled out.
I would therefore be inclined to create a whole hierarchy of
transforms
CreateGetSetMethod
CreateSetMethod
CreateSetSignature
since these would then be re-usable in a variety of contexts.
At the top level I would do 5 evolutions, and invoke
5 nested transformations one to populate each of the 5 RHS's.
These nested transformations could make some re-use of
CreateGetSetMethod etc. This could be flattened a bit but a
diagram that has a transformation invocation to name the conversion
policy for each of your wiggly lines is going to be cluttered,
unless there is a special shorthand for 1:1 transformations
comprising a named wiggly-line. Even your diagram is cluttered
having to pack 2/5 RHS's on the LHS.
Another issue on precision arises from multiplicity. UMLX has
the formalisable definition of the LHS matches as each distinct
set of node identities for which all constraints are fully and
maximally satisfied. When multiple sub-textures appear in a single
diagram this means that there is an AND operation between the
sub-textures. Provided they are orthogonal this does not matter.
However as soon as there is an interaction between sub-textures
we are into the intuitive world of using "all" or "any" in the
way that is most convenient. This gets particularly nasty in
the presence of negation.
Your Fig 5 example, has a top-level texture creating 5 classes
from 1, and a host of sub-textures applying to "all" attributes
etc. For Fig 5, this is ok, but I think once you consider Fig 7
you get into trouble.
I find that it is best to put sub-textures in nested transformations
so that their multiplicity constraints do not interact with their
parent unless explicitly required.
> the syntax works, it's just quite verbose. If you use a model
> based template
> language you can write that particular example in perhaps 15 lines of
> template code... and the result is directly in the concrete
> syntax of the
> target language. So with my practicioner hat on, the UMLX
>
15 lines! Well, I think you just put your head on the block.
The UMLX solution was significantly simpler until I started dealing
with some of the nastier corners. My suspicion is that template
languages are fine for an A to B translation, pareticularly when a lot of
implicit knwloedge of B is built-in to the language, but get in to trouble
as soon as we move from B to C and require an influence from D.
But I would be delighted to see a compact example. It might give me
the inspiration that I'm looking for on the text side.
> 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.
I find I can do most things that I need, though I'm still discovering
new idioms. The inadequacies of the schematic editor slow me down,
so I alternate between coding in UMLX and coding in NiceXSL.
There are two areas that don't seem to model well at present.
We decided to do XMI to XMI, so the niceties of XMI policy are
rather built in to the output sertialiser, so they don't model well,
and the trivial XMI interface passes do not seem to want to be drawn
in UMLX. I think the solution is to work XML to XML, then XMI might
be modellable properly.
I have drawn UMLX for compiler and execution engine. The compiler
transforms are sensible. The execution engine transforms have an
unmodelled secret - how nodes are located. I envisage a pool of
all objects so that references can be resolved, by dictionary in
Java, by pointer in C. If I model this in the execution engine
transforms I get into a silly loop whereby the pool is located within
the pool. I think this is because the execution engine transforms define
what the generated code does, not how it does it. The pool is indeed
a code generation policy secret.
There are areas in need of further thought...
MultiObjects are necessary to handle a group of objects at once.
However there can be some interesting interactions if some
intuitively sensible realtionships are drawn. I think that any
non-unity multiplicity must apply at the boundary of a clean sub-graph
otherwise there is a confusion of constraint paths.
Exceptions and Error reporting are still TBD. I sorted out
overloading above. I thought I was beginning to know what inheritance
means - but overloading seems to nullify my current thoughts.
I'm unclear as to how to distinuish the situation where a
transformation fails intentionally because a type match fails,
or accidentally through a coding error. Any local solution is
potentially invalidated by an outer usage that genuinely wants to
probe.
Regards
Ed Willink
------------------------------------------------------------------------
E.D.Willink, Email: mailto:EdWillink@xxxxxxx
Thales Research and Technology (UK) Ltd, Tel: +44 118 923 8278 (direct)
Worton Drive, or +44 118 986 8601 (ext 8278)
Worton Grange Business Park, Fax: +44 118 923 8399
Reading, RG2 0SB
ENGLAND http://www.computing.surrey.ac.uk/personal/pg/E.Willink
------------------------------------------------------------------------
