de_DEen_USes_ESfa_IRfr_FRhi_INid_IDjapl_PLpt_PT

Kompletny przewodnik po diagramach UML

Wprowadzenie

Język modelowania zintegrowanego (UML) stał się domyślnym standardem wizualizacji, specyfikacji i dokumentowania systemów oprogramowania w różnych gałęziach przemysłu. W jego centrum UML nie jest sztywną metodologią rozwoju, lecz elastycznym językiem wizualnym zaprojektowanym do mostu między abstrakcyjnymi wymaganiami a konkretną realizacją. UML 2.0 formalizuje tę funkcję, organizując typy diagramów w dwie uzupełniające się kategorie: diagramy strukturalne, które odzwierciedlają architekturę statyczną i relacje fizyczne systemu, oraz diagramy zachowaniowe, które modelują sposób działania komponentów, zmianę stanu i wykonywanie logiki w czasie. W oparciu o podstawowe zasady przedstawione w UML 2.0 w pigułce (O’Reilly), ten przewodnik zapewnia kompleksowy przegląd każdego głównego typu diagramu UML, jego podstawowych pojęć, zasad notacji oraz praktycznych zastosowań. Niezależnie od tego, czy projektujesz systemy zorientowane obiektowo, mapujesz topologie wdrażania, czy modelujesz złożone przepływy pracy biznesowej, zrozumienie, kiedy i jak stosować każdy diagram, pozwoli Ci wyrażać rozwiązania techniczne z jasnością, precyzją i wspólnym celem.

Przegląd

UML 2.0 organizuje diagramy na dwie główne kategorie:

Kategoria Cel
Diagramy strukturalne Zapisują fizyczną organizację elementów – jak obiekty wzajemnie się odnoszą
Diagramy zachowaniowe Skupiają się na tym, jak elementy oddziałują, zmieniają stan i przetwarzają zachowanie w czasie

💡 Kluczowa zasada: Model UML składa się z jednego lub więcej diagramów. Każdy diagram reprezentuje określoną widok lub zainteresowanie w systemie, który jest modelowany. Poszczególne elementy często pojawiają się na wielu diagramach.


🔷 Diagramy strukturalne

Diagramy strukturalne modelują architekturę statyczną Twojego systemu – „co”, a nie „jak”.

1. Diagramy klas

Cel: Klasy modelu, interfejsy oraz ich statyczne relacje.

Kluczowe elementy:

  • Klasy z atrybutami i operacjami

  • Interfejsy i relacje realizacji

  • Powiązania, agregacje, kompozycje i ogólne relacje

  • Modyfikatory widoczności (+-#~)

  • Specyfikacje wielokrotności (10..*1..5)

Przykład użycia:Kiedy stosować:

Stereotypy i typy klas

Diagram wykorzystuje stereotypy (oznaczone tekstem umieszczonym w nawiasach trójkątnych, takich jak <<encja>>) w celu sklasyfikowania roli każdej klasy:

  • Klasy graniczne (<<granica>>): Są one odpowiedzialne za interakcję między systemem a jego aktorami (użytkownikami lub zewnętrznymi systemami).

  • Przykłady: OknoKonsoli i OknoDialogowe.

  • Klasy sterujące (<<sterowanie>>): Zarządzają koordynacją, transakcjami oraz przepływem logiki biznesowej aplikacji.

  • Przykłady: KontekstRysowania i SterownikDanych.

  • Klasy encji (<<encja>>): Reprezentują dane główne lub stałe informacje, które system śledzi.

  • Przykłady: KlatkaOknoZdarzenieFiguraKołoProstokątWielokąt, i Punkt.

  • Klasa abstrakcyjna: Klasa Shape klasa reprezentuje pojęcie abstrakcyjne. Służy jako podstawowy szablon dla konkretnych kształtów i nie może być bezpośrednio instancjonowana.


Anatomia klasy

Standardowy prostokąt klasy UML jest podzielony na komórki. Rozważając przykład klasy Koło klasy jako przykład:

  • Nazwa klasy: Znajduje się w górnej komórce (Koło).

  • Atrybuty: Znajduje się w środkowej komórce, reprezentując pola danych.

  • -promień : float (Znak minus - wskazuje atrybut prywatny).

  • -środek : int bez znaku

  • Operacje (Metody): Znajduje się w dolnej komórce, reprezentując zachowania lub funkcje.

  • +area(w promieniu : float) : double (Znak plus + oznacza metodę publiczną).

  • +obwod()+ustawSrodek(), i +ustawPromien().


Związki i linki

Linie i strzałki łączące klasy określają sposób ich wzajemnego oddziaływania i zależności:

Generalizacja (dziedziczenie)

Zaznaczona linią ciągłą z pustym zakończeniem strzałki wskazującym na klasę nadrzędna. Oznacza to relację „jest rodzajem”, w której klasa potomna dziedziczy atrybuty i zachowania z klasy nadrzędnej.

  • Okno dziedziczy po Ramka.

  • OknoKonsoli i OknoDialogowe dziedziczy po Okno.

  • KołoProstokąt, i Wielokąt dziedziczyć po klasie abstrakcyjnej Figura (np. okrąg to Figura).

Agregacja

Zaznaczona linią ciągłą z pustym rombem na końcu kontenera. Oznacza to luźną relację „ma” lub całość-część, w której dziecko może istnieć niezależnie od rodzica.

  • Okno agreguje Figura (mnożność 1 do *). Okno może zawierać wiele (*) figur, ale jeśli okno zostanie zamknięte, same figury mogą nadal istnieć koncepcyjnie w pamięci lub w innym kontekście.

Kompozycja

Zaznaczona linią ciągłą z wypełnionym (czarnym) rombem na końcu kontenera. Wskazuje to na silną relację „ma” z zgodnym czasem życia — jeśli kontener zostanie usunięty, części również zostaną usunięte.

  • Okrąg składa się z Punkt obiektów (mnożność 1 do *). Okrąg nie może istnieć bez swojego środka ani punktów brzegowych; zniszczenie okręgu niszczy te konkretne odniesienia do punktów.

Zależność

Zaznaczony jako przerywana strzałka. Pokazuje, że jedna klasa zależy od innej, co oznacza, że zmiana w klasie docelowej może wpłynąć na klasę źródłową.

  • Okno ma zależność od Zdarzenie (wskazane przez przerywaną strzałkę wskazującą na Zdarzenie). Okno opiera się na wyzwalaczy zdarzeń, aby wykonywać operacje takie jak handleEvent().

Powiązanie

Zaznaczane prostą linią ciągłą. Wskazuje relację strukturalną, w której obiekty jednej klasy są połączone z obiektami innej klasy.

  • Okno dialogowe jest powiązane z Kontroler danych, co oznacza, że komunikują się ze sobą w celu przekazywania informacji lub koordynowania zachowania.


Elementy dokumentacji

  • Uwaga: Diagram zawiera pole notatki z zagiętym rogiem połączone linią przerywaną z klasą Okno klasy. Daje czytelny dla człowieka kontekst: „Główne okno aplikacji.”

What is Class Diagram?

  • Projektowanie architektury oprogramowania zorientowanego obiektowo

  • Dokumentowanie modeli domenowych

  • Generowanie szkieletów kodu


2. Diagramy składników

Cel: Pokazuje organizację i zależności jednostek implementacji.

Kluczowe elementy:

  • Składniki (stereotypowane jako «składnik»)

  • Dostarczane/ wymagane interfejsy (notacja kulka i gniazdo)

  • Połączenia montażowe i relacje zależności

  • Artefakty (skompilowane wyjścia: JAR, DLL, pliki wykonywalne)

Przykład zastosowania:Kiedy stosować:

Składniki i granice modułowe

W centrum diagramu znajduje się pojęcie składnika – samodzielnej i modułowej jednostki systemu, która hermetyzuje swoje zawartości i ujawnia swoje zachowanie poprzez wyraźne interfejsy. Duża zewnętrzna granica reprezentuje ogólne Terminal składnik, który działa jako podsystem lub kontener. Wewnątrz tego kontenera znajdują się mniejsze, specjalizowane wewnętrzne składniki – mianowicie InspekcjaBezpieczności, Personel, Wadliwy, oraz Mapa. Każdy z tych wewnętrznych jednostek reprezentuje modułowy fragment oprogramowania lub logiki zarządzania danymi działającej razem w celu spełnienia obowiązków Terminala.

Interfejsy jako umowy

Składniki nie ujawniają bezpośrednio swojej logiki wewnętrznej; zamiast tego komunikują się poprzez dokładnie zdefiniowane interfejsy, które pełnią rolę umów architektonicznych.

  • Dostarczane interfejsy:Oznaczane symbolem „lollipop” lub okręgiem, oznaczają usługi, dane lub operacje, które składnik realizuje i oferuje środowisku. Na przykład zewnętrzny składnik Terminal udostępnia zewnętrzne dostarczane interfejsy takie jakStan, Szczegóły, oraz Element inspekcji, wskazując, co zewnętrzni klienci mogą żądać od niego.

  • Wymagane interfejsy:Oznaczane symbolem „gniazdo” lub półokręgiem, określają usługi lub dane, które składnik wymaga od innej jednostki, aby poprawnie działać. Po prawej stronie diagramu składnik Terminal jawnie udostępnia wymagane interfejsy dlaKonto oraz Identyfikator inspekcji, pokazując jego zależności od zewnętrznych podsystemów.

Porty i wewnętrzne połączenia

Aby zarządzać przepływem danych i sterowania, zachowując przy tym hermetyzację, system wykorzystuje porty i relacje delegowania.

  • Porty:Małe kwadraty znajdujące się na brzegu składników oznaczają porty. Są one oddzielnymi punktami interakcji, przez które struktura wewnętrzna składnika łączy się z zewnętrznym światem. Porty pozwalają na izolację wewnętrznych połączeń składnika od środowiska zewnętrznego, co oznacza, że składniki wewnętrzne mogą być zastępowane lub modyfikowane bez zmiany sposobu, w jaki składnik nadrzędny wydaje się zewnętrznemu światu.

  • Delegowanie i montaż:Wewnątrz składnika Terminal linie łączą te interfejsy, tworząc strukturalny montaż. Interfejs dostarczany na zewnętrznym porcie deleguje przychodzące żądania bezpośrednio do dostarczanego interfejsu składnika wewnętrznego (jak widać na ścieżkach Stan oraz Szczegóły prowadzących do Inspekcji bezpieczeństwa). Z kolei składniki wewnętrzne podłączają swoje wymagane interfejsy gniazda bezpośrednio do dostarczanych interfejsów „lollipop” sąsiednich składników. Na przykład składnikInspekcji bezpieczeństwa opiera się na interfejsieInspektora dostarczanym przezPersonel, ten Szczegóły wad interfejs zapewniony przez Wada, oraz Lokalizacja interfejs zapewniony przez Mapa, tworząc dobrze skoordynowany, ale luźno powiązany wewnętrzny ekosystem.

What is Component Diagram?

  • Planowanie architektury systemu modułowego

  • Zarządzanie zależnościami kompilacji

  • Dokumentowanie bibliotek składników ponownie używanych


3. Diagramy struktury złożonej(Dodane w UML 2.0)

Kluczowe elementy:

  • Części (właściwości z relacjami całość-część)

  • Porty (punkty interakcji z dostarczonymi/ wymaganymi interfejsami)

  • Połączenia (łącza czasu działania między częściami)

  • Wystąpienia współpracy

Przykład zastosowania: Modelowanie Samochodu:

Klasa zawierająca (Klasa)

Zewnętrzny prostokąt reprezentuje klasę zawierającą, w tym przypadku klasę Samochodu klasa. W diagramie struktury złożonej ta granica działa jako kontener, który zawiera konfigurację czasu działania systemu. Określa kontekst, w którym pojedyncze instancje współpracują w celu osiągnięcia szerszego celu behawioralnego, ukrywając złożoność działania „Samochodu” wewnętrznie przed jednostkami zewnętrznymi.

Części (struktura wewnętrzna)

Wewnętrzne prostokąty w granicach pojazdu Car oznaczają Części. Część wyjaśnia rolę, którą pełni zbiór wystąpień podczas wykonywania zawierającego klasyfikatora. Zamiast pokazywać statyczne, czasu kompilacji relacje (jak typowy diagram klas), te części oznaczają wystąpienia czasu działania wypełniające określone miejsca architektoniczne:

  • -t : Przekładnia: Wystąpienie pełniące rolę układu przekładniowego.

  • -e : Silnik: Wystąpienie pełniące rolę źródła mocy silnika.

  • -s : Układ kierowniczy: Wystąpienie pełniące rolę mechanizmu kierowniczych.

Notacja z dwukropkiem wskazuje, że są to role strukturalne typowane przez odpowiednie klasy, definiujące dokładnie, jakie komponenty muszą istnieć w działającym aucie.

Porty i granice

Małe kwadraty zagnieżdżone zarówno na zewnętrznej granicy klasyfikatora, jak i na granicach wewnętrznych części oznaczają Porty. Porty to odrębne punkty interakcji, które odłączają strukturę wewnętrzną klasyfikatora od jego otoczenia zewnętrznego.

  • Zewnętrzne porty na granicy pojazdu Car – takie jak : Koło, : Pedal gazu, oraz : Kierownica– ujawniają sposób, w jaki samochód oddziałuje na świat zewnętrzny lub środowisko fizyczne, nie ujawniając przy tym którewewnętrzne części obsługują te interakcje.

  • Porty na częściach wewnętrznych (takie jak porty na blokach Przekładni lub Silnika) regulują sposób, w jaki te podsystemy komunikują się ze sobą lub z granicą nadrzędnej.

Połączenia i wewnętrzne przewody

Pełne linie łączące porty ze sobą oznaczają Połączenia. Połączenia definiują ścieżki komunikacji między częściami lub między częścią a zewnętrznym portem w czasie działania.

  • Połączenia delegowania: Łączą zewnętrzny port kontenera bezpośrednio z wewnętrznym portem części. Na przykład zewnętrzny : Koło port przekazuje bezpośrednio do Skrzynią biegów, a zewnętrzny : Kierownica przekazuje bezpośrednio do System kierowniczy. Zapewnia to, że zewnętrzne bodźce są bezproblemowo przekazywane odpowiedniemu wewnętrznemu odbiorcy.

  • Połączenia zespołów: Łączy ze sobą części wewnętrzne, aby umożliwić współpracę. Połączenie między Skrzynią biegów a Silnikiem pokazuje, że te dwa różne role czasu działania bezpośrednio wymieniają sygnały, dane lub siłę mechaniczną, aby samochód działał jako jedność.

Kiedy stosować:

  • Dokumentowanie wzorców projektowych

  • Modelowanie złożonych wewnętrznych współpracy

  • Łączenie projektowania klas i implementacji składników


4. Diagramy wdrażania

Cel: Mapuje artefakty oprogramowania na środowiska wykonawcze sprzętowe.

Kluczowe elementy:

  • Węzły (urządzenia, środowiska wykonawcze)

  • Artefakty (jednostki wdrażalne)

  • Ścieżki komunikacji między węzłami

  • Specyfikacje wdrażania (szczegóły konfiguracji)

Przykład zastosowania:Kiedy stosować:

Węzły i infrastruktura fizyczna

W przeciwieństwie do diagramów projektowania logicznego, które modelują układ kodu lub struktury klas, diagram wdrażania skupia się na topologii sprzętu. Głównymi elementami budowlanymi sąWęzły, które wizualnie przedstawia się jako sześciany trójwymiarowe. Węzły ilustrują zasoby obliczeniowe fizyczne lub środowiska wykonawcze, w których faktycznie działają elementy oprogramowania:

  • <<procesor>> Węzły: Sześciany o stereotypie<<procesor>> (takie jakSerwer buforujący, Serwer główny, oraz ogólnySerwer bloki) reprezentują węzły o zdolności obliczeniowej, pamięci i mocy przetwarzania umożliwiających uruchamianie plików binarnych oprogramowania.

  • <<sieć>> Węzły: Sześcian wydłużony oznaczony jakoSieć lokalna reprezentuje ścieżkę komunikacyjną lub infrastrukturę routingu, a nie pojedynczy komputer. Oznacza fizyczny szkielet umożliwiający wymianę strumieni pakietów danych między połączonymi procesorami.

  • Węzły urządzeń:Nieokreślone węzły takie jakInternet iBank modemów reprezentują komponenty sprzętowe graniczne lub zewnętrzne infrastruktury fizyczne wymagane do kierowania ruchu zewnętrznego do środowiska systemu głównego.

Związki i ścieżki komunikacyjne

Pełne linie łączące sześciany trójwymiarowe reprezentująPołączenia. Na diagramie wdrożenia te połączenia wyznaczają fizyczne ścieżki komunikacji, połączenia sieciowe lub połączenia sprzętowe między węzłami.

  • Linia pomiędzy Internet i Bank modemówilustruje punkt wejścia danych publicznych zewnętrznych do stosu sprzętowego.

  • Połączenie rozciągające się od Bank modemów w dół do Serwer buforowaniawyznacza fizyczne routowanie przychodzącego ruchu w kierunku warstwy buforowania krawędziowej.

  • Połączenia łączące Serwery buforowania i leżący poniżej Serwerem głównym klastra z Sieć lokalnąustalają sposób komunikacji między wewnętrznymi składnikami poprzez współdzieloną wysokoprzepustową magistralę lokalną lub infrastrukturę przełącznika sieciowego.

Warstwowanie topologiczne i nadmiarowość

Układ węzłów na diagramie jasno pokazuje topologię wdrożenia oraz wybrane rozwiązania architektoniczne zapewniające wysoką dostępność i dystrybucję obciążenia.

  • Warstwa buforowania krawędziowego: Umieszczone bezpośrednio poniżej sprzętu modemów punktu wejściowego znajdują się dwa różne, równoległe Serwer buforowaniawęzły. Ta konfiguracja wizualnie demonstruje nadmiarową warstwę krawędziową zaprojektowaną do rozkładania obciążenia przychodzącego ruchu i buforowania zasobów przed zapytaniami dotarłymi do głębokiej infrastruktury.

  • Farma serwerów wewnętrznych: Umieszczone na dole stosu, połączone poprzez Sieć lokalną, jest klastrzem serwerów głównych. Różnica między Serwerem głównym oraz sąsiedni ogólny Serwer węzły wizualnie przedstawiają układ architektury master-replica lub primary-secondary, zapewniając trwałość danych i bezpieczne koordynowanie ciężkich obciążeń obliczeniowych w środowisku wewnętrznego centrum danych.

What is Deployment Diagram?

Cel: Modeluje wewnętrzną strukturę klasyfikatorów i złożonych wzorców.

  • Planowanie infrastruktury systemu

  • Dokumentowanie architektur rozproszonych

  • Określanie strategii przejścia awaryjnego i nadmiarowości


5. Diagramy pakietów

Cel: Organizuje i zarządza przestrzeniami nazw poprzez grupowanie logiczne.

Kluczowe elementy:

  • Pakiety (prostokąty z kartkami)

  • Związki importu/dostępu («import»«dostęp»)

  • Związki scalania («scalanie»)

  • Widoczność (+ publiczny, - prywatny)

Przykład zastosowania:

Granice podsystemu i pakietu

Diagram opiera się w dużym stopniu na oznaczeniu „folderu”, aby przedstawić logiczne grupowania elementów projektowych.

  • Podsystem: Duży zewnętrzny folder oznaczony jako <<podsystem>> Zamówienia reprezentuje główną, hermetyczną jednostkę zachowania systemu fizycznego. Wykonuje funkcję kontenera najwyższego poziomu, który grupuje powiązane komponenty i pakiety wymagane do obsługi zarządzania zamówieniami.

  • Pakiet: Mniejsze foldery wewnątrz i na zewnątrz podsystemu (takie jak UI, Przetwarzanie zamówień, oraz GUIManager) to standardowe pakiety. Są one używane do organizowania elementów w zarządzalne grupy, tworzenia przestrzeni nazw oraz definiowania granic widoczności w architekturze.

Zależności i warstwowanie

Strzałki z myślnikiem wskazują na Zależności, co oznacza, że zmiana w jednym pakiecie (celu) może wpłynąć na działanie pakietu źródłowego (źródła).

  • Wewnętrzne zależności: Wewnątrz podsystemu Zamówienia widoczne jest jasne warstwowanie architektoniczne od góry do dołu. Pakiet UI zależy od Przetwarzanie zamówień, które z kolei zależy od Kalkulator cen oraz Zewnętrzne przechowywanie. Reprezentuje to przepływ architektoniczny, w którym elementy prezentacji najwyższego poziomu opierają się na kluczowych warstwach logiki biznesowej i dostępu do danych.

  • Zależność od zewnętrznego pakietu: Pakiety mogą również zależeć od elementów poza ich bezpośrednim granicą podsystemu. Na przykład pakiet UI pakiet ma zależność od zewnętrznego GUIManager. Podobnie, pakiet Random Storage i Stream Storage pakietów na dole przekracza granicę podsystemu, aby zależeć od zewnętrznych struktur danych, co pokazuje, jak podsystem integruje się w większym ekosystemie oprogramowania.

Abstrakcja i dziedziczenie (generalizacja)

Diagram używa specjalnego stylu i strzałek relacji, aby pokazać abstrakcyjne wzorce projektowe stosowane do architektury modułowej.

  • Pakiety abstrakcyjne wobec pakietów konkretnych: Pakiety zawierające elementy abstrakcyjne lub definiujące strukturę podobną do interfejsu są oznaczane kursywą (takie jak External Storage i StorageManagement). Z kolei pakiety zawierające implementacje kodu operacyjnego, takie jak Repository i FileStorage, używają zwykłego tekstu, aby oznaczyć, że są to konkretne pakiety.

  • Generalizacja: Reprezentowane jest linią pełną z otwartym, pustym trójkątem wskazującym na pakiet nadrzędny. Oznacza to relację dziedziczenia lub implementacji. Wewnątrz podsystemu Random Storage i Stream Storage specjalizują lub implementują abstrakcyjny interfejs External Storage interfejsu. Poza podsystemem konkretne Repository i FileStorage pakiety uogólniają się w kierunku abstrakcji ZarządzaniePamięcią pakiet, pokazujący, jak zachowanie polimorficzne i klasyfikacja strukturalna mogą być modelowane na poziomie pakietu.

    What is Package Diagram?

  • Kiedy stosować:

  • Zarządzanie dużymi bazami kodu

  • Definiowanie granic modułów

  • Kontrolowanie zależności kompilacji


6. Diagramy obiektów

Cel: Pokazują zrzuty stanu instancji i ich połączeń w konkretnym momencie.

Kluczowe elementy:

  • Obiekty (nazwy podkreślone: mojeAuto:Auto)

  • Połączenia między instancjami obiektów

  • Wartości atrybutów w czasie działania

Przykład zastosowania:

Obiekty i konkretne instancje

W przeciwieństwie do diagramów klas, które pokazują abstrakcyjne, poziomowe konfiguracje szablonu, diagram obiektów zapisuje rzeczywiste instancje znajdujące się w pamięci. Obiekty są przedstawiane jako prostokąty, a ich nazwy zawsze są podkreślone, aby oznaczyć instancjonowanie.

  • Obiekty o nazwie: Posiadają następującą składnię nazwaInstancji : NazwaKlasy. Na przykład, c : Firma reprezentuje konkretną instancję firmy o nazwie „c”, a p : Osoba reprezentuje konkretną instancję osoby o nazwie „p”.

  • Obiekty anonimowe: Gdy identyfikator konkretnego wystąpienia jest pominięty lub nieistotny dla scenariusza, podawana jest tylko nazwa klasy, poprzedzona dwukropkiem (np. : Informacje kontaktowe). Oznacza to, że istnieje konkretny egzemplarz informacji kontaktowych, który jest przypięty do struktury, ale nie wymaga unikalnej nazwy zmiennej w tym kontekście.

Stan i wartości atrybutów

Dolna komórka prostokąta obiektu zawiera jego określony stan, definiowany przez jawne wartości przypisane do jego atrybutów w danym momencie. Zamiast tylko wymieniać typy danych, te wpisy używają formatu przypisania atrybut = wartość przypisania, aby odzwierciedlić rzeczywistość:

  • Egzemplarz instancji działu d1 przechowuje wartość atrybutu name = Sprzedaż.

  • Inny odrębny egzemplarz instancji działu d2 przechowuje wartość name = O&D.

  • Egzemplarz instancji osoby p przechowuje całą grupę danych stanu, wyznaczając konkretny profil: name = Derek, employeeID = D-12821, oraz title = Menadżer.

Linki i relacje

Pełne linie łączące obiekty reprezentują Linki. Linka to konkretny przykład związku zdefiniowanego między klasami. Jeśli diagram klas mówi, że Firmy mają Działy, to diagram obiektów pokazuje rzeczywiste połączenia w czasie działania.

  • Instancja firmy c jest aktywnie połączona z instancjami działów d1 (Sprzedaż) i d2 (Badania i rozwój).

  • Diagram również przedstawia hierarchiczne połączenia instancji, gdzie d1 : Dział (Sprzedaż) łączy się z instancją poddziału również typu Dział (nazwa = Amerykańska Sprzedaż).

  • Na końcu instancja osoby p (Derek) jest połączona z instancją działu Amerykańska Sprzedaż, jednocześnie utrzymując połączenie z anonimową instancją : Informacje kontaktowe zawierającą jego adres fizyczny.

Kiedy stosować:

  • Weryfikowanie projektów diagramów klas

  • Debugowanie złożonych relacji obiektów

  • Pokazywanie przykładów stanów czasu działania


🔶 Diagramy zachowania

Diagramy zachowania modelują aspekty dynamiczne – jak system zachowuje się w czasie.

7. Diagramy aktywności

Cel: Modelowanie przepływów pracy, procesów biznesowych i logiki algorytmicznej.

Kluczowe elementy:

  • Akcje (okręgi z zaokrąglonymi rogami)

  • Węzły sterujące: początkowy, decyzyjny, scalający, rozgałęziający, łączący, końcowy

  • Węzły obiektów i złącza

  • Podziały (korytarze) do przypisania odpowiedzialności

  • Obsługa wyjątków i przerwalne obszary

Przykładowe zastosowanie: Przepływ pracy przetwarzania zamówienia

Organizacja strukturalna (korytarze i podziały)

Diagram jest uporządkowany pionowo w duże kolumny znane zamiennie jakoKorytarze lub Podziały. Te granice kategoryzują odpowiedzialności za działania zawarte w nich, przypisując kroki do określonych ról lub jednostek biznesowych:

  • Interfejs sprzedaży klienta:Należy do cyklu życia skierowanego do klienta, obsługuje inicjalizację klienta, alternatywne routowanie i ostateczne przedstawienie.

  • Właściciel propozycji:Zarządza podstawowym planowaniem, analizą operacyjną oraz kompilacją struktur danych formalnej propozycji.

  • Właściciel oferty:Skupia się wyłącznie na ocenie finansowej i przygotowaniu konkretnych metryk oferty.

Przepływ sterowania i stany akcji

Wykonywanie krok po kroku jest kierowane przez węzły sterujące i skierowane ścieżki.

  • Węzeł początkowy:Zaznaczony jako pełny czarny okrąg na górze, wskazuje punkt początkowy całego przepływu działania.

  • Akcja: Okręgi z zaokrąglonymi rogami (np. Zainicjuj kontakt, Wyszukaj alternatywę, oraz Zbierz dodatkowe informacje) oznaczają pojedyncze, niedzielone kroki lub zadania w ciągu wykonywania.

  • Przepływ sterowania: Pełne strzałki łączące elementy określają sekwencyjny przebieg przepływu pracy, wskazując dokładnie, które działanie musi zostać zakończone przed rozpoczęciem następnego.

  • Węzeł końcowy działania: Symbol tarczy (pełny okrąg w pustym pierścieniu) na dole oznacza absolutny punkt zakończenia całego wykonania procesu.

Kierowanie i logika zabezpieczona (węzły decyzyjne)

Symbole w kształcie diamentu oznaczająWęzły decyzyjne, które modelują warunkowe rozgałęzienie w przepływie pracy.

  • Przychodzące ścieżki sterowania są dzielone na wiele wzajemnie wykluczających się wyjściowych ścieżek na podstawie określonych danych wejściowych.

  • Warunki, które decydują, którą ścieżkę wybrać, są umieszczone w kwadratowych nawiasach, znanych jako warunki zabezpieczające (takie jak[zaakceptowane], [odrzucone], oraz[połączenie z innym dostawcą lub zmiana wymagań]). Proces ocenia te warunki w czasie rzeczywistym, aby skierować wykonanie w odpowiednią ścieżkę funkcjonalną.

Przetwarzanie równoległe (węzły Fork i Join)

Pełne czarne paski na schemacie działają jako punkty synchronizacji do zarządzania równoległymi lub jednoczesnymi strumieniami wykonania.

  • Węzeł Fork (oznaczony jako Węzeł przepływu w wskaźniku schematu): Jedna przychodząca ścieżka sterowania wchodzi do paska i dzieli się na wiele niezależnych, równoległych wątków wykonania. Tutaj, po utworzeniu planu projektu, proces rozgałęzia się, umożliwiając Właścicielowi propozycji wykonanie analizy i planowania dostawy, podczas gdy Właściciel oferty jednocześnie zajmuje się przygotowaniem oferty.

  • Węzeł Join: Pasek synchronizacji, który łączy wiele równoległych ścieżek z powrotem w jedną ścieżkę sterowania. Proces nie może przejść dalej po węźle Join, dopókiwszystkie przychodzące równoległe strumienie nie zostały pomyślnie osiągnięte przez pasek, zapewniając, że kompilacja oferty i sporządzanie propozycji zostały w pełni zakończone przed przejściem do kompilacji ostatecznego pakietu.

Integracja danych (węzły obiektów)

Standardowe prostokąty oznaczająWęzły obiektów, które wprowadzają przepływ danych do schematu działania skierowanego na sterowanie.

  • Węzły obiektów reprezentują instancje określonych danych lub artefaktów fizycznych produkowanych lub zużywanych przez działania, używającnazwaInstancji : Klasa konwencja (np. propozycja : Propozycja i plan : Plan projektu dostawy).

  • Jawnie oznaczone utwórz strzałki dokładnie pokazują, kiedy działanie tworzy lub aktualizuje strukturę danych, demonstrując przepływ danych od zadania do zadania wraz z wykonywaniem operacji.

Activity Diagram, UML Diagrams Example: Relationships between Activates and Business Entities - Visual Paradigm Community Circle

Kiedy stosować:

  • Dokumentowanie procesów biznesowych

  • Modelowanie realizacji przypadków użycia

  • Określanie złożonych algorytmów


8. Diagramy maszyn stanów (Statecharts)

Cel: Modelowanie cyklu życia i zachowania zależnego od stanu obiektów.

Kluczowe elementy:

  • Stany (okręgi z aktywnościami wejścia/wyjścia/realizacji)

  • Przejścia (wyzwalacz[warunek]/efekt)

  • Pseudostany: początkowy, wybór, rozgałęzienie, połączenie, historia, zakończenie

  • Stany złożone i ortogonalne obszary

Przykładowe zastosowanie: konfiguracja telefoniczna

Stany i warunki systemu

Diagram uchwytyje zachowanie systemu – konkretnie konfigurację telefoniczną – poprzez odwzorowanie jego różnych dyskretnych sytuacji lub stanów.

  • Stany: Okręgi reprezentują stany (np. Nieaktywny, Dzwonienie, Dzwonienie, Łączenie, i Połączony). Stan reprezentuje okres w cyklu życia obiektu, w którym spełnia pewne warunki, wykonuje działanie lub oczekuje na zdarzenie.

  • Początkowy stan pseudoczynny: Pełny czarny okrąg po lewej stronie reprezentuje punkt początkowy maszyny stanów. Jest to stan pseudoczynny, a nie prawdziwy stan, pełniący jedynie rolę wskaźnika stanu aktywnego domyślnego w momencie inicjalizacji obiektu (Nieaktywny).

  • Stan końcowy: Symbol tarczy po prawej stronie reprezentuje zakończenie działania maszyny stanów, wskazując, że obiekt ukończył swój cykl życia.

Przejścia i kierowanie oparte na zdarzeniach

Kierowane linie łączące stany toPrzejścia, które reprezentują przemieszczenie z jednego stanu do drugiego jako odpowiedź na określony wyzwalacz.

  • Standardowe przejścia: Wyzwalane przez konkretne zdarzenia, takie jak działanie użytkownika lub odpowiedź systemu, zaznaczone na liniach. Na przykład przemieszczanie się zNieaktywny do Dzwonienie następuje, gdy zdarzenieonHook zostanie wyzwolone, a przemieszczanie się zDzwonienie do Dzwonienie występuje, gdy cyfra(n) zdarzenie zostaje odebrane.

  • Przejścia samodzielne: Strzałka przejścia, która wychodzi z stanu i natychmiast wraca do tego samego stanu (jak widać na stanieWybieranie z wyzwalaczemcyfra(n) trigger). Oznacza to, że zdarzenie jest przetwarzane i aktualizuje kontekst wewnętrznego stanu (np. zapisanie nowo wybranego cyfry), nie powodując wyjścia obiektu z tego stanu ani zmiany jego ogólnego stanu działania.

Alternatywne ścieżki i obsługa błędów

Maszyny stanów wyróżniają się pokazywaniem logiki zachowania i rozgałęzienia błędów w oparciu o zmieniające się warunki podczas wykonywania.

  • Ścieżka pomyślnego wykonania: Pozioma centralna ścieżka pokazuje optymalną trasę:Nieaktywny $rightarrow$ Ton wybierania $rightarrow$ Wybieranie $rightarrow$ Łączenie $rightarrow$ Dzwoni $rightarrow$ Połączony $rightarrow$ Rozłączony.

  • Stany obsługi wyjątków i błędów: System uwzględnia niepowodzenia lub opóźnienia poprzez rozgałęzienie do dedykowanych stanów obsługi. Jeśli numer jest zajęty podczas łączenia, system wyzwala stannumerZajęty przejście do wejścia w Dzwonienie zajęte stan. Jeśli użytkownik zatrzyma się zbyt długo podczas wybierania, wystąpi przekroczenie limitu czasu zdarzenie przesuwa system do stanu Ostrzeżenie lub Przekroczenie limitu czasu stan. Jeśli zostanie wykryta niepoprawna sekwencja, wystąpi nieprawidłowyNumer wyzwalacz przekierowuje system do stanu Zapisana wiadomość stanu, zapewniając, że system bezpiecznie obsługuje wszystkie przypadki z rzeczywistego świata.

State Diagram - A Quick Tutorial - Visual Paradigm Blog

 

Kiedy stosować:

  • Modelowanie systemów wbudowanych lub implementacji protokołów

  • Określanie zarządzania stanem interfejsu użytkownika

  • Dokumentowanie reguł cyklu życia obiektu


9. Diagramy interakcji

Cztery typy diagramów podkreślają różne aspekty współpracy obiektów:

a) Diagramy sekwencji (Najczęściej używany)

Cel: Pokazuje uporządkowane w czasie wymiany komunikatów między liniami życia.

Kluczowe elementy:

  • Linie życia (pionowe linie przerywane)

  • Komunikaty (strzałki pełne/przerywane z etykietami)

  • Wystąpienia wykonania (paski aktywacji)

  • Fragmenty połączone: altoptpetlaparprzerwanie

Przykładowe użycie:

Linie życia i konteksty wykonania

Diagram czyta się od lewej do prawej, aby ustalić uczestników, a od góry do dołu, aby oznaczyć upływ czasu.

  • Linie życia: Prostokąty na górze przyłączone do przerywanych pionowych linii reprezentują linie życia. Modelują pojedynczych uczestników interakcji, stosując konwencjęnazwaInstancji : NazwaKlasy (np. okno : UI, aChain : HotelChain, oraz aHotel : Hotel). Przerywana linia śledzi istnienie tego uczestnika przez całą sekwencję.

  • Paski aktywacji: Cienkie, kolorowe pionowe prostokąty spoczywające na liniach życia wskazują na aktywację (lub wystąpienie wykonania). Te paski dokładnie pokazują, kiedy obiekt aktywnie wykonuje operację lub oczekuje na zwrócenie zagnieżdżonego wywołania podprocedury.

  • Zatrzymano: Duży symbol „X” na dole okno : UI linia życia wskazuje na zniszczenie lub zakończenie, co oznacza, że cykl życia tego konkretnego uczestnika się zakończył i jego zasoby zostały zwolnione.

Typy wiadomości i komunikacja

Komunikacja między uczestnikami jest modelowana za pomocą poziomych strzałek reprezentujących wiadomości, uporządkowanych sekwencyjnie przy użyciu systemu numeracji hierarchicznej (np. 1, 1.1, 1.1.1).

  • Wiadomości synchroniczne: Pełne linie z pełnymi zakończeniami strzałek (np. 1: makeReservation i 1.1: makeReservation) wskazują na wywołania synchroniczne. Nadawca blokuje wykonanie i czeka, aż obiekt odbierający zakończy przetwarzanie.

  • Wiadomości samodzielne: Pętla wiadomości, która zaczyna się i kończy na tym samym pasku aktywacji (np. 1.1.1: available(roomId, date): isRoom wykonana przez aHotel) reprezentuje wiadomość samodzielna. Oznacza to wykonanie metody wewnętrznej, podczas której obiekt wywołuje jedną z własnych operacji.

  • Wiadomości tworzenia: Linia przerywana z otwartym zakończeniem strzałki wskazującym bezpośrednio na pole obiektu (np. wiadomość 1.1.2: wskazująca na aReservation : Reservation) reprezentuje tworzenie obiektu. Oznacza to, że instancja aHotel dynamicznie tworzy w tym momencie w czasie działania obiekt aReservation w dokładnie tym momencie w sekwencji działania.

Fragmenty połączone i przepływ sterowania

Duże prostokątne pola otaczające fragmenty sekwencji to fragmenty połączone, które używają operatorów interakcji do zarządzania złożoną logiką, rozgałęzieniami i iteracją.

  • Fragment pętli: Zewnętrzny prostokąt oznaczony jako pętla z warunkiem strażniczym [każdy dzień] reprezentuje iterację. Wszystkie interakcje zawarte w tym prostokącie będą powtarzane ciągle dla każdego dnia określonego w żądaniu rezerwacji.

  • Fragment alternatywny (Alt): Zagnieżdżony w pętli znajduje się fragment alt (oznaczony jako „Jeśli” w wskaźniku diagramu), który obsługuje rozgałęzienie warunkowe. Ocenia warunek strażniczy [isRoom = true]. Jeśli warunek jest spełniony, sekwencja wykonuje określoną ścieżkę wewnątrz tego bloku — tworząc instancję aReservation i następnie wywołując wiadomość 2: w celu utworzenia instancji aNotice : Potwierdzenie. Jeśli warunek byłby fałszywy, wykonywana byłaby alternatywna ścieżka (lub nie byłoby żadnej akcji).

b) Diagramy komunikacji

Cel: Podkreślają relacje między obiektami, a nie czas wysyłania wiadomości.

What is Communication Diagram?

Kluczowe elementy:

  • Obiekty jako węzły

  • Połączenia z ponumerowanymi, skierowanymi komunikatami

  • Skupienie się na „kto rozmawia z kim”

c) Diagramy przeglądowe interakcji

Cel: Ogólny przebieg sterowania z wykorzystaniem notacji diagramu aktywności.

Interaction Overview Diagram Example

Kluczowe elementy:

  • Wystąpienia interakcji jako węzły działania

  • Decyzja/łączenie dla rozgałęzienia

  • Rozgałęzienie/łączenie dla równoległości

d) Diagramy czasu

Cel: Modelowanie dokładnych ograniczeń czasowych (systemy czasu rzeczywistego).

What is Timing Diagram?

Kluczowe elementy:

  • Wykresy stanów dla każdej linii życia

  • Skale czasu i ograniczenia

  • Strzałki komunikatów z oznaczeniami czasu trwania

Kiedy używać interakcji:

  • Określanie realizacji przypadków użycia

  • Debugowanie złożonych przepływów komunikatów

  • Dokumentowanie wzorców używania interfejsów API

  • Modelowanie czasu działania protokołów czasu rzeczywistego


10. Diagramy przypadków użycia

Cel: Zbieranie wymagań funkcjonalnych z perspektywy zewnętrznego aktora.

Kluczowe elementy:

  • Przypadki użycia (elipsy lub prostokąty klasyfikatorów)

  • Aktory (postacie z drutu lub klasyfikatory)

  • Powiązania (aktor ↔ przypadek użycia)

  • Związki: «include»«rozszerz», uogólnienie

  • Pole graniczne systemu

Przykładowe zastosowanie: System bankomatowy

A Comprehensive Guide to Use Case Modeling - Visual Paradigm Guides

Kiedy stosować:

  • Wyciąganie wymagań od stakeholderów

  • Określanie zakresu i granic systemu

  • Planowanie scenariuszy testowych


🎯 Wybieranie odpowiedniego diagramu: przewodnik decyzyjny

Cel Zalecane diagram(y)
Projektowanie struktury klas Klasa, Obiekt, Pakiet
Modelowanie interakcji w czasie działania Sekwencja, Komunikacja
Dokumentowanie przepływów biznesowych Działanie, Przypadek użycia
Określanie cyklu życia obiektu Maszyna stanów
Planowanie wdrożenia systemu Wdrożenie, Komponent
Modelowanie skomplikowanych wzorców wewnętrznych Struktura złożona
Zapisywanie ograniczeń czasu rzeczywistego Diagram czasowy
Definiowanie wymagań Przypadek użycia, Działanie

🔑 Kluczowe zasady modelowania

  1. Zacznij od prostego: Zaczynaj od typu diagramu, który najlepiej odpowiada Twojemu obecnemu celowi.

  2. Iteruj: Doskonal modele wraz z pogłębianiem zrozumienia — żaden diagram nie jest „ostateczny” w pierwszym szkicu.

  3. Kluczowe jest docelowe odbiorcze: Dopasuj poziom szczegółowości do odbiorców (programiści vs. stakeholderzy).

  4. Połącz perspektywy: Używaj wielu diagramów, aby opowiedzieć pełną historię (np. Przypadek użycia → Sekwencja → Klasa).

  5. Rozszerz zrozumieniem: Używaj stereotypów, oznaczonych wartości i profili do potrzeb specyficznych dla dziedziny — ale dokumentuj konwencje.

  6. Zachowaj czytelność: Pomijaj nieistotne szczegóły; używaj notatek do dodatkowego kontekstu.

📌 Pamiętaj„UML to język, a nie metodyka.” Daje oznaczenia — nie proces. Wybieraj diagramy, które ułatwiają komunikację, a nie te, które służą do zaznaczania pól.

Wnioski

Opanowanie UML polega mniej na zapamiętywaniu każdej reguły składniowej, a bardziej na nauce opowiadania jasnej, celowej historii o Twoim systemie. Jak pokazuje ten przewodnik, każdy typ diagramu UML oferuje inny punkt widzenia: diagramy klas i pakietów ujawniają architekturę statyczną, diagramy sekwencji i maszyn stanów odsłaniają zachowanie dynamiczne, podczas gdy diagramy wdrażania i struktury złożonej łączą projektowanie z wykonaniem. Prawdziwa siła UML tkwi w jego elastyczności — skaluje się od szkiców na tablicy do modeli wykonywalnych sterowanych narzędziem, a dostosowuje się do potrzeb programistów, architektów i stakeholderów biznesowych. Pamiętaj, że skuteczne modelowanie jest iteracyjne, kierowane przez odbiorcę i świadomie selektywne. Zacznij od najprostszego diagramu, który przekazuje Twój cel, doskonal go wraz z pogłębianiem zrozumienia i łączy kilka perspektyw, gdy pojedynczy diagram nie wystarcza. UML to język komunikacji, a nie lista do sprawdzenia; używaj go do rozjaśniania niepewności, a nie do ich tworzenia. Stosując te zasady zrozumieniem, przekształcisz abstrakcyjne pojęcia w wykonalne szkice, które wyrównają zespoły, przyspieszą rozwój i utrzymają Twoje systemy odporność w trakcie ich ewolucji.

Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, English, Bahasa Indonesia, 日本語 and Portuguese