Czym jest komunikat#
Komunikat (message) na diagramie sekwencji reprezentuje przekazanie informacji lub żądania między uczestnikami interakcji. Łączy linię życia nadawcy z linią życia odbiorcy i jest umieszczony na osi czasu, dzięki czemu widać, kto inicjuje daną część zachowania oraz w jakiej kolejności. Komunikat może odpowiadać wywołaniu operacji, wysłaniu sygnału, odpowiedzi albo innemu zdarzeniu interakcji.
Strzałka komunikatu ma grot przy odbiorcy. Nazwa i argumenty powinny opisywać znaczenie wiadomości, a nie jedynie implementacyjny szczegół. Diagram pokazuje interakcję z wybranego punktu widzenia; nie stanowi pełnej listy metod, które musi mieć każdy obiekt.
W przykładzie zamówienie przechodzi od klienta do aplikacji, a następnie aplikacja prosi magazyn o rezerwację. Linie przerywane oznaczają odpowiedzi w użytej notacji. To uproszczony przebieg: diagram nie określa wszystkich błędów, czasu oczekiwania ani gwarancji transakcyjnych.
Wywołanie synchroniczne i asynchroniczne#
Komunikat synchroniczny oznacza wywołanie, przy którym nadawca oczekuje na zakończenie obsługi lub wynik w danym przebiegu interakcji. Jego zapis zwykle wykorzystuje grot wskazujący wywołanie. Komunikat asynchroniczny oznacza przekazanie, po którym nadawca może kontynuować bez oczekiwania na zakończenie obsługi; typowe notacje używają otwartego grotu. Dokładny kształt grotów i styl linii należy czytać zgodnie ze standardową notacją lub legendą narzędzia.
Synchroniczność nie mówi sama o tym, czy komunikacja odbywa się w jednym wątku, przez sieć czy w procesie. Asynchroniczne API może mieć synchroniczną fazę wysyłania, a wywołanie sieciowe może blokować klienta. Modeluj semantykę interakcji, a decyzje platformy zapisuj odrębnie.
Odpowiedź i wartość zwracana#
Odpowiedź (reply message) pokazuje wynik lub zakończenie obsługi wcześniejszego komunikatu. Często zapisuje się ją linią przerywaną i podpisuje zwracaną wartością, ale diagram może pominąć odpowiedź, gdy nie wnosi ona istotnej informacji lub powrót jest oczywisty z wywołania synchronicznego.
Odpowiedź nie jest tym samym co nowy komunikat inicjujący niezależne zachowanie. Jeśli system później wysyła zdarzenie lub powiadomienie, przedstaw je jako odrębny komunikat od właściwego nadawcy. Nie pokazuj wyniku dwa razy, jeżeli model nie zakłada odrębnych wiadomości.
Samowywołanie, tworzenie i zakończenie#
Komunikat może wracać do tej samej linii życia, pokazując wywołanie własnej operacji lub rekurencję. Wcięta aktywacja pomaga zobaczyć zagnieżdżenie, ale nie każdy diagram musi ją pokazywać.
Komunikat tworzący obiekt prowadzi do początku nowej linii życia; nagłówek uczestnika pojawia się w miejscu utworzenia, a niekoniecznie na górze diagramu. Zakończenie instancji może być zaznaczone krzyżykiem na końcu jej linii życia. Użyj tych oznaczeń, gdy czas życia obiektu jest częścią wyjaśnianego zachowania, a nie jako ozdoby.
Komunikaty znalezione i utracone#
Komunikat znaleziony (found) dociera do interakcji z nieznanego lub niewidocznego nadawcy. Komunikat utracony (lost) opuszcza pokazany model bez widocznego odbiorcy. Notacja z końcówką wypełnioną lub otwartą może wskazywać takie sytuacje w narzędziu modelującym. W diagramie dla początkujących częściej lepiej jawnie dodać uczestnika albo objaśnić pominięcie, ponieważ abstrakcyjne końcówki mogą być mylące.
Warunki, pętle i równoległość#
Komunikaty można umieszczać w ramach interakcji, które wyrażają warunki, iteracje lub współbieżność. Fragment alt rozdziela warianty, opt pokazuje opcjonalny przebieg, loop — powtarzanie, a par — współbieżne fragmenty. Warunki powinny być czytelne i wzajemnie zrozumiałe. Nie zastępuj kompletną logikę programu gęstym diagramem sekwencji; złożone algorytmy mogą czytelniej wyglądać na diagramie aktywności.
Kolejność pionowa komunikatów wyraża porządek w ramach przedstawionej interakcji, ale nie jest precyzyjną miarą czasu. Poziome położenie linii życia służy układowi, nie oznacza kolejności ważności ani kierunku przepływu danych.
Jak nazywać komunikaty#
Używaj nazw wyrażających intencję, takich jak autoryzujPlatnosc(kwota) albo zarezerwowano(produkty). Czasownik, nazwa zdarzenia lub krótki opis stanu wyniku pomaga odróżnić żądanie od odpowiedzi. Dodawaj argumenty tylko wtedy, gdy wpływają na zrozumienie przebiegu; nie przepisuj całych sygnatur API.
Jeśli wiadomość reprezentuje błąd lub odmowę, nazwij ten rezultat jawnie albo pokaż alternatywny fragment. Diagram zawierający wyłącznie ścieżkę sukcesu nie powinien sugerować, że inne wyniki nie istnieją — opisz jego zakres w podpisie lub tekście.
Typowe błędy#
- Grot po stronie nadawcy. Strzałka wskazuje odbiorcę komunikatu.
- Kolejność pozioma odczytana jako czas. Czas biegnie z góry w dół; szerokość służy rozplanowaniu uczestników.
- Odpowiedź potraktowana jak nowe żądanie. Pokaż odrębny komunikat tylko wtedy, gdy rzeczywiście istnieje osobna interakcja.
- Asynchroniczność utożsamiona z technologią. Symbol wyraża sposób oczekiwania w interakcji, nie protokół transportowy.
- Każde wywołanie metody narysowane. Pokazuj komunikaty istotne dla pytania diagramu.
- Pominięty rezultat błędny. Uwzględnij ważne alternatywy albo jasno ogranicz diagram do scenariusza sukcesu.
- Zbyt skomplikowana logika w jednym diagramie. Rozbij przebieg lub wybierz inny diagram zachowania.
Podsumowanie#
Komunikat UML pokazuje przekazanie informacji między uczestnikami interakcji; jego grot wskazuje odbiorcę, a położenie pionowe — kolejność. Rodzaj komunikatu może wyrażać wywołanie synchroniczne, asynchroniczne, odpowiedź, utworzenie lub zakończenie. Nazwy i fragmenty warunkowe dobieraj do celu diagramu, a nie do pełnego odwzorowania kodu.