Community
Participate
Working Groups
According to UML 2.2 1) An actor can have operations because it inherits from BehavioredClassifier and it inherits from Classifier which can have features. 2) An actor can have associations also to components and classes. It is not allowed by Papyrus. The consequence is that it is not possible to model the behavior of a use case using an interaction between actors and the subject (component or class) of the use case. Generalizations • “BehavioredClassifier (from BasicBehaviors, Communications)” on Constraints [1] An actor can only have associations to use cases, components, and classes. Furthermore these associations must be binary. self.ownedAttribute->forAll ( a | (a.association->notEmpty()) implies ((a.association.memberEnd.size() = 2) and (a.opposite.class.oclIsKindOf(UseCase) or (a.opposite.class.oclIsKindOf(Class) and not a.opposite.class.oclIsKindOf(Behavior))))
1) An actor can have operations because it inherits from BehavioredClassifier and it inherits from Classifier which can have features. -> You should report this to MDT "UML2" component. 2) Can you describe precisely the concerned diagram from your point of view ?
(In reply to comment #1) > 1) An actor can have operations because it inherits from BehavioredClassifier > and it inherits from Classifier which can have features. > > -> You should report this to MDT "UML2" component. > > 2) Can you describe precisely the concerned diagram from your point of view ? In my opinion it concerns the class diagram. First it is necessary to create operations and associations between actors on one side and the subject (e.g. a component) on the other side. If this is allowed on the class diagram then it is possible to create an interaction owned by a use case and draw a sequence diagram showing the message exchange between actors and the subject. I didn't look at MDT UML2. I will try to find out whether the relationship is already disallowed in the MDT UML2 metamodel. It could be so.
> 1) An actor can have operations because it inherits from BehavioredClassifier and it inherits from Classifier which can have features. Nope. Classifier can indeed have Features, and Operation is a Feature. But Classifier#feature is derived. A Classifier by itself doesn't have features. Each sub(meta-)class of Classifier has to (re)define its features. And Actor doesn't redefine anything related to Operations. An Actor can however contain a Behavior (Which might indirectly "call" an Operation). Operations do not appear at a more abstract level than Class or Interface. > 2) An actor can have associations also to components and classes. Indeed. However, the Actor cannot own its association end, as it cannot contain Properties (It is not a StructuredClassifier). So that's a restricted kind of Association, which may currently not be properly supported (Especially in the Properties view).
