[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [gmt-dev] evolving GMT in a fully open process that allowsothers to join the effort
|
I'm a little concerned about this. As I understand it, the definition of
what is and isn't a metamodel has little or nothing to do with UML, and
everything to do with MOF. That is, a model is a metamodel iff it is
written in MOF. The UML metamodel is just one metamodel, and a "model"
of, for example, petri-nets, is a metamodel if it is defined in MOF,
regardless of any relationship, or lack thereof, to UML.
Jim.
Jorn Bettin wrote:
I like this one! I think we should sort out the meta, meta-meta,
meta-meta-meta confusion. I have the impression that lots of talk about
meta
models is really about models. Any model in UML that is not about UML, is
a
model, not a meta model.
Yes! Even beyondUML, *any* meta model is a model in the end ;-)
Actually, according to this definition, FUUT-je's tool model IS a meta
model.
Yes.
It is a model about itself, modeled in its own modeling language that
is not quite UML. Still, I think it is much more helpful for understanding
what this model is about, to think of it as a model of what the tool knows
about, modeled in something close enough to UML that anyone knowing UML
can
understand it. Since '-je' means: 'Java environment', the model contains
exactly those things that are helpful to generate Java code and anything
related (DDL for example or XML), nothing more, nothing less.
I am not in favor to make the tool model very generic, because it would
loose its applicability to its domain: generating Java applications. What
would be possible, is to use FUUT-jes tool factory capability to create a
meta-modeling tool. Or to create a series of specific tools. For example,
for my PHP/MySQL work, the FUUT-je models I made of the application have
only limited applicability. Maybe it would be better to create a specific
PHP tool (using FUUT-je to create it). Such a tool could very efficiently
generate code from templates. Velocity can easily be used as the template
engine for such an application, or else the FUUT-je template engine is
generic enough for this purpose too (with slightly more effort).
With the right generic tool model you can easily generate your Fuut-je tool.
I don't understand why Fuut-je - which as you say is Java specific, and
which has additional idiocyncracies that could be removed - should be at the
root of the tool ancestry. We should strive for good separation of concerns
between problem space and solution space. The dependencies on the target
language (Java in this case) should be kept in template code as far as
possible, rather than in the structure of the model from which you generate.
See my other email. Starting from one meta model of a DSL expressed in some
tool model, you may want to generate multiple modelling tools for the DSL.
One such modelling tool *may be* implemented in Java.
Jorn
Jorn Bettin
jorn.bettin@xxxxxxxxxxxxxxxx
www.softmetaware.com
Tel +64 9 372 3073 | Mobile +64 27 448 3507 | Fax +64 9 372 3534
_______________________________________________
gmt-dev mailing list
gmt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/gmt-dev
--
"Its only a model." - Monty Python's The Holy Grail.
Jim Steel Tel: +33 (0)2 99 842 554
IRISA (INRIA & Univ. Rennes 1) Fax: +33 (0)2 99 847 171
Campus de Beaulieu e-mail: Jim.Steel@xxxxxxxx
F-35042 RENNES (FRANCE)
