UML służy do tworzenia modeli, które pomagają ludziom zrozumieć system, uzgodnić jego wymagania, rozważyć rozwiązania i przekazać ważne decyzje. Można nim opisać zarówno funkcje widziane przez użytkowników, jak i strukturę oprogramowania, zachowanie jego części czy sposób wdrożenia. Wartość UML polega na tym, że dobiera się konkretne symbole i diagramy do pytania, które trzeba rozstrzygnąć — nie na rysowaniu wszystkiego, co język dopuszcza.
Najważniejsze zastosowania UML#
OMG opisuje UML jako język pomagający specyfikować, wizualizować i dokumentować modele systemów. Te trzy zastosowania często występują razem, ale nie są tym samym.
- Specyfikowanie polega na precyzowaniu elementów, relacji, zachowania lub ograniczeń, które mają znaczenie dla projektu. Model może na przykład ustalić, że każde złożone zamówienie jest przypisane do klienta i zawiera co najmniej jedną pozycję.
- Wizualizowanie polega na pokazaniu wybranych informacji w formie diagramu. Obraz może ujawnić zależności i luki trudniejsze do zauważenia w długim opisie tekstowym.
- Dokumentowanie polega na zachowaniu modelu jako punktu odniesienia dla zespołu. Taka dokumentacja pomaga wrócić do uzgodnień, ale wymaga aktualizacji, gdy zmienia się opisywany system.
UML nie narzuca kolejności tych czynności. Zespół może zacząć od szkicu podczas warsztatu, dopracować go w analizie, wykorzystać w przeglądzie projektu, a potem zachować wybrane diagramy w dokumentacji. Może też użyć tylko jednego diagramu do jednego, wąskiego pytania.
Uzgadnianie wymagań i celów użytkowników#
Na początku pracy osoby zaangażowane w projekt mogą inaczej rozumieć słowa takie jak „klient”, „zamówienie” czy „opłacone”. Model pomaga je nazwać i ustalić, o czym zespół rozmawia. Diagram przypadków użycia pokazuje zewnętrzne role oraz cele osiągane przy współpracy z systemem. Uzupełniony opisem scenariuszy może stać się podstawą rozmowy o typowym przebiegu, wariantach i wyjątkach.
Poniższy przykład obejmuje tylko sklep internetowy z płatnością online. Pokazuje kilka celów klienta, jedną czynność administratora i zewnętrzny system płatności. Relacja <<include>> wskazuje, że w przyjętym wariancie standardowy przebieg składania zamówienia zawsze obejmuje przetworzenie płatności.
Granica systemu to prostokąt opisany „Sklep internetowy — płatność online”. Przypadki użycia wewnątrz określają, jakie cele w tym zakresie obsługuje sklep. Aktorzy są na zewnątrz, bo reprezentują role lub systemy wchodzące z nim w interakcje. Aktor Klient oznacza rolę, a nie konkretną osobę ani konto; System płatności jest aktorem, ponieważ znajduje się poza granicą modelowanego sklepu.
Asocjacje między aktorem i przypadkiem użycia wskazują udział w interakcji. Zwykła linia nie opisuje pełnego przebiegu ani kolejności działań. Relacja <<include>> biegnie od przypadku bazowego Złóż zamówienie do dołączanego Przetwórz płatność. Przyjęto tu założenie, że dotyczy ona każdego standardowego wykonania zamówienia w tym modelu. Odrzucenie płatności powinno być opisane jako wariant lub wyjątek scenariusza; nie wynika z samej strzałki.
Jeśli sklep dopuszcza również płatność przy odbiorze, ten diagram wymaga doprecyzowania: bezwarunkowe include sugerowałoby przetwarzanie płatności online przy każdym zamówieniu. Można wtedy opisać alternatywne przypadki użycia albo wybrać inny podział modelu. Diagram nie powinien przedstawiać prostszej reguły, niż faktycznie obowiązuje.
Diagram przypadków użycia nie jest pełną specyfikacją wymagań. Nie określa sam z siebie pól formularza, reguł walidacji, kolejności ekranów, treści błędów ani warunków biznesowych. Te informacje mogą znaleźć się w opisach tekstowych, kryteriach akceptacji lub innych modelach. Rysunek pomaga wyznaczyć tematy do omówienia, a nie zastępuje szczegółów potrzebnych do implementacji i testów.
Rozumienie dziedziny i struktury rozwiązania#
UML może porządkować pojęcia problemu przed decyzjami o technologii. Diagram klas pomaga opisać istotne typy pojęć, ich cechy i powiązania. W sklepie mogą to być na przykład Klient, Zamówienie, Pozycja zamówienia i Produkt. Taki model dziedziny ułatwia sprawdzenie, czy zespół jednakowo rozumie pojęcia, oraz wskazanie brakujących reguł.
Później diagram klas może przedstawiać projekt klas oprogramowania: typy, operacje, widoczność i relacje implementacyjne. To inny poziom modelu niż pojęciowy opis dziedziny, mimo że w obu mogą występować podobne nazwy. Diagram klas nie przesądza automatycznie o strukturze tabel bazy danych ani o szczegółach kodu.
Gdy system jest większy, diagramy pakietów lub komponentów pozwalają omawiać jego podział na części oraz zależności między nimi. Diagram wdrożenia może pomóc przedstawić środowisko wykonawcze, węzły i rozmieszczenie artefaktów. Takie widoki są przydatne w rozmowie o architekturze, granicach odpowiedzialności i integracji, ale same nie rozstrzygają jakości architektury.
Analiza przebiegów, stanów i komunikacji#
UML oferuje różne diagramy zachowania, bo pytania o działanie systemu mają różne formy:
- Diagram aktywności pomaga rozłożyć proces lub algorytm na działania, przepływy, decyzje i ścieżki równoległe. Przydaje się, gdy zespół chce uzgodnić, jakie kroki prowadzą od zdarzenia początkowego do wyniku.
- Diagram sekwencji pokazuje uczestników scenariusza i uporządkowane w czasie komunikaty między nimi. Pomaga prześledzić, jak współpracują elementy podczas konkretnej operacji, na przykład złożenia zamówienia.
- Diagram maszyny stanów opisuje możliwe stany obiektu lub systemu oraz zdarzenia i warunki prowadzące do przejść. Jest użyteczny, gdy zachowanie zależy od aktualnego stanu, jak w cyklu życia zamówienia: nowe, opłacone, wysłane, dostarczone lub anulowane.
- Diagram komunikacji skupia się na połączeniach między uczestnikami interakcji; kolejność komunikatów zapisuje się przy nich.
- Diagram czasowy pokazuje zmiany stanów lub wartości względem osi czasu, gdy istotne są granice czasowe albo synchronizacja.
W jednym modelu te diagramy mogą się uzupełniać. Przypadek użycia określa cel widziany z zewnątrz; opis scenariusza rozwija jego przebieg; diagram sekwencji może pokazać wewnętrzną współpracę elementów; diagram stanów może opisać cykl życia zamówienia. Każdy widok odpowiada jednak na inne pytanie, więc należy uzgadniać, do jakiej wersji scenariusza i reguł się odnosi.
Wspólna rozmowa, przegląd i dokumentacja#
Diagram może być narzędziem do rozmowy między analitykami, programistami, testerami, architektami i osobami znającymi proces biznesowy. Wspólny zapis pomaga wskazać niejasność: na przykład brak informacji, kto może anulować zamówienie albo co dzieje się po odrzuconej płatności. Nazwy elementów, granica modelu i przyjęte uproszczenia powinny być zrozumiałe dla odbiorców; sam formalny symbol nie gwarantuje wspólnej interpretacji.
W dokumentacji UML pozwala zapisać wybrane decyzje i strukturę. Warto utrzymywać te diagramy, do których ktoś rzeczywiście wraca — na przykład podczas wdrożenia, testowania, analizy wpływu zmian lub przekazywania systemu innemu zespołowi. Nieaktualny diagram może wprowadzać w błąd bardziej niż brak diagramu, dlatego musi być jasne, jaki zakres i wersję systemu opisuje.
Praca z narzędziami i automatyzacją#
Narzędzia mogą ułatwiać rysowanie, przechowywanie, wersjonowanie, sprawdzanie i wymianę modeli. Niektóre potrafią generować diagramy z tekstowego zapisu, analizować elementy modelu, łączyć model z kodem albo w określonych warunkach generować część artefaktów. Możliwości zależą od narzędzia i użytego fragmentu modelu.
Nie należy zakładać, że każdy diagram UML da się bez dodatkowych ustaleń przekształcić w kompletny program. Generowanie kodu wymaga decyzji i informacji, których ogólny diagram może nie zawierać. Podobnie diagram wygenerowany ze źródeł może pomóc poznać istniejącą strukturę, ale nie wyjaśni automatycznie intencji autorów ani reguł biznesowych.
Kiedy UML pomaga, a kiedy można go pominąć?#
UML jest szczególnie przydatny, gdy trzeba wyjaśnić złożone zależności, porównać warianty, omówić strukturę wielu części, prześledzić przebieg lub uzgodnić wspólną terminologię. Pomaga też wtedy, gdy diagram jest zrozumiały dla konkretnych odbiorców i wspiera decyzję, do której zespół musi wrócić.
Pełny diagram bywa zbędny, gdy problem jest prosty, zespół rozumie go bez dodatkowego zapisu, a koszt sporządzenia i aktualizowania modelu byłby większy niż korzyść. Czasem wystarczy krótki szkic, tabela, przykład wejścia i wyjścia albo opis tekstowy. UML nie jest obowiązkowym rytuałem ani celem samym w sobie.
Dobrym testem jest pytanie: jaką decyzję lub rozmowę ułatwi ten model? Jeśli nie da się wskazać odbiorcy, zakresu ani pytania, diagram może jeszcze nie mieć uzasadnionego celu. Jeżeli cel jest jasny, dobierz taki diagram i taki poziom szczegółowości, które pozwolą go osiągnąć bez przeciążania rysunku.
Najczęstsze błędne oczekiwania#
- „Diagram przypadków użycia zawiera wszystkie wymagania”. Pokazuje aktorów i cele, ale szczegółowe scenariusze, ograniczenia i kryteria trzeba opisać osobno.
- „Każdy element systemu musi trafić na diagram”. Widok ma zakres; pomijanie nieistotnych szczegółów jest częścią modelowania.
- „UML wymaga jednej metodyki”. Język można stosować w różnych procesach. Nie określa sam, kiedy zespół ma rysować diagram ani ile ich przygotować.
- „Poprawny diagram oznacza poprawny system”. Zgodność zapisu nie dowodzi prawdziwości założeń, kompletności wymagań ani jakości implementacji.
- „Z UML zawsze da się wygenerować gotowy kod”. Automatyzacja wymaga odpowiedniego narzędzia, rodzaju modelu i szczegółów, które nie zawsze są na diagramie.
- „Więcej diagramów znaczy lepszy projekt”. Nadmiar nieaktualnych lub powtarzających się modeli zwiększa koszt utrzymania i może zaciemniać istotne informacje.
Podsumowanie#
UML pomaga zespołowi modelować system z wybranej perspektywy: uzgadniać cele i pojęcia, opisywać strukturę, analizować zachowanie, komunikować decyzje i zachowywać potrzebną dokumentację. To, czy użyć diagramu przypadków użycia, klas, sekwencji, aktywności, stanów czy wdrożenia, zależy od problemu i odbiorcy. Model ma wartość wtedy, gdy ułatwia konkretną rozmowę lub decyzję, pozostaje zrozumiały i jest aktualizowany w miarę zmian.