Best practices for Tag/Property in profiles?

[Paolo F Cantoni]

With the recent changes to the way Tags work, those of us with long-term (some even ancient) repositories are presented with a new challenge.

Firstly, the most significant recent change.  In the past, Tags could (and probably should) have been seen as user-defined properties of the item, there to supplement the default set of properties for the item.  Recently, Sparx has formalised this and tags that are defined in the profile are now shown in the Properties window of the item rather than the Tag window.  This is useful as the user can be educated to think more correctly about the model.

So far so good.  But this is Sparx, after all, and naturally, there are inconsistencies.

There are several situations:

1. Tag only in General UML area (t_propertytypes - specific to a repository)   - If attached to an item it is stored in t_objectproperties as <Tag Name> with a unique GUID per instance.

2. Tag defined in General Area but referenced as an item "property" in the profile - attached to the item via item creation or "Synchronize Stereotype" toolbox option.  Stored in t_objectproperties as <Tag Name> with a semi-unique GUID per instance (the left part of the GUID is the same for each instance of the Tag).

3. Tag defined in Profile and referenced as an item "property" in the profile - attached to the item via item creation or "Synchronize Stereotype" toolbox option.  Stored in t_objectproperties as <Tag Name> with a unique GUID per instance.

4. Tag defined in Profile and NOT referenced as an item "property" in the profile - attached to the item via the Tag window.  Stored in t_objectproperties as <Profile Name>::<Tag Name> with a unique GUID per instance.

There are probably other situations, but this is enough to illustrate the basic issues. 

Not only are the tags named as above, but the same name is propagated to the property window!  Thus ONLY in situation 4 is the profile name visible to the user.  This, to me, is inconsistent and confusing the user!

Now to the meat of the post!  What is the best practice in the view of the forum for the evolution of these long-term repositories toward the new model-based technologies - in this case specifically in respect of Tags/Properties?

Where the tag/property is defined as mandatory for the metatype (that is, every instance of the metatype must have a value associated with the tag), it's pretty obvious;  make it a profile property of the metatype!
 
Where the tag/property is not always applicable/present against the metatype, it becomes a bit more problematic.  If we make it a profile property then it will always be included.  For a large repository, this can present almost a combinatorial explosion in tags, especially if the coverage is sparse.

In the past, we took the view that if the tag/property was NOT mandatory, it remained a general Tag and not a profile property and was attached to the item as required.  However, the General tag list is repository-specific and the process for maintaining consistency across many repositories is burdensome!  So, in line with Sparx's apparent direction (since they NEVER release Roadmaps), we converted our General tags to profile tags.

We've just discovered that now that we've done that, we're "hit" by situation 4 if we try to attach a non-metatype property via the Tag window!

So what are people's thoughts about possible best practices here?

TIA,
Paolo

[Geert Bellekens]

I use preferably 3 (tag definition in MDG + referenced as property in MDG), but only for tags that should always be there.

We use some other tags that are only used in certain circumstances and/or can be present on the same item multiple times (mapping tags, Change tags).
These tags are of type 1 (only defined in the repository). One of the reasons we choose for 1 is that otherwise you get the "profile::" prefix in the name of the tag, which is annoying clutter.

Geert

[qwerty]

My tags come from the profile and end up with their pur name in t_objectproperties. The fact that they are from a profile is stored in t_xref. (Well the way Sparx realized it is none I appreciate, but...) Using "Profile::Tag" in t_objectproperties looks like it would heavily irritate EA.

q.

[Paolo F Cantoni]

My tags come from the profile and end up with their pure name in t_objectproperties. The fact that they are from a profile is stored in t_xref. (Well the way Sparx realized it is none I appreciate, but...) Using "Profile::Tag" in t_objectproperties looks like it would heavily irritate EA.

q.

As I indicated, I didn't do anything.  Sparx did it!  As I recall, you're not on v15 yet.  I also didn't see this before (in the past, I thought, they "end up with their pure name").  Maybe it's something that has inadvertently crept in recently?

Anyway, further experiments have shown that:

5. Tag defined in Profile and referenced as an item "property" in the profile - attached to the item via Tag Property Window.  Stored in t_objectproperties as <Tag Name> with a semi-unique GUID per instance.   This is, essentially #3, but via a different route and will add a second instance of the "property" in the Element property window (which cannot normally be done).

Note also that if the Tag is defined as a property in more than one metatype, then the tag attached to that second metatype also has a semi-unique GUID.  As we have previously described (in other posts), the first two "components" of the GUID are used to denote that the tag is a tag in a profile and defined for that metatype.  The first component seems to identify the profile and the second the metatype.  FWIW, I see this as a rather useful solution to the problem of identifying a profile tag solely within the instance itself. (Q, I couldn't find where in t_xref the profile is kept for a Tag - can you enlighten?)

The defect is (as usual) one of inconsistency.  If we look at the 5 situations, we see that ONLY one places the profile name in the property (name) column.  Qwerty says "Using "Profile::Tag" in t_objectproperties looks like it would heavily irritate EA."  Well, obviously, it doesn't - since that's what's happening! But it SURELY irritates me and my queries!

Given that Sparx has taken to using the semi-unique (more correctly, "qualified") GUID to identify the source and mapping of the tag, why not "go the whole hog" and do it consistently?

It seems to me that the two-part qualification of the GUID is a consistent pattern that can be applied to ALL tags in the following manner:
Each profile is assigned a unique profile component value.  Each repository can be considered a "profile" for this purpose.  Every repository has a general section which can correspond to the <All> metatype - assigned a unique value as per the profile metatype.  Each profile (in effect) defines an <All> metatype when the tag is defined in the <TaggedValueTypes> section - unique value applied as per any other metatype.  When the tag is defined/referenced in a specific metatype, a new metatype value is assigned as at present.

The Tag Property (name) is always set to the Tag name - without the profile.  The profile name is a chimera here.  To the user, the rendered Tag/Property name should be the same and mean the same thing regardless of the source.  If that is not the case, then we have bigger problems!

In my view, this change can be implemented "with no loss of generality", and should be at the earliest opportunity!

Thoughts?
Paolo

[qwerty]

Yes, I'm NOT on V15. Unfortunately my customer was sweet talked by a salesman to upgrade to V14 so I have to deal with V13.5 and V14. Bad enough. Reading the bug reports for V15 here assures me to touch it only with pliers.

I remember having seen that <profile>::<tag> some time in the past but claimed it to be some "ghost effect". I got rid of them. And since I found out how it's supposed to be (in V13.5) I was able to add sanity check and keep it that was.

Conclusion: I can only wish you good luck :-(

q.

[Geert Bellekens]

Yes, I'm NOT on V15. Unfortunately my customer was sweet talked by a salesman to upgrade to V14 so I have to deal with V13.5 and V14. Bad enough. Reading the bug reports for V15 here assures me to touch it only with pliers.

I remember having seen that <profile>::<tag> some time in the past but claimed it to be some "ghost effect". I got rid of them. And since I found out how it's supposed to be (in V13.5) I was able to add sanity check and keep it that was.

Conclusion: I can only wish you good luck :-(

q.

The <profile>::<tag> is what happens if you include a tagged value type in your MDG and then manually add that tagged value to an element.
It has been like that since (at least) v12, so not a new thing.

Geert

[Paolo F Cantoni]

Yes, I'm NOT on V15. Unfortunately, my customer was sweet-talked by a salesman to upgrade to V14 so I have to deal with V13.5 and V14. Bad enough. Reading the bug reports for V15 here assures me to touch it only with pliers.

I remember having seen that <profile>::<tag> some time in the past but claimed it to be some "ghost effect". I got rid of them. And since I found out how it's supposed to be (in V13.5) I was able to add sanity check and keep it that way.

Conclusion: I can only wish you good luck :-(

q.

The <profile>::<tag> is what happens if you include a tagged value type in your MDG and then manually add that tagged value to an element.
It has been like that since (at least) v12, so not a new thing.

Geert

OK, accepted it's not new.  But, do you agree that since it is inconsistent it is, by definition, BAD?

Paolo

[Geert Bellekens]

OK, accepted it's not new.  But, do you agree that since it is inconsistent it is, by definition, BAD?

Paolo

Definitely. I don't like it, so we stopped using it and went back to repository defined tagged value types.
I would like them to be consistent (=> not use the profile:: prefix anymore) but that would definitely break existing functionality (e.g. SQL searches, scripts, document generation), so it would not be a painless transition.

Geert

[Paolo F Cantoni]

OK, accepted it's not new.  But, do you agree that since it is inconsistent it is, by definition, BAD?

Paolo

Definitely. I don't like it, so we stopped using it and went back to repository-defined tagged value types.
I would like them to be consistent (=> not use the profile:: prefix anymore) but that would definitely break existing functionality (e.g. SQL searches, scripts, document generation), so it would not be a painless transition.

Geert

Well, moving to it breaks our searches.  Also, I suspect MOST (if not all) users faced with this situation would have taken your route and not used it because it makes life so much more difficult.  We may still take that route (or "fix them post-facto").

Since Sparx doesn't seem to ask the user base "Do you use such and such a feature?"; and I STRONGLY suspect they don't have the instrumentation to report to them on actual usage.  No one actually knows if fixing this inconsistency will affect what percentage of users.

Thus, we might retain BAD functionality under the illusion that it will break stuff - when the facts might be different.

Finally, as I've said elsewhere, we users (especially those that maintain the modelling environments) might view the supposedly "breaking" change as the lesser of the two (or more) evils.  All we need is advance warning that the change is coming and we can adapt.

Paolo

[Geert Bellekens]

To be entirely clear, I'm not advocating to keep the current way, just that we do have some rework if it would be fixed.

Geert

[Eve]

Since Sparx doesn't seem to ask the user base "Do you use such and such a feature?"; and I STRONGLY suspect they don't have the instrumentation to report to them on actual usage.  No one actually knows if fixing this inconsistency will affect what percentage of users.

Don't suspect. We DO NOT and likely WILL NEVER have ANY kind of callback that sends us ANY data of ANY sort. This fact is important to a non trivial portion of our user base.

If read our license agreement you will also see that it makes no allowances for us to collect data.

[Paolo F Cantoni]

To be entirely clear, I'm not advocating to keep the current way, just that we do have some rework if it would be fixed.

Geert

Because the notes column of the tag can be overwritten with the superfluously inconsistent details of the Tag specification, we've decided that the superfluously inconsistent details of the specification will be eliminated by a background query.  Similarly with the profile name prefix in the Property column.

Paolo