| Summary: | [Sequence diagram] when created a reply message the operations of the wrong lifeline are displayed | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] Papyrus | Reporter: | Mathieu Velten <mathieu.velten> | ||||
| Component: | Core | Assignee: | Thibault Landré <thibault.landre> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | agnes.lanusse | ||||
| Version: | 0.7.0 | ||||||
| Target Milestone: | SR1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Mathieu Velten
Patch proposed by Mathieu Created attachment 178733 [details]
use_case_reply
I changed back the behavior because I think the initial behavior is the correct one : a reply message represents the return of a function, then it should use an operation from the source lifeline. you can find attached a classic use case that was not possible to do anymore. OK this behavior is correct Actually, the reply message must be displayed with the return value of the operation called in the initial request. In the first implementation, you proposed to select an operation name and you displayed this name in the message. The right behavior is to display the return argument. In your initial implementation only the name of the operation was displayed without any return value, so it seemed that you were trying to call an operation of the part represented by second lifeline on the part represented by first lifeline. this is already done since yesterday. the current behavior is what you can see in the attachment. |