Talk:Sequence diagram

Untitled

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)[reply]

In the first diagram, shouldn't the arrow for 'pickup' be pointing in the opposite direction? Surely it is the waiter that performs the 'pickup' action?

I would remove the phrase well-known - it's subjective. —The preceding unsigned comment was added by 83.67.57.153 (talk) 15:31, August 21, 2007 (UTC)

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)[reply]

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)[reply]

Poor reference

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)[reply]

Too many errors

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)[reply]

I agree with these comments: UML Sequence Diagrams were influenced by ITU's Message Sequence Charts, but it is not a direct construct.

Regarding the different diagrams: in the 2.2 version of UML, Interaction is an abstract concept, and an Interaction can be depicted with Sequence Diagrams or Communication Diagrams or Interaction Overview Diagrams or Timing Diagrams or Interaction Tables (so these are just concrete notations for Interactions).

Micskeiz (talk) 17:28, 13 November 2009 (UTC)[reply]

Diagrams

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)[reply]

you say the same in case of wine? drink wine? —Preceding unsigned comment added by 195.205.192.10 (talk) 15:03, 7 April 2010 (UTC)[reply]

The restaurant example for a Sequence Diagram is appropriate if you consider that the sequence diagram represents the information flow between Patron, Waiter, Cook and Cashier and the sequential actions performed on the Food object. Waiter does send an "Eat Food" message either by telling the patron "Your soup is ready sir!" or by simply showing the food to the Patron. Patron signals Waiter by asking for the bill. Waiter then tells Cashier to prepare bill, Waiter takes bill to Patron, Patron pays, etc.

The Food is not a message but is another object that is independently processed by the Cook, Waiter and Patron but not by the Cashier in a sequential manner.

The restaurant model is a sequential process that can be modeled well by a sequence diagram if the messages or actions that define the stages in the sequence are properly identified. It is also an appropriately complex example that shows that the process objects- Patron, Waiter, Cook and Cashier exchange messages with each other and also perform uni-directional actions (messages) on the Food - prepare, deliver, eat(or not eat) and clean up. Food should also be another object with its own timeline and interactions in the sequence diagram.

But definitely, the diagram needs to be corrected. —Preceding unsigned comment added by 121.54.92.117 (talk) 21:03, 28 June 2010 (UTC)[reply]

Someone deleted the resturaunt diagram. DavidDHaynes (talk) 21:18, 21 April 2014 (UTC)[reply]

Email Diagram

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)[reply]

I agree that the diagram is in conflict with the description, but what do you mean with "So is the use of a solid-arrowhead coming from a found message."? EulerPie (talk) 22:50, 13 December 2017 (UTC)[reply]

New reference paper

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)[reply]

Superstep redirect?

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://wiki.riteme.site/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)[reply]

Actually I just went ahead and changed the Superstep redirect to Bulk synchronous parallel. It is clearly more appropriate at this time. — Preceding unsigned comment added by 98.215.55.215 (talk) 13:20, 22 January 2015 (UTC)[reply]

Merge proposal

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)[reply]

Merger complete. Klbrain (talk) 09:33, 20 August 2021 (UTC)[reply]