Nesting inside interactions is not possible – and, consequently, nor try-catch

[José Farinha]

As classifiers, interactions should be allowed to have nested classifiers.
(The same for state machines, but these are less prone to require nested classifiers.)

For instance, it is rather frequent to have an interaction decomposed into several sub interactions. As much as an activity being decomposed into sub activities. Sub interactions should be nested inside their parent interaction, for the sake of model organization. But also to achieve some modelling purposes that can’t be done otherwise. E.g., I use nested interactions stereotyped by «catch» to model exception-catching blocks. Such blocks’ scope can’t be specified otherwise, since UML doesn’t provide any other construct for that.

As classifiers, interactions (and state machines) should be allowed to have inner classifiers of all types: interactions, classes, activities, etc. Apparently, EA only allows ports inside interactions.
I guess this is a bug. At least it is a non-conformity with UML.

[Geert Bellekens]

I think you are correct.
Have you reported an official bug?
That is the only way to make sure it gets on the backlog of Sparx development.

Geert

[José Farinha]

Thanks, Geert.
Not yet. Before I submit a report, I like to post it here, just to check that I'm not missing anything.
Replies like yours help, thanks.
Best regards.

[qwerty]

If I interpret the definition in UML 2.5 correctly an Interaction is Behavior and not a PackagableElement and as such you can not nest things. In contrast, Classifier is a NamedElement. So the implementation in EA seems to be correct.

q.

[Eve]

I agree that UML allows the behavior being described. But being a Classifier is not what provides that ability.

Interaction Generalization Tree
Interaction --> Behavior --> Class --> BehavioredClassifier

BehavioredClassifier Association Ends
ownedBehavior : Behavior [0..*]{subsets Namespace::ownedMember} (opposite A_ownedBehavior_behavioredClassifier::behavioredClassifier)
Behaviors owned by a BehavioredClassifier.

My interpretation is that it shouldn't be treated as a nestedClassifier from Class. Although that's based on the English description (The Classifiers owned by the Class that are not ownedBehaviors) not a formal constraint. In terms of EA behavior it makes no difference because they are both a subset of Namespace::ownedMember)