Direction in operation parameters

[philchudley]

Hi All

Just curious as to why EA insists on representing the parameter directions of in, out, inout and return incorrectly?

I my opinion the direction should be stated explicitly as shown in the generic example below:

+ myOperation(in para1 : String, out para2 : String, inout para2 : String, return String)

in of course can be omitted as it is the default (correct in EA)
out is represented incorrectly by * after the parameter name
inout is represented incorrectly by * after the parameter name
return is omitted (just like in) also incorrect

I am more concerned about out an inout, particularly in a Platform Independent Model.

Any thoughts as to divergence from the UML spec?

Phil

[Uffe]

Hi Phil,


From what I can read in UML 2.5, 9.4.4 Notation, you are indeed correct.

A Parameter is shown as a text string of the form:
<parameter> ::= [<direction>] <parameter-name> ’:’ <type-expression> [’[’<multiplicity-range>’]’]
          [’=’ <default>] [’{’ <parm-property> [’,’ <parm-property>]* ’}’] where:
    · <direction> ::= ’in’ | ’out’ | ’inout’ (defaults to ’in’ if omitted).
    · <parameter-name> is the name of the Parameter.
...

I don't think the C-flavoured '*' notation can be derived from that; 'in', 'out' and 'inout' are literals which in this clause may be omitted, but not augmented or replaced.

Mind you, the sales blurb for EA doesn't say "UML 2.5 compliant", it says "Based on UML 2.5 - plus", which means about as much as it does in Hollywood's "Based on a true story."

Certainly the star notation takes up less space in diagrams, but you can't really make that argument without the corollary "and anyway the standard is only a recommendation."

A shave and a haircut, my good man.


/Uffe

[Geert Bellekens]

Hi All

Just curious as to why EA insists on representing the parameter directions of in, out, inout and return incorrectly?

I my opinion the direction should be stated explicitly as shown in the generic example below:

+ myOperation(in para1 : String, out para2 : String, inout para2 : String, return String)

in of course can be omitted as it is the default (correct in EA)
out is represented incorrectly by * after the parameter name
inout is represented incorrectly by * after the parameter name
return is omitted (just like in) also incorrect

I am more concerned about out an inout, particularly in a Platform Independent Model.

Any thoughts as to divergence from the UML spec?

Phil

Look who's dotting the I's and crossing the T's now

I'm sure if Simon reads this he'll make sure EA follows the UML syntax to the letter.

Geert

[Eve]

Not that easy unfortunately.

Changing this rendering would make the operation description wider, which would in turn impact the size of the containing class and result in a lot of "furious" users because we have "destroyed" all of their hundreds/thousands of diagrams.

Technically, a return parameter should be displayed outside the parenthesis.
+ myOperation(in para1 : String, out para2 : String, inout para2 : String) : String

We also don't have the option to render the multiplicity, default or properties for a parameter. Showing the stereotype isn't provided by either EA or UML (but from memory SysML adds it for Activity Parameters) On the other hand the UML specification doesn't allow for listing name only or type only, which we do.

[Geert Bellekens]

Simon,

I agree that you shouldn't "destroy" everyone's diagrams, but on the other hand it should be at least possible to use a UML compliant syntax.

Maybe you can add another option next to "name only" and "type only"?

Geert

[qwerty]

From a cost/effect ratio I would not vote to implement it. The more complex a tool gets the less useful it tends to be. I often prefer KISS over completeness. I have only once in my life seeing someone asking for the optionality notation (the one on SO, you know). So everyone has to pay for the implementation of a feature which only a few use (like too many features in EA, I think).

q.

[Uffe]

From a cost/effect ratio I would not vote to implement it. The more complex a tool gets the less useful it tends to be. I often prefer KISS over completeness. I have only once in my life seeing someone asking for the optionality notation (the one on SO, you know). So everyone has to pay for the implementation of a feature which only a few use (like too many features in EA, I think).

I can agree with you on a lot of non-essential EA features (project management, issue tracking, all that guff which other tools do far better), but not on the *ML standards. And I don't buy the argument that adding stricter adherence to the standards makes the tool more complex. It's the non-UML stuff that makes a UML tool more complex.

I agree that it shouldn't be enforced, indeed one of the strengths of EA is its relaxed approach to the standards, but the option should be there. Geert's suggestion makes perfect sense. Just don't make it the default, because that would indeed break people's precious diagrams.  

/Uffe

[qwerty]

Good point. I guess I can concur. EA's "featureism" stroke me too hefty.

q.