Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: Paolo F Cantoni on April 08, 2020, 10:59:11 am
-
With the evolving mechanisms for handling Tags - especially in profiles, I thought I'd ask what is best practice for setting a tag to a specific value?
say I have a Tag named APMQuadrant, defined as:
Type=Enum;
Values=Tolerate,Invest,Migrate,Eliminate,«Unspecified»;
Default=«Uninitialized»;(NOTE: I don't think it matters, for the purposes of this discussion, whether the tag is defined in a profile or in a repository. If I'm wrong, please clarify)
In a profile, suppose I know that a particular metatype will always be in the "Tolerate" quadrant. How can I best specify that fact?
I could:
<Tag name="MeasureNature" default="Tolerate"/>The result is what I'm after(see edit), but is it the only/best way to do this? I'm actually altering the definition of the tag, rather than explicitly setting a value.
TIA,
Paolo
[Edit: This method as we showed elsewhere - will cause the notes column of the tag to be overwritten with the superfluously inconsistent details of the specification! NOT useful!]
-
The way they defined the tags with putting enum data (or other definitions) in memo, interpreting the value field with <memo> content is a design accedent par excelence. This should have ended in the dreaded t_xref (which itself is an even bigger design accident). Well, to be blunt the whole database is filled with design faults which have never been fixed. Rather they added work arounds en masse. I don't expect anything to get better.
q.
P.S. I just had a confirmation. I have a profile element. For (shape script) test purpose I added a "wild" tag named test. First I did set a value of the stereotype properties. of my element. Then I altered its stereotype to that "wild" one. Guess what: the value of the stereotype property was left with a blank name. Goes without further comment.
-
The way they defined the tags with putting enum data (or other definitions) in memo, interpreting the value field with <memo> content is a design accedent par excelence. This should have ended in the dreaded t_xref (which itself is an even bigger design accident). Well, to be blunt the whole database is filled with design faults which have never been fixed. Rather they added work arounds en masse. I don't expect anything to get better.
q.
P.S. I just had a confirmation. I have a profile element. For (shape script) test purpose I added a "wild" tag named test. First I did set a value of the stereotype properties. of my element. Then I altered its stereotype to that "wild" one. Guess what: the value of the stereotype property was left with a blank name. Goes without further comment.
Although to be fair, I expect other similar tools probably have similar fundamental design issue, it's just the vendor may not as open as Sparx sharing its schema, object model etc.
-
Sparx does not really share their model. It's just that I analyzed it with publicliy available tools. The fact that others may be equaly bad or worse does not justify to break even.
q.
-
[SNIP]
[Edit: This method as we showed elsewhere - will cause the notes column of the tag to be overwritten with the superfluously inconsistent details of the specification! NOT useful!]
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