Tagged values from multiple stereotypes completely mystifies EA

[Uffe]

Hi all,


I'm working on a profile with a bit of complexity to it, where I want reusable groups of tagged values which I can combine in different ways in my concrete stereotypes.

So I've set up some abstract stereotypes with attributes, which include some Const tagged value types which I have to configure into the MDG source project, and some others which are Booleans or enums defined in the profile. I don't have any tagged-value connectors as yet.

I then combine these abstract stereotypes (which don't extend any metaclasses) into concrete stereotypes which do extend metaclasses. I can't specify tag groupings per abstract stereotype because EA only allows one metaclass per stereotype (it silently ignores any others, and there is obviously no documentation that either mentions this or details the criteria by which The One Metaclass is selected), but I'll just have to deal with that.

But here's the thing.

I create my concrete stereotype and its lone metaclass (a Class, to be precise), and specify the tag groupings in that (which I have to do manually because the profile helper doesn't check for the attributes described in the parent classes even though they certainly get included when the profile is generated but I guess that arbitrary limitation is documented too somewhere aaaaaaand not so much). I generate the profile (from the package) and the technology.

I go into my test project, create an element with my new stereotype and look at its properties.

They are grouped perfectly well in the order I want.

If I look in the properties window.
In the properties dialog, they are instead grouped by abstract (generalized) stereotype. The tag groupings I've specified in my concrete stereotype are completely ignored.

Why in all the nine circles of hell would anyone want this?

Are you seriously telling me that I have to define every single -- closely-related but slightly different -- stereotype with its complete set of tagged values independently from all the others in order to get EA to display them correctly? Whatever happened to object-oriented design?

How does Sparx deal with this in its technologies, like BPMN etc? There's got to be some similarities there with what I'm trying to do.
Or do they simply override the default properties dialog with customized ones so they can ignore this idiotic design and leave the rest of us toolmakers hanging?


/Uffe

[Uffe]

By the way, the tag groupings in the property dialog are taken from the metaclass, as intended, but they are repeated for each abstract stereotype even though each grouping is only relevant in one of those abstract stereotypes, and even though the abstract stereotypes do not extend the metaclass where the groupings are defined. So there's an enormous amount of irrelevant repetition which I can't get rid of.

So in the dialog it looks like this:
AbstractStereotype1 (<element_name>)
    Tag group 1
        Tag 1:1
    Tag group 2 (looks expandable but isn't)
    Tag group 3 (looks expandable but isn't)
    Tag group 4 (looks expandable but isn't)
    Tag group 5 (looks expandable but isn't)
AbstractStereotype2 (<element_name>)
    Tag group 1 (looks expandable but isn't)
    Tag group 2
        Tag 2:1
        Tag 2:2
    Tag group 3 (looks expandable but isn't)
    Tag group 4 (looks expandable but isn't)
    Tag group 5 (looks expandable but isn't)
AbstractStereotype3 (<element_name>)
    Tag group 1 (looks expandable but isn't)
    Tag group 2 (looks expandable but isn't)
    Tag group 3
        Tag 3:1
        Tag 3:2
        Tag 3:3
        Tag 3:4
        Tag 3:5
    Tag group 4 (looks expandable but isn't)
    Tag group 5 (looks expandable but isn't)
AbstractStereotype4 (<element_name>)
    Tag group 1 (looks expandable but isn't)
    Tag group 2 (looks expandable but isn't)
    Tag group 3 (looks expandable but isn't)
    Tag group 4
        Tag 4:1
        Tag 4:2
        Tag 4:3
        Tag 4:4
    Tag group 5 (looks expandable but isn't)
AbstractStereotype5 (<element_name>)
    Tag group 1 (looks expandable but isn't)
    Tag group 2 (looks expandable but isn't)
    Tag group 3 (looks expandable but isn't)
    Tag group 4 (looks expandable but isn't)
    Tag group 5
        Tag 5:1
        Tag 5:2


By contrast, the property window shows the same set of tags for the same element with the same stereotype like this:
ConcreteStereotype ( from <profile_name> ) (Which is what the user sees everywhere else in the GUI; the abstract stereotypes are never shown except for in the tagged values tab of the properties dialog)
    Tag group 1
        Tag 1:1
    Tag group 2
        Tag 2:1
        Tag 2:2
    Tag group 3
        Tag 3:1
        Tag 3:2
        Tag 3:3
        Tag 3:4
        Tag 3:5
    Tag group 4
        Tag 4:1
        Tag 4:2
        Tag 4:3
        Tag 4:4
    Tag group 5
        Tag 5:1
        Tag 5:2


/U

[Uffe]

I found a workaround for this second problem.

1) Create a single abstract stereotype which holds the generalizations from the multiple abstract tagged-value-group stereotypes, and also has the extends to the lone metaclass.

2) Draw a single generalization from the concrete stereotype to this new "proxy" abstract stereotype.

With this solution, EA will only apply the tag groupings once in the properties dialog. It still ignores the tag groupings, but it doesn't stupidly repeat them, as it does when the concrete stereotype has multiple generalizations. (Yes, it is weird that EA simultaneously ignores and applies the tag groupings in one and the same window. Anything else I can help you with?)

The properties window still presents the tag groupings correctly. It even works with multiple concrete stereotypes each with a single generalization to the "proxy" stereotype. (No reason why it wouldn't, but then... EA.)

So with this solution the properties dialog presents the tagged values like this:
AbstractStereotype1 (<element_name>)
    Tag S1:1
    Tag S1:2
    Tag S1:3
AbstractStereotype2 (<element_name>)
    Tag S2:1
    Tag S2:2
AbstractStereotype3 (<element_name>)
    Tag S3:1
AbstractStereotype4 (<element_name>)
    Tag S4:1
    Tag S4:2
    Tag S4:3
AbstractStereotype5 (<element_name>)
    Tag S5:1
    Tag S5:2
    Tag S5:3
    Tag S5:4
    Tag S5:5

The property window presents the same tagged values like this (as before):
ConcreteStereotype ( from <profile_name> )
    Tag group 1
        Tag G1:1
    Tag group 2
        Tag G2:1
        Tag G2:2
    Tag group 3
        Tag G3:1
        Tag G3:2
        Tag G3:3
        Tag G3:4
        Tag G3:5
    Tag group 4
        Tag G4:1
        Tag G4:2
        Tag G4:3
        Tag G4:4
    Tag group 5
        Tag G5:1
        Tag G5:2


So. The properties window presents the tagged values grouped as specified in the metaclass (note that this grouping is independent of which stereotype defines which tagged value); the properties dialog presents them grouped by stereotype (case A).

If a concrete stereotype has multiple generalizations to other stereotypes, the properties window still presents the tag groupings correctly, but the properties dialog now applies the tag groupings once for each generalized stereotype (case B, shown in previous post).

If a concrete stereotype has a single generalization to a stereotype which in turn has multiple generalizations, the dialog presents the tags as in case A.

Case A is still bad, but it's not as much of a horrorshow as case B. So the toolmaker can apply Yet Another EA Kludge, prepare their answers to the users' inevitable questions, and live to fight another day.

Mind you, I haven't tested how any of this works when you start applying metaconstraints to this mess. Won't that be fun to find out.


/Uffe

[Eve]

Sounds like all you are describing is that the properties dialog groups properties by the superclass they come from while the docked window doesn't. Up until the properties window moved profile properties into the main page they were always grouped by the stereotype where they were defined.

Unfortunately, there are still people that are resisting the change. (They probably don't use grouping) The dialog is a concession to those people.

[Uffe]

Unfortunately, there are still people that are resisting the change. (They probably don't use grouping) The dialog is a concession to those people.

People suck.