Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: Mauricio Moya (Arquesoft) on June 28, 2018, 06:43:39 am
-
Hi. After several tests and reading several posts in the forum about different versions of EA, I'm a bit confused about the ultimate right way to change a stereotype programatically. In a simple scenary as follows:
-There are two stereotypes, from the same profile, extending the same metaclass
-Both stereotypes add the same tag values to the elements.
Sometimes you create the element with the wrong stereotype (A), and later you want to change it to the stereotype B (with a script). What is the right procedure?
I'm particulary confused with: element.Stereotype, element.StereotypeEx, element.FQStereotype, element.MetaType, element.SynchTaggedValues.
Thanks in advance.
-
I've found that setting element.StereotypeEx always seems to do the job.
I hardly ever use any of the other methods/properties, if at all.
Geert
-
I'm particulary confused with: element.Stereotype, element.StereotypeEx, element.FQStereotype, element.MetaType, element.SynchTaggedValues.
- Use StereotypeEx for every time you want to write a stereotype.
- Use HasStereotype() for every time you want to check a stereotype.
- Edge cases for appending a stereotype to the existing list or checking for any stereotype both use StereotypeEx.
- FQStereotype is read only. It allows you to see the profile the first stereotype applied comes from.
- MetaType allows you to get the Metatype defined for an applied stereotype. (It's not read only, but it ignores any assignment)
- SynchTaggedValues() should be automatic when assigning a stereotype. It's useful if the stereotype definition has been updated or tags accidentally deleted
-
So, the right way to do it is as follows?
element.StereotypeEx = "MyStereotype";
element.Update();
or like this?
element.StereotypeEx = "MyProfile::MyStereotype";
element.Update();
So, I think: how does EA know which one of two stereotypes (with the same name but in different profiles) you want to set?
-
The first one will (silently) add EAUML (the default profile). So I would guess. Any stereotype is only part of a profile. This has been introduced in some recent UML version (don't get me nailed on that). But EA still uses its glue-profile so you can stumble from one pitfall to the next.
It's strange (ehrm, no; not at all) that Stereotype (without Ex) has never been deprecated (like some other attributes/operations). EA is conziztent as its "Generalisation".
q.
-
Better to go with the FQ Name, and also take a note of the 'synchronize Stereotypes.' call
-
The first one will (silently) add EAUML (the default profile). So I would guess. Any stereotype is only part of a profile.
Not quite true.
If you don't specify a fully qualified name, EA will apply a matching stereotype from any profile. Only if no matching stereotype exists will it create a new stereotype entry.
As a result, you get an insidious bug in your code. It works fine until some other profile including a stereotype with that name loads before yours.
Please... Always fully qualify your stereotypes.
-
As a result, you get an insidious bug in your code. It works fine until some other profile including a stereotype with that name loads before yours.
Please... Always fully qualify your stereotypes.
Phew. Even worse :-( How about EA insisting on a FQN when checking the parameters?
q.
-
As a result, you get an insidious bug in your code. It works fine until some other profile including a stereotype with that name loads before yours.
Please... Always fully qualify your stereotypes.
Phew. Even worse :-( How about EA insisting on a FQN when checking the parameters?
q.
And breaking a bunch of existing working code?
I hope not.
Geert
-
Well, that's the attitude still having "Generalisation" and other rotten stuff. Software is not dead. You have to work on it to keep it alive.
Of course it would have been better to require FQN in the first place when this operation had been introduced.
q.