Guidelines for updating the UML profiles

[cyril.combe]

Dear all,



I am currently working on an issue for which I need to edit an UML profile (adding a tagged value to andromda-profile-service). So I wonder what is the right way of doing it as we have several versions of the profiles that need to be in sync:

profiles/uml-1.4
profiles/uml-2.0
profiles/emf/uml2

I have installed version of MagicDraw 9.5 and 12.5.

Step by step guidelines would be greatly appreciated.

Thanks,



Cyril

[Bob Fields]

Some things I discovered while updating profiles...



- It looks like UML1.4 and UML2 profiles are maintained separately, rather than upgrading a copy of the UML1.4.xml.zip profile to UML2. The .uml2 profiles can be exported from the UML2.xml.zip profile models.



- Many of the UML2 profiles contain hard-coded module resource directory references to related models, assuming they can be found by configuring the Environment Global model reference directories. These should be replaced with a pathmap element like <andromda3.home>. Some models also have references to UMLStandard MagicDrawProfile, making them UML tool specific.



- There are a number of issues with upgrading the UML1.4 models as-is: UML2 requires tagged values to be a property under a Stereotype (most of the UML1.4 tagged values are standalone). Also, it requires profile elements to be in a special <<Profile>> package, and creates a new separate Profile package under the top level model during the conversion. Creation of the <<Profile>> package only copies some of the profile elements from the original model package (Stereotypes and tagged values), not others (Classes and Enumerations). If you try to apply the <<Profile>> stereotype to the UML14 shared cartridge profile package, the model returns an error that the shared package contains an external dependency. I'm not sure if there's an easy way around this, other than to let it create the separate Profile package under the top level model element. Reference: MagicDraw UML2 Migration documentation.



- Tagged values in the UML1.4 profiles look like -@andromda.cartridge.whatever. Tagged values in the UML2 profiles look like -andromda_cartridge_whatever. These should be the same, at a minimum to avoid documentation confusion, even if there is no processing difference. I'm not sure if the different structure of the tagged values affects whether the cartridge sees the tagged value or not. There's a number of new Stereotypes in the UML2 profiles (i.e. WebServiceNature), containing the old tagged values, so apparently that doesn't affect processing. Migrating the UML1.4 tagged values creates a new stereotype with the same tagged value name, if it was a standalone tagged value.



The long term solution to this is to make the UML1.4 profiles forward compatible with UML2, making sure the tagged values are still recognized. I'm not sure if the tagged value identifier can be preserved after migration (so that the tagged values do not have to be removed and reapplied to existing models migrated to the new profile version).

[tfmorris]

It isn't clear to me that AndroMDA hasn't been abandoned, so we could be talking in an empty echo chamber here, but here are some additional tidbits:



- The UML 1.4 AndroMDA profiles are MagicDraw-specific because the separate module references are incorrectly serialized making them unusably by other tools.



- My personal opinion is that the profiles should be UML tool neutral and the UML 1.4 profiles should be follow as many of the UML 2.x rules as possible (I think they're all actually good and recommended practices for UML 1.4 anyway). Having said that, I don't see where the manpower is going to come from to achieve this. The core AndroMDA developers were historically only interested in MagicDraw because that's all they used and I think they've all left anyway.



- Whether or not tagged values are unowned by stereotypes or not is, I think, mostly a matter of vintage. Things which were added to the profiles more recently tend to have an owning stereotype. This was a new feature introduced in UML 1.4 which may account for some of this if some of the earlier work was done with UML 1.3. Having everything owned by a stereotype makes the modeling much cleaner because the modeler is only presented with the applicable choices by the UML tool.



- The last time I looked at it (1-2 years ago), all the AndroMDA stereotype/tagged value/etc resolution was done based on name alone, so you don't actually have to have a stereotype with the right ID that resolves to the one in the AndroMDA profile. It just has to have the same name. That means you can create your own profiles from scratch using whatever tool you want as long as the names match up.



- If the xmi.id's of the tagged values aren't preserved during the migration that you are attempting, it should be possible to restore them with a little hand editing. Technically there's no reason you shouldn't be able to copy the existing TagDefinitions into a new owning Stereotype, although I don't know if MagicDraw will do it. I'm pretty sure ArgoUML will do this without changing the xmi.id's.



Hope those tidbits help enhanced the accumulated knowledge about AndroMDA profiles.



Tom

[Bob Fields]

AndroMDA definitely hasn't been abandoned, there's lots going on, and it still has the best UML to code implementation around. There's a few of the core developers left and the existing infrastructure, plus some new people (myself included).



I've pretty much got the UML14 profiles forward compatible with UML2, such that the test models also migrate forward, I'm testing most of the cartridges right now with the migrated models, seeing a number of minor differences and inconsistencies. I wanted to keep the xmi IDs the same to avoid reapplying the stereotypes to existing migrated models, successful so far.



A couple more things I noticed:



- UML2 metafacade specifically checks for the andromda_whatever format of the tagged value in UMLUtilities.doesTagValueNameMatch(), and UML2 specifically disallows the @andromda.whatever format because it isn't a valid Java identifier even though MagicDraw stores it in that format internally. RSM automatically migrates the values to the _andromdawhatever format, which is pretty ugly, so the taggedValue name should really be changed to be consistent across all UML implementations (andromda_whatever). As long as the xmi:id remains the same, and the UML14 implementation is updated to check for the new format, everything should remain compatible in existing UML14 models.



- The profiles can be made UML tool agnostic even though they have the UML Standard Profile. MagicDraw adds the MagicDraw profile which can be removed separately or can be added as a separate dependency.



- Applying the UML Standard <<Profile>> to the profile package works for migration to keep everything in a single package. UML2 cannot find/apply stereotypes in subpackages, so these must be moved to the top level stereotype packages (i.e. persistence.manageable).



- If a taggedValue references an Enumeration, and no default is defined, the first value in the EnumerationList is always selected as the default. For this reason, the extra 'default' enumeration value is added to each Enumeration as the first enumerated value.

[tfmorris]

AndroMDA definitely hasn't been abandoned, there's lots going on, and it still has the best UML to code implementation around. There's a few of the core developers left and the existing infrastructure, plus some new people (myself included).

That's good to hear. I haven't been following CVS recently, so I was mostly going by forum activity and the disappearance of folks like Chad, Wouter (and of course Matthias), but Ohloh, for what it's worth, also seems to think the project is abandoned. http://www.ohloh.net/p/AndroMDA If that's just an issue with the CVS registrations there or something, it might be worth fixing them so folks don't get the wrong impression.

As long as the xmi:id remains the same, and the UML14 implementation is updated to check for the new format, everything should remain compatible in existing UML14 models.

Presumably the UML14 metafacade/cartridges would look for both the old and the new names so that they'd continue to work with models which are still linked to the old profiles (as well as models which are linked to homebrew profiles or contain the necessary Stereotypes and TagDefinitions which were created by hand directly in the model).

Of course folks with homebrew profiles should follow the same strategy to migrate them forward, changing the names, but keeping the xmi.id values the same.

The profiles can be made UML tool agnostic even though they have the UML Standard Profile. MagicDraw adds the MagicDraw profile which can be removed separately or can be added as a separate dependency.

The issue isn't the UML Standard Profile (or any other linked profile), but rather the way MagicDraw serializes what they call "modules." If you look at the XMI for one of the modules, you'll see that it contains some outer packages which MagicDraw basically ignores when it reads things back in. The combination of those containing packages and the containing packages in the linked-from XMI create a situation where the profile package is trying to be in two places at once causing a composition violation if you try to read the linked XMIs with a conformant reader.



I don't know if they can read models which are serialized correctly. If they can't and you want to continue to use MagicDraw to maintain the profiles, then some type of post-processing is probably required.



The NetBeans MDR library is one conformant reader which can't read these profiles, but the AndroMDA developers side stepped the problem by hacking MDR to work around the problem (but didn't publish their diffs which I'm pretty sure is a violation of Sun's license).



If anyone is interested in more detail, you should be able to find past discussions either here in the forums or in the mailing list archives for the period before when a mailing list was used instead of a forum.



Tom

[Bob Fields]

I'm not sure how Ohloh measures activity, but a 3.3 release this year plus a bunch of activity on both andromda-all and andromda-plugins should put the project in the 'not abandoned' category.



The MDR hack was way before my time, I didn't notice anything because it simply worked, including the migrated products. I'm just trying to get everything migratable to UML2 and UML2.2 and working there.



More problematic for me is that the .uml models exported by MD 15.5 fail when read by AndroMDA, but the .emx models from RSM 7.5 (and the .uml models exported by RSM from the .emx models) work fine. It may be a module dependency problem, UML patch level problem, or something else, I'm still researching. Right now it takes three model import/save/export sequences (MD9.5 -> 12.1, MD 12.1->15.5->.uml, .uml->RSM7.5) to get a working model version for UML2 2.x.

[repinel]

- If a taggedValue references an Enumeration, and no default is defined, the first value in the EnumerationList is always selected as the default. For this reason, the extra 'default' enumeration value is added to each Enumeration as the first enumerated value.

Hi Bob,

I know that this post is a little old, but I am having a hard time with the Enumeration issue...

I have some UML1.4 profiles based on the AndroMDA-3.1 profiles, that I am exporting to UML2. I have already exported and almost everything is working well, despite of the tagged values with boolean or Enumeration values.

When I apply a tagged value that has a Enumeration and I don't change it value, leaving on default, I can't see an effect while generating the code with AndroMDA-3.4-SNAPSHOT using EMF-UML22. Is just like the tagged value isn't there. However, if I select another value from the Enumeration, then I get it on AndroMDA. And the same occurs with boolean values...

Do I always need to have a "default" value when using Enumeration? I also saw on the AndroMDA-3.4 UML2 profiles that you have a TernaryBoolean Enumeration with a "default" value, is it a workaround for boolean tagged values?

Another thing, what if I use a default value specify directly on the tagged value?

Thank your for any help!

[Bob Fields]

The TernaryBoolean value is a workaround for primitive boolean not being nullable, because the UML2 stereotype attribute values cannot be null. The UML2 profiles were designed using those originally instead of being migrated from UML14. Whether the default has an effect or not depends on the specific implementation in the cartridge, typically it checks specifically for 'default' and substitutes the actual default value, so either one can be used if that is the intent. Which profile value were you using with which cartridge and model element, that had no effect?

When upgrading profile versions, you really want to point to the current version from the model instead after upgrading a local copy of the existing profile.

[repinel]

Thank you, Bob. I wanted to be sure before having to modify the converted profiles.

Now everything is working well. I added a new element 'default' to all Enumerations and a TernaryBoolean for primitive boolean types.

Before, I was having a problem with the tagged value @andromda.presentation.web.view.field.type, that had 'select' as default value. So when I tried to use 'select', the cartridge could't read the value...