Talk:Sequence diagram

message: I have rewritten the first paragraph, hoping to make it clearer, and added a "Usage and limitations" section with the main purpose of avoiding the misconception that sequence diagrams generally suffice to describe behavior.  However I am not a real expert on sequence diagrams and theur use, so corrections will be much appreciated.  Rp 17:42, 10 July 2006 (UTC)
replies: text: Sequence Diagrams in UML 2.0 have a ref construct that allows nesting of sequence diagrams. This enables interactions of arbitrary complexity to be modeled using multiple sequence diagrams. Moreover, saying that sequence diagrams can model only "simple" systems is a POV (and a beginner's POV at that) and is non-neutral. Hence, the "Usage and limitations" section is not neutral and should be removed.Kishorekumar 62 (talk) 12:07, 22 September 2009 (UTC)
replies: text: I don't believe nested sequence diagrams can describe complex interaction protocols between multiple concurrently operating objects. There appears to be a strict hierarchy of levels of concurrent processes, each populated by communicating objects from a fixed set, as far as I can see.  If sequence diagrams can express more complex communication, e.g. the dining philosophers problem, this passage is indeed mistaken, but an explanation would be in order. Rp (talk) 18:50, 20 April 2010 (UTC)
thread_title: Untitled

message: I checked the first reference - it does not have a page 91! This reference needs to be removed.Kishorekumar 62 (talk) 11:39, 22 September 2009 (UTC)
thread_title:  Poor reference 

message: Sequence diagrams are not a construct of Message Sequence Chart. They may be similar, but neither is a "construct" of the other.
Nowhere does the UML specifications say that sequence diagrams are called Event-trace diagrams, event scenarios, and timing diagrams. In fact, Timing Diagram are quite different from Sequence Diagrams.
These errors need to be removed.
Kishorekumar 62 (talk) 12:07, 22 September 2009 (UTC)
thread_title:  Too many errors 

message: ===Resturarant===
Attempting to model the interactions in a restaurant using sequence diagrams is not a good idea. This is better modeled using use case diagrams.
Trouble is, sequence diagrams are all about objects passing messages to each other. In the case of restaurant interactions, a message passing model works well to represent the order-taking process, but when it comes to the delivery part, the message passing paradigm becomes unsuitable. In other words, until the Waiter receives the "pickup" message, this diagram reads well. The Waiter sending a "serve food" message to the Patron - that is jarring! The Waiter is not sending any messages to the Parton; he is serving real food! If you insist on a message exchange paradigm, the Waiter should more appropriately send a "eat food" message to the Patron!
Kishorekumar 62 (talk) 13:04, 22 September 2009 (UTC)
thread_title:  Diagrams 

message: Attempting to model the interactions in a restaurant using sequence diagrams is not a good idea. This is better modeled using use case diagrams.
Trouble is, sequence diagrams are all about objects passing messages to each other. In the case of restaurant interactions, a message passing model works well to represent the order-taking process, but when it comes to the delivery part, the message passing paradigm becomes unsuitable. In other words, until the Waiter receives the "pickup" message, this diagram reads well. The Waiter sending a "serve food" message to the Patron - that is jarring! The Waiter is not sending any messages to the Parton; he is serving real food! If you insist on a message exchange paradigm, the Waiter should more appropriately send a "eat food" message to the Patron!
Kishorekumar 62 (talk) 13:04, 22 September 2009 (UTC)
thread_title: Resturarant

message: The email diagram makes numerous synchronous calls but only one of them replies. This is bothersome. So is the use of a solid-arrowhead coming from a found message. (refer to the UML Superstructure Specification v2.4.1 page 519, Table 14.2, second row). We either need to modify the digram to use asynchronous calls, reply to to other synchronous requests, or make a new diagram that combines the elements we are looking for. I'd be happy to make such a diagram and add or replace it.DavidDHaynes (talk) 21:18, 21 April 2014 (UTC)
thread_title: Email Diagram

message: I have a paper about the different semantics choices in UML 2 Sequence diagrams:
Z. Micskei and H. Waeselynck: The many meanings of UML 2 Sequence Diagrams: a survey, Software and Systems Modeling, Springer, Online first, DOI:10.1007/s10270-010-0157-9, 2010, http://springerlink.metapress.com/content/6716hk1844h16694/
I thing it is a good overview and quite relevant to this page. Any objections against adding it to the references section? Micskeiz (talk) 17:12, 16 May 2010 (UTC)
thread_title:  New reference paper 

message: The term 'Superstep' redirects to this page, but the term is never used here.  The only context I know of that involves supersteps is located at http://en.wikipedia.org/wiki/Bulk_synchronous_parallel, where the concept is discussed extensively.  It seems like this would be a better redirect target?  — Preceding unsigned comment added by 98.215.55.215 (talk) 13:14, 22 January 2015 (UTC)
thread_title:  Superstep redirect? 

message: There's a 2020 proposal to merge System sequence diagram and this page (Sequence diagram). I think that this is worthwhile, on the grounds that these are both brief and overlapping, although it would require some restructuring. The current page focusses on the UML, but the System sequence diagram is broader in scope. This breadth in scope would be better presented under the simpler/broader title (hence the advantage of a merge). Klbrain (talk) 10:02, 10 April 2021 (UTC)
replies: text: Klbrain (talk) 09:33, 20 August 2021 (UTC)
thread_title:  Merge proposal