Multiple stereotypes

[Uffe]

Hey gurus,


I'm looking at the manual and its discussion of multiple-stereotype settings in a profile.

What I would like to be able to do is kind of the opposite of what's described. I want to specify that an element should be allowed to use multiple stereotypes from one profile (preferably from a specific set of compatible stereotypes) but not stereotypes from any other profile. I'm thinking in terms of groups of tagged values here, sort of like interfaces in Java.

This isn't possible with EA's implementation: I can specify that an element is not allowed two stereotypes from the same profile, or from the same technology, or at all. But I can't specify that it is allowed two stereotypes as long as they're from the same profile.

Am I stupid?


/Uffe

[qwerty]

I always found it problematic to have an element with two stereotypes - though there are exceptions. On the one hand you have stereotypes that define "heavy" business relation. So the stereotype represents a business object. On the other hand you have more attributive stereotypes. E.g. I do have a <<To Be Done>> which I use to color elements for good reason. Question is: is that a legal application for a stereotype (thinking about it lets me tend more to a NO than a YES). What do the UML authors say? I probably need to read those chapters.

q.

[Geert Bellekens]

I think it's indeed not possible to limit the allowed stereotypes to certain combinations.

But I tend to limit myself to one stereotype per element. This is mostly for pragmatical reasons. It's much easier to query where t_object.stereotype = 'mystereotype' then to have to join t_xref for every item that could have a stereotype and try to filter out the correct stereotype from the description field.
I haven't really had the feeling this "one stereotype" dogma was holding me back somehow; never saw the need to add multiple stereotypes.

Geert

[Uffe]

I agree that multiple-stereotype elements are an oddity in general, and particularly so in EA.

But from a UML perspective, is the notion of restricting an element to having multiple stereotypes from the same profile only a silly one? This type of positive specification honestly makes more sense to me than EA's negative one.

/U

[Geert Bellekens]

I agree that multiple-stereotype elements are an oddity in general, and particularly so in EA.

But from a UML perspective, is the notion of restricting an element to having multiple stereotypes from the same profile only a silly one? This type of positive specification honestly makes more sense to me than EA's negative one.

/U

No, I don't think its a silly restriction; makes sense to me.

Geert

[KP]

You might consider making a new stereotype that specializes multiple stereotypes. It will inherit tagged values from all of them. Not ideal, but functional.

[Eve]

I always found it problematic to have an element with two stereotypes - though there are exceptions. On the one hand you have stereotypes that define "heavy" business relation. So the stereotype represents a business object. On the other hand you have more attributive stereotypes. E.g. I do have a <<To Be Done>> which I use to color elements for good reason. Question is: is that a legal application for a stereotype (thinking about it lets me tend more to a NO than a YES). What do the UML authors say? I probably need to read those chapters.

Yes, that's an absolutely valid way to use stereotypes in UML. With the way UML handles stereotypes, even your definitive stereotypes are attributive.

But from a UML perspective, is the notion of restricting an element to having multiple stereotypes from the same profile only a silly one? This type of positive specification honestly makes more sense to me than EA's negative one.

Not silly, but perhaps without precedent. UML doesn't have much to say about interaction between stereotypes, but I'm sure I've seen examples where a constraint was specified that only one of a set of stereotypes could be applied to a single element. The EA "profile" and "technology" strictness values allow you to specify a particular group of stereotypes are mutually exclusive. Effectively reasoning about the stereotypes that you know about. While "all" explicitly prevents you from using the UML extension mechanism for that language. (Personally, I would describe that as either short sighted or arrogant that you think you can define all the ways that end users will want to use your technology)

[Uffe]

You might consider making a new stereotype that specializes multiple stereotypes. It will inherit tagged values from all of them. Not ideal, but functional.

Yes, that's what I am doing. The problem with this approach is that it causes a combinatorial explosion of stereotypes.

But from a UML perspective, is the notion of restricting an element to having multiple stereotypes from the same profile only a silly one? This type of positive specification honestly makes more sense to me than EA's negative one.

Not silly, but perhaps without precedent. UML doesn't have much to say about interaction between stereotypes, but I'm sure I've seen examples where a constraint was specified that only one of a set of stereotypes could be applied to a single element. The EA "profile" and "technology" strictness values allow you to specify a particular group of stereotypes are mutually exclusive. Effectively reasoning about the stereotypes that you know about.

You can reason about stereotypes you know about, but only partially. You can only prohibit stereotype combinations (in the scopes profile, technology or global), you can't permit them. So I can't say "allow multiple stereotypes within this set of stereotypes that I know about", I can only say "prohibit multiple stereotypes within this set of stereotypes that I know about." That feels unnecessarily limited to me, which is why I wondered if that approach is mandated or indicated by the standard. It appears not.

Thinking out loud, I wonder if it wouldn't make sense to separate metaclass extensions from property sets. An EA stereotype represents both that my element type is a subtype of Actor, and that my element type has a certain set of tagged values. This concept could instead be split into Stereotype and, I dunno, PropertySet.

So property sets would act more like an OO interface which stereotypes would realize, while stereotypes would be more like classes in an inheritance hierarchy. Stereotypes would be concerned with what extended types are, property sets with what they have (both in terms of content and behaviour). I think this is somewhat similar to qwerty's light and heavy stereotypes.

Possibly a property set could be associated with a keyword, though I'm not sure whether the standard would allow that. But if it did, you could have stereotypes for things like subsystems and business roles, and keywords for things like organizational ownership (which could apply both to subsystems and business roles, but only those that are defined by our organization).

/U

[Geert Bellekens]

(Personally, I would describe that as either short sighted or arrogant that you think you can define all the ways that end users will want to use your technology)

I guess that depends on your perspective.

For a toolbuilder as yourself that seems valid.

But in my situation (which is similar to Uffe's I suppose) I usually develop such a UML Profile and MDG for a single client.
These clients usually want more of a whitelist situation, meaning that users are only allowed to use what is in the list.
The range of language constructs EA offers is way too broad for these clients. Even UML or BPMN have many things they never use, and never want anyone in the organisation to use.
Sometimes a certain construct it too generic and we want to make sub-types of it using our own stereotypes.
Together we choose a set of language constructs and rules, and then we materialize those using MDG technologies.

In that situation it totally makes sense to say you that the users may only combine stereotype X with stereotypes Y or Z without being arrogant or short sighted.

Geert

[qwerty]

What they said!

q.

[Paolo F Cantoni]

What they said!

q.

ibid

Paolo

[Eve]

Yes, I know that I don't directly engage with my end users in the way many of you do. I'm happy to be the person making the controversial statement. If I can encourage thought and conversation then it's a good result for me. I'll even admit that what's being asked for here, is an example of a way Sparx Systems restricts the ways you can use EA. Of course those decisions happen every day, it's just a fact of any development work.

Still, are you always going to be available to your clients to extend or update your work? How confident are you that your documentation about why you've made those decisions to limit such functionality will be fully understood by whoever has to maintain it in the future?

PS.

The range of language constructs EA offers is way too broad for these clients. Even UML or BPMN have many things they never use, and never want anyone in the organisation to use.

This is where I encourage strict perspectives again. You can force all users of a model to use a subset of the technologies that EA includes

[qwerty]

A little addendum. I was thinking about both, multiple stereotypes and stereotypes extending multiple metaclasses. The problem that came to me was the 2nd class citizenship of connectors. When you extend multiple metaclasses EA stores everything in the stereotype which should have gone to the connector (or they should have uses association classes). If you have shape scripts of other individual properties you can only put them in the stereotype. But of course you would treat a stererotype for one metaclass different to that for another one. So now you get a bad blend (good for the sink but not to create meta models). Same goes for assignement of multiple stereotypes (which might as well be an UML design issue). What happens if multiple stereotypes have the properties with the same name? Will they appear as duplicates? Will one dominate the other? Which shape script will take effect?

q.

[Eve]

But of course you would treat a stererotype for one metaclass different to that for another one.

A big if/else condition at the top level of your stereotype.

What happens if multiple stereotypes have the properties with the same name? Will they appear as duplicates? Will one dominate the other?

Very easy to see, even in old versions there was an option to see the fully qualified names. In recent versions they are grouped by the stereotype.

Which shape script will take effect?

EA only allows one, it prioritizes stereotypes that define a metaclass, then uses the first one it finds.

[qwerty]

But of course you would treat a stererotype for one metaclass different to that for another one.

A big if/else condition at the top level of your stereotype.

Will not work for diagram properties.

q.