Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta.

Podobne prezentacje


Prezentacja na temat: "E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta."— Zapis prezentacji:

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

2 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 2 Zagadnienia Diagramy aktywności Diagramy implementacyjne: Diagramy komponentów Diagramy wdrożeniowe Diagramy pakietów

3 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 3 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. Odella, 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.

4 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 4 Notacja 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, 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ć typufork (rozdzielenie jednej operacji na kilka przebiegających równolegle) lub typu join (złączenie kilku operacji równoległych w jedną) aktywność początkowaaktywność końcowa

5 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 5 Diagramy aktywności; przykład Osoba::Przygotowanie Napoju Znajdź Napój Nasyp kawy do filtru Dolej wody do zbiornika Włóż filtr do maszynki Włącz maszynkę Gotowanie kawy Nalej kawę Zrób herbatę Weź sobie wody [nie ma kawy] [kawa znaleziona] [nie ma herbaty] [herbata znaleziona] światełko zgasło Weź filiżanki Wypij fork join *[dla 3 filiżanek]

6 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 6 Swimlanes (1) Pobierz zamówienie Wyślij to, co zamówiono Pamiętaj, co wysłano Skompletuj zamówienie Płać KlientDział SprzedażyMagazyn :Zamówienie {wprowadzone} :Zamówienie {skompletowane} :Zamówienie {wysłane} :Zamówienie {umieszczone} Wystaw zamówienie

7 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 7 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).

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

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

10 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 10 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.

11 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 11 Diagramy implementacyjne 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 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:

12 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 12 Diagramy komponentów (1) interfejs bez nazwy Program do harmonogramów Program planujący Interfejs graficzny rezerwacje aktualizacje 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. 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. komponent interfejs nazwany zależność

13 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 13 Diagramy komponentów (2) 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. « baza danych » Konta Komponent może być opatrzony stereotypem. Zbiór komponentów tworzących kod systemu może być opisywany na dwa sposoby:

14 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 14 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. AdminServer:KomputerHost :Program do harmonogramów rezerwacje KomputerJacka:PC :Program planujący połączenie komunikacyjne

15 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 15 Diagramy wdrożeniowe; przykład Specjalne symbole są zwykle znacznie lepsze. W UML są one w pełni legalne. Serwer diabetyków Serwer oddziału terapii Szpitalna sieć Ethernet Internet Klient Web Sieć Ethernet oddziału PC z Windows

16 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 16 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.

17 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 17 Diagramy pakietów (2) 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. 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.

18 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 18 Diagramy pakietów; przykład Edytor Elementy diagramów graficznych Elementy dziedziny zastosowań Sterownik Rdzeń grafiki Rdzeń grafiki Motif Rdzeń grafiki Windows System okienkowy MotifMS Windows

19 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 19 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 » (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. P A X:E Q E « import » 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 A X:Q::E Q E « access » Dla zależności typu « access » nazwa, do której następuje odwołanie musi być poprzedzona nazwą pakietu, w którym jest zawarta.

20 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 20 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.

21 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 21 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 chronionej. Cała zawartość klasy jest widoczna wewnątrz klasy. Przykład: A +X -Y B +U -V « access » 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).

22 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 22 Reguły widoczności; przykład A +X B C +K -L « access » A +X B C +K -L « access »

23 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 23 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.

24 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 24 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.


Pobierz ppt "E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta."

Podobne prezentacje


Reklamy Google