Jak modelować komunikację między obiektami?

Zacznij od scenariusza, nie od klas#

Modelowanie komunikacji między obiektami polega na opisaniu, jak uczestnicy współpracują, aby osiągnąć konkretny rezultat. Najpierw wybierz jeden scenariusz — np. udaną rezerwację oraz ważny wariant odmowy — a następnie określ nadawców, odbiorców, komunikaty i kolejność zdarzeń. Dopiero później dopasuj nazwy do operacji, klas lub usług.

Komunikat na diagramie jest częścią interakcji, a nie automatycznie gotową metodą w kodzie. W analizie może reprezentować żądanie na poziomie biznesowym; w projekcie może być precyzyjnym wywołaniem operacji. Zawsze określ, na jakim poziomie abstrakcji pracujesz.

Wybierz diagram do pytania#

Diagram sekwencji pokazuje uczestników jako linie życia oraz porządek komunikatów od góry do dołu. Jest dobrym wyborem, gdy istotne są odpowiedzi, warunki, oczekiwanie albo kolejność. Diagram komunikacji podkreśla sieć powiązań uczestników, a porządek wiadomości zapisuje numerami. Użyj go, gdy najważniejsze jest, kto z kim współpracuje.

Oba diagramy mogą opisywać tę samą interakcję. Nie musisz utrzymywać obu widoków dla każdego scenariusza. Dodaj drugi, gdy odbiorcy potrzebują odpowiedzieć na inne pytanie, a nie tylko zobaczyć kopię tej samej informacji.

Wyznacz uczestników i odpowiedzialności#

Uczestnik może być aktorem, obiektem, komponentem lub systemem zewnętrznym — zależnie od skali diagramu. Ustal systemową granicę i wybierz te lifelines, które naprawdę wpływają na scenariusz. Nazwij je na poziomie, który odbiorca potrafi rozpoznać: interfejs: Sklep, rezerwacja: SerwisRezerwacji, magazyn: Magazyn.

Przydzielaj odpowiedzialności tak, aby nazwy komunikatów odzwierciedlały intencję nadawcy i rolę odbiorcy. Unikaj obiektu System obsługującego wszystkie czynności oraz uczestników bez znaczącej odpowiedzialności. Jeśli komunikat prowadzi do kilku niepowiązanych obowiązków jednego obiektu, rozważ, czy granice odpowiedzialności są poprawne.

Zapisz komunikaty i ich przepływ#

Każdy komunikat powinien mieć nadawcę, odbiorcę i zrozumiałą intencję. Nazwij go czasownikiem lub zdarzeniem, a parametry dodaj wtedy, gdy potrzebne są do interpretacji: sprawdźDostępność(produkt, okres). Wynik może być osobną odpowiedzią, jeśli zmienia dalszy przebieg albo jest ważny dla kontraktu.

Rozróżnij wywołania synchroniczne od asynchronicznych. Wywołanie synchroniczne modeluje oczekiwanie nadawcy na zakończenie obsługi lub wynik zgodnie z danym poziomem modelu. Asynchroniczny sygnał nie wymaga takiego oczekiwania. Dobór strzałki wynika z semantyki interakcji, nie z preferencji wizualnej. Jeżeli typ strzałki jest istotny, sprawdź, jak obsługuje go używane narzędzie.

Odpowiedź można pokazać linią przerywaną, lecz nie każda interakcja wymaga jawnego rysowania wszystkich zwrotów. Dodaj ją, gdy wynik jest istotny, a pominięcie mogłoby sugerować brak informacji zwrotnej. Pamiętaj, że powrót po wywołaniu a samodzielny komunikat asynchroniczny mają różne znaczenie.

Uwzględnij warunki, pętle i współbieżność#

Przed rysowaniem zidentyfikuj warunki, które zmieniają przebieg. alt przedstawia alternatywne fragmenty wraz z warunkami; opt zachowanie opcjonalne; loop powtarzanie; par współbieżne fragmenty. Upewnij się, że warunki są zrozumiałe i że diagram nie sugeruje niemożliwej ścieżki.

Nie rozwijaj każdej reguły biznesowej jako osobnej strzałki. Jeśli powstaje wiele warunków, powtórzeń i wyjątków, podziel scenariusz lub użyj diagramu aktywności czy maszyny stanów dla odpowiedniego aspektu. Długie opisy umieść w scenariuszu tekstowym, a na strzałkach pozostaw zwięzłe nazwy komunikatów.

Przykład: rezerwacja produktu#

Scenariusz rozdziela sprawdzenie dostępności od utworzenia rezerwacji, bo ich wyniki mają różne znaczenie. W rzeczywistym systemie samo sprawdzenie, a potem rezerwacja może być podatne na równoczesne żądania; potrzebna może być atomowa operacja rezerwacji albo ponowna walidacja. Diagram nie rozstrzyga tego problemu i nie powinien sugerować bezpieczeństwa współbieżnego, którego system nie zapewnia.

Powiąż interakcję z innymi modelami#

Nazwy uczestników powinny być spójne z diagramem klas, komponentów lub architektury, jeżeli diagramy opisują ten sam system na zbliżonym poziomie. Nazwy wiadomości mogą odpowiadać operacjom, ale w analizie pozostają opisem współpracy, zanim projekt zostanie ustalony.

Przypadek użycia określa cel aktora, diagram aktywności może opisać przepływ procesu, a diagram sekwencji pokazuje wymianę wiadomości między elementami w konkretnym scenariuszu. Ustal relację między widokami: które kroki przypadku użycia są przedstawione w interakcji i jakie założenia współdzielą.

Sprawdź model na pytaniach kontrolnych#

• Czy wiadomo, jaki scenariusz i rezultat opisano?
• Czy każdy komunikat ma uzasadnionego nadawcę i odbiorcę?
• Czy typ komunikatu odpowiada temu, czy nadawca czeka na wynik?
• Czy odpowiedzi, błędy i warunki zmieniające dalszy przebieg są jawne?
• Czy uczestnicy mają spójne odpowiedzialności?
• Czy nazwy odpowiadają poziomowi analizy albo projektu?
• Czy nie sugerujesz transakcyjności, atomowości lub dokładnego czasu bez uzasadnienia?
• Czy model zgadza się z wymaganiami i pozostałymi diagramami?

Przejdź przez każdą ścieżkę od początku do końca i spróbuj opisać ją zdaniami. Jeśli nie można ustalić, kto wysyła wiadomość, kto odpowiada albo co dzieje się po błędzie, doprecyzuj model.

Typowe błędy#

• Diagram bez jednego scenariusza. Mieszanina niezależnych przebiegów staje się trudna do sprawdzenia.
• Za dużo lifelines. Ogranicz uczestników do tych, którzy wyjaśniają odpowiedzialności.
• Komunikaty nazwane jako techniczne szczegóły za wcześnie. Dobierz poziom abstrakcji do odbiorcy.
• Każda strzałka synchroniczna. Rozróżniaj żądania, odpowiedzi, zdarzenia i komunikaty asynchroniczne.
• Odpowiedź pozbawiona znaczenia. Jeśli wpływa na dalsze kroki, przedstaw jej wynik.
• Warunek ukryty w komentarzu. Wariant powinien być czytelnie powiązany z fragmentem, którego dotyczy.
• par użyty dla alternatywy. Wybór ścieżki to nie współbieżność.
• Przeciążone aktywacje i szczegóły. Pokaż je, gdy coś objaśniają.
• Mylenie poprawnego diagramu z gwarancją implementacji. Model opisuje zamierzone zachowanie; nie dowodzi, że kod je realizuje.
• Pominięcie współbieżności. Sprawdź wyścigi, idempotencję i możliwość powtórzeń, jeśli uczestnicy działają równolegle.

Lista kontrolna#

• Czy cel, scenariusz i jego zakres są jawne?
• Czy uczestnicy są dobrani i nazwani na właściwym poziomie?
• Czy komunikaty mają czytelny kierunek i intencję?
• Czy typy komunikatów odpowiadają oczekiwanemu zachowaniu?
• Czy warunki, pętle, odpowiedzi i błędy są wystarczająco opisane?
• Czy relacje z innymi diagramami i wymaganiami są spójne?
• Czy diagram jest czytelny i nie zastępuje niepotrzebnie innych widoków?

Modeluj komunikację od scenariusza do odpowiedzialności i wiadomości. Diagram ma objaśniać współpracę, a nie zgadywać strukturę programu ani obiecywać właściwości, których nie potwierdzają wymagania i projekt.