Diagramy mają uzasadniać decyzje architektoniczne#
Architekt może używać UML do komunikowania granic, zależności, kontraktów, scenariuszy zachowania i rozmieszczenia systemu. Diagram jest użyteczny, jeśli wspiera decyzję lub pomaga odbiorcom przewidzieć wpływ zmiany. Nie musi zawierać całego rozwiązania ani zastępować opisu architektury, wymagań jakościowych i decyzji projektowych.
Widok pokazuje zależność modułu zamówień od kontraktu dostępności zasobów. Nie określa, czy kontrakt jest obsługiwany przez bibliotekę, usługę zdalną czy wspólną bazę. Architektura powinna to doprecyzować w innym widoku, jeśli różnica wpływa na wydajność, dostępność lub bezpieczeństwo.
Zacznij od interesariuszy i scenariuszy#
Ustal, kto będzie podejmował decyzje na podstawie modelu: zespół developerski, operatorzy, bezpieczeństwo, właściciel produktu, integratorzy lub kierownictwo. Każda grupa może potrzebować innego widoku. Opisz scenariusze, które wpływają na architekturę, takie jak skok obciążenia, awaria zależności, utrata regionu, zmiana dostawcy lub naruszenie granicy zaufania.
Wybór diagramu powinien wynikać z tych pytań. Diagram komponentów pokazuje moduły i kontrakty, wdrożenia — środowiska i artefakty, sekwencji — zachowanie integracji, stanów — cykl życia krytycznych elementów. Diagram kontekstu może pokazać aktorów i systemy, ale nie zastępuje dokładnego modelu interfejsu.
Granice, odpowiedzialność i zależności#
Granice komponentów powinny wynikać z odpowiedzialności, zmian, zespołów, danych lub wymagań jakościowych. Diagramy pomagają wykryć zależności cykliczne, wspólne moduły o niejasnym właścicielu, kontrakty przeciekające przez granice i integracje, których awarie nie mają obsługi.
Pokaż interfejsy wymagane i dostarczane, gdy kontrakt jest istotny. Nazwy ogólne, takie jak Common lub Manager, często ukrywają odpowiedzialność; doprecyzuj, czy element jest źródłem prawdy, adapterem, usługą czy bramą. Nie każda zależność powinna być narysowana — wybierz te, które wpływają na decyzję.
Jakościowe atrybuty i zachowanie#
UML może pomóc umieścić wymaganie jakościowe w kontekście, ale sam diagram nie zastąpi mierzalnego kryterium. Dla wydajności podaj wielkość i warunek pomiaru, dla dostępności scenariusz awarii i czas odtworzenia, dla bezpieczeństwa granicę zaufania i wymagane kontrole. Powiąż te kryteria z komponentami, interfejsami lub przepływami, na które wpływają.
Diagram sekwencji może pokazać, co dzieje się po timeoutcie, retry albo niedostępności usługi. Wdrożeniowy — rozmieszczenie i redundancję. Aktywność — obciążający przebieg. Użyj widoku, który pozwoli omówić mechanizm, ale zapisz testowalne kryteria osobno.
Widoki logiczne i wdrożeniowe#
Diagram komponentów opisuje moduły niezależnie od konkretnej infrastruktury. Diagram wdrożenia pokazuje węzły, środowiska wykonawcze, artefakty i połączenia. Mapowanie pomiędzy nimi powinno być zrozumiałe, zwłaszcza jeśli komponenty rozkładają się na wiele artefaktów lub współdzielą węzły.
Oznacz środowisko i poziom konkretności: architektura docelowa, konfiguracja referencyjna czy stan aktualny. W razie potrzeby twórz osobne widoki dla środowisk testowego i produkcyjnego. Nie ujawniaj poufnych szczegółów infrastruktury w dokumentacji przeznaczonej dla szerokiego odbiorcy.
Powiązanie z decyzjami i ograniczeniami#
Diagram powinien mieć kontekst decyzyjny: jakie opcje rozważono, dlaczego wybrano granicę lub kontrakt i jakie kompromisy zaakceptowano. Zachowaj te informacje w zapisie decyzji architektonicznej lub dokumentacji modelu, zamiast próbować umieścić całą argumentację na rysunku.
Ograniczenia technologiczne, organizacyjne, regulacyjne i operacyjne wpływają na projekt. Oznacz założenia, niepewność i właściciela decyzji. Jeśli nowe dane podważają założenie, sprawdź wszystkie diagramy, które się na nim opierają.
Poziomy szczegółowości#
Zespół może potrzebować mapy systemu, widoku komponentów, diagramu integracji i diagramu szczegółowego dla ryzykownej funkcji. Każdy powinien mieć zakres i odbiorcę. Nie rozpisuj wszystkich klas w widoku architektonicznym, jeśli utrudnia to komunikację granic; utwórz osobny widok projektu dla implementacji.
Diagramy aktualizuj po zmianach kontraktów, granic i decyzji. Zdefiniuj źródło prawdy i właściciela każdego widoku. Generowanie z kodu może pomóc, ale nie odtworzy intencji, kompromisów ani niewdrożonych planów.
Typowe błędy#
- Jeden diagram nazwany całą architekturą. System wymaga spójnego zestawu perspektyw.
- Szczegóły kodu pomylone z granicami architektonicznymi. Dobierz poziom abstrakcji do decyzji.
- Jakościowe cele bez mierników. Diagram nie zastępuje kryteriów wydajności lub dostępności.
- Komponent utożsamiony z usługą wdrożoną. Logiczny moduł może być realizowany inaczej w środowisku.
- Zależności bez kontraktów. Określ odpowiedzialność i oczekiwania na granicy.
- Brak widoku na awarie. Modeluj zachowanie istotnych integracji i trybów degradacji.
- Diagram bez decyzji i właściciela. Zapisz kontekst oraz proces utrzymania.
Podsumowanie#
Architekt używa UML do wyjaśniania granic, kontraktów, interakcji i środowisk, które wpływają na decyzje. Zaczynaj od scenariuszy i odbiorców, łącz jakościowe wymagania z elementami architektury i utrzymuj spójne widoki o określonym źródle prawdy.