When drawing out quick class diagrams, I'm often at a loss how to represent classes that are used just to pass data around between various parts of the program. I've been putting them out in the middle of nowhere, so that other people can see what the class in the parameters/returns is. Is this the correct way to do it?

(They look awefully lonely out there by themselves.)


I don't think there's a set standard. Some CASE tools may be picky, but the majority of software engineers use UML to design, not to generate code, in which case the goal is to increase communication effectiveness.

I've found that the presence of data-carrying objects, especially if they are only used in method arguments and return values, tends to obscure the important interactions.

Here is what I would do:

If you use these classes in multiple locations, it is often ok to pick a separate area of the diagram as a "legend", and organize these classes in alphabetic order. There is no need to clutter the diagram with these or with extra arrows - the repeated in the signatures is sufficient. Make it easy for someone to find these. A separate legend sheet (if using posterboards) is particularly good.

If the class is only used in the communication between a very small set of classes, then it might make more sense to place it somewhere on the lines of interaction between them.

Finally, if your data objects are used to communicate between tiers (e.g., serialized data between client and server), you might want to draw each tier on a separate side and line these up in the middle.

Oh, and if the data relations inside the data carrying objects are complex, don't hesitate to use ERDs or your favourite database related notation in the class diagram. The goal is to design, not to focus on formalism.

  • Some excellent ideas here. I actually have used ERDs for context objects! – Michael K Apr 12 '11 at 13:03
  • Michael, years ago I spent a significant portion of my Ph.D. work observing how people use UML in the real world and how they mix notation. A lot of the photos are in my dissertation, you might find them reassuring. – Uri Apr 12 '11 at 21:34

Classes with no behavior are usually called data objects. There's nothing wrong in diagramming them like any other class, and their loneliness may give you some ideas for improving the overall design. The fact that data objects are passed around could imply that the concepts they represent are in some relationship with the existing classes. Maybe they should even contain some significant business logic, and cease to be data objects after all.

Alternatively, you could use the generic UML dependency relationship to make them less lonely. It's depicted by a dashed line with an arrow at the end pointing towards the data object.

  • Dependencies would be a good option in some cases - I hadn't thought of using them. – Michael K Apr 12 '11 at 13:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.