Przegląd diagramów języka UML
|
|
|
Artykuł jest krótkim i ogólnym przewodnikiem po diagramach UML-a, uwzględniającym zmiany tego tego języka, które zostały wprowadzone w wersji 2.0.
Przedstawione jest przeznaczenie każdego z dostępnych diagramów, podany jest prosty przykład oraz opis najważniejszych elementów diagramu.
Artykuł jest przeznaczony dla początkujących użytkowników UML-a lub osób, które go znają i chciałyby poznać nowe elementy UML-a 2.0 albo mieć po ręką skrótowy opis diagramów.
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ądź 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 <<Actor>> oraz elipsy, które zawierają krótki opis przypadku użycia. Aktorzy (czyli użytkownicy) systemu mogą być ludź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 (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óź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ądź 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ądź 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ądź 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). Łą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 przeglądu interakcji (interaction overview)
|
Diagram przeglądu interakcji (interaction overview) (UML 2.0)
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.
|
|
Podsumowanie i dodatkowe informacje
|
Use Case diagram
Diagram przypadków użycia
Class diagram
Diagram klas
Package diagram
Diagram pakietów
Object diagram
Diagram obiektów
Composite Structure diagram
Diagram strukturalny
Component diagram
Diagram komponentów
Deployment diagram
Diagram wdrożenia
Activity diagram
Diagram akywności (czynności)
State Machine diagram
Diagram maszyny stanowej
Statechart diagram(diagram stanów)
Sequence diagram
Diagram przebiegu (sekwencji)
Communication diagram
Diagram komunikacji
Collaboration diagram (diagram współpracy)
Timing diagram
Diagram przebiegów czasowych
Interaction Overview diagram
Diagram przeglądu interakcji
|