Czym jest diagram komunikacji#

Diagram komunikacji (communication diagram) jest diagramem interakcji UML. Pokazuje uczestników współpracy, połączenia między nimi oraz komunikaty wymieniane podczas scenariusza. Kolejność komunikatów zapisuje się przede wszystkim za pomocą numerów, a nie położenia w pionowej osi czasu.

Diagram pomaga odpowiedzieć na pytania: które obiekty lub role uczestniczą w scenariuszu, jak mogą się komunikować i w jakiej kolejności wysyłają wiadomości. Jest szczególnie użyteczny, gdy ważniejsza jest sieć współpracujących elementów niż szczegółowy przebieg w czasie.

W UML 2 diagram komunikacji należy do diagramów interakcji. W starszych materiałach można spotkać nazwę „diagram współpracy” (collaboration diagram); obecnie standardowa nazwa to „diagram komunikacji”.

Uczestnicy i połączenia#

Uczestnik diagramu reprezentuje rolę lub instancję biorącą udział w interakcji. Może być zapisany jako obiekt: Klasa, : Klasa albo nazwany bardziej ogólnie, gdy scenariusz nie wymaga wskazania klasy. Aktor zewnętrzny może inicjować wymianę komunikatów.

Linia między uczestnikami oznacza ścieżkę, przez którą mogą przesyłać komunikaty w przedstawionej współpracy. Nie jest to automatycznie połączenie sieciowe, zależność klas ani szczegółowa topologia wdrożenia. Jej znaczenie wynika z kontekstu modelu i roli, jaką odgrywa w interakcji.

Rozmieszczenie elementów można dostosować do czytelności. W przeciwieństwie do diagramu sekwencji samo położenie uczestników nie koduje czasu. To etykiety komunikatów oraz ich numeracja pozwalają odtworzyć przebieg.

Komunikaty i ich numerowanie#

Komunikat jest pokazany na połączeniu między nadawcą a odbiorcą. Strzałka wskazuje kierunek, a etykieta opisuje operację, sygnał lub przekazywane dane. Przykładowa etykieta może mieć postać 1: złóżZamówienie(dane).

Numer główny wskazuje kolejność w scenariuszu. Komunikaty z numerami 1, 2, 3 tworzą prosty przebieg. Zagnieżdżenie można przedstawić numerami hierarchicznymi, np. 1.1, 1.2 dla wywołań wykonywanych w ramach komunikatu 1. Dokładna konwencja zapisu zależy od narzędzia i przyjętej notacji, dlatego stosuj ją konsekwentnie i objaśnij, jeśli odbiorca może ją odczytać niejednoznacznie.

Warunek można zapisać w nawiasach kwadratowych, np. [płatność zaakceptowana]. Iterację można oznaczyć gwiazdką lub opisem pętli. W praktyce warto unikać nadmiernej komplikacji numeracji: jeśli alternatywy, pętle i współbieżność stają się trudne do odczytania, diagram sekwencji może lepiej wyrazić przebieg.

Przykład: komunikacja przy składaniu zamówienia#

Poniższy przykład przedstawia klienta, interfejs sklepu, usługę zamówień, bazę danych oraz bramkę płatności. Numerowane etykiety pokazują kolejność działań, a warunki rozdzielają dwa wyniki autoryzacji.

Diagram komunikacji: klient wysyła zamówienie przez interfejs do usługi zamówień, która zapisuje je w bazie danych i prosi bramkę płatności o autoryzację.
Uczestnicy i numerowane komunikaty na głównej ścieżce składania zamówienia.

Graf przedstawia współpracę, a numery odtwarzają główną ścieżkę scenariusza. Wynik autoryzacji może być zaakceptowany albo odrzucony; w tym uproszczonym widoku szczegóły obu ścieżek zostały pominięte, aby skupić się na połączeniach uczestników.

Diagram celowo pomija timeout, ponowienia, ochronę przed podwójnym obciążeniem i transakcje kompensacyjne. Jeśli któryś z tych aspektów jest istotny, dodaj osobny scenariusz lub wybierz diagram, na którym można czytelniej pokazać warunki czasowe i rozgałęzienia.

Jak przygotować diagram komunikacji#

  1. Wybierz jeden scenariusz i określ jego początek oraz oczekiwany rezultat.
  2. Wypisz uczestników, którzy rzeczywiście wysyłają lub odbierają komunikaty.
  3. Połącz uczestników, między którymi zachodzi komunikacja w tym scenariuszu.
  4. Zapisz wiadomości na odpowiednich połączeniach, wskazując kierunek i znaczenie.
  5. Ponumeruj komunikaty według kolejności; użyj numerów zagnieżdżonych, jeśli pokazujesz wywołania podrzędne.
  6. Oznacz istotne warunki, iteracje lub warianty i sprawdź, czy da się jednoznacznie odtworzyć przebieg.
  7. Usuń uczestników i komunikaty, które nie wspierają celu diagramu.
  8. Porównaj nazwy oraz rezultaty z przypadkiem użycia, diagramem sekwencji i modelem klas.

Warto najpierw opisać scenariusz kilkoma zdaniami. Następnie można wyprowadzić z niego role, połączenia i komunikaty. Diagram powinien przedstawiać jeden spójny kontekst, a nie wszystkie możliwe interakcje systemu.

Diagram komunikacji a diagram sekwencji#

Oba diagramy opisują interakcję i mogą przedstawiać te same uczestniki oraz komunikaty. Diagram komunikacji eksponuje połączenia między uczestnikami, a kolejność koduje numerami. Diagram sekwencji ustawia uczestników w kolumnach i układa komunikaty od góry do dołu, dzięki czemu lepiej pokazuje kolejność, aktywacje i warianty przebiegu.

Wybierz diagram komunikacji, gdy chcesz pokazać, kto z kim współpracuje. Wybierz sekwencję, gdy ważne jest, co dzieje się po czym, gdzie uczestnik czeka na odpowiedź albo jak przebiegają warianty czasowe.

Diagram komunikacji a diagram klas#

Diagram klas opisuje typy, ich cechy i relacje w modelu statycznym. Diagram komunikacji opisuje uczestników konkretnej interakcji i komunikaty przesyłane między nimi w scenariuszu. Podobna linia na obu diagramach nie musi mieć tego samego znaczenia ani zakresu.

Komunikat w diagramie komunikacji może odpowiadać operacji klasy, ale diagram nie jest automatycznie kompletną specyfikacją jej interfejsu. Utrzymuj spójne nazwy, a szczegóły struktury przedstawiaj na diagramie klas.

Typowe błędy#

  • Odczytywanie rozmieszczenia jako osi czasu. Kolejność komunikatów wynika z numeracji i semantyki, nie z tego, który obiekt znajduje się wyżej.
  • Brak kierunku strzałki. Odbiorca powinien wiedzieć, kto wysyła, a kto otrzymuje wiadomość.
  • Niespójne numery. Numeracja powinna prowadzić przez scenariusz bez sprzeczności i niejasnych skoków.
  • Traktowanie połączenia jak topologii sieci. Linia reprezentuje ścieżkę komunikacji w modelu, a niekoniecznie fizyczny kanał.
  • Zbyt wiele uczestników. Elementy bez istotnej roli utrudniają odczytanie współpracy.
  • Zbyt rozbudowana hierarchia numerów. Głębokie zagnieżdżenia bywają czytelniejsze w diagramie sekwencji lub osobnych interakcjach.
  • Mieszanie wariantów bez warunków. Oznacz, które wiadomości należą do danej ścieżki.
  • Mylące etykiety. Nazwy komunikatów powinny wskazywać intencję lub dane, a nie być ogólnym „wywołaniem”.
  • Modelowanie wszystkich szczegółów implementacji. Diagram ma wyjaśnić współpracę, nie zastąpić kodu ani pełnego śladu wykonania.

Co diagram komunikacji pokazuje, a czego nie#

Diagram komunikacji pokazuje uczestników, połączenia w ramach współpracy, kierunek i numerowaną kolejność komunikatów oraz wybrane warunki. Ułatwia omówienie odpowiedzialności i zależności komunikacyjnych w jednym scenariuszu.

Nie zapewnia tak czytelnej osi przebiegu w czasie jak diagram sekwencji, nie opisuje wszystkich stanów obiektów i nie określa sam z siebie architektury wdrożenia. Uzupełnij go odpowiednim diagramem, jeśli trzeba wyjaśnić kolejność czasową, przepływ procesu, cykl życia albo fizyczne rozmieszczenie systemu.