This pages explains how profiles are persisted in eclipse UML2 and EMF. A sample
profile and a model are developed to demonstrate how the XMI representation evolves. The key topic of this article is the work with changing profiles and how the model uses them. Everything here can be done using ArgoUML (in fact lot's of development is done along the writing of this article).

This pages explains how profiles are persisted with eclipse UML2 and EMF. A sample
profile and a model are developed to demonstrate how the XMI representation evolves. The key topic of this article is the work with changing profiles and how the model uses them. Everything here can be done using ArgoUML 0.32 or higher in UML2 mode (in fact lot's of development is done along the writing of this article).

TODO: changing the profile and apply it again, watching what happens to the old stereotype application

While the model references the profile with the <profileApplication ...> tag,
the stereotyped class myClass itself has no knowledge about myStereotype.
Instead, there is a myStereotype instance defined *outside* of the model, that
references myClass.

Note that the <references ...> tag contains the reference to the Ecore package
in the profile, we will soon comment on that.

== Modifying the profile ==

Now let's modify the profile by adding another stereotype myOtherStereotype.
In myProfile.xmi, the following lines are added/changed:

The Ecore package is not changed, because we didn't define the profile again.
As a consequence, the profile works, but only myStereotype is functional. So
we'll going to define the profile a second time, which adds the following lines
to myProfile.xmi:

By defining the profile a second time, a new Ecore package is created which
contains the data required to apply the new stereotype myOtherStereotype, as
expected. But this new Ecore package also contains a section for the old
myStereotype, like in the first Ecore package, so by now we have two such
sections for myStereotype.

If you recall the profile application in our model, where a concrete Ecore
packages was referenced, then it becomes clear that our model still references
the old Ecore package. That's OK, because the profile provides both the old and
the new Ecore package, so the XMI of the model gets parsed without problems.

I'll try to demonstrate it. Our model applies the profile and references it that way in XMI:
{{{<references xmi:type="ecore:EPackage" href="http://argouml.org/user-profiles/myProfile.xmi#_vOqHcPOuEd-ZR_t966HNrQ"/>}}}

This is a reference to the following node in the profile's XMI:
{{{<contents xmi:type="ecore:EPackage" xmi:id="_vOqHcPOuEd-ZR_t966HNrQ" name="myProfile" nsURI="http:///schemas/myProfile/_vONbgPOuEd-ZR_t966HNrQ/0"
nsPrefix="myProfile">}}}

After calling define() again on the profile, another node is created with another id:
{{{<contents xmi:type="ecore:EPackage" xmi:id="_2q7_IAavEeCTnu3LMa6_rg" name="myProfile" nsURI="http:///schemas/myProfile/_2qyOIAavEeCTnu3LMa6_rg/1"
nsPrefix="myProfile">}}}

Both nodes (Ecore packages) are in the profile, they are loaded when the profile is used. So the above reference in the model's XMI serializations remains valid. New models using the profile will use the new Ecore package with the id "_2q7_IAavEeCTnu3LMa6_rg":
{{{references xmi:type="ecore:EPackage" href="http://argouml.org/user-profiles/myProfile.xmi#_2q7_IAavEeCTnu3LMa6_rg"/>}}}

Moreover, when loading our model, something really strange happens (at least in
ArgoUML): the model with the old reference (to id "_vOqHcPOuEd-ZR_t966HNrQ") not
only loads fine (because the profile has both Ecore packages), but even more, the
UML2 xmi parser CHANGES that reference to the new one (to id "_2q7_IAavEeCTnu3LMa6_rg")!
So, the model gets its profile references refreshed in every load/save cycle, which
is quite handy.

To summarize this: modifying (and redefining) a profile is no problem, as long
as no objects (with an xmi:id attribute) are removed.

== Deleting objects in a profile ==

But what could happen to models if we delete elements in a profile?

Let's try and remove a stereotype in our profile. That's not that easy, because
the Ecore packages contain references to a profile element, when it existed at
define time. So, this would violate the profile, and indeed ArgoUML refuses to
save the profile in this case.

Of course it is possible to manually modify the XMI of the profile. But then
a model that applies a removed stereotype causes a problem. Luckily, it
doesn't get invalid, only the stereotype applications will not function
anymore: they become useless {{{AnyType}}} objects polluting the model. Not really
a problem, but undesirable unless the model can be cleaned up. The same happens
when deleting an old Ecore container.

So we get an important rule: never delete profile elements when models exist
that use the profile! 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.

== Conclusion ==

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.

A text file of this article including all model and profile XMI data can be downloaded here: [attachment:Profiles_and_XMI.txt]

This pages explains how profiles are persisted with eclipse UML2 and EMF. A sample profile and a model are developed to demonstrate how the XMI representation evolves. The key topic of this article is the work with changing profiles and how the model uses them. Everything here can be done using ArgoUML 0.32 or higher in UML2 mode (in fact lot's of development is done along the writing of this article).

Profile creation

In UML 2.x, a profile is a separate metamodel element. Both metamodel elements "Model" and "Profile" are packages. In ArgoUML, they are top level packages. You can see this in the XMI files created by ArgoUML: a model begins with a <uml:Model ...> node, while a profile begins with a <uml:Profile ...> node (after the XMI header).

Such a profile object is created in ArgoUML via the "New Profile" functionality. It is then displayed in the explorer pane, and elements like stereotypes or datatypes can be added to it. Since ArgoUML saves this in a project file (.zargo), even diagrams can be added to the profile project.

Elements in a profile can only be applied to model elements, when the profile is "deployed" as an XMI file. This is performed via the "Deploy" menu item when you right-click on a profile in the explorer, which then does three things:

In eUML, a method define() is called on the profile package, which adds (nonstandard) Ecore extensions to it.

Export the defined profile as a (to be chosen) XMI file.

Load it as a read-only profile so that it's available in the "Profile Configuration".

Let's create a sample profile with one stereotype 'myStereotype', which can be applied to a class. The XMI representation is (xmi:id values made more readable, some parts omitted):

This cannot be applied to a model, because in eclipse UML2 the profile needs to be "defined" first. This step introduces an Ecore package in the profile, that represents the whole profile. (Without that Ecore package, ArgoUML cannot use any profile element of the profile!) In XMI, only that Ecore package is added in comparison to the previous listing:

Profile application

In ArgoUML, a profile is applied via the "Profile Configuration". Applying a profile basically means referring it in the model. As an example, we create a very simple model with just one minimalistic class, here are it's main XMI parts (simplyfied again):

While the model references the profile with the <profileApplication ...> tag, the stereotyped class myClass itself has no knowledge about myStereotype. Instead, there is a myStereotype instance defined *outside* of the model, that references myClass.

Note that the <references ...> tag contains the reference to the Ecore package in the profile, we will soon comment on that.

Modifying the profile

Now let's modify the profile by adding another stereotype myOtherStereotype. In myProfile.xmi, the following lines are added/changed:

The Ecore package is not changed, because we didn't define the profile again. As a consequence, the profile works, but only myStereotype is functional. So we'll going to define the profile a second time, which adds the following lines to myProfile.xmi:

By defining the profile a second time, a new Ecore package is created which contains the data required to apply the new stereotype myOtherStereotype, as expected. But this new Ecore package also contains a section for the old myStereotype, like in the first Ecore package, so by now we have two such sections for myStereotype.

If you recall the profile application in our model, where a concrete Ecore packages was referenced, then it becomes clear that our model still references the old Ecore package. That's OK, because the profile provides both the old and the new Ecore package, so the XMI of the model gets parsed without problems.

I'll try to demonstrate it. Our model applies the profile and references it that way in XMI: <references xmi:type="ecore:EPackage" href="http://argouml.org/user-profiles/myProfile.xmi#_vOqHcPOuEd-ZR_t966HNrQ"/>

Both nodes (Ecore packages) are in the profile, they are loaded when the profile is used. So the above reference in the model's XMI serializations remains valid. New models using the profile will use the new Ecore package with the id "_2q7_IAavEeCTnu3LMa6_rg": references xmi:type="ecore:EPackage" href="http://argouml.org/user-profiles/myProfile.xmi#_2q7_IAavEeCTnu3LMa6_rg"/>

Moreover, when loading our model, something really strange happens (at least in ArgoUML): the model with the old reference (to id "_vOqHcPOuEd-ZR_t966HNrQ") not only loads fine (because the profile has both Ecore packages), but even more, the UML2 xmi parser CHANGES that reference to the new one (to id "_2q7_IAavEeCTnu3LMa6_rg")! So, the model gets its profile references refreshed in every load/save cycle, which is quite handy.

To summarize this: modifying (and redefining) a profile is no problem, as long as no objects (with an xmi:id attribute) are removed.

Deleting objects in a profile

But what could happen to models if we delete elements in a profile?

Let's try and remove a stereotype in our profile. That's not that easy, because the Ecore packages contain references to a profile element, when it existed at define time. So, this would violate the profile, and indeed ArgoUML refuses to save the profile in this case.

Of course it is possible to manually modify the XMI of the profile. But then a model that applies a removed stereotype causes a problem. Luckily, it doesn't get invalid, only the stereotype applications will not function anymore: they become useless AnyType objects polluting the model. Not really a problem, but undesirable unless the model can be cleaned up. The same happens when deleting an old Ecore container.

So we get an important rule: never delete profile elements when models exist that use the profile! 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.

Conclusion

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.