Diagramy strukturalne UML pokazują, z jakich elementów składa się modelowany system i jak te elementy są ze sobą powiązane. Diagramy zachowania pokazują, co system lub jego część robi, jak przebiega proces, jak reaguje na zdarzenia albo jak komunikują się uczestnicy. Te dwie rodziny odpowiadają na różne pytania: „co istnieje i jak jest zorganizowane?” oraz „co się dzieje i w jakiej kolejności?”. Często trzeba użyć obu, ale nie należy traktować ich jako dwóch konkurencyjnych sposobów opisania dokładnie tej samej informacji.
Co oznacza struktura, a co zachowanie?#
Struktura opisuje elementy modelu i ich względnie trwałe powiązania. Mogą to być klasy i obiekty, komponenty, pakiety, węzły wdrożeniowe lub wewnętrzna budowa elementu. Diagram strukturalny może też pokazywać zależności, które nie zmieniają się przy każdym wykonaniu procesu. Słowo „statyczny” jest tu skrótem myślowym: nie oznacza, że system nigdy się nie zmienia, tylko że dany widok koncentruje się na organizacji elementów, a nie przebiegu zdarzeń w czasie.
Zachowanie opisuje działania lub możliwe przebiegi. Może przedstawiać przepływ pracy, zmiany stanu obiektu, cele użytkownika albo komunikaty wymieniane w scenariuszu. Diagram zachowania odpowiada więc na pytania takie jak: jakie kroki prowadzą do wyniku, co warunkuje przejście dalej, co dzieje się po zdarzeniu i które elementy współpracują w trakcie operacji.
W UML oba aspekty mogą odnosić się do tego samego elementu. Klasa Zamówienie może wystąpić na diagramie klas jako część struktury, a jej cykl życia można przedstawić diagramem maszyny stanów. Model nie musi być rozdzielony na dwa niezależne światy; diagramy pokazują różne aspekty i poziomy opisu.
Diagramy strukturalne UML#
W UML 2.5.1 do diagramów strukturalnych zalicza się siedem typów:
- Diagram klas przedstawia klasyfikatory, ich cechy i operacje oraz relacje między nimi. Stosuje się go zarówno do pojęciowego modelu dziedziny, jak i do projektu struktur oprogramowania — trzeba tylko jasno określić, który poziom pokazuje rysunek.
- Diagram obiektów pokazuje konkretne instancje i ich powiązania w wybranym przykładzie lub momencie. Może posłużyć do sprawdzenia, czy abstrakcyjny diagram klas daje się zrozumieć na konkretnych danych.
- Diagram komponentów przedstawia większe, wymienne lub odrębne części systemu oraz ich interfejsy i zależności.
- Diagram struktur złożonych pokazuje wewnętrzną strukturę klasyfikatora — jego części, porty, konektory i współpracujące role.
- Diagram pakietów grupuje elementy modelu i pokazuje zależności między grupami.
- Diagram wdrożenia przedstawia węzły środowiska wykonawczego oraz rozmieszczenie na nich artefaktów.
- Diagram profili pokazuje profile i rozszerzenia używane do dostosowania UML do określonej dziedziny.
Nie każdy diagram strukturalny jest „diagramem klas w innym stylu”. Każdy ma inny zakres i symbole. Na przykład diagram komponentów koncentruje się na częściach systemu i ich interfejsach, a diagram wdrożenia — na środowisku wykonawczym. Zastąpienie jednego drugim może pozostawić bez odpowiedzi ważne pytanie.
Przykład poniżej opisuje statyczne pojęcia związane z zamówieniem. Nie pokazuje kroków składania zamówienia ani reakcji na błąd.
Każde zamówienie należy do jednego klienta, a klient może mieć zero lub wiele zamówień. W tym modelu zamówienie ma co najmniej jedną pozycję; każda pozycja dotyczy jednego produktu, który może pojawiać się na wielu pozycjach różnych zamówień. Diagram nie określa cen, rabatów, dostępności ani kolejności przetwarzania. To celowe ograniczenie widoku, a nie twierdzenie, że takie informacje nie są potrzebne w całym systemie.
Diagramy zachowania UML#
Drugą rodzinę tworzy siedem typów diagramów zachowania. Oprócz trzech ogólnych diagramów, obejmuje ona cztery diagramy interakcji:
- Diagram przypadków użycia pokazuje aktorów i cele realizowane względem systemu. Pomaga ustalić granice i funkcje widziane z zewnątrz, lecz nie zastępuje szczegółowych scenariuszy.
- Diagram aktywności przedstawia działania, przepływ sterowania i danych, decyzje, pętle lub ścieżki równoległe. Nadaje się do modelowania procesu biznesowego, procedury albo algorytmu.
- Diagram maszyny stanów pokazuje stany obiektu lub systemu, zdarzenia, warunki i przejścia. Jest użyteczny, gdy dozwolone działanie zależy od aktualnego stanu.
- Diagram sekwencji pokazuje uczestników interakcji oraz kolejność komunikatów na osi czasu.
- Diagram komunikacji przedstawia uczestników i ich powiązania, a kolejność komunikatów zapisuje przy łącznikach.
- Diagram przeglądu interakcji łączy elementy przepływu sterowania z odniesieniami do interakcji, na przykład diagramów sekwencji.
- Diagram czasowy obrazuje zmiany stanów lub wartości w czasie, szczególnie gdy ważne są ograniczenia czasowe i synchronizacja.
Podział na „strukturalne” i „zachowania” opisuje przede wszystkim rodzaj informacji. Nie oznacza, że diagram zachowania jest po prostu animacją ani że musi przedstawiać wyłącznie działania wykonywane przez komputer. Może opisywać współpracę ludzi i systemu lub przepływ w organizacji, jeśli zakres modelu został tak zdefiniowany.
Ten sam temat w dwóch perspektywach#
Diagram klas powyżej pokazuje elementy danych i ich związki. Nie wiadomo z niego, w jakiej kolejności obsłużyć zamówienie. Do przedstawienia prostego przebiegu możemy użyć diagramu aktywności:
Diagram aktywności pokazuje kolejność działań i decyzję zależną od poprawności danych. Nie wyjaśnia jednak, jakie pola składają się na zamówienie ani jak zamówienie jest powiązane z klientem — to przedstawiał diagram strukturalny. Z kolei nie opisuje szczegółowo, który komponent waliduje dane ani jakie komunikaty są wymieniane między usługami. Można te pytania modelować osobnymi diagramami, jeśli są potrzebne.
Przykład jest celowo uproszczony: brak danych prowadzi do prośby o ich uzupełnienie, ale nie pokazujemy, czy proces wraca do początku, czy kończy się na tym komunikacie. Jeśli ta różnica wpływa na wymaganie lub implementację, należy dodać pętlę albo opisać wariant dokładniej. Diagram nie powinien sugerować reguły, której autor nie zamierzał ustalić.
Jak rozpoznać, której rodziny potrzebujesz?#
Zacznij od sformułowania pytania:
| Pytanie | Perspektywa i możliwy diagram |
|---|---|
| Jakie pojęcia lub elementy występują i jak są powiązane? | Struktura: diagram klas albo obiektów |
| Jak system jest podzielony na większe części? | Struktura: diagram komponentów lub pakietów |
| Gdzie działa oprogramowanie i co jest wdrożone na węzłach? | Struktura: diagram wdrożenia |
| Jak przebiega proces lub algorytm? | Zachowanie: diagram aktywności |
| Jak obiekt reaguje na zdarzenia zależnie od stanu? | Zachowanie: diagram maszyny stanów |
| Jakie komunikaty są wymieniane i w jakiej kolejności? | Zachowanie/interakcja: diagram sekwencji lub komunikacji |
| Jakie cele realizują użytkownicy lub systemy zewnętrzne? | Zachowanie: diagram przypadków użycia |
Jeśli trzeba jednocześnie wyjaśnić strukturę i przebieg, zwykle lepiej przygotować dwa powiązane, czytelne widoki niż połączyć wiele pytań na jednym rysunku. Wspólny słownik nazw i jawne założenia pomagają utrzymać spójność między diagramami.
Powiązane diagramy i ich granice#
Diagramy strukturalne i zachowania uzupełniają się, ale każdy zachowuje własny zakres. Asocjacja na diagramie klas mówi o dopuszczalnym powiązaniu instancji; sama nie wskazuje, w którym momencie ani przez jaki scenariusz ono powstaje. Działanie na diagramie aktywności może odwoływać się do zamówienia, ale nie definiuje automatycznie wszystkich jego atrybutów. Diagram sekwencji może pokazać komunikaty między komponentami, lecz nie zastąpi ich pełnego widoku architektury.
Łączenie diagramów wymaga konsekwentnych nazw i zgodnych założeń. Jeśli na diagramie klas zamówienie może zawierać wiele pozycji, a opis procesu zakłada dokładnie jedną, trzeba wyjaśnić, czy widoki modelują inne warianty, czy też są niespójne. Diagramy nie kontrolują się wzajemnie automatycznie, o ile narzędzie lub dodatkowe reguły walidacji nie zostały do tego przygotowane.
Typowe nieporozumienia#
- „Struktura oznacza tylko klasy”. UML ma kilka typów diagramów strukturalnych, między innymi obiektów, komponentów, struktur złożonych, pakietów, wdrożenia i profili.
- „Diagram aktywności opisuje strukturę systemu”. Przedstawia przebieg działań; nie zastępuje opisu elementów i relacji.
- „Diagram zachowania zawsze pokazuje zachowanie jednego obiektu”. Przypadki użycia, aktywności i interakcje mogą obejmować szerszy zakres, zależnie od celu modelu.
- „Każdy diagram odpowiada dokładnie jednemu elementowi kodu”. Diagram jest widokiem modelu i może obejmować różne poziomy abstrakcji.
- „Obie rodziny trzeba stosować w każdym projekcie”. Wybór zależy od pytania i wartości informacyjnej diagramu.
- „Te dwa diagramy są sprzeczne, bo pokazują inne rzeczy”. Różne widoki mogą być komplementarne; sprzeczność występuje, gdy ich założenia wzajemnie się wykluczają.
Podsumowanie#
Diagramy strukturalne opisują elementy i ich organizację, a diagramy zachowania — działania, przebiegi, stany i interakcje. UML obejmuje siedem typów strukturalnych i siedem typów zachowania; interakcje są podgrupą diagramów zachowania. Wybór rodziny wynika z pytania, na które model ma odpowiedzieć. W przykładzie struktura zamówienia pokazała, jakie pojęcia są powiązane, a diagram aktywności — co dzieje się po przyjęciu danych. Dopiero razem dają szerszy, nadal selektywny obraz systemu.