Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 351391

Summary: [ClassDiagram] Actor is over-constrained
Product: [Modeling] Papyrus Reporter: yirco <netswengineer>
Component: DiagramAssignee: Patrick Tessier <Patrick.Tessier>
Status: ASSIGNED --- QA Contact:
Severity: normal    
Priority: P3    
Version: 0.10.0   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description yirco CLA 2011-07-07 03:31:11 EDT 
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))))
Comment 1 Yann Tanguy CLA 2011-07-07 04:24:00 EDT 
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 ?
Comment 2 yirco CLA 2011-07-07 07:29:43 EDT 
(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.
Comment 3 Camille Letavernier CLA 2013-05-06 14:13:07 EDT 
> 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).