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

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

Hi Ed,

You're making the assumption that UMLX as-is forms the base of GMT. The list of features of GMT as per project description is much larger than what you currently have in UMLX - as far as I can see - and the list of envisaged GMT features will rather grow than shrink over time. At the highest level it makes sense to distinguish the components of GMT as:

 

Workflow

Plug-in architecture for our own components and "third party" MDA tool components using XMI-based workflow. This architecture should also allow our own "legacy" tools to be plugged in. The scope of this component is more than the sequencing of transformations.

Mapping

The mapping component includes the loading of the PIM and PDM, and the tools to specify texture mappings and launch the transformations specified by the model mappings. Some of that you currently cover in GME, but I would suspect major items are still missing. I'm not convinced that the graphical notation you've implemented is sufficient, we may also need more compact notations to supplement the graphical notation. 

Transformation

The transformation component is the engine that excecutes the transformations defined in the mapping component and churns out the resulting models.

Text Generation

Yes, text generation is a special form of model transformation. This component is responsible for the last step, converting a model into text files that will typically be traditional textual source code. In some cases you're right and this last step is just a simple "serialisation", in other cases you may want to use a template language engine to bridge a larger generation gap. Depending on the domain and the task at hand, the usage patterns of GMT will vary significantly.

Hence the directory high-level structure. From the package/directory structure you suggest, it is evident that your anticipated usage of GMT is quite different from Ghica's and mine. We certainly don't see any "java" or "sql" package at the core of GMT. The mapping to java for example will be dependent on the specific target environment (local application architecture standards, implementation technology standards, legacy context, etc.), and should be captured in a PDM and the texture mapping between PIM and PDM. Similarly the SQL DDL that needs to be generated depends on local O/R mapping standards/strategies, the chosen persistence framework etc. and needs to be defined in the form of PDM and texture mappings.

In order for us to better understand the scope and usefulness of UMLX, please post your code base at org.eclipe.gmt.umlx.... then we can hopefully start a meaningful discussion. Meanwhile I'd like to suggest that the standard implementation language should be JAVA, and XML technologies. Any other technologies such as C or C++ should only be used if absolutely necessary, such as for the integration of GME which does not yet have a Java interface.

 

The next step in our project is the prioritisation of features as per project ground rules. The result of the prioritisation will provide context for discussing the architecture, allowing us to focus on the important items. 

 

Regards,

Jorn