Tagged Values vs Attributes - when to use what?

[volenin]

Hi. I'm a bit confused re: Tagged Values - what's the actual purpose for these? Seems like they can be used in the exactly the same fashion as attributes. When should tagged values be used vs attributes? Are there any advantages / disadvantages to them?

Thanks,

Vlad

[MREA]

Well I understood this like that

Attributes are normal attributes like : int, struct, enum, string,...
Tagged values are further informations for that attribute
like for struct or enum or type def. "type_synonyms"
so you get
               struct {
               } name1,name 2,name 3 (taggs)

you also can mark structs as "typedef=true" to say you wanna have a type def too, hope I helped

[qwerty]

There's no big semantic difference between both. As MREA said the attributes are meant for more technical purpose. That is, they will be transformed to bits and bytes while tags convey more human readable information.

YMMV

q.

[volenin]

Are tag names / values searchable? Eg, when I create Relationship Matrix? Seems like they are not...

[MREA]

what you mean with searching?
you mean with CTRL+F ?
try extended

[qwerty]

Are tag names / values searchable? Eg, when I create Relationship Matrix? Seems like they are not...

Not in the RM. As MREA points out you can used the Extended search from Ctrl-F or you write your own search like

Code: [Select]

SELECT
  o.ea_guid AS CLASSGUID, o.Object_Type As CLASSTYPE, o.Name, p.property, p.value
FROM t_object o
INNER JOIN t_objectproperties p ON o.object_id = p.object_id(from my book Inside EA).

q.

[KP]

Attributes and tagged values are very different things. Attributes are properties of a class. When you generate code from your model, they will become member variables. Tagged values, on the other hand, are a way to extend UML. For example, you may want to add a review status to each message on a sequence diagram. UML has nothing to say on the subject of review statuses, so you add a tagged value to all your messages.

Attributes are part of what you are modeling; tagged values are part of how you are modeling.

[volenin]

Still not very clear to me... Here is a concrete example: I need to model a deployment Node, which represents an execution environment. Each execution environment can run either 'real' or 'artificially generated' data. Also, the environments can be targeted to be used for different purposes: production, test, dev, project specific, etc. Should i be using tags or attributes to describe all these features associated with environment?

[g.makulik]

I think for this case you should use tagged values to specify the purpose of the actual node. IMHO attributes would be more appropriate to model the (relevant) hardware/software properties of this node.

On the other hand if you use attributes to describe these characteristics, you can build diagrams using instances(!) of such nodes, where you fill in concrete values.

It depends a bit of what's your purpose, for e.g. programming language related classes its pretty clear as KP describes it. In this case tagged values would be used to specify meta information for attributes (e.g. programming language language characteristics like 'volatile' that aren't supported directly in UML).

HTH,
Günther

[MMA]

IMHO
In meta model, a stereotype (e.g. named as A)'s attribute will become its instance's (stereotyped by A)  tagged value. The instance of A is a classifier (e.g. named as B). Then instance of B is an object, its slot can dynamically play the role as B's attribute; but can not change B's tagged value.

For example,
1. In meta model, create a stereotype "Car" with an attribute "transmissionKind", value can be enumerated as "auto" or "manual".

2. On Class diagram, create three classes:
     <<Car>>AutoCar, whose tag "transmissionKind" is set as "auto";
     <<Car>>ManualCar, whose tag "transmissionKind" is set as "manual";
     <<Car>>CVTManualCar, whose tag "transmissionKind" is set as "manual"; add another tag "CVT", whose value is true (or "manualType", whose value is "CVT"; whatsoever...)

3. All AutoCar, ManualCar and CVTManualCar were added following attributes:
     leftFront: Wheel
     leftRear: Wheel
     rightFront: Wheel
     rightRear: Wheel
     transmission: Transmission

4. Now if I create an object "MyCar", typed by "CVTManualCar", then
     It will definitely be a "CVT manual" car, no chance to be an "auto" car, no chance to be other type of manual car.
     But I have the right to change wheels:
        Michelin / leftFront: Wheel
        Funlop / leftRear: Wheel
        FireStone / rightFront: Wheel
        HomeMade / rightRear: Wheel
     And have the right to choose a CVT Manual Transmission
        Shimano / transmission: Transmission

5. When do code generation, something like:
class CVTManualCar
{
     Wheel* leftFront;
     Wheel* leftRear;
     Wheel* rightFront;
     Wheel* rightRear;
     Transmission* transmission;
}

Pardon, how to use the "transmissionKind" tag? It can be used in the code generation template like this way (pseudo):
%if tag.transmissionKind.value == "auto"%
       AutoTransmisson* transmission;
%else if tag.transmissionKind.value == "manual"%
       ManualTransmission* transmission;
%    if tag.CVT.value == "true"%
           CVTManualTransmission* transmission;
%    end if%  
%end if%

Note: class "Transmission" is generalized by "AutoTransmisson" and "ManualTransmission", which is further generalized by "CVTManualTransmission".

Maybe it is an ugly design, but it demonstrated how tag value are used in code generation.

Quote what KP said "Attributes are part of what you are modeling; tagged values are part of how you are modeling."

 

[volenin]

Thanks - that's a really good explanation. Sparx docs would definitely benefit if this kind of info is incorporated there. I have a followup question re: this statement though:

It will definitely be a "CVT manual" car, no chance to be an "auto" car, no chance to be other type of manual car.

I modeled a new stereotype like you mentioned. Defined the value of the tag in the classifier. But I still could 'redefine' this value in the instantiation of that classifier. When I change the value of the tag in the instance, Sparx seem to create a 'copy' of that tag in a separate section. So I end up with two sections in the 'MyProfile' section of my instantiation:

Code: [Select]

---------
MyProfile::Car (MyCar)
    transmissionKind: auto  ---> this is the value I redefined for the MyCar instantiation of CVTManualCar classifier
---------
from CVTManualCar
    MyProfile::Car
         transmissionKind: manual ----> this is the value defined for the CVTManualCar classifier

So, if I understand it correctly, I CAN change the transmission type of my CVTManualCar for the particular MyCar instance...

Thanks!

[MMA]

EA has the ability to create tag for the instance to overwrite the classifier's tag value (I'm not sure it is intentional or not, maybe some customer requested that). At least, it is correct that you can not change the classifier's tag value from its instance. I think that's enough.

Personally, I don't like to add tag value or attribute to an object. For instance of classifier, it only cares "run state", which is the slot play the role of its classifier's property(aka attribute).

[volenin]

Ok. Thx.

[Geert Bellekens]

I'm not sure of this is going to help, but you should consider tagged values as "meta" attributes.

They are very much the same thing as the notion "IsAbstract", "Type","OwnedProperties", "Name". All of these things are attributes of the metaclass Class, and can be filled in in an instance of this metaclass (the actual class in your model).

Tagged values offer a way to extend UML and add your own properties to UML elements. (in case you need more then the standard Name, Type,...)

If you have trouble deciding which one to use, you're doing something wrong.

Geert