Samouczek dotyczący diagramów UML

Jeden obraz wart jest tysiąca słów. Właśnie dlatego powstał Unified Modeling Language (UML) — aby zapewnić wspólny język wizualny w złożonym świecie tworzenia oprogramowania, zrozumiały również dla użytkowników biznesowych i każdego, kto chce pojąć zasady działania systemu. Ten przewodnik zawiera wszystko, co musisz wiedzieć o UML. Nawet jeśli Twoje pierwsze zetknięcie z UML miało miejsce podczas formalnego szkolenia i od tamtej pory rzadko z niego korzystasz, nadal pozostaje on praktycznym sposobem na utrzymanie czytelności złożonych systemów — zwłaszcza gdy służy jako żywa dokumentacja, a nie tylko jednorazowy projekt.

Czym jest UML?

Unified Modeling Language (UML) powstał, aby stworzyć wspólny, bogaty pod względem semantycznym i składniowym wizualny język modelowania na potrzeby architektury, projektowania i wdrażania złożonych systemów oprogramowania, zarówno w ujęciu strukturalnym, jak i behawioralnym.

Jest on analogiczny do planów architektonicznych stosowanych w innych dziedzinach i składa się z różnych typów diagramów. Łącznie diagramy UML opisują granice, strukturę oraz zachowanie systemu i znajdujących się w nim obiektów. Podczas pisania kodu aplikacja składa się z tysięcy linii, przez co trudno jest śledzić relacje i hierarchie w systemie oprogramowania. Diagramy UML dzielą ten system na komponenty i podkomponenty.

Istnieją cztery kategorie modeli rozwiązywania problemów: języki imperatywne, funkcyjne, deklaratywne i obiektowe. W językach obiektowych algorytmy są wyrażane poprzez definiowanie „obiektów” i wprowadzanie ich w interakcje ze sobą. Obiekty te są elementami poddawanymi manipulacji i istnieją w świecie rzeczywistym. Mogą to być budynki, widżety na pulpicie lub ludzie.

Języki obiektowe dominują w świecie programowania, ponieważ modelują obiekty ze świata rzeczywistego. UML stanowi połączenie kilku notacji obiektowych: projektowania obiektowego, techniki modelowania obiektowego oraz inżynierii oprogramowania obiektowego.

UML wykorzystuje mocne strony tych trzech podejść, aby zaprezentować spójniejszą i łatwiejszą w użyciu metodologię. Odzwierciedla on najlepsze praktyki w zakresie tworzenia i dokumentowania różnych aspektów modelowania oprogramowania oraz systemów biznesowych. Dzięki standaryzacji UML można stosować niezależnie od języków programowania i procesów programistycznych, co czyni go powszechnie zrozumiałym dla większości deweloperów.

W praktyce UML jest również formą wizualnej dokumentacji, która pozwala skrócić czas poświęcany na ponowne wyjaśnianie zasad działania systemu. Dokumentacja ta pomaga inżynierom na wiele sposobów — od wdrożenia nowych pracowników (onboardingu) po przedstawienie interesariuszom szybkiego przeglądu systemu, dzięki czemu programiści nie marnują czasu na spotkaniach.

Historia i geneza UML

Grady Booch, James Rumbaugh i Ivar Jacobson, znani również jako „Trzej Amigos” inżynierii oprogramowania, połączyli siły, aby zapewnić programistom jasność poprzez stworzenie nowych standardów.

Wysiłki tej grupy doprowadziły do opublikowania dokumentów UML 0.9 i 0.91 w 1996 roku. Szybko stało się jasne, że wiele organizacji, w tym Microsoft, Oracle i IBM, uznało UML za kluczowy element rozwoju własnego biznesu. Wraz z wieloma innymi osobami i firmami stworzyły one zasoby umożliwiające opracowanie pełnoprawnego języka modelowania. „Trzej Amigos” opublikowali podręcznik „The Unified Modeling Language User Guide” w 1999 roku oraz jego aktualizację w 2005 roku, która obejmowała wersję UML 2.0.

Rola Object Management Group (OMG) w rozwoju UML

Zgodnie z informacjami na stronie internetowej, Object Management Group® (OMG®) to międzynarodowe konsorcjum ds. standardów technologicznych typu open membership i not-for-profit, założone w 1989 roku. Standardy OMG są rozwijane przez dostawców, użytkowników końcowych, instytucje akademickie i agencje rządowe. Grupy robocze OMG (OMG Task Forces) opracowują standardy integracji przedsiębiorstw dla szerokiej gamy technologii i jeszcze większej liczby branż. Standardy modelowania OMG, w tym UML oraz Model Driven Architecture® (MDA®), umożliwiają zaawansowane wizualne projektowanie, realizację i utrzymanie oprogramowania oraz innych procesów.

OMG nadzoruje definiowanie i utrzymywanie specyfikacji UML. Nadzór ten daje inżynierom i programistom możliwość używania jednego języka do wielu celów we wszystkich fazach cyklu życia oprogramowania, niezależnie od wielkości systemu.

OMG definiuje cel UML jako:

• Zapewnienie architektom systemów, inżynierom oprogramowania i programistom narzędzi do analizy, projektowania i wdrażania systemów opartych na oprogramowaniu, a także do modelowania biznesowego i podobnych procesów.

• Rozwój branży poprzez umożliwienie interoperacyjności wizualnych narzędzi do modelowania obiektowego. Aby jednak zapewnić znaczącą wymianę informacji o modelach między narzędziami, wymagana jest zgoda co do semantyki i notacji.

UML spełnia następujące wymagania:

• Ustanowienie formalnej definicji wspólnego metamodelu opartego na Meta-Object Facility (MOF), który określa składnię abstrakcyjną UML. Składnia abstrakcyjna definiuje zestaw pojęć modelowania UML, ich atrybuty i relacje, a także reguły łączenia tych pojęć w celu budowania częściowych lub kompletnych modeli UML.

• Zapewnienie szczegółowego wyjaśnienia semantyki każdego pojęcia modelowania UML. Semantyka definiuje w sposób niezależny od technologii, jak pojęcia UML mają być realizowane przez komputery.

• Określenie czytelnych dla człowieka elementów notacji służących do reprezentowania poszczególnych pojęć modelowania UML, a także reguł łączenia ich w różne typy diagramów odpowiadające odmiennym aspektom modelowanych systemów.

• Zdefiniowanie sposobów, w jakie narzędzia UML mogą zachować zgodność z tą specyfikacją. Jest to obsługiwane (w osobnej specyfikacji) przez opartą na formacie XML specyfikację odpowiednich formatów wymiany modeli (XMI), które muszą być realizowane przez zgodne narzędzia.

Słownik pojęć UML

Zapoznaj się ze słownictwem UML dzięki tej liście zaczerpniętej z dokumentu UML 2.4.1, która ma pomóc osobom nienależącym do OMG zrozumieć powszechnie używane terminy.

• Zgodność ze składnią abstrakcyjną: Użytkownicy mogą przenosić modele między różnymi narzędziami, nawet jeśli używają one innych notacji.

• Common Warehouse Metamodel (CWM): Standardowe interfejsy używane do umożliwienia wymiany metadanych hurtowni danych i analiz biznesowych (business intelligence) między narzędziami hurtowni, platformami hurtowni i repozytoriami metadanych hurtowni w rozproszonych środowiskach heterogenicznych.

• Zgodność ze składnią konkretną: Użytkownicy mogą nadal korzystać ze znanej sobie notacji w różnych narzędziach.

• Rdzeń (Core): W kontekście UML rdzeń zazwyczaj odnosi się do „pakietu rdzenia” (core package), który jest kompletnym metamodelem zaprojektowanym specjalnie z myślą o wysokiej gotowości do ponownego użycia.

• Jednostka językowa (Language unit): Składa się z kolekcji ściśle powiązanych pojęć modelowania, które dają użytkownikom możliwość reprezentowania aspektów badanego systemu zgodnie z określonym paradygmatem lub formalizmem.

• Poziom 0 (L0): Podstawowy poziom zgodności infrastruktury UML; pojedyncza jednostka językowa umożliwiająca modelowanie struktur klasowych spotykanych w większości popularnych obiektowych języków programowania.

• Meta Object Facility (MOF): Specyfikacja modelowania OMG, która stanowi podstawę definicji metamodeli w rodzinie języków MDA należących do OMG.

• Metamodel: Definiuje język i procesy, na podstawie których tworzy się model.

• Konstrukcje metamodelu (LM): Drugi poziom zgodności w infrastrukturze UML; dodatkowa jednostka językowa dla bardziej zaawansowanych struktur klasowych używanych do budowania metamodeli (przy użyciu CMOF), takich jak sam UML. UML ma tylko dwa poziomy zgodności.

• Model Driven Architecture (MDA): Podejście i plan mający na celu osiągnięcie spójnego zestawu specyfikacji technologicznych opartych na modelach.

• Object Constraint Language (OCL): Język deklaratywny do opisywania reguł stosowanych w Unified Modeling Language. OCL uzupełnia UML, udostępniając terminy i symbole schematów blokowych, które są bardziej precyzyjne niż język naturalny, ale łatwiejsze do opanowania niż matematyka.

• Object Management Group (OMG): Konsorcjum ds. specyfikacji branży komputerowej typu not-for-profit, którego członkowie definiują i utrzymują specyfikację UML.

• UML 1: Pierwsza wersja języka Unified Modeling Language.

• Unified Modeling Language (UML): Język wizualny do określania, tworzenia i dokumentowania artefaktów systemowych.

• XMI: Oparta na formacie XML specyfikacja odpowiednich formatów wymiany modeli.

Typy diagramów UML

UML wykorzystuje elementy i łączy je na różne sposoby, tworząc diagramy statyczne (które reprezentują strukturalne aspekty systemu) oraz diagramy behawioralne (które reprezentują dynamiczne aspekty systemu). Niewtajemniczonym może się wydawać, że istnieje nieskończona liczba diagramów UML, ale w rzeczywistości standardy UML wyróżniają 14 typów diagramów, które dzielą się na dwie grupy zdefiniowane poniżej.

Strukturalne diagramy UML

• Diagram klas: Jest to najczęściej używany diagram UML i podstawa każdego rozwiązania obiektowego. Pokazuje klasy w systemie, atrybuty i operacje oraz relacje między poszczególni klasami. Podczas tworzenia diagramów dużych systemów klasy są łączone w grupy. Klasa jest reprezentowana przez prostokąt, który zawiera trzy pionowo ułożone sekcje: górna sekcja zawiera nazwę klasy i jest obowiązkowa, natomiast dwie dolne sekcje zawierają szczegółowe informacje o atrybutach klasy oraz operacjach lub zachowaniach klasy.

• Diagram komponentów: Diagram komponentów to w zasadzie bardziej wyspecjalizowana wersja diagramu klas — dla obu obowiązują te same reguły notacji. Diagram komponentów dzieli złożony system na mniejsze komponenty i wizualizuje relacje między nimi.

• Diagram struktury złożonej: Tego typu diagramy są w zasadzie planami wewnętrznej struktury klasyfikatora. Mogą być również używane do pokazywania zachowania współpracy lub interakcji klasyfikatora z otoczeniem za pomocą portów. Pozwalają łatwo przedstawić wewnętrzne komponenty dowolnego sprzętu, aby dokładniej zrozumieć jego wewnętrzne działanie.

• Diagram wdrożenia: Diagramy te są najbardziej przydatne dla inżynierów systemowych i zazwyczaj przedstawiają wydajność, skalowalność, łatwość konserwacji oraz przenośność. Gdy komponenty sprzętowe są wyświetlane w relacji do siebie, łatwiej jest śledzić całą sieć sprzętową i upewnić się, że wszystkie elementy zostały uwzględnione we wdrożeniu.

• Diagram obiektów: Diagramy obiektów pokazują przykłady struktur danych w określonym momencie. Możesz użyć diagramu klas do pokazania struktury, a następnie użyć diagramów obiektów jako przypadków testowych w celu zweryfikowania kompletności diagramu klas. Możesz też utworzyć diagram obiektów, aby odkryć informacje o elementach modelu i ich powiązaniach.

• Diagram pakietów: Diagramy pakietów służą do pokazywania zależności między różnymi pakietami w systemie. Pakiet, przedstawiony jako folder na pliki, organizuje elementy modelu, takie jak przypadki użycia lub klasy, w grupy. Między pakietami zdefiniowane są dwa specjalne typy zależności: import pakietu (package import) i scalanie pakietów (package merge).

• Diagramy profili: Diagramy profili są również częścią standardu UML i służą głównie do dostosowywania UML do konkretnej dziedziny. Dodane niedawno w wersji UML 2.0 diagramy profili są unikalne i rzadko stosowane w specyfikacjach. Diagram profilu najlepiej rozumieć jako mechanizm rozszerzalności służący do dostosowywania modeli UML do określonych dziedzin i platform.

Behawioralne diagramy UML

• Diagramy czynności: Diagramy czynności są stosowane jako alternatywa dla diagramów maszyn stanowych. Wizualizują one kroki wykonywane w ramach przypadku użycia — czynności mogą być sekwencyjne, rozgałęzione lub współbieżne. Ten typ diagramu UML służy do pokazywania dynamicznego zachowania systemu, ale może być również przydatny w modelowaniu procesów biznesowych.

• Diagram komunikacji: Diagramy komunikacji, dawniej nazywane diagramami współpracy, pokazują, jak obiekty odnoszą się do siebie. Modelują one sposób, w jaki obiekty łączą się i komunikują za pomocą komunikatów w ramach projektu architektonicznego systemu. Mogą również pokazywać alternatywne scenariusze w przypadkach użycia lub operacje wymagające współpracy różnych obiektów i interakcji.

• Diagram przeglądu interakcji: Ten diagram przedstawia ogólny przepływ sterowania między interaktywnymi węzłami. Obejmują one węzły początkowe, węzły końcowe przepływu, węzły końcowe czynności, węzły decyzyjne, węzły scalające, węzły rozwidlenia i węzły połączenia.

• Diagram sekwencji: Diagram sekwencji, czasami nazywany diagramem zdarzeń lub scenariuszem zdarzeń, pokazuje kolejność, w jakiej obiekty wchodzą w interakcje. W ten sposób możesz wizualnie przedstawić proste scenariusze wykonawcze (runtime).

• Diagram stanów: Diagramy stanów, mówiąc najprościej, przedstawiają stany i przejścia. Stan odnosi się do różnych kombinacji informacji, które obiekt może przechowywać, a ten diagram UML pozwala zwizualizować wszystkie możliwe stany oraz sposób, w jaki obiekt przechodzi z jednego stanu w kolejny.

• Diagram harmonogramowania: Często opisywany jako odwrócony diagram sekwencji, diagram harmonogramowania (timing diagram) pokazuje, jak obiekty oddziałują na siebie w określonym czasie. Użyj tych diagramów, aby zobaczyć, ile czasu zajmuje każdy krok procesu i znaleźć obszary do optymalizacji.

• Diagram przypadków użycia: Diagramy przypadków użycia modelują interakcje użytkowników, przedstawionych jako postacie zwane "aktorami", z systemem. Ten typ diagramu UML powinien stanowić wysokopoziomowy przegląd relacji między aktorami a systemami, dzięki czemu jest doskonałym narzędziem do objaśniania działania systemu nietechnicznym odbiorcom.

Koncepcje modelowania określone przez UML

Rozwój systemu koncentruje się na trzech ogólnych, odmiennych modelach systemu:

• Funkcjonalny: Są to diagramy przypadków użycia, które opisują funkcjonalność systemu z punktu widzenia użytkownika.
• Obiektowy: Są to diagramy klas, które opisują strukturę systemu w kategoriach obiektów, atrybutów, powiązań i operacji.
• Dynamiczny: Diagramy interakcji, diagramy maszyn stanowych i diagramy czynności są używane do opisywania wewnętrznego zachowania systemu.

Te modele systemowe są wizualizowane za pomocą dwóch różnych typów diagramów: strukturalnych i behawioralnych.

Koncepcje obiektowe w UML

Obiekty w UML to encje ze świata rzeczywistego, które nas otaczają. W tworzeniu oprogramowania obiekty mogą być używane do opisywania lub modelowania tworzonego systemu w kategoriach istotnych dla danej dziedziny. Obiekty pozwalają również na rozbicie złożonych systemów na zrozumiałe komponenty, co umożliwia budowanie jednego elementu na raz.

Oto kilka fundamentalnych koncepcji świata obiektowego:

• Obiekty: Reprezentują encję i podstawowy budulec
• Klasa: Plan (szablon) obiektu.
• Abstrakcja: Zachowanie encji ze świata rzeczywistego
• Enkapsulacja (hermetyzacja): Mechanizm wiązania danych ze sobą i ukrywania ich przed światem zewnętrznym
• Dziedziczenie: Mechanizm tworzenia nowych klas na podstawie już istniejących
• Polimorfizm: Definiuje mechanizm występowania w różnych formach

W nowoczesnych zespołach — zwłaszcza tych praktykujących zwinne metodyki (Agile) — te koncepcje obiektowe są często najłatwiejsze do przekazania, gdy diagramy są traktowane jako „główna dokumentacja” i aktualizowane wraz z kodem, a nie tworzone raz i pozostawiane bez zmian.

Dlaczego zespoły nadal używają diagramów UML (szczególnie w Agile)

Jeśli masz za sobą formalne szkolenie z programowania, prawdopodobnie z diagramami UML zetknąłeś się w szkole lub na studiach. Ale jak często używasz ich od tamtego momentu? Ponieważ budowanie diagramów UML wymaga czasu, a w środowisku Agile stają się one dość szybko nieaktualne, wielu programistów o nich zapomniało.

Ta obawa jest słuszna: diagramy, które nie rozwijają się wraz z projektem, szybko tracą na wartości. Jednak gdy są aktualizowane na bieżąco, UML przyspiesza prace programistyczne i rozjaśnia komunikację. Choć wielu inżynierów obawia się diagramów, są one niezwykle przydatne w zwinnym środowisku programistycznym. Pozwalają utrzymać produktywność i koncentrację podczas prac. Zamiast myśleć o nich jako o czymś, co „warto mieć”, traktuj diagramy UML jako kluczowe elementy dokumentacji.

Diagramy UML pomagają zespołom inżynieryjnym:

• Szybko wdrażać nowych członków zespołu lub programistów zmieniających zespoły.

• Poruszać się po kodzie źródłowym.

• Planować nowe funkcje jeszcze przed rozpoczęciem programowania.

• Łatwiej komunikować się z technicznymi i nietechnicznymi odbiorcami.

Jednak diagramy, które nie zmieniają się wraz z projektem, stają się bezużyteczne, dlatego konieczne jest posiadanie stale aktualizowanych modeli. Jednym ze sposobów na zmniejszenie obciążeń związanych z konserwacją jest generowanie diagramów z lżejszych danych wejściowych (na przykład definicji tekstowych), dzięki czemu dokumentacja pozostaje elastyczna w miarę zmian w systemie. Lucidchart umożliwia generowanie diagramów sekwencji UML ze znaczników tekstowych, co czyni proces tworzenia diagramów automatycznym i elastycznym.

Jak stworzyć diagram UML

Diagramy UML opierają się na określonym zestawie reguł i kształtów, a nauka poprawnego budowania każdego typu zajmuje sporo czasu. Na szczęście ułatwiliśmy to zadanie dzięki prostym samouczkom (zaczynając od diagramów klas), które poprowadzą Cię przez ten proces krok po kroku.

Niezależnie od używanego narzędzia, praktyczny przepływ pracy jest spójny: wybierz typ diagramu odpowiadający Twojemu pytaniu (struktura vs. zachowanie), modeluj tylko to, czego potrzebujesz dla bieżących odbiorców, i wracaj do diagramu w miarę zmian w kodzie i wymaganiach. Bez względu na to, czy rozplanowujesz statyczną architekturę nowego systemu oprogramowania, czy wizualizujesz dynamiczne interakcje użytkowników, wykonaj poniższe kroki, aby zbudować skuteczny model:

1. Zdefiniuj swój cel

Określ dokładnie, co chcesz zwizualizować. Zadaj sobie pytanie, czy musisz odwzorować statyczną strukturę systemu (diagram strukturalny), czy pokazać, jak komponenty wchodzą w interakcje i zmieniają się w czasie (diagram behawioralny).

2. Wybierz odpowiedni typ diagramu

Na podstawie wymagań systemowych wybierz odpowiedni diagram UML. For example, use a class diagram for object-oriented system structure, a sequence diagram for time-ordered interactions, or a use case diagram to illustrate user functionality. (Wskazówka: rozpoczęcie od jednego z gotowych szablonów UML w Lucidchart to najszybszy sposób na start).

3. Włącz biblioteki kształtów UML

Ponieważ UML korzysta ze ścisłego słownictwa wizualnego, potrzebujesz odpowiednich symboli. W Lucidchart kliknij "Więcej kształtów" u dołu lewego menu, wyszukaj "UML" i zaznacz pola wyboru dla określonych bibliotek kształtów, których potrzebujesz (np. klasy UML, stany UML, sekwencje UML).

4. Dodaj i zdefiniuj swoje kształty

Przeciągnij i upuść encje, obiekty, węzły lub aktorów na obszar roboczy. Rozmieść je logicznie i kliknij dwukrotnie wewnątrz kształtów, aby dodać niestandardowy tekst, określone atrybuty oraz operacje do swoich obiektów.

5. Połącz swoje komponenty

Ustanów relacje między swoimi encjami, rysując między nimi linie. Dostosuj punkty końcowe linii (grot strzałki, romby itp.), aby dokładnie odzwierciedlić określone relacje UML, takie jak dziedziczenie, kompozycja, zależności lub podstawowe powiązania.

6. Przejrzyj i współpracuj

UML został zaprojektowany jako wspólny język dla programistów, inżynierów i interesariuszy biznesowych. Po sporządzeniu szkicu diagramu użyj funkcji współpracy w czasie rzeczywistym Lucidchart, aby zaprosić swój zespół do sprawdzenia architektury, pozostawienia komentarzy i sfinalizowania projektu.

Zostań ewangelistą UML

Czasami nie wystarczy, że to Ty przekonasz się do tworzenia diagramów UML. W końcu jako programista zazwyczaj pracujesz w zespole, dlatego ważne jest, aby pociągnąć za sobą innych.

If your team is reluctant to integrate UML diagrams into the development process, propose using them for just one project to start. Gdy zespół zobaczy, jak wielkim dobrodziejstwem dla dokumentacji są diagramy UML, chętniej uczyni z nich obowiązkowy etap prac.

Ponadto z Lucidchart diagramy UML nie są przykrym obowiązkiem — są atutem.