Stereotype name clash trashes MDG

[Paolo F Cantoni]

We created a modelling technology that had the same stereotype for Actions as Activities.  We then decided to create an MDG to support this methodology.  Although they are technically in different namespaces (one Actions, the other Activities) EA will erroneously suppress the second one from the saved profile file.

Given that we users are always complaining that EA allows items with the same name in places where it SHOULDN'T; it is hilarious (or it would be if it wasn't for the two hours lost trying to figure out why the toolbox wasn't working) that EA inhibits items with the same name in different namespaces (the <apply type= is different).

So we thought we'd get around the problem by hand crafting the MDG XML.  Doesn't help - because the same namespace problem exists on input of the MDG XML.  In fact the first entry in the list (whatever it may be) "gets the Guernsey"...

Steps:
Create two stereotypes with the same name extending different metaclasses.

Observe only one gets into the emitted profile.
Reported,
Paolo

[KP]

Create two stereotypes with the same name extending different metaclasses.

No, create one stereotype class that extends multiple metaclasses.

[Paolo F Cantoni]

Create two stereotypes with the same name extending different metaclasses.

No, create one stereotype class that extends multiple metaclasses.

So how do I create two stereotypes with different properties (such as shape scripts).  Within the Settings|UML...|Stereotypes I currently have two stereotypes with the same name applying to each of the metaclasses, but with different properties.  I need to create the same in the MDG.

Do you agree that the instances should be in different namespaces?  If not can you explain why not (query not criticism)?

Paolo

[KP]

The namespace of the stereotype is the profile that owns it, not the metaclass it can be applied to. So I would say that if EA's implementation is incorrect anywhere, it's in allowing duplicate stereotype names in the Settings>UML dialog which defines stereotypes in the global namespace. We won't be fixing that one though, too useful.

So I can think of three ways around your problem:

1. You can move the stereotypes into separate profiles. The MDG Technology can cope with multiple profiles, but you may come across problems if you have cross-profile dependencies such as a stereotype in one profile generalizing a stereotype in another profile. (A fix for that is planned but I have no information on progress.)

2. You can put conditional blocks in the stereotype's shape script, e.g. if(hasproperty("type","Action")) {...

3. You can rename one or both stereotypes, maybe putting the metaclass it applies to into the stereotype name as a suffix.

HTH

[Paolo F Cantoni]

The namespace of the stereotype is the profile that owns it, not the metaclass it can be applied to. So I would say that if EA's implementation is incorrect anywhere, it's in allowing duplicate stereotype names in the Settings>UML dialog which defines stereotypes in the global namespace. We won't be fixing that one though, too useful.
[size=18]...[/size]

So, technically, the "Base Class" in the Settings>UML...|Stereotypes  dialog should be a list - to bring it into line with MDG and UML?  That would make sense I think.

Is there any major drama in allowing the MDG functionality to track the Settings>UML...|Stereotypes functionality - even if only for consistency's sake?  The purists could use the more correct multiple extension process, the pragmatists could mimic the existing EA functionality in the Settings>UML...|Stereotypes dialog.

The other thing I'd like to check is that it seems that if a stereotype is defined in an MDG Technology, then it doesn't appear in the Settings>UML...|Stereotypes list.  Is that correct?  So, once we move the stereotype to the MDG, it should be removed from the common list?

Paolo

[KP]

The other thing I'd like to check is that it seems that if a stereotype is defined in an MDG Technology, then it doesn't appear in the Settings>UML...|Stereotypes list.  Is that correct?  So, once we move the stereotype to the MDG, it should be removed from the common list?

Yes and no. There are two ways to deploy an MDG Technology: file-based and model-based deployment.

The file-based deployment uses the "Settings > MDG Technologies" command to reference technologies that are external to the model, and that is the method you need to use if you want to create custom toolboxes or custom project browser icons. File-based deployment doesn't load the stereotypes table, so yes you may need to perform some housekeeping.

The model-based deployment however loads the technology into the Resources tree, and so populates the stereotypes table.

[Paolo F Cantoni]

Yes and no. There are two ways to deploy an MDG Technology: file-based and model-based deployment.

The file-based deployment uses the "Settings > MDG Technologies" command to reference technologies that are external to the model, and that is the method you need to use if you want to create custom toolboxes or custom project browser icons. File-based deployment doesn't load the stereotypes table, so yes you may need to perform some housekeeping.

The model-based deployment however loads the technology into the Resources tree, and so populates the stereotypes table.

So, if (as I may do while I'm fixing things) I have a stereotype defined in both the file-based technology and in the stereotypes table, which takes precedence?  Since once I've created an item it has no knowledge it was created by an MDG; yes?

Paolo

[Paolo F Cantoni]

The namespace of the stereotype is the profile that owns it, not the metaclass it can be applied to.
[size=18]...[/size]
2. You can put conditional blocks in the stereotype's shape script, e.g. if(hasproperty("type","Action")) {...
[size=18]...[/size]

Hi Neil,

I just wanted to check that I can use this technique to handle the same stereotype in BOTH one or more EAElement types AND one or more EAConnector types in the same technology.

While I'm at it, is there any mechanism to simulate the <all> functionality of the global namespace?

TIA,
Paolo

[KP]

I just wanted to check that I can use this technique to handle the same stereotype in BOTH one or more EAElement types AND one or more EAConnector types in the same technology.

e.g. one stereotype with one shape script that extends Class and Component and Association and Dependency? Yes that will work, as long as your custom toolbox profile is explicitly told what to create e.g. "MyProfile::MyStereo(UML::Association)".

While I'm at it, is there any mechanism to simulate the <all> functionality of the global namespace?

Not quite. If you create a profile with a stereotype that extends a metaclass named "<all>", the stereotype will appear in stereotype listboxes but you won't be able to drag and drop it from the toolbox (I just tried and failed).

[Paolo F Cantoni]

[size=18]...[/size]
Not quite. If you create a profile with a stereotype that extends a metaclass named "<all>", the stereotype will appear in stereotype listboxes but you won't be able to drag and drop it from the toolbox (I just tried and failed).

Just to be clear - if I create a specific EAElement or EAConnector of a nominated type with that stereotype for the toolbox, I won't be able to use it from the toolbox?  

But I CAN set the value on an existing EAElement or EA Connector and the shapescript WILL activate?

Will I need to add a Feature Request/Bug Report to get that fixed?

Paolo