difference between sequence and collaboration diagrams

[sridhar satuloori]

Please explain me the difference between sequence and collaboration diagrams. and when to use what??
TIA
Sridhar

[Vikrama Sanjeeva]

Hi,
I have noted the following difference b/w Sequesnce & Collaboration Diagram.If i am wrong then plz correct me.
1:
In Sequence diagrams we can show Synchronous as well as Asynchronous messages.
In Collaboration Diagram we can only shoy Synchronous messages.
2:
Sequence Diagram shows overall flow of System event/s in a given use case.
Collaboration diagram shows how objects interacts with each other ohow intercommunication b/w objects for a give use case
3:
Its difficult to fine the responsibilities of objects in sequence diagram.
Its ease to detect the responsibilities of objects in collaboration diagram by juist counting the number of arrows coming into the object.
4:
Sequence Diagrams are less spatial.
Collaboration Diagram are much spatial.
When to use when:-
A/C to Fowler: You should use interaction diagrams when you want to look at the behaviour of several objects within a single use case.
Bye,
Viki.

[Frank Carver]

In Sequence diagrams we can show Synchronous as well as Asynchronous messages. In Collaboration Diagram we can only show Synchronous messages.
I don't see why this should be the case.
A collaboration diagram just shows all the objects of interest and the ways they interact, all in one diagram with no time or situatioanl element.
A sequence diagram, on the other hand, shows the specific interactions that occur the sequence in which they occur for a particular scenario.
Sequence Diagrams are less spatial. Collaboration Diagram are much spatial.
I don't really understand what you are getting at here.
By nature all diagrams are spatial. A sequence diagram is effectively a two-dimensional graph with time on one axis and objects of interest on the other.
A collaboration diagram is a visualization of a collection of objects linked by interactions, arranged in an attempt to optimize understandability

[Ilja Preuss]

Originally posted by Frank Carver:
In Sequence diagrams we can show Synchronous as well as Asynchronous messages. In Collaboration Diagram we can only show Synchronous messages.
I don't see why this should be the case.
A collaboration diagram just shows all the objects of interest and the ways they interact, all in one diagram with no time or situatioanl element.

That's not entirely true - you typically show the sequence of the collaboration by numbering the interactions.
OTOH I think you can also depict asynchronous interaction in collaboration diagrams, though possibly not with as much detail.
See also
http://www.objectmentor.com/resources/articles/umlCollaborationDiagrams.pdf
and
http://www.objectmentor.com/resources/articles/UMLSequenceDiagrams.pdf

[Craig Jackson]

I think what is meant by:

In Sequence diagrams we can show Synchronous as well as Asynchronous messages.
In Collaboration Diagram we can only shoy Synchronous messages

Is that sequence diagrams are valuable in showing concurrent processes. They have the ability to show an asynchronous message. Which is represented as a half-arrowhead symbol. And as far as I know collaboration diagrams do not have this ability.
Also the statement...

Sequence Diagrams are less spatial.
Collaboration Diagram are much spatial

To me, that means if you have a particular long scenario you wanted to be represented by sequence diagram, which involves many objects, the length(left-right) of the sequence diagram could be quite long on a 17" monitor. This particular situation might be better represented as a collaboration diagram, where you could have several messages flowing along the link between the objects.
my 2 cents.
craig

[Ilja Preuss]

Originally posted by cj jack:
[...]sequence diagrams are valuable in showing concurrent processes. They have the ability to show an asynchronous message. Which is represented as a half-arrowhead symbol. And as far as I know collaboration diagrams do not have this ability.

I think you could use a stereotype for this, if there are no other means.
Nevertheless, sequence diagrams are certainly better in showing *any* timing related concept, whereas collaboration diagrams are better in depicting the relationships between objects - even when they are in fact both containing identical information.
So I think it is less about what information you could put into them, but mostly about what information they are good for at highlighting.

[Ilja Preuss]

With other words, from http://www.devx.com/codemag/articles/2002/mayjune/collaborationdiagrams/codemagp.asp :
"Collaboration diagrams, like their close cousin, sequence diagrams, show the dynamic interaction of messages sent and received between objects in a software system. A collaboration diagram's focus is the structural organization of objects that send and receive messages, while a sequence diagram's focus is the time-ordering of messages. Collectively, collaboration diagrams and sequence diagrams are referred to as interaction diagrams."

[Frank Carver]

Ilja wrote: That's not entirely true - you typically show the sequence of the collaboration by numbering the interactions.
Interesting. I don't use UML much, but I probably use collaboration diagrams most of all. I've never done that though! I've always kept the collaboration diagrams scenario-independent and left any sequence information (rarely) to a sequence diagram or (more usually) to a code snippet.
This is probably because I'm generally more familiar with CRC cards than UML, so carry over the CRC-style loose collaborations into the UML diagrams.

[Frank Carver]

cj jack wrote: They have the ability to show an asynchronous message. Which is represented as a half-arrowhead symbol. And as far as I know collaboration diagrams do not have this ability.
I never thought of that either. In my copy of UML Distilled, Second Edition, which I use as my main UML reference these days, there are diagram examples inside both covers. In the back there is a "half arrow" shown with the Collaboration Diagram example, and labelled "asynchronous message". If you have a copy, check it out!
Can anyone explain why it wouldn't make sense to show anychronous messages in a collaboration diagram ?

[Vikrama Sanjeeva]

Originally Posted By Frank Carver:
Sequence Diagrams are less spatial. Collaboration Diagram are much spatial.
I don't really understand what you are getting at here

See page# 73 1st para of UML Distilled 2nd Edition

Originally Posted By Frank Carver:
I never thought of that either. In my copy of UML Distilled, Second Edition, which I use as my main UML reference these days, there are diagram examples inside both covers. In the back there is a "half arrow" shown with the Collaboration Diagram example, and labelled "asynchronous message". If you have a copy, check it out!

Please mention the page.

Originally Posted By Frank Carver:
Can anyone explain why it wouldn't make sense to show anychronous messages in a collaboration diagram ?

First of all i haven't found any notation in UML for showing "asynchronous" messages in collaboration diagram.Secondly, Sequence diagram is made to see overall flow of system event/s in a use case, in other words you can say the flow of messages, & flow of messages can be syncronous as well as asyncronous, therefore UML has notation for showing asynchronous messages.
On the other hand, Collaboration diagram is made to see intercommunication b/w objects, and at a given instant one object can interact with exactly one object. i.e one object cannot interact with multiple objects at a given instant.Since Asyncronous messages can not be shown or craft in collaboration diagram.Therefore UML has not included notation for showing Asyncronous messages in collaboration diagram(as far as my knowledge is concern).
Bye,
Viki.

[Ilja Preuss]

Originally posted by Vikrama Sanjeeva:
Please mention the page.

He already did: The inside of the back cover.

First of all i haven't found any notation in UML for showing "asynchronous" messages in collaboration diagram.

Even if Frank would be wrong and there isn't any explicit notation for that in collaboration diagrams, you could always "invent" your own stereotype for the interaction (like, say, <<asynch>> ) . Or you could simply use the same notation as in sequence diagrams anyway.

Secondly, Sequence diagram is made to see overall flow of system event/s in a use case, in other words you can say the flow of messages, & flow of messages can be syncronous as well as asyncronous, therefore UML has notation for showing asynchronous messages.
On the other hand, Collaboration diagram is made to see intercommunication b/w objects, and at a given instant one object can interact with exactly one object. i.e one object cannot interact with multiple objects at a given instant.Since Asyncronous messages can not be shown or craft in collaboration diagram.Therefore UML has not included notation for showing Asyncronous messages in collaboration diagram(as far as my knowledge is concern).

I don't follow you. Interaction between objects *is done* by sending messages, so if a message is send asynchronously, certainly the interaction between the objects is asynchronous, too, isn't it? After all, asynchronous communication doesn't mean to interact with more than one object at the same time, but simply not waiting for an answer before sending the next message.
[ August 21, 2002: Message edited by: Ilja Preuss ]

[Frank Carver]

Vikrama Sanjeeva wrote: On the other hand, Collaboration diagram is made to see intercommunication b/w objects, and at a given instant one object can interact with exactly one object. i.e one object cannot interact with multiple objects at a given instant.Since Asyncronous messages can not be shown or craft in collaboration diagram.Therefore UML has not included notation for showing Asyncronous messages in collaboration diagram(as far as my knowledge is concern).
From the paragraph before the one you pointed me to:
"Within a collaboration diagram, the example objects are shown as icons. As on a sequence diagram, arrows indicate the messages sent within the given use case. This time, however, the sequence is indicated by the numbering of the messages"
I read the italicised section (my emphasis) as implying that similar arrows are used to indicate similar types of messages. Am I wrong ?
I still don't understand why you seem so admant that UML can't represent asynchronous messages in collaboration diagrams. May I ask what is your source which indicates that they can't be shown ?
I quite often find I need to describe or diagram asynchronous collaboration. Try describing a J2EE system using Message-Driven Beans some time!
Or are we talking about different things ?

[Vikrama Sanjeeva]

Hi,
After a long period which i have spent in the research of above ongoing discussion, I am back with robust resaons from authentic resourses.
In my first post I said,

In Collaboration Diagram we can only show Synchronous messages.

This is totally wrong!
Here are the reasons/links,
1:See the back cover of UML Distilled,2nd Edition(As Frank said)
2:See page# 430 Article# 36.5, of Craig Larman.
3:Kendall Scott, author of UML Explained, in one of his email said:

Sequence diagrams are lousy for representing concurrency no matter what tool
you're using. I recommend you use collaboration diagrams to show concurrency (with sequence numbers).

By, last point, it is much clear to use Collaboration diagram to show Asynchronus message instead of Sequence Diagram.Anyway, it depends upon your choice, i.e which gives more clarity.

One last thing which I want to confirm at this stage is,(Frank plz read this concept)
As i said in my last message,

On the other hand, Collaboration diagram is made to see intercommunication b/w objects, and at a given instant one object can interact with exactly one object. i.e one object cannot interact with multiple objects at a given instant.Since Asyncronous messages can not be shown or craft in collaboration diagram.Therefore UML has not included notation for showing Asyncronous messages in collaboration diagram(as far as my knowledge is concern).

Now I realize that this concept is also totally wrong:
Because one object can be used by one or more threads at a time,provided
1:No synchronize block
2:No synchronize method.
If any one of the above is true, then at a given instant only one thread can use an object, while others are waiting to acquire lock.
Frank you are right!.And u should be
Bye,
Viki.