Hi Kenn
The OCL support for UML now uses the UMLResources directly in order
to avoid losing information by using a UML to Ecore conversion.
The UML content of UML model and profile files is complete, so the
Ecore definitions are not needed to syntax check an OCL constraint
involving stereotypes in accordance with information provided in
OMG-compliant UML.
The UMLResource loader resolves the EDynamicEObjectImpl for the
<XX::YY ...> stereotype name to the Ecore definition via the
ECore EAnnotation. This makes the 'purely UML' loading slightly
harder; it is necessary to traverse up to the stereotyped package to
locate the applied profile by nsURI and then down by name to locate
the UML version of the 'Ecore Stereotype'.
[It might have been better to have an
org.eclipse.uml2.uml.StereotypeApplication object so that the Java
model was regular, relegating the XMI serialisation eccentricity to
the loader/saver.]
If it is desirable for the OCL support to use the MDT/UML2 extension
for multiple definitions, then the OCL support can indeed use the
reference to the Ecore stereotype but it must then reconstruct the
UML corresponding to the Ecore definition. [For instance, the
particular definition may have different additional stereotyped
properties in the Ecore representation to those in the UML
representation.]
Regards
Ed Willink
On 20/08/2012 16:12, Kenn Hussey wrote:
Ed,
This support for multiple profile versions has been in place
since the beginning of UML2's support for profiles. The embedded
constructs aren't "sub-profiles" but, rather, Ecore
representations ("definitions") of the profile. There's no
requirement to keep each and every definition of a profile (some
tools actually surface "purge" functionality), but keeping some
of them aids in automatic migration from older profile versions
and supports use cases where perhaps the user doesn't want to
immediately upgrade to the latest version.
What is it about the profile definitions that is causing
trouble for OCL? After all, it's just serialized Ecore
elements...
Kenn
On Sat, Aug 18, 2012 at 4:54 AM, Ed
Willink <ed@xxxxxxxxxxxxx>
wrote:
Hi
I'm trying to get Profiles to load correctly in OCL and have
been somewhat surprised by the non-OMG extensions in an
MDT/UML2 Profile to support Profile versions.
When generating an Ecore model, it may be helpful to have
selectable Ecore sub-profiles available in the overall
profile, however for UML tools these sub-profiles do not
properly exist; there is just the one outer UML profile
definition.
The presence of six sub-profiles in Ecore.profile.uml and
three in my toy example suggests that this approach is not
scalable. Surely profile versions are the responsibility of
the MOF Lifecycle specification and/or a CM tool rather than
embedded multi-content in a different language? Why does a
UML loading tool have to read every obsolete sub-profile?
Why is 'version control' available for Profiles but not for
Imports?
For OCL purposes, it seems that the Ecore sub-profiles can
be completely ignored, which rather undermines the
disciplined version setting imposed by Papyrus.
Regards
Ed Willink
_______________________________________________
mdt-uml2.dev mailing list
mdt-uml2.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-uml2.dev
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
No virus
found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2197 / Virus Database: 2437/5211 - Release Date:
08/20/12
|
