RE: [gmt-dev] Outsider View

["Ghica van Emde Boas" <emdeboas@xxxxxxxxxxxx>]

Hi Philipp,
As one of the core contributers to GMT, I would like to add my 2c.

> If my comments are inappropriate, please just forget about  them.
They are very appropriate.

> The main-problem with the GMT project is the gap between
> the goal, which is interesting for everyone working with models
> in the Eclipse area, and the missing common plan.
I can understand your impatience. This is an open source project, and we are
not funded like some of the other Eclipse projects. Therefore this depends
on the scarce time we have available during evening hours. The best way to
speed things up is to start helping us!

Because GMT is intended as a tool set, not as a tool, we are depending on
others to make their tools available. So far Fuut-je is there, and a QVT
implementation (ATL) will be there.

> If someone knowing Eclipse, and the huge success of frameworks
> like EMF, XSD, UML2, GEF, just the title "Generative Model Transformer"
> seems to make clear, what GMT is doing: a generative way of specifying
> transformations between Models. How to define models seems to be
> clear in a number of projects: using MOF (or in the Eclipse context the
> implementation of essential MOF done by the EMF project). As well
> in Model Driven Architectures, it seems to be clear, that you use MOF
> to define Models.
I am not so sure I agree with this. What is the relationship of XSD (an XML
Schema tool) or GEF (a drawing framework) with MOF?
In all projects I have worked on, we used UML to define models (or some of
the older methods), not MOF. In the last years there has emerged a standard
to exchange models: XMI. You can consider XMI to be based on MOF, but that
is not of interest to Joe Developer using this.

> How to plug existing transformation tools into GMT seems to be clear as
> well, write a plug in, that reads models and writes models. All models are
> in MOF (EMF), and all tools naturally collaborate. A free competition.
This is not compliant with the standard that is being defined by the OMG:
QVT.
What does all models are in MOF mean? EMF is not exactly MOF. How are these
models stored? I would think in XMI. This is in the GMT spec: write a tool
that reads XMI does something useful and writes XMI. The binding glue is
XMI. This is much more flexible that saying MOF in EMF.
Having models and model transformations alone is not enough. Finally you
would like to arrive at an application, to be deployed in the real world.
Advocates of EMF will claim that EMF would be fine for that too. Frankly, I
never worked in a project in my 35 year career where that would have been
suitable. There is always old stuff that has to fit in, other frameworks
that have to be used, other target environments than Eclipse/Java. My latest
project is PHP/MySQL. EMF would be no use with that execpt maybe some
initial modeling, and Fuut-je helps me fine.

> Like this, GMT would just add the necessary infrastructure for
> collaboration
> of various tools. The project would define and agree on higher levels of
> collaborations, and then provide the infrastructure. E.D.
> Willink's proposal
> gives some examples how to lift the infrastructure.
There is a presentation of a GMT-workflow demo we gave at OOPSLA last
November on the GMT site, I have made it better visible recently. Ed's
proposal does not apply to GMT and will go with him to his OMELET project.

Now your questions:
> - if MOF the standard means of the project to define
> meta-models/abstract syntax?
>   If not, why?
MOF is only interesting to researchers and scientists, not practitioners. We
would like to support anything that is useful in practice and that allows us
to model applications in Domain Specific Languages. However, we would expect
that all tools collaborating within GMT support XMI.

> - are you using the EMF implementation of MOF? If not, why?
No. See above. We may use EMF to implement our workflow component.

> - are Eclipse extension-points and extensions the standard means for
plugin existing
>   tools into GMT and for composing different GMT components? If not why?
This is a tough one. Yes. Although... why could a GMT component not be a
web-service or EJB implementation? That seems to be pretty hard as an
Eclipse plugin. Also, I must confess that I find it very hard to write an
Eclipse plugin. The effort I have spent on trying to master this is not
proportional to the results I would expect.

> Your current answers based on XMI do not seem enough to me. For
> connecting pure
> XMI based components, you can use Unix pipes or Web Services, you do not
> need
> Eclipse. XMI is only a way to export and import MOF based models
> (including UML
> models).
If we do not need Eclipse, great!
What about what happens between the import and export of XMI - the model
transformation itself?
What about the workflow component - the GMT component that structures the
model transformations to be done to finally arrive at an application, that
determines the order and conditions for a transformation, and schedules
them, all this in an interaction with Joe Developer, the intended user of
GMT. Modeling and model transformations are only a means to an end: finally
our "payroll application" should roll out for example. GMT should become a
tool to do Model-Driven Software Developement (MDA is only a specific view
of that) in practice. MDA is a way to speed-up application development, ease
maintenance, allow better quality etc.
I think there is plenty of opportunity to use Eclipse as a developement
tool, to make some of the GMT components as plugins and to ensure that
Eclipse itself is part of the GMT toolset.

Regards,
Ghica van Emde Boas
Bronstee.com 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 Philipp W. Kutter
> Sent: Tuesday, March 23, 2004 9:59 AM
> To: gmt-dev@xxxxxxxxxxx
> Subject: [gmt-dev] Outsider View
>
> ...

> Best Regards,
>
> Philipp Kutter
>
> A4M applied formal methods AG
> www.a4m.biz
> kutter@xxxxxxx
>
>
> _______________________________________________
> gmt-dev mailing list
> gmt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/gmt-dev
>
> --
> This message has been scanned for viruses and dangerous content
> by MoveNext MailScanner, and is believed to be clean.
>
>