Thinking in UML

3 stycznia 2012

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 komponentów
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.

Diagram przypadków użycia

Cześć, jestem Hania.

Jako strategiczny analityk biznesowy na pograniczu zarządzania i IT zapewniam, że projekty i działania w organizacji przynoszą wartość biznesową. Dostarczam kompetencji analitycznych managerom i zarządom z Polski, Niemiec i Szwajcarii przy tworzeniu strategii oraz wdrażaniu jej w kilkuset osobowej międzynarodowej organizacji.

Komentarze - 3

Pingback: Podsumowanie roku 2012 « analiza IT
Pingback: Jak ogarnąć projekt i nie zginąć w bałaganie « analiza IT
Pingback: Jak stawać się doskonałym analitykiem bez stresu i wysiłku - Analiza IT

Dodaj komentarz Anuluj pisanie odpowiedzi

Może zaciekawi Cię także:

Analiza biznesowa w projektach IT, Wydarzenia,

3 maja 2021

Konferencja MAP IT 2021 – 15 maja

MAP IT 2021! Ruszamy z zapisami na konferencję Management, Analysis & Product in IT. W sobotę 15 maja w 1

Rozwój zawodowy i psychologia, Wydarzenia,

Talenty Gallupa z Kasią Syrówką – live 6.05 o 19:00

Znasz swoje talenty Gallupa? I co dalej? Dowiedz się jak wygląda profil talentów osoby nadającej się na analityka. Zobacz jak

Analiza biznesowa w projektach IT, Analiza strategiczna w zarządzaniu, Chcę się przebranżowić, Chcę zostać analitykiem, Doświadczenia, Rozwój zawodowy i psychologia, Wydarzenia,

21 kwietnia 2021

Moja droga analityka biznesowego

Ostatnio napisał do mnie Marcin: “Czy mogłabyś podzielić większa ilością informacji na temat Twojej historii? Jakie działania podejmowałaś? Jaką wiedzę