Czym jest diagram sekwencji#

Diagram sekwencji (sequence diagram) jest diagramem interakcji UML, który pokazuje, jak uczestnicy wymieniają komunikaty w określonym scenariuszu. Wyróżnia uczestników, ich linie życia i kolejność zdarzeń odczytywaną z góry na dół. Pomaga odpowiedzieć na pytania: kto wysyła komunikat, do kogo, w jakiej kolejności i jakie warianty przebiegu są możliwe.

Diagram jest szczególnie przydatny do rozwijania scenariusza przypadku użycia, wyjaśniania współpracy obiektów albo dokumentowania kontraktu między usługami. Pokazuje interakcję w wybranym kontekście, nie wszystkie możliwe zachowania całego systemu. Złożone rozgałęzienia i pętle można zapisać fragmentami łączonymi, lecz diagram sekwencji nie powinien stawać się wielostronicowym schematem całego algorytmu.

Uczestnicy i linie życia#

Uczestnik (participant) jest rolą, obiektem, aktorem, komponentem lub innym elementem biorącym udział w interakcji. U góry diagramu umieszcza się nagłówek uczestnika, a pionowa linia przerywana pod nim jest jego linią życia (lifeline). Linia wskazuje uczestnictwo w czasie przedstawionego scenariusza.

Uczestnika można opisać jako obiekt konkretnej klasy, np. usługa: Zamówienia, lub pokazać samą rolę, np. Bramka płatności. Zapis zależy od celu diagramu. Aktor często znajduje się po lewej stronie, a kolejne elementy systemu po prawej, ale rozmieszczenie nie zastępuje znaczenia komunikatów.

Linia życia może rozpoczynać się albo kończyć w trakcie scenariusza. Utworzenie obiektu można pokazać komunikatem skierowanym do nowej linii życia, której nagłówek zaczyna się na wysokości momentu utworzenia. Zniszczenie obiektu może być oznaczone symbolem X na końcu linii. Nie rysuj całej linii życia aż do dołu, jeśli obiekt zostaje zniszczony wcześniej.

Komunikaty i kierunek czasu#

Komunikat (message) jest przekazaniem informacji, sygnału, żądania lub wyniku między uczestnikami. Zwykle rysuje się go jako strzałkę od linii życia nadawcy do odbiorcy. Etykieta może zawierać nazwę, argumenty, zwracany wynik lub warunek. Strzałki komunikatów porządkuje się pionowo: zdarzenia wyżej zachodzą wcześniej niż te niżej, z uwzględnieniem relacji porządku opisanych w modelu.

Diagram nie jest domyślnie wykresem w skali czasu. Odległości pionowe są zwykle umowne i służą czytelności. Jeśli czas trwania, deadline lub opóźnienie mają znaczenie, dodaj ograniczenie czasu lub wyraźnie zapisz założenie. Nie wyciągaj wniosku, że komunikat trwa dłużej tylko dlatego, że strzałka jest dłuższa.

Komunikaty synchroniczne i asynchroniczne#

Komunikat synchroniczny oznacza wywołanie, w którym nadawca oczekuje na zakończenie obsługi lub odpowiedź zgodnie z przyjętym modelem. Zwykle ma linię ciągłą i grot wypełniony. Komunikat asynchroniczny oznacza przekazanie, które nie wymaga natychmiastowego oczekiwania nadawcy; jego symbol często ma grot otwarty. Dokładne oznaczenia mogą różnić się w narzędziach, dlatego legenda jest przydatna, jeśli diagram używa nietypowych strzałek.

Dobieraj typ komunikatu do semantyki interakcji, a nie tylko do wyglądu kodu. Wywołanie asynchroniczne może zakończyć się późniejszym komunikatem zwrotnym, a komunikat synchroniczny może być pokazany bez jawnego powrotu, jeśli odpowiedź nie jest istotna dla scenariusza.

Odpowiedź i komunikat zwrotny#

Wynik komunikatu można pokazać jako osobną strzałkę zwrotną, zwykle linią przerywaną. Jest to użyteczne, gdy odpowiedź decyduje o dalszym przebiegu, zawiera ważne dane albo rozjaśnia kontrakt. Pominięcie jawnego powrotu nie oznacza, że uczestnik niczego nie zwraca; może oznaczać, że odpowiedź jest nieistotna w tym widoku.

Nazwy komunikatów zapisuj jako operacje lub zdarzenia z argumentami, np. autoryzuj(kwota, token). Nie umieszczaj w etykiecie całego akapitu. Dłuższe znaczenie przenieś do opisu scenariusza.

Komunikat do samego siebie#

Komunikat może wychodzić z linii życia i wracać do tego samego uczestnika. Pokazuje wywołanie wewnętrznego zachowania, wywołanie rekurencyjne albo delegację do innej operacji w obrębie tego samego obiektu. Zagnieżdżone aktywacje mogą pokazać zagnieżdżenie wykonania.

Aktywacja i fokus wykonania#

Aktywacja (execution specification), często nazywana paskiem aktywacji lub fokusem sterowania, jest wąskim prostokątem umieszczonym na linii życia. Oznacza okres wykonania zachowania przez uczestnika. Komunikat synchroniczny może rozpoczynać aktywację odbiorcy; odpowiedź lub zakończenie operacji może odpowiadać jej końcowi.

Aktywacja nie jest stanem obiektu ani miernikiem dokładnego czasu wykonania. Jej długość jest zwykle schematyczna. Rysuj ją, gdy pomaga zrozumieć zagnieżdżenie, odpowiedzialność lub moment odpowiedzi; nadmiar prostokątów może zaśmiecić diagram.

Fragmenty łączone#

Fragment łączony (combined fragment) jest ramką obejmującą część interakcji i określającą, jak należy ją interpretować. Operator umieszcza się w nagłówku ramki, a warunki ochronne przy poszczególnych operandach. Najczęściej używane operatory to:

  • alt — alternatywy odpowiadające warunkowym wariantom, np. zaakceptowana albo odrzucona płatność;
  • opt — opcjonalny fragment, który może zostać wykonany, jeśli spełniony jest warunek;
  • loop — powtarzany fragment z warunkiem lub ograniczeniem iteracji;
  • par — operandy, które mogą być wykonywane współbieżnie;
  • break — warunkowa sekwencja zastępująca dalszą część interakcji w danym kontekście;
  • ref — odwołanie do innej interakcji lub diagramu;
  • critical — fragment krytyczny, którego wykonanie należy rozpatrywać jako niepodzielne względem współbieżnej interakcji;
  • assert, neg, ignore, consider — operatory do asercji, sekwencji niedozwolonych albo określenia, które komunikaty są brane pod uwagę.

Operator alt nie jest zwykłym rombem. Obejmuje warianty wraz z warunkami; w danym przebiegu wykonywany jest operand, którego warunek jest spełniony, zgodnie z regułami interakcji. Jeśli warunki nakładają się lub nie obejmują wszystkich przypadków, diagram może być niejednoznaczny.

Fragment loop nie określa automatycznie konkretnej liczby wykonań. Warunek iteracji lub ograniczenie trzeba podać, jeśli ma znaczenie. Fragment par wskazuje współbieżne zachowania, ale nie musi określać ich dokładnej kolejności między uczestnikami.

Przykład: złożenie zamówienia i autoryzacja płatności#

Diagram pokazuje interakcję klienta z interfejsem, usługą zamówień, bazą danych i bramką płatności. Po zapisaniu zamówienia usługa prosi bramkę o autoryzację. Fragment alt rozdziela zaakceptowaną i odrzuconą odpowiedź.

Klient przesyła zamówienie przez interfejs do usługi zamówień, która zapisuje je w bazie i prosi bramkę płatności o autoryzację; alternatywne odpowiedzi prowadzą do potwierdzenia albo komunikatu o błędzie.
Interakcja przy składaniu zamówienia z dwiema odpowiedziami bramki.

W komunikatach czytanych od góry do dołu klient przekazuje dane interfejsowi, a interfejs zleca utworzenie zamówienia. Usługa zapisuje zamówienie i czeka na potwierdzenie bazy, następnie wysyła żądanie do bramki. Fragment alt dokumentuje dwa wyniki i odpowiadające im skutki dla statusu oraz odpowiedzi interfejsu.

Diagram nie pokazuje szczegółów szyfrowania, ponowień po awarii bazy, timeoutu bramki, anulowania rezerwacji ani dokładnej transakcyjności zapisu. Jeśli mają znaczenie, dodaj je w osobnym fragmencie lub scenariuszu, zamiast zakładać, że odbiorca wywnioskuje je ze strzałek.

Utworzenie i zniszczenie uczestnika#

Uczestnik może zostać utworzony w trakcie interakcji. Komunikat create prowadzi do początku nowej linii życia w miejscu powstania obiektu. To odróżnia utworzenie instancji od wysłania zwykłego komunikatu do obiektu, który już istnieje.

Zniszczenie uczestnika można pokazać symbolem krzyżyka na końcu linii życia. Zdarzenie usunięcia powinno odpowiadać rzeczywistemu końcowi życia instancji, nie tylko wyjściu z zakresu ekranu, zakończeniu żądania czy zmianie stanu na Nieaktywny.

Komunikaty utracone i znalezione#

Komunikat utracony (lost message) ma znanego nadawcę, ale odbiorca znajduje się poza zakresem diagramu lub wiadomość nie dociera do zamierzonego miejsca. Komunikat znaleziony (found message) dociera do uczestnika, ale jego nadawca nie jest pokazany lub nie jest znany w danym widoku. Końce komunikatów oznacza się specjalnymi punktami końcowymi.

Używaj tych symboli, gdy brakujący kontekst jest świadomy i ważny. Nie zastępuj nimi zwykłego pominięcia komunikatu, jeśli diagram po prostu pokazuje wybrany fragment większej interakcji.

Jak tworzyć diagram sekwencji#

  1. Wybierz scenariusz. Opisz jeden przypadek, wynik lub sytuację błędną.
  2. Ustal uczestników. Uwzględnij aktora, elementy systemu i zewnętrzne usługi, które rzeczywiście uczestniczą.
  3. Określ granice odpowiedzialności. Nazwij lifelines na poziomie właściwym dla odbiorcy: obiekty, komponenty lub systemy.
  4. Wypisz komunikaty w kolejności. Każdy komunikat powinien mieć nadawcę, odbiorcę i znaczącą treść.
  5. Oznacz typ wiadomości. Rozróżnij wywołanie synchroniczne, asynchroniczne, odpowiedź, utworzenie lub zniszczenie, jeśli wpływa to na interpretację.
  6. Pokaż warunki i powtórzenia. Użyj alt, opt lub loop zamiast rozwijać każdą ścieżkę w osobny diagram bez potrzeby.
  7. Dodaj aktywacje tylko tam, gdzie pomagają. Nie przedstawiaj ich jako dokładnej osi czasu.
  8. Sprawdź kompletność odpowiedzi i błędów. Upewnij się, że wiadomo, jaki rezultat otrzymuje inicjator.
  9. Porównaj z przypadkiem użycia lub wymaganiem. Diagram powinien rozwijać ten sam scenariusz i używać spójnych nazw.

Diagram sekwencji jest często precyzyjniejszy po spisaniu scenariusza słowami. Najpierw ustal główny i alternatywne przebiegi, potem wybierz uczestników oraz komunikaty, które są istotne dla celu widoku.

Diagram sekwencji a diagram komunikacji#

Diagram sekwencji i diagram komunikacji przedstawiają interakcję z różnych perspektyw. Diagram sekwencji eksponuje kolejność komunikatów w pionowym czasie. Diagram komunikacji kładzie nacisk na relacje między uczestnikami, a kolejność oznacza numerami komunikatów. Wybierz widok odpowiadający pytaniu: co dzieje się po czym albo którzy uczestnicy są połączeni.

Diagram sekwencji a diagram aktywności#

Diagram aktywności pokazuje przepływ działań, decyzji i równoległych ścieżek. Diagram sekwencji pokazuje komunikaty pomiędzy uczestnikami. W tym samym scenariuszu aktywność może opisywać, jakie kroki są wykonywane, a sekwencja — jak uczestnicy wymieniają żądania i odpowiedzi podczas tych kroków.

Typowe błędy#

  • Traktowanie osi pionowej jako dokładnego czasu. Pokazuje przede wszystkim porządek, a nie skalę czasu.
  • Mylenie linii życia z aktywacją. Linia życia oznacza uczestnictwo; wąski prostokąt wskazuje fokus wykonania.
  • Utożsamianie każdej strzałki z wywołaniem synchronicznym. Zdarzenia, sygnały, odpowiedzi i komunikaty asynchroniczne mają różną semantykę.
  • Pominięcie odpowiedzi mającej wpływ na scenariusz. Jeśli wynik zmienia dalszy przebieg, pokaż go jawnie.
  • Nadużywanie fragmentów łączonych. Używaj ich do rzeczywistych warunków, pętli i współbieżności, a nie do modelowania każdego szczegółu programu.
  • Przeładowanie diagramu lifelines. Ogranicz uczestników do tych, którzy pomagają wyjaśnić interakcję.
  • Założenie, że par ustala kolejność. Fragment równoległy modeluje współbieżne operandy; nie narzuca ich pełnego porządku.
  • Pokazywanie wszystkich metod klas. Diagram sekwencji opisuje wybrany scenariusz, a nie kompletny interfejs obiektów.
  • Niespójne nazwy z diagramem klas lub przypadkiem użycia. Zachowuj nazwy uczestników i rezultatów w powiązanych widokach.
  • Brak wariantu błędnego. Jeśli odmowa lub timeout jest istotny, pokaż go albo wskaż w tekście, że pozostaje poza zakresem.

Co diagram sekwencji pokazuje, a czego nie#

Diagram sekwencji pokazuje uczestników interakcji, komunikaty, ich porządek, aktywacje i wybrane warianty zachowania. Ułatwia omawianie kontraktów między obiektami lub usługami oraz analizę scenariusza krok po kroku.

Nie przedstawia automatycznie wszystkich stanów uczestników, pełnej logiki biznesowej, architektury wdrożenia ani dokładnych czasów wykonania. Uzupełnij go diagramem aktywności, stanów, komponentów lub wdrożenia, jeśli dokumentacja ma odpowiedzieć również na te pytania.