Czym jest UML?

UML (Unified Modeling Language, czyli zunifikowany język modelowania) to standardowy język służący do opisywania, wizualizowania i dokumentowania modeli systemów. Dostarcza wspólnego zestawu pojęć, elementów i reguł zapisu, dzięki którym można przedstawić różne aspekty rozwiązania — od pojęć dziedziny i wymagań po strukturę oprogramowania, zachowanie i komunikację między jego częściami. UML nie jest językiem programowania ani gotową metodyką prowadzenia projektu: określa, jak można zapisywać modele, ale nie narzuca, co konkretny zespół ma modelować ani w jakiej kolejności.

Co oznacza nazwa UML?#

Nazwa rozwija się jako Unified Modeling Language. „Zunifikowany” odnosi się do ujednoliconego zestawu notacji i pojęć, a „język modelowania” wskazuje jego rolę: UML służy do tworzenia modeli, a nie bezpośrednio wykonywalnego kodu źródłowego. Specyfikację UML utrzymuje Object Management Group (OMG), organizacja rozwijająca standardy technologiczne. Wersja UML 2.5.1 została przyjęta jako formalna specyfikacja w grudniu 2017 roku.

UML jest językiem ogólnego przeznaczenia. Najczęściej stosuje się go przy oprogramowaniu, ale model może opisywać także proces biznesowy, organizację lub inny system, jeśli użyte pojęcia i diagramy pomagają odpowiedzieć na określone pytania. UML można dostosowywać do wyspecjalizowanych dziedzin za pomocą profili: profilu UML, który grupuje rozszerzenia i konwencje dla danego zastosowania. Profil nie oznacza osobnego języka od podstaw; rozszerza sposób używania elementów UML w ustalonym kontekście.

Model, diagram i notacja — trzy różne rzeczy#

Model to uproszczony opis wybranego fragmentu rzeczywistości lub projektowanego systemu. Autor wybiera elementy i zależności ważne dla celu modelowania, a pozostałe pomija. Model analityczny może skupiać się na pojęciach problemu, model projektu — na strukturze rozwiązania, a model procesu — na kolejności działań. Żaden z nich nie musi opisywać wszystkiego.

Diagram to graficzny widok wybranych elementów modelu i relacji między nimi. Jeden model może mieć wiele diagramów, które pokazują różne aspekty albo poziomy szczegółowości. Diagram klas może prezentować strukturę pojęć, podczas gdy diagram sekwencji przedstawia wymianę komunikatów w konkretnym scenariuszu. Rysunek nie musi więc być kompletną mapą systemu. Zwykle jest celowym wyborem informacji przydatnych określonemu odbiorcy.

Notacja obejmuje symbole, etykiety, łączniki oraz reguły ich odczytywania. W diagramie klas prostokąt może oznaczać klasę, linia — asocjację, a zapis przy końcu linii — liczność powiązania. Znaczenie nie wynika wyłącznie z koloru czy układu graficznego: zależy od użytego symbolu i reguł UML.

Te pojęcia warto rozdzielać także podczas oceny diagramu. Zgodność notacji mówi, czy zapisano go zgodnie z regułami języka. Trafność modelu mówi, czy przedstawione elementy i zależności odpowiadają problemowi. Czytelność mówi, czy odbiorca potrafi poprawnie go zinterpretować. Diagram może być składniowo poprawny, ale opisywać błędne założenie; może też być trafny, lecz tak przeładowany, że trudno go użyć.

Jakie diagramy obejmuje UML?#

UML zawiera 14 typów diagramów, zwykle grupowanych według tego, na jakie pytanie odpowiadają. Podział pomaga wybrać widok, ale nie oznacza, że każdy projekt powinien użyć wszystkich typów.

Diagramy strukturalne#

Diagramy strukturalne pokazują elementy systemu i ich względnie trwałe zależności:

• diagram klas — klasy, ich cechy i relacje;
• diagram obiektów — przykładowe obiekty i ich powiązania w określonym momencie;
• diagram komponentów — komponenty i zależności między nimi;
• diagram struktur złożonych — wewnętrzną budowę klasyfikatora lub współpracę jego części;
• diagram pakietów — grupowanie elementów modelu i zależności między grupami;
• diagram wdrożenia — węzły wykonawcze oraz rozmieszczenie na nich artefaktów;
• diagram profili — definicje rozszerzeń używanych do specjalizowania UML.

Diagramy zachowania i interakcji#

Diagramy zachowania opisują, co dzieje się w systemie, procesie lub scenariuszu:

• diagram przypadków użycia przedstawia aktorów i cele, które realizują względem systemu;
• diagram aktywności pokazuje przepływ działań, decyzji i odpowiedzialności;
• diagram maszyny stanów opisuje stany obiektu lub systemu oraz zdarzenia wywołujące przejścia;
• diagram sekwencji pokazuje uczestników i kolejność komunikatów w interakcji;
• diagram komunikacji przedstawia uczestników interakcji i ich powiązania, z komunikatami oznaczonymi kolejnością;
• diagram przeglądu interakcji łączy przebiegi interakcji z logiką przepływu;
• diagram czasowy pokazuje zmiany stanów lub wartości w czasie.

Ostatnie cztery typy są diagramami interakcji, czyli szczególną grupą diagramów zachowania. Diagram strukturalny nie opisuje sam z siebie kolejności zdarzeń, a diagram zachowania nie musi wyjaśniać pełnej statycznej budowy systemu. W razie potrzeby różne widoki uzupełniają się.

Przykład: model wypożyczenia w bibliotece#

Załóżmy, że chcemy uzgodnić trzy podstawowe pojęcia w bibliotece: czytelnika, fizyczny egzemplarz książki i wypożyczenie. Rozróżnienie egzemplarza od tytułu ma znaczenie: biblioteka może posiadać kilka fizycznych kopii tej samej książki, a pojedyncze wypożyczenie dotyczy jednej z nich.

Poniższy diagram klas przedstawia pojęcia jako klasy i łączy je asocjacjami. Liczność przy końcu asocjacji mówi, ile obiektów po tej stronie może być powiązanych z jednym obiektem po stronie przeciwnej.

Czytając pierwszą asocjację od strony Wypożyczenia, widzimy 1 przy Czytelniku: każde wypożyczenie w tym modelu jest powiązane z dokładnie jednym czytelnikiem. Zapis 0..* przy Wypożyczeniu mówi odwrotnie, że jeden czytelnik może być powiązany z żadnym, jednym albo wieloma wypożyczeniami. Druga asocjacja ma tę samą logikę: każde wypożyczenie dotyczy jednego egzemplarza, a egzemplarz może uczestniczyć w wielu wypożyczeniach.

„Wielu” nie znaczy tu „w tym samym czasie”. Diagram nie określa, czy egzemplarz może być równocześnie wypożyczony kilku osobom, ponieważ nie modeluje okresów wypożyczeń ani reguły dostępności. Nie przedstawia też dat, zwrotów, rezerwacji, kar, anulowanych prób ani historii zmian. Te informacje można dodać do bogatszego modelu, ale tylko wtedy, gdy służą celowi konkretnego diagramu. W tym przykładzie każde Wypożyczenie oznacza zarejestrowany fakt wypożyczenia egzemplarza, a nie próbę, która może zakończyć się niepowodzeniem.

Jest to model pojęć dziedziny, a nie gotowy projekt kodu lub bazy danych. Klasa Wypożyczenie nie musi odpowiadać tabeli o tej samej nazwie, a klasa Czytelnik nie przesądza o tym, jak dane czytelnika będą przechowywane. Przejście od modelu dziedziny do projektu technicznego wymaga odrębnych decyzji.

Do czego używa się UML?#

Zespół może użyć UML do wyjaśniania pojęć i wymagań, analizowania wariantów, projektowania struktury, opisywania przebiegów i stanów, uzgadniania interfejsów albo dokumentowania decyzji. Diagram stanowi wspólny punkt odniesienia dla osób o różnych rolach — na przykład analityków, programistów, testerów i osób odpowiedzialnych za proces — o ile zawiera informacje istotne dla ich rozmowy.

Model może pomagać wykrywać braki lub sprzeczności przed implementacją, bo zmusza do nazwania elementów i pokazania zależności. Nie dowodzi jednak, że wymagania są kompletne ani że system zadziała poprawnie. Wniosek zależy od prawdziwości założeń, właściwego zakresu modelu i umiejętności jego odczytania. Model jest narzędziem do myślenia i komunikacji, nie automatycznym certyfikatem jakości.

UML może też być wejściem dla narzędzi. Zależnie od narzędzia i rodzaju modelu możliwa jest analiza, wymiana danych modelu, synchronizacja z kodem albo generowanie części artefaktów. Sam standard nie sprawia jednak, że każdy diagram jest wykonywalny ani że z dowolnego rysunku można automatycznie uzyskać poprawny program. Automatyzacja wymaga dodatkowych reguł, informacji i wsparcia konkretnego narzędzia.

Czym UML nie jest?#

• Nie jest językiem programowania. Zapis UML opisuje model; typowo nie zastępuje kodu, który komputer wykonuje.
• Nie jest metodyką ani cyklem życia projektu. Nie nakazuje pracy kaskadowej, iteracyjnej, zwinnej ani używania określonej liczby diagramów.
• Nie jest jedną obowiązkową dokumentacją całego systemu. Autor wybiera diagramy i poziom szczegółowości stosownie do celu.
• Nie gwarantuje poprawności rozwiązania. Poprawne symbole mogą przedstawiać niewłaściwe pojęcia, założenia lub relacje.
• Nie jest nazwą konkretnego programu. PlantUML to narzędzie, które potrafi wygenerować diagram z tekstowego zapisu; jego składnia jest sposobem tworzenia grafiki, a nie definicją całego UML.

Jak wybrać diagram i poziom szczegółowości?#

Zacznij od pytania, na które odbiorca ma odpowiedzieć. Jeśli chodzi o pojęcia i powiązania — rozważ diagram klas. Jeśli o cele użytkowników — diagram przypadków użycia. Jeśli o kolejność komunikatów — diagram sekwencji. Jeśli o przebieg procesu — diagram aktywności. Jeżeli pytanie dotyczy zmian stanu — diagram maszyny stanów. Nie trzeba tworzyć diagramu tylko dlatego, że UML go oferuje; tekst, tabela albo rozmowa mogą czasem przekazać informację prościej.

Następnie określ granicę modelu: jaki system, scenariusz lub zakres obejmuje, co pomija i kto będzie go czytać. Dobierz szczegółowość do decyzji. Szkic roboczy może pokazywać tylko pojęcia potrzebne do rozmowy; model przeznaczony do wymiany z narzędziami może wymagać precyzyjniejszych typów, relacji i ograniczeń. W obu przypadkach niejasne założenia należy objaśnić, zamiast liczyć, że sam rysunek rozstrzygnie każdą interpretację.

UML a narzędzia do diagramów#

UML określa język i jego reguły; aplikacja dostarcza interfejs do tworzenia, przechowywania, sprawdzania lub renderowania modeli. Narzędzie może udostępniać edytor graficzny albo tekstowy. PlantUML należy do tej drugiej grupy: autor zapisuje elementy i relacje krótkimi instrukcjami, a program generuje z nich diagram.

Wygenerowanie obrazu potwierdza, że narzędzie rozpoznało obsługiwaną składnię. Nie jest samo w sobie dowodem, że model odpowiada pełnej semantyce UML albo trafnie opisuje rzeczywisty problem. Przy czytaniu przykładu w PlantUML oddzielaj więc dwa pytania: „co oznacza model?” oraz „jak zapisać go w tym narzędziu?”.

Najważniejsze wnioski#

• UML to standardowy, ogólnego przeznaczenia język modelowania, a nie język programowania ani metodyka projektu.
• Model jest wybranym, uproszczonym opisem; diagram pokazuje graficzny widok jego części, a notacja określa, jak ten widok odczytywać.
• UML obejmuje typy diagramów strukturalnych i zachowania, w tym diagramy interakcji; wybór zależy od pytania, celu i odbiorcy.
• Diagram może wspierać analizę i komunikację, ale jego poprawność składniowa nie gwarantuje trafności założeń ani kompletności systemu.
• Narzędzia mogą ułatwiać edycję, wymianę i przetwarzanie modeli, lecz same nie zastępują decyzji modelarskich.