Die folgende Abbildung zeigt das Sequenzdiagramm zum Anwendungsfall "Lieferscheine erstellen":
Ein Sequenzdiagramm hat zwei Dimensionen: Die vertikale Dimension repräsentiert die Zeit und die horizontale Dimension die Objekte sowie den Benutzer. In den meisten Fällen ist man nur an der zeitlichen Abfolge der Interaktionen interessiert, so daß eine Metrik für die Zeitachse nicht erforderlich ist. Die beteiligten Objekte werden durch schwarz umrandete Kästen symbolisiert. In jedem Kasten steht ein Bezeichner für das Objekt. Dieser Bezeichner hat folgendes Format: [Variablenname]:<Klassenname> .
Ein Objekt-Bezeichner muß also mindestens aus einem Doppelpunkt gefolgt von einem Klassennamen bestehen, um das Objekt eindeutig als Instanz dieser Klasse zu kennzeichnen. Optional ist die Vergabe eines Variablennamens für diese Instanz. Diese Möglichkeit ist insbesondere nützlich, wenn mehrere Instanzen derselben Klasse in einem Sequenzdiagramm verwendet werden.
Die Dauer der Existenz eines Objekts wird im Sequenzdiagramm als senkrechte gestrichelte Linie unterhalb des Objekt-Symbols dargestellt. Wenn das Objekt während des im Diagramm abgebildeten Zeitabschnitts erzeugt oder zerstört wird, beginnt oder endet diese "Lebenslinie" an der entsprechenden Stelle, ansonsten verläuft sie durchgehend von oben nach unten im Diagramm (vgl. /UML 97/, UML Notation Guide, S. 84). Wenn ein Objekt erzeugt wird, so zeigt der Pfeil der erzeugenden Nachricht (siehe unten) auf das Symbol (den Kasten) des neu erzeugten Objektes. Die Zerstörung eines Objektes wird durch ein großes "X" am Ende seiner Lebenslinie kenntlich gemacht.
Die auf der Lebenslinie eines Objektes plazierten Rechtecke kennzeichnen Perioden, in denen dieses Objekt aufgrund einer empfangenen Nachricht eine Aktion ausführt - entweder direkt oder durch eine an ein anderes Objekt verschickte Nachricht. Es kann für jedes Objekt in einem Sequenzdiagramm mehrere solcher Aktivitätsperioden geben.
Der Benutzer wird stereotypisch als Strichmännchen links oben im Diagramm repräsentiert. Er stößt die Abarbeitung der Aktionen des Anwendungsfalls durch eine Nachricht an das direkt rechts von ihm stehende Objekt an (in der Abbildung die Instanz der Klasse "Verwaltung"), das wiederum die gewünschten Aktionen entweder selbst ausführt oder per Nachricht an andere Objekte veranlaßt. Der Benutzer interagiert nur mit diesem Objekt, die restlichen Objekte und Nachrichten bleiben vor ihm verborgen.
Der Austausch von Nachrichten zwischen Objekten bedeutet im Grunde nur, daß ein Objekt eine Operation eines anderen Objektes aufruft. Dieser Vorgang wird als durchgezogener waagerechter Pfeil mit ausgefüllter Spitze von der Lebenslinie des sendenden Objekts zu der des empfangenden Objekts gezeichnet, wobei Objekte auch Nachrichten an sich selbst senden können, wie etwa "lieferscheine_zuordnen" in obiger Abbildung. Der Pfeil wird mit dem Namen der Nachricht bzw. Operation und den evtl. erforderlichen Parametern versehen. Nachdem die durch die Nachricht veranlaßte Aktion ausgeführt wurde, kennzeichnet ein gestrichelter Rückpfeil mit offener Spitze die Rückkehr zum aufrufenden Objekt. Bei der Rückkehr kann ggf.. ein Wert an den Urheber der Nachricht zurückgegeben werden, so etwa "lsnr" im Beispiel.
Eine bedingte Verzweigung wird durch mehrere von einem Punkt ausgehende Nachrichten-Pfeile dargestellt, von denen jeder vor dem Namen der Nachricht eine Bedingung in eckigen Klammern ("[", "]") trägt, unter der diese Alternative zu wählen und die betreffende Nachricht zu versenden ist. Bedingungen können in natürlicher Sprache, als Pseudocode oder in einer konkreten Programmiersprache formuliert werden. Ziele der einzelnen Pfeile sind alternative Aktivierungen desselben oder verschiedener Objekte. Im Beispieldiagramm wird in Abhängigkeit davon, ob ein Lieferschein für die aktuelle Bestellnummer ("bnr") vorhanden ist oder nicht, entweder die Nachricht "posten_anhängen(bnr, lfdnr)" an das Objekt "ls:Lieferschein" verschickt oder mit "neu(bnr, lfdnr)" die Erzeugung einer neuen Instanz ("ls_neu") der Klasse "Lieferschein" veranlaßt.
Wenn Nachrichten wiederholt werden sollen, wird dies durch ein Stern-Symbol "*" vor dem Namen der Nachricht kenntlich gemacht. Um die Anzahl der Iterationen festzulegen, kann hinter dem Stern-Symbol zusätzlich in eckigen Klammern eine Abbruchbedingung spezifiziert werden. Soll eine Menge von aufeinanderfolgenden Nachrichten wiederholt werden, umrahmt man sie wie in der Abbildung dargestellt und fügt eine Iterationsspezifikation hinzu. Iterationen und bedingte Verzweigungen können miteinander verknüpft werden, indem beispielsweise eine Iteration nur dann ausgeführt wird, wenn zuvor eine Bedingung erfüllt ist oder eine bedingte Verzweigung innerhalb einer Iteration auftritt.
Besteht zwischen dem durch das Sequenzdiagramm modellierten Anwendungsfall und einem anderen Anwendungsfall eine USES-Beziehung, so kann dies in der aktuellen Version der UML nur durch eine Anmerkung in Textform an der Stelle im Sequenzdiagramm, wo der Anwendungsfall benutzt wird, kenntlich gemacht werden. Eine eigene Notation hierfür gibt es nicht.
Ein weiteres Problem stellt das Fehlen eines "ELSE"-Teils bei bedingten Verzweigungen dar. Bei jedem Ast muß explizit eine Bedingung angegeben werden, unter der dieser Ast der Alternative gewählt wird. Also kann in der UML beispielsweise nicht direkt modelliert werden: "IF x <= y THEN x := z ELSE x := y END;". Es ist vielmehr erforderlich, dieses Konstrukt in zwei bedingte Verzweigungen aufzuspalten: "IF x <= y THEN x := z END; IF x > y THEN x := y END;".
Schließlich besteht noch die Möglichkeit, Kommentare in Sequenzdiagrammen zu plazieren, die die Modellierung näher erläutern. Diese Kommentare können frei in natürlicher Sprache formuliert werden und beliebige Länge haben.
Sequenzdiagramme haben als Mittel zur Beschreibung der dynamischen Struktur des zu modellierenden Anwendungssystems gewisse Vorteile gegenüber den Kollaborationsdiagrammen: