Community
Participate
Working Groups
Creating a message from the palette in a sequence diagram results in showing a message wizard, asking for already existing signals, operations etc. The dialog is not implemented as I have expected it, since it does not show the operations that are provided by interfaces being referenced as provided interfaces of ports of the type of the connectable element, representing the lifeline. See tge pseudo-code below for better representation: Interface2{ op1() } Component1{ port1: Interface2 } Collaboration{ part_1: Component1 Interaction{ lifeline1 : represents part1 (of Type Component1){ //should offer op1 via port 1 via Interface1 } } } For signal messages, the situation is a little different. There, all signals available in the model are listed as potential signals for the message. This might be helpful to support high level modelling, but for technically mature models, only those signals should be listed, which are receivable by the receiving lifeline. Therefore, I'd recommend to integrate a filter meachnism allowing the users to filter out all signals which are not receivable by the type of the receiving lifelin.
Precisely, we need to add: 1. An option in the Preferences, the default value is off 2. A check box to enable/disable the filter in the wizard dialog.
Created attachment 220646 [details] Bugfix
patch committed on the branch 0.9.X r.8881
The filter out signals option removes all signals from the list, even signals referenced by receptions on the class which types the lifeline representation property, which shouldn't be the case.
Created attachment 220673 [details] bugfix display more signals from property type of lifeline representation
patch committed on the branch and the trunk .r8937
The patch doesn't solve the problem. Signals declared as reception still don't appear on the list when the filter is active.
Actually, the best solution would be to outsource the entire dialog into an extension point. User would be able to implement their own dialog with their own functionality. When creating a message, a context menu could appear (similar to the creation of IngoreConsiderFragment) and the corresponding dialog would be opened. This would allow to provid a default dialog by Papyrus but also to provide a tailored one, if necessary.
What is "Signals declared as reception"? I may not understand your situation. It would be better if you can provide the test project files, and provide some explanation. (In reply to comment #7) > The patch doesn't solve the problem. Signals declared as reception still > don't appear on the list when the filter is active.
Created attachment 221336 [details] Signal Reception Here is a model with a signal reception declared for class2. For a message incoming to Class2 lifeline, when the "filter out signals that are not receivable" is checked, Signal1 should be available because it has been declared receivable by Class2. Signal2 should be filtered because it has not been declared receivable.
Created attachment 221395 [details] bugfix
Patch committed.
closed
(In reply to comment #13) > closed Sorry, but I still do have the same problem in Kepler nightly build (19th February). I checked the code and the patch has been incorporated, however, I still do not get listed the operations provided by an port that is typed by an Interface. Neither the operations are listed, nor the filtering mechanism for the signals works as expected. Furthermore, I think the patch is not sufficient. What would happen if the port is typed by an Component that has an InterfaceRealization to an Interface? These operations should be offered by the Port as well, currently, only the owned Operation by the Type (and its super classes) of that Port would be listed (see CommandHelper.gestExeistingElementsFromParents, line 398). What is missing is the inclusion required interfaces of a Port as well. Insert the follwoing code after line 411 in CommandHelper p.getRequireds().getAllOperations(); p.getRequireds().getOwnedReceptions() //also the Reception owned by super interfaces.... there is not convenience methods for this in UML2 What I could offer is to write an exhaustive algorithm to determine the invokable features on the receiving lifeline. Would this be appreciated?!
The current master branch (oxygen release) does not yet provide dialog boxes or other mechanisms for choosing message signature (see Bug 507349) When the feature is made available again, we'll see if this bug is still valid. By the way, if the bug is valid, I am not sure it is specific to the sequence diagram.
I guess as already mentioned in Comment 14, this should be generalized to also cover InterfaceRealization as well. I just tried (using the latest build on Nenon) the case where the lifeline represents a Class which have an InterfaceRealization to an Interface, which in its turn have some Operation and Reception. None of these is available for selection. The same goes for ports which are typed by some Classifier which in its turn have InterfaceRealization and Usage relationships. In this case also the isConjugated property of the port needs to be considered regarding what is available for selection, i.e. either what is provide by the InterfaceRealization or the Usage.
