[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[gmt-dev] Re: [gmt-dev] Markus Völter comments on GMT Framework Proposal
|
Hi Markus
Thanks for the comments. I don't have Acroibat at home so my re-comments are
back in text form.
"I think it is important to start with one specific setup of the system to
give people a hands-on way to actually do some work."
Yes. I would envisage that the 0.0.0 GMT Feature will contain framework,
plus at least enough to do some minimal XML work, while by 1.0.0 we could
have some rather better coverage. However whereas Eclipse can impose JDT as
prepackaged, there may be no
GMT extras that are obligatory until QVT is stable. So we may need to
provide a GMT+EMF feature etc as starters.
"do you propose one default model store implementation? For example the MDR
could be plugged in as a default."
I am relectant to support anything by default. It may become a legacy
embarassment. So as per above there could be a standard GMT+MDR feature.
"do you plan to standardize on any metametamodel? MOF?"
No. If we went for MOF we would upset EMF, and if we went for EMF we would
suffer slightly from OMG incompatibility. We must be neutral, and provide
MOF to EMF and vice-versa transformation.
Whoops I misread the number of metas. At the metameta level we might manage
MOF, except that there is a large body of fixed function Java code that
arguably has no meta-model let alone a meta-meta-model.
"I think we agree that the transformations themselves (the model activities)
should not depend on a specific concrete syntax representation but rather on
the in-memory representation of the metamodel, to allow for different
concrete syntaxes and to support transformations that do not need to care
about XMI and stuff. The b+m generator framework implements this approach
very nicely."
Seems like we should support the B+M model representation. The important
point is to allow it to co-exist with all the others.
"OMG version standard" "is this planned??"
I'm not sure. I've heard discussions of the problem. What's important is to
have a framework into which it can fit.
"Robustness" "can you give an example here? I am not sure I understand this
point."
Again it's really about establishing future proofing. Suppose I quantify
robustness in a RubustnessModel as requiring that 99.9% of the code is
subject to 3 way voting on 99.9% up-time machines, and then require the
remaining 0.1% to exhibit 99.9999% up-time. A transformation that performs
joint analysis of code and robustness model can ensure that the figures are
met. Difficult research challenge but possible, once the numbers are there.
"it may throw an exception if it cannot find the necessary transformation
activities. Maybe add to signature."
Yes. I got a lot of this framework going yesterday, the actual signatures
will be slightly different in the light of experience.
"Use a more specific ex!"
May be, but do you want all standard Java exceptions wrapped?
"what is the "program"?"
A programmable transformation engine interprets/compiles/executes a
transformation program. So if you use Saxon as a transformation engine, the
stylesheet is the program. Ultimately this will be an instance of the QVT
meta-model. (There is no need for the two signatures, fixed functionality
transformations can just ignore a null program).
"So you assume that the models in the inputs[] array are correct (in the
sense that they adhere to the underlying metamodel). Also, you assume that
the activity is completely compatible (versions, etc.) I think you should
plan for exceptions when this is not the case, or explain, why this cannot
happen."
Yes and No. Transformations can be much more efficient if a schema
validation has already be performed, and this can be regarded as just
another transformation in which exceptions could be detected.
"We will need some kind of "rule engine" that finds out the composite
activities (sequences...) in cases where no direct transformation is
available."
Yes. I alluded to this in my M4M'03 paper. It's arguably another research
area. Any rule engine is a transformation between models, so the framework
handles it. If it's really rule oriented, then a suitable DSL will be
useful. I think it can be substantially driven from the
metamodel types.
"they need to be specified in the plugin.xml file or even in a separate XML
file. We may need to load this manually when the GMT master plugin starts
up."
I have this working nicely. The plugin defines the signatures, which can be
checked while creating Delegates. Only when the transformation is invoked,
model store used, does the relevant plug-in need loading.
Extract from the experimental XML support plug-in
<extension point="org.eclipse.gmt.umlx.gmt.modelActivityRegistration">
<transform name="Reader" class="org.eclipse.gmt.umlx.gmt.xml.XmlToDom">
<input name="in" model-type="XML[x]"/>
<output name="out" model-type="DOM[x]"/>
</transform>
<transform name="Writer" class="org.eclipse.gmt.umlx.gmt.xml.DomToXml">
<input name="in" model-type="DOM[x]"/>
<output name="out" model-type="XML[x]"/>
</transform>
</extension>
I changed from <> to [] for nested encodings since <> is bad in XML.
"Again: Mappings should be defined as MOF<MySimplifiedUML> -> MOF<YSU> but
ignoring the concrete representations!"
That would be nice, but any particular transformation operates on a concrete
representation, so either the transformation is made polymorphic, which
impacts on every transformation, or the model store is capable of concrete
representation conversion. I prefer to share the functionality by making the
stores smart.
"I would propose to do that. Eclipse also has this concept (I think it's
called IProgressMonitor). We could subclass this interface..."
Ok.
"do you know of any OCL plugin for eclipse? Or any other really workable OCL
parsers?"
I understand that the OCL part of the Kent Modelling Framework has been
contributed to Eclipse. I also understand that Kleppe and Warner have an
Open Source OCL. And I think there's more. I have my own partially debugged
CUP parser for OCL.
"another one should be provided for the b+m generator framework (I'll send
details in a separate mail)."
All useful documented contributions welcome.
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)
