Home » Modeling » UML2 » [solved] How to modify a profile that is already in use?(It's about the correct usage of define() and how UML2 profiles are managed)
[solved] How to modify a profile that is already in use? [message #638933] |
Sat, 13 November 2010 13:57 |
Thomas Neustupny Messages: 75 Registered: October 2009 |
Member |
|
|
EDIT: In the meantime, the results on this topic are documented here:
http://argouml.tigris.org/wiki/UML2%2C_Profiles_and_XMI
Happy reading!
---------------------------topic-begins-here---------------- -----------
Dear experts,
I've read the article about using profiles ( http://www.eclipse.org/modeling/mdt/uml2/docs/articles/Intro duction_to_UML2_Profiles/article.html) and managed to create and (un)apply profiles programmatically for quite a long time. But I always run into a problem when an already used profile needs to be modified (extended/changed).
Here is the problem:
After making a change to the profile, I have to define it again to also update the Ecore representation. But then, I've got both the old and the new Ecore package in my profile. So I wonder what happens to my models that apply that profile *before* and *after* my modification and redefinition of the profile.
Questions:
Is it feasible to modify profiles, or are they ment to be read-only after defining and/or applying them?
Is it correct to let the profile evolve the way I described? It grows with each modification cicle!
Do different models refer to different "generations" of the Ecore package in the profile, and is this done intentionally?
Thanks for any clarification! (I'm struggling here for several months now)
Regards,
Thomas Neustupny
[Updated on: Tue, 14 December 2010 12:59] Report message to a moderator
|
|
| |
Re: How to modify a profile that is already in use? [message #639455 is a reply to message #639379] |
Tue, 16 November 2010 16:15 |
Thomas Neustupny Messages: 75 Registered: October 2009 |
Member |
|
|
Thank you for the links, Vlad. So, your answer basically is: "never change a profile that is once applied"? Does this mean that, e.g., if the Hibernate profile (in your first link) is missing a stereotype, then there is no way to add it later? As a consequence, it should not be possible to successfully call define() on a once defined profile, but it works (with the described effect of a growing XMI file).
I was hoping to find an answer on how a profile can be updated, but I didn't find it following your links, or I just overlooked it. I thought profiles cannot be updated?
So should I avoid to call define() more than once on a profile?
But if I do, which problems with my applying models can occur?
|
|
| | | |
Re: [solved] How to modify a profile that is already in use? [message #645229 is a reply to message #638933] |
Thu, 16 December 2010 06:41 |
Thomas Neustupny Messages: 75 Registered: October 2009 |
Member |
|
|
I finished my work on the linked wiki page, here is my conclusion:
When loading a model after a used profile got redefined, something really strange happens (at least in ArgoUML): the references to the old Ecore package are automatically changed, so the model suddenly references the new Ecore package after loading the XMI. So, the model gets its profile references refreshed in every load/save cycle.
So: modifying (and redefining) a profile is no problem, as long as no objects (with an xmi:id attribute) are removed. But: never delete profile elements when models exist
that use the profile!
Maintaining a profile means to add or change elements, this is well supported by the profile mechanism of UML2/EMF. Keep in mind that the profile grows by introducing a new Ecore package with all profile elements in it, so avoid to define the profile too often.
Are these statement correct? Please give feedback!
[Updated on: Thu, 16 December 2010 06:43] Report message to a moderator
|
|
|
Re: [solved] How to modify a profile that is already in use? [message #645343 is a reply to message #645229] |
Thu, 16 December 2010 17:04 |
Rafael Chaves Messages: 161 Registered: July 2009 |
Senior Member |
|
|
Can you illustrate what you are describing with two versions of the profile markup, in the 1st serialization, and the 2nd serialization?
Are you sure it isn't just a result of random id generation? In the TextUML Toolkit, where models (and profiles) are rebuilt from scratch every time the user saves a TextUML file, we use stable id generation to allow cross references to remain valid:
if (resource instanceof XMIResource) {
for (TreeIterator ti = resource.getAllContents(); ti.hasNext();) {
EObject current = (EObject) ti.next();
String identifier = UML2Util.getXMIIdentifier((InternalEObject) current);
((XMIResource) resource).setID(current, identifier);
}
}
Rafael
http://alphasimple.com
[Updated on: Thu, 16 December 2010 17:04] Report message to a moderator
|
|
| | |
Re: [solved] How to modify a profile that is already in use? [message #645442 is a reply to message #638933] |
Fri, 17 December 2010 09:31 |
Thomas Neustupny Messages: 75 Registered: October 2009 |
Member |
|
|
Hi Rafael,
I explained in my article why all the different definitions are needed. Of course the profile keeps growing, but this is a tribute to a well working concept of managing profile dependencies (the profile itself cannot know which model depends on it).
It's like a stable interface distribution without a deprecation mechanism: any artefact (profile element in our case, function/method signature in the case of programming languages) that is once published, must be kept forever.
In the thread you mentioned, the problem was not multiple project definition, but the way it was used: when you define a profile in memory and then apply it to a model, then of course the saved model will contain profile references that don't exist, because the underlying profile is not saved after the second define.
About the "magic", and if it will continue to work: though I think it makes perfectly sense, I'd really appreciate if some expert would confirm that this is indeed intended (I found no docs on this)!
|
|
|
Goto Forum:
Current Time: Mon Sep 23 03:24:38 GMT 2024
Powered by FUDForum. Page generated in 0.06611 seconds
|