If stereotype property type is metaclass, how ...

[Hendrik Jan van Randen]

Subject: If a stereotype property type is a metaclass, how can you for its tagged value select instances of that metaclass?


dear all,

I've defined a stereotype «crud» which extends metaclass 'Use Case'.
On this stereotype I've defined property 'maintains', of which the type is metaclass 'Class', with multiplicity 1..*.

When I apply this stereotype to a use case, I would expect that for the tagged value 'maintains' I can select one or more classes that I've defined in the same model.
Instead, in its value field I can type any text, as if the type of the defined property is 'string', and I cannot select any class for it.

What should I do to be able to select one or more classes for this property? I'm using Enterprise Architect version 7.0.817.

Hendrik Jan


P.S. To a certain extent a workaround is to define a stereotype «x» which extends metaclass 'class', and to define a 'tagged value' relationship named 'maintains' from «crud» to «x», with target role multiplicity 1..*.
However, this workaround has the following disadvantages:
1. For the tagged value 'maintains' you can select only one class, thus the multiplicity definition is apparently ignored.
2. It is ugly and inconvenient that you have to apply stereotype «x» to a class in order to make it selectable in the 'maintains' property.

[KP]

Hello Hendrik,

Search the EA help file for "RefGUIDList" - you should find exactly one page which discusses creating your own predefined tagged value types. You will need to create a tagged value type with the following:

Type=RefGUIDList;
Values=Class;

[Hendrik Jan van Randen]

Thank you for your suggestion, this works fine to a certain extent if I define such a tagged value type in the project in which I want to apply the mentioned stereotype.

However, the following issues remain:

1. In this way I have to redefine this tagged value type (and my other similar tagged value types) manually in each project in which I want to apply my profile. That's too much repeating work. How can I define such tagged value types in my profile project, so that they can be exported and imported with the profile? (If I define the tagged value types in my profile project, and export-import the profile to another project, the tagged value types are currently not available in that other project.)

2. How can I restrict the elements on which users can give this tag a value? (In my example I want to restrict that to «crud» use cases.)

3. How can I, for the elements (in the example «crud» use cases) on which this tagged value type applies, show the tag automatically in the Tagged Values pane? Now users for each «crud» use case have to click the 'New Tag' button and select the 'maintains' tag from a long list of possible tags.

These issues would all be resolved if the type and multiplicity of the stereotype-property-definition described in the first paragraph of my original scenario would result in a corresponding tagged value type definition in the projects that use (thus import) the profile. What can I do to accomplish that?

with kind regards,

Hendrik Jan van Randen

[«Midnight»]

Hendrik,

1) Try exporting these as reference data and importing them into your new project.

2) Not sure, but look around to see if there is something analogous to the RefGUIDList, but relating to where you can apply the tag.

3) Not sure. This used to work - at least it did when I last tried it with EA 6.x. You should see the tag, set either to a bland value or a default. In the case of a list you will be presented with a drop-down from which you can select (only) from the defined values.

Check the example Sparx gives. I did so back in the 6.x days, and when I followed the same pattern things started to work for me.

HTH, David

[thomaskilian]

2) AFAIK not possible

3) You can write an add-in to do that. There was a quite recent post in the automation board (will try to find it).
http://www.sparxsystems.com/cgi-bin/yabb/YaBB.pl?board=Automation;action=display;num=1192561628

[KP]

1. In your profile, give the <<stereotype>> element an attribute with the same name as the tagged value type.

2. User education? Alternatively, you can write an add-in to perform model validation. Search the help file for ""Model Validation Broadcasts" and "Model Validation Example".

3. See my answer to 1.

[«Midnight»]

Thanks for clearing those up Neil; I was sure it was there someplace

For validation, how far can one get through writing custom rules? If these would work it might save writing an add-in for this task.

David

[KP]

For validation, how far can one get through writing custom rules? If these would work it might save writing an add-in for this task.

At the moment, writing an add-in is the only way to perform custom validation. A long-term goal of ours is to have OCL constraints evaluated in real-time so you could prevent, for example, attaching that connector to this element, or dropping an operation or attribute or tagged value on some other type of element (that would solve Hendrik's question 2). That's some way in the distant future though.

[Eve]

2) At the bottom of http://www.sparxsystems.com.au/EAUserGuide/index.html?predefinedtaggedvaluetypes.htm is where you can filter where a tag can be applied.

Note that it doesn't prevent a tag of that name being applied, but it won't appear in the list of possible tags and it won't have the type that was specified for the tag.

[Hendrik Jan van Randen]

Thank you all for your suggestions! I've done some experiments, which show the following concerning point 1:

> In your profile, give the <<stereotype>> element an
> attribute with the same name as the tagged value type

Giving the stereotype a «tagged value» relationship with the same name brings the tagged value to the export file (an attribute doesn't).
This however doesn't export the details field of the tagged value type from the UML Types. I can workaround that by copy-pasting "Type=Classifier;Stereotypes=persistent;" from that details field into the notes attribute in the export xml file, but that is (of course) overwritten when I re-export the profile (e.g. after adding new stereotypes to it).

All together it would be a lot easier if issues 1, 2 and 3 would all be derived automatically from the stereotype attribute type and multiplicity, now it is a lot of manual work.