Czym jest UML (Unified Modeling Language)

UML (Unified Modeling Language) został opracowany w celu stworzenia wspólnego, bogatego semantycznie i składniowo wizualnego języka modelowania dla architektury, projektowania i implementacji złożonych systemów oprogramowania, zarówno pod względem strukturalnym, jak i behawioralnym. UML jest stosowany nie tylko przy tworzeniu oprogramowania, ale także w procesach produkcyjnych.

Jest on analogiczny do schematów używanych w innych dziedzinach i składa się z różnych rodzajów diagramów. Ogólnie rzecz biorąc, diagramy UML opisują granice, strukturę i zachowanie systemu oraz obiektów w nim zawartych.

UML nie jest językiem programowania, ale istnieją narzędzia, które mogą być używane do generowania kodu w różnych językach przy użyciu diagramów UML. UML ma bezpośredni związek z analizą i projektowaniem zorientowanym obiektowo.

W informatyce, która jest nauką o algorytmach i danych, istnieje wiele paradygmatów lub modeli rozwiązywania problemów. Istnieją cztery kategorie modeli rozwiązywania problemów: języki imperatywne, funkcyjne, deklaratywne i zorientowane obiektowo (OOP).  W językach zorientowanych obiektowo algorytmy są wyrażane poprzez definiowanie „obiektów” i ich wzajemne oddziaływanie na siebie. Obiekty te są elementami, którymi można manipulować i które istnieją w świecie rzeczywistym. Mogą to być budynki, widżety na pulpicie czy ludzie.  

Języki zorientowane obiektowo zdominowały świat programowania, ponieważ modelują obiekty świata rzeczywistego. UML stanowi połączenie kilku notacji zorientowanych obiektowo: projektowania obiektowego, techniki modelowania obiektowego i inżynierii oprogramowania obiektowego.

UML wykorzystuje mocne strony tych trzech podejść, by przedstawić bardziej spójną metodologię, która jest łatwiejsza w użyciu. UML przedstawia najlepsze praktyki budowania i dokumentowania różnych aspektów modelowania oprogramowania i systemów biznesowych.

Autorzy znani jako „Trzej przyjaciele” inżynierii oprogramowania opracowali inne metodologie. Połączyli siły, żeby stworzyć nowe standardy, które będą jasne dla programistów. Dzięki współpracy Booch, Rumbaugh i Jacobson wszystkie trzy metody stały się lepsze i udoskonaliły produkt końcowy.

Dzięki staraniom tych myślicieli w 1996 roku ukazały się dokumenty UML 0.9 i 0.91. Bardzo szybko okazało się, że kilka organizacji, w tym Microsoft, Oracle i IBM, uznało UML za kluczowy element rozwoju ich własnej działalności. To oni, wraz z wieloma innymi osobami i firmami, stworzyli zasoby, dzięki którym można było rozwinąć pełnowartościowy język modelowania. Trzech przyjaciół opublikowało podręcznik The Unified Modeling Language User Guide w 1999 roku oraz aktualizację zawierającą informacje o UML 2.0 w drugim wydaniu z 2005 roku.

Według strony internetowej Object Management Group® (OMG®) jest międzynarodowym, ogólnodostępnym, nienastawionym na zysk konsorcjum zajmującym się standardami technologicznymi, założonym w 1989 roku. Standardy OMG są tworzone przez sprzedawców, użytkowników końcowych, instytucje akademickie i agencje rządowe. Grupy zadaniowe OMG opracowują standardy integracji przedsiębiorstw dla szerokiej gamy technologii i jeszcze szerszej gamy branż. Standardy modelowania OMG, w tym UML i Model Driven Architecture® (MDA®), umożliwiają wydajne wizualne projektowanie, wykonywanie i utrzymywanie oprogramowania oraz innych procesów.

OMG nadzoruje definiowanie i utrzymywanie specyfikacji UML. Ten nadzór daje inżynierom i programistom możliwość używania jednego języka do wielu celów na wszystkich etapach cyklu życia oprogramowania dla wszystkich rozmiarów systemów.

OMG następująco definiuje przeznaczenie UML:

• Architektom systemów, inżynierom oprogramowania i programistom zapewnia narzędzia do analizy, projektowania i implementacji systemów opartych na oprogramowaniu, a także do modelowania procesów biznesowych i podobnych.
• Poprawia sytuację w branży, umożliwiając współdziałanie narzędzi do modelowania wizualnego obiektów. Jednak, aby możliwa była sensowna wymiana informacji o modelu między narzędziami, konieczne jest osiągnięcie porozumienia co do semantyki i notacji.

UML spełnia następujące wymagania:

• Ustanawia formalną definicję wspólnego metamodelu opartego na MOF (Meta-Object Facility), który określa abstrakcyjną składnię UML. Abstrakcyjna składnia definiuje zestaw pojęć modelowania UML, ich atrybuty i relacje między nimi, a także zasady łączenia tych pojęć w celu zbudowania częściowych lub pełnych modeli UML.
• Zawiera szczegółowe wyjaśnienie semantyki każdego z pojęć modelowania UML. Semantyka określa, 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 koncepcji modelowania UML, a także reguł łączenia ich w wiele różnych typów diagramów odpowiadających różnym aspektom systemów będących przedmiotem modelowania.
• Określa, w jaki sposób narzędzia UML mogą stać się zgodne z tą specyfikacją. Wspomaga to (w osobnej specyfikacji) oparta na XML specyfikacja odpowiednich formatów wymiany modeli (XMI), które muszą być realizowane przez zgodne narzędzia.

UML jest popularny wśród programistów, ale nie jest powszechnie używany przez twórców baz danych. Jednym z powodów jest po prostu to, że twórcy UML nie skupiali się na bazach danych. Mimo to UML sprawdza się w wysokopoziomowym modelowaniu danych koncepcyjnych i można go stosować w różnych typach diagramów UML. Informacje o nakładaniu obiektowego modelu klas na relacyjną bazę danych znajdziesz w artykule Modelowanie baz danych w UML.

UML jest nieustannie udoskonalany. UML 2.0 rozszerza specyfikacje UML, obejmując więcej aspektów rozwoju, w tym Agile. Celem było zrestrukturyzowanie i udoskonalenie UML tak, by uprościć użyteczność, implementację i adaptację. Oto kilka aktualizacji diagramów UML:

• Lepsza integracja między modelami strukturalnymi i behawioralnymi.
• Zdolność do definiowania hierarchii i podziału systemu oprogramowania na komponenty i subkomponenty.
• UML 2.0 zwiększa liczbę diagramów z 9 do 13.

Zapoznaj się z terminologią UML, korzystając z tej listy zaczerpniętej z dokumentu UML 2.4.1, która ma pomóc osobom niebędącym członkami OMG w zrozumieniu powszechnie używanych terminów.

• Zgodność z abstrakcyjną składnią (Abstract syntax compliance)

  Użytkownicy mogą przenosić modele między różnymi narzędziami, nawet jeśli używają one różnych notacji

• CWM (Common Warehouse Metamodel)

  Standardowe interfejsy, które służą do umożliwienia wymiany metadanych magazynowych i metadanych business intelligence pomiędzy narzędziami magazynowymi, platformami magazynowymi i repozytoriami metadanych magazynowych w rozproszonych środowiskach heterogenicznych

• Zgodność z konkretną składnią

  Użytkownicy mogą nadal korzystać z notacji, z którą są zaznajomieni, w różnych narzędziach

• Rdzeń (Core)

  W kontekście UML, rdzeń zwykle odnosi się do "pakietu podstawowego", który jest kompletnym metamodelem zaprojektowanym specjalnie z myślą o wysokiej wielokrotnej użyteczności.

• Jednostka językowa (Language Unit)

  Składa się z kolekcji ściśle powiązanych ze sobą koncepcji modelowania, które dają użytkownikom możliwość reprezentowania aspektów badanego systemu zgodnie z określonym paradygmatem lub formalizmem.

• Poziom 0 (Level 0)

  Dolny poziom zgodności dla infrastruktury UML – pojedyncza jednostka języka, która umożliwia modelowanie rodzajów struktur opartych na klasach spotykanych w większości popularnych obiektowych języków programowania

• MOF (Meta Object Facility)

  Specyfikacja modelowania OMG, która stanowi podstawę dla definicji metamodeli w rodzinie języków MDA od OMG.

• Metamodel

  Definiuje język i procesy, z których można stworzyć model

• Konstrukcje metamodelu (LM)

   Drugi poziom zgodności w infrastrukturze UML – dodatkowa jednostka języka dla bardziej zaawansowanych struktur opartych na klasach, używanych do budowania metamodeli (przy użyciu CMOF), takich jak sam UML. UML ma tylko dwa poziomy zgodności

• MDA (Model Driven Architecture)

  Podejście i plan osiągnięcia spójnego zestawu specyfikacji technologicznych opartych na modelu.

• OCL (Object Constraint Language)

  Deklaratywny język do opisywania reguł, które mają zastosowanie w UML. OCL uzupełnia UML, zapewniając terminy i symbole diagramów blokowych, które są bardziej precyzyjne niż język naturalny, ale mniej trudne do opanowania niż matematyka.

• Object Management Group (OMG)

  Konsorcjum specyfikacji przemysłu komputerowego nienastawione na zysk, którego członkowie definiują i utrzymują specyfikację UML.

• UML 1

  Pierwsza wersja języka UML (Unified Modeling Language).

• Unified Modeling Language (UML)

  Wizualny język do określania, konstruowania i dokumentowania artefaktów systemów.

• XMI

  Oparta na XML specyfikacja odpowiednich formatów wymiany modeli.

Wyświetl cały dokument MOF.

Pobierz kompletny Dokument infrastruktury UML 2.4.1.

Rozwój systemu koncentruje się na trzech zasadniczo różnych modelach systemu:

• Funkcjonalne:

  Są to diagramy przypadków użycia, które opisują funkcjonalność systemu z punktu widzenia użytkownika.

• Obiektowe:

  Są to diagramy klas, które opisują strukturę systemu w kategoriach obiektów, atrybutów, asocjacji i operacji.

• Dynamiczne:

  Diagramy interakcji, diagramy maszyn stanów i diagramy aktywności są używane do opisania wewnętrznego zachowania systemu.

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

Obiekty w UML są elementami świata rzeczywistego, które istnieją wokół nas. W rozwoju oprogramowania obiekty mogą być używane do opisywania lub modelowania tworzonego systemu w kategoriach, które są istotne dla danej dziedziny. Obiekty pozwalają też rozłożyć złożone systemy na zrozumiałe komponenty, które umożliwiają budowanie jednej części naraz.

Oto kilka podstawowych pojęć występujących w środowisku zorientowanym obiektowo:

• Obiekty

  Reprezentują encję i podstawowy blok konstrukcyjny.

• Klasa

  Blue print obiektu.

• Abstrakcja

  Zachowanie jednostki świata rzeczywistego.

• Hermetyzacja

  Mechanizm wiązania danych razem i ukrywania ich przed światem zewnętrznym.

• Dziedziczenie

  Mechanizm tworzenia nowych klas na podstawie istniejących.

• Polimorfizm

  Definiuje mechanizm, który może występować w różnych formach.

UML używa elementów i łączy je na różne sposoby, tworząc diagramy, które przedstawiają statyczne, czyli strukturalne aspekty systemu, oraz diagramy behawioralne, które oddają dynamiczne aspekty systemu.

Strukturalne diagramy UML

• Diagram klas

  Najczęściej używany diagram UML i podstawowy fundament każdego rozwiązania zorientowanego obiektowo. Klasy w systemie, atrybuty i operacje oraz relacje pomiędzy poszczególnymi klasami. Klasy są grupowane razem, by tworzyć diagramy klas podczas tworzenia diagramów dużych systemów.

• Diagram komponentów

  Wyświetla strukturalne relacje elementów systemu oprogramowania, najczęściej stosowane podczas pracy ze złożonymi systemami z wieloma komponentami. Komponenty komunikują się za pomocą interfejsów.

• Diagram struktury złożone

  Diagramy struktury złożonej są używane do pokazania wewnętrznej struktury klasy.

• Diagram wdrażania

  Przedstawia sprzęt systemowy i jego oprogramowanie. Przydaje się, gdy rozwiązanie programowe jest wdrażane na wielu maszynach o unikalnych konfiguracjach.

• Diagram obiektów

  Przedstawia relacje między obiektami na przykładach z prawdziwego świata i ilustruje, jak dany system będzie wyglądał w danym momencie. Dane są dostępne wewnątrz obiektów, dlatego można ich używać do wyjaśniania relacji między obiektami.
• Diagram pakietów Istnieją dwa specjalne rodzaje zależności zdefiniowanych pomiędzy pakietami: import pakietów i łączenie pakietów. Pakiety mogą reprezentować różne poziomy systemu, by ujawnić jego architekturę. Zależności pakietów mogą być zaznaczone, aby pokazać mechanizm komunikacji między poziomami.

Behawioralne diagramy UML

• Diagramy aktywności

  Graficzne odwzorowanie biznesowych lub operacyjnych przepływów pracy w celu pokazania aktywności każdej części lub komponentu systemu. Diagramy czynności są używane jako alternatywa dla diagramów maszyn stanów.

• Diagram komunikacji

  Podobny do diagramów sekwencji, ale skupia się na komunikatach przekazywanych pomiędzy obiektami. Te same informacje można przedstawić za pomocą diagramu sekwencji i różnych obiektów.
• Diagram przeglądu interakcji Istnieje siedem typów diagramów interakcji, a ten diagram pokazuje kolejność, w jakiej one działają.

• Diagram interakcji

  Przedstawia, jak obiekty oddziałują na siebie i w jakiej kolejności. Przedstawiają one interakcje dla konkretnego scenariusza.

• Diagram stanu

  Podobnie jak diagramy aktywności, opisuje on zachowanie obiektów, które w swoim aktualnym stanie zachowują się w różny sposób.

• Diagram czasowy

  Podobnie jak diagramy interakcji, przedstawia on zachowanie obiektów w danym przedziale czasowym. Jeśli istnieje tylko jeden obiekt, diagram jest prosty. Jeśli masz więcej niż jeden obiekt, interakcje pomiędzy obiektami są pokazywane w tym konkretnym przedziale czasowym.

• Diagram przypadków użycia

  Przedstawia konkretną funkcjonalność systemu, stworzoną po to, by zilustrować, jak funkcjonalności są ze sobą powiązane oraz jakie są ich wewnętrzne/zewnętrzne kontrolery (aktorzy).

Aby pokazać, jak tworzyć różne typy diagramów UML, skorzystaj z jednego lub wszystkich poniższych poradników, które przeprowadzą Cię przez proces rysowania zarówno diagramów strukturalnych, jak i behawioralnych.

Przykłady poradników dotyczących diagramów strukturalnych

DIAGRAMY KLAS

Diagramy klas przedstawiają statyczne struktury systemu, w tym jego klasy, atrybuty, operacje i obiekty. Diagram klas może przedstawiać dane obliczeniowe lub dane organizacyjne w postaci, odpowiednio, klas implementacyjnych i klas logicznych. Te dwie grupy mogą się pokrywać.

1. Klasy są reprezentowane przez prostokątny kształt, który jest podzielony na trzy części. Górna sekcja wyświetla nazwę klasy, a środkowa zawiera jej atrybuty. Dolna sekcja zawiera operacje klasy (znane też jako metody).
2. Dodaj kształty klas do diagramu klas, aby zamodelować relacje między tymi obiektami. Może się okazać, że trzeba będzie dodać także podklasy.
3. Użyj linii do reprezentowania asocjacji, dziedziczenia, mnogości i innych relacji między klasami i podklasami. Twój preferowany styl notacji będzie miał wpływ na zapis tych linii.

 

DIAGRAMY KOMPONENTÓW

Diagramy komponentów przedstawiają, w jaki sposób komponenty są łączone w większe komponenty lub systemy oprogramowania. Diagramy te służą do modelowania zależności pomiędzy poszczególnymi komponentami systemu. Komponent jest czymś wymaganym do wykonania funkcji stereotypu. Stereotyp komponentu może składać się z plików wykonywalnych, dokumentów, tabel baz danych, plików lub bibliotek.

1. Przedstaw komponent za pomocą kształtu prostokąta. Powinien mieć dwa małe prostokąty z boku lub mieć ikonę w tym kształcie.
2. Dodaj linie pomiędzy kształtami składowymi, aby przedstawić odpowiednie zależności.

 

DIAGRAMY WDRAŻANIA

Diagram wdrożenia modeluje fizyczne rozmieszczenie i strukturę komponentów sprzętowych. Diagramy wdrażania przedstawiają, gdzie i jak poszczególne elementy systemu będą ze sobą współpracować.

1. Rysując diagram wdrażania, używaj tej samej notacji, której używasz w przypadku diagramu komponentów.
2. Użyj kostki trójwymiarowej do modelowania węzła (który reprezentuje maszynę fizyczną lub wirtualną).
3. Oznacz węzeł etykietą w tym samym stylu, który jest używany w diagramach sekwencji. W razie potrzeby dodaj inne węzły, a następnie połącz je liniami.

 

Przykłady poradnika schematu behawioralnego

DIAGRAM AKTYWNOŚCI

Diagramy aktywności przedstawiają przepływ proceduralny kontroli pomiędzy obiektami klasy, a także procesy organizacyjne, takie jak procesy robocze w biznesie. Diagramy te są wykonane z określonych kształtów, a następnie połączone strzałkami. Zestaw notacji diagramów aktywności jest podobny do notacji diagramów stanów.

1. Zacznij tworzenie diagramu aktywności od pełnego koła.
2. Połącz koło z pierwszą aktywnością, która jest odwzorowana za pomocą prostokąta o zaokrąglonych brzegach.
3. Teraz połącz każdą czynność z innymi czynnościami za pomocą linii, która pokazuje stopniowy przebieg całego procesu.
4. Możesz też spróbować wykorzystać tory do przedstawienia obiektów, które wykonują poszczególne czynności.

 

DIAGRAM PRZYPADKÓW UŻYCIA

Przypadek użycia to lista kroków, które definiują interakcję między aktorem (człowiekiem, który wchodzi w interakcję z systemem lub systemem zewnętrznym) a samym systemem. Diagramy przypadków użycia przedstawiają specyfikację przypadku użycia i modelują jednostki funkcjonalne systemu. Diagramy te pomagają zespołom rozwojowym zrozumieć wymagania stawiane przez ich system, w tym rolę interakcji międzyludzkiej i różnice między różnymi przypadkami użycia. Diagram przypadków użycia może przedstawiać wszystkie przypadki użycia w systemie lub tylko jedną grupę przypadków użycia o podobnej funkcjonalności.

1. Aby rozpocząć tworzenie diagramu przypadków użycia, dodaj owalny kształt na środku rysunku.
2. W owalnym polu wpisz nazwę przypadku użycia.
3. Przedstaw aktorów za pomocą postaci w pobliżu diagramu, a następnie użyj linii do modelowania relacji między aktorami i przypadkami użycia.

 

DIAGRAM INTERAKCJI

Diagramy interakcji, znane też jako diagramy zdarzeń lub scenariusze zdarzeń, ilustrują, jak procesy oddziałują na siebie, pokazując połączenia między różnymi obiektami w sekwencji. Diagramy te mają dwa wymiary: pionowy i poziomy. Pionowe linie pokazują kolejność komunikatów i wywołań w porządku chronologicznym, a poziome elementy pokazują instancje obiektów, do których komunikaty są przekazywane.

1. Aby stworzyć diagram interakcji, wpisz nazwę instancji klasy i nazwę klasy w prostokątnym polu.
2. Narysuj linie pomiędzy instancjami klas, by odwzorować nadawcę i odbiorcę wiadomości.
3. Użyj litych grotów strzałek do symbolizowania wiadomości synchronicznych, otwartych grotów strzałek do wiadomości asynchronicznych, a linii przerywanych do wiadomości z odpowiedzią.

Już teraz możesz rozpocząć tworzenie diagramów UML w Lucidchart. Sprawiamy, że jest to proste, skuteczne, a nawet przyjemne.

• Łatwość użycia

  Jeśli tworzysz diagram UML, na pewno wiesz, jak to zrobić, jednak chcemy, by to zadanie było jak najłatwiejsze do wykonania. Zaoszczędzisz czas dzięki dopracowanemu interfejsowi Lucidchart i inteligentnemu edytorowi typu „przeciągnij i upuść”.

• Obszerna biblioteka kształtów

  Rysuj diagramy stanów, diagramy aktywności, diagramy przypadków użycia i inne. W obszernej bibliotece kształtów i łączników znajdziesz wszystko, czego potrzebujesz.

• Pełna integracja

  Lucidchart jest w pełni zintegrowany z Google Workspace. Kiedy zaczniesz korzystać z Lucidchart, znajdziesz nas w swoim pakiecie narzędzi Google, obok Gmaila i Dysku Google. Dodatkowo możesz używać tego samego loginu, którego używasz w Google.

• Możliwość współpracy

  Możesz łatwo udostępnić swój diagram UML współpracownikom, klientom lub szefowi. Twoje diagramy możesz osadzić na stronie internetowej lub opublikować jako PDF, a tryb prezentacji Lucidchart zamieni Twoje dzieło w świetnie wyglądające materiały wizualne.

• Importowanie/eksportowanie plików Visio

  Importowanie i eksportowanie plików programu Visio jest bardzo proste, dzięki czemu możesz zachować już wykonaną pracę. Cały proces przebiega szybko i bezproblemowo.