Avoiding stereotype clashes of MDG technologies

[bockfu]

What are the practices to avoid stereotype clashes of MDG technologies?

I am observing a problem I haven't resolved yet which I believe is due to a stereotype clash.

Steps leading to the issue:

• Create MDG Technology called 'My Requirements'
• 'My Requirements' defines a 'Functional Requirement' stereotype derived from the requirement metaclass
• Import 'My Requirements' MDG technology into model
• Import 'SYSMOD' MDG technology into model (Reference)
• Create a Business Requirement element called REQ1 (Note: Element could be of any type other than "My Requirements::Functional Requirement"
• Change type & stereotype of REQ1 to "My Requirements::Functional Requirement"

This is where I run into problems.
Expected Result: I am able to change type and stereotype to "My Requirements::Functional Requirement"
Actual Result: The type and stereotype changes to "SYSMOD::Functional Requirement"

Perhaps I am doing something wrong; on either the MDG development side, or EA usage side.

Any pointers?

[KP]

Two bits of advice:
1. Disable any technologies that you aren't currently using.
2. It is better to create a new stereotyped element than to change the stereotype of an existing one. There is no confusion about which profile the stereotype is coming from, and properties with default values are set to default values.

[qwerty]

Things are only what their name is. You can give one thing two names, but never two things one name. So what KP said: reduce the amount of names by turning off unneeded MDGs (that's the first I do in any EA-related project). And then: name things unique.

q.

[Glassboy]

I generally use a unique prefix for each MDG so each element is unique.

[Paolo F Cantoni]

I generally use a unique prefix for each MDG so each element is unique.

If I must qualify, I prefer suffixes. That way, the alphabetic sorting of the original values is preserved.

However, we have just been through a TOTAL revamp of (almost) our entire MDG and we have completely separated our stereotypes by using contracted forms.  The metatype in the MDG holds the user friendly name.  We will be ensuring that every metatype (both vertices and arcs) will have a unique visual representation and therefore we wont be displaying the contracted stereotypes anywhere.  Every item will have an attached stereotype (there won't be ANY nulls! - Yea!)

Paolo

[bockfu]

Thank you all.  The comments helped me understand common practices to minimize and workaround the scenario I am in.