Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: DanG83616 on December 29, 2008, 12:42:03 pm
-
I've added a tag for a bunch of elements. If an element specializes other elements, the Tagged Values view shows the tag and value for the selected element and a list of "from ...". There is one entry in the "from ..." list for each general element specialized by the selected element. It kind of makes sense because the value of the tag is overriding values of the general elements. However, this seems different from other attributes such as Short Description or Alias. Thus, I'm wondering if I have the wrong idea about tags.
Is a tag not the same thing as any other element attribute except that it is a domain-specific addition? In this case, the tag is an external id for the element. Perhaps I've got the wrong idea about how tags can be used.
I'm about to tag about 1000 elements and would like an heads-up if it looks like I've got the wrong idea. If I don't have the wrong idea, why would I care to see the "from ..." information displayed in the Tagged Values view?
Thanks,
Dan
-
Hi Dan,
Somewhat oversimplified, here's how I understand it...
Tagged values are not quite like other attributes. They originally were an extension mechanism, allowing UML to transcend its design boundaries. That is, you could use tagged values to represent additional properties - whether attributes or other subtleties did not matter, just so long as the 'extended' property could be identified with a name and have its value expressed as a string - beyond those that UML provided by default.
This is still a major function of tagged values of course. As UML has come to be used for more things, whether through custom extension via profiles or through specialized dialects, tagged values have become invaluable. For example, EA uses tagged values to easily capture things - including some that are part of the standard UML - that are not well handled by the core schema. While this is not quite what UML (originally) had in mind for tagged values, it is a perfectly reasonable way to use them.
Back to your situation. It seems that tagged values would work best for you if they could be treated like any other attribute. Ideally this is how they should work, at least in a profile. My guess is that you've run into the EAUI here. You could make a feature request to Sparx regarding some way to turn this off. Perhaps it could be added to the Tools | Options | Objects dialog as a global option. It might operate something like the options to group attributes by stereotype, or sort them alphabetically.
I'll leave you to decide whether to make the request. If you do, I strongly suggest you either start a new thread in the S&R forum section and cross reference the new thread and this one, or simply post back here to tell us what you suggested.
David
-
Hi Dan,
I think the real question that you are asking is (correct me if I've misunderstood): "if a class has a Generalization to another class, what information does it inherit?" The short answer is features (i.e. attributes and operations), tagged values and constraints. Characteristics of the parent class such as alias and description don't get inherited.
HTH
EDIT: You and I have different meanings for the word "attributes". I'm referring to the UML representation of member variables. I think your meaning is the same as my use of the word "characteristics" above.
-
KP,
David gave me the reassurance I was looking for and your explaination helped as well. You are right that I was using attribute generally and it might be helpful to use "characteristic" in this context. I see that the SysML profile add-in uses tagged values to add "Id" and other characteristics to Requirement elements. I'm feeling pretty safe at this point.
I'm not ready to propose a feature change per David's suggestion because I don't feel qualified. About all I could do is describe how I got confused (see the start of the thread) and leave it to Sparx to decide if something really needs to be done.
Thanks for the replies and Happy New Year !
Dan
(childish as it is, it's kind of cool to reply to a post that was made next year :))