Studia Podyplomowe IT w Biznesie Analiza dynamiczna w UML Polsko-Japońska Wyższa Szkoła Technik Komputerowych Warszawa Studia Podyplomowe IT w Biznesie Analiza dynamiczna w UML Wykład 1 Diagramy aktywności Wykładowca: dr inż. Ewa Stemposz ewag@ipipan.waw.pl

Zagadnienia Diagramy aktywności Swimlanes Modelowanie iteracji Notacja Swimlanes Modelowanie iteracji Podsumowanie diagramów dynamicznych

Diagramy aktywności Diagramy aktywności, nie posiadające wyraźnego pierwowzoru w poprzednich pracach “trzech przyjaciół” (Jacobsona, Boocha i Rumbaugha), łączą idee pochodzące z trzech źródeł: diagramów zdarzeń J. Odell’a, technik modelowania stanów i sieci Petriego. Są szczególnie użyteczne przy modelowaniu przepływów operacji czy też w opisie zachowań z przewagą przetwarzania współbieżnego. Graf aktywności to maszyna stanów, której podstawowym zadaniem nie jest analiza stanów obiektu, ale modelowanie przetwarzania (przepływów operacji). Stany grafu aktywności odpowiadają stanom wyróżnialnym w trakcie przetwarzania, a nie stanom obiektu i noszą nazwę aktywności. Aktywność może być interpretowana różnie, w zależności od perspektywy: jako zadanie do wykonania i to zarówno przez człowieka, jak i przez komputer (z perspektywy pojęciowej) czy też np. jako pojedyncza metoda (z perspektywy projektowej). Podobnie, przejścia między stanami nie są tu związane z nadejściem zdarzenia, ale z zakończeniem przetwarzania wyspecyfikowanego dla danego stanu. Diagramy aktywności z zasady nie pokazują wszystkich szczegółów przetwarzania. Pokazują aktywności bez pokazywania bytów, realizujących daną aktywność i dlatego z reguły używane są jako punkt startowy dla procesu modelowania zachowań. Dla skompletowania projektu każda aktywność powinna być rozpisana na szereg operacji, z których każdą trzeba będzie na późniejszym etapie przydzielić do odpowiedniej klasy.

Notacja Notacja przyjęta w UML dla diagramów aktywności: nazwa aktywność (z zaokrąglonymi końcami); przejście, z zasady nie opisywane, ponieważ z reguły oznacza zakończenie aktywności; może być opatrzone warunkiem, może też być oznaczone symbolem iteracji; akcje opisujące przejścia powinny być raczej dołączone do którejś z aktywności; linia przerywana oznacza przepływ obiektu romb, który może rozdzielać jedno przejście na kilka innych (opatrzonych warunkami) lub łączyć kilka alternatywnych przejść w jedno sztabka synchronizujaca (synchronization bar); może być typu “fork” (rozdzielenie jednej operacji na kilka przebiegających równolegle) lub typu “join” (złączenie kilku operacji równoległych w jedną) aktywność początkowa aktywność końcowa

Diagramy aktywności; przykład Osoba::Przygotowanie Napoju [nie ma kawy] [nie ma herbaty] Znajdź Napój [herbata znaleziona] [kawa znaleziona] fork Zrób herbatę Weź sobie wody Nasyp kawy do filtru Dolej wody do zbiornika Weź filiżanki Włóż filtr do maszynki *[1..4] Nalej kawę join Wypij światełko zgasło Włącz maszynkę Gotowanie kawy

Swimlanes (1) Diagramy aktywności opisują przepływy operacji, ale nie specyfikują, kto jest odpowiedzialny za ich wykonanie: którzy ludzie czy które komórki organizacyjne (z perspektywy pojęciowej). Z perspektywy projektowej dotyczy to klas. Można opisywać każdą aktywność podając osobę czy klasę odpowiedzialną za jej wykonanie, ale być może wygodniejszym sposobem przenoszenia informacji tego rodzaju jest grupowanie aktywności odpowiednio do odpowiedzialności i umieszczanie ich w regionach rozdzielonych pionowymi liniami (jak na następnej folii). Regiony, z powodu swojego wyglądu, są traktowane jak tory dla przepływów (tory pływackie, ang. swimlanes). Nazwy regionów odpowiadają nazwom osób, komórek organizacyjnych czy klas odpowiedzialnych za wykonanie aktywności. Na diagramach aktywności, oprócz przepływów sterowania można też pokazywać przepływy obiektów, w takim przypadku nie zamieszczamy na diagramie przepływu sterowania (patrz następna folia). Obiekt może stanowić daną wejściową dla aktywności (linia przerywana prowadzi wtedy od obiektu do aktywności) czy też daną wyjściową (linia przerywana idzie od aktywności do obiektu).

Swimlanes Klient Dział Sprzedaży Magazyn Wystaw zamówienie :Zamówienie [umieszczone] Pobierz zamówienie :Zamówienie [wprowadzone] Płać :Zamówienie [skompletowane] Skompletuj zamówienie :Zamówienie [wysłane] Wyślij to, co zamówiono

Modelowanie iteracji; przykład (1) znajdź serwisantów, którzy potrafią naprawiać dane uszkodzenie * [ dla wszystkich serwisantów ] {multiple trigger - wszystkie aktywności są odpalane jednocześnie } znajdź 1-szy wolny termin {synchronizacja aktywności, które zostały jednocześnie odpalone; może być opuszczona } przydziel naprawę wybranemu serwisantowi znajdź serwisanta z najlepszym terminem

Modelowanie iteracji; przykład (2) sprawdź, czy serwisant ma czas w ciągu najbliższego tygodnia znajdź serwisantów, którzy potrafią naprawiać dane uszkodzenie nie ma/ma/sprawdzono wszystkich serwisantów [nie ma] {rozwiazanie z wykorzystaniem rombu decyzyjnego} [sprawdzono wszystkich serwisantów] [ma] anuluj zgłoszenie przydziel serwisantowi naprawę

Przykład dla wymagań z biblioteką (1) Scenariusz dla przypadku użycia: wypożyczenie egzemplarza książki Sprawdzenie, czy można wypożyczyć danemu czytelnikowi o ile można, to: Sprawdzenie, czy książka jest dostępna (jest wolny egzemplarz) o ile jest dostępny egzemplarz, to: Rejestracja wypożyczenia Sprawdzenie, czy można wypożyczyć danemu czytelnikowi «include» Personel biblioteczny Wypożyczenie egzemplarza książki «extend» Sprawdzenie dostępności książki «extend» Rejestracja wypożyczenia egzemplarza

Przykład dla wymagań z biblioteką (2) Sprawdzenie czy można wypożyczyć danemu czytelnikowi [można] Sprawdzenie dostępności książki [nie można] [niedostępna] [dostępna] Rejestracja wypożyczenia egzemplarza książki

Podsumowanie diagramów dynamicznych Kiedy używać diagramów aktywności: Do analizowania przypadków użycia - gdy bardziej interesują nas operacje niezbędne do realizacji danego przypadku (czy też wzajemne zależności między tymi operacjami), a nie to, kto jest odpowiedzialny za ich przeprowadzenie. Przypisanie operacji do obiektów jest wykonywane na etapie późniejszym z wykorzystaniem diagramów interakcji. Do zrozumienia interakcji zachodzących między przypadkami użycia. Do modelowania przetwarzania wielowątkowego. Kiedy nie używać diagramów aktywności: Do pokazywania współpracy między obiektami w trakcie realizacji przypadku użycia - do tego bardziej nadają się diagramy interakcji. Do pokazywania zachowań obiektów w trakcie ich życia, w tym celu powinno się wykorzystywać diagramy stanów. Prosta reguła na wykorzystywanie diagramów dynamicznych w procesie modelowania zachowań: jeden przypadek użycia, wiele obiektów - diagramy interakcji, wiele przypadków użycia, jeden obiekt - diagramy stanów, wiele przypadków użycia, wiele obiektów - diagramy aktywności.