Changing Stereotypes from the toolbox

[Paolo F Cantoni]

On the Diagram Toolbox Help Page (file:///C:/Program%20Files%20(x86)/Sparx%20Systems/User%20Guide/modeling_tools/objecttoolbar.html) Notes section it mentions changing the stereotype of an unstereotyped item by [Ctrl+Drag] from the Toolbox onto the existing item.

If you do this for an ALREADY stereotyped item the behaviour seems to vary depending on the metatypes (both type and stereotype) involved.  My users are getting quite confused and annoyed with the (wait for it...) inconsistency.

Can anyone (especially a Sparxian) provide any insight into how this works?

TIA,
Paolo

[qwerty]

As I see it, this was meant to be used on not stereotyped elements only. As usual, the missing test department is sitting at the user's site.

q.

[Eve]

It depends on the values for strictness defined for both stereotypes.

See http://sparxsystems.com/enterprise_architect_user_guide/13.0/modeling_tools/restricting_application_of_mul.html

I don't use the keyboard shortcut for holding control. It's easier to select what I want from the pop-up if you don't hold anything.

It also won't apply at all if the item being dragged is is for a different base type, meaning it can't be applied to that element.

[Paolo F Cantoni]

It depends on the values for strictness defined for both stereotypes.

See http://sparxsystems.com/enterprise_architect_user_guide/13.0/modeling_tools/restricting_application_of_mul.html

I don't use the keyboard shortcut for holding control. It's easier to select what I want from the pop-up if you don't hold anything.

It also won't apply at all if the item being dragged is is for a different base type, meaning it can't be applied to that element.

Thanks, Simon,

We have decided that we don't want multiple stereotypes at all, so we should set the "strictness" to "all"?

I veer toward qwerty's view that this functionality (dragging from the toolbox) was not designed to replace an element of one stereotype with another stereotype.  Are you able to comment on that?

Notwithstanding the original design, it seems to me that now that we are in the world of "metatypes", the functionality should allow the replacement of one metatype with another (even changing the underlying type - with appropriate checks).

What do others think?  I want to make things as frictionless as possible for my users.  If a previous user has incorrectly metatyped an element a subsequent user should be able to fix it by dragging the right one from the toolbox.

I'm happy to create a feature request.

Paolo

[Eve]

We have decided that we don't want multiple stereotypes at all, so we should set the "strictness" to "all"?

Yes. To me, that would mean that your stereotypes are equivalent to replacing the base UML type with a new type that doesn't allow stereotypes to be applied.

I veer toward qwerty's view that this functionality (dragging from the toolbox) was not designed to replace an element of one stereotype with another stereotype.  Are you able to comment on that?

It exists only to modify the stereotypes of an existing element. Depending on the type of element, the stereotype(s) already applied an the one being dropped it will provide the option of replacing the existing stereotype, adding the new stereotype or adding a new element with that stereotype.

Notwithstanding the original design, it seems to me that now that we are in the world of "metatypes", the functionality should allow the replacement of one metatype with another (even changing the underlying type - with appropriate checks).

Doing this would end up with users accidentally violating every rule in UML or a user domain and likely corrupt all the other usages of that element. (I'm strongly against such a proposal)

[Paolo F Cantoni]

Notwithstanding the original design, it seems to me that now that we are in the world of "metatypes", the functionality should allow the replacement of one metatype with another (even changing the underlying type - with appropriate checks).

Doing this would end up with users accidentally violating every rule in UML or a user domain and likely corrupt all the other usages of that element. (I'm strongly against such a proposal)

They've already done that...  We're looking for a way to fix it with minimum friction.  We've already (using security) determined who is allowed to make changes.

From our perspective, allowing one to change the stereotype and not allowing to change the type (as I said - with appropriate checks), is unnecessarily restrictive.  WE see NO semantic difference in the outcome.

Paolo