HasTag and realised MDG tags

[AndrewW]

I understand how HasTags work as below,
if (HasTag("Tag","Value"))

{
do stuff
}

These are fine for locally defined tags or those craeted by MDG.
However how can i get them to work for realised tags. Especailly if the shape script is generic. and the script will be used for may realised values from many classes.

Kind Regards
Andrew

[qwerty]

Maybe the posts from KP here will help: http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1335287086

q.

[AndrewW]

Had a read , but the requirements looks different. I want to use the realised values in a shape script, so i can change the appearance of the shape depending on the value of the realised values. This way i can change one value and the value if then be automatically propigated to all reated classes, and their shapes

Is this even  possible with in EA

[qwerty]

I just thought you could check the mentioned tags in the way you pointed out. But this only works for a realization from an Interface. If that's not the case for you then you can probably write some complicated add-in which you evaluate in the shape script.

q.

[AndrewW]

Thanks qwerty,
Tried the interface (via MDG), and no luck

Let me explain what I am trying to achieve, as there is the possibility that I am going around this the wrong way.

I trying to create an overall Technical Architecture, and link this to a Technology Roadmap. So as the roadmap is changed so is the Technical Architecture diagram.

I was going to follow the deployment UML model for this but; this did not appear to meet my requirements so I tried with classes.

These classes are extended with MDG to have predefined tags, drop down menus to keep consistency, and shape scripts (this is where I am stuck).

I planned to have each item on the technical roadmap defined (including details and architectural status), and then link the execution environment and nodes (represented as classes)  to them (realised) so I could pass down the tagged values (including architectural status),more importantly one change to the technology class will  update all relevant (realised) elements.

I have been trying this with servers which realise two other classes one for the OS and one for the H/W along with the individual architectural status (yes I have used differed tagged value names for the OS and h/w classes).  I would then use shape scripts on the class representing the server to

1.      show a small Icon of the OS
2.      show the architectural status i.e. Strategic  etc of the OS
3.      show the architectural status i.e. Strategic  etc of the H/W
on each class representing a server

If this worked, it  would be extended to the Execution environments (again represented as classes.)

In this example if the OS moved from Strategic to Avoid all I would need to change would be the class representing the OS and any related classes (representing servers) would automatically update.

Additionally (not tried yet) I would like to product reports for the technical roadmap and the technical Architecture probably will be split by applications  although there will be links between the apps as the diagram would be too big otherwise.

I this possible in EA and have I used the completely wrong approach, if so what’s the correct one.

Kind Regards
Andrew

[qwerty]

So you create realizations (also) in order to see the tagged values of the inherited classes. And you want to visualize these tags in the inheriting nodes/environments?

If that's true you won't see the inherited tags directly. Only by creating an add-in to evaluate these and call that from your shape script.


q.

[AndrewW]

Thanks for the help , yes your correct.
In your view is EA a suitable platform for this use ?
Andrew

[qwerty]

Well, your needs can't be satisfied out of the box. The problem here is that the display in tagged values window shows more than the direct tagged values of an object while the HasTag just searches the latter. Probably it's worth a feature request to extend HasTag with a boolean parameter to also search through inherited tags. But that won't help you  now. You need to bite the bullet and get into add-in programming. Once you made the step it is not too difficult. You can extend shape scripts by advanced add-in functions. Here you would inspect your inherited tags (which is quite easy) and return the according values which you can use to create different renderings. I haven't done that but for sure it should be doable in 2-3 days.

q.

[Michael Proske]

I had the same problem today with instantiated classes where the tags also are inherited and will not be seen by the shape script. I made a bug report out of it lets see how Sparx react on that.
qwerty you have the right idea i will write extend my extension to read inherited tags.

[Paolo F Cantoni]

Guys,

I think this is getting down to the question of what is "Generalization" versus "Realization".  I don't think it's right to talk about Realization "inheriting" things.  It's true that EA seems to use a very similar mechanism - but that may be part of the problem here.

Over the years, I've found it's really all about the "language".  When you use the correct and unambiguous terms, you can often get to the real problem and describe the right solution.

Generalization is about getting access to items defined higher up the generalization tree and so the way in which EA provides these to us a the lower levels is correct - they aren't really there.

In the case of Realization, it's a different proposition.  I view it as a copy mechanism at the time of realization.  The features of the classifier (such as the interface) are "copied" into the realized item (say the class).  If the interface changes, the class doesn't necessarily change.  However, obviously, at the design level, you'd often like the two to track each other.  My view is that if the interface changes, the user should be alerted to  the fact that the class MAY need to change.

Paolo

[qwerty]

IOW you mean that EA should actually COPY the (currently inherited) tags whenever a Realization is created?

q.

[Paolo F Cantoni]

IOW you mean that EA should actually COPY the (currently inherited) tags whenever a Realization is created?

q.

My feeling is yes, but I'd like to discuss - because I might be implementing something in the future and I DO like to be consistent...

Of course, the problem of design-time management of changes in the supplier being propagated into the client needs to be addressed, but I have a pattern for that - I think.

Paolo

[qwerty]

Sounds reasonable. However - you know - I doubt you get Sparx to be consistent in this direction.

q.