Relationship between Business Delegate and Value Object

[shay Aluko]

This question is for the UML experts here. What is the relationship between a business delegate and and its related value object. Is it a dependency or an association--i am not sure.

[Ramon Gill]

Shay,
Are you talking about within class diagrams? I personally wouldn't put any Value Objects in class diagrams. I would include them in interaction diagrams though.

Ray

[Eduardo Rodrigues]

Originally posted by Ramon Gill:
Shay,
Are you talking about within class diagrams? I personally wouldn't put any Value Objects in class diagrams. I would include them in interaction diagrams though.

Ray

What about put VO�s in the sequence diagrams?

Bye

[Ramon Gill]

Eduardo,
Interaction diagrams are sequence diagrams and collaboration diagrams (see Fowler).

Ray

[shay Aluko]

I have seen value objects in some class diagrams, but my original question has not been answered

[Shogo Ito]

BD is very likely to have a dependency on VO, not association. In BD, VO usually appears (or should appear) as a method parameter, return type, or just as a local variable. These are dependency. An association means a class has a structural relationship e.g. attribute.

my comment always without any warranty

[Eduardo Rodrigues]

Hello again guys!
If I put the VO�s showing the dependendy then my component diagram will be a confusion!

the BD�s will have the dependency to VO�s
the JSP�s will have the dependency to VO�s
the EJB�s will have the dependency to VO�s

I�m thinking in not put the VO�s in the component diagram, like Cade did in his example...

Please, comments!

[Ramon Gill]

Cade only included them in the interaction diagrams (Sequence or Collaboration), so he must have thought this was sufficient.

It would be interesting to see other opinions.Cade's component diagrams do look a bit on the 'brief' side.

Ray

[Peter Storch]

Originally posted by Eduardo Rodrigues:
If I put the VO�s showing the dependendy then my component diagram will be a confusion!

That's the point. UML diagrams should help to communicate a design or a solution and not make it more incomprehensible.

The same goes for utility classes, like logger classes and so on. Every other class needs it and has a dependency on it. But that's obvious and doesn't need to be communicated via a dependency in a class diagram.