A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I'm trying to use UML and I don't see a good way to illustrate data (objects) being passed from one object to another.
* There are 4 object instances, of type ClassA, ClassB, ClassC, and ClassD, which are named ObjectA, ObjectB, ObjectC, and ObjectD
* ObjectA invokes a method of ObjectB: this method of ObjectB is named 'doSomething' and requires two parameters, the first parameter is of type ClassC and the second parameter is of type ClassD.
I don't see how to illustrate well, graphicly, that objects of type ClassC and ClassD are being passed to this method of ClassB.
[ObjectA has reference to ObjectC and ObjectD, which it can pass to ObjectB's doSomthing method, either because ObjectA contains these references or because the references are being passed as input parameters to the method of ObjectA].
I can do a sequence diagram showing ObjectA and ObjectB , and draw an arrow from one to the other, and label the arrow "doSomething(ClassC ObjectC,ClassD ObjectD)" ... but a label with text like that isn't really quite the same as an illustration that shows classes/objects C and D graphically ... not the same as and not as good as because, for example, anyone who is looking at but not *reading* the diagram doesn't even 'see' these objects at all.
I think this is a major weakness of UML. It tends to encourage very 'flat' architectures which use inheritance (IsA relationships) and association (HasA relationship) but de-emphasizes the "I'm going to take one of these and one of these and make a third thing out of them" approach.
I could be wrong on this one, though.
And in my experience the sequence diagram with parameters in the call IS the canonical way to draw it.
Thursday, April 07, 2005
I don't think there is a good UML type for what you're trying to do.
In fact, even more simply, UML describes dependencies and inheritance, but does not describe "intent".
That to me is the big weakness, and I guess it just means that although the picture of dependencies is very helpful, it doesn't negate the drawing of other non-UML diagrams and surrounding text that really describe what you're thinking.
I think that the sequence diagram that you're drawing is the right thing to do - especially as you've described it objects passing objects as messages. The dependency diagram also will be helpful to show someone the class organization.
There might be some other diagram or text that you make up on your own to describe your thoughts.
I think that you just need to accept that a large part of the UML *is* actually textual. For example, it's not sufficient to simply draw stick men and bubbles for use cases, there should always be supporting text.
I'm sure that your sequence diagram is fine.
Thursday, April 07, 2005
>but a label with text like that isn't really quite the same as an illustration that shows classes/objects C and D graphically ... not the same as and not as good as because, for example, anyone who is looking at but not *reading* the diagram doesn't even 'see' these objects at all.
This is not a problem. Sequence diagram is just differ from class diagram, that's it. It has its place and in your case it shoudl work well. Or maybe try collaboration diagram
Friday, April 08, 2005
The notation used to illustrate an "Association Class" is interesting ... and, in a way, a parameter is the data that provides the association between two classes across a method call ... but the 'association class' notation is meant for a class diagram, not meant for a sequence dagram (and is meant to illustrate the static/logical nature of the class, not the dynamic use to which the class is being put).
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz