UML Question

dk345 · 2 Dec 2011 at 11:55

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

GravyMonster · 2 Dec 2011 at 12:04

*EDIT*
I changed my mind - reasd post #4

dk345 · 2 Dec 2011 at 12:15

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

GravyMonster · 2 Dec 2011 at 12:19

Actually, I've changed my mind - I wouldn't do either.

With the first example, it looks like you're specifying the parameters to pass into the method. The second just looks ugly

dk345 · 2 Dec 2011 at 12:28

Well that was one of the reasons why I was hesitant to do what the book told me

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

rickh · 2 Dec 2011 at 12:59

dk345 said:
Hi Guys,

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?

Absolutely not. The output of a getter method is never defined by specifying input parameters.

Input goes in the parenthesis, output type goes after the colon.
In this case,
+getName(): String

dk345 said:
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?

Setters take input and return nothing, so:
+setName(name: String): void

dk345 said:
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.

Ask your head of department to give you a lecturer who knows the UML specification. Confusing getter and setter methods is not acceptable. Most Uni's in the UK don't treat UML with the rigour it deserves. I know a lot of lecturers who teach UML who have never written any object oriented software and don't understand the basics.

In the future of Model Driven Architecture, UML will become far more important than "just a documentation tool that doesn't need to be correct".

Dj_Jestar · 2 Dec 2011 at 13:03

Even better would be to ask your department to drop UML all together, as it is the devil incarnate and a complete waste of time.

rickh · 2 Dec 2011 at 13:06

Dj_Jestar said:
Even better would be to ask your department to drop UML all together, as it is the devil incarnate and a complete waste of time.

I don't agree.

I'm working on some huge projects in aero-eng where code generation from UML saves lots of time.

Should it be used on smaller projects where no one will look at it again and no one will maintain it? Perhaps not.

Dj_Jestar · 2 Dec 2011 at 13:07

Time is better spent on maintaining code, than maintaining pretty pictures of the code. If UML code generation is actually saving you time (something I doubt, btw) there is a lot to be said for your codebase.

We certainly do disagree

rickh · 2 Dec 2011 at 13:11

Dj_Jestar said:
Time is better spent on maintaining code, than maintaining pretty pictures of the code. If UML code generation is actually saving you time (something I doubt, btw) there is a lot to be said for your codebase.

We certainly do disagree

In these projects, UML is the code.
And yes, it does save lots of time compared to hand coding given the volatile portability requirements of the output code.

dk345 · 2 Dec 2011 at 13:15

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

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.

rickh · 2 Dec 2011 at 13:18

dk345 said:
Thanks for your input, rickh.

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

Knowing Universities as I do, it is definitely the latter.

Dj_Jestar · 2 Dec 2011 at 13:23

rickh said:
In these projects, UML is the code.

No it's not. You even said so yourself.

And yes, it does save lots of time compared to hand coding given the volatile portability requirements of the output code.

BS.

rickh · 2 Dec 2011 at 13:36

Dj_Jestar said:
No it's not. You even said so yourself.
BS.

You're talking about code as the end result, I'm talking about code as the language you use to construct the program. You could argue about levels of abstraction and what language the end result is, but if we did that, we'd have to conclude that everyone programmed in assembly.

I understand your scepticism; there are only a few situations where UML is suitable as a programming language replacement.

However, in this case (aero engine control systems), it works and is proven to be more efficient. Perhaps the biggest reason is that in this domain, complete and maintained documentation is essential and "code" portability allows better re usability between products.

UncleRuckus · 5 Dec 2011 at 03:04

I'll be doing a module on UML in the next year or so, the idea of having a visual representation of my code pleases me. I'd imagine it could potentially help with the planning of structured classes and programmes and help spotting malformed classes.