| [Solved] How to set return type of operation? [message #963042] |
Mon, 29 October 2012 14:26  |
 Robert Wloch
Messages: 109
Registered: July 2009 |
Senior Member |
|
|
I was wondering how one is supposed to set the return type of operations in class diagrams in Papyrus 0.9.1?
Steps to reproduce:
1. Create new Papyrus UML project with class diagram.
2. In the diagram create class "Foo" via palette's "Class" tool.
3. Add operation "bar" via palette's "Operation" tool.
4. Select operation "bar" and go to "UML" tab in properties view
Expected: Can set the return type with an appropriate editor.
Found: No editor for return type.
5. Go to tab "Appearance". There's a checkbox for showing the return type and it is checked. So I suppose one should be able to set the return type.
6. Go to tab "Advanced" and scroll down to "type". Double clicking the cell editor has no effect.
7. Open the menu of the property view and "Customize Papyrus Properties View".
8. Make a copy of the "UML" configuration.
9. Edit that copy.
10. Filter for "SingleOperation"
11. Have a look at how the "name" property editor is configured and do the same for the SingleOperation.type property.
12. Save the modified configuration.
13. Go to Papyrus preference page -> "Properties View" and disable the original "UML" properties view and enable the modified copy.
14. Go back to the class diagram, select something else and a different tab in the properties view then select the operation "bar" again.
15. Go to the "UML" tab and find the new property editor for "type" but it is disabled.
So first of all: Big compliment for such an extraordinary configurable properties view! That's just frelling awesome! 
Second: Is there a way to edit the return type of an operation or is it a bug?
Regards,
Robert
Edit:
I thought I could out smart the property editor by manually editing the UML file with a text editor and just append the "type" attribute from a property I created as a template didn't work. Papyrus wouldn't event load the model anymore after that although the id of the type is valid as it's used in the property already.
Also, editing the UML model with the sample reflective ecore editor had the same result as step #6 above.
[Updated on: Tue, 30 October 2012 06:49] Report message to a moderator |
|
|
|
|
| Re: How to set return type of operation? [message #964357 is a reply to message #963973] |
Tue, 30 October 2012 13:04  |
|
On 2012-10-30 06:48:54 +0000, Robert Wloch said:
> Thanks for the clarification I never thought the return value would be
> a parameter.
It used to be even better than that: an earlier UML 2.x revision
permitted *multiple* return parameters, which actually several modern
programming languages implement. But that made the operation's type
rather ambiguous (perhaps OCL would have interpreted it as an anonymous
TupleType, but UML doesn't have such construct).
|
|
|
|
| Re: How to set return type of operation? [message #965157 is a reply to message #964742] |
Wed, 31 October 2012 02:59 |
|
Hi, Ed.
"Yep" on all counts.
Although, for this particular case, I think UML actually has a
constraint (since 2.2?) that an operation must have not more than one
return parameter. Formerly, when there was more than one return, the
operation type was constrained to be unset.
cW
On 2012-10-30 19:14:23 +0000, Ed Willink said:
> HI
>
> UML also allows any number of 'out' or 'inout' parameters. These lack
> coherent OCL syntax or semantics.
>
> Since OCL has no assignment support, I guess that an anonymous Tuple is
> unavoidable to increase the connectivity of the normal anonymous
> 'result'.
>
> UML doesn't have any nested Collection types either. Both UML and OCL
> have a bit of mutual catching up to do.
>
> Regards
>
> Ed Willink
>
> On 30/10/2012 13:04, Christian W. Damus wrote:
>> On 2012-10-30 06:48:54 +0000, Robert Wloch said:
>>
>>> Thanks for the clarification I never thought the return value would be
>>> a parameter.
>>
>> It used to be even better than that: an earlier UML 2.x revision
>> permitted *multiple* return parameters, which actually several modern
>> programming languages implement. But that made the operation's type
>> rather ambiguous (perhaps OCL would have interpreted it as an anonymous
>> TupleType, but UML doesn't have such construct).
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02272 seconds
] 
Search
Help
Register
Login
Home
