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 {{{}}} node, while a profile begins with a {{{}}} 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: 1. In eUML, a method {{{define()}}} is called on the profile package, which adds (nonstandard) Ecore extensions to it. 1. Export the defined profile as a (to be chosen) XMI file. 1. 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: {{{ <-------------- from here it's exactly the same as in the previous listing}}} Such a defined profile can then be used, which is presented next. == 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): {{{ }}} Applying the profile and stereotyping the class with myStereotype yields the following: {{{ }}} While the model references the profile with the 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 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. When loading our model, 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, 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! == 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. APPENDIX Listing 1: myProfile.xmi Listing 2: myProfile.xmi (after being defined) Listing 3: myModel.xmi Listing 4: myModel_using_myProfile.xmi Listing 5: myprofile.xmi (defined, modified afterwards) Listing 6: myprofile.xmi (defined a second time)