Wybieraj diagram UML od pytania, na które ma odpowiedzieć, a nie od ulubionego typu rysunku. Jeśli chcesz pokazać pojęcia i ich powiązania, rozważ diagram klas; jeśli kolejność działań — diagram aktywności; jeśli reakcje zależne od stanu — diagram maszyny stanów; jeśli wymianę komunikatów — diagram sekwencji lub komunikacji. Diagram przypadków użycia pomaga opisać cele aktorów, a diagram wdrożenia — środowisko, w którym działają elementy systemu. Jeden problem może wymagać kilku uzupełniających się widoków.
Zacznij od pytania i odbiorcy#
Zanim wybierzesz typ diagramu, zapisz jedno zdanie: „Po obejrzeniu diagramu odbiorca ma zrozumieć…”. Dokończ je konkretem, na przykład: „jak zamówienie jest zbudowane”, „co dzieje się po odrzuceniu płatności” albo „z jakich węzłów korzysta aplikacja”. Jeśli trudno dokończyć zdanie, temat może być zbyt szeroki albo diagram nie jest potrzebny.
Następnie określ odbiorcę. Osoba biznesowa może potrzebować celów, kroków procesu i wyjątków; programista — komunikatów między komponentami, typów danych albo stanów obiektu; administrator — węzłów, połączeń i artefaktów wdrożenia. Diagram dla kilku grup może wymagać legendy lub krótkiego opisu założeń. Nie zmieniaj znaczenia symboli UML dla wygody odbiorcy; raczej wybierz prostszy diagram albo objaśnij trudne pojęcia.
Szybka mapa wyboru#
| Co chcesz zrozumieć? | Diagramy do rozważenia | Co pokażą najlepiej | Czego same nie rozstrzygną |
|---|---|---|---|
| Jakie pojęcia, typy lub klasy występują i jak są powiązane? | Klas | Typy, cechy i relacje | Kolejności zdarzeń ani konkretnego przebiegu |
| Jak wygląda konkretny przykład obiektów i ich powiązań? | Obiektów | Instancje w wybranym momencie lub scenariuszu | Pełnego zakresu wszystkich dopuszczalnych danych |
| Jakie cele realizują użytkownicy lub systemy zewnętrzne? | Przypadków użycia | Aktorów, granicę systemu i cele widziane z zewnątrz | Szczegółowych kroków, reguł walidacji i komunikatów |
| Jak przebiega proces, algorytm, decyzja lub ścieżka równoległa? | Aktywności | Kroki, przepływy, rozgałęzienia i równoległość | Pełnej struktury danych lub architektury |
| Jak obiekt reaguje na zdarzenia w zależności od stanu? | Maszyny stanów | Stany, zdarzenia, przejścia i warunki | Pełnej współpracy wielu uczestników w scenariuszu |
| Kto komu wysyła komunikat i w jakiej kolejności? | Sekwencji | Uczestników i kolejność komunikatów w czasie | Złożonej struktury systemu ani wszystkich scenariuszy |
| Którzy uczestnicy się komunikują, a jakie są ich powiązania? | Komunikacji | Sieć uczestników i uporządkowane komunikaty | Osi czasu tak czytelnej jak diagram sekwencji |
| Jak system dzieli się na większe moduły i interfejsy? | Komponentów, pakietów | Granice części i zależności | Szczegółów pojedynczego przebiegu lub hostów uruchomieniowych |
| Na czym i gdzie uruchamiane są elementy rozwiązania? | Wdrożenia | Węzły środowiska, artefakty i rozmieszczenie | Zachowania użytkownika ani wewnętrznej logiki programu |
| Jak zmieniają się wartości lub stany w czasie rzeczywistym? | Czasowy | Zależności czasowe, synchronizację i zmiany | Ogólnej architektury całego systemu |
To mapa pomocnicza, nie reguła, która przypisuje jeden temat do jednego diagramu. Różne typy mogą być sensowne dla tego samego problemu, jeśli odpowiadają na inne pytania. Na przykład przypadek użycia może określić cel „Złóż zamówienie”, diagram aktywności — przebieg jego wariantów, a diagram sekwencji — współpracę usług w jednym scenariuszu.
Przykładowa ścieżka decyzji#
Poniższe drzewo pomaga zacząć. Jest celowo uproszczone: nie obejmuje wszystkich typów UML ani sytuacji, w których potrzebny jest inny język modelowania.
Po wskazaniu typu sprawdź, czy jego symbole wyrażają właśnie tę informację, której potrzebujesz. Jeśli na diagramie aktywności próbujesz pokazać wiele klas i ich atrybutów, prawdopodobnie mieszasz dwa pytania. Z kolei diagram klas nie jest dobrym miejscem do opisywania szczegółowej kolejności kroków, nawet jeśli da się dodać do niego notatki.
Kryteria, które pomagają podjąć decyzję#
1. Czy pytanie dotyczy struktury, czy przebiegu?#
Wybierz diagram strukturalny, gdy kluczowe są typy, elementy, części, interfejsy albo zależności. Diagram klas może odpowiedzieć na pytanie, jakie pojęcia występują i jak są związane; komponentów — jak system jest podzielony; wdrożenia — gdzie znajdują się artefakty i węzły.
Wybierz diagram zachowania, gdy ważne są działania, zdarzenia, warunki lub komunikacja. Diagram aktywności jest użyteczny, gdy trzeba przejść przez rozgałęziony proces. Diagram maszyny stanów sprawdza się, gdy zachowanie obiektu zależy od jego aktualnego stanu. Diagram sekwencji pomaga zobaczyć kolejność komunikatów w konkretnym scenariuszu.
2. Czy pokazujesz typ, przykład, cel czy wykonanie?#
Diagram klas opisuje typy i ich relacje; diagram obiektów może pokazać konkretny układ instancji, który pozwala wyjaśnić albo przetestować ten opis. Diagram przypadków użycia opisuje cele widziane z zewnątrz, a nie wnętrze implementacji. Diagram sekwencji przedstawia wykonanie wybranego scenariusza, nie wszystkie możliwe wykonania całego systemu.
Pomylenie tych poziomów prowadzi do mylących rysunków. Jeśli na diagramie klas wpiszesz konkretne zamówienie z określoną ceną i datą, odbiorca może nie wiedzieć, czy ogląda definicję typu, czy przykładowy obiekt. W takim przypadku diagram obiektów może być właściwszy.
3. Jak wiele szczegółów i uczestników jest potrzebnych?#
Diagram sekwencji jest czytelny, gdy liczba lifeline’ów i komunikatów pozwala śledzić istotny scenariusz. Gdy próbujesz umieścić na nim wszystkie procesy i warianty, rozważ kilka diagramów odnoszących się do różnych scenariuszy albo diagram przeglądu interakcji. Gdy diagram klas obejmuje każdą klasę projektu, ogranicz zakres do obszaru, który ma znaczenie dla pytania.
Poziom szczegółowości zależy też od tego, czy model ma służyć rozmowie, trwałej dokumentacji czy automatycznemu przetwarzaniu. Szkic do rozmowy może pomijać elementy oczywiste dla uczestników. Model wykorzystywany jako źródło generowania lub walidacji potrzebuje bardziej precyzyjnych i konsekwentnych definicji.
4. Czy diagram jest dla odbiorcy zrozumiały?#
Jeśli odbiorcy nie znają notacji, dodaj krótkie objaśnienie, ogranicz liczbę symboli albo wybierz widok, który odpowiada ich słownictwu. Dla uzgodnienia procesu przez zespół biznesowy bardziej bezpośredni może być diagram aktywności; dla dyskusji o interfejsach modułów — diagram komponentów. W razie potrzeby diagramowi powinien towarzyszyć opis słowny.
Nie należy jednak wybierać typu tylko dlatego, że konkretne narzędzie ma go w szablonie albo łatwo go narysować. Wybór wynika z informacji i odbiorcy; możliwości narzędzia są dopiero kolejnym ograniczeniem.
Przykład: zamówienie internetowe#
Załóżmy, że zespół musi wyjaśnić trzy różne kwestie:
- Jak zamówienie łączy klienta, pozycje i produkty? Diagram klas pokaże typy, relacje i ewentualne liczności.
- Co ma się stać, gdy klient złoży zamówienie, a płatność zostanie odrzucona? Diagram aktywności może pokazać główny przepływ i wariant błędu.
- Które elementy aplikacji wysyłają sobie komunikaty podczas próby płatności? Diagram sekwencji może pokazać klienta, interfejs, usługę zamówień, bramkę płatniczą i kolejność komunikatów.
Rysowanie jednego diagramu, który próbuje odpowiedzieć na wszystkie trzy pytania, zwykle miesza typy informacji. Zespół może utworzyć trzy widoki i powiązać je wspólnym scenariuszem oraz nazwami. W każdym trzeba zaznaczyć, co jest poza zakresem: na przykład diagram sekwencji nie musi pokazywać wszystkich atrybutów klas, a diagram klas nie określa wyniku komunikacji z bramką.
Kiedy nie tworzyć diagramu UML?#
Nie każdy problem wymaga diagramu. Jeśli opis jest prosty, odbiorcy już go rozumieją, a rysunek nie pomoże w podjęciu decyzji, wystarczy tekst, lista kontrolna, tabela, przykład danych lub fragment kodu. Diagram nie powinien powstawać tylko po to, aby „był UML” w dokumentacji.
Może też okazać się, że odbiorca potrzebuje innego rodzaju modelu. Diagram przepływu pracy nie zawsze zastąpi BPMN w organizacji, która potrzebuje szczegółowej notacji procesów biznesowych. Model danych może wymagać notacji zaprojektowanej pod schematy relacyjne. UML może nadal być częścią opisu, ale nie musi być jedynym językiem.
Jeśli rysunek jest jedynie szkicem, jasno określ, że jest selektywny i roboczy. Jeżeli ma być specyfikacją, podstawą testów lub wejściem narzędzia, doprecyzuj semantykę, zakres oraz reguły, które szkic mógł bezpiecznie pominąć.
Typowe błędy przy wyborze#
- Wybór diagramu przed określeniem pytania. W efekcie powstaje ładny rysunek bez jasnego zastosowania.
- Użycie diagramu klas do opisania sekwencji zdarzeń. Struktura i kolejność zachowania wymagają innych symboli.
- Traktowanie diagramu przypadków użycia jak szczegółowego procesu. Cele aktorów trzeba uzupełnić scenariuszem lub innym widokiem, jeśli ważne są kroki i wyjątki.
- Rysowanie zbyt wielu klas lub komunikatów. Przeładowany diagram utrudnia znalezienie informacji, której odbiorca szuka.
- Powtarzanie tej samej informacji na wielu niesynchronizowanych diagramach. Zwiększa to ryzyko sprzeczności; powiązane widoki powinny dzielić nazwy i aktualne założenia.
- Utożsamianie renderowalności z poprawnym wyborem. Narzędzie może wygenerować diagram, który nie odpowiada pytaniu albo używa relacji błędnie.
- Pomijanie odbiorcy. Techniczny poziom szczegółowości może być niezrozumiały dla interesariusza biznesowego i odwrotnie.
Krótka checklista#
Przed narysowaniem diagramu odpowiedz sobie:
- Jakie jedno główne pytanie ma rozstrzygnąć?
- Kto będzie z niego korzystać i jaką decyzję ma podjąć?
- Czy chodzi o strukturę, zachowanie, cele zewnętrzne, interakcję czy wdrożenie?
- Jaki zakres i poziom abstrakcji pokażę, a co celowo pominę?
- Czy diagram jest czytelny bez ustnego dopowiadania kluczowych reguł?
- Czy potrzebny jest drugi widok, czy wystarczy opis, tabela albo szkic?
Jeśli diagram pomaga odbiorcy odpowiedzieć na określone pytanie, jego typ jest właściwy niezależnie od tego, czy pokazuje dużo elementów. Jeśli celu nie da się nazwać, najpierw doprecyzuj problem. W UML wybiera się widok do informacji, którą chce się przekazać — nie informację do gotowego szablonu diagramu.