Patryk Matlak - Blog

Streszczenie

UML (ang. Unified Modeling Language) – to język modelowania systemów, znajdujący zastosowanie nie tylko w informatyce. Jest to standard umożliwiający w jednolity sposób zamodelować systemy różnej wielkości, a w przypadku ogromnych, wielowarstwowych systemów, składających się z setek  komponentów, zastosowanie tego języka  modelowania przynosi ważną  korzyść: łatwość zarządzania projektem. Na całość zamodelowanego systemu składają się różnorakie diagramy opisujące różne aspekty programu. Postaram się w prosty sposób opisać dwa, jedne z najważniejszych w modelowaniu diagramy: diagramy sekwencji oraz komunikacji. Oba są częścią grupy diagramów – tak zwanych diagramów interakcji. W rzeczywistości oba diagramy nie różnią się między sobą zbyt wiele, co jest często dylematem osób modelujących który diagram byłby w danej sytuacji lepszym rozwiązaniem do zaprezentowania w jaki sposób przebiega interakcja pomiędzy uczestnikami.

1. Wstęp

Opisane tutaj diagramy sekwencji oraz komunikacji są tylko częścią tego co kryje się pod terminem UML. Dlatego w kolejnych rozdziałach są opisywane jedynie te elementy które bezpośrednio związane są tymi elementami języka UML. Dlatego na początku należy się wyjaśnienie, tego co nie jest objęte w następnych rozdziałach. Na rysunkach przedstawiam wyłącznie diagramy sekwencji oraz komunikacji. Na niektórych z nich można zobaczyć taki element jak notatka – jest to prostokąt z zagiętym prawym, górnym rogiem, zawierający komentarze. Do tworzenia tych diagramów użyłem dwóch narzędzi: „Dia” – oparte na GTK+/GNOME narzędzie obsługujące m.in. UML (strona projektu: http://www.gnome.org/projects/dia/) oraz narzędzie typu IDE (zintegrowane środowisko programistyczne) o nazwie „NetBeans IDE” (strona projektu: http://www.netbeans.org/). Oba programy są darmowe oraz dostępne do ściągnięcia ze stron projektu. Pochyłą czcionką w tekście uwzględniłem ważne informacje, natomiast ciągi znaków pisane czcionka o równej szerokości są częścią kodu.

2. Diagramy sekwencji

Diagramy sekwencji  przedstawiają przepływ komunikatów pomiędzy partiami systemu w czasie. Celem przedstawienia systemu na diagramie sekwencji jest zaprezentowanie kolejności interakcji  pomiędzy uczestnikami wykonywanej czynności. Atutem tak zaprezentowanego modelu jest wydajne przedstawianie informacji na temat kolejności w jakiej, te informacje przepływają.
Podstawowymi elementami na diagramach sekwencji są uczestnicy. Reprezentują oni elementy systemu, które komunikują się między sobą w celu zapewnienia poprawnego zakończenia czynności. W UML 1.x  uczestnicy byli reprezentowani jako obiekty, w wersji 2.0, która jest bardziej ogólnym modelowaniem, uczestnik jest częścia komunikującą się. Uczestników układa się w pozycji poziomej – każdy oddzielny uczestnik sekwencji nie może występować w tej samej kolumnie diagramu, natomiast wszyscy mogą być ułożeni obok siebie. Od każdego uczestnika ciągnie się w dół linia życia danego elementu. Która może być zakończona znakiem krzyżyka, co oznaczałoby usunięcie uczestnika. Przykład okładu uczestników zaprezentowałem na rysunku 1.

Rys 1.    Podstawowa postać diagramu sekwencji

Jest wiele sposobów nadania nazw uczestnikom, wszystkie jednak muszą być jednak utworzone według standardowego formatu:

Nazwa [selektor] : nazwa_klasy ref dekompozycja

Nadawanie nazw zależy od autora diagramu. W zależności co dany uczestnik powinien zawierać, mogą oni przybierać różne nazwy, na przykład
1.    Uzytkownik – zawiera tylko nazwę, jednocześnie klasa nie jest do użytkownika przypisana.
2.    :klasaUzytkownika – zadeklarowanie jedynie klasy do jakiej uczestnik należy, nazwa jest dla projektującego w danym momencie nieznana.
3.    Użytkownik:klasaUzytkownika – w tym przypadku nazwa oraz klasa użytkownika została zadeklarowana.
4.    Użytkownik[0]:klasaUzytkownika – uczestnik jako element tablicy.
Oczywiście istnieje jeszcze wiele zapisów, z uwzględnieniem rodzajów fragmentów.
Jak przedstawia rysunek 2 „upływ” czasu jest skierowany w dół, to znaczy że akcja zaczyna się na samej górze diagramu i biegnie w dół, po drodze występują w uporządkowanej kolejności komunikaty pomiędzy elementami systemu. Ważne jest to że czas nie przestawia wcale jak długo zdarzenie jest wykonywane, tylko w jakiej kolejności komunikaty występują. Komunikaty są też nazywane sygnałami, zwłaszcza wśród projektantów systemów czasu rzeczywistego. Przesył komunikatów jest przedstawiany za pomocą strzałek, kierunek oznacza do kogo jest adresowany komunikat.
 
Każdy komunikat posiada sygnaturę, czyli opis komunikatu. Przybiera ona formę:

Atrybut = nazwa_komunikatu (argumenty) : typ_zwracany

 

Rys 2.    Czas na diagramie sekwencji

Strzałki komunikatów mogą przybierać różne formy, w zależności od tego jaki rodzaj strzałki jest potrzebny. Wyróżniamy:
1.    komunikaty synchroniczne, oznaczone strzałki mają zapełniony grot i są rysowane linią ciągłą. Są one używane, gdy nadawca wysyła sygnał do adresata i oczekuje na odpowiedź, oznaczoną kolejnym rodzajem strzałek:
2.    komunikat zwrotny – oznaczany przerywaną linią z końcówka o kształcie litery V lub pełną (w zależności od stosowanego narzędzia)
3.    komunikaty asynchroniczne – występują w momencie gdy nadawca nie ma zamiaru czekać na odpowiedź, i kontynuuje swoje działanie. Strzałki takiego komunikatu są rysowane linią ciągłą ze strzałką o kształcie litery V.
4.    komunikaty tworzenia uczestnika – używane do zadeklarowania utworzenia użytkownika, w momencie gdy jest nam on potrzebny do dalszego działania. Strzałka jest rysowana podobnie jak komunikat zwrotny - linią przerywaną zakończoną grotem o kształcie litery V lub pełnym, posiada sygnaturkę <>, czyli komunikat tworzenia elementu.
5.    komunikat usuwania uczestnika – w parze z komunikatem tworzenia uczestnika. Dzięki niemu możliwe jest usuwanie elementu z sekwencji, jeżeli takowy nie będzie już potrzebny. Wygląda on identycznie jak strzałka komunikatu synchronicznego, z tą różnicą, że na końcu umieszczony jest znak krzyżyka, informujący że element jest usunięty.
Rysunek 3 przedstawia listę wszystkich rodzajów komunikatów. Każdy komunikat może być używany w zależności od sytuacji jaką osoba modelująca chce przedstawić na diagramie sekwencji. Uczestnik może wysyłać komunikat do samego siebie, co zostało zaprezentowane na rysunku 4. Najczęstszym używanym komunikatem jest komunikat synchroniczny, lecz asynchroniczne stają się bardzo przydatne w niejednej sytuacji, gdy chcemy zaprezentować że dany element nie jest zależny od innych, często taka sytuacja występuje w systemach czasu rzeczywistego.

Rys 3.    Rodzaje strzałek komunikatów

Rys 4.    Strzałka komunikacji kierowana do samego siebie

Na liniach życia znajdują się tak zwane belki aktywacji – ich istnienie początkują napływy komunikatów. Belki aktywacji nie są wymagane, ponieważ w rozbudowanych diagramach mogą niepotrzebnie przeszkadzać i utrudniać odczytywanie, jednakże stosowanie ich jest zalecane. Belka aktywacji przybiera postać prostokąta biegnącego wzdłuż linii życia, tak jak już to było zaprezentowane na rysunkach 1 i 2.
W diagramach sekwencji występuje takie zjawisko jak zagnieżdżanie, polegające na tym że komunikaty mogą występować jako zagnieżdżenie innych komunikatów. Wysłanie jednego komunikatu do uczestnika2 może spowodować wysłanie kolejnego komunikatu przez uczestnika2 do innego uczestnika. Przykład zagnieżdżenia zaprezentowałem na rysunku 5. Oczywiście głębokość zagnieżdżenia nie jest ograniczona i zależy od tego w jaki sposób system ma być zbudowany. Jeżeli pierwszy komunikat będzie wysłany jako synchroniczny to oczywiście będzie musiał czekać aż wszystkie zagnieżdżone w nim komunikaty zostaną dokończone i komunikat zwrotny zostanie odesłany.

Rys 5.    komunikaty zagnieżdżone

W UML 2.0 wprowadzono fragmenty sekwencji, pozwalające na grupowanie regionów na diagramie. Wcześniejsze wersje UML’a nie posiadały elementu grupującego fragmenty diagramu co powodowało że diagramy sekwencji robiły się z czasem ogromne i trudne do odczytywania, dlatego w wersji 2.0 z pomocą przybyły fragmenty sekwencji. Graficzna reprezentacja fragmentów sekwencji to prostokąty, posiadający operatora fragmentu sekwencji w górnym prawym rogu. Rysunek 6 przedstawia diagram z użyciem fragmentu sekwencji.

Rys 6.    Diagram z użyciem fragmentu sekwencji

 Fragment sekwencji nakłada się na region diagramu, w którym zdefiniowana jest jego własna interakcja. Przez to fragment sekwencji może być oddzielnie przedstawiany, na zewnątrz głównego diagramu. Nic nie stoi na przeszkodzie, ażeby fragment sekwencji zawierał inne fragmenty sekwencji w dowolnej ich ilości. Jeżeli sytuacja tego wymaga, diagram jest na tyle skomplikowany, że przydatne jest pofragmentowanie go na mniejsze partie, dzięki temu prezentacja jest bardziej przejrzysta.
Zdefiniowano kilka rodzajów fragmentów:
1.    ref -  przypominający zależność <>, jest reprezentacją fragmentu oddzielonego od głównego diagramu, może być zaprezentowany na oddzielnym diagramie, co więcej może być wykorzystywany wiele razy.
2.    assert – interakcja w nim zawarta musi za każdym razem zakończyć się powodzeniem, w przeciwnym razie zostanie wygenerowany wyjątek.
3.    loop – posiadający parametr – ilość powtórzeń – powtarza zawarte w nim interakcje określoną w parametrze ilość razy. Podobne do pętli for(…) w językach programowania.
4.    alt – podobny do instrukcji if(…) else w językach programowania. Przyjmuje jako parametry – [warunki] oraz [else] dla niespełnionych warunków.  Wykonuje instrukcje tego warunku, które jako pierwszy przyjmie wartość true.
5.    opt – przyjmuje warunek, którego spełnienie gwarantuje wykonanie interakcji zawartych we fragmencie. Podobny do instrukcji if(…) gdzie nie ma warunku else.
6.    break – Gdy tylko wystąpi w nim interakcja, następuje wyjście z każdej zawierającej go interakcji, np. fragmentu typu loop.
7.    neg – interakcje w nim zawarte nie będą wykonywane, do czasu gdy mamy pewność że będą mogły być bezpiecznie usunięte.
8.    par – zawarte w nim instrukcje mogą być wykonywane równolegle.
9.    region – wewnątrz takiego fragmentu obszar interakcji oznaczony jest jako krytyczny.
Dzięki fragmentom sekwencji możliwe jest tworzenie bardzo dokładnych diagramów sekwencji. Jeżeli ktoś chce otrzymać widok diagramu bardzo przeglądowy, otrzymuje główny diagram z zawartymi w nim fragmentami sekwencji odwołującymi się do bardziej szczegółowych diagramów. Jednocześnie zarządzanie takim diagramem jest prostsze i wygodniejsze.

3. Diagramy komunikacji

Pewną alternatywą dla diagramów sekwencji są diagramy komunikacji. Jak już wcześniej wspominałem, są one do siebie podobne. Diagramy sekwencji mają na celu przedstawienie kolejności zdarzeń jakie zachodzą pomiędzy elementami systemu. Celem diagramów komunikacji jest zaprezentowanie którzy uczestnicy są połączeni ze sobą. Ważne tutaj jest które elementy systemu wiąże węzeł komunikacyjny bezpośredni, które łączą się pośrednio, a które się nie łączą wcale.
Elementami istotnymi w tych diagramach są uczestnicy, to w końcu je będziemy przedstawiać na diagramie jako główne składniki diagramu. Sam wygląd uczestników na diagramie nie różni się niczym od wyglądu uczestników na diagramie sekwencji. Ilustrowane są za pomocą prostokątów w których umieszczana jest nazwa oraz klasa. Połączenie komunikacyjne jest pojedynczą linią ciągłą, łączącą uczestników. Jak sama nazwa wskazuje połączenie komunikacyjne pozwala łączyć uczestników, którzy komunikują się ze sobą – niezbędne do przedstawienia kto z kim się komunikuje. Dla diagramu komunikacji nieważny jest układ uczestników, tak jak to miało miejsce na diagramach sekwencji. Uczestnicy mogą występować w dowolnym miejscu na diagramie, czy to obok innego uczestnika czy to pod nim. Trzeba jedynie pamiętać ażeby nie zagmatwać się przy ustawianiu elementów, gdy ich ilość jest duża, bo często w rezultacie, gdy ustawimy wszystkie połączenia, jakie między nimi zachodzą, diagram może wyglądem przypominać kłębek wełny i ciężko będzie odczytywać taki diagram.
Komunikaty obrazowane na diagramie komunikacji są strzałkami z wypełnionymi grotami. Są one skierowane od nadawcy do adresata i tak jak diagramy sekwencji posiadają identyczną sygnaturę w postaci:

Atrybut = nazwa_komunikatu (argumenty) : typ_zwracany

Jednak sama taka sygnatura nie wystarczy do oznaczenia komunikacji na diagramie komunikacji, ponieważ jak wiemy już, między dwoma uczestnikami może występować więcej niż tylko jeden sygnał, dlatego też ważne tutaj jest oznaczenie kolejności występowania komunikatów. Prosty diagram komunikacji został zilustrowany na rysunku 7.

Rys 7.    Prosty diagram komunikacji

 Oczywiście UML ma opracowany system tworzenia oznaczeń dla kolejno występujących sygnałów. Przypomnijmy sobie sytuacje z poprzedniego rozdziału, kiedy jeden komunikat wywoływał wysłanie kolejnego komunikatu (komunikaty zagnieżdżone). Tam nie było problemu w odróżnianiu który sygnał występuje po którym. W diagramach komunikacji używa się odpowiedniego schematu numerowania. Wygląda on tak: komunikat wysłany w następstwie odebrania przez element komunikat 1 zostaje oznaczony jako komunikat 1.1. Tak samo kolejne zagnieżdżone komunikaty będą kolejno numerowane jako 1.2, 1.3, 1.4, itd. Przykład zagnieżdżonych komunikatów na diagramie komunikacji zilustrowano na rysunku 8.

Rys 8.    Diagram komunikacji z zagnieżdżonymi sygnałami

Jeżeli zachodzi potrzeba wysłania wielu komunikatów naraz to na diagramie komunikacji wystarczy odpowiednio nadać oznaczenie literowe dla równoczesnych komunikatów, np. gdy zaszłaby potrzeba na rysunku 8 równoczesne wysłanie komunikatu 1 oraz  komunikatu 2, wystarczyłoby ich kolejność zaprezentować w następujący sposób:

1a.komunikat1(argumenty:typ), 1b.komunikat2(argumenty:typ)

Dla każdego kolejnego sygnału, wysyłanego równocześnie z tymi komunikatami wystarczy dodać kolejną literę alfabetu do nr kojności wysyłania (w tym przypadu 1a, 1b, 1c, 1d, itd.). Rysunek 9 przedstawia przykład komunikatów wysyłanych w tym samym czasie.
Przy modelowaniu systemu często zachodzi potrzeba wielokrotnego wysyłania jednego komunikatu. W diagramach komunikacji jest możliwe zamodelowanie takiej sytuacji. Przyjęło się że znak * będzie oznaczać ograniczenie iteracyjne, i tak – jeżeli chcemy zaznaczyć że dany sygnał jest powtarzany 10 razy stosujemy notację:

1.komunikat() *[i=0..9]

Oczywiście znak „i” nie jest tutaj narzucany przez UML jako wymóg, ma jedynie oznaczać bieżący element iteracji.

Rys 9.    Komunikaty równoczesne

Podobnie ma się wysyłanie sygnału, w momencie spełnienia określonego warunku. Często musimy zamodelować sytuację która jest inicjowana po spełnieniu pewnego warunku, taki przypadek w diagramie komunikacji można zaprezentować w następujący sposób:

1.komunikat() [warunek = true]

Tak zaprezentowana sygnaturka komunikatu będzie wskazywać, że komunikat będzie wysłany tylko wtedy gdy warunek będzie miał wartość true.
Ostatnią kwestią przeze mnie opisywaną jest sytuacja gdzie uczestnik wywołuje komunikat do samego siebie. Jak już opisywałem tą sytuację w poprzednim rozdziale, taka sytuacja może zajść a nawet zachodzi nie żadko. Rysunek 4 ilustrował jak wygląda ta kwestia w diagramach sekwencji. W diagramach komunikacji jest to po prostu poprowadzenie linii komunikacji do samego siebie. Przypadek ten został zilustrowany na rysunku 10.

 

Rys 10.    Uczestnik wysyła komunikat do samego siebie

4. Podsumowanie

Język modelowania UML jest bardzo szerokim pojęciem, nie tylko ograniczającym się do diagramów sekwencji oraz komunikacji, należących do grupy diagramów interakcji. Występuje jeszcze szereg diagramów, takich jak: diagramy aktywności wykorzystywane do modelowania procesów biznesowych czy diagramy klas opisujące rodzaje obiektów występujących w systemie. Ja postarałem się opisać w przystępny sposób jak funkcjonują diagramy sekwencji oraz diagramy komunikacji i mam nadzieje że przydadzą się komuś w poznawaniu tak popularnego języka modelowania jakim jest UML.

 

 

Utworzono na podstawie:
1.    Russ Miles, Kim Hamilton „UML 2.0 Wprowadzenie”, Wyd. Helion, 2007
2.    Witryna: http://pl.wikipedia.org/, hasło: UML