[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-uml2.dev] Profile Versions
|
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
