Defining one Tagged Value in terms of another

[Paolo F Cantoni]

We are finding increasingly that we can define a structured Tagged Value (typically an enum) and re-use it in a number of places.  I'm not talking about using the same named tagged value in multiple elements - that's easy enough to manage.  I'm talking about using the same set of values (with effectively the same set of semantics) multiple times for the same element.  One example is  "Degree of Fit" - where the same enum values are used for three different types of "fit" (for the same element).  We have currently created three Tagged Values defined identically, but once they've been created the fact that they have the same enum literals and semantics is lost.

I couldn't see how to use one definition in multiple named tagged values.  Is there such a mechanism?

TIA,
Paolo

[Uffe]

Hi Paolo,


Not if you're using in-project-defined tagged value types (I don't think).

But if you're using a proper profile, the tagged value connector should let you do just that (I think). With the connector, you specify the tagged value's name as the connector's target role.

I haven't verified that this construct (multiple connectors between the stereotype and the tagged value type) works, but I remember testing a while back whether you could get the behaviour of a RefGuidList tagged value, as opposed to a RefGuid one, by setting a multiplicity on the tagged value connector -- and whaddyaknow, it worked!

So it's worth a try at least.

HTH,


/Uffe

[qwerty]

Just what Uffe said. The enum is defined in the profile and as such still existent. You can't change the enum base from a user perspective and thus it's preserved. You can not see the definition, but I guess one can live with that since you anyway need some documentary of your MDG which covers this fact.

q.

[Paolo F Cantoni]

Hi Paolo,


Not if you're using in-project-defined tagged value types (I don't think).

But if you're using a proper profile, the tagged value connector should let you do just that (I think). With the connector, you specify the tagged value's name as the connector's target role.

I haven't verified that this construct (multiple connectors between the stereotype and the tagged value type) works, but I remember testing a while back whether you could get the behaviour of a RefGuidList tagged value, as opposed to a RefGuid one, by setting a multiplicity on the tagged value connector -- and whaddyaknow, it worked!

So it's worth a try at least.

HTH,


/Uffe

Hi Uffe,

Could you (or anyone) post an example of the resultant MDG entries?  As I've mentioned before, we're editing the MDG directly.

Paolo

[Uffe]

Hi again,


Looks like I spake too soonly. The tagged value connector is not allowed between a stereotype and an enum in a profile model. Multiple connectors do work for the situation where you want multiple RefGUIDs of the same stereotype, though. I checked.

In the profile model, what you must do with enums is create an attribute in the stereotype and set its type to the enum type by selecting it in the attribute property dialog. If you do that, you can indeed create multiple tagged values with the same set of enum values.

However, what EA does in that case is duplicate the enum values in the stereotype definition. This might not be what you want, but I don't think there's a way around it. (RefGUIDs, by contrast, are defined as separate entities which are referred to from the stereotype definition, even in the XMI).

Here's a profile with one stereotype which has two RefGUID tagged values of the same type, as well as two enum tagged values of the same type. As you can see, the enum definition is simply duplicated for each tag.

Code: (XMI) [Select]

<?xml version="1.0" encoding="windows-1252"?>
<UMLProfile profiletype="uml2">
    <Documentation id="1464CA28-2" name="Prof" version="1.0" notes="Prof"/>
    <Content>
        <Stereotypes>
            <Stereotype name="SomeReference" notes="" cx="90" cy="70" bgcolor="-1" fontcolor="-1" bordercolor="-1" borderwidth="-1" hideicon="0">
                <AppliesTo>
                    <Apply type="Class">
                        <Property name="isActive" value=""/>
                    </Apply>
                </AppliesTo>
            </Stereotype>
            <Stereotype name="TheMainStereotypeWithAllTheStuffInIt" notes="" cx="90" cy="70" bgcolor="-1" fontcolor="-1" bordercolor="-1" borderwidth="-1" hideicon="0">
                <AppliesTo>
                    <Apply type="Class">
                        <Property name="isActive" value=""/>
                    </Apply>
                </AppliesTo>
                <TaggedValues>
                    <Tag name="Suitability" type="enumeration" description="" unit="" values="Spiceresque,Loose,Casual,Tailored,Body-hugging,Tight! Too tight! Argh gasp cough splutter" default=""/>
                    <Tag name="Fitness" type="enumeration" description="" unit="" values="Spiceresque,Loose,Casual,Tailored,Body-hugging,Tight! Too tight! Argh gasp cough splutter" default=""/>
                    <Tag name="refA"/>
                    <Tag name="refB"/>
                </TaggedValues>
            </Stereotype>
        </Stereotypes>
        <TaggedValueTypes>
            <TaggedValueType property="refA" description="" notes="Type=RefGUID;Stereotypes=SomeReference;"/>
            <TaggedValueType property="refB" description="" notes="Type=RefGUID;Stereotypes=SomeReference;"/>
        </TaggedValueTypes>
    </Content>
</UMLProfile>

Also note that the name of the enum type, which was "Degree of Fitness", doesn't make it into the XMI.

HTH,


/Uffe

[qwerty]

You beat me to a second here. Found out the same that the XMI just just the origin of the enum and expands it. So, Paolo, you should start stepping into creating profiles from EA models, rather than sticking to Profiler Assembler.

q.

[Paolo F Cantoni]

You beat me to a second here. Found out the same that the XMI just just the origin of the enum and expands it. So, Paolo, you should start stepping into creating profiles from EA models, rather than sticking to Profiler Assembler.

q.

I've got too big a "hump" to reverse engineer the MDG into a model.  If Sparx or anyone has an MDG file importer...

But, Uffe's reply isn't what I'm after...  We already have the equivalent of "Suitability" and "Fitness"

As I explained to the Sparxians, I'm more after:
DegreeOfFit (in the UML types in Repository or the <TaggedValueTypes> section of MDG)

Type=Enum; v1.0 8-Jun-2017
Values=Very Bad,Bad,Partial,Good,Very Good,«Unspecified»;
Default=«Uninitialized»;

Then in the MDG:

<Tag name="BusinessFit" type="DegreeOfFit"/>
<Tag name="TechnologyFit" type="DegreeOfFit"/>

That is, if the "type" is NOT one of the base types, and corresponds to an existing Tagged Value Name, use its definition...

Paolo

[qwerty]

That's what Uffe said. The relation in the XMI is lost. So you need to maintain that by hand if you don't have it in a model source.

Probably that's also a reason why there is no reverse engineering of XMI to a model.

q.

[OpenIT Solutions]

Hi,

You can do this I think. Have a look at the bpmn2.xml MDG in the sparx install folder for an example. If you just generate a 'profile' you may not get the xmi your after - I think you need to generate an MDG - as you need to define a <taggedvaluetypes> section

Regards,

Jon.

[Paolo F Cantoni]

Hi,

You can do this I think. Have a look at the bpmn2.xml MDG in the sparx install folder for an example. If you just generate a 'profile' you may not get the xmi your after - I think you need to generate an MDG - as you need to define a <taggedvaluetypes> section

Regards,

Jon.

Thanks, Jon,

that looks more like what I'm after.  I'll have a play with my MDG and see if it does what I need.  Not withstanding this possible solution, I think I'm still after the extension that if the TaggedValueType is NOT in the MDG, but in the general list, it should be available for reference also.

Paolo