[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [gmt-dev] The four compoents (was Initial CVS structure)
|
Hi Jorn
> You're making the assumption that UMLX as-is forms the base
> of GMT.
I assume a transformation-based philosophy. Apart from GReAT,
I'm not aware of any other graphical alternatives. GReAT is C++
and not self-compiling. UMLX is NiceXSL until it self-compiles.
UNLX certainly needs to grow. At present I'm concentrating on
a core syntax to which more sugary conveniences can be mapped.
> 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:
However if we are to avoid the mistakes of iUML we must make
our MDA activities accessible. Therefore we make everything a
transformation.
So I stand by my previous estimate:
I'm well on the way to getting the first 100 transforms that
constitute a UMLX compiler working.
Then we need
200 transforms to support optimisation.
200 transforms to support code generation.
>1000 transforms to do MDA transformations.
The MDA activities will involve transformations which should all
be written in an evolved UMLX, unless we want to start from scratch.
Until we can agree to refer to most of these four components as
transformation suites we have a lot more disccussion to go.
I think that we in broad agreement that we need to do mapping. The
difference is that I think you want to write Java code to do it.
I want to produce UMLX diagrams that specify what your Java code
must do, and since UMLX is executable, generate either Java or C or
whatever code direct from the UMLX diagrams.
> 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.
The UMLX core is currently an N-input XMI to 1-output XMI internally,
with a round-to-it restriction that only 1-input can be provided externally.
This will shortly change to N-input, M-output, with a facility to use a
custom serialiser for each output.
Therefore we need a load of adapters to
extract models as XMI from third party tools
activate the UMLX engine
return models back to the tool
where source models may include compilation options
return models may include error logs
I don't see that this merits the term workflow component.
Per-tool adapters are one-off. Thereafter everything is done
by throwing models at the UMLX engine, with the models explicitly
sequenced within the models, or implicitly sequenced by deduced
properties of the models.
The implicit deduction is a low priority suite 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.
The mapping engine can be UMLX. The mapping transformation suites
are a very major development activity that I haven't started.
> 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.
I didn't mean to imply that I did either.
I would expect to see 'code generation' transformations that
introduce an ObjectOriented or DataBase flavour to the PSM
and to follow these by more specific Java/C++/SQL/VHDL/...
transformations that actually produce the code.
> 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.
Indeed, at each level users should be able to select one of a variety
of different ObjectOriented styles or to replace or enhance
transformations to create custom styles. This selection should
occur automatically either in response to the PDM, or to
manually provided configuration in the 'Deployment/Mapping' Model.
> 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.
I'll put the doc files up tonight, and the NiceXSL by Monday.
> 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.
I agree whole heartedly, but envisage writing as little Java,
or C++ or whatever as possible.
I had to use C++ since that is what GME supports for add-ins.
That is a potentially finished development for XMI, and only
a minor ongoing activity for each new UMLX 'icon'.
We will similarly need to use the favoured language of other
third party tools to enhance them. So Java within Eclipse.
I temporarily use NiceXSL to program the UMLX bootstrap, until
I'm able to use UMLX itself.
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.
