RE: [gmt-dev] The four compoents (was Initial CVS structure)

["Willink, Ed" <Ed.Willink@xxxxxxxxxxxxxxx>]

Hi Jorn

> From: Jorn Bettin [mailto:jorn.bettin@xxxxxxxxxxxxxxxx]
> The directory structure should be

> org.eclipse.gmt.workflow

> org.eclipse.gmt.mapping

> org.eclipse.gmt.transformation

> org.eclipse.gmt.textgeneration

I wondered why you hadn't incorporated my comments into
the home page.

We clearly have an understanding gap.

The first three components are all fundamental to UMLX
working at all. It's as if you're distinguishing function
declaration, function invocation and parameter passing as
different aspects of a programming language.

Workflow
--------

To me, workflow is the sequencing of transformations.
It may occur in three ways.

a) explicit sequencing through use of causal information flow
between transforms connected in a hierarchy of UMLX diagrams.

b) explicit parallelism through use of parallel information
flow between transforms connected in a hierarchy of UMLX diagrams.

c) implicit sequencing as a result of schema analysis to deduce a
transformation sequence from the specification in the PIM to a
PSM that exploits the resources in the PDM.

Pethaps c) is what you mean, but I see it as just one of many
advanced UMLX optimisation activities.

a) and b) are part of UMLX.

Mapping
-------

The ability to do mapping is fundamental to UMLX. It is not
possible to perform interesting transformations without reacting
to two or more inputs, which inevitably means a mapping between
them. UMLX does mapping already.

Mapping as part of an MDA tool, is one of the many different
transformation phases between DSVL and code. I would therefore
suggest that mapping sits as part of

org.eclipse.gmt.transforms.mapping
org.eclipse.gmt.transforms.types
org.eclipse.gmt.transforms.scheduling
org.eclipse.gmt.transforms.communication
org.eclipse.gmt.transforms.partitioning
...

Transformation
--------------

Everything is a transformation. The compiler provides the
ability to do transformations (model to model)
mappings (models to model) text generation (model to text).

The transforms library provides the wide variety of facilities
that will be necessary to transform DSVLs into PIMs and other
DSVLs into PDMs and then map them to produce a PSM and then
to produce code.

Text generation
---------------

Text is just a particular view of a model. I could draw a UML
diagram of a text document - at its most trivial a list of
characters. more interestingly a list of words which are lists
of characters. ... paragraphs, indentation, prefix/suffix wrapping.

This is what my text thread was about. If we have an appropriate
text model, then text generation is a model transformation, with
a trivial serialisation to finish off, and whren we come to do
XMI generation in C we won't have library support so this approach
supports creation of XML in a text model that is easily output
in any language.

If a text model is defined, then the UMLX support is simple, and
code generation is supported by 

org.eclipse.gmt.transforms.generation.java
org.eclipse.gmt.transforms.generation.cxx

> To assess the capabilities of your code and to determine the 
> appropriate
> location, can you please provide us with an overview of the 
> design of the
> tool, say in the form of some UML package diagrams that show us what
> subsystems you've got, what is exposed on the subsystem 
> interfaces, and what
> the dependencies between subsystems are.

Until I put my code in to CVS, I guess it is difficult for you
to grasp quite how small it is.

In order to get GME to export XMI, there is an XmiEmitter
add-in, that creates the XMI model understood by the NormalizeXxx
transformations. This code is GME-specific but otherwise dependent 
only on the XMI standard. It should really
become part of GME itself.

In order to get GME to support UMLX editing, there is a
Umlx.xmp paradigm, which uses a UmlxDecorator add-in to draw
icons appropriately. This code is GME-specific but otherwise
dependent only on the UMLX language definition.

Everything else is transformations, An overview of the subsystems
just makes it into the paper for Twente, which subject to comments,
I plan to put at gmt-home/doc/uml/UmlxGraphiclaLanguage.pdf.

The UMLX compiler is defined by transformations which execute at two
levels. At M2 where transformations are compiled and at M1 where the
compiled transformations are executed to compile user models.

For M2 the UmlxCompilation system compises the 4 transformation
sub-systems, AnnotateSchema, AnnotateTransform, GenerateScan,
CreateBuild.

For M1 the UmlxExecution system comprises the 3 transformation
sub-systems, AnnotateUsage, Scan, Build

In order to interface with GME there are a further 3 transformation
sub-systems for M2, NormalizeSchema, NormalizeTransform, NormalizeUsage,
which normalize the XMI of the arcs-and-nodes
corresponding to visible graphics as edited within GME, to the
XMI of the arcs-and-nodes corresponding to information concepts
as defined by UMLX.

The dependencies between transformations are established by the
schema that define each interface. Additionally in the NiceXSL
implementation there are utility functions that are shared. 

Most of the transforms from most of the GME-independent sub-systems
are shown in the UmlxToXslModels that I sent you and, subject to
comments, will put up as org/eclipse/gmt/doc/umlx/UmlxCompiler.doc.

Each sub-system when coded in NiceXSL is a single file varying in
size from 100 to 2000 lines.

Hence my suggestion of three areas, one for each isolated add-in,
and one for the UMLX compiler that in bootsrrap form is small enough
to be flat.

	tools/gme/XmiEmitter
	tools/gme/UmlxDecorator
	umlx/...

In compiled form, we will have to decide whether there is a genuine
boundary between UMLX-compiler-only transforms, shared code generation
and optimisation and non-compiler transforms. If I
choose to build a UMLX compiler for a GRID, I suspect I use
nearly everything, so that we will end up with

org.eclipse.gmt.transforms.mapping
org.eclipse.gmt.transforms.types
org.eclipse.gmt.transforms.scheduling
org.eclipse.gmt.transforms.communication
org.eclipse.gmt.transforms.partitioning
org.eclipse.gmt.transforms.qvt.compilation
org.eclipse.gmt.transforms.qvt.optimisation
org.eclipse.gmt.transforms.generation.java
org.eclipse.gmt.transforms.generation.sql
org.eclipse.gmt.transforms.optimisation.expressions
org.eclipse.gmt.transforms.optimisation.types

	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
------------------------------------------------------------------------
(formerly Racal Research and Thomson-CSF)

As the originator, I grant the addressee permission to divulge
this email and any files transmitted with it to relevant third parties.