[gmt-dev] evolving GMT in a fully open process that allows others to joi

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

Hi Ghica,

As we discussed I think it's now a good time to start to use the GMT mailing
list to start evolving GMT in a fully open process that allows others to
join the effort. Up to now we've been able to make good progress, but
without much external visibility ;-)

In particular I think Fuutje has the potential to play an important role
within GMT:

In order to get further people involved in the evolution of Fuutje, the
following steps are required:

STEP 1:
We need basic documentation of the Fuutje tool architecture so that I, Jeff,
and others can evolve the tool. Without further documentation we cannot
suggest appropriate ways to improve the implementation, and we can only
provide external specifications of desired GMT functionality (which we
already have done in the requirements specification).

STEP2:
Any changes/documentation required to make definition of a custom "tool
model" (meta-model) a standard activity, as meta modeling is a standard
activity in Model-Driven Software Development (MDSD).

STEP 3:
In real projects that I'm seeing in my pipeline we'll need to implement meta
models as in the example shown in the MDSD white paper (with Enterprise
Components and Business Components as explict model elements, and with a
structure that automatically enforces a number of architectural constraints.
Of course we could do this with Fuutje as it stands now, but I don't think
it would be elegant (the templates needed to generate the domain-specific
modeling tool would not look nice).

The default Fuutje "tool model" (i.e. the default meta model) needs to be as
simple as possible. As per discussion, some of the historic baggage can be
shed, and something along the lines of the model underlying MetaEdit will do
the trick. Terminology-wise, to prevent meta modellers (users who develop a
meta model) from unadvertently slipping into the solution space, the
following elements are required for meta modeling:

(a) CONCEPT - to represent the items being modelled
(b) RELATIONSHIP - to represent binary relationships between concepts
(c) ROLE - to represent the "Role" of one Concept in relation to another
Concept via a Relationship. Each Relationship needs to provide a Role for
the Concept at the "source" end of the Relationship and a Role for the
Concept at the "target" end of the Relationship.
(d) CONTAINER - a grouping mechanism for Concepts and Relationships (which
contain Role definitions)
(e) PROPERTY - All the elements (a) ... (d) may contain any number of
"atomic" Properties

These modelling elements are sufficient to for meta modelling, i.e. the
definition of domain-specific modelling languages. The nice thing about this
particular meta model [terminology] is that it does not overlap with the
terminology found in OO implementation languages, so when template languages
are used to navigate the meta model for the purposes of transformation, the
template code/text will be relatively easy to read - at least much easier
than when you have "classes", "attributes", and "operations" in both the
meta model and in the target langugage of the transformation.

How do we get there? We simply use Fuutje as it stands now to generate a
tool conforming to the specs above. With potentially a bit of refactoring in
the architecture, the result should be a tool with a meta model stripped of
all baggage, and with a simple component for visual meta modelling. If we do
it properly, the tool will provide a combination of features that is not
available in similar elegance & simplicity in any other tool that I'm aware
of.

STEP 4:
Minor point. Perhaps we need to change the name of Fuutje at some point,
because the "Java" part of it is misleading and may lead poeple to think
it's not suitable to generate other text output.

Jorn

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