Multiple Return message in Sequence diagram

[Arunkumar S]

Hi,

I am using Borland Together UML tool. In this tool, If I select return
option for a method call, a single dotted lined will be drawn to show
return message.
But, my method has multiple return messages for different conditions.
Is there any notation using which I can represent return message
directly.

Thanks,
Arun

[H. S. Lahman]

Responding to S...

This is probably a tool issue so a better place to query would be a
Borland user forum.

There is insufficient information. What is the context of drawing the
line? An Interaction Diagram? Object Diagram? what do you mean by
multiple messsages? The callee responds with multiple returns at
different times? There are multiple objects that can respond? There are
different messages between the same two objects?

Some general comments...

A Call Event message in UML can have only one return. (Call Events in
UML map to tradittional 3GL procedures calls.) This is driven not so
much by OOA/D but by the nature of functions in 3GLs. The return from a
function can have a complex data packet but there is only one return;
that's just how stack-based architectures work.

At the OOA/D level collaborations are triggered by messages. There is a
single message for each collaboration. So if the message is a Call
Event, there would be a single response.

In an OO context only knowledge getter messages should ever return
values. Behavior responsibilities should /never/ return values because
that creates an immediate hierarchical dependence in the caller on how
the callee computes the returned value. In an OO context all behavior
messages should be simple announcements of something the behavior did
(I'm Done). If the receiver's response involves doing something the
original sender needs to know about, the receiver generates a new
message back to the original sender in a new collaboration. When a
behavior responsibility returns a value it is a dead giveaway that the
developer is overlaying procedure design techniques (Do This
imperatives) on an OOPL.

If the context of the call is a knowledge accessor, then there is only
one ADT value to return. That's because the public knowledge
responsibility of the object is always a logically indivisible scalar at
the subsystem's level of abstraction. (The actual data may be more
complex but that will be hidden behind an ADT definition of the
responsibility.) So there is no reason for multiple returns from a
single knowledge access at the UML model level.

So I am guessing the tool is doing the right thing.

Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html