Znacie powiedzenie, że rysunek przedstawia więcej niż tysiące słów? Diagramy UML mają nie tylko tę zaletę. Często powtarza się jako główny walor ich zrozumiałość dla klienta. W odpowiedzi słychać czasem powątpiewanie. Ja zapytam tak – mieliście kiedyś przed sobą dziesiątki, setki wymagań zebranych z różnych źródeł – niekompletnych, niespójnych, stających ze sobą w sprzeczności? Model przedstawia wybrany aspekt jednoznacznie i kompletnie – pozwala odrzucić stosy zbędnych informacji, wskazuje brakujące! Nie każdy urodził się ze zrozumieniem UML. Jest to jednak standard, którego wystarczy się nauczyć, by używać dokładnie tak samo jak wszyscy inni na świecie! Zapraszam zatem Studentów, Wykonawców i Zamawiających Oprogramowanie do czytania i rysowania 🙂
Może jesteś studentem i po prostu potrzebujesz zaliczyć przedmiot? Nie potrzeba Ci zatem dodatkowej motywacji 😉
Jeśli pracujesz w firmie wytwarzającej oprogramowanie, może przemówią do Ciebie argumenty podyktowane przez praktykę? Co może dać Ci używanie UML?
- Uporządkuje informacje – będziesz mógł odrzucić stosy zbędnych informacji, łatwiej wychwycisz sprzeczności i braki, ponieważ UML zrobi z nimi porządek
- Skróci czas ustaleń z dociekliwym klientem – „No, dobrze, ale jak to ma działać?” – będziesz rzadziej słyszeć takie pytania, ponieważ UML przedstawi brakujący aspekt – Koniec z ciągłym dopracowywaniem opisów!
- Skróci czas dopytywania podczas programowania, testów wewnętrznych i akceptacyjnych – „Jak to ma działać?” – będziesz rzadziej słyszeć takie pytania, ponieważ UML pokaże im to w sposób jednoznaczny
- Pomyśli za Ciebie o tym, o czym Ty zapomniałeś – „O-o, tam jeszcze miał być taki użytkownik, taki podsystem, tych operacji będzie wiele, a tamte muszą być równoczesne!” – rzadziej będziesz wpadać w takie tarapaty, ponieważ UML przypomni Ci o tym, o czym nie napisałeś w skrótowej notatce albo obszernym swobodnym opisie wypowiedzi klienta
- Umożliwi świadome projektowanie zamiast lepienia całości z rozwiązań programistów – dzielenie się (zadaniami do oprogramowania) jest fajne, ale UML pokaże Ci jak można czerpać jeszcze większą radość (i spokój) robiąc to po zaprojektowaniu architektury
- Umożliwi rozwój starych systemów – ile razy spotkałeś się z sytuacją, że działający system trzeba było pisać od nowa, bo nie dało się zrozumieć kodu? Koniec z tym! – ponieważ UML pozwoli Ci opisać strukturę
- Da Ci siłę i swobodę – siłę wyrazu i swobodę wyboru, ponieważ z UML możesz wziąć tylko to, czego potrzebujesz
Czy coś przemawia właśnie do Ciebie?:)
Jeśli jesteś Zamawiającym oprogramowanie, być może męczy Cię współpraca z Wykonawcami, ponieważ:
- nie widać końca (może gubi się w Twoich licznych wymaganiach),
- nie możecie się porozumieć (nie potrafisz przedstawić, czego potrzebujesz, a Wykonawca wszystko rozumie po swojemu),
- dostajesz dokumentację, z której niewiele wynika i nie wiesz już co zamówiłeś, co to będzie robić i jak to będzie działać,
Zaskocz Wykonawcę! (i pomóż mu:) Zaproponuj UML – przeczytaj, co zawierają poszczególne diagramy i poproś o taki, na który pokaże to, na czym Ci zależy.
Zaczynamy!
Skąd się wziął UML? Ano stąd – http://www.uml.org/ – strony organizacji ustanawiającej standardy (OMG – Object Management Group). Ostatnią wersją (z sierpnia 2011 r.) jest UML 2.4.1 (http://www.omg.org/spec/UML/2.4.1/).
Mamy 13 diagramów UML. Niektóre z nich przedstawiają strukturę systemu, inne – zachowanie. Jest także podział zaproponowany przez P. Kruchtena 4+1 widoków (widok logiczny, konstrukcji, procesu, fizyczny, przypadków użycia).
A Ty jaką perspektywę chcesz przedstawić?
Diagramy struktury
Diagramy struktury przedstawiają architekturę modelu – klasy, obiekty, interfejsy i fizyczne komponenty a także powiązania i zależności tych elementów.
- Diagram pakietów przedstawia podział modelu na logiczne pojemniki lub pakiety i opisuje interakcję pomiędzy nimi na wysokim poziomie.
- Diagram klas lub struktury przedstawia podstawowe bloki, z jakich składa się model: typy i klasy używane do konstruowania pełnego modelu.
- Diagram obiektów przedstawia jak instancje elementów struktury są powiązane i wykorzystywane w czasie wykonywania programu.
- Diagram struktur złożonych przedstawia warstwy elementów struktury i skupia się na wewnętrznych detalach, budowie i powiązaniach.
- Diagram komponentów przedstawia model wysokiego poziomu lub bardziej złożonych struktur, zazwyczaj złożony z jednej lub większej liczby klas i dostarczających dobrze zdefiniowane interfejsy.
- Diagram wdrożenia przedstawia fizyczne rozmieszczenie komponentów w świecie rzeczywistym (oprogramowanie zainstalowane na maszynach).
Diagramy zachowania
Diagramy zachowania przedstawiają zachowanie i stany w modelu w czasie wykonywania programu. Pozwalają one śledzić, w jaki sposób system będzie zachowywał się w rzeczywistym środowisku oraz obserwować efekty operacji i zdarzeń.
- Diagram przypadków użycia przedstawia interakcje między użytkownikami a systemem, definiuje zachowanie, wymagania i ograniczenia.
- Diagram aktywności ma wiele zastosowań – od przedstawiania przepływu sterowania w programie po przechwytywanie punktów decyzyjnych i akcji w jakimkolwiek procesie.
- Diagram maszyny stanów przedstawia zmiany stanów obiektów systemu w czasie wykonywania programu.
- Diagram komunikacji przedstawia sieć przesyłania i sekwencje wiadomości lub komunikację między obiektami w czasie wykonania programu.
- Diagram sekwencji przedstawia sekwencje wiadomości przesyłanych między obiektami w zależności od czasu. Związany z diagramem komunikacji.
- Diagram przebiegów czasowych przedstawia zmiany stanów obiektów w zależności od czasu oraz sekwencje wiadomości, które zmieniają te stany. Łączy diagram sekwencji i stanów.
- Diagram przeglądu interakcji przedstawia interakcje elementów systemów w połączeniu z punktami decyzyjnymi i przepływem sterowania. Łączy diagram aktywności i sekwencji.
Model P. Kruchtena (4+1)
Widok logiczny
Dotyczy funkcjonalności, jakiej system dostarcza użytkownikowi.
Diagram klas
Diagram komunikacji
Diagram sekwencji
Widok konstrukcji (implementacji)
Perspektywa programisty i project maganera.
Diagram pakietów
Widok procesu
Przedstawia dynamikę, wyjaśnia procesy – jak system komunikuje się i działa w czasie, umożliwia przedstawienie współbieżności.
Diagram aktywności
Widok fizyczny (wdrożenia)
Punkt widzenia inżyniera. Topologia, warstwa fizyczna, fizyczne powiązania między komponentami.
Diagram wdrożenia
Widok przypadków użycia
Przedstawienie interakcji między użytkownikiem a systemem, między procesami. Punkt wyjścia dla projektowania i testowania.
