Projektowanie systemów informacyjnych

Prezentacja na temat: "Projektowanie systemów informacyjnych"— Zapis prezentacji:

1 Projektowanie systemów informacyjnych
Wykład 11b Diagramy implementacyjne i diagramy pakietów Ewa Stemposz Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

2 Zagadnienia Diagramy implementacyjne: Diagramy komponentów
Diagramy wdrożeniowe Diagramy pakietów

3 Diagramy implementacyjne
Diagramy implementacyjne pokazują niektóre aspekty implementacji SI, włączając w to strukturę kodu źródłowego, kodu binarnego oraz strukturę kodu czasu wykonania (ang. 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 za ich pomocą odpowiednich parametrów wydajnościowych. UML wprowadza dwa rodzaje takich diagramów: Diagramy komponentów (ang. component diagram): pokazują zarówno implementację elementów projektu (np. grupy klas) przez komponenty, jak i interfejsy oraz zależności między komponentami. Diagramy wdrożeniowe (ang. deployment diagram): pokazują konfigurację systemu czasu wykonania, czyli rozmieszczenie komponentów i artefaktó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 artefakty mogą migrować między węzłami w czasie wykonania.

4 Adaptacja notacji BNF Symbol Znaczenie =
struktura danych po lewej stronie symbolu = składa się z elementów wyspecyfikowanych po stronie prawej + odpowiada słowu “i”; wykorzystywane do agregowania elementów [ … ] definiowana struktura zawiera tylko jeden spośród elementów zawartych w nawiasach [ ] i oddzielonych przecinkami ( … ) elementy zawarte w nawiasach ( ) są opcjonalne, co oznacza, że mają 0..1 wystąpień { … } definiowana struktura zawiera od 0..* wystąpień elementu zawartego w nawiasach { } * … * informacje zawarte między * * są traktowane jak komentarz, a więc nie stanowią elementów składowych definiowanej struktury

5 Prezentowanie diagramów implementacyjnych
<nagłówek-diagramu> = (<wyróżnik_diagramu>) + <nazwa-diagramu> + {<parametr>} cod Nazwa diagramu cod – wyróżnik diagramu komponentów (component diagram) dd Nazwa diagramu dd – wyróżnik diagramu wdrożeniowego (deployment diagram)

6 Kategorie modelowania (1)
Kategoria modelowania Notacja komponent (ang. component) interfejs udostępniający (ang. provided interface) interfejs pozyskujący (ang. required interface) port (ang. port) Port złożony (ang. complex port)

7 Kategorie modelowania (2)
Kategoria modelowania Notacja zależność (ang. dependency) realizacja (ang. realization) Konektor delegowany (ang. connector with «delegate» stereotype ) Konektor składany (ang. ball & socket) «realize» «delegate»

8 Komponent (1) Komponent: jednostka implementacji, dobrze wyizolowana z kontekstu, z dobrze zdefiniowanym interfejsem/interfejsami, nadająca się do wielokrotnego wykorzystania. UML 1.* Harmonogramy IRezerwacja interface UML 2.0 IRezerwacja Harmonogramy IRezerwacja «component» Harmonogramy «component» Harmonogramy IRezerwacja

9 Komponent (2) Przykładowe stereotypy wykorzystywane dla oznaczania zawartości komponentów: Stereotyp Zawartość komponentu «subsystem» podsystem «executable» program wykonywalny «library» biblioteka oprogramowania «table» baza danych; tabela baz danych Przykłady: «executable» Harmonogramy.exe «table» Harmonogramy.db

10 Artefakty Artefakt: oznacza każdy produkt informatyczny wykorzystywany lub wytworzony w trakcie cyklu życiowego systemu, np. dokument tekstowy, diagram, model, skrypt systemowy, kod źródłowy, kod wykonywalny, itp. Komponent oprogramowania można traktować jako specjalny rodzaj artefaktu. Notacja: «artifact» Nazwa artefaktu Artefakty mogą być opatrywane stereotypami, np.: «document» «file» «source» «script»

11 Specyfikacja komponentu (1)
Komponent może być specyfikowany w postaci: czarnej skrzynki – tzw. perspektywa zewnętrzna bez pokazywania zawartości komponentu; specyfikowane są wyłącznie interfejsy i/lub operacje komponentu, białej skrzynki – tzw. perspektywa wewnętrzna; wprowadzono tu dodatkową sekcję realizations specyfikującą klasyfikatory, o które oparto realizację komponentu. Inne, dodatkowe sekcje mogą być wykorzystywane np. dla specyfikowania konektorów czy artefaktów skojarzonych z komponentem. «component» Zamówienia IZamówienie IFaktura IOsoba perspektywa zewnętrzna; notacja graficzna

12 Specyfikacja komponentu (2)
«component» Zamówienia «provided interfaces» IZamówienie utwórzZamówienie() walidujZamówienie() dodajWierszZamówienia() «required interfaces» IFaktura utwórzFakturę() rejestrujZapłatę() IOsoba utwórzOsobę() podajDaneOsoby() znajdźOsobęPoNazwisku() «component» Zamówienia «provided interfaces» IZamówienie «required interfaces» IFaktura IOsoba «realizations» Zamówienie NagłówekZamówienia WierszZamówienia «artifacts» Zamowienia.jar perspektywa zewnętrzna; notacja tekstowa perspektywa wewnętrzna; notacja tekstowa

13 Alternatywna reprezentacja zawartości komponentu
«component» Zamówienia Zamówienie WierszZamówienia NagłówekZamówienia 1 * IZamówienie IOsoba IFaktura

14 Jawna reprezentacja interfejsów
Jawna reprezentacja interfejsów pozwala, o ile jest to potrzebne, na specyfikowanie operacji interfejsu. IZamówienie – interfejs udostępniający IOsoba – interfejs pozyskujący «component» Zamówienia «interface» IZamówienie utwórzZamówienie() walidujZamówienie() dodajWierszZamówienia() IOsoba utwórzOsobę() podajDaneOsoby() znajdźOsobęPoNazwisku() «realize» «use»

15 Porty, konektory (1) Port: wyróżniony element, związany z interfejsem, przez który komponent komunikuje się z otoczeniem. Port złożony: to port skojarzony z więcej niż jednym interfejsem. Konektor: wykorzystywany do łączenia elementów diagramu komponentów. «component» Zamówienia Zamówienie WierszZamówienia NagłówekZamówienia 1 * IZamówienie IOsoba IFaktura «delegate» port konektor delegowany złożony

16 Porty, konektory (2) Sklep Zamówienia Klienci Produkty «component»
IZamówienie «delegate» IOsoba «component» Zamówienia «component» Klienci IZamówienie IOsoba IProdukt IKonto konektor składany IProdukt «delegate» «component» Produkty IKonto

17 Diagramy wdrożeniowe Diagramy wdrożeniowe pokazują konfigurację elementów czasu wykonania: komponentów sprzętowych, platform użytkowania systemu, komponentów oprogramowania, artefaktów – w tym przypadku, artefakty dotyczą możliwego do uruchomienia kodu. 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 mogą być opatrywane stereotypami, np.: «serwer», «klient», «PC», «drukarka», itp. węzeł połączenie komunikacyjne «PC» «serwer» Komputer użytkownika Serwer harmonogramów «TCP/IP» 1 1..* IRezerwacja «component» Harmonogramy «component» Planowanie

18 Diagram wdrożeniowy; 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

19 Specyfikacja artefaktów/komponentów w węzłach (1)
1) Notacja tekstowa – specyfikacja artefaktów i komponentów umieszczonych w węźle 2) Notacja graficzna – specyfikacja artefaktów i komponentów umieszczonych w węźle «serwer» Obsługa zamówień «component» Zamówienia «component» Klienci «component» Produkty «artifact» FormularzZamówienia «serwer» Obsługa zamówień «component» Zamówienia Klienci Produkty «artifact» FormularzZamówienia

20 Specyfikacja artefaktów/komponentów w węzłach (2)
3) Notacja graficzna – specyfikacja artefaktów i komponentów połączonych z węzłem stereotypowaną zależnością «deploy» «component» Produkty «component» Zamówienia «deploy» «deploy» «serwer» Obsługa zamówień «component» Klienci «deploy» «deploy» «artifact» FormularzZamówienia

21 Kategoria modelowania manifestowanie
Manifestowanie: sterotypowany związek zależności określający sposób prezentowania przez dany artefakt swoich elementów składowych. «serwer» Obsługa zamówień «klient» Komputer klienta Przeglądarka internetowa «artifact» FormularzZamówienia «manifest» 1..* 1

22 Diagramy pakietów Pakiet: grupuje elementy danego (jednego) modelu, łącznie z zachodzącymi pomiędzy tymi elementami zależnościami. Każdy element modelu musi być przypisany do jednego pakietu (ang. home package). Pakiety zawierają elementy tzw. wysokiego poziomu, takie jak np.: klasy i ich związki, maszyny stanowe, przypadki użycia, itp. To, co jest zawarte w elementach wysokiego poziomu, np. atrybuty, operacje, stany zagnieżdżone, itp. z reguły nie pojawia się jako bezpośrednia zawartość pakietu. 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 mogą być zagnieżdżane. Diagramy pakietów są istotne przede wszystkim dla dużych projektów, składających się z wielu jednostek funkcjonalnych (ze złożonymi relacjami pomiędzy tymi jednostkami) oraz tworzonych przez grupę współpracujących osób.

23 Reprezentowanie diagramów pakietów
<nagłówek-diagramu> = (<wyróżnik_diagramu>) + <nazwa-diagramu> + {<parametr>} pd Nazwa diagramu pd – wyróżnik diagramu komponentów (package diagram)

24 Kategorie modelowania
Kategoria modelowania Notacja pakiet (ang. package) zależność (ang. dependency) zagnieżdżanie (ang. nesting) + Nazwę pakietu umieszcza się albo wewnątrz większego prostokąta – w sytuacji, gdy nie pokazano zawartości pakietu – albo, zgodnie z notacją zakładkową, wewnątrz mniejszego prostokąta (w zakładce pakietu). 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 wewnętrznymi elementami pakietów, czy też pakietami, ale szczegóły nie powinny utrudniać rozumienia. Zazwyczaj, uwidaczniany jest wyłącznie fakt istnienia zależności.

25 Zależności pomiędzy pakietami
Przypadek A Pakiet P1 Przypadek B Pakiet P2 «extend» Przypadek A Pakiet P1 Przypadek B Pakiet P2

26 Diagram pakietów; przykład
Edytor Sterownik Elementy diagramów graficznych Elementy dziedziny zastosowań Rdzeń grafiki System okienkowy

27 Zagnieżdżanie pakietów (1)
Zagnieżdżanie pakietów można pokazywać na 3 sposoby: 1) 2) Edytor Elementy diagramów graficznych Sterownik dziedziny zastosowań Rdzeń grafiki Edytor Elementy diagramów graficznych Elementy dziedziny zastosowań Rdzeń grafiki Sterownik

28 Zagnieżdżanie pakietów (2)
3) Edytor + Elementy diagramów graficznych Sterownik dziedziny zastosowań Rdzeń grafiki

29 Odwołania Pakiet_klient (klient usług), który odwołuje się do elementu zawartego w pakiecie_dostawca (dostawca usług), może uzyskać dostęp do pożądanego elementu używając zależności typu «import» lub zależności typu «access». Oba rodzaje zależności różnią się sposobem importowania przestrzeni nazw z pakietu_dostawca do pakietu_klient. P A x : E Q E «import» oznaczenie klasy Dla zależności typu «import», nazwy z pakietu_dostawcy są dodawane do przestrzeni nazw pakietu_klient, jest to tzw. import publiczny. Na diagramie: nazwy z pakietu Q są dodawane do przestrzeni nazw pakietu P, co oznacza, że elementy w P traktują nazwy z Q, tak samo jak nazwy z P (uwaga: może wystąpić konflikt nazw). P A x : E Q «access» E Zależność typu «access» oznacza tzw. import prywatny.

30 Odwołania; import publiczny/prywatny
Q P R S «access» E Nazwy z pakietu R są importowane do przestrzeni nazw pakietów Q i P (import publiczny). Natomiast nazwy z pakietu S będą importowane wyłącznie do pakietu Q (import prywatny). Odwołania w pakiecie P do nazw zdefiniowanych w S muszą być kwalifikowane nazwą pakietu S, czyli np. S::E. Import może dotyczyć tylko wybranych nazw w danym pakiecie, co oznacza się następująco: ”{import” <nazwa_kwalifikowana> ”}” ”{access” <nazwa_kwalifikowana> ”}”

31 Zależność typu merge Zależność typu merge: bezpośrednia relacja między dwoma pakietami oznaczająca, że zawartość pakietów ma być połączona. Konceptualnie jest to bardzo podobne do generalizacji, w tym sensie, że pakiet_klient rozszerza charakterystykę swoich elementów o własności elementów zdefiniowanych w pakiecie_dostawca. Mechanizm łączenia zawartości pakietów za pośrednictwem zależności typu merge powinien być wykorzystywany w sytuacji, gdy elementy zdefiniowane w różnych pakietach mają te same nazwy i podobną semantykę. Główne zastosowanie to dostarczanie różnych definicji elementów (dla różnych zastosowań) w oparciu o jedną definicję bazową. Q E P R Podklasa klasy E «import» «merge»

32 Zasady widoczności Symbole używane na oznaczenie widoczności elementu zawartego w pakiecie na zewnątrz pakietu – widoczności dla innych pakietów, będących klientami danego pakietu: publiczna + prywatna - chroniona # Zasady widoczności można sformułować następująco Element zdefiniowany w danym pakiecie jest widoczny dla innych elementów tego pakietu. Pakiet widzi wszystkie elementy widoczne 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. Jeśli pakiet A (klient_usług) jest powiązany zależnością z pakietem B (dostawcą_usług), wtedy wszystkie elementy o widoczności publicznej w B są widoczne w A. Zależność odwrotna nie zachodzi.

33 Reguły widoczności (2) «import» Reguły widoczności dla elementów klas
Cała zawartość klasy jest widoczna wewnątrz klasy. Elementy zawarte wewnątrz klasy, np. atrybuty czy operacje, 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 z nadklasy. 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 B +U -V «import» +X -Y

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

35 Specjalne rodzaje pakietów (1)
Fasada (ang. facade): zawiera wyłącznie odwołania do elementów zdefiniowanych w innych pakietach. Oznaczany jest stereotypem «facade». Model (ang. model): stanowi 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». Do oznaczania pakietu typu model wykorzystywany jest stereotyp tekstowy «model» albo stereotyp graficzny «model» Model przypadków użycia Model przypadków użycia

36 Specjalne rodzaje pakietów (2)
Podsystem (ang. subsystem): pakiet reprezentujący pewien spójnie i logicznie wyizolowany fragment systemu, posiadający dobrze wyspecyfikowany zbiór interfejsów do interakcji z otoczeniem. 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. Do oznaczania pakietu typu podsystem wykorzystywany jest stereotyp tekstowy «subsystem» albo stereotyp graficzny «subsystem» Zamówienia Zamówienia

37 Specjalne rodzaje pakietów (3)
Szkielet (ang. framework): pakiet będący rodzajem wzorca projektowego, stanowiącego rozwiązanie dla pewnej klasy problemów. Do oznaczania pakietu typu szkielet wykorzystywany jest stereotyp «framework». Biblioteka elementów modelu (ang. model library): pakiet stanowiący zgrupowanie elementów modelu, wykorzystywanych przez inne pakiety – analogia do biblioteki klas w obiektowym języku programowania. Do oznaczania pakietu typu biblioteka elementów modelu wykorzystywany jest stereotyp «modelLibrary».

38 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 wewnątrz dokładnie jednej przestrzeni nazw (ang. home package). Pakiet, oprócz elementów modelu, może też zawierać inne pakiety (zagnieżdżanie). Są pakiety specjalnego rodzaju: fasada, model, podsystem, szkielet, biblioteka elementów modelu. 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.