Projektowanie systemów informacyjnych Wykład 11 Model dynamiczny (3) Diagramy aktywności Diagramy implementacyjne i pakietów Ewa Stemposz, Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

Zagadnienia Diagramy aktywności Notacja Swimlanes Modelowanie iteracji Podsumowanie diagramów dynamicznych Diagramy implementacyjne: Diagramy komponentów Diagramy wdrożeniowe Diagramy pakietów

Diagramy aktywności Diagramy aktywności nie posiadają wyraźnego pierwowzoru w poprzednich pracach “trzech przyjaciół” (Jacobsona, Boocha i Rumbaugha). Łącząc idee pochodzące z trzech źródeł: diagramów zdarzeń J. Odell’a, technik modelowania stanów i sieci Petriego i 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 wią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 bedzie na późniejszym etapie przydzielić do odpowiedniej klasy.

Notacja Notacja przyjęta w UML dla diagramów aktywności: nazwa aktywność (z zaokrąglonymi bokami) przejście, rzadko opisywane nazwą zdarzenia, 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; kreska ciągła oznacza przepływ sterowania, a przerywana - przepływ obiektu romb decyzyjny, który może rozdzielać jedno przejście na kilka innych (opatrzonych warunkami) lub łączyć kilka alternatywnych przejść w jedno sztabka synchronizująca (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 *[dla 3 filiżanek] 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 (2) Klient Dział Sprzedaży Magazyn Wystaw 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 Pamiętaj, co wysłano

Modelowanie iteracji; przykład (1) Wyszukiwanie serwisantów, którzy potrafią naprawiać dane uszkodzenie * [ dla wszystkich serwisantów ] { multiple trigger - wszystkie aktywności są odpalane jednocześnie } Wyszukiwanie 1-szego wolnego terminu { synchronizacja aktywności, które zostały jednocześnie odpalone; może być opuszczona } Wyszukiwanie serwisanta z najlepszym terminem Przydzielanie naprawy wybranemu serwisantowi

Modelowanie iteracji; przykład (2) Wyszukanie serwisantów, którzy potrafią naprawiać dane uszkodzenie Sprawdzenie, czy serwisant ma czas w ciągu najbliższego tygodnia { nie ma/ma/sprawdzono wszystkich serwisantów } [ nie ma] { rozwiazanie z wykorzystaniem rombu decyzyjnego} [ sprawdzono wszystkich serwisantów ] [ ma ] Anulowanie zgłoszenia Przydzielenie naprawy serwisantowi

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 interesują nas bardziej 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 (ważne zastosowanie). 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.

Diagramy implementacyjne Diagramy implementacyjne pokazują niektóre aspekty implementacji SI, włączając w to strukturę kodu źródłowego oraz strukturę kodu czasu wykonania (run-time). Konstruowanie takich diagramów jest użyteczne zarówno ze względu na ponowne użycie, jak i ze względu na możliwość osiągania z ich pomocą odpowiednich parametrów wydajnościowych. UML wprowadza dwa typy takich diagramów: Diagramy komponentów pokazujące zarówno implementację elementów projektu ( np. klas) przez komponenty, jak i interfejsy oraz zależności między komponentami, innymi słowy pokazujące strukturę kodu konstruowanego SI. Diagramy wdrożeniowe pokazujące konfigurację systemu czasu wykonania, czyli rozmieszczenie komponentów i obiektów na obliczeniowych zasobach czasu wykonania, zwanych tu węzłami. Taka konfiguracja może być zarówno statyczna, jak i dynamiczna - i komponenty i obiekty mogą migrować między węzłami w czasie wykonania.

Diagramy komponentów (1) Komponent jest jednostką implementacji z dobrze zdefiniowanym interfejsem, dobrze wyizolowany z kontekstu, nadający się do wielokrotnego wykorzystania. Dobrze skonstruowany komponent korzysta z innych komponentów wyłącznie za pośrednictwem ich interfejsów, co z założenia ułatwia przyszłe modyfikacje. komponent Diagramy komponentów pokazują zależności pomiędzy komponentami oprogramowania, włączając komponenty kodu źródłowego, kodu binarnego oraz kodu wykonywalnego. Komponenty mogą istnieć w różnym czasie: niektóre z nich w czasie kompilacji, niektóre w czasie konsolidacji, zaś niektóre w czasie wykonania. Diagram komponentów jest przedstawiany jako graf, gdzie węzłami są komponenty, zaś strzałki (z przerywaną linią - zależność, dependency) prowadzą od klienta pewnej informacji do jej dostawcy. Program do harmonogramów rezerwacje interfejs nazwany Program planujący aktualizacje zależność Interfejs graficzny interfejs bez nazwy

Diagramy komponentów (2) Komponent może być opatrzony stereotypem. «baza danych» Konta Zbiór komponentów tworzących kod systemu może być opisywany na dwa sposoby: poprzez utworzenie listy komponentów wraz ze specyfikacją ich wzajemnych zależności (biblioteka komponentów) - tu bardzo pomocne jest nazywanie interfejsów, poprzez diagram komponentów pokazujący graficznie sieć ich wzajemnych zależności; diagram komponentów pokazuje też, za realizację jakiego interfejsu jest odpowiedzialny każdy z komponentów.

Diagramy wdrożeniowe Diagramy wdrożeniowe pokazują konfigurację elementów czasu wykonania: komponentów sprzętowych, czyli fizycznych jednostek posiadających co najmniej pamięć, a często i możliwości obliczeniowe, komponentów oprogramowania, obiektów związanych z komponentami. Diagram wdrożeniowy jest grafem, gdzie wierzchołki (węzły) połączone są przez linie odwzorowywujące połączenia komunikacyjne komponentów sprzętowych. Węzły, podobnie jak połączenia komunikacyjne, mogą być opatrzone stereotypami, np.: «CPU», «pamięć», «urządzenie jakieś». Węzły przechowują obiekty i wystąpienia komponentów. Węzły mogą brać udział w związkach generalizacji. komponent sprzętowy połączenie komunikacyjne AdminServer:KomputerHost KomputerJacka:PC :Program planujący :Program do harmonogramów rezerwacje

Diagramy wdrożeniowe; przykład Specjalne symbole są zwykle znacznie lepsze. W UML są one w pełni legalne. Serwer oddziału terapii Szpitalna sieć Ethernet Internet Klient Web Serwer diabetyków Sieć Ethernet oddziału PC z Windows PC z Windows

Diagramy pakietów (1) Pakiety są zestawami elementów danego modelu wraz z zachodzącymi pomiędzy nimi zależnościami. Każdy element modelu musi być przypisany do jednego pakietu (home package). Dany model może być opisany przez zbiór pakietów. Podział modelu na pakiety jest arbitralny, ale u jego podstaw powinny leżeć racjonalne przesłanki, np. wspólna funkcjonalność, silne skojarzenia, itp. Pakiety zawierają elementy tzw. wysokiego poziomu, takie jak np.: klasy i ich związki, maszyny stanów, grafy przypadków użycia, itp. To, co jest zawarte w elementach wysokiego poziomu, np. atrybuty, operacje, stany zagnieżdżone, linie życia, komunikaty, itp. z reguły nie pojawia się jako bezpośrednia zawartość pakietu. Pakiety mogą być zagnieżdżane. Zależności pomiędzy pakietami, wynikające z zależności między elementami w nich zawartymi, są przedstawiane na diagramach pakietów w postaci strzałek z przerywaną linią (dependency). Strzałki wyznaczają kierunek przepływu informacji pomiędzy pakietami. Pakiety mogą brać udział w związkach dziedziczenia. Pakiety mogą być opatrywane stereotypami i listami własności etykietowanych. Diagramy pakietów są istotne przede wszystkim dla dużych projektów, składających się z wielu jednostek funkcjonalnych (ze złożonymi zależnościami pomiędzy tymi jednostkami) oraz tworzonych przez grupę współpracujących osób.

Diagramy pakietów (2) Istnieje co najmniej kilka powodów, dla których warto jest używać pakietów: W celu ukrycia mniej istotnych elementów modelu. Dla przypomnienia: uproszczenie diagramu współpracy przez wykorzystanie pakietu zawierającego subkolaborację. Dla ułatwienia podziału pracy między członkami zespołu, czy też różnymi zespołami. Dla zaprojektowania komponentu. Dwa ostatnie przypadki dotyczą specjalnego rodzaju pakietu, zwanego podsystemem. Symbolu pakietu można używać we wszystkich rodzajach diagramów. Można pokazywać zależności, asocjacje czy inne relacje zachodzące między elementami pakietów, czy też pakietami, ale jak zawsze (dla każdego rodzaju diagramów) szczegóły nie powinny utrudniać rozumienia. Pakiety są rysowane jako duże prostokąty z małym prostokątem u góry (“etykietą”). Jeżeli zawartość pakietu nie jest pokazana, wówczas nazwa pakietu jest wpisana do większego prostokąta. Jeżeli jest pokazana, to nazwę pakietu wpisuje się do “etykiety”. Zależności między elementami mogą być różnego rodzaju (mogą być opatrzone stereotypami), ale tego typu informacja nie jest przenoszona przez diagramy pakietów - uwidaczniany jest wyłącznie fakt istnienia zależności dowolnego rodzaju.

Diagramy pakietów; przykład Edytor Sterownik zależność Elementy diagramów graficznych Elementy dziedziny zastosowań System okienkowy Rdzeń grafiki Rdzeń grafiki Motif Motif Rdzeń grafiki Windows MS Windows

Odwołania Pakiet (klient), który odwołuje się do elementu w innym pakiecie (dostawcy), może wykorzystać pakiet zawierający pożądany element używając albo zależności «import» albo «access» (dwa rodzaje zależności typu «usage»). Różnica w obu rodzajach zależności polega na różnych sposobach odwoływania się elementów z jednego pakietu do drugiego. oznaczenie klasy Nazwy z pakietów zaimportowanych za pomocą zależności typu «import» są dodawane do przestrzeni nazw pakietu importującego. Na diagramie: nazwy z pakietu Q są dodawane do przestrzeni nazw pakietu P, co oznacza, że elementy z P traktują nazwy z Q, tak samo jak nazwy z P (tu może wystąpić konflikt nazw). P Q A X:E «import» E P Q Dla zależności typu «access» nazwa, do której następuje odwołanie musi być poprzedzona nazwą pakietu, w którym jest zawarta. A X:Q::E «access» E

Reguły widoczności Pakiet widzi zawartość wszystkich pakietów widoczną dla pakietu, wewnątrz którego jest zagnieżdżony, innymi słowy zagnieżdżony pakiet widzi to samo, co pakiet zawierający go. Zależność odwrotna nie zachodzi. Symbole + (publiczna), - (prywatna), # (chroniona) są używane na oznaczenie widoczności elementu modelu na zewnątrz pakietu – widoczności dla pakietów, klientów danego pakietu. Zasady widoczności można sformułować następująco: Element zdefiniowany w danym pakiecie jest widoczny dla innych elementów tego pakietu. Jeśli element jest widoczny w pakiecie A, to jest widoczny we wszystkich pakietach, które są w A zagnieżdżone. Jeśli A jest powiązany zależnością z pakietem B, wtedy wszystkie elementy o widoczności publicznej w B są widoczne w A. Jeśli pakiet A dziedziczy po pakiecie B, wtedy wszystkie elementy w B, o widoczności publicznej lub chronionej, są widoczne w A. Zależności nie są przechodnie, tzn. jeśli A jest połączone zależnością z B, a B z C, to nie oznacza, że A jest połączone zależnością z C. Zależności nie są też symetryczne.

Reguły widoczności (2) «access» Reguły widoczności dla elementów klas: Elementy zawarte wewnątrz klasy, np. atrybuty, operacje czy klasy zagnieżdżone są widoczne (dostępne dla innych klas) wewnątrz pakietu, jeśli widoczność tych elementów jest publiczna. W przypadku dziedziczenia, podklasa widzi elementy o widoczności publicznej i chronionej. Cała zawartość klasy jest widoczna wewnątrz klasy. Przykład: Pakiet A ma dostęp do pakietu B, ale B nie ma dostępu do A. Klasy X i Y w pakiecie A widzą klasę U w pakiecie B (widoczność publiczna), nie widzą zaś klasy V (widoczność prywatna). Klasy U i V nie mają dostępu do żadnej klasy w pakiecie A, mimo publicznej widoczności klasy X (brak odpowiedniej zależności, B nie ma dostępu do A). Klasy X i Y, podobnie jak U i V, widzą nawzajem swoje publiczne elementy (jako klasy zdefiniowane w tym samym pakiecie). A +X -Y B +U -V «access»

Reguły widoczności; przykład «access» «access» +X +X C +K -L C +K -L = B B «access»

Specjalne rodzaje pakietów «facade» («fasada») Zawiera wyłącznie odwołania do elementów zdefiniowanych w innych pakietach. «model» Stanowi mniej lub więcej kompletną abstrakcję systemu (na pewnym poziomie szczegółowości), widzianą z pewnej perspektywy. Zwykle zawiera wewnątrz drzewo pakietów. Model może zawierać relewantne elementy z otoczenia systemu, np. aktorów. Elementy z różnych modeli nie oddziaływują bezpośrednio na siebie, ale często stanowią różne reprezentacje tego samego bytu, różniące się np. ilością detali, stąd może wynikać potrzeba łączenia ich zależnością typu «trace» czy «refinement». «subsystem» («podsystem») Jest rodzajem pakietu, który reprezentuje pewien spójny, logiczny, dobrze wyizolowany fragment systemu. Posiada dobrze wyspecyfikowany zbiór interfejsów, do interakcji z otoczeniem. Podsystem podzielony jest na dwie części: specyfikacyjną i realizacyjną. Część specyfikacyjna zawiera opis interakcji z otoczeniem, z reguły za pomocą przypadków użycia. Część realizacyjna, posługując się kolaboracjami, podaje sposoby realizacji przypadków przez podsystem. Podsystemy mogą być zbudowane z innych podsystemów, wtedy te najniższego poziomu muszą już zawierać elementy modelu. Podsystem stanowi zgrupowanie elementów modelu logicznego. Komponent jest zgrupowaniem elementów modelu implementacyjnego. W wielu przypadkach podsystemy są implementowane jako komponenty. To upraszcza mapowanie modelu logicznego w implementacyjny i dzięki temu jest powszechnie stosowanym podejściem.

Podsumowanie diagramu pakietów Pakiety stanowią zgrupowanie elementów modelu. Są środkiem ogólnego zastosowania przeznaczonym do budowania struktur hierarchicznych. Każdy element modelu, który nie jest zawarty wewnątrz innego elementu modelu, musi być zdefiniowany wewnątrz dokładnie jednego pakietu, czyli jednej przestrzeni nazw (home package). Pakiet, oprócz elementów modelu, może też zawierać inne pakiety (zagnieżdżanie). Są pakiety specjalnego rodzaju: fasada, model, podsystem, system. Stosowanie pakietów ułatwia zarządzanie przechowywaniem, konfiguracjami czy modyfikowaniem elementów systemu. Dobrze przeprowadzony podział na pakiety może znacząco ułatwić zarządzanie procesem konstrukcji produktu programistycznego.