Diagram wdrożenia

Czym jest diagram wdrożenia#

Diagram wdrożenia (deployment diagram) pokazuje wybrane elementy środowiska uruchomieniowego systemu oraz sposób rozmieszczenia na nich oprogramowania. Pomaga odpowiedzieć na pytania: na jakich urządzeniach lub środowiskach działa system, gdzie trafiają jego artefakty i jak węzły komunikują się ze sobą.

Diagram jest strukturalnym widokiem konfiguracji w czasie wykonania. Może przedstawiać sprzęt, oprogramowanie infrastrukturalne, artefakty i ścieżki komunikacji. Nie jest sam w sobie kompletną instrukcją instalacji, schematem sieci ani opisem algorytmu aplikacji. Zakres i poziom szczegółowości trzeba dobrać do odbiorcy: inny widok będzie potrzebny do rozmowy o architekturze, a inny do planowania konkretnego wdrożenia.

Kiedy używać diagramu wdrożenia#

Użyj go, gdy ważne jest fizyczne lub wykonawcze rozmieszczenie systemu: które urządzenia biorą udział, gdzie działają procesy, które artefakty są wdrażane na danych węzłach oraz którędy odbywa się komunikacja. Diagram może wspierać projektowanie architektury, dokumentowanie środowisk testowych i produkcyjnych, omawianie wymagań infrastrukturalnych oraz analizę granic zaufania i punktów integracji.

Diagram wdrożenia jest szczególnie przydatny, gdy taki sam logiczny moduł może być rozmieszczony na różne sposoby albo gdy układ środowiska wpływa na dostępność, opóźnienia, bezpieczeństwo lub skalowanie. Nie zastępuje jednak decyzji o tych właściwościach: jeżeli replikacja, szyfrowanie, zapora czy redundancja mają znaczenie, trzeba je wyraźnie zaznaczyć i opisać.

Nie wybieraj tego diagramu do pokazywania wyłącznie podziału na odpowiedzialności programowe. Do logicznych modułów i ich interfejsów lepszy jest diagram komponentów. Diagram wdrożenia może oba widoki powiązać, ale odpowiada na pytanie o uruchomienie i rozmieszczenie.

Główne elementy notacji#

Węzeł#

Węzeł (node) to element wykonawczy, który może przetwarzać lub przechowywać oprogramowanie. W diagramie może oznaczać urządzenie, serwer, maszynę wirtualną, kontener, środowisko wykonawcze, urządzenie wbudowane albo inny element infrastruktury. UML rozróżnia m.in. urządzenie (device) oraz środowisko wykonawcze (execution environment), które może być zagnieżdżone wewnątrz urządzenia lub innego węzła.

W notacji węzeł jest zwykle rysowany jako prostopadłościan. Węzły mogą zawierać inne węzły, artefakty lub elementy reprezentujące wdrożone oprogramowanie. Typ i rola węzła mogą być doprecyzowane nazwą, stereotypem lub właściwościami. Nie zakładaj, że sam trójwymiarowy kształt oznacza konkretny system operacyjny, dostawcę chmury ani klasę sprzętu.

Węzeł jako typ opisuje rodzaj środowiska, np. Serwer aplikacyjny. Instancja węzła opisuje konkretny egzemplarz w danej konfiguracji, np. serwer01: Serwer aplikacyjny. Rozróżnienie jest użyteczne, gdy diagram pokazuje topologię z konkretnymi maszynami albo liczbą replik.

Artefakt#

Artefakt (artifact) jest fizycznym elementem informacji wykorzystywanym lub wytwarzanym przez proces rozwoju oprogramowania, który może być wdrożony na węźle. Przykładami są plik wykonywalny, pakiet aplikacji, biblioteka, skrypt wdrożeniowy, plik konfiguracyjny, obraz kontenera lub dokument. Artefakt jest reprezentacją dostarczanej postaci oprogramowania; komponent lub moduł opisuje jego logiczną rolę.

Na diagramie artefakt może być pokazany z nazwą i stereotypem «artifact», a zależność wdrożenia może wskazywać, na którym węźle jest instalowany. W prostym rysunku często umieszcza się artefakt wewnątrz węzła, by pokazać jego wdrożenie. Warto rozróżnić artefakt źródłowy od wynikowego, jeśli oba są istotne.

Ścieżka komunikacji#

Ścieżka komunikacji (communication path) łączy węzły i pokazuje, że mogą wymieniać informacje. Zwykle jest rysowana linią ciągłą. Można ją opisać protokołem, kanałem, siecią lub inną ważną właściwością, np. HTTPS, TCP albo „sieć wewnętrzna”. Etykieta nie powinna sugerować, że diagram zawiera pełną konfigurację transportu.

Ścieżka nie musi oznaczać bezpośredniego fizycznego kabla. Może reprezentować logiczny kanał komunikacji przez sieć lub pośredników, zależnie od poziomu abstrakcji. Jeśli przez połączenie biegnie ruch przez load balancer, proxy lub bramę, a element ten jest ważny dla rozumienia architektury, pokaż go jawnie.

Specyfikacja wdrożenia i manifest#

Specyfikacja wdrożenia (deployment specification) opisuje parametry wdrożenia artefaktu na węźle. Może odwoływać się do informacji potrzebnych do skonfigurowania środowiska, takich jak parametry uruchomienia lub wymagane właściwości. Manifest (manifestation) wiąże artefakt z elementem modelu, który ten artefakt reprezentuje, np. komponentem. Te elementy są przydatne w modelu szczegółowym i narzędziowym, lecz nie trzeba ich dodawać do każdego diagramu poglądowego.

Jeśli parametry mają być odtwarzalne w konkretnym środowisku, pojedynczy rysunek zwykle nie wystarcza. Wtedy potrzebne są wersjonowane pliki konfiguracji, manifesty wdrożeniowe lub dokumentacja operacyjna. Diagram może wskazywać ich rolę bez powielania całej konfiguracji.

Przykład: wdrożenie sklepu internetowego#

Poniższy przykład pokazuje przeglądarkę użytkownika, węzeł serwera aplikacji z wdrożonym artefaktem oraz bazę danych. Przeglądarka komunikuje się z serwerem przez HTTPS, a serwer z bazą danych przez wewnętrzny kanał. Nazwy są celowo ogólne, bo diagram ilustruje strukturę, a nie konkretnego dostawcę infrastruktury.

Zagnieżdżone artefakty wskazują, na jakim węźle działają lub są przechowywane przedstawione elementy. Rysunek nie precyzuje, czy sklep.war działa na maszynie wirtualnej, w kontenerze czy bezpośrednio w środowisku serwera aplikacyjnego. Nie określa też konkretnego portu, uwierzytelniania ani tego, czy połączenie do bazy jest szyfrowane.

Przykład przedstawia logiczny widok wdrożenia. W produkcyjnej dokumentacji należy dopisać lub pokazać szczegóły istotne dla pytania: instancje i ich liczebność, środowiska, strefy sieciowe, load balancer, repliki bazy, zapory lub usługi zewnętrzne. Nie dodawaj tych elementów, jeśli nie są znane — diagram nie powinien zamieniać założeń w fakty.

Jak czytać diagram wdrożenia#

1. Zidentyfikuj granicę systemu i elementy zewnętrzne.
2. Odczytaj węzły: ustal, które są sprzętem, a które środowiskami wykonawczymi lub innymi elementami infrastruktury.
3. Sprawdź zagnieżdżenie: artefakty i podwęzły pokazują zawartość albo strukturę środowiska.
4. Prześledź ścieżki komunikacji i ich etykiety; sprawdź, które węzły wymieniają dane.
5. Rozróżnij typ węzła od jego konkretnej instancji.
6. Zwróć uwagę na nazwę środowiska i wersję konfiguracji, jeśli zostały podane.
7. Zidentyfikuj brakujące informacje, których diagram nie obiecuje pokazać.

Linia między węzłami opisuje ścieżkę komunikacji, a nie automatycznie zależność komponentów. Wewnątrz węzła mogą wystąpić różne elementy modelu; obecność artefaktu nie wyjaśnia sama z siebie, które komponenty implementuje. Do tej relacji można dołączyć widok komponentów albo jawne powiązanie realizacji.

Jak tworzyć diagram wdrożenia#

1. Określ scenariusz wdrożeniowy#

Zapisz, czy przedstawiasz środowisko lokalne, testowe, produkcyjne, czy architekturę docelową. Ustal, czy diagram opisuje rodzaje węzłów, konkretne instancje, czy oba poziomy. Nie mieszaj środowisk bez rozróżniających etykiet.

2. Wybierz poziom szczegółowości#

Na widoku wysokiego poziomu wystarczą główne strefy lub węzły i istotne połączenia. Widok operacyjny może wymagać nazw instancji, protokołów, artefaktów i liczby replik. Nie ma sensu wypisywać każdej karty sieciowej, procesu systemowego i pliku, jeśli nie wspiera to celu.

3. Umieść oprogramowanie na węzłach#

Dodaj artefakty lub komponenty tam, gdzie są wdrażane. Jeżeli artefakt implementuje komponent, pokaż lub opisz to powiązanie. Unikaj podwójnego znaczenia, w którym nazwa węzła jest raz typem maszyny, a raz środowiskiem wykonawczym.

4. Pokaż ścieżki komunikacji#

Połącz węzły, które wymieniają dane, i oznacz protokoły lub kanały, jeśli są istotne. Wskaż zewnętrzne integracje, granice zaufania, punkty wejścia i istotne pośredniki. Nie zapisuj numerów portów ani gwarancji bezpieczeństwa, których nie potwierdza konfiguracja.

5. Zweryfikuj konfigurację#

Porównaj diagram z faktycznym środowiskiem, manifestami wdrożeniowymi i dokumentacją operacyjną. Ustal właściciela widoku i regułę aktualizacji. Rysunek, który nie odzwierciedla już wdrożenia, może wprowadzać w błąd podczas incydentu lub zmiany infrastruktury.

Diagram wdrożenia a inne diagramy#

Te diagramy mogą opisywać ten sam system z różnych perspektyw. Komponent może być realizowany przez artefakt, który jest wdrożony na węźle, a uczestnicy tego komponentu mogą wymieniać komunikaty w konkretnym scenariuszu. Powiązania między widokami powinny być jawne i utrzymywać spójne nazwy.

Typowe błędy#

• Mylenie komponentu z węzłem. Komponent opisuje logiczną część systemu, węzeł środowisko wykonawcze lub urządzenie.
• Traktowanie diagramu jako dokładnej topologii sieci. Uproszczona linia może reprezentować logiczny kanał, a nie fizyczne połączenie.
• Pominięcie artefaktów, gdy pytanie dotyczy wdrożenia. Warto pokazać, co konkretnie jest instalowane lub uruchamiane.
• Mieszanie typów i instancji węzłów. Wyjaśnij, czy rysunek pokazuje rodzaje środowisk, czy konkretne maszyny.
• Nieuzasadnione etykiety bezpieczeństwa. Sam opis HTTPS nie dokumentuje całej konfiguracji TLS, tożsamości ani polityk dostępu.
• Zbyt niski lub zbyt wysoki poziom szczegółowości. Dopasuj zawartość do decyzji, którą odbiorca ma podjąć.
• Przedstawianie środowiska docelowego jako istniejącego. Oznacz propozycję, stan obecny i planowane wdrożenie.
• Brak aktualizacji po zmianie infrastruktury. Zestaw diagram z konfiguracją i wskaż odpowiedzialność za utrzymanie.
• Dodawanie szczegółów na podstawie przypuszczeń. Nie wpisuj dostawcy, protokołu ani topologii, jeśli nie zostały potwierdzone.

Co diagram wdrożenia pokazuje, a czego nie#

Diagram wdrożenia przedstawia wybrany obraz środowiska uruchomieniowego: węzły, rozmieszczenie artefaktów i ścieżki komunikacji. Jest pomocny w rozmowie o infrastrukturze i granicach wykonania, a także w łączeniu architektury logicznej z fizycznym środowiskiem.

Nie określa samodzielnie wszystkich ustawień sieci, konfiguracji operacyjnej, procedur instalacji, zachowania aplikacji ani gwarancji dostępności i bezpieczeństwa. Uzupełnij go aktualnymi manifestami, konfiguracją oraz opisem wdrożenia, jeżeli te szczegóły są niezbędne do pracy.