3

I'd like to express (visually) in UML that class Foo returns class Bar. The Bar object is created in one of Foo's methods and returned as a result.

I don't know whether to use a dependency or association relationship for this. Any suggestions?

EDIT

I should clarify that the UML diagram I'm working on doesn't contain any class attributes or operations. It's just intended as an overview that shows relationships between classes. Descriptions of attributes and operations are already generated from the source code (via Doxygen).

EDIT 2

I should further clarify that I want to show this relationship from a class diagram. I apologize for not being clear from the start.

EDIT 3

Upon further digging around, looking at examples, I realized that it's more important to document that Foo creates Bar. The fact that one of Foo's methods returns Bar is an implementation detail that I can leave out of my class diagram. So now, my question is: what's the best way to show a "Foo creates Bar" relationship in a class diagram?

Emile Cormier
  • 28,391
  • 15
  • 94
  • 122

2 Answers2

4

As I've mentioned in my third edit, I realized it was more important to document the relationship that Foo creates Bar. The fact that some of Foo's methods return Bar is a detail better left to the Doxygen documentation (in my situation anyway).

As mentioned by others, the fact that Foo returns Bar can also be represented in the operations compartment of the Foo class, or in behavioral diagrams. But in my question, I've constrained myself to only class diagrams without listing attributes and operations.

I've done some digging around, and have discovered that UML has the <<create>> predefined stereotype for a usage dependency, illustrated here as

+------------+               +------------+
|            |  <<create>>   |            |
| Datasource +-- -- -- -- -->+ Connection |
|            |               |            |
+------------+               +------------+

The <<create>> stereotype is described in the UML 2.4.1 Superstructure specification, page 704 as:

A usage dependency denoting that the client classifier creates instances of the supplier classifier.

A usage dependency is (UML 2.4.1 Superstructure, page 139)

a relationship in which one element requires another element (or set of elements) for its full implementation or operation.

Furthermore:

The usage dependency does not specify how the client uses the supplier other than the fact that the supplier is used by the definition or implementation of the client.

The UML spec also has the <<instantiate>> predefined stereotype, defined as:

A usage dependency among classifiers indicating that operations on the client create instances of the supplier.

There seems to be some overlap between the <<create>> and <<instantiate>> stereotypes.

Emile Cormier
  • 28,391
  • 15
  • 94
  • 122
1

Return types from methods are expressed in the method definition within the class. Most tools can turn on/off attribute and method visibility. If class Foo creates or operates on class Bar, you can use a directional association from Foo to Bar. It doesn't sound like a dependency.

Bruce
  • 2,230
  • 18
  • 34
  • *If class Foo **creates** or operates on class Bar...* Thanks, that phrase helped me focus more on the creation aspect, and I ended up finding the `<>` stereotype for that very purpose. `<>` is used with dependency relationships, and not with associations, though. – Emile Cormier Mar 28 '15 at 22:25