UML oznaczaJęzyk modelowania zintegrowanego. Jest to standardowy język modelowania składający się z zintegrowanej zbioru diagramów stworzonych w celu pomocy inżynierom systemów i oprogramowania w określaniu, wizualizacji, budowaniu i dokumentowaniu artefaktów systemów oprogramowania, a także do modelowania biznesowego i innych systemów niezwiązanych z oprogramowaniem.

UML reprezentuje zbiór najlepszych praktyk inżynierskich, które się sprawdziły w modelowaniu dużych i skomplikowanych systemów. UML jest ważną częścią tworzenia oprogramowania zorientowanego obiektowo oraz procesu rozwoju oprogramowania. UML głównie wykorzystuje notację graficzną do wyrażania projektu systemów oprogramowania. Użycie UML pomaga zespołom projektowym komunikować się, eksplorować potencjalne projekty i weryfikować architekturę oprogramowania. W tym artykule przedstawiamy szczegółowe informacje na temat tego, czym jest UML.

Pochodzenie UML

Cel UML polega na zapewnieniu standardowej notacji, którą można wykorzystywać we wszystkich metodach zorientowanych obiektowo, oraz na wyborze i zintegrowaniu najlepszych elementów poprzednich notacji. UML został zaprojektowany do szerokiego zakresu zastosowań. Dlatego oferuje konstrukcje dla szerokiego zakresu systemów i działań (np. systemy rozproszone, analiza, projektowanie systemów i wdrażanie).

UML powstał z połączenia trzech wiodących notacji modelowania zorientowanych obiektowo:

1. Technika modelowania obiektowego (OMT) [James Rumbaugh 1991] – najlepiej nadaje się do analizy i systemów informacyjnych z dużą ilością danych.
2. Booch [Grady Booch 1994] – bardzo silny w projektowaniu i implementacji. Grady Booch pracował intensywnie z językiemAda i był głównym twórcą rozwoju tego języka w kierunku zorientowanym obiektowo. Choć metoda Booch była potężna, jej notacja nie była szczególnie popularna (w jego modelach dużo kształtów w kształcie chmury – niezbyt estetyczne).
3. OOSE (Inżynieria oprogramowania zorientowanego obiektowo [Ivar Jacobson 1992]) – charakteryzowane jest modelem zwanym przypadkami użycia. Przypadki użycia to potężna technika do zrozumienia zachowania całego systemu (dziedzina, w której OO tradycyjnie była słaba).

W 1994 roku świat oprogramowania został wstrząśnięty, gdy Jim Rumbaugh, twórca OMT, opuścił General Electric i dołączył do Grady’ego Boocha w Rational Software. Współpraca miała na celu połączenie ich idei w jedną metodę (tymczasowy tytuł to „Metoda Zintegrowana”).

Do 1995 roku Ivar Jacobson, twórca OOSE, również dołączył do Rational, a jego pomysły (szczególnie koncepcja „Przypadków użycia”) zostały włączone do nowej metody zintegrowanej – teraz nazywanej Językiem Modelowania Zintegrowanego 1. Zespół Rumbaugh, Booch i Jacobson był serdecznie nazywany „Trójką Przyjaciół”.

UML został również wpływowany przez inne notacje zorientowane obiektowo w tym czasie:

• Mellor i Shlaer [1998]
• Coad i Yourdon [1995]
• Wirfs-Brock [1990]
• Martin i Odell [1992]

UML również zawierał nowe koncepcje, których nie było w innych głównych metodach tego czasu, takie jak mechanizmy rozszerzania i języki ograniczeń.

Historia UML

1. W 1996 rokuGrupa Zarządzania Obiektami (OMG) wydała pierwszą prośbę o ofertę (RFP), która stała się bodźcem do współpracy tych organizacji w celu przygotowania wspólnej odpowiedzi na RFP.
2. Rational utworzyła konsorcjum UML Partners z kilkoma organizacjami gotowymi poświęcić zasoby na stworzenie silnej definicji UML 1.0. Największy udział w definicji UML 1.0 miały następujące organizacje:
   • Digital Equipment Corporation
   • Hewlett-Packard
   • I-Logix
   • IntelliCorp
   • IBM
   • ICON Computing
   • MCI Systemhouse
   • Microsoft
   • Oracle
   • Rational Software
   • Texas Instruments
   • Unisys
3. Ta współpraca przyniosła UML 1.0, dobrze zdefiniowany, wyrazisty, potężny i ogólnego przeznaczenia język modelowania. Został przedstawiony OMG jako pierwsza odpowiedź na RFP w styczniu 1997 roku.
4. W styczniu 1997 roku IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies i Softeam również przedstawiły osobne odpowiedzi na RFP w OMG. Te firmy dołączyły do partnerów UML, aby przyczynić się do rozwoju idei, a partnerzy wspólnie przygotowali zmienioną odpowiedź UML 1.1. UML 1.1 skupił się na poprawie jasności semantyki UML 1.0 oraz włączeniu wkładu nowych partnerów. Przedstawiono ją do rozważenia w OMG i przyjęto ją jesienią 1997 roku. Wersje rozwinęły się od 1.1 do 1.5, a następnie UML 2.0 do 2.5 (obecna wersja to UML 2.5).

Dlaczego UML?

Wraz z rosnącą wartością strategiczną oprogramowania dla wielu firm, przemysł szukał technologii do automatyzacji produkcji oprogramowania i poprawy jakości przy jednoczesnym zmniejszaniu kosztów i czasu wprowadzania na rynek. Do tych technologii należą technologia komponentów, programowanie wizualne, wzorce i frameworki. Firmy poszukują również sposobów zarządzania złożonością w miarę zwiększania zakresu i skali działalności. W szczególności uznają potrzebę rozwiązywania powtarzających się problemów architektonicznych, takich jak rozkład fizyczny, współbieżność, replikacja, bezpieczeństwo, balansowanie obciążenia i odporność na awarie. Dodatkowo rozwój World Wide Web, mimo że uproszczył niektóre aspekty, pogorszył te problemy architektoniczne. Język Modelowania Unifikowanego (UML) został zaprojektowany w celu spełnienia tych potrzeb.

1. Zaoferuj użytkownikom gotowy do użycia, wyrazisty język modelowania wizualnego do tworzenia i wymiany znaczących modeli.
2. Zaoferuj mechanizmy rozszerzalności i specjalizacji w celu rozszerzenia podstawowych pojęć.
3. Być niezależnym od konkretnych języków programowania i procesów rozwojowych.
4. Zaoferuj podstawę formalną do zrozumienia języka modelowania.
5. Zachęcaj do rozwoju rynku narzędzi zorientowanych obiektowo.
6. Wsparcie zaawansowanych koncepcji rozwojowych, takich jak współprace, frameworki, wzorce i komponenty.
7. Zintegruj najlepsze praktyki.

UML – Przegląd

Zanim zajmiemy się teorią UML, krótko przedstawmy niektóre z głównych koncepcji UML.

Pierwszą rzeczą do zauważenia w UML jest to, że istnieje wiele różnych diagramów (modeli), do których trzeba się przyzwyczaić. Powodem tego jest to, że system można oglądać z wielu różnych perspektyw. Tworzenie oprogramowania obejmuje wiele stron zaangażowanych.

Na przykład:

• Analitycy
• Projektanci
• Programiści
• Testeri
• QA
• Klienci
• Autorzy techniczni

Wszyscy ci ludzie interesują się różnymi aspektami systemu, a każdy aspekt wymaga innego poziomu szczegółowości. Na przykład programiści muszą zrozumieć projekt systemu i potrafić przekształcić ten projekt w kod niskiego poziomu. W przeciwieństwie do tego, autorzy techniczni interesują się ogólnym zachowaniem systemu i muszą zrozumieć funkcjonalność produktu. UML stara się zapewnić język wystarczająco wyrazisty, aby wszyscy zaangażowani mogli skorzystać z co najmniej jednego diagramu UML.

Oto szybki przegląd każdego z 13 diagramów przedstawionych w strukturze diagramów UML 2:

Diagramy strukturalne pokazują statyczną strukturę systemu i jego części na różnych poziomach abstrakcji i implementacji, oraz jak się ze sobą wiążą. Diagramy strukturalne mają siedem typów:

• Diagram klas
• Diagram komponentów
• Diagram wdrożenia
• Diagram obiektów
• Diagram pakietów
• Diagram struktury złożonej
• Diagram profilu

Diagramy zachowaniowe pokazują dynamiczne zachowanie obiektów w systemie, które można opisać jako serię zmian w czasieczasie. Istnieją siedem typów diagramów zachowaniowych:

• Diagram przypadków użycia
• Diagram aktywności
• Diagram maszyny stanów
• Diagram sekwencji
• Diagram komunikacji
• Diagram przeglądowy interakcji
• Diagram czasu

Co to jest diagram klas?

Diagram klas to centralny sposób modelowania używany w prawie wszystkich metod obiektowych. Diagram ten opisuje typy obiektów w systemie oraz różne relacje statyczne między nimi.

Relacje

Istnieją trzy główne relacje, które są ważne:

1. Związek – wskazuje relację między instancjami typów (np. osoba pracuje w firmie, firma ma wiele biur).
2. Dziedziczenie – najbardziej oczywiste uzupełnienie diagramów ER używanych w programowaniu obiektowym. Ma bezpośredni odpowiednik w dziedziczeniu w projektowaniu obiektowym.
3. Agregacja – forma kompozycji obiektów w projektowaniu obiektowym.

Przykład diagramu klas

Aby uzyskać więcej informacji na temat diagramów klas, przeczytaj artykuł Co to jest diagram klas?

Co to jest diagram komponentów?

W języku modelowania jednolitych (UML), diagram komponentów przedstawia sposób łączenia komponentów w celu utworzenia większych komponentów lub systemów oprogramowania. Ilustruje architekturę komponentów oprogramowania oraz ich zależności. Do komponentów oprogramowania zaliczają się komponenty uruchamiane, komponenty wykonywalne oraz komponenty kodu źródłowego.

Przykład diagramu komponentów

Aby uzyskać więcej informacji na temat diagramów komponentów, przeczytaj artykuł Co to jest diagram komponentów?

Co to jest diagram wdrożenia?

Diagramy wdrożenia pomagają modelować aspekty fizyczne systemów oprogramowania zorientowanych obiektowo. Jest to diagram strukturalny, który przedstawia architekturę systemu jako wdrożenie (dystrybucję) artefaktów oprogramowania na cele wdrożenia. Artefakty reprezentują konkretne elementy świata fizycznego powstające w wyniku procesu rozwoju. Modeluje konfigurację czasu działania w widoku statycznym i wizualizuje dystrybucję artefaktów w aplikacji. W większości przypadków dotyczy modelowania konfiguracji sprzętu oraz komponentów oprogramowania, które na nim działają.

Przykład diagramu wdrożenia

Aby uzyskać więcej informacji na temat diagramów wdrożenia, przeczytaj artykuł Co to jest diagram wdrożenia?

Co to jest diagram obiektów?

Diagram obiektów to graf instancji, obejmujący obiekty i wartości danych. Diagram obiektów statyczny jest instancją diagramu klas; przedstawia zdjęcie szczegółowego stanu systemu w konkretnym momencie. Różnica polega na tym, że diagram klas reprezentuje abstrakcyjny model składający się z klas i ich relacji, podczas gdy diagram obiektów przedstawia instancje w konkretnym momencie, który jest z natury konkretny. Użycie diagramów obiektów jest dość ograniczone, głównie do pokazywania przykładów struktur danych.

Diagram klas w porównaniu z diagramem obiektów – przykład

Niektórzy ludzie mogą mieć trudności z zrozumieniem różnicy między diagramami klas UML a diagramami obiektów UML, ponieważ oba zawierają nazwane „prostokątne bloki” z atrybutami i połączeniami między nimi, co sprawia, że oba diagramy UML wyglądają podobnie. Niektórzy nawet uważają je za identyczne, ponieważ w narzędziach UML symbole diagramu klas i diagramu obiektów znajdują się w tym samym edytorze diagramów – edytorze diagramu klas.

W rzeczywistości diagramy klas i diagramy obiektów reprezentują dwa różne aspekty kodu źródłowego. W tym artykule przedstawiamy kilka pomysłów na temat tych dwóch diagramów UML, czym są, jak się różnią i kiedy ich używać.

Związek między diagramem klas i diagramem obiektów

Tworzysz „klasy” podczas programowania. Na przykład w systemie bankowości internetowej możesz stworzyć klasy takie jak „Użytkownik”, „Konto”, „Transakcja” itp. W systemie zarządzania klasą możesz stworzyć klasy takie jak „Nauczyciel”, „Uczeń”, „Zadanie” itp. W każdej klasie znajdują się atrybuty i operacje, które reprezentują cechy i zachowania klasy. Diagram klas to diagram UML, na którym możesz wizualizować te klasy, ich atrybuty, operacje oraz relacje między nimi.

Diagram obiektów UML pokazuje, jak wyglądają instancje obiektów klas (narysowane na diagramie klas UML) w konkretnym stanie. Innymi słowy, diagram obiektów UML można traktować jako instancję sposobu, w jaki klasy (na diagramie klas UML) są używane w konkretnym stanie.

Jeśli nie podoba Ci się te definicje, zajrzyj do przykładów diagramów UML poniżej. Uważam, że zrozumiesz ich różnicę w ciągu sekund.

Przykład diagramu klas

Poniższy przykład diagramu klas przedstawia dwie klasy – Użytkownik i Załącznik. Użytkownik może przesłać wiele załączników, dlatego klasy te są powiązane relacją z wielokrotnością 0…* po stronie Załącznik.

Przykład diagramu obiektów

Poniższy przykład diagramu obiektów pokazuje, jak wyglądają instancje obiektów klas Użytkownik i Załącznik, gdy Peter (czyli użytkownik) próbuje przesłać dwa załączniki. Zatem istnieją dwie specyfikacje instancji dwóch załączników do przesłania.

Aby uzyskać więcej informacji na temat diagramów obiektów, przeczytaj artykuł Co to jest diagram obiektu?

Co to jest diagram pakietu?

Diagram pakietu to diagram struktury UML, który pokazuje pakietu i zależności między nimi. Diagramy pakietów pozwalają przedstawić różne widoki systemu, np. jako aplikację wielowarstwowa (nazywana również wielopoziomową) – model aplikacji wielowarstwowej.

Przykład diagramu pakietu

Aby uzyskać więcej informacji na temat diagramów pakietów, przeczytaj artykuł Co to jest diagram pakietu?

Co to jest diagram struktury złożonej?

Diagramy struktury złożonej to jedna z nowych artefaktów dodanych do UML 2.0. Diagram struktury złożonej jest podobny do diagramu klas i stanowi rodzaj diagramu składników, głównie używany do modelowania systemu z mikroperspektywy, ale przedstawia strukturę wewnętrzną pojedynczego elementu, a nie całej klasy. Jest to diagram statycznej struktury, który pokazuje wewnętrzną strukturę klasy oraz współprace, które ta struktura umożliwia.

Diagram może zawierać elementy wewnętrzne, porty, przez które elementy współdziałają ze sobą lub instancje klasy współdziałają z zewnętrznym światem, oraz połączenia między elementami lub portami. Struktura złożona to zbiór połączonych ze sobą elementów, które współpracują w czasie wykonywania, aby osiągnąć określony cel. Każdy element ma określoną rolę w tej współpracy.

Przykład diagramu struktury złożonej

Aby uzyskać więcej informacji na temat diagramów struktury złożonej, przeczytaj artykuł Co to jest diagram struktury złożonej?

Co to jest diagram profilu?

Z wykorzystaniem diagramu profilu możesz tworzyć stereotypy specyficzne dla domeny i platformy oraz definiować ich relacje. Stereotypy możesz tworzyć, rysując kształty stereotypów i łącząc je za pomocą kompozycji lub uogólnienia poprzez interfejs skupiony na zasobach. Możesz również definiować i wizualizować wartości oznaczone stereotypów.

Przykład diagramu profilu

Aby uzyskać więcej informacji na temat diagramów profilu, przeczytaj artykuł Co to jest diagram profilu w UML?

Co to jest diagram przypadków użycia?

Model przypadków użycia opisuje wymagania funkcjonalne systemu pod kątem przypadków użycia. Jest to model zamierzonych funkcji systemu (przypadki użycia) oraz jego środowiska (aktorów). Przypadki użycia pozwalają na powiązanie tego, co system ma robić, z tym, jak system spełnia te wymagania.

Wyobraź sobie model przypadków użycia jak menu, takie jak to, które znajdziesz w restauracji. Patrząc na menu, możesz zobaczyć, jakie dania są dostępne, poszczególne dania i ich ceny. Wiesz również, jaką kuchnię obsługuje restauracja: włoską, mejkaną, chińską itd. Patrząc na menu, otrzymujesz ogólny obraz tego, jaką doświadczenie gastronomiczne czeka na Ciebie w tej restauracji. Menu naprawdę „symuluje” zachowanie restauracji.

Ponieważ jest to tak potężny narzędzie planowania, modele przypadków użycia są wykorzystywane przez wszystkich członków zespołu na wszystkich etapach cyklu rozwojowego.

Przykład diagramu przypadków użycia

Aby uzyskać więcej informacji na temat diagramów przypadków użycia, przeczytaj artykuł Co to jest diagram przypadków użycia?

Co to jest diagram aktywności?

Diagram aktywności to graficzne przedstawienie przepływów krok po kroku działań i czynności z obsługą wyboru, iteracji i współbieżności. Opisuje przepływ sterowania systemu docelowego, np. badanie złożonych reguł i operacji biznesowych, opisywanie przypadków użycia i procesów biznesowych. W języku Unified Modeling Language diagramy aktywności mają na celu modelowanie zarówno procesów obliczeniowych, jak i organizacyjnych (tj. przepływów pracy).

Przykład diagramu aktywności

Aby uzyskać więcej informacji na temat diagramów aktywności, przeczytaj artykuł Co to jest diagram aktywności?

Co to jest diagram maszyny stanów?

Diagram stanu to rodzaj diagramu używany w UML do opisu zachowania systemu na podstawie koncepcji statechart Davida Harela. Diagramy stanu przedstawiają dozwolone stany i przejścia, a także zdarzenia wpływające na te przejścia. Pomaga w wizualizacji całego cyklu życia obiektu, co ułatwia lepsze zrozumienie systemów opartych na stanach.

Przykład diagramu maszyny stanów

Aby uzyskać więcej informacji na temat diagramów maszyny stanów, przeczytaj artykuł Co to jest diagram maszyny stanów?

Co to jest diagram sekwencji?

Diagram sekwencji modeluje współpracę obiektów według kolejności czasowej. Pokazuje, jak obiekty współdziałają ze sobą w konkretnym scenariuszu przypadku użycia. Dzięki zaawansowanym możliwościom modelowania wizualnego możesz tworzyć złożone diagramy sekwencji jednym kliknięciem. Dodatkowo niektóre narzędzia modelowania (takie jak Visual Paradigm) mogą generować diagramy sekwencji na podstawie przepływu zdarzeń, które zdefiniowałeś w opisach przypadków użycia.

Przykład diagramu sekwencji

Aby uzyskać więcej informacji na temat diagramów sekwencji, przeczytaj artykuł Co to jest diagram sekwencji?

Co to jest diagram komunikacji?

Podobnie jak diagram sekwencji, diagram komunikacji służy również do modelowania zachowania dynamicznego przypadku użycia. W porównaniu z diagramami sekwencji, diagramy komunikacji skupiają się bardziej na pokazaniu współpracy obiektów niż na kolejności czasowej. Są semantycznie równoważne, dlatego niektóre narzędzia modelowania (takie jak Visual Paradigm) pozwalają generować jeden z drugiego.

Przykład diagramu komunikacji

Aby uzyskać więcej informacji na temat diagramów komunikacji, przeczytaj artykuł Co to jest diagram komunikacji?

Co to jest diagram przeglądowy interakcji?

Diagram przeglądowy interakcji skupia się na przeglądzie przepływu sterowania interakcji. Jest to wariant diagramu aktywności, w którym węzły to interakcje lub wystąpienia interakcji. Diagram przeglądowy interakcji opisuje interakcje, w których wiadomości i linie życia są ukryte. Możesz tworzyć linki do „rzeczywistych” diagramów i osiągać wysoką nawigacyjność między diagramami w diagramie przeglądowym interakcji.

Przykład diagramu przeglądowego interakcji

Aby uzyskać więcej informacji na temat diagramów przeglądowych interakcji, przeczytaj artykuł Co to jest diagram przeglądowy interakcji?

Co to jest diagram czasowy?

Diagram czasowy pokazuje zachowanie obiektów w określonym przedziale czasu. Diagramy czasowe to specjalna forma diagramu sekwencji. Różnica między diagramami czasowymi a diagramami sekwencji polega na tym, że osie są odwrócone, więc czas rośnie od lewej do prawej, a linie życia są przedstawione w pionowo ułożonych oddzielnych komorach.

Przykład diagramu czasowego

Aby uzyskać więcej informacji na temat diagramów czasowych, przeczytaj artykuł Co to jest diagram czasowy?

Naucz się UML. Rysuj UML.

Pobierz wersję społecznościową Visual Paradigm – darmowe narzędzie UML, które pomaga szybciej i skuteczniej nauczyć się UML. Wersja społecznościowa Visual Paradigm obsługuje wszystkie typy diagramów UML. Jej nagradzany modeler UML jest intuicyjny i łatwy w użyciu.

Pobierz bezpłatnie

Słownik i terminologia UML

• Klasa abstrakcyjna – Klasa, która nigdy nie jest instancjonowana. Nie istnieją żadne instancje tej klasy.
• Uczestnik – Obiekt lub osoba, która inicjuje zdarzenia związane z systemem.
• Aktywność: Krok lub działanie w diagramie aktywności. Reprezentuje operację wykonywaną przez system lub uczestnika.
• Diagram aktywności: Ulepszony schemat blokowy pokazujący kroki i decyzje w procesie, a także operacje równoległe, takie jak algorytm lub proces biznesowy.
• Agregacja – Jest częścią innej klasy. Pokazywane jako pusta romboidna strzałka obok klasy zawierającej na diagramie.
• Artefakt – Dokument opisujący wynik kroku w procesie projektowania. Opis może być graficzny, tekstowy lub ich kombinacją.
• Związek – Połączenie między dwoma elementami w modelu. Może reprezentować zmienną członkowską w kodzie, związek między rekordem personelu a osobą, którą reprezentuje, relację między dwiema klasami pracowników lub dowolną podobną relację. Domyślnie oba elementy w związku znają się wzajemnie i są równe. Związek może również być kierowalny, co oznacza, że końcówka źródłowa zna końcówkę docelową, ale nie na odwrót.
• Klasa związku: Klasa, która reprezentuje związek między dwiema innymi klasami i dodaje do niego informacje.
• Atrybut – Cecha obiektu, która może służyć do odwoływania się do innych obiektów lub przechowywania informacji o stanie obiektu.
• Klasa bazowa: Klasa, która definiuje atrybuty i operacje dziedziczone przez podklasy poprzez relację uogólnienia.
• Gałąź: Punkty decyzyjne w diagramie aktywności. Z gałęzi wychodzą wiele przejść, każde z warunkiem ochronnym. Gdy sterowanie osiąga gałąź, dokładnie jeden warunek ochronny musi być prawdziwy, a sterowanie następuje po odpowiednim przejściu.
• Klasa: Kategoria podobnych obiektów, wszystkie opisane tymi samymi atrybutami i operacjami, oraz wszystkie kompatybilne pod względem przypisania.
• Diagram klas – Pokazuje klasy w systemie i relacje między nimi.
• Klasyfikator: Element UML, który ma atrybuty i operacje. Dokładnie: uczestnicy, klasy i interfejsy.
• Kooperacja: Relacja między dwoma obiektami na diagramie komunikacji, wskazująca, że komunikaty mogą przepływać w obu kierunkach między obiektami.
• Diagram komunikacji – Diagram pokazujący, jak wykonywana jest operacja, z naciskiem na role obiektów.
• Komponenta: Jednostka kodu, którą można wdrożyć w systemie.
• Diagram komponentów: Diagram pokazujący relacje między różnymi komponentami i interfejsami.
• Koncepcja – rzeczownik lub koncepcja abstrakcyjna do uwzględnienia w modelu dziedziny.
• Faza budowy – Trzecia faza procesu Rational Unified Process, w której w zbudowanym systemie tworzony jest wiele iteracji funkcjonalnych. To w tej fazie odbywa się większość pracy.
• Zależność: Relacja wskazująca, że jeden klasifikator zna atrybuty i operacje drugiego klasifikatora, ale nie jest bezpośrednio połączony z żadnymi wystąpieniami drugiego klasifikatora.
• Diagram wdrożenia: Diagram pokazujący relacje między różnymi procesorami.
• Dziedzina – Część uniwersum dyskursu, z którą system się zajmuje.
• Faza wypracowania – Druga faza procesu Rational Unified Process, pozwalająca na dodatkowe planowanie projektu, w tym iteracje w fazie budowy.
• Element: Dowolny element wyświetlany w modelu.
• Ukrywanie danych – Dane wewnątrz obiektu są prywatne.
• Ogólnienie – Wskazuje, że jedna klasa jest podklasą drugiej (klasy nadrzędnej). Pusta strzałka wskazuje klasę nadrzędna.
• Zdarzenie: W diagramie stanów reprezentuje sygnał, zdarzenie lub wejście, które powoduje podjęcie działania przez system lub zmianę stanu.
• Stan końcowy: W diagramie stanów lub diagramie aktywności reprezentuje punkt, w którym diagram zostaje zakończony.
• Rozgałęzienie: Punkt w diagramie aktywności, w którym zaczynają się wiele równoległych wątków sterowania.
• Ogólnienie: Relacja dziedziczenia, w której podklasa dziedziczy i rozszerza atrybuty i operacje klasy bazowej.
• GoF – wzorce projektowe Gang of Four.
• Wysoka spójność – Wzorzec oceniany GRASP, który zapewnia, że klasa nie jest zbyt złożona i nie wykonuje niezwiązanych ze sobą funkcji.
• Niska acykliczność – Wzorzec oceniany GRASP, który mierzy stopień, w jakim jedna klasa zależy od lub jest połączona z inną klasą.
• Faza inicjacji – Pierwsza faza procesu Unified Rational, zajmująca się początkową koncepcją i rozpoczęciem projektu.
• Dziedziczenie – Klasa pochodna dziedziczy atrybuty lub cechy z klasy nadrzędnej (klasy nadrzędnej). Te atrybuty mogą być nadpisywane w klasie pochodnej.
• Stan początkowy: W diagramie stanów lub diagramie działań reprezentuje punkt, w którym diagram zaczyna się.
• Instancja – Obiekt jest instancją klasy. Klasa działa jak szablon do tworzenia obiektów. Można utworzyć dowolną liczbę instancji klasy.
• Interfejs: Klasifikator definiujący atrybuty i operacje tworzące kontrakt zachowaniowy. Klasa lub komponent dostawcy może wybrać zaimplementowanie interfejsu (tj. zaimplementować jego atrybuty i operacje). Klasy lub komponenty klienta mogą następnie polegać na interfejsie, używając dostawcy bez znajomości szczegółów rzeczywistej klasy dostawcy.
• Iteracja – Część mini-projektu, w której dodawana jest pewna mała część funkcjonalności do projektu. Zawiera cykl rozwojowy obejmujący analizę, projektowanie i kodowanie.
• Połączenie: Punkt w diagramie działań, w którym wiele równoległych wątków sterowania synchronizuje się i ponownie łączy.
• Członek: Atrybut lub operacja w klasifikatorze.
• Scalenie: Punkt w diagramie działań, w którym różne ścieżki sterowania łączą się.
• Komunikat – Prośba jednego obiektu do drugiego o wykonanie pewnej czynności. Jest to zasadniczo wywołanie metody w odbiorczej obiekcie.
• Metoda – Funkcja lub procedura w obiekcie.
• Model – Kluczowy element UML. Składa się z różnych elementów ułożonych w hierarchiach z relacjami między nimi.
• Wielokrotność – Wyświetlane obok pola pojęcia zewnętrznego w modelu domeny i wskazuje relację ilościową między obiektami a innymi obiektami.
• Nawigacja: Wskazuje, które końce relacji mają wiedzę o drugim końcu. Relacja może mieć nawigację dwukierunkową (każdy koniec zna drugi) lub jednokierunkową (jeden koniec zna drugi, ale nie odwrotnie).
• Notacja – Dokumentacja graficzna z zasadami tworzenia metod analizy i projektowania.
• Uwaga: Tekstowa uwaga dodana do diagramu w celu szczegółowego wyjaśnienia diagramu.
• Obiekt – W diagramie aktywności obiekt, który otrzymuje informacje lub dostarcza informacje do aktywności. W diagramie współpracy lub sekwencji obiekt uczestniczący w scenariuszu opisanym na diagramie. Ogólnie: wystąpienie lub przykład danego klasyfikatora (aktor, klasa lub interfejs).
• Pakiet – Zbiór elementów UML, które logicznie należą do siebie.
• Diagram pakietu: Diagram klas, w którym wszystkie elementy są pakietami i zależnościami.
• Wzorzec – Rozwiązanie problemu przypisywania odpowiedzialności za interakcje obiektów. Jest to nazwane rozwiązanie problemu, który często się pojawia i jest dobrze znany.
• Parametr: Parametr operacji.
• Polimorfizm – Ta sama wiadomość, różne metody. Używany również jako wzorzec.
• Prywatny: Poziom widoczności stosowany do atrybutu lub operacji, wskazujący, że dostęp do elementu ma tylko kod znajdujący się w zawierającym klasyfikatorze.
• Procesor: W diagramie wdrożenia reprezentuje komputer lub inny urządzenie programowalne, na którym można wdrożyć kod.
• Chroniony: Poziom widoczności stosowany do atrybutu lub operacji, wskazujący, że dostęp do elementu ma tylko kod znajdujący się w zawierającym klasyfikatorze lub jego podklasach.
• Publiczny: Poziom widoczności stosowany do atrybutu lub operacji, wskazujący, że dostęp do elementu ma dowolny kod.
• Strzałka kierunku odczytu – Wskazuje kierunek relacji w modelu domeny.
• Realizacja: Wskazuje, że komponent lub klasa zapewnia dany interfejs.
• Rola – Używane w modelu domeny, jest opcjonalnym opisem roli, jaką odgrywa jednostka.
• Diagram sekwencji: Diagram pokazujący istnienie obiektów w czasie oraz komunikaty przekazywane między tymi obiektami w czasie w celu wykonania pewnej behawioru. Diagram stanu – Diagram pokazujący wszystkie możliwe stany obiektu.
• Stan: W diagramie stanu reprezentuje warunek lub stan systemu lub podsystemu: co robi w danym momencie i jakie ma wartości danych.
• Diagram stanu: Diagram pokazujący stany systemu lub podsystemu, przejścia między stanami oraz zdarzenia, które powodują przejścia.
• Statyczny: Modyfikator stosowany do atrybutu wskazujący, że tylko jedna kopia atrybutu jest współdzielona przez wszystkie instancje klasyfikatora. Modyfikator stosowany do operacji wskazujący, że operacja jest niezależna i nie działa na konkretnej instancji klasyfikatora.
• Stereotyp: Modyfikator stosowany do elementu modelu wskazujący na coś, co zwykle nie może być wyrażone w UML. W istocie, stereotypy pozwalają na zdefiniowanie własnego „dialektu” UML.
• Podklasa: Klasa, która dziedziczy atrybuty i operacje zdefiniowane przez klasę nadrzędną poprzez relację uogólnienia.
• Płyn: Element w diagramie aktywności wskazujący, która część systemu lub domeny odpowiada za określoną aktywność. Wszystkie aktywności w płycie są odpowiedzialnością obiektu, komponentu lub aktora reprezentowanego przez płat.
• Ograniczanie czasowe – Każda iteracja ma ustalony limit czasowy z konkretnym celem.
• Przejście: W diagramie aktywności reprezentuje przepływ sterowania od jednej aktywności lub gałęzi lub scalenia lub rozgałęzienia lub połączenia do innej. W diagramie stanu reprezentuje zmianę od jednego stanu do innego.
• Faza przejściowa – Ostatnia faza procesu Rational Unified Process, w której użytkownicy są uczonymi używania nowego systemu, a system jest udostępniany użytkownikom.
• UML – Unified Modeling Language poprawia analizę i projektowanie projektów oprogramowania poprzez umożliwienie silniejszych relacji między obiektami za pomocą dokumentacji tekstowej i graficznej.
• Przypadek użycia: W diagramie przypadków użycia reprezentuje działanie podjęte przez system w odpowiedzi na żądanie od aktora.
• Diagram przypadków użycia: Diagram pokazujący relacje między aktorami i przypadkami użycia.
• Widoczność: Modyfikator dla atrybutu lub operacji wskazujący, który kod może uzyskać dostęp do elementu. Poziomy widoczności obejmują Publiczny, Chroniony i Prywatny.
• Przepływ pracy – Zestaw działań, które prowadzą do konkretnego wyniku.

Popularne książki o UML

Oto niektóre z najpopularniejszych książek o UML, które możesz przeczytać, aby nauczyć się UML:

1. UML Distilled: Krótkie przewodnik po standardowym języku modelowania obiektowego
2. UML 2 i Unified Process: Praktyczna analiza i projektowanie obiektowe
3. Nauka UML 2.0
4. Tworzenie aplikacji internetowych z użyciem UML
5. Podręcznik referencyjny języka modelowania Unified
6. Zasady stylu UML™ 2.0
7. UML dla programistów Java
8. Schaum’s Outline of UML
9. Przewodnik użytkownika języka modelowania Unified
10. Przewodnik do certyfikacji UML 2: egzaminy podstawowe i średnie
11. Podstawy projektowania obiektowego w UML
12. Zastosowanie modelowania obiektowego opartego na przypadkach użycia z UML: przykład e-handlu z komentarzami
13. Projektowanie elastycznych systemów obiektowych z użyciem UML
14. Modelowanie obiektowe oparte na przypadkach użycia z UML
15. Analiza i projektowanie systemów z UML w wersji 2.0: podejście obiektowe
16. UML 2.0 w pigułce
17. Analiza i projektowanie obiektowe z zastosowaniami
18. UML wyjaśnione
19. Wzorce projektowe: elementy oprogramowania obiektowego użytecznego ponownie
20. Podstawy obiektowe: rozwój modelowy agilny z UML 2.0

Linki powiązane

1. Profesjonalny narzędzie do projektowania UML do modelowania wizualnego