Projektowanie systemów informacyjnych

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

Zagadnienia

Diagramy aktywności

 Diagramy komponentów

 Diagramy wdrożeniowe Diagramy pakietów

Diagramy implementacyjne:

 Notacja

 Swimlanes

 Modelowanie iteracji

 Podsumowanie diagramów dynamicznych

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ści 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ą)

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]

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)

Pobierz zamówienie

Wyślij to, co zamówiono Pamiętaj, co

wysłano

Skompletuj zamówienie Płać

Klient Dział Sprzedaży Magazyn

Zamówienie [wprowadzone]

Zamówienie [skompletowane]

Zamówienie [wysłane]

Zamówienie [umieszczone]

Wystaw zamówienie

Modelowanie iteracji; przykład (1)

Wyszukiwanie serwisantów, którzy potrafią naprawiać

dane uszkodzenie

* [ dla wszystkich serwisantów ]

Wyszukiwanie 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 }

Przydzielanie naprawy wybranemu serwisantowi Wyszukiwanie 1-szego wolnego terminu

Modelowanie iteracji; przykład (2)

Wyszukanie serwisantów, którzy potrafią naprawiać

dane uszkodzenie

Przydzielenie naprawy serwisantowi Sprawdzenie, czy serwisant

ma czas w ciągu najbliższego tygodnia

{ nie ma/ma/sprawdzono wszystkich serwisantów }

[ ma ] [ nie ma]

{ rozwiazanie z wykorzystaniem rombu decyzyjnego}

[ sprawdzono wszystkich serwisantów ]

Anulowanie zgłoszenia

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

Personel biblioteczny

Wypożyczenie egzemplarza książki

Sprawdzenie, czy można wypożyczyć danemu czytelnikowi

Sprawdzenie dostępności książki

Rejestracja wypożyczenia egzemplarza

«include»

«extend»

«extend»

Przykład dla wymagań z biblioteką (2)

Sprawdzenie,

czy można wypożyczyć danemu czytelnikowi

Sprawdzenie dostępności książki

Rejestracja wypożyczenia egzemplarza książki

[ można]

[ nie można ]

[ dostępna ] [ niedostępna ]

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,

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:

Diagramy komponentów (1)

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ść, dependency) prowadzą od klienta pewnej informacji do jej

komponent

interfejs nazwany

zależność

Diagramy komponentów (2)

 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.

«

baza danych

»

Konta

Komponent może być opatrzony stereotypem.

Zbiór komponentów tworzących kod systemu może być opisywany na dwa sposoby:

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.

AdminServer:KomputerHost

:Program do harmonogramów

KomputerJacka:PC :Program planujący

połączenie komunikacyjne komponent sprzętowy

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 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)

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ół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.

Diagramy pakietów; przykład

Edytor

Elementy diagramów graficznych

Elementy dziedziny zastosowań

Sterownik

Rdzeń grafiki

Rdzeń grafiki Motif

Rdzeń grafiki Windows

System okienkowy

Motif

MS Windows

zależność

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.

P

A X:E

Q

«import» 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).

P

A X:Q::E

Q

«access» E

Dla zależności typu

«

access

»

nazwa, do której następuje odwołanie musi być poprzedzona nazwą pakietu, w którym jest zawarta.

oznaczenie klasy

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)

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ą nawzajem swoje publiczne elementy (jako klasy zdefiniowane w tym samym pakiecie).

Reguły widoczności; przykład

A

+X

B

C

+K -L

«

^access

»

A

+X

B

C

+K -L

«

^access

»

«

^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.