[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [mdt-ocl.dev] MDT 2.0.0 vs OMG 2.0 / 2.2?
|
Hi Ed,
Excuse me for
posting on dev mail list.
I'd like to share some notes on simulteneous
support of different version :)
Comments are in-lined
below.
Regards,
Sergey.
> -----Original Message-----
> From: mdt-ocl.dev-bounces@xxxxxxxxxxx
> [mailto:mdt-ocl.dev-bounces@xxxxxxxxxxx] On Behalf Of
> ed@xxxxxxxxxxxxxxxxxx
> Sent:
Wednesday, July 01, 2009 20:15
> To: MDT OCL mailing list
> Subject:
Re: HA: [mdt-ocl.dev] MDT 2.0.0 vs OMG 2.0 / 2.2?
>
> Hi
Adolfo
>
> You're right. It's not easy. Code decisions can be
handled by
> alternate behavioiural objects/methods. The meta-models are
harder.
>
> The UML2 project gives us some clues. It supports UML
2.1 and 3.0.
>
> The model directory contains uml.ecore (3.0) and
uml_21.ecore (2.1).
> The Jasva classes are from the 3.0 model
only.
As for UML2 project it looks like UML_21.ecore
metamodel is maintained for supporting possible upward conversion 2.1.0 ->
3.0.0.
This is also done for 1.0.0 -> 2.1.0 in UML2_2_UML.ecore2ecore
which references deprecated/plugins/org.eclipse.uml2/model/UML2.ecore
metamodel.
I believe UML2 direction is to support latest
version in HEAD and provide implicit means for conversion from older versions
(UML22UMLResource.java for 1.0.0 -> 2.0.0, UML212UMLResource.java for 2.0.0
-> 3.0.0).
In case of OCL such conversion is not so seamless
since OCL sources are text in opposite to ecore models.
But maybe implicit
upward conversion can also be an option. And only OCL 2.2 can be developed in
HEAD.
It also may be reasonable to add possibility to somehow annotate source
with it's version that refers to spec compliance (referring to xmlns in XMI) for
future extensions.
>
> The important point is that the Ecore
model is an Eclipse
> implementation that matches the OMG/EMOF specs as
closely as possible.
> It is not precise.
> Use of EReference makes
the model instantly non-identical from a
> pedantic semantic viewpoint
and totally incompatible from a meta-model
> spelling viewpoint.
>
> We therefore maintain the Ecore OCL 2.2 model as a slight superset
> (include the obsolete classes) so that all the model classes still
> have Java classes, but exclude the spurious classes programatically.
> Certain reflective actions will be inaccurate, such as what are my
> superclasses, but they were in accurate anyway because they had OCL
> class names twice and higher level classes with E prefixes.
>
> So for instance the TypeTypeImpl constructor when configured for OCL
> 2.2 must throw a ClassNotFoundException, but work normally for OCL
> 2.0.
>
> Regards
>
> Ed Willink
>
