Aggregated Enumerations in Profile

[Knaldgas]

I'm trying to create a profile and have reached a bump.
I've created an Information stereotype extended from class metaclass.
Information stereotype has an attribute Sensitive of type class (ordinary class) which in turn contains 2 attributes of type enumeration (different enumerations).


Problem is that when loading the profile, Information stereotype does get the Sensitivity attribute shown, but the two enumerations do not have drop-down - They are just free text edit boxes.
I've added the same two enumerations directly to Information, and they have both drop-down selections.


How can structured tagged values containing enumerations retain their drop-down functionality?

I'm not to keen to create grouped tags, as Sensitivity is going to be used quite a few places.

[Geert Bellekens]

That is probably not possible currently.

If you have that same combo in multiple stereotypes, you might want to consider making an abstract stereotype that contains these (grouped) tags, and let the other stereotypes inherit from that.

Geert

[Knaldgas]

Thanks Geert,

Yes, that's an option for some of the fields.
Any solution if Sensitivity is going to be used several times? E.g. a Node could have Sensitivity on Logs, on Data storage and on Processing.

~Per

[Geert Bellekens]

Thanks Geert,

Yes, that's an option for some of the fields.
Any solution if Sensitivity is going to be used several times? E.g. a Node could have Sensitivity on Logs, on Data storage and on Processing.

~Per

I think I would implement that as just several different tags:
- Log Sensitivity
- Storage Sensitivity etc...

Another question is if you should.
Having that much fine grained properties on your model elements is a risk in it own right.
More often then not, there will be an initial initiative to fill in those properties, but I see that those tend to go stale very quickly.

And also, if there is so much data to be filled in, I often see that it's filled in the same for all categories.

What I sometimes propose in those cases is to set a single sensitivity property, and then have another property that indicates the most important category (logs, storage, processing) for wich the sensitivity is applicable.

Geert

[Knaldgas]

I've changed my approach a bit. I have now created a multiple stereotypes, and then let user add relevant stereotypes to their elements (DataType, Component, Node and Association).
Adding multiple stereotypes results in something close to what I want to achieve: grouping of tagged values in a way that allows identical identifiers across groups 

Is there a simple way to have a toolbox have a UML::Component (or something extended from it), but have multiple Stereotype appended to it (StereotypeEx)?

As to the question if it gets too fine-grained: Perhaps. This is a proof of concept, so the result may come to look very different.

[Geert Bellekens]

Using multiple stereotypes on a single element has it's own issues.

I personally avoid that at all costs. A lot of things don't work correctly with multiple stereotypes.

Geert

[Knaldgas]

Oh dear, YAEAB!?! - What am I up against with multiple stereotypes?

[Geert Bellekens]

Oh dear, YAEAB!?! - What am I up against with multiple stereotypes?

Not bugs per sé, but things that are simply nor forseen for multiple stereotypes.
What I can think about is:

- You can't use the field t_object.Stereotype anymore as it now contains one of the multiple stereotype names (and it might be any of them)
- Metatype determination becomes uncertain
- Shapescript might behave erratic, depending on the "order" of the stereotypes (although in UML there is no order)
- metamodel constraints will probably behave in weird ways
- the icon in the project browser/toolbox will be what?

As you can see there are many things that work just fine if you have only one stereotype, but might behave differently when there are multiple stereotypes.
You can offcourse try to take all of these into account, and use different "types" of stereotypes. (e.g. Full stereotype vs tagged value only stereotype) but it is a can of worms I'd rather avoid.

Geert

[Eve]

depending on the "order" of the stereotypes (although in UML there is no order)

I can't find any information in the UML spec about whether they are ordered or not. But there is some kind of ordering in the spec because if multiple stereotypes aren't applied they are displayed in an order.

- You can't use the field t_object.Stereotype anymore as it now contains one of the multiple stereotype names (and it might be any of them)

And you shouldn't be using it. The API allows access to the full list even if there are properties (on each object) to access that field.

- Metatype determination becomes uncertain

Always the first.

- Shapescript might behave erratic, depending on the "order" of the stereotypes (although in UML there is no order)

Metatype if it's defined and if not then the first.

- metamodel constraints will probably behave in weird ways

Not as far as I'm aware.

- the icon in the project browser/toolbox will be what?

For the project browser it's the metatype. For the toolbox it's a non-issue because a toolbox item can only have one stereotype.