UML Question

Associate
Joined
30 Dec 2008
Posts
418
Location
York
Hi Guys,

We're doing a software engineering project for the second year of my degree, it's supposed to mimic a 'real' software development life cycle as much as possible.

I'm currently going over our Team's UML model and I have a question about methods in the diagram.

Say we have a method getName() that returns the name of a character. Is it standard practice to include what is returned within the brackets, for example "getName(String name)" or not?

Secondly, if we have a method setName() which sets the name, and as such returns nothing, is it standard practice to complete the method with : void in the UML diagram. So: "setName() : void" as there is no return parameter?

I've read several text books and online resources and haven't found a certain yes or no. I've asked my lecturer and she says either is right as long as you justify why you've chosen that way of doing things, but that seems to be the answer for everything we ask.

So, I was wondering what the members of OcUK would do in this situation, as you'd obviously have more experience than me :)

Thanks A Lot
 
Thanks for the quick reply. I see what you mean about not specifying the return type - probably should have thought of that myself.

Anyway, thanks for your opinion :)
 
Well that was one of the reasons why I was hesitant to do what the book told me :p

If I did put getName(String name) then it would look like I was passing a String, name, into the method. I've had a look on the OMG website, who apparently 'set the standard' and I've found a 400 page PDF that hasn't helped much yet.

I'll keep reading :D
 
Thanks for your input, rickh.

What you've said does make sense and has cleared things up for me. I don't know why the books I've read were telling me to put return types in the brackets, one of them wasn't even that old - 2005!

Looking at it now, I feel silly for having to ask the question as it just makes sense and is pretty obvious. As for my Lecturer, she's 'not supposed to tell us much, we have to decide for ourselves'. Not sure if that's just a guise for not knowing much, I hope not :p

As for the whole is UML relevant debate, this is the only time I've used it and I have to say, for small projects I can see why it'd be tedious and many people would elect not to use it. But for larger projects, I can fully understand why it needs to be there - even if it's just a to do list of what to implement.
 
Back
Top Bottom