Węzeł i artefakt opisują wdrożenie#
Diagram wdrożenia pokazuje, gdzie i w jakim środowisku mogą działać elementy oprogramowania. Węzeł (node) reprezentuje zasób obliczeniowy lub środowisko, na którym można uruchomić albo przechować artefakt. Artefakt (artifact) jest fizycznie wytworzonym elementem informacji, takim jak plik wykonywalny, pakiet, skrypt, schemat bazy, dokumentacja lub wynik kompilacji.
Artefakt sklep.jar jest wdrażany na węźle serwera aplikacji. Linia między serwerem a bazą przedstawia połączenie komunikacyjne w modelowanym środowisku. Diagram nie określa wszystkich szczegółów topologii ani zabezpieczeń; pokazuje elementy istotne dla tego widoku.
Węzeł sprzętowy i środowisko wykonawcze#
Węzeł może reprezentować urządzenie sprzętowe, takie jak serwer, telefon lub kontroler wbudowany, ale może też reprezentować środowisko wykonawcze, na przykład maszynę wirtualną, kontener, system operacyjny lub środowisko aplikacyjne. Węzły można zagnieżdżać, jeśli model ma pokazać, że jedno środowisko działa wewnątrz innego.
Węzeł typu opisuje kategorię środowiska, a instancja węzła konkretny element działającej konfiguracji. Instancję można oznaczyć nazwą i typem, na przykład serwer01 : SerwerAplikacji, oraz podkreśleniem nazwy zgodnie z notacją instancji. Używaj poziomu typu, gdy projektujesz architekturę docelową, i instancji, gdy dokumentujesz konkretną konfigurację.
Artefakt, komponent i plik#
Artefakt jest materialnym wynikiem lub składnikiem procesu rozwoju. Komponent to modularny element architektoniczny z kontraktami, który może być realizowany przez artefakty. Związek między nimi można modelować osobno: artefakt może manifestować komponent lub komponent może być realizowany przez artefakt, zależnie od użytej relacji i celu diagramu.
Słowo „plik” jest często dobrym przykładem artefaktu, ale UML nie ogranicza artefaktów wyłącznie do plików na dysku. Z kolei nie każdy plik konfiguracyjny musi być rysowany; dodaj go, jeśli ma znaczenie dla wdrożenia lub uruchomienia. Diagram powinien pomagać zrozumieć architekturę, a nie katalogować wszystkie bajty.
Relacja wdrożenia#
Relacja wdrożenia przypisuje artefakt do węzła lub celu wykonawczego. Można pokazać wdrożenie artefaktu na typie węzła, co wyraża założenie architektury, albo na konkretnej instancji, gdy artefakty różnią się w poszczególnych środowiskach. Kierunek relacji i sposób jej notowania powinny być czytelne oraz spójne z narzędziem.
Wdrożenie na diagramie nie jest poleceniem dla systemu CI/CD ani gwarancją, że artefakt faktycznie został zainstalowany. Opisuje modelowaną alokację. Rzeczywisty stan instalacji można przedstawić jako konkretną konfigurację lub uzupełnić raportem z procesu wdrożeniowego.
Ścieżki komunikacji między węzłami#
Asocjacja między węzłami może przedstawiać ścieżkę komunikacji. Etykiety i stereotypy mogą wskazywać rodzaj kanału lub protokół, na przykład TLS albo HTTPS, jeśli informacja jest znana i ważna. Nie dopisuj parametrów sieciowych bez wiarygodnych danych. Diagram wdrożenia może też zawierać ograniczenia bezpieczeństwa, właściwości sprzętu, stany i inne informacje o konfiguracji.
Linia komunikacji sama w sobie nie stwierdza, że każdy artefakt może korzystać z każdego węzła ani że połączenie jest stale dostępne. Pokaż interfejsy lub zależności komponentów w widoku architektury logicznej, jeśli relacje usługowe są głównym pytaniem.
Węzeł a pakiet lub komponent#
Pakiet organizuje elementy modelu, komponent definiuje moduł i jego kontrakty, a węzeł opisuje zasób lub środowisko uruchomieniowe. Te pojęcia mogą występować obok siebie na różnych diagramach: komponent realizowany przez artefakt jest wdrażany na węźle. Nie zastępuj jednego drugim tylko dlatego, że narzędzie przedstawia je podobnymi prostokątami.
Diagramy wdrożenia są szczególnie przydatne do omawiania architektury fizycznej, środowisk testowych i produkcyjnych, rozkładu usług oraz zależności od infrastruktury. Złożony system zwykle wymaga kilku widoków, zamiast jednego diagramu z każdą klasą, usługą, plikiem i serwerem.
Typowe błędy#
- Węzeł utożsamiony z serwerem fizycznym. Może oznaczać także środowisko programowe lub typ zasobu.
- Artefakt utożsamiony wyłącznie z plikiem wykonywalnym. Może być innym fizycznym wynikiem procesu rozwoju.
- Komponent utożsamiony z węzłem. Komponent jest modułem, węzeł miejscem lub środowiskiem wykonania.
- Deklarowane wdrożenie uznane za faktyczny stan. Model architektury nie potwierdza stanu produkcji.
- Każdy plik dodany do diagramu. Pokazuj tylko artefakty znaczące dla wdrożenia.
- Ścieżka komunikacji uznana za pełny model sieci. Topologia, zabezpieczenia i parametry mogą wymagać osobnego opisu.
- Niejasny typ węzła i jego instancja. Zdecyduj, czy diagram opisuje docelowy wzorzec, czy konkretne uruchomienie.
Podsumowanie#
Węzeł oznacza sprzęt lub środowisko wykonawcze, a artefakt — fizyczny wynik lub element informacji wdrażany albo używany w systemie. Diagram wdrożenia pokazuje alokację artefaktów, środowiska i połączenia między węzłami. Odróżniaj tę perspektywę od logicznych komponentów i nie traktuj modelowanej konfiguracji jako automatycznego dowodu rzeczywistego wdrożenia.