Najpierw wybierz diagram i jego granicę#
System zewnętrzny nie ma jednego obowiązkowego symbolu UML. W diagramie przypadków użycia może być aktorem, w diagramie komponentów — elementem dostarczającym lub wymagającym interfejsu, w diagramie sekwencji — uczestnikiem interakcji, a w diagramie wdrożenia — węzłem, artefaktem lub elementem połączonym z infrastrukturą. Wybór zależy od tego, co diagram ma wyjaśnić.
W diagramie przypadków użycia operator płatności jest zewnętrznym aktorem wobec granicy sklepu. Pokazuje udział w celu, a nie szczegółowy kontrakt API ani rozmieszczenie usług. Jeżeli te szczegóły są istotne, użyj innego widoku UML.
Diagram przypadków użycia: aktor#
Użyj aktora, gdy system zewnętrzny uczestniczy w przypadku użycia systemu, który modelujesz. Nazwij go zrozumiale, na przykład Operator płatności, Krajowy rejestr lub nazwą konkretnej usługi. Umieść aktora poza granicą i połącz z przypadkiem użycia, w którym rzeczywiście uczestniczy.
Aktor nie określa, czy system inicjuje komunikację, odpowiada na żądanie, czy działa asynchronicznie. Opisz to w scenariuszu lub diagramie interakcji. Nie wprowadzaj systemu zewnętrznego jako aktora, jeśli chcesz jedynie zaznaczyć użycie jego bazy lub pliku przez wewnętrzną implementację.
Diagram komponentów: kontrakt i zależność#
Na diagramie komponentów pokaż zewnętrzny system jako komponent dostarczający interfejs, którego wymaga twój system, albo jako klienta twoich usług. Przedstaw interfejsy wymagane i dostarczane, porty oraz połączenia, jeśli kontrakt i granica integracji są ważne.
To dobry wybór do pokazania zależności architektonicznych i odpowiedzialności. Dodaj tylko tyle informacji, by wskazać potrzebne operacje lub usługi; protokół, wersjonowanie, autoryzację, format danych i warunki błędów można opisać w specyfikacji interfejsu.
Diagram sekwencji: komunikacja w scenariuszu#
Na diagramie sekwencji system zewnętrzny może być linią życia, która wymienia komunikaty z uczestnikami modelowanego scenariusza. Użyj tej perspektywy, gdy liczy się kolejność żądań i odpowiedzi, alternatywne wyniki, timeout lub asynchroniczne zdarzenia.
Uczestnik na diagramie sekwencji nie jest automatycznie aktorem ani komponentem. Linia życia może reprezentować obiekt, rolę, system lub inny uczestniczący element; znaczenie powinno wynikać z kontekstu i nazw. Pokaż scenariusz istotny dla pytania, nie całą powierzchnię API.
Diagram wdrożenia: węzeł i połączenie#
Jeśli interesuje cię lokalizacja i środowisko uruchomieniowe, pokaż zewnętrzny system jako węzeł lub grupę węzłów. Dodaj artefakty i ścieżki komunikacji, jeżeli są znane i istotne. Węzeł opisuje środowisko, nie rolę biznesową ani sam kontrakt usługi.
Diagram nie powinien udawać wiedzy, której nie ma. Jeżeli nie znasz infrastruktury zewnętrznej, pokaż jedynie granicę lub usługę abstrakcyjną i zapisz założenie. Nie wpisuj niezweryfikowanych adresów IP, regionów chmurowych ani protokołów.
Oddziel perspektywy#
Ten sam system może wystąpić w kilku diagramach: jako aktor wobec przypadku użycia, komponent w architekturze, uczestnik w scenariuszu i węzeł w topologii. Te widoki są spójne, gdy mają tę samą nazwę lub odwołanie, ale odpowiadają na różne pytania.
W niewielkim projekcie można pokazać kilka poziomów na jednym diagramie, jeśli jest to czytelne. W złożonym rozwiązaniu oddziel cele, kontrakty, interakcje i wdrożenie. Wyraźnie określ granicę „zewnętrzności”: może zależeć od systemu lub podsystemu, nie od organizacji czy fizycznej sieci.
Informacje o integracji, które warto dopisać#
Gdy integracja wpływa na projekt, opisz protokół, format wiadomości, uwierzytelnienie, autoryzację, błędy, limity czasu, ponowienia, idempotencję, wersje API, kierunek inicjowania komunikacji i odpowiedzialność za dane. Sam symbol aktora lub komponentu nie określa tych szczegółów.
Nie wszystkie te właściwości muszą znaleźć się na diagramie. Umieść je w kontrakcie, specyfikacji integracji, katalogu interfejsów albo wymaganiach niefunkcjonalnych i powiąż z właściwym widokiem.
Typowe błędy#
- Jeden symbol użyty niezależnie od diagramu. Rola aktora, komponent i węzeł oznaczają różne aspekty.
- Granica systemu nieokreślona. Bez niej nie wiadomo, dlaczego element jest zewnętrzny.
- System zewnętrzny pominięty w scenariuszu błędu. Timeout i niedostępność często wpływają na zachowanie.
- Aktor uznany za specyfikację API. Do kontraktu użyj interfejsów lub osobnej dokumentacji.
- Elementy infrastruktury dopisane bez wiedzy. Oznacz założenia i używaj poziomu abstrakcji adekwatnego do danych.
- Diagram przeciążony kilkoma perspektywami. Rozdziel widoki, gdy odbiorca traci główną informację.
- Wniosek o inicjowaniu wyciągnięty z połączenia aktora. Szczegółowy kierunek komunikacji pokaż w interakcji.
Podsumowanie#
Dobierz symbol systemu zewnętrznego do pytania: aktor dla celu, komponent dla kontraktu, linia życia dla przebiegu komunikatów, węzeł dla środowiska. Najpierw ustal granicę, a szczegóły integracji opisz w odpowiedniej specyfikacji. Kilka spójnych diagramów daje lepszy obraz niż jeden widok mieszający wszystkie poziomy.