Kluczem do obiektowego sposobu rozwiązywania problemów jest skonstruowanie modelu. Model abstrahuje podstawowe cechy problemu ze zwykle skomplikowanego świata rzeczywistego. Pod wspólną nazwą UML™ (ang. Unified Modeling Language™) kryje się kilka narzędzi do modelowania. Celem tego dokumentu jest przedstawienie najważniejszych właściwości języka UML.

Podstawą języka UML jest dziewięć rodzajów diagramów modelowania:

• Diagramy przypadków użycia

• Diagramy klas

• Diagramy obiektów

• Diagramy sekwencji

• Diagramy współpracy

• Diagramy stanów

• Diagramy aktywności

• Diagramy komponentów

• Diagramy wdrożenia

W niektórych podrozdziałach tego samouczka znajdują się łącza do stron z bardziej szczegółowymi informacjami. Po każdym podrozdziale następuje kilka krótkich pytań; spróbuj na nie odpowiedzieć, aby sprawdzić, czy dobrze rozumiesz temat podrozdziału.

Dlaczego język UML jest ważny?
Spróbujmy odpowiedzieć na to pytanie z perspektywy branży budowlanej. Architekci projektują budynki, a inżynierowie budują je na podstawie projektów. Im bardziej skomplikowany budynek, tym ważniejsza jest komunikacja między architektem a inżynierem. Plany architektoniczne to standardowy graficzny język, którego architekci i inżynierowie muszą się nauczyć jako części swojego zawodu.

Pisanie programowania można porównać ze wznoszeniem budynku. Im bardziej skomplikowany jest bazowy system, tym ważniejsza staje się komunikacja między wszystkimi osobami zaangażowanymi w tworzenie i wdrażanie oprogramowania. W zeszłej dekadzie UML stał się standardowym językiem do tworzenia planów oprogramowania, używanym przez analityków, projektantów i programistów. Obecnie stanowi nieodłączną część rzemiosła programistycznego. UML to wspólny język analityków biznesowych, projektantów i programistów, za pomocą, którego mogą mówić o projektowaniu oprogramowania.

Język UML da się zastosować do obiektowego sposobu rozwiązywania problemów. Każdy, kto chce nauczyć się języka UML, musi dobrze znać kanony podejścia obiektowego - wszystko zaczyna się od skonstruowania modelu. Model to abstrakcja problemu. Domena to rzeczywisty świat, który jest źródłem problemu.

Modele składają się z obiektów, które wchodzą w interakcje, przesyłając sobie nawzajem komunikaty. Wyobraź sobie obiekt jako żywą istotę. Obiekty mają coś, co wiedzą (atrybuty), oraz coś, co mogą zrobić (zachowania lub operacje). Wartości atrybutów obiektu określają jego stan.

Klasy to "plany" obiektów. Klasa łączy atrybuty (dane) oraz zachowania (metody lub funkcje) w jedną odrębną jednostkę. Obiekty są egzemplarzami (instancjami) klas.

Diagramy przypadków użycia
Diagramy przypadków użycia opisują, co robi system z punktu widzenia zewnętrznego obserwatora. Eksponują to, co robi system, a nie jak to robi. Diagramy przypadków użycia pozostają w bliskim związku ze scenariuszami. Scenariusz to przykład tego, co się dzieje, kiedy ktoś wchodzi w interakcję z systemem. Oto scenariusz dla kliniki medycznej:

"Pacjent dzwoni do kliniki, aby umówić się na coroczne badania. Recepcjonistka znajduje najbliższy wolny termin w książce przyjęć i wyznacza badanie na tę datę".

Przypadek użycia to podsumowanie scenariuszy pojedynczego zadania lub celu. Aktor to ktoś albo coś, co inicjuje zdarzenia związane z tym zadaniem. Aktor po prostu określa rolę, którą odgrywa człowiek lub obiekt. Rysunek poniżej przedstawia przypadek użycia Ustalanie terminu badania w klinice medycznej. Aktor to Pacjent. Połączenie między aktorem a przypadkiem użycia to skojarzenie komunikacyjne (w skrócie komunikacja).

Aktorzy to schematyczne sylwetki. Przypadki to owale. Komunikacje to linie łączące aktorów z przypadkami użycia. Diagram przypadków użycia to zbiór aktorów, przypadków użycia i ich komunikacji. Umieściliśmy przypadek Ustalanie terminu badania na diagramie z czterema aktorami i czterema przypadkami użycia. Zwróć uwagę, że jeden przypadek użycia może mieć wielu aktorów.

Diagramy przypadków użycia mają trzy zastosowania:

• Określanie funkcji (wymagań). Nowe przypadki użycia często generują nowe wymagania, kiedy system jest analizowany i projekt przybiera coraz wyraźniejszy kształt.

• Komunikacja z klientami. Prostota notacji sprawia, że diagramy przypadków użycia są dobrym sposobem porozumiewania się programistów z klientami.

• Generowanie przypadków testowych. Zbiór scenariuszy danego przypadku użycia może zasugerować sposoby testowania tych scenariuszy.

Więcej inrormacji na stronie http://bdn.borland.com/article/images/31863/usecase.html

Diagramy klas
Diagram klas przedstawia ogólną panoramę systemu, pokazując klasy i ich wzajemne relacje. Diagramy klas są statyczne - pokazują, co wchodzi w interakcje, a nie co się dzieje podczas tych interakcji.

Poniższy diagram klas modeluje zamówienie z katalogu. Centralna klasa to Zamówienie. Z tą klasą związany jest Klient, który dokonuje zakupu, oraz Płatność. Są trzy rodzaje Płatności: Gotówka, Czek lub Kredyt. Zamówienie zawiera SzczegółyZam (pozycje transakcji), każdy z powiązaną Pozycją.

Notacja klas w języku UML to prostokąt podzielony na trzy części: nazwa klasy, atrybuty i operacje. Nazwy klasy abstrakcyjnych, takich jak Płatność, są pisane kursywą. Relacje między klasami są zilustrowane przez łączące je linie.

Nasz diagram klas zawiera trzy rodzaje relacji:

• Skojarzenie - związek między instancjami dwóch klas. Skojarzenie dwóch klas zachodzi wtedy, gdy jedna klasa musi wiedzieć o drugiej, aby wykonywać swoje zadania. Na diagramie skojarzeniem jest linia łącząca dwie klasy.

• Agregacja - skojarzenie, w którym jedna z klas należy do kolekcji. Agregacja jest zakończona rombem wskazującym tę część, która zawiera całość. Na naszym diagramie Zamówienie ma kolekcję SzczegółyZam.

• Uogólnienie - łącze dziedziczenia, które wskazuje, że jedna klasa jest nadrzędna w stosunku do drugiej. Uogólnienie ma trójkąt wskazujący klasę nadrzędną. Płatność to klasa nadrzędna klas Gotówka, Czek i Kredyt.

Skojarzenie ma dwa końce. Koniec może mieć nazwę roli, która wyjaśnia naturę skojarzenia. Na przykład SzczegółZam jest pozycją każdego Zamówienia. Strzałka możliwości nawigacji pokazuje kierunek, w którym można przechodzić lub odpytywać skojarzenie. SzczegółZam można zapytać o Pozycję, ale nie odwrotnie. Strzałka informuje też, kto jest "właścicielem" implementacji skojarzenia; w tym przypadku, SzczegółZam ma Pozycję. Skojarzenia bez strzałek mają możliwości nawigacji dwukierunkowe.

Wielokrotność końca skojarzenia to dopuszczalna liczba instancji klasy skojarzonych z jedną instancją na drugim końcu. Wielokrotności są pojedynczymi liczbami albo zakresami liczb. W naszym przykładzie może być tylko jeden Klient na każde Zamówienie, ale Klient może mieć dowolną liczbę Zamówień.

Poniższa tabela opisuje najczęściej używane wielokrotności.

Wielokrotności	Znaczenie
0..1	Brak instancji lub jedna instancja. Notacja n . . m oznacza od n do m instancji.
0..* lub *	Bez ograniczenia liczby instancji (łącznie z brakiem instancji).
1	Dokładnie jedna instancja
1..*	Przynajmniej jedna instancja

Więcej informacji na stronie http://bdn.borland.com/article/images/31863/classdiagram.html

Każdy diagram klas zawiera klasy, skojarzenia i wielokrotności. Możliwości nawigacji i role to elementy opcjonalne, które zwiększają czytelność diagramu klas.

Pakiety i diagramy obiektów
Aby uprościć skomplikowane diagramy klas, możesz zgrupować klasy w pakiety. Pakiet to zbiór logicznie powiązanych elementów UML. Poniższy diagram to model biznesowy, na którym klasy zostały zgrupowane w pakiety.

Pakiety to prostokąty z małymi zakładkami na górze. Nazwa pakietu znajduje się na zakładce albo wewnątrz prostokąta. Strzałki z przerywanymi liniami to zależności. Jeden pakiet jest zależny od drugiego, jeśli zmiany w drugim pakiecie mogą wymusić zmiany w pierwszym.

Diagramy obiektów zamiast klas pokazują instancje. Przydają się do wyjaśniania drobnych elementów ze skomplikowanymi relacjami, zwłaszcza rekurencyjnymi.

Poniższy niewielki diagram klas pokazuje, że Wydział uniwersytetu może zawierać wiele innych Wydziałów.

Poniższy diagram obiektów konkretyzuje diagram klas, zastępując go rzeczywistym przykładem.

Każdy prostokąt na diagramie obiektów odpowiada pojedynczej instancji. Nazwy instancji na diagramach UML są podkreślone. Nazwy klas lub instancji mogą zostać pominięte na diagramach obiektów, pod warunkiem, że sens diagramu pozostaje jasny.

Diagramy sekwencji
Diagramy klas i obiektów to statyczne widoki modelu. Diagramy interakcji są dynamiczne. Opisują one, jak obiekty ze sobą współpracują. Diagram sekwencji to diagram interakcji, który szczegółowo pokazuje, w jaki sposób są wykonywane operacje - jakie komunikaty są wysyłane i kiedy. Czas upływa w miarę poruszania się w dół strony. Obiekty zaangażowane w operację są wymienione od lewej do prawej według tego, kiedy biorą udział w sekwencji komunikatów. Poniżej przedstawiono diagram sekwencji ilustrujący rezerwację hotelu. Obiektem inicjującym sekwencję komunikatów jest Okno rezerwacji.

Okno rezerwacji wysyła komunikat zarezerwuj() do SieciHoteli. Następnie SiećHoteli wysyła komunikat zarezerwuj() do Hotelu. Jeśli Hotel ma wolne pokoje, to dokonuje Rezerwacji i Potwierdzenia.

Każda przerywana pionowa linia to linia życia reprezentująca czas, przez który istnieje obiekt. Każda strzałka to przesłanie komunikatu. Strzałka zaczyna się od nadawcy, a kończy na pasku aktywności komunikatu na linii życia odbiorcy. Pasek aktywacji reprezentuje czas przetwarzania komunikatu. Na naszym diagramie Hotel wykonuje autowywołanie, aby sprawdzić, czy dysponuje wolnym pokojem. Jeśli tak, to Hotel tworzy Rezerwację i Potwierdzenie. Gwiazdka przy autowywołaniu oznacza iterację (w celu zagwarantowania, że pokój będzie wolny podczas każdego dnia pobytu w hotelu). Wyrażenie w nawiasie kwadratowym, [ ], to warunek.

Diagram zawiera notę z objaśnienami, czyli tekst w prostokącie z zagiętym rogiem. Noty można umieszczać na wszystkich rodzajach diagramów UML.

Więcej informacji na stronie http://bdn.borland.com/article/images/31863/state.html

Diagramy współpracy
Diagramy współpracy to również diagramy interakcji. Dostarczają tych samych informacji co diagramy sekwencyjne, ale skupiają się na rolach obiektów, a nie na czasach przesyłania komunikatów. Na diagramie sekwencyjnym role obiektów są wierzchołkami, a komunikaty - liniami łączącymi wierzchołki.

Prostokąty opisujące rolę obiektu są oznaczone nazwami klas lub obiektów (albo obiema nazwami). Nazwy klas są poprzedzone dwukropkiem ( : ).

Każdy komunikat na diagramie współpracy ma numer sekwencji. Komunikaty najwyższego poziomu mają numer 1. Komunikaty na tym samym poziomie (wysyłane podczas tego samego wywołania) mają ten sam przedrostek dziesiętny oraz przyrostki 1, 2 itd. w zależności od tego, kiedy występują.

Diagramy stanów
Obiekty cechują się zachowaniami i stanem. Stan obiektu zależy od jego bieżącej aktywności lub warunków. Diagram stanów pokazuje możliwe stany obiektu oraz przejścia, które powodują zmianę stanu.

Nasz przykładowy diagram modeluje logowanie się do sieciowego systemu bankowego. Logowanie składa się z wprowadzenia prawidłowego numeru PESEL oraz osobistego identyfikatora i przedłożenia tych informacji do zatwierdzenia.

Logowanie można rozłożyć na cztery nienakładające się stany: Pobieranie PESEL, Pobieranie PIN, Weryfikowanie i Odrzucanie. Z każdego stanu wynika pełny zbiór przejść, które określają następny stan.

Stany to zaokrąglone prostokaty. Przejścia to strzałki wiodące od jednego stanu do drugiego. Zdarzenia lub warunki wyzwalające przejścia są zapisane obok strzałek. Nasz diagram zawiera dwa autoprzejścia, jedno przy stanie Pobieranie PESEL, a drugie przy stanie Pobieranie PIN. Stan początkowy (czarne kółko) to atrapa, która zapoczątkowuje akcję. Stany końcowe są również atrapami, które finalizują akcję. Akcję, która występuje w wyniku zdarzenia lub warunku, wyraża się w postaci /akcja. Kiedy obiekt znajduje się w stanie Weryfikacji, nie czeka, aż zewnętrzne zdarzenie wyzwoli przejście. Zamiast tego wykonuje pewną operację. Wynik tej operacji określa jego następny stan.

Więcej informacji na stronie http://bdn.borland.com/article/images/31863/state.html#State

Diagramy aktywności
Diagram aktywności to w gruncie rzeczy fantazyjny diagram przepływu. Diagramy aktywności i diagramy stanów są powiązane. Diagram aktywności skupia się na obiekcie przechodzącym pewien proces (albo na procesie traktowanym jak obiekt), natomiast diagram stanów skupia się na operacjach związanych z jednym procesem. Diagram aktywności pokazuje wzajemne zależności między tymi operacjami.

Do celów naszego przykładu wykorzystaliśmy następujący proces:

"Pobieranie pieniędzy z konta bankowego za pomocą bankomatu".

Trzy klasy zaangażowane w tę operację (osoby itp.) to Klient, Bankomat i Bank. Proces zaczyna się od czarnego kółka na górze i kończy na czarno-białym kółku na dole. Operacje to zaokrąglone prostokąty.

Diagramy aktywności można dzielić na tory obiektów. Tory określają, który obiekt jest odpowiedzialny za daną aktywność. Od każdej aktywności odchodzi przejście, łącząc ją z kolejną aktywnością.

Przejście może rozgałęziać się na dwa lub więcej wzajemnie wykluczających się przejść. Wyrażenia sprawdzające (w nawiasach kwadratowych [ ]) opisują przejścia wychodzące z rozgałęzienia. Rozgałęzienie i jego późniejsze scalenie, które wskazuje koniec rozgałęzienia, pojawiają się na diagramie jako puste romby.

Przejście może rozwidlać się na dwie lub więcej równoległych aktywności. Rozwidlenie i późniejsze połączenie wątków wychodzących z rozwidlenia jest przedstawione na diagramie jako grube poziome lonie.

Diagramy komponentów i wdrożeń
Komponent to moduł kodu. Diagramy komponentów są fizycznymi odpowiednikami diagramów klas. Diagramy wdrożeń pokazują fizyczną konfigurację oprogramowania i sprzętu.

Poniższy diagram wdrożenia pokazuje związek między komponentami programowymi i sprzętowymi związanymi ze sprzedażą nieruchomości.

Fizyczny sprzęt składa się z węzłów. Każdy komponent należy do węzła. Komponenty są przedstawione jako prostokąty z dwoma zakładkami w lewym górnym rogu.

---