[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[omelet-dev] RE: OMELET: some question
|
- From: "Ed Willink" <ed@xxxxxxxxxxxxx>
- Date: Sun, 23 Jan 2005 19:06:41 -0000
- Delivered-to: omelet-dev@eclipse.org
- Importance: Normal
Hi Matteo
[I hope you don't mind me replying on-list. Others may be interested.]
> Thanks for deploy into cvs the new OMELET version, I ran some OMELET
> examples and I try to understand the OMELET structure.
I'm afraid the update-site has been delayed slightly by a bug in Eclipse 3
with manifest files. I now know the fix. I probably will sort it out
tomorrow evening.
> I'd like to ask you some question about OMELET.
> We would convert a model representation into another model
> (the models
> are written in XMI 1.2 and we used and EMF editor).
> We know all metamodel representation (metamodel are written
> in XMI 1.2) The modelEditor is generated with EMF plugin and
> we have modified the
> XMI serialization, the editor, now,generates XMI 1.2 model
> file. (EMF generates XMI 2.0 we need XMI 1.2 because we save
> the model into
> MDR repository.)
I'm not quite clear here, because my understanding is that many tools
including Netbeans are exclusively XMI 1.x while EMF is exclusively XMI 2.x.
Could you let me know exactly what tools and versions you are using?
> Now we'd like to decode the model (written with our editor)
> into other
> metamodel. Can OMELET help me?
Yes and No. Today no. Tomorrow (well next month) yes. See later discussion.
> How can I start to write a personalization into OMELET?
With a plug-in that implements some of the extension points.
org.eclipse.omelet.bridges.emf or org.eclipse.omelet.examples are
good starting points.
> Which are the primitive class for OMELET transformation?
Most minimally; IModelProgram or probably ModelProgram.
More constrained (preserved meta-model): IModelConversion or probably ModelConversion.
More constrained (changed meta-model): IModelTransformation or probably ModelTransformation.
(Last week I significantly reduced the distinction between conversions and
transformations, so that the Conversion derivation is almost redundant.)
> Do we have to write a particular ResourceSet? (a specific
> resource set
> for the two metamodel).
No. ResourceSet at present is only a temporary artefact in org.eclipse.omelet.bridges.emf.
Yes soon. Using ATL or Tefkat, I find poor integration with the editor and meta-models.
So anything registered to OMELET will be in OMELET's resource set and there will be
an edit with EMF XMI/XML variant in which all OMELET knowledge is available to
resolve URIs. This should make use of the above transformation tools, community
edition UML tools, and EMF model maintenance fit together tidily.
OMELET is intended to be framework neutral, so it should be useable in a non-Eclipse,
non-EMF context, so EMF related facilities such as ResourceSet will only be available
when the EMF plug-in is used, but this is supposedly Eclipse-independent, so does
not preclude use with an Eclipse-independent OMELET.
This leaves me with slightly awkward design constraints. The core OMELET functionality
must be independent. This doesn't seem to much of a problem so far since OMELET is in
many ways just proxies-for/bridges-to real functionality, such as EMF. The extra
indirection supports the interoperability of different tools and libraries.
> It is not a problem if OMELET is instable or has some errors, if you
> tell me that is possible I try to correct the bug and I send
> to you the
> bug's correction.
This is kind. Unfortunately the bugs may take the form of missing functionality,
not minor defects.
> The other question is:
> We would generate java code from model(now java, in future
> C++, .NET, or
> other code) can OMELET help me? ( I think it is the same answer of
> previous question).
OMELET is a tool for integrating transformation technologies.
OMELET does not perform transformations, it just invokes
some transformation capability that has been installed.
If you only need to do one transformation, you will probably find that
it is much easier to extend the generating or receiving IDE rather
than introduce a third. In due course OMELET may be integrated with
generating/receiving IDE so that you don't care.
The same is true of make or Ant. They do nothing by themselves, and
so if you only have a single activity you don't need a makefile.
The power of OMELET only arises when multiple incompatible activities need
to be combined. This is appearing rather sooner than I expected in the
maintenance of meta-models with diverse XSD, MOF 1.4, UML 1.3,
MOF 2.0, Ecore semantics and XSD, XMI 1, XMI 2, representations.
If your Java/.NET conversions are structured as multiple layers
so that some can shared and others replaced as you vary targets,
then this is exactly where OMELET can come in.
Potentially you can acquire a State Machine optimiser from one source,
a component mapper from another, code generation piecemeal from ...
and of course all with incompatible interfaces.
OMELET should enable the syntactic interface incompatibilities to be
resolved automatically and the appropriate transformations sequenced
automatically relatively soon.
In the much longer term, OMELET should support imposition of semantic
consistency on different transformations. For now we will just rely
on intuitively sensible transformations of convenient sub-sets of
UML w.x to UML y.z.
Regards
Ed Willink