Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Public Method Names in Class Diagram

 
James Owen
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi
I have a small yet non trivial doubt. My assignment states "Public Method Names referenced in other UML diagrams should be provided for class diagram".

Now my deliema is Do i have to include 1) Just the method name OR 2) Method name and its Signature.
Ex
submitShippngRequest()
OR
submitShippngRequest(Address, int) :void

The whole signature is making the class diagram pretty Huge/wide. Imagine that in 16-20 classes. And i dont know if haveing an int in signature communicates that its OrderNumber that shoud be passed as an int.

Any response from my expericed colleagues is much appreciated.
Thanks
SCJP 5 91%
SCEA Part 1 93%
 
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper
Posts: 4968
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I always prefer to see method signatures included.

If you've got a long method signature, maybe that's an indication you need to factor out an object or two. Method signatures shouldn't be too long for the assignment.

Maybe an orderRequest object could encapsulate those two properties?

-Cameron McKenzie
 
James Owen
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So would you suggest that orderRequest should be shown in class diagram too??
 
J J Wright
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I wouldn't get too flustered about the size of the diagram. As for encapsulating two parameters in a request object I think that's a little excessive (unless you envisage a change in the signature and you want to encapsulate that change in the request object). Methods with five or more parameters, however, should start alarm bells ringing, but refactoring based solely on the aesthetics of your diagram seems silly. In case you're tempted, I also think abbreviating identifiers is a big mistake. After all, in many cases the code is the documentation.

Regardless, a class diagram with only 16-20 classes is never going to be overly complex. What I would say is that whatever approach you take be consistent - don't mix and match.
 
J J Wright
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
submitShippngRequest() OR submitShippngRequest(Address, int) :void


I think it's OK to only list the types of objects that are passed as parameters. However, as you say, primitives are a different matter so in the case of your orderNumber param I would provide a name, i.e.

 
Don't get me started about those stupid light bulbs.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic