UML notation: Class operation return value multiplicity
Hallo,
how would you write function from example below using UML notation on implementation level, please:
class Coin{
public String[] getSideNames(){
returnnew String{"Odd","Even"};
}
}
Multiplicity in return value is troubling me. I've tried+getSideNames( ) : String [ 2 ] but my tool just created new class named "String[2]" :-( To be precise I know that return value of function is array of MyClass with one or more element (1..*) so created class name was "MyClass[1..*]" -- nasty name to pass to javac isn't it? :-)
Is is possible to write multiplicity of return value this way? I couldn't find anything in omg's "UML: supertructure document" :-( I am *not* telling that it's not written there :-)))
Thank You.
[1136 byte] By [
a3cchana] at [2007-10-3 10:39:02]
Is code generation formalized? Could be - I certianly haven't looked in a while.Does your tool allow [*] or [n]?
gotta ask - what's the point? the code makes it clear enough. what added value does putting this in UML provide?
you can have cardinality in a class diagram that shows exactly two values are available.
personally, i don't think that exposing the side names as an array is a very good abstraction. users shouldn't have to know that you happen to store side names in an array of strings. this isn't very good OO practice, IMO.
%
jschell>
Unfortunately [n] behaves in same fashion as [*] => creating class named MyClass[1..n]" :-(
duffymo> what's the point?
this was only sample, real application is far more complex than that. Even "nature" of result was just made up.
duffymo> you can have cardinality in a class diagram that shows exactly two values are available.
yup, i ended like that but there's still problem coz return value class is "Object[]" :-(
duffymo> personally, i don't think that exposing the side names as ...
"side names" were just example :-) IMHO there are certain situations where one could say "screw the abstraction" :-D E.g. for final classes from one package that cooperate on single time critical task. :)
thanks for suggestions
Ad
> jschell>
> Unfortunately [n] behaves in same fashion as [*] =>
> creating class named MyClass[1..n]" :-(
A long time ago, at different times, I found the following with various tools that I used.
1. Some variation will do it. Just try them all.
2. The generator allows for code modification. This will be buried somewhere besides the diagram, maybe even in script files, but modifying the template code allows a slightly different output.
3. Create a post processor tool. It takes the generated output and modifies it based on rules that you decide.
The last obviously requires the most work.
> jschell>
> Unfortunately [n] behaves in same fashion as [*] =>
> creating class named MyClass[1..n]" :-(
>
> duffymo> what's the point?
> this was only sample, real application is far more
> complex than that. Even "nature" of result was just
> made up.
How am I or anyone else who responds supposed to know that?
>
> duffymo> you can have cardinality in a class diagram
> that shows exactly two values are available.
> yup, i ended like that but there's still problem coz
> return value class is "Object[]" :-(
Sounds like a bad design, but I haven't seen the code, so I can't tell.
> duffymo> personally, i don't think that exposing the
> side names as ...
> "side names" were just example :-) IMHO there are
> certain situations where one could say "screw the
> abstraction" :-D E.g. for final classes from one
> package that cooperate on single time critical task.
> :)
"screw the abstraction" - good luck as an object-oriented designer with that attitude.
Either you're doing real-time work where time really is critical, or you're just another yutz who is congratulating himself on recognizing a time critical task without doing profiling or getting any real data. (A common mistake.)The maintainence and development time might be more critical here.
Gotta admit that I'm not much interested in commenting on your poor approximation of the real problem.
%
jschell>
thank You, i've finally decided to abandon that idea. i've upcasting return type to Object. It will be
duffymo>
no need to get angry :-) no comment. well maybe one...
duffymo> "screw the abstraction" - good luck as an object-oriented designer with that attitude.
no silver bullet.
