"oils ain't oils" Is it the same TAG?

[Paolo F Cantoni]

I have a tag defined ONLY in my Profile.  I use the tag in two different metatypes.  Is it the same tag?  I don't mean instances of the same tag since they obviously are (and EA conveniently provides a structured GUID that says the two instances came from my profile - thanks to qwerty for identifying that).

Following advice from (Sparxian) Eve, I'm playing with having multiple stereotypes against an item.  Previously, we had a rule one metatype = one stereotype.  I'm testing out the concept that there is still one stereotype to define/identify the metatype, but there are supplemental stereotypes to "enhance" metatype with additional information.

I have a metatype "Organisation" which may or may not be a legal entity.  If it is not a legal entity, I want to add the property that references the legal entity to which it belongs.  So I created a supplemental stereotype "NOTLegalEntity" to which was attached the property LegalEntityReference (RefGUID). I created a simple Organisation and then added the supplemental stereotype and used the toolbox to "Synchronize Stereotype".  Lo and behold! The item gained the additional property!

Flushed with success, I decided to push my luck!  Organisation items have a property "IsLegalEntity" to managed whether it is or not.  In the Organisation metatype in the MDG, the value of the property is extrinsically set to «Uninitialized», the user has to set it to True or False as required.  It seemed to me that if I set the supplemental stereotype to "NOTLegalEntity" then I am explicitly setting the value of the "IsLegalEntity" to False!  So I set up the Tag in the supplemental stereotype to set the value to False.  [NOTE: I may not be using the correct syntax - but that's another story for the present].

I resynchronized the stereotype and EA said it added the Tag.  And that's what it did! 

I was expecting that EA would say "you already have a Tag "IsLegalEntity" which has a value, I'm NOT overwriting it!"  I was hoping EA would overwrite the default value with the value I supplied (False).  What I wasn't expecting was that I would now have two tags with name "IsLegalEntity", one with the value «Uninitialized», the other with the value False!  Obviously, EA is saying they aren't the same tag because (in the absence of any other instruction) they came from different stereotypes.  I can't really argue with that.   Some experimentation proves that the property GUID contains encoding to determine which value belongs to (not only which profile but also) which stereotype.

My question, therefore, is, from my user perspective, is there any syntax that I can provide that says the Tag I reference in "NOTLegalEntity" is the same Tag I created in "Organisation" in the MDG.  Since I can't decode the GUID, I can't write a process that would rectify things after the effect.

TIA,
Paolo

[EDIT:  I have now determined that, as many people have suggested, where you have multiple tags, EA will always return the first one it finds.  Thus, regardless of which stereotype the tag is actually assigned to, the shapescript will pick up (apparently) the first one it finds, even though conceptually (and physically) it is NOT assigned to that stereotype!  Sparxians, if you are going to encode the stereotype in the GUID then you need to use it to select the CORRECT ONE for the shapescript!]

[qwerty]

Well, I was always aware that picking a tag via TagByName gives you"some" tag, but never a defined one. Broken by design. And for sure you never see a fix. I got my own wrapper for that. Using non-unique tags in shape scripts is a no-no.

q.

[Paolo F Cantoni]

Well, I was always aware that picking a tag via TagByName gives you"some" tag, but never a defined one. Broken by design. And for sure you never see a fix. I got my own wrapper for that. Using non-unique tags in shape scripts is a no-no.

q.

(my emphasis) Not sure what you mean here q,
There is NO way a user can distinguish uniqueness at the script level.  In this case, they both have the same identifier externally <profile>::<tagname>.  As far as I'm currently aware, there is no user-accessible way to distinguish that the tag belongs to one stereotype or another.

Paolo

[qwerty]

Yes, you can't distinguish them. So you can't (meaningful) use them in shape scripts.

q.

[Eve]

My question, therefore, is, from my user perspective, is there any syntax that I can provide that says the Tag I reference in "NOTLegalEntity" is the same Tag I created in "Organisation" in the MDG.  Since I can't decode the GUID, I can't write a process that would rectify things after the effect.

If "NOTLegalEntity" and "Organisation" both inherit from an abstract stereotype that defines the property then it will be the same property and EA may not create a new tag.

Yes, you can't distinguish them. So you can't (meaningful) use them in shape scripts.

Actually, you can use the tag fully qualified name in a shape script.

Code: [Select]

shape main{
rectangle(0,0,100,100);
Println("#TAG:ProfileA::StereotypeA::PropertyA#");
}


[Paolo F Cantoni]

My question, therefore, is, from my user perspective, is there any syntax that I can provide that says the Tag I reference in "NOTLegalEntity" is the same Tag I created in "Organisation" in the MDG.  Since I can't decode the GUID, I can't write a process that would rectify things after the effect.

If "NOTLegalEntity" and "Organisation" both inherit from an abstract stereotype that defines the property then it will be the same property and EA may not create a new tag.

Yes, you can't distinguish them. So you can't (meaningful) use them in shape scripts.

Actually, you can use the tag fully qualified name in a shape script.

Code: [Select]

shape main{
rectangle(0,0,100,100);
Println("#TAG:ProfileA::StereotypeA::PropertyA#");
}


Thanks Eve,
It wasn't easy to find the documentation on fully qualified tag names. 

As we're still trying to transition to model based ^[1], how would that (abstract stereotype inheritance) look like in a "classic" MDG?

Also, assuming I can get the "same tag" working, will it work the way I wanted?  That is when I set the value in NOTLEgalEntity, it will overwrite the value in the original Tag?

Paolo
^[1]  Getting time and resources to transition is proving problematic when "It works OK now, doesn't it?" 

[Eve]

As we're still trying to transition to model based ^[1], how would that (abstract stereotype inheritance) look like in a "classic" MDG?

Create a stereotype. Set it as abstract. Create Generalization connectors to it from the stereotypes that you want to share a property.

Also, assuming I can get the "same tag" working, will it work the way I wanted?  That is when I set the value in NOTLEgalEntity, it will overwrite the value in the original Tag?

I'm honestly not sure what the exact behavior will be. What I don't think you'll be able to get is that the two concrete stereotypes use a different default value for the property.

[Paolo F Cantoni]

Thanks, Eve,

I can confirm the explicit syntax in the shapescript works.

As we're still trying to transition to model-based ^[1], how would that (abstract stereotype inheritance) look like in a "classic" MDG?

Create a stereotype. Set it as abstract. Create Generalization connectors to it from the stereotypes that you want to share a property.

I guess I'll have to create a mini MDG model and see what the generated output is and use that.  I was actually hoping for the XML output syntax...    I think the last time I tried this I don't think I set the "abstract" property correctly.  Can anyone share how it's done in the metamodel?

Also, assuming I can get the "same tag" working, will it work the way I wanted?  That is when I set the value in NOTLegalEntity, it will overwrite the value in the original Tag?

I'm honestly not sure what the exact behavior will be. What I don't think you'll be able to get is that the two concrete stereotypes use a different default value for the property.

What I'm really after is the ability to set a specific (rather than default) value via the MDG (accepting that if it IS now the same tag, you CAN'T have two defaults).  At present, I'm using the default="..." syntax to achieve this because profile property tags behave differently from generic tags with regard to "default" handling.  But I'm not after a default in the second case (NOTLegalEntity) I want to set it to an explicit value.  I take it there is no syntax to do that?  Do you (or anyone else) see the distinction as conceptually valid? If so, I'll pop in a feature request.

Paolo

[Paolo F Cantoni]

I decide to add a new post rather than edit the last one.

I managed to "bodgie-up" an abstract stereotype in our MDG from which both "Organisation" and "NOTLegalEntity" inherited.  I placed the property "ISLegalEntity" in the antecedent only.  I removed the properties (there were two) in the t_objectproperties table and performed a "Synchronize stereotype" on "Organisation" and "NOTLegalEntity".  Only one property was created although (interestingly) it appears in both places in the window (which is fair enough) and you can confirm it's only one property, by changing one and after some arbitrary events (like clicking away from the object on the diagram then coming back) the other rendering of the value becomes eventually consistent.  Also, I had to change the shapescript to reference the abstract stereotype (rather than the stereotype for which the script was defined) which is appropriate.

So, it would seem we have the potential of a very powerful mechanism, once we can directly set the value of the property from the MDG specification. Let's say the XML attribute syntax might be something like

Code: [Select]

<Tag name="<[profile::]<antecedant>::IsLegalEntity" require="False"/>.  The original property definition may set a default value or even an explicit value.  When I apply the descent stereotype EA would then set the value to that required by the stereotype.  If I play games behind the scenes and "fudge" the value to one not set in the stereotype, it would fail the Integrity/Validity check.  If I have more than one competing setting then that would also fail the Integrity/validity checks.

One could extend the concept.  One could restrict the value set of the original specification in the descendant stereotype.  This would allow the building of rigorous models fairly declaratively!

Thoughts?
Paolo

[Eve]

I misunderstood what you were after.

Code: [Select]

<Stereotype name="HasLegalEntity" notes="" isAbstract="true">
<TaggedValues>
<Tag name="IsLegalEntity" type="" description="" unit="" values="" default=""/>
</TaggedValues>
</Stereotype>
<Stereotype name="NOTLegalEntity" notes="" generalizes="HasLegalEntity" baseStereotypes="HasLegalEntity">
<AppliesTo>
<Apply type="Class"/>
</AppliesTo>
</Stereotype>
<Stereotype name="Organisation" notes="" generalizes="HasLegalEntity" baseStereotypes="HasLegalEntity">
<AppliesTo>
<Apply type="Class"/>
</AppliesTo>
</Stereotype>
Things like whether it would show up in both stereotype sets or not were the kinds of things I wasn't sure about the behavior.

Dealing with actually assigning values to those properties when applying a stereotype etc is another matter entirely. Even if the stereotyped defined a fixed value you have to specify precedence over any other values including what the user has set. I'd suggest you just treat it as a model validation exercise to ensure that when that stereotype is applied the corresponding value is correct.

[Paolo F Cantoni]

[SNIP]
Dealing with actually assigning values to those properties when applying a stereotype etc is another matter entirely. Even if the stereotyped defined a fixed value you have to specify precedence over any other values including what the user has set. I'd suggest you just treat it as a model validation exercise to ensure that when that stereotype is applied the corresponding value is correct.

Thanks, Eve,

That's more or less what I hand-crafted for the code.

I agree that assigning values via the MDG is "another kettle of fish".  However, as we have now shown, it is possible and I believe we are in the situation (as (reputedly) evinced by George Bernard Shaw - "Madam, we've established what you are.  Now we're discussing the price") of establishing a viable process.

It seems to me that we can use the inheritance mechanism to assist here.  Via our existing example, if we have the IsLegalEntity tag defined at the base stereotype thusly...

Code: [Select]

<Stereotype name="Legality" notes="" isAbstract="true">
<TaggedValues>
<Tag name="IsLegalEntity" type="Boolean" description="" unit="" values="True,False" default="«Uninitialized»"/>
</TaggedValues>
</Stereotype>
<Stereotype name="Organisation" notes="" generalizes="Legality" baseStereotypes="Legality">
<AppliesTo>
<Apply type="Class"/>
</AppliesTo>
</Stereotype>
<Stereotype name="NOTLegalEntity" notes="" generalizes="Organisation" baseStereotypes="Organisation">
<AppliesTo>
<Apply type="Class"/>
</AppliesTo>
<TaggedValues>
<Tag name="<profile>::OrganisationalLegality::IsLegalEntity" require="False"/>
</TaggedValues>
</Stereotype>
The inhertance path is: Legality <- Organisation <- NOTLegalEntity and so it can be argued that the precedence order of value assignment can follow that path.  In other words, when I apply the NOTLegalEntity stereotype to an Organisation, I'm explicitly saying that the IsLegalEntity value shall be set to "False".

Paolo