How to stop EA "hijacking" stereotypes via API?

[Paolo F Cantoni]

We are having problems with EA "Hijacking" our MDG stereotypes (on items created via the API) - even though we ONLY have our MDG selected in the lists.

Normally, our stereotype names are encoded (using an algorithm) so that they DON'T conflict with any other MDG technologies.  However, sometimes, the algorithm (as it currently stands) will generate a conflict - as we discovered with "Goal" today.

We have observed, that even with our encoded stereotypes, if a stereotype with the same name (such as Otcm) exists in the general stereotype list, then EA will use the general version (thus the t_xref entry has a GUID, rather than an FQName).  So we try to ensure that such entries are purged.  But since it's not clear as to how these are created it seems to be a post-facto event (the purging).

So, our own MDG is the only one selected and it is set as the active Technology.  Is it, therefore, a bug that under these circumstances, if I get the API to set the stereotype to "Goal", the t_xref entry should be @STEREO;Name=Goal;FQName=<OurMDG>::Goal;@ENDSTEREO;  and nothing else?

As far as I'm aware, I don't need to set the stereotype in the API to "<OurMDG>::Goal" and, indeed, when we do that, we may get a general stereotype of "<OurMDG>::Goal" at no extra charge and with anomalous consequences.

Can anyone advise on how to specify stereotypes to ensure that our MDG is used when setting via the API?

TIA,
Paolo

[Geert Bellekens]

Paolo,

Always use StereotypeEx instead of Stereotype.
In StereotypeEx you can set the "fully qualified stereotype" such as "MyProfile::Goal"

This has always worked for me, but it is still a best practice to make sure your stereotypes are unique.
I use the Archimate approach for my own stereotypes: use a prefix such as «mp_Goal» This pretty much ensures the stereotypes are unique.

Geert

[Paolo F Cantoni]

Paolo,

Always use StereotypeEx instead of Stereotype.
In StereotypeEx you can set the "fully qualified stereotype" such as "MyProfile::Goal"

This has always worked for me, but it is still a best practice to make sure your stereotypes are unique.
I use the Archimate approach for my own stereotypes: use a prefix such as «mp_Goal» This pretty much ensures the stereotypes are unique.

Geert

Thanks, Geert,

Does this process ENSURE you DON'T get a general stereotype anomalously created?   That is, it will NOT (in your experience) create "MyProfile::Goal" (as we have seen).

In the meantime, as you say, I'll have to alter our "Goal" stereotype.

Paolo

PS: Nevertheless, it IS a bug isn't it?

[Eve]

PS: Nevertheless, it IS a bug isn't it?

Why? You've asked EA to find a Goal stereotype and assign that to the element. That's exactly what it has done.

[Paolo F Cantoni]

PS: Nevertheless, it IS a bug isn't it?

Why? You've asked EA to find a Goal stereotype and assign that to the element. That's exactly what it has done.

NO, I specifically excluded ALL but my active MDG - which DOES contain a Goal stereotype and it found one in the TARDIS!  What's more, it didn't find MY (active) one and didn't give me the option of choosing which (of at least 3 possible) I might want to select.

So, if I have an ONLY Project Management MDG active and EA decides to give me a GOAL from Eriksson Penker that's fine?

By definition, it should look in my (Active) MDG FIRST then if not found, look elsewhere!  What so hard about that concept?

Paolo

[Geert Bellekens]

Thanks, Geert,

Does this process ENSURE you DON'T get a general stereotype anomalously created?   That is, it will NOT (in your experience) create "MyProfile::Goal" (as we have seen).

I think it creates the stereotype if it can't find that one.
I've seen that happen when I had a typo in the name of my stereotype.

Geert

[qwerty]

Maybe it's a lack in the definition. I can create a stereotype "BPMN2.0::burp" and EA will treat that as a "normal" stereotype. But (IIRC) stereotypes aew now (since UML 2.?) only valid as part of a profile. EA silently had introduced those EAUML profiles for most (!) of those "normal" stereotypes. But (well, it's EA) it does not consequently use that. Instead there are tons of un-profiled stereotypes lurking around. And you still can create them wildly. Ends up in stereotypes that look like being from a profile but actually are not. This is (typical EA) a half cooked concept.

Try to be consistent on your own. Run your own model checks. Don't trust EA.

q.

[Eve]

NO, I specifically excluded ALL but my active MDG

You prevented them from showing in the toolbox etc. That's all that option does. The other technologies are explicitly still available to ensure existing models using them still appear correct.

By definition, it should look in my (Active) MDG FIRST then if not found, look elsewhere!  What so hard about that concept?

The concept is easy. The problem is that your definition doesn't match the actual definition of that option.

Does this process ENSURE you DON'T get a general stereotype anomalously created?   That is, it will NOT (in your experience) create "MyProfile::Goal" (as we have seen).

From 1425, EA blocks creation of new stereotypes containing "::". You shouldn't see them created. The other thing I would suggest is disable the Configure Stereotypes for all users. This will prevent extra stereotypes being defined from typos etc.

As Geert said, always use the fully qualified name. If you don't, EA will try to guess your meaning. And it will probably get it wrong.

[Paolo F Cantoni]

NO, I specifically excluded ALL but my active MDG

You prevented them from showing in the toolbox etc. That's all that option does. The other technologies are explicitly still available to ensure existing models using them still appear correct.

That's a strange use of the term "Active".  I thought unmarking the MDG list stopped the toolboxes from appearing.  Since you can ONLY set ONE of any enabled MDGs to be active I would have thought, by definition,  "All enabled MDGs are created equal, but the active MDG is more equal than others".  But in these post-truth times, I guess anything goes.

I understand (and agree) that the other technologies should be available to ensure existing models still render correctly.  BUT we're NOT talking about existing models, we're talking about new arcs!  Surely, EA should try to match the stereotype in the MDG of the diagram the arc is being created on?  If not, then we're really NOT on planet Sparx.

If you need any more proof that "She Brok"! (as my mum would say...)

We have code that creates 5 composition arcs in a loop.  Before the test, the general stereotypes are cleared of the specific MDG related uniquely named stereotype ("Cmpstn").  The test is run and "lo and behold", the first arc (by ID) creates a new general stereotype whose value is the unique name "Cmpstn" and the arc is created with a t_xref entry referencing a GUID.  Now for the REALLY BROK bit... The subsequent 4 arcs have been created with the correct MDG FQName t_xref entry!  Go figure!

What a way to build a battleship!

By definition, it should look in my (Active) MDG FIRST then if not found, look elsewhere!  What so hard about that concept?

The concept is easy. The problem is that your definition doesn't match the actual definition of that option.

Does this process ENSURE you DON'T get a general stereotype anomalously created?   That is, it will NOT (in your experience) create "MyProfile::Goal" (as we have seen).

From 1425, EA blocks creation of new stereotypes containing "::". You shouldn't see them created. The other thing I would suggest is to disable the Configure Stereotypes for all users. This will prevent extra stereotypes being defined from typos etc.

As Geert said, always use the fully qualified name. If you don't, EA will try to guess your meaning. And it will probably get it wrong.

Where is the use of the fully qualified name documented?

So I tried to do what is suggested in VBScript

Code: [Select]

foundConnector.Stereotype = stereotype
 foundConnector.StereotypeEx = "MDG::" & stereotype
Setting the breakpoint at the second statement, foundConnector.Stereotype is set to the value of the Stereotype ("Cmpstn").
After the StereotypeEx assignment, both foundConnector.Stereotype and foundConnector.StereotypeEx are set to empty string!  I'm assuming that's NOT supposed to happen.  So what, if anything am I doing wrong?

Exasperated,
Paolo

PS: the caching issue around scripts and debug vs non-debug mode aren't helping and adding to the exasperation!

[Paolo F Cantoni]

BTW, In this repository, User Security is NOT enabled so I can't disable Configure Stereotypes.  In any case, we're talking about automation, not UI stuff.

The Help system says:
The system checks the loaded and enabled Profiles and Technologies, and the Stereotypes table, for a  stereotype with a matching name and base type. If it finds a match, it links to that stereotype and applies the effects. If it doesn't find a match, it creates a new stereotype name in the Stereotypes table and links to that - the stereotype acting as a simple label.

Therefore:

If you don't want the element's stereotype to match with an identically named stereotype located by the system, either:
     -  Disable the Technology that owns the stereotype
     -  Unload the Profile that owns the stereotype, or
     -  Delete the stereotype from the stereotypes table
If you do want the stereotype to match to a specific stereotype in a Profile or Technology, load the Profile or enable the Technology.

AFAIK, I did all these things (In spades - since the ONLY enabled Technologies was our own) and EA still got it wrong!

What is the rationale for finding a match OUTSIDE the scope of the action when there IS a match within the scope?  AND, as per my previous post, getting a different answer in the same loop!

Rita Mae Brown (apparently NOT Einstein) said:  “Insanity is doing the same thing over and over again and expecting different results.”
Sending someone else insane is “Doing the same thing over and over again and providing different results.”

Paolo

[Paolo F Cantoni]

I've got it to work EVEN with an entry in the General Stereotypes for "Cmpstn".

However the following VBScript code

Code: [Select]

Set foundConnector = oEAPackage.Connectors.AddNew(gs_EMPTY_STRING, sConnectorType)
foundConnector.Subtype = sConnectorSubtype
foundConnector.ClientID = orginEAElementID
foundConnector.SupplierID = destinationEAElementID
foundConnector.StereotypeEx = "MDG::" & stereotype
foundConnector.Stereotype = stereotype
foundConnector.Name = name
Session.output "6St="&foundConnector.Stereotype&"= StEx="&foundConnector.StereotypeEx&"= FQS="&foundConnector.FQStereotype&"="
on error resume next
foundConnector.Update
Session.output "11St="&foundConnector.Stereotype&"= StEx="&foundConnector.StereotypeEx&"= FQS="&foundConnector.FQStereotype&"="

Generates the following output:
6St=Cmpstn= StEx== FQS==   
11St=Cmpstn= StEx=Cmpstn= FQS=MDG::Cmpstn=

(for all the 5 arcs in the loop)

Note the change in ordering of the setting of StereotypeEx vs Stereotype

Anybody care to explain the differences in output?

As an experiment, I then commented out the "foundConnector.StereotypeEx = "MDG::" & stereotype" line.
By now, it won't be a surprise to you that it STILL worked!

Final (and further testing - taking time out of my day job) has revealed that if the General Stereotypes entry for "Cmpstn" is NOT present, EA will create one, and (as noted in previous posts) the first will be a GUID and the rest MDG correct.  Whereas, if the General entry is present, all 5 will be correct!  That's why nos 2-5 are correct!

I await someone to tell me I'm not doing it right or that EA is making apposite decisions.

Astounded,
Paolo

[Eve]

That's a strange use of the term "Active".  I thought unmarking the MDG list stopped the toolboxes from appearing.  Since you can ONLY set ONE of any enabled MDGs to be active I would have thought, by definition,  "All enabled MDGs are created equal, but the active MDG is more equal than others".

I may have misunderstood you.

The 'Enabled' checkbox for each add-in is the GUI state. ie. (It can be shown by a perspective)

The 'Active' flag that can be set for a single technology does give it special priority, but only in a limited sense.

https://sparxsystems.com/enterprise_architect_user_guide/14.0/modeling_tools/manage_mdg_technologies.html

Setting a Technology to Active makes that Technology your default interface to Enterprise Architect, and can:

• Override various Toolbox pages (including those from other Technologies) with pages specific to the active Technology
• Redefine a stereotype in another profile, adding new tags and removing or modifying existing tags, while the stereotype behaves in all other ways as if it is the original stereotype

If your preferred Technology does not use overrides and redefinitions, it is not necessary to set it to Active.

Given you would have to have other technologies enabled for either of those, I can safely say that enabling your technology will have no impact on your situation. There's no "post truth" or anything going on.

So I tried to do what is suggested in VBScript

Code: [Select]

foundConnector.Stereotype = stereotype
 foundConnector.StereotypeEx = "MDG::" & stereotype
Setting the breakpoint at the second statement, foundConnector.Stereotype is set to the value of the Stereotype ("Cmpstn").
After the StereotypeEx assignment, both foundConnector.Stereotype and foundConnector.StereotypeEx are set to empty string!  I'm assuming that's NOT supposed to happen.  So what, if anything am I doing wrong?

For a start, never assign to Stereotype. Seriously, never so much as look at it.

The fact that you're getting an empty string is probably a good thing. It means that you're trying to use a fully qualified name that doesn't exist, or can't be applied to that type. Setting the Stereotype after StereotypeEx is bypassing that, and again telling EA to guess where the stereotype comes from.

Are you using the technology name or id instead of the profile name? Does the connector type actually match the type the stereotype is extending?

EA only assigning your stereotype if a matching stereotype exists in the stereotype table could be an indicator that it's actually matching your stereotype despite it not matching the base type. I can't tell without knowing what connector type you are creating, what the stereotype in t_stereotypes is extending and what your profile stereotype is actually extending.

Based on you setting Subtype I'd say that you are trying to extend "Composition", which doesn't have a corresponding metatype, but that's a guess. It's also worth knowing if you can reproduce the behavior with a profile created by EA instead of your own, which may have something that is confusing EA.

Did you know that you could pass a qualified metaclass name (<profile>::<metaclass>) to Connectors.AddNew? Would mean you don't need to explicitly deal with the stereotype at all.

[Geert Bellekens]

I can confirm Simon's statement regarding StereotypeEx.
In my code I almost never use the Stereotype Field.
After setting the StereotypeEx field I would expect the Stereotype field only to be filled in after updating and reloading the element.

Simons tip about setting the qualified metatype is even better. Should remember to apply that in my own code.

Geert

[Paolo F Cantoni]

I can confirm Simon's statement regarding StereotypeEx.
In my code, I almost never use the Stereotype Field.
After setting the StereotypeEx field I would expect the Stereotype field only to be filled in after updating and reloading the element.

Simons tip about setting the qualified metatype is even better. Should remember to apply that in my own code.

Geert

It turns out my local EA 1427 was corrupt!    Repairing the setup made my machine work consistently with others.

Even after I repaired the computer I was getting anomalous results.  However in the last half an hour, things seemed to have settled down.

BTW: in 1427, Setting SetereotypeEx also sets Stereotype, even before the update.

As to Simon's point about "Strong", I never mentioned Strong.  This code is DEEP inside a library and used for all sorts of arcs.  So we set Subtype to the value passed in, in the call.

As it happens, the behaviour was anomalous when we passed in a Type of Aggregation and a Subtype of Strong, but we think we've now tracked it down to an error in our handcrafted MDG.  We ARE trying to move to a generated MDG. 

This code is a VBScript port of code that has worked in VBA (apparently) satisfactorily for nearly a decade.  Hence my perturbation.

It seems I picked the wrong example to start with...  (typical  "Cantoni effect" - point me at a system and I'll find the one anomalous issue)  If I'd started with another arc metatype on a machine with a valid EA install, I might have tracked down the problems myself.

So, believe it or not, thanks to everyone for their help!

I still believe the search algorithm is questionable, but it shouldn't apply if the automation is correct.

Relieved,
Paolo

[Paolo F Cantoni]

Not so fast, Batman!

It seems for our setup we haven't quite got the "ducks" in a row.  Our Composition relationship is still problematic.

But based on the last few days, I'm going to take it more slowly.

Following Simon's injunction to Check on a profile created by an EA model, we confirmed that our handcrafted MDG entry for our Composition (Composite Aggregation) arc appeared to be correct:

Code: [Select]

<Stereotype name="Cmpstn" metatype="Composition" notes="" cx="200" cy="100" bgcolor="-1" fontcolor="-1" bordercolor="-1" borderwidth="-1" hideicon="0">
{Image and Icon entries removed for clarity}
         <AppliesTo>
<Apply type="Composition">
<Property name="compositionKind" value="Composite at Target"/>
<Property name="direction" value="Source -&gt; Destination"/>
<Property name="_SourceMultiplicity" value="1..*"/>
<Property name="_TargetMultiplicity" value="1"/>
<Property name="_lineStyle" value="orthogonalS"/>
</Apply>
</AppliesTo>
</Stereotype>
E.g. this stereotype Extends the Composition Metaclass (via the <Apply> entry)

Can this be confirmed, please?  That is, that this arc should behave like a normal Composition.

Tired,
Paolo