Handling of enumeration Tagged Vlaues

[Paolo F Cantoni]

We've started using Enum(erated) Tagged Values in a big way recently.  If the Tagged Value has already been applied, then it's a simple matter to select it in the list and use the drop-down.

However, if you're manually creating it using the Add Tagged Value, once selected,  the default value is provided but the value can't be changed.  You have to create the value then go back in and change it.

Is it just me, or does this suck conceptually?  The word default value means (in this domain): "in the absence of any other input".  If there's no provision for input, it can't be a default, it's a const.

Should I put in a bug report to get the Enum type entry fixed?  If we can change it on the dialog, we can make better use of the facility to add multiple Tagged Values but selecting a group of diagram objects and using the <Context Menu>.  If we're going to fix it, then in the latter case there should be a mechanism to set the same value to all the objects, or select the value on a per-object basis.

Thoughts?
Paolo

[ChB]

However, if you're manually creating it using the Add Tagged Value, once selected,  the default value is provided but the value can't be changed.  You have to create the value then go back in and change it.
Is it just me, or does this suck conceptually? 

+1
Me too: I've been irritated by this and feel it could be improved.

[Eve]

It's not just enumerations. None of the predefined tagged value types allow for entry on the create tagged value dialog.

The reasons are implementation related rather than user focused.

It's irritated me over the years, but I've learned to live with it. It's only an extra couple of clicks.

[Paolo F Cantoni]

It's not just enumerations. None of the predefined tagged value types allow for entry on the create tagged value dialog.

The reasons are implementation related rather than user focused.

It's irritated me over the years, but I've learned to live with it. It's only an extra couple of clicks.

So it's not just the fact that a default value has been defined?

If you're inputting only one value, then it's "ONLY" an extra few clicks (but a cognitive dissonance each time - because it doesn't work the way it should).
If you're trying to attach to multiple elements it's a PITA.

I think I'll report it as a a bug.

The frog  has decided that the water is too hot and complaining... 

Paolo
[Edit: Bug report submitted.  Show support by posting here...]

[Glassboy]

Yes the behaviour here is irritating.

[Geert Bellekens]

I was just thinking: "Yes, that must be irritating", but then "why has it never bothered me?".
The reason is that I'm only using tagged values in combination with UML Profiles (like they should be used in fact  ).
So I never need to add a tagged value myself, they are already there.

Geert

[qwerty]

Like Simon: got used to it. Feels the real EA way. Can't imagine what it would be once they change it.

q.

[ChB]

I was just thinking: "Yes, that must be irritating", but then "why has it never bothered me?".
The reason is that I'm only using tagged values in combination with UML Profiles (like they should be used in fact  ).
So I never need to add a tagged value myself, they are already there.
Geert

Insightful, thanks Geert.
But bother (lol), I wish I was confident about setting up profiles.  I'm working with SysML <<blocks>> at the moment and I want everyone of them to have an enumerated tag that I've created.  I can only imagine how Geert's suggestion would work ;-)

[Paolo F Cantoni]

I was just thinking: "Yes, that must be irritating", but then "why has it never bothered me?".
The reason is that I'm only using tagged values in combination with UML Profiles (like they should be used in fact  ).
So I never need to add a tagged value myself, they are already there.

Geert

Indeed, but increasingly, we're coming across use cases where we need to be able to add special values.

Also, in Enterprise wide models you come across a scaling issue.  For our Boolean Tagged Values (principally), we've adopted the convention that where a Tagged value is sparsely true, then the absence of the tagged value implies false.  Therefore we don't create one unless we need one (for the true case).  Obviously, setting it to false also implies false, but we scavenge those in our overnight processing.

Unfortunately, as far as I know EA doesn't support these optional types of tagged values in profiles.  We currently have over 300,000 (t_object) tagged values "in play" and we've only just started enhancing our MDG.

Paolo

[skiwi]

I support this fully. I've always wondered why I could not add the value at the same time as adding the tag, since the value field is clearly present on the dialogue.

For example when adding the predefined RTFTemplate tag to a package that I want to generate documentation for. 

[ChB]

Earlier in this thread Geert suggested:

... I'm only using tagged values in combination with UML Profiles (like they should be used in fact  ).
So I never need to add a tagged value myself, they are already there.

I though that was a useful hint and I such I've learned a bit more about creating and using profiles.... and specifically using tags in profiles to help-with (not actually solve) the problem described in the Original Post.

Posting here in case it helps others:
The following white paper explains how to add default tags to a profiled element: http://sparxsystems.com/downloads/whitepapers/Requirements_Management_in_Enterprise_Architect.pdf (see last section before the glossary).  It was not obvious to me that I'd need to  use Attributes to create Tags when creating the extended element in a profile.  The example given in the white paper uses enumerations and as such adds the enumerations to the Profile Diagram.  I just needed tags with text and number values so I created some attributes to my profiled elements using the normal built in types.

So much more to learn!
ChB

[Eve]

For our Boolean Tagged Values (principally), we've adopted the convention that where a Tagged value is sparsely true, then the absence of the tagged value implies false.  Therefore we don't create one unless we need one (for the true case).  Obviously, setting it to false also implies false, but we scavenge those in our overnight processing.

If that's what you are modelling, why not set the default to true? Or even better, use 'Type=Const;' to ensure it's only used in the way you intend.

[Paolo F Cantoni]

For our Boolean Tagged Values (principally), we've adopted the convention that where a Tagged value is sparsely true, then the absence of the tagged value implies false.  Therefore we don't create one unless we need one (for the true case).  Obviously, setting it to false also implies false, but we scavenge those in our overnight processing.

If that's what you are modelling, why not set the default to true? Or even better, use 'Type=Const;' to ensure it's only used in the way you intend.

Hi Simon,


yes, that IS what we do: Type=Boolean, Default=True.  We considered Type=Const and decided that, from a User understanding point of view, allowing them to change the value rather than forcing them to delete the Tagged Value was more intuitive.


Speaking of Type=Const...  What happens if you synchronize tagged values, does the new const value get inserted?


Paolo