Projektowanie systemw informacyjnych Wykad 11 Diagramy dynamiczne 3

Projektowanie systemów informacyjnych Wykład 11 Diagramy dynamiczne (3) Kazimierz Subieta, Ewa Stemposz Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 1

Zagadnienia Diagramy aktywności Diagramy implementacyjne § Diagramy komponentów § Diagramy wdrożeniowe Diagramy pakietów K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 2

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ć interpretowna 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. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 3

Notacja przyjęta w UML dla diagramów aktywności: nazwa aktywności aktywność (z zaokrąglonymi końcami); dla przypomnienia - stan na diagramach stanu posiada zaokrąglone rogi 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; 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 K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 4 aktywność końcowa

Diagramy aktywności; przykład Osoba: : Przygotowanie Napoju Znajdź Napój [kawa znaleziona] Nasyp kawy do filtru [nie ma herbaty] [nie ma kawy] Dolej wody do zbiornika Włóż filtr do maszynki (fork) Zrób herbatę Weź filiżankę * [1. . 4] (join) Weź sobie wody Nalej * [1. . 4] kawę Wypij światełko zgasło Włącz maszynkę [herbata znaleziona] Gotowanie kawy K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 5

Swimlanes (1) Klient Dział Sprzedaży Magazyn Wystaw zamówienie : Zamówienie [umieszczone] Płać : Zamówienie [wysłane] Pamiętaj zamówienie K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 6 Pobierz zamówienie : Zamówienie [skompletowane] Wyślij to, co zamówiono : Zamówienie [wprowadzone] Skompletuj zamówienie

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 odpowidają 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). K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 7

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. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 8

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. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 9

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 jako klasyfikator 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 K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 10

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. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 11

Diagramy wdrożeniowe pokazują konfigurację elementów czasu wykonania: § komponentów sprzętowych, § komponentów oprogramowania, § związanych z nimi obiektów. Diagram wdrożeniowy jest grafem, gdzie węzłami są zasoby czasu wykonania połączone przez linie odwzorowywujące ich połączenia komunikacyjne. Węzły oznaczają fizyczne jednostki posiadające co najmniej pamięć, a często i możliwości obliczeniowe. 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 Admin. Server: Komputer. Host : Program do harmonogramów Komputer. Jacka: PC rezerwacje K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 12 : Program planujący

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 K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 13 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ść, mocne 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, 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. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 14

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 interakcji przez wykorzystanie pakietu zawierającego subkolaborację. § Dla ułatwienia podziału pracy między członków zespołu, czy też różne zespoły. § 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. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 15

Diagramy pakietów; przykład Edytor Sterownik Elementy diagramów graficznych Elementy dziedziny zastosowań System okienkowy Rdzeń grafiki Motif Rdzeń grafiki Windows K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 16 Motif MS Windows

Odwołania 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>> (rodzaje zależności typu <<usage>>). Różnica w obu rodzajach zależności polega na sposobie odwoływania się elementów z jednego pakietu do drugiego. Q P A X: E <<import>> Q P A X: Q: : E E 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). <<access>> E K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 17 Dla zależności typu <<access>> nazwa, do której następuje odwołanie musi być poprzedzona nazwą pakietu, w którym jest zawarta.

Reguły widoczności Pakiet widzi wszystkie pakiety zaimportowane 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. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 18

Reguły widoczności (2) 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 prywatnej. § Cała zawartość klasy jest widoczna wewnątrz klasy. Przykład: A B +X -Y <<access>> +U -V K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 19 Pakiet A ma dostęp do pakietu B, ale B niema 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).

Reguły widoczności; przykład A A <<access>> +X +X C B <<access>> C +K B +K -L -L <<access>> K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 20

Specjalne rodzaje pakietów <<façade>> (<<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. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 21

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. 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. K. Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 11, Folia 22