Diagramy aktywności Diagramy implementacyjne i pakietów

Zagadnienia Diagramy aktywności Diagramy implementacyjne: Diagramy komponentów Diagramy wdrożeniowe Diagramy pakietów

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 stanu, 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 raczej 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 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 końcami); dla przypomnienia - stan na diagramach stanu posiada zaokrąglone rogi przejście, rzadko 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; kreska ciągła oznacza przepływ sterowania, a przerywana - 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 *[dla 3 filiżanek] Nalej kawę join Wypij światełko zgasło Włącz maszynkę Gotowanie kawy

Swimlanes (1) 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

Swimlanes (2) Jak było już wspomniane, 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 poprzedniej folii). Regiony, z powodu swojego wyglądu, są traktowane jak tory dla przepływów (tory pływackie) (swimlanes). Nazwy regionów odpowiadają nazwom osób, komórek organizacyjnych czy klas odpowiedzialnych za wykonanie aktywności. Na diagramch aktywności, oprócz przepływów sterowania można też pokazywać przepływy obiektów. 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).

Modelowanie iteracji (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 znajdź serwisanta z najlepszym terminem przydziel wybranemu serwisantowi naprawę

Modelowanie iteracji (2) znajdź serwisantów, którzy potrafią naprawiać dane uszkodzenie sprawdź, czy serwisant ma czas w ciągu najbliższego tygodnia znaleziony lub sprawdzono wszystkich serwisantów? [nie] rozwiazanie z wykorzystaniem rombu decyzyjnego (decision diamond) [nie znaleziono żadnego] [tak] anuluj zgłoszenie przydziel serwisantowi naprawę

Podsumowanie Kiedy używać diagramów aktywności (M. Fowler): 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 obiekt, wiele przypadków użycia - diagramy stanu, wiele obiektów, jeden przypadek użycia - diagramy interakcji, wiele obiektów, wiele przypadków użycia - 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ści) 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 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, związanych z nimi obiektów. 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ą wystąpienia obiektów i komponentów. Węzły mogą brać udział w związkach generalizacji. 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 stanu, 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łki z przerywaną linią (zależność, dependency). Strzałki zaznaczają przepływ 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ólpracy przez wykorzystanie pakietu zawierającego subkolaborację. Dla ułatwienia podziału pracy między członkami zespołu, czy też różne 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 Elementy diagramów graficznych Elementy dziedziny zastosowań System okienkowy Rdzeń grafiki Rdzeń grafiki Motif Motif Rdzeń grafiki Windows MS Windows

Odwołania «import» «access» Pakiet (klient), który odwołuje się do elementu w innym pakiecie (dostawcy), musi zaimportować 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. 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 «import» A X:E 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. «access» A X:Q::E E

Reguły widoczności Pakiet widzi wszystkie pakiety widoczne przez pakiet, 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. 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. 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ą siebie nawzajem (zdefiniowane w tym samym pakiecie). Przykład: 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». «subsytem» («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. Podsytemy mogą być zbudowane z innych podsystemów, wtedy te najniższego poziomu muszą już zawierać elementy modelu. Podsytem 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 przez to 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 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 znacząco 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.