Incorrect Profile Namespace Assigned on Element Creation

[wikitect]

I have now seen two scenarios where over-aggressive defaults have assigned an incorrect (profile) namespace to a stereotype on creation

1) Import from CSV. First time OK. On reimport what was a TRAK::Node got changed to UPDM2::Node - despite this being defined in the CSV with the namespace. New elements imported assigned the defined TRAK namespace.
2) Quicklink (meta method). Creates a UAFP::Project despite TRAK::Project being defined and a UAFP::Concern where a TRAK::Concern was defined. Of course the new stereotypes then break any quicklink definition as they aren’t present in any toolbox.

The fact that I don’t have TOGAF etc enabled doesn’t stop the corruption of the stereotypes.

Has anyone else experienced this? I’ve seen similar in the past with an Entity stereotype. It seems that if you have a stereotype with the same name as one of the built-in defaults there might be problems.

[qwerty]

Whatever it is, if it's V16: report a bug.

q.

[wikitect]

Don’t worry on that score. Two submitted wrt this particular behaviour.

Just curious about what other stereotype names might suffer similar problems.

[Paolo F Cantoni]

Don’t worry on that score. Two submitted wrt this particular behaviour.

Just curious about what other stereotype names might suffer similar problems.

A number of the earlier MDGs have hardcoded stereotypes.  In our case, the Database related MDG is one such.  Unfortunately, Sparx doesn't publish a list and so we users have to "trip over them".

HTH,
Paolo

[wikitect]

So far the troublesome stereotype names used by the internal Borg Collective discovered using Quicklink definitions to create TRAK:: stereotypes:-

• Concern (transmuted into UAFP::Concern)
• Event (transmuted into TOGAF::Event)
• Project (transmuted into UAFP::Project)
• Standard (transmuted into TOGAF::Standard)
• Vulnerability (transmuted into RiskTaxonomy::Vuln)

[Geert Bellekens]

So far the troublesome stereotype names used by the internal Borg Collective discovered using Quicklink definitions to create TRAK:: stereotypes:-

• Concern (transmuted into UAFP::Concern)
• Event (transmuted into TOGAF::Event)
• Project (transmuted into UAFP::Project)
• Standard (transmuted into TOGAF::Standard)
• Vulnerability (transmuted into RiskTaxonomy::Vuln)

Have you tried using the fully qualified name of the stereotype?
When using the regular stereotype it's a but of a lottery as to which of the MDG's containing such a stereotype will be selecte.

Geert

[wikitect]

Yes. The Quicklinker definition is fully qualified but Sparx EA ignores this for these stereotype names in preference to its internal Borg technologies.

There is a similar problem on importing from CSV under certain circumstances.

[wikitect]

More default (Borg) stereotypes incorrectly applied to fully-qualified stereotypes using quicklink:-

• Module - transmuted into FML::Module
• Feature - transmuted into TOGAF::Feature
• Product - transmuted into BIZBOK UML Profile::Product

[qwerty]

What I usually do is to simply remove that lot of unneeded MDGs in EA's program folder. Not only makes it the menus less confusing but it would likely prevent these bugs from happening.

q.

[wikitect]

It's a possible mitigation but the faulty mechanism is still present - at best it will (possibly) prevent it from being executed. I say 'possibly' because I don't have any technology other than the basic set enabled and it's not clear that EA is even looking at local technologies rather than assigning a default based on a simple internal look-up. We just don't know.

I've also not checked to see whether it occurs using the older CSV-based method of defining Quicklink but I can't remember seeing elements with unexpected appearances be created (which is the immediate indicator that the stereotype is incorrect).

In some cases it is impossible to manually correct the stereotype once created - the only option is to manually create by dragging off the toolbox (which correctly implements the same fully-qualified stereotype).

This problem with ignoring/transmuting the fully-qualified name also manifests in part of the CSV import.

[Eve]

Regarding the CSV, just makes sure that your specification has 'Fully Qualified Stereotype' instead of 'Stereotype'. Otherwise you will just get the first stereotype EA finds with that name.

I did have an attempt at reproducing your issue with with the quicklinker. I managed to reproduce it once, and only when I was trying to create incorrect profile to reproduce your problem. I think the situation I had was that I had a stereotyped relationship to the element from the original profile as well as the abstract Profile::Stereotype element within the profile I was working with.

Just to be clear. There is nothing special about any of the built-in stereotypes. We're not conspiring to make your profile not work. If you ever get a stereotype from a wrong profile it's because the profile name is missing. I can't say that it will never be because EA has dropped it, but it's been years since I've seen that happen.

[wikitect]

Eve it's not a conspiracy but it is reliably and repeatedly ignoring the qualifying namespace of the stereotype - but only where the (unqualified) stereotype name already exists within a default set.

There is something special about the stereotypes because as I understand it EA will no longer accept an unqualified stereotype name and therefore it will add the (missing) profile name using a known profile that contains the stereotype name. EA therefore has some definition of a default profile which it can apply to ensure that stereotypes are fully-qualified. For whatever reason it's incorrectly applying it during creation using Quicklink.

I am not using nor have enabled any of the profiles which I've seen applied by EA on quicklink stereotype creation. They do not exist in any of the profiles I create. The profile name is very definitely not missing.

[qwerty]

Wouldn't it be more reasonable to simply reject unqualified stereotypes rather than making an (obscure) guess?

q.

[Eve]

Eve it's not a conspiracy but it is reliably and repeatedly ignoring the qualifying namespace of the stereotype - but only where the (unqualified) stereotype name already exists within a default set.

That's the problem. It is not reliable or repeatable on my end. The only time I succeeded to reproduce your behavior was when the rule generated on the profile generated a reference to a stereotype that didn't exist.

There is something special about the stereotypes because as I understand it EA will no longer accept an unqualified stereotype name and therefore it will add the (missing) profile name using a known profile that contains the stereotype name. EA therefore has some definition of a default profile which it can apply to ensure that stereotypes are fully-qualified. For whatever reason it's incorrectly applying it during creation using Quicklink.

Your reason is not remotely related to your claim.

Yes. The user interface no longer allows you to just type a stereotype name in. You can still have stereotypes in the global list and those are unqualified. But that change is something that prevents Enterprise Architect from needing to guess when you're setting a stereotype. Suggesting that change impacts anything else is completely unfounded.

Just to be clear. Your guess about what is happening in the EA code is wrong. There is no default profile. If a stereotype is missing the profile name for any reason and it's not in the global list you will just get the first stereotype with that name that EA finds. That doesn't mean that the stereotype or the profile it comes from is special in any way.

The profile name is very definitely not missing.

Then we're looking for a reason why it gets lost. As I said in my previous post, it's possible even if I haven't seen a case for years.

[wikitect]

Eve it's not a conspiracy but it is reliably and repeatedly ignoring the qualifying namespace of the stereotype - but only where the (unqualified) stereotype name already exists within a default set.

That's the problem. It is not reliable or repeatable on my end. The only time I succeeded to reproduce your behavior was when the rule generated on the profile generated a reference to a stereotype that didn't exist.

Every single stereotyped relationship is fully qualified. The same stereotypes used and referenced in the quicklink are used in view specifications and dragging from the resulting toolbox creates elements with the correct fully-qualified stereotype i.e. it's not stereotypes being unable to be found.

In terms of the lookup (which is a default behaviour and because it is systematic wrt lookup there are default defacto values even if they aren't defined as such ) a) why does it ignore whether a technology is enabled or not; which leads to b) is it only possible to mitigate by finding and temporarily moving them to another folder so they cannot be used as a source? Or do I guarantee what I want by renaming the technology so it appears at one end of the list and therefore the first to be looked within...?