Sparx Systems Forum

Enterprise Architect => General Board => Topic started by: bockfu on June 22, 2016, 03:48:46 pm

Title: Avoiding stereotype clashes of MDG technologies
Post by: bockfu on June 22, 2016, 03:48:46 pm
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:

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?

Title: Re: Avoiding stereotype clashes of MDG technologies
Post by: KP on June 22, 2016, 04:09:07 pm
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.
Title: Re: Avoiding stereotype clashes of MDG technologies
Post by: qwerty on June 22, 2016, 05:46:04 pm
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.
Title: Re: Avoiding stereotype clashes of MDG technologies
Post by: Glassboy on June 23, 2016, 07:35:16 am
I generally use a unique prefix for each MDG so each element is unique.
Title: Re: Avoiding stereotype clashes of MDG technologies
Post by: Paolo F Cantoni on June 23, 2016, 09:51:02 am
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
Title: Re: Avoiding stereotype clashes of MDG technologies
Post by: bockfu on June 25, 2016, 07:27:01 am
Thank you all.  The comments helped me understand common practices to minimize and workaround the scenario I am in.