Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [gmt-dev] gmt-home/description.html

Hi Ed and all,
To me it was immediately clear that the diagram is an informal use-case
diagram. Maybe Jorn can add a stick-puppet to make that more obvious. True
UML therefore.

To my opinion we should never talk about transform providers and transform
users, we could more formally introduce GMT-tool users, GMT-tool
configuration implementers, and GMT-tool users.

As far as I know, you have a different definition of what a texture is than
we have. As long as that is the case, you will remain baffled. In any case,
it is not an information model. Something should change: We could introduce
your concept of texture in the tool (and call it something else). Please
provide a clear description of your concept, intended for dumbos like me.
Maybe you could try to understand again what we mean by texture.

My conclusion is that the diagram is just fine as it is. Of course there are
details possible in the form of class-diagrams or state diagrams, or maybe
even activity diagrams, that will come at a later stage.

>>I see the mapping information as associations of instantiations. So I
>>associate some properties of the PIM with some properties of a PDM. Each
>>these may be substantial hierarchical models in their own right...
I agree to this. The rest of the paragraph is vague to me, because I am only
unconsciously a user of TCP/IP communication.

2) What is your point here?

3) Workflow.
All I know, is that to GMT users the tool looks like a workflow tool. It
will be configured to fit the particular development environment of the user
(e.g. application developers). We should adhere as much as possible to
workflow standards that are out there, presumably WfMC. We should look into
that soon.

To me, UMLX is a node in the workflow. I do not think it is mature enough to
serve as the tool to implement the workflow with yet. We need at least some
graphical tools that can define the workflow processes for a particular

Textures: see above.

Pattern: This is an unsolvable problem. I have been in big trouble once,
because my opponent with better managerial influence, failed to understand
that "view" as in database-view is something different than "view" as in
MVC. Do a proposal for an alternative! I do not understand what a pattern
solution is, do you mean "solution pattern"? that would be ok .

Ghica van Emde Boas Software & Services b.v.
e-mail: emdeboas@xxxxxxxxxxxx,
tel: +31 23 5474422,
or: +31 6 53368747 (mobile)
fax: +31 23 5473347

-----Original Message-----
From: gmt-dev-admin@xxxxxxxxxxx [mailto:gmt-dev-admin@xxxxxxxxxxx]On
Behalf Of Willink, Ed
Sent: 12 June 2003 10:21
To: Gmt-Dev (E-mail)
Subject: [gmt-dev] gmt-home/description.html

Hi All

Jorn, Ghica: I think this discussion should be on-list.

I'm unhappy with our top-level detailed description.

1) Stylistic

This may appear trivial, but actually I feel it's very important.

The diagrams are hard to understand beyond a very superficial level

The diagrams are in an informal notation for which only clues as to meaning
are provided. It was a while before I noticed that the diagram showed
order, although I'm not certain that that is true. More normally IMVHO data
is in
square boxes and processes are in rounded boxes, so we start on the wrong
It would be much better if they were drawn in UML, probably as activity
where careful page positioning can indicate time, and swim lanes can
activity phases.

A major problem is the failure to distinguish the activities of the
provider and the transform consumer. While we certainly want to be able to
users who consume their own provisions, it is essential to keep apart the
meta-programming phase (transform provision) from the compilation phase
(transform consumption). We should hope that a substantial library of
(and proprietary transforms would become available.

I'm baffled by the Texture Mapping ellipse. It presumably is an information
model, but as such it can take no action so I'm not sure where the mapping
comnponent that you try to keep distinct is. Figure 2 is easier to argue
here. The concepts we must deal with are:

Input models (and their meta-models) which may be PIMs and PDMs.
Ontput model(s) (and their meta-models) which may be PSMs.
Information to control the mapping process
Specification of algorithms to implement the mapping
An engine that executes the algorithms

We are in agreement about input and output models, although I would
to M inputs and N outputs. Though note that a PDM is Description, so it
information about the platform, it does not contain compilation algorithms,
although it may contain command lines or compilation options and locations
of appropriate tools or libraries.

You fail to clearly apportion the three mapping concepts into the two icons;

a texture mapping ellipse and a multi-stage transformation box.

I think that we are seeking to meta-model everything, so that the
to control the mapping process is an instance of a mapping/deployment
The specification of algorithms is an instance of a programming meta-model.
So our information in the PIM + PDM to PSM case comprises
	PIM model + meta-model
	PDM model + meta-model
	PSM model + meta-model
	Mapping model + meta-model
	Transformation model(program) + meta-model
The first four are information only and so represent input/output of an
engine. The latter is a program that probably needs compilation in order to
efficiently executed by the information engine.

I would therefore like to draw Figure 2 with three inputs (A, B, C or
Mapping) and
their meta-models, feeding a transformation engine which has a side input
a transformation(s) ellipse and its meta-model.

We combine Figure 3 and Figure 4, deleting the central Texture Mapping
(move it up as a third input if you like). The dependencies are simple; the
programming meta-model depends on all the input and output meta-models. If
use a UML-based programming language then these dependencies represent
If we do this at the meta-levrl as in UMLX, the input and output schema
the data declarations, that just need to be related by a hierachy of
evolution, presevation and removal operations.

I see the mapping information as associations of instantiations. So I
associate some properties of the PIM with some properties of a PDM. Each of
these may be substantial hierarchical models in their own right, for
if I allocate a communication path in the PIM to a TCP/IP communcation link,
the PDM will provide support for that link. Or more realistically my mapping
directive causes TCP/IP elements rather than X25 elements to be pulled in.
I make no distinction as to whether what is pulled in is a very thin wrapper
pre-packaged IP, or a deep detailed model that supports synthesis of the
stack. In this latter case we find that there is a substantial grey area in
activation of a PDM resource may activate a PIM that realises it at one
layer of
abstraction allowing a further mapping to select which particular Ethernet
is required at another layer.

2) Components

The document describes mapping components, transformation components and
text generation components.

My experience with UMLX, is that nearly all (56 out of 68 drawn so far)
ard multi-input. This is because there is either a need to merge external
inputs, or
internal inputs. For instance consider a compression transformation. Pass 1
may analyse
the data to be compressed to produce a compression model that can then be
applied to
the data, so pass 2 is multi-input. This happens everywhere that things get
so multi-input is fundamental to transformations. There is therefore no
distinction between an engine that transforms one input and one that
transforms multiple,
and an engine that transforms multiple inputs is also a mapping engine.

The mapping component is therefore supported by a multi-input transformation

Real mappings require real work to define suitable PIM, PDM, PSM and mapping
and the transformations that operate upon them.

We previously agreed that the text generation component is arguably just a
choice of
output serialisation policies on a more general transformation engine. In
this case
the activity is to design and implement a driver. There is no distinct
component and
no need for special integration.

3) Workflow

There are three kinds of transformation that we may seek to apply.

Foreign transformations implemented by some random third party tool, that
well require input and output adapters and invocation in a separate process.
A compiler would be an example of this. We would need to produce specially
formatted input, and provide a custom translator to re-acquire its symbol
table output for further processing.

External transformations may be more accessible, probably because they are
in Java and so may be amenable to direct passing of DOM or equivalent models
within the
same process, rather than separate XMI files.

Internal transformations are more interesting. We have a meta-level
specification of their
behaviour so that we may seek to optimise the way in which multiple
are invoked and synthesize more effecient composite transformations. UMLX ,
pending QVT,
is probably a good way in which to handle internal transformations.

Few interesting transformations are single pass, so it is necessary to be
able to
create appropriate sequential or parallel combinations of transformations.
compiler has at least five major passes at different meta-levels, with a
number of
sub-passes internally. Sequencing transformations is therefore a fundamental
of a transformation engine that supports hierarchical composition. One level
hierarchy defines the composition of its children. A useful meta-model of
transformations must define a meaningful semantics of hierarchy and
transform composition.

I have previously pointed out that top-level sequencing of available
transformation suites
can be automated by path analysis through the meta-models from what the PIM
requires to
what the PDM offers.

So we have just a transformation component that does mapping inherently as a
of multiple inputs, workflow as a by-product of hierarchy and text
with the aid of an output driver.

We therefore need to develop 'just'
	- the transformation compiler (for each transformation language)
	- the transformation engine
	- text output driver(s)
	- standard interface(s) to external transformations
	- custom interfaces to foreign transformations (low priority)
	- one set of logging facilities.
	- one set of debugging fafacilities.
to satisfy our XMI to XMI role, but also
	- transformation language GUI
	- debugging/logging GUI
to make the tool usable and
	- MDA schema library
	- MDA transformation library
to support MDA.


We must be very clear about the distinction between texture (classes) and
instances. A transformation defines texture (classes) whose instances in
input model(s)
activate the transformation. This error occurs in the first paragraph, which
with a non-sequitur about texture mappings. It is certainly not appropriate
to speak of
such things without any further clarification. I'm unclear whrether you wish
term to mean the activation of a special program, while I mean the mapping
which drives a standard transformation engine.

The requirement for a texture to feature in a single input model is
If I'm correlating two inputs, I may look for textures A and B in document 1
and texture C and D in document 2, and when these share some relationship I
A, B, C, D therefore form part of a compound texture over multiple inputs.
>From a
different perspective, if I break a given texture up into sub-textures, I
will find
that the sub-textures acquire multiple inputs.

Single input is an, I think accidental, property of GReAT, which I believe
Adi thought could
be removed. Single input was an early design simplification for UMLX,
particularly given
the natural single input behaviour of XSLT. However, I rapidly discovered
the power of
and need for multiple inputs and using the document() capability of XSLT, I
have multiple
inputs working at minimal extra complexity.

Multiple outputs is less essential, since multiple single output
transformations can
always produce multiple outputs, however this may involve mass rework, so it
pretty silly not to allow multiple outputs too.


There are some people in the pattern community who feel very strongly about
a pattern
establishing a context in which many different solutions are available. We
therefore try to avoid using the term pattern loosely, and certainly avoid
usage such as the title of figure 2 which is most certainly not a pattern at
When we must use the term pattern, we should probably say pattern solution.


		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
(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.
gmt-dev mailing list

This message has been scanned for viruses and dangerous content by MoveNext
MailScanner, and is believed to be clean.

Back to the top