Wysłanie przez obiekt komunikatu może być uzależnione od spełnienia pewnego warunku. Warunek ten, zapisywany wewnątrz nawiasów kwadratowych, może być wyspecyfikowany np. w języku naturalnym, w języku ustrukturalizowanym (np. OCL), w języku programowania, itp. Prosty warunek z Rys. 12 sprawdza wartość zmiennej i: jeżeli wartość ta wynosi 0, to wówczas wysyłany jest komunikat x; jeżeli wartość wynosi 1, to wysyłany jest komunikat y. Warunki na diagramie (a) są sprawdzane w różnych punktach czasowych, w związku z czym potencjalnie mogą zostać wysłane oba komunikaty. Natomiast na diagramie (b), gdzie warunki są sprawdzane jednocześnie, a zmienna i nie może być jednocześnie równa 0 i 1, może być wysłany co najwyżej jeden z komunikatów.

Rys. 12. Ilustracja zachowań warunkowych

Rozważmy Rys. 13. Przedstawia on sytuację, kiedy linia życia dla wystąpienia klasy K2 została rozdzielona na dwie gałęzie, dla podkreślenia faktu, że stan obiektu może wyglądać inaczej w zależności od tego, który z komunikatów x czy y zostanie wysłany.

Rys. 13. Rozgałęzienie linii życia obiektu

Także diagramy współpracy dopuszczają definiowanie warunków, nie jest jednak możliwe ilustrowanie na nich rozgałęzienia linii życia obiektu. Dlatego wydaje się, że poza najprostszymi sytuacjami, diagramy sekwencyjne lepiej modelują realizację bardziej złożonych (zwłaszcza z opcjonalnymi scenariuszami) przypadków użycia. Ponadto, dzięki posiadaniu środków innych niż tylko numeracja komunikatów (jak na diagramach współpracy), są bardziej przystosowane do ilustrowania zależności czasowych występujących między przesyłanymi komunikatami. Z kolei, diagramy współpracy są użyteczne w sytuacji, gdy bardziej niż operacje niezbędne do zrealizowania przypadku użycia interesuje nas struktura (klasy, asocjacje, itd.), na której te operacje będą wykonywane - diagram współpracy, traktowany jest wtedy jako wystąpienie fragmentu diagramu klas i stanowi podstawę do jego weryfikacji.