Community
Participate
Working Groups
Steps to reproduce: 1. Create an interface having one operation 2. Create a class 3. Create an interface realization relationship between the class and the interface 4. Create an interaction 5. Create a sequence diagram for the interaction 6. Create a gate in the sequence diagram 7. Create a property in the interaction of the class type 8. Create a lifeline using the property created in the previous step 7. Draw an asynchronous message from the gate to the lifeline in the sequence diagram, and try to select the operation from the interface The operation that was created in the interface should be accessible from the classifier point of view, however, it is not present in the drop down list when using option "Select existing element" for message creation in the sequence diagram. Previously described feature work correctly when a generalization relationship is used. However, UML 2.4.1 Superstructure clearly states (on page 89) the following: "An interface realization relationship between a classifier and an interface implies that the classifier supports the set of features owned by the interface, and any of its parent interfaces. For behavioral features, the implementing classifier will have an operation or reception for every operation or reception, respectively, defined by the interface. For properties, the realizing classifier will provide functionality that maintains the state represented by the property." Meaning that classifier must support behavioral features from the interface, i.e., they should be accessible when creating sequences.
I think this should be resolved as invalid. Interface realization does not imply inheritance: that is a function of the generalization relationship. The interface realization is a declaration by the realizing classifier that it fulfils the contract of the interface in some possibly language/implementation-dependent fashion. The UML specification goes as far as to offer an example of Java-specific semantics of interface implementation: a Property defined by an Interface may be realized by a Class as a getter/setter pair of Operations. The most obvious way for the realizing classifier to provide the features of the interfaces that it realizes is actually to re-declare them (use copy/paste to do that, if necessary). Note that in this regard Papyrus is consistent with the UML semantics as implemented by the Eclipse UML2 metamodel. In fact, Papyrus isn't doing anything here at all: it just uses the UML2 API to determine which features are inherited and, therefore, which operations are available to be message signatures in the interaction.
Ok, before you resolve it as invalid, consider the following: - IBM Rational Software Architect works exactly how I described it. It allows you to access behavioral features through an interface realization relationship. - Exactly as you described it, interface realization relationship is not the same thing as inheritance. Instead, interface realization notifies that a classifier must have behavioral features of the interface it is realizing. This means they can be used transitionally in other artifacts. In fact, UML specification says it quite clearly: "...implies that the classifier supports the set of features owned by the interface...". I'm kinda sad, because this issue literally makes Papyrus unusable for me.
Yes, other tools may offer different interpretations and/or more free-form diagramming capabilities. I think Papyrus is trying to implement the the UML specification as precisely (from a notational perspective) as the UML2 project does the semantics, but I'm not sure. That's why I didn't resolve the bug; I'll leave it to the Papyrus leaders to decide what to do with my input. :-)
Also, I'm not sure that the Operation that is the signature of a Message necessarily has to be a feature of the type of the receiving lifeline's represented element. In fact, when the message is of a signal sort, the signature is a Signal. That obviously isn't a feature of any type because the behavioral feature invoked by a signal is a Reception. I don't see any constraints on what the Operation signature of a Message is allowed to be ... So, it would seem reasonable that Papyrus should allow the selection of any operation that is featured in some way directly or indirectly by the type of the lifeline, including operations declared by realized interfaces.
IIRC, in the context of Realization, UML specifies that the realizing classifier must provide a "compliant/compatible" implementation, but doesn't necessarily have to implement a property with a property, or an operation with the same operation. So it must not be automatic, and requires more flexibility. An example of this (From the spec.) is that a Property from an Interface can be "Realized" with a getter and setter operation. Regarding operations however, the specification seems a little bit more restrictive (Once again, I didn't go into the details so I may be a little bit inaccurate here, or even completely wrong). Papyrus doesn't add (Or isn't supposed to) any constraint to the specification (Which most UML tools do, thus locking the user to a pre-defined methodology), and neither does it enforce models "correct by construction" (Because sometimes you don't want/need a valid model) However, what might be done in Papyrus is to implement some shortcuts/filters/helpers to help users achieve this easily, without forcing or preventing others from doing something different if they're not interested in such features or want a different abstraction mechanism.
