Empty tags of a class not shown in diagram

[Boron]

Hello,
I just observed that EA 14.1 does not display tags with no value (empty tags) in a diagram, even if the compartment visibility is set for tags (or even inherited tags).
As soon as I give the empty tags a value they are displayed.

Is this behavior normal/intended?
How is the behavior in EA version <= EA 14.0?

I would like to see all tags, even those with no value, if compartment visibility is set for tags.

[qwerty]

TVs are never shown unless you explicit it in the diagram properties. In V!2 all TVs are shown if that is done.

q.

[Boron]

If showing tags is activated in a diagram OR in teh individual "show compartment visibility" of an element (e.g. class):
Why are only tags with filled out values shown in EA 14.x?
How to show all (really all) tags of an element (no matter if the tags are filled with values or not)?

As qwerty write EA 12 showed all tags, but EA 14 does not, only the filled ones (EA 13 behavior?).

[qwerty]

Just report a bug. V14 seems to have enough for any user.

q.

[Eve]

It was an intentional change. Probably to clear some unnecessary clutter since there is no value there. (Although we have had some discussions here about whether an empty string is a value)

I don't believe there's an option to revert to the previous behavior. If you really want the empty value displayed, maybe you could insert a zero width space?

[Boron]

OK, thanks Simon .

Inserting such a space would might be an option, but I would have used displaying empty tags for a quick overview of which tags are still empty.
I decided to add a red colored circle as decoration via a shape script if one of the tags are empty ("red bubble --> something is missing").

[Paolo F Cantoni]

It was an intentional change. Probably to clear some unnecessary clutter since there is no value there. (Although we have had some discussions here about whether an empty string is a value)

[SNIP]

nterestingly, we also had the same discussion.
The UML v2.5 specification has exactly 3 occurrences of the term "Tagged Value".

It says...
Just like a Class, a Stereotype may have Properties, which have traditionally been referred to as Tag Definitions. When a Stereotype is applied to a model element, the values of the Properties have traditionally been referred to as tagged values.

So, the things are actually Tags, the Tag Definitions define which values are possible against which Stereotypes.  If the Tag has a value, then that value is known as a Tagged Value.  However, it doesn't seem to preclude a Tag existing, but not having a value.

It seems to me that we've got the terminology wrong (myself included) when we talk about the tag as the tagged value.

Paolo

[Eve]

By here I meant on this forum. If I remember correctly, with the two of us taking slightly different sides.

Yes, tagged values haven't been officially called that since UML 2.0 was released. However, it's still an easier term to use.

Technically, when you apply a stereotype to an element, you create an instance of that stereotype, which references the target element. The tag is a slot referencing the property, and the tagged value is zero or more of the type for the property.

[Paolo F Cantoni]

By here I meant on this forum. If I remember correctly, with the two of us taking slightly different sides.

Yes, tagged values haven't been officially called that since UML 2.0 was released. However, it's still an easier term to use.

Technically, when you apply a stereotype to an element, you create an instance of that stereotype, which references the target element. The tag is a slot referencing the property, and the tagged value is zero or more of the type for the property.

By here I meant at my workplace...    The discussion being amongst an "Argument" of Architects.

BTW: did you mean: "and the tagged value is zero or more of the value(s) for the property."  If not what's the difference?

Paolo

[Eve]

Instances of the type.

Where 5 is an instance of int, "" or "value" are instances of string.

[Paolo F Cantoni]

Instances of the type.

Where 5 is an instance of int, "" or "value" are instances of string.

So just to be clear...
Technically, when you apply a stereotype to an element, you create an instance of that stereotype, which references the target element (a property). The tag is a slot referencing the property for that element, and the tagged value is zero or more instances of the property type.

Have I got it right now?
Paolo

[Glassboy]

So just to be clear...
Technically, when you apply a stereotype to an element, you create an instance of that stereotype, which references the target element (a property). The tag is a slot referencing the property for that element, and the tagged value is zero or more instances of the property type.

I think my soul died a little.

[Eve]

Have I got it right now?

Almost.

which references the target element (a property).

The target element could be a property. But it could be any concrete UML Element.

• A Stereotype is a class.
• A Stereotype may extend one or more Metaclasses
• A Stereotype has a collection of Properties, each of which has a corresponding type (and UML allows a multiplicity)
• Applying a stereotype is creating an instance. The instance includes a reference to exactly one instance of one of the metaclasses. (The one you are applying the stereotype to)
• Slots are the containers for the values for each property.
• Everything in those containers are instances of the property type.
• The number of items in the container should match the multiplicity of the property. (Although UML explicitly allows for a multiplicity lower than the minimum during creation)

Some notes as far as EA is concerned.
An empty tagged value (including intial value when none is specified) would be the same as having no value conceptually. Except for the string, memo and possibly Addin broadcast or custom tagged value types.
EA profiles don't include multiplicity information