Wstęp
UML jest zunifikowanym, standardowym językiem
służącym do modelowania systemów
informatycznych (i nie tylko). Architekt,
projektant czy programista używają diagramów
UML-a w podobny sposób jak murarz bądz

elektryk używają planu architektonicznego
budynku. Abstrakcyjny, utworzony na papierze,
model pozwala podkreślić te elementy przyszłego
oprogramowania (albo budynku), które są
najistotniejsze dla jego funkcjonowania.
Efektem tego jest istnienie wielu diagramów UML-
owych; tak jak inaczej na dom patrzy murarz,
elektryk, hydraulik, właściciel to i podobnie
innego punktu widzenia na system informatyczny
potrzebuje analityk, projektant, programista,
osoba odpowiedzialna za QA, autor dokumentacji
czy wreszcie klient  odbiorca oprogramowania.
W wersji 1.4 UML-a było osiem diagramów plus
dwa, które były używane bardzo często, ale
 nieoficjalnie : diagram pakietów i obiektów. W
wersji 2.0 pojawiły się trzy zupełnie nowe.
Poniżej przyjrzymy się kolejno im wszystkim,
poznamy obszary ich stosowania i najważniejsze
elementy.
Diagram przypadków użycia i diagram klas
Diagram przypadków użycia
Diagram przypadków użycia opisuje system z punktu widzenia użytkownika,
pokazuje co robi system, a nie jak to robi. Diagram ten sam w sobie zazwyczaj nie
daje nam zbyt wielu informacji, dlatego też zawsze potrzebna jest do niego
dokumentacja w postaci dobrze napisanego przypadku użycia. Przypadki użycia są
bardzo ważnym narzędziem zbierania wymagań. Diagramy przypadków użycia,
mimo swojej prostoty, są bardzo przydatne, gdyż tworzą swojego rodzaju spis
treści dla wymagań modelowanego systemu.
Na diagramie widzimy aktorów, reprezentowanych przez ludziki lub prostokąty
oznaczone tzw. stereotypem <> oraz elipsy, które zawierają krótki opis
przypadku użycia. Aktorzy (czyli użytkownicy) systemu mogą być ludz
mi lub
zewnętrznymi systemami. W tym drugim przypadku warto je oznaczać używając
notacji prostokątnej. Każdy przypadek użycia jest powiązany z jednym lub wieloma
aktorami, ciągła linia ze strzałką oznacza, że pewien aktor jest szczególnym
przypadkiem innego (szef sprzedaży jest także sprzedawcą). Relacja include
między przypadkami użycia informuje nas o tym, że jeden przypadek użycia
zawiera w sobie inny.
Diagram klas
Diagram klas jest ściśle powiązany z projektowaniem obiektowym systemu
informatycznego lub wręcz bezpośrednio z jego implementacją w określonym
języku programowania. Elementami tego diagramu są klasy, reprezentowane przez
prostokąty, które mogą zawierać informację o polach i metodach klasy. Zobaczmy
jak to wygląda w przypadku prostego modelu biblioteki:
Związki pomiędzy klasami są oznaczane liniami, które mogą, opcjonalnie, mieć
strzałkę wskazującą kierunek relacji. Końce związków mogą także być oznaczone
krotnościami: mówią one o tym, ile obiektów danej klasy może brać udział w danej
relacji. Na przykład istnieje jeden katalog ale może się nim posługiwać dowolna
liczba pracowników biblioteki (co oznaczamy 0...*). Inną ciekawą relacją pokazaną
na diagramie jest agregacja między biblioteką i książką, oznaczona linią z rombem
po stronie biblioteki. Agregacja oznacza relację część-całość, przy czym romb jest
oczywiście po stronie całości.
Diagram komunikacji i diagram przebiegu
Diagram współpracy (diagram komunikacji od UML 2.0)
Diagram współpracy jest jednym z czterech diagramów interakcji. Używamy go po
to, żeby zobrazować dynamikę systemu  wzajemne oddziaływanie na siebie
obiektów oraz komunikaty, jakie między sobą przesyłają.
Linie, jak zwykle, oznaczają związki między obiektami (prostokąty), strzałki
wskazują kierunki przesyłania określonych komunikatów, a numery ich kolejność.
Warto zwrócić uwagę na to, że akurat w tym konkretnym przypadku diagram UML-a
został użyty do tego, aby przedstawić pewien element działania biblioteki z bardzo
ogólnego punktu widzenia (np. dyrektora biblioteki). Dlatego też związki i
komunikaty między obiektami mogą się znacznie różnić od tego, co zrobi póz
niej
programista implementując system, tak, by był on łatwy w utrzymaniu i
rozbudowie.
Diagram przebiegu (sekwencji)
Analogiczną informację do diagramu komunikacji zawiera drugi z diagramów
interakcji, diagram przebiegu. Diagram komunikacji koncentrował się na
zobrazowaniu współpracy między obiektami, teraz chcemy pokazać kolejność
przesyłania komunikatów i czas istnienia obiektów.
Czas na diagramie płynie w dół; prostokąty narysowane wzdłuż przerywanej linii
oznaczają czas życia obiektu, z którego wychodzi linia.
Diagram stanów i diagram aktywności
Diagram stanów (diagram maszyny stanowej w UML 2.0)
Diagramy interakcji mówiły nam o zachowaniu obiektów, diagram stanów z kolei
służy do tego, by pokazać w jakich stanach mogą być obiekty. Poniżej widzimy
diagram stanów obiektu dane:
Dane mogą znajdować się w różnych stanach, które są oznaczone zaokrąglonymi
prostokątami. Linie ze strzałkami oznaczają przejścia między stanami. Na
diagramie widzimy także przypadek, kiedy istnieją dwie alternatywne drogi
przejścia między stanami. Rozwidlenie, podobnie jak scalenie dwóch ścieżek
przebiegu zmian stanów jest zaznaczone na diagramie pogrubioną poziomą kreską.
Diagram aktywności (czynności)
Diagram aktywności jest pewną mutacją diagramu stanów, z tą różnicą, że diagram
aktywności skupia się raczej na opisaniu jakiegoś procesu, w którym uczestniczy
wiele obiektów, zaś diagram stanów pokazuje, jakie są możliwe stany konkretnego
obiektu. Diagram aktywności jest bardzo dobrym narzędziem, gdy chcemy
przedstawić odpowiedzialność obiektów w ramach jakiegoś procesu.
Na diagramie zaokrąglone prostokąty reprezentują konkretne zadania, które
powinien wykonać system (bądz
jego elementy), rombami zaznaczamy miejsca, w
których są podejmowana decyzje, wynikające z efektów wykonania jakiegoś
zadania. Podobnie jak na diagramie stanów (maszyny stanowej) pogrubione
poziome linie oznaczają miejsca, w których pewne czynności wykonywane są
jednocześnie. W naszym przypadku system komputerowy może sprawdzać, czy
dana książka jest dostępna i czy dana osoba ma prawo ją wypożyczyć.
Prostokąt z zagiętym rożkiem oznacza element UML-a, który może wystąpić na
dowolnym diagramie  notatkę. Notatka służy do tego, aby przekazać jakieś
informacje, które tłumaczą bądz
precyzują znaczenie jakiegoś elementu (lub jak to
się czasem mówi, artefaktu) diagramu
Oczywiście modelując rzeczywisty system należałoby określić jakie systemy są
odpowiedzialna za każde z działań, trzeba by też zadbać o to, żeby nie było
wątpliwości, że wysłanie książki następuje tylko wtedy, gdy jest ona zarówna
dostępna jaki i osoba chcąca ją wypożyczyć ma do tego prawo.
W tym miejscu warto zrobić następującą uwagę. UML w pewnym sensie nie jest
kompletny  nie zawsze udaje się modelować przy jego pomocy każdy aspekt
tworzonego systemu. Innymi słowy nie zawsze uda się osiągnąć zależność jeden do
jednego między kodem a diagramem. Stąd też pojawiają się pokusy, aby rozszerzyć
UML tak, by można było z niego generować gotową aplikację. Warto jednak
pamiętać, że UML jest językiem modelowania, a model z założenia nie jest
dokładną kopią modelowanego obiektu, lecz takim jego obrazem, który pozwala
poznać jego najistotniejsze elementy.
Trzeba pamiętać zatem o tym, aby diagramom UML-owym towarzyszyła
odpowiednia dokumentacja, która będzie zawierała istotne informacje, które nie
są widoczne na diagramie.
Diagram pakietów i diagram komponentów
Diagram pakietów
Diagram pakietów służy do tego, by uporządkować strukturę zależności w systemie,
który ma bardzo wiele klas, przypadków użycia itp. Przyjmujemy, że pakiet
zawiera w sobie wiele elementów, które opisują jakieś w miarę dobrze określone
zadanie. Na diagramie umieszczamy pakiety i wskazujemy na zależności między
nimi. Dzięki temu dostajemy na jednym diagramie obraz całości, bądz
dużego
fragmentu, systemu.
Na powyższym diagramie widzimy poszczególne pakiety grupujące elementy
systemu (np. klasy) odpowiedzialne za konkretne zadania. Przerywane linie ze
strzałkami pokazują zależności między pakietami.
Diagram komponentów
Diagram komponentów robimy z podobnych powodów, co diagram pakietów 
chcemy podzielić system na prostsze elementy i pokazać zależności między nimi.
Diagram pakietów koncentrował się na podziale systemu z logicznego punktu
widzenia, diagram komponentów z kolei dzieli system na fizyczne elementy
oprogramowania: pliki, biblioteki, gotowe, wykonywalne programy itp.
Na diagramie mamy przedstawione komponenty systemu wraz z interfejsami, które
one udostępniają. Udostępniane interfejsy są zaznaczone kółkami, podczas gdy
interfejsy, których dany komponent wymaga do swojego działania, są oznaczone
półokręgiem  gniazdem. Na przykład DB Menadżer udostępnia interfejsy do różnych
baz danych, natomiast Aplikacja.exe wymaga wskazania takiego interfejsu.
Notacja kółko gniazdo (ball and socket), przy pomocy której możemy pokazać
połączenie dwóch komponentów poprzez interfejs została wprowadzona w UML 2.0,
także na starszych diagramach jej nie spotkamy. Podobnie w UML 2.0 zmienił się
sposób oznaczania komponentów, obecnie reprezentuje je prostokąt z ideogramem
w prawym górnym rogu, dawniej komponent był oznaczany elementem, który stał
się w wersji 2.0 ideogramem.
Diagram strukturalny (composite structures) (UML
2.0)
Diagram strukturalny pojawił się w UML wersji 2.0. Jest przeznaczony do tego, by
modelować współpracę klas, interfejsów, komponentów, które są zaangażowane w
pewne zadanie. Diagram ten jest nieco podobny do diagramu klas, z tą różnicą, że
diagram klas przedstawia statyczny obraz fragmentu systemu, a diagram
strukturalny obrazuje elementy systemu wykonujące wykonujące wspólne zadanie,
typowe sposoby użycia elementów systemu, związki między tymi elementami,
które może być trudno przedstawić na innych diagramach.
Zobaczmy, jak można efektywnie wykorzystać diagram strukturalny.
Na diagramie poniżej widzimy typowy sposób przedstawienia związku między
fakturą a jej częściami:
Linie z wypełnionymi rombami na końcach oznaczają kompozycję. Kompozycja,
podobnie jak agregacja, oznacza relację część-całość między elementami
diagramu, tylko, że w przypadku kompozycji zniknięcie całości automatycznie
oznacza zniknięcie jej części.
Diagram ten może w zupełności wystarczyć, jednak ma on pewną wadę. Może się
okazać, że wcale nie chcemy, aby Naglowek i Dane były oddzielnymi klasami 
chcemy tylko podkreślić fakt, że Faktura składa się z takich części jednak bez
potrzeby specyfikowania detali. Właśnie w takim przypadku pomocny jest diagram
strukturalny:
Faktura jest w tym przypadku modelowana jako klasa, zaś Naglowek i Dane jako
części (parts w terminologii UML 2.0). A
ącznik (connector w UML 2.0) pokazuje
związek między częściami, krotności mówią nam, że każda faktura ma jeden
nagłówek i co najmniej jedno pole z danymi (reprezentujące np. pojedynczy
towar).
Inny sposób pokazania związku strukturalnego kilku klas można osiągnąć używając
elementu współpracy (collaboration):
lub, jeśli ktoś woli inną notację:
Elipsa narysowana przerywaną linią oznacza element współpracy, z którym
połączone (lub wewnątrz którego leżą) współdziałające klasy.
Innym możliwym zastosowaniem diagramu strukturalnego jest połączenie jego z
diagramem przypadku użycia, który jest przez niego realizowany:
Widzimy, że diagram przypadku użycia reprezentujący zapisanie się na kurs jest
realizowany przez klasy połączone w jedną strukturę. Taki zapis jest o wiele
czytelniejszy od wcześniej stosowanego łączenia klas z przypadkiem użycia.
Diagram opisu interakcji (interaction overview)
Diagram ten, podobnie jak poprzedni, jest nowością w UML-u. Jego pojawienie się
wywołało nieco zamieszania, gdyż nie do końca jest jasne kiedy i jak ten diagram
stosować. Jest on swego rodzaju połączeniem diagramu aktywności i diagramu
przebiegu (lub innego diagramu pokazującego dynamikę systemu). Zadaniem tego
diagramu jest wizualizacja współpracy ze sobą diagramów interakcji.
Diagram przeglądu interakcji ma notację bardzo podobną do notacji diagramu
aktywności (czynności), z tą różnicą, że zaokrąglone prostokąty, które
reprezentowały zadania wykonywane przez system, są zastąpione przez zwykłe
prostokąty, które mogą mieć dwie postacie:
ż Prostokąt zawiera jakiś diagram interakcji  diagram współpracy
(komunikacji), diagram przebiegu, diagram przebiegów czasowych lub inny
diagram przeglądu interakcji.
ż Prostokąt zawiera odnośnik do już istniejącego diagramu interakcji.
Obecność odnośnika jest zaznaczona słowem ref w lewym górnym rogu diagramu
Obie możliwości możemy zobaczyć na poniższych diagramach:
W drugim przypadku kompletne diagramy przebiegu są zastąpione odnośnikami
(ref)
Czas pokaże w jaki sposób i jak często w praktyce będzie wykorzystywany ten
diagram. Wielu specjalistów od UML-a (np. Martin Fowler, autor UML Distilled) jest
sceptycznych co do faktycznej przydatności tego diagramu.
Diagram przebiegów czasowych i diagram
wdrożenia
Diagram przebiegów czasowych (UML 2.0)
Diagram przebiegów czasowych jest nowym diagramem interakcji wprowadzonym
w UML 2.0. Jego pojawienie ucieszyło na pewno wszystkich tych, którzy zajmują się
projektowaniem systemów czasu rzeczywistego czy aplikacji, których działanie jest
powiązane z zewnętrznymi urządzeniami.
Diagram przebiegów czasowych obrazuje zachowanie obiektu z naciskiem na
dokładne określenie czasu, w którym obiekt jest poddawany jakimś zmianą lub sam
wykonuje jakieś działanie.
Powyżej widzimy przykładowy diagram przebiegów czasowych. Są dostępne dwie
notacje: czasowa (wyżej) i zadaniowa (niżej), w obu przypadkach diagram ma
oczywiście to samo znaczenie.
Diagram wdrożenia
Diagram wdrożenia pokazuje, jak będzie wyglądało wdrożenie i konfiguracja
naszego oprogramowania.