v15.2 – MDG Enum Tags Shemozzle!!!

[Paolo F Cantoni]

We have developed a (relatively) sophisticated mechanism for our MDG that allows us to define Tags as properties of various stereotypes.  Mostly this is managed via inheritance through abstract intermediate stereotypes. As a management mechanism, this works very well.  But unfortunately, it seems to be built on quicksand...   

In order for the tags to be regarded as properties of a stereotype, they need to be defined in the MDG.  They can be defined locally to EACH stereotype OR they can be defined globally within the MDG in the <TaggedValueTypes> section.  The globally defined Tag can be used in the individual stereotype by either explicitly adding it to the <TaggedValues> section of the stereotype or inherited via the baseStereotypes attribute of the stereotype.

Elsewhere, our fellow user qwerty has noted that if the Tag is an MDG based tag it gets a special GUID - the first 'n' characters of the GUID for a specific tag type are the same for a given <MDG>  Thus if the GUID for a specific instance of <MDG>::Fred is "{4D8BF378-485E-442f-BDB7-AADC6AF007FB}" then the first 19 characters are the same for another instance of <MDG>::Fred (for example: {4D8BF378-485E-442f-8918-57E9C85C24E7}).  In this way, EA can tell which tags have been created using the MDG and which not.

Such identified Tags which are formally attached to a stereotype appear in the Properties Window.  Other Tags, which may be defined locally to the repository (via the Configure | UML Type | Tagged Value Types dialog) end up in the Tags window.

So far so good...  So, where's the quicksand?

So, let's say we have stereotype Bill which has a Tag (property) Fred associated with it.  If I create a new Bill (either by dragging from the toolbox or directly in the browser via <Context Menu> | Add Element... ) EA will add the item and add the property (tag), Fred, with the default value specified in the MDG definition (or something else if directly overridden in the definition of Bill).  Inspecting the t_objectproperties (where the item tags are stored) reveals that EA has added a Fred with GUID prefix "{4D8BF378-485E-442f" AS EXPECTED!

However, if I want to add Fred to another stereotype, the Add Stereotype dialog will list the available stereotypes prefixed by the MDG name (as <MDG>::<Tag name> - example BPMN2.0::documentation).  So if I select <MDG>::Fred from the list, I get
<MDG>::Fred (not Fred) in t_objectproperties (AND in the Properties Window - so EA thinks it's a Property) but the GUID Prefix is NOT the same (in fact it varies by instance as though it was a non-MDG Tag!!!).   

So is <MDG>::Fred the same as <MDG>::Fred or is it actually <MDG>::Fred?  In other words, this is a self-inconsistent Shemozzle!  Either I'm talking about the same thing or I'm not!   

FIX IT!

To indicate how self-inconsistent the Shemozzle is; if Fred is defined in the MDG as an Enum, the <MDG>::Fred entry in t_objectproperties - which appears in the Properties window as <MDG>::Fred has the Enum dropdown whereas the original MDG Stereotype defined Fred does NOT have the dropdown even though it is defined as an Enum.  If I add the <MDG>::Fred tag to a stereotype for which it has NOT been defined as a Property, it appears in the properties Window (not the Tags Window) and DOES have the dropdown.   

Reported,
Paolo

[Eve]

I'm going to make an educated guess, that you are adding a new tag to an element with a specialized stereotype of the stereotype that adds the original tag.

That unique prefix is not <MDG>::<Tag>. It's <Profile>::<Stereotype>::<Tag>. If you have two different stereotypes reference the same global tag, they will have a different prefix. The current behavior only checks if the tag exists on the actual stereotype applied, not the supertypes. Because it doesn't find a matching tag it goes back to the behavior of putting the technology name into the name field.

I make that guess because your explanation is enough to prompt my memory that this is the issue I had reported late last year. Unfortunately, I provided insufficient detail for a developer to know what I meant or for me to interpret after I got back from my long break.

[Paolo F Cantoni]

I'm going to make an educated guess, that you are adding a new tag to an element with a specialized stereotype of the stereotype that adds the original tag.

That unique prefix is not <MDG>::<Tag>. It's <Profile>::<Stereotype>::<Tag>. If you have two different stereotypes reference the same global tag, they will have a different prefix. The current behaviour only checks if the tag exists on the actual stereotype applied, not the supertypes. Because it doesn't find a matching tag it goes back to the behaviour of putting the technology name into the name field.

I make that guess because your explanation is enough to prompt my memory that this is the issue I had reported late last year. Unfortunately, I provided insufficient detail for a developer to know what I meant or for me to interpret after I got back from my long break.

Thanks, Eve for the clarification,

Well, I AM creating a new Element which is a specialization of the stereotype that defines the Tag.  I think that's the same as what you said.  Don't forget, this is during element creation from the toolbox.

Do I (now) understand correctly that the GUID prefix is composed of three components, Profile, Stereotype and Tag and that they will alter ONLY when the name of the component changes?  That will explain some prefix behaviour that I observed in recent days.  I can adjust our processes (and validations) to accommodate that (new) fact.

Now your point about adding the technology name, not the profile name is interesting (it's not clear to me that the profile name and the technology name are always the same), but to me seems a non-sequitur.  Since the technology name isn't rendered anywhere else in the various use cases here, I don't see the point of adding it to the property name.  If the intent is to leave a "footprint" of the technology used to create the "anomalous" tag, then add the technology name to the Notes field as is done with the (to me, spurious) default value specification for a known profile tag.

Besides, it's already decided what Profile Tag I'm talking about - since it, correctly, acquires some properties from the global tag - so it's not really anomalous.  Why not just synthesize the prefix for the new stereotype according to the existing algorithm?

Seems a whole lot easier to me...

Paolo

[Edit:  Do I further understand correctly, that the prefix is stable for a given Profile, Stereotype and Tag naming through profile, stereotype and tag versions?  Also, that is is stable across repositories?]

[Eve]

The new tag dialog shows <Technology>::<Tag>. When it finds that you have selected something that looks like that it attempts to find a matching tag in the stereotype definition and if it finds one it fixes it up to match the actual definition that it should use. If it doesn't, it just puts the selected text into the name field (which in my personal opinion is dumb) and it won't be tied to the stereotype at all.The attempt is to do that is relatively recent and I believe that it missed some cases.

For a very long time, tagged value types defined in a technology didn't work at all unless the profile name matched the technology name. I'm not sure when that changed. Looks like the issue I was thinking may have been around this mismatch rather than inheritance, but I won't rule out the possibility that there are other things going on. As always though, sending a sample technology to demonstrate the issue rather than a textual description will make it easier for the developers to investigate.

Disclaimer: This is coming from memory of something that I haven't looked at in over 5 months when I'm still in the tail end of a whopper of a cold that completely killed my ability to focus on anything for the better part of a week.

[Paolo F Cantoni]

Thanks, further, Eve,

I added some further questions to the previous response.  Can you please confirm or deny them?  Also, is tag name matching cased or uncased?

Paolo

[qwerty]

IIRC a comment from Geert said "it depends". If so, my guess would be the database collation. A guess in any case and I would try to keep the case correct.

q.

[Eve]

I can't confirm or deny because I can't remember what your post previously used to look like to know what the added questions are.

The UI for the new tagged value dialog shows <Technology>::<Tag> for any tag definitions in a technology. But by itself that is useless, and unless EA can work out which stereotype the tag should come from it's not going to do any good.

[Paolo F Cantoni]

I can't confirm or deny because I can't remember what your post previously used to look like to know what the added questions are.

The UI for the new tagged value dialog shows <Technology>::<Tag> for any tag definitions in a technology. But by itself that is useless, and unless EA can work out which stereotype the tag should come from it's not going to do any good.

I meant reply #3 to this thread.  Next time, I'll provide a link... 

[Edit:  Do I further understand correctly, that the prefix is stable for a given Profile, Stereotype and Tag naming through profile, stereotype and tag versions?  Also, that it is stable across repositories?]

Paolo

[Eve]

Ah. I was looking at that post, but didn't know that the "Edit" was after my previous reply.

Yes, the prefix will be stable until one of the components of it change. None of those change between repositories. They will change if you rename any of them between versions.

[Paolo F Cantoni]

Ah. I was looking at that post but didn't know that the "Edit" was after my previous reply.

Yes, the prefix will be stable until one of the components of it change. None of those change between repositories. They will change if you rename any of them between versions.

Thanks,  That knowledge helps us to fix up everything in the background.  We're already "repairing" the <Technology>::<Tag> spuriousity (coined a new word!), so we can make our repository more consistent with our intended result.

Paolo

[Paolo F Cantoni]

Well, Eve, I hate to be a "party pooper" but a quick experiment doesn't bear up your assertion about the prefix value...

We already have a table that we created when we believed the prefix was generated by <Profile>::<Tag>  (it contains the TagUUID column below).  So to confirm the assertion, I created three new items each with the same property - expecting that a query to find those prefixes that don't match to show up to three different prefixes.  Instead, we found:

Profile   Stereotype      Property      TagUUID            Prefix
MyProfile   DBSrvr         LifecycleStatus   {C67F44D4-E9BC-fde9   {C67F44D4-91DC-9491
MyProfile   DBSrvrInstnc           LifecycleStatus   {C67F44D4-E9BC-fde9   {C67F44D4-91DC-9491
MyProfile   Dtstr                 LifecycleStatus   {C67F44D4-E9BC-fde9   {C67F44D4-91DC-9491

As you can see, all three stereotypes had the SAME prefix, which, if I understand you correctly, they shouldn't have.  So what's going on?  Remember, these are global tags, applied to specific stereotypes via inheritance.  Could the "same" prefix come about by using the most antecedent stereotype on the inheritance tree - that is, the tag is applied once in the inheritance tree and the rest inherit?  That would make sense (and indeed, would make life a bit easier for us all).  We could then use tag inheritance properly and reduce the number of prefixes required.

Paolo

[Eve]

Yes, the stereotype that is relevant is not the end stereotype, but whichever one defines the property.

[Paolo F Cantoni]

Yes, the stereotype that is relevant is not the end stereotype, but whichever one defines the property.

Thanks, that makes sense...

Paolo

[Paolo F Cantoni]

Although this is a slight tangent, it is intimately related to the identification of MDG based Tags in the repository.

Is it the case, that, when synchronising stereotypes, if EA finds a named tag with an incorrect prefix, it will rectify that as part of the synchronisation process?

TIA,
Paolo

[Eve]

The synch will link non-profile tags with a matching name to a the profile, but won't change any tags that do belong to a stereotype (even if that stereotype is not applied)