Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

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

Podobne prezentacje


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

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

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

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

4 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 4 Adaptacja notacji BNF =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 SymbolZnaczenie

5 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 5 Prezentowanie diagramów implementacyjnych cod Nazwa diagramu cod – wyróżnik diagramu komponentów (component diagram) dd – wyróżnik diagramu wdrożeniowego (deployment diagram) = ( ) + + { } dd Nazwa diagramu

6 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 6 Kategorie modelowania (1) Kategoria modelowaniaNotacja 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 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 7 Kategorie modelowania (2) Kategoria modelowaniaNotacja zależność (ang. dependency) realizacja (ang. realization) Konektor delegowany (ang. connector with «delegate» stereotype ) Konektor składany (ang. ball & socket) «realize» «delegate»

8 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 8 Komponent (1) Komponent: jednostka implementacji, dobrze wyizolowana z kontekstu, z dobrze zdefiniowanym interfejsem/interfejsami, nadająca się do wielokrotnego wykorzystania. IRezerwacja Harmonogramy UML 1.* IRezerwacja «component» Harmonogramy IRezerwacja Harmonogramy UML 2.0 IRezerwacja «component» Harmonogramy interface

9 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 9 Komponent (2) Przykładowe stereotypy wykorzystywane dla oznaczania zawartości komponentów: StereotypZawartość komponentu «subsystem»podsystem «executable»program wykonywalny «library»biblioteka oprogramowania «table»baza danych; tabela baz danych «executable» Harmonogramy.exe «table» Harmonogramy.db Przykłady:

10 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 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 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 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 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 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() perspektywa zewnętrzna; notacja tekstowa «component» Zamówienia « provided interfaces » IZamówienie «required interfaces» IFaktura IOsoba «realizations» Zamówienie NagłówekZamówienia WierszZamówienia «artifacts» Zamowienia.jar perspektywa wewnętrzna; notacja tekstowa

13 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 13 Alternatywna reprezentacja zawartości komponentu «component» Zamówienia Zamówienie WierszZamówieniaNagłówekZamówienia 1 * IZamówienieIOsobaIFaktura

14 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 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() «interface» IOsoba utwórzOsobę() podajDaneOsoby() znajdźOsobęPoNazwisku() «realize» «use»

15 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 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ówieniaNagłówekZamówienia 1 * IZamówienie IOsoba IFaktura «delegate» port konektor delegowany port złożony

16 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 16 Porty, konektory (2) «component» Zamówienia IZamówienie IProdukt IOsoba «component» Klienci IOsoba IKonto «component» Produkty IProdukt «component» Sklep «delegate» konektor składany IKonto IZamówienie

17 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 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. Serwer harmonogramów Komputer użytkownika «component» Planowanie IRezerwacja «component» Harmonogramy «serwer» «PC» «TCP/IP» węzeł połączenie komunikacyjne 11..*

18 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 18 Diagram wdrożeniowy; 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

19 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 19 Specyfikacja artefaktów/komponentów w węzłach (1) 1) Notacja tekstowa – 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 «component» Klienci «component» Produkty «artifact» FormularzZamówienia 2) Notacja graficzna – specyfikacja artefaktów i komponentów umieszczonych w węźle

20 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 20 Specyfikacja artefaktów/komponentów w węzłach (2) «serwer» Obsługa zamówień «component» Zamówienia «component» Klienci «component» Produkty «artifact» FormularzZamówienia 3) Notacja graficzna – specyfikacja artefaktów i komponentów połączonych z węzłem stereotypowaną zależnością «deploy» «deploy»

21 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 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 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 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 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 23 Reprezentowanie diagramów pakietów pd – wyróżnik diagramu komponentów (package diagram) = ( ) + + { } pd Nazwa diagramu

24 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 24 Kategorie modelowania Kategoria modelowaniaNotacja 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 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 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 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 26 Diagram pakietów; przykład Edytor Elementy diagramów graficznych Elementy dziedziny zastosowań Sterownik Rdzeń grafiki System okienkowy

27 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 27 Zagnieżdżanie pakietów (1) Edytor Elementy diagramów graficznych Sterownik Elementy dziedziny zastosowań Rdzeń grafiki Zagnieżdżanie pakietów można pokazywać na 3 sposoby: 1) Edytor Elementy diagramów graficznych Elementy dziedziny zastosowań Rdzeń grafiki Sterownik 2)

28 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 28 Zagnieżdżanie pakietów (2) 3) Edytor Elementy diagramów graficznych Sterownik Elementy dziedziny zastosowań Rdzeń grafiki +

29 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 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. 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 E «import» oznaczenie klasy Zależność typu « access » oznacza tzw. import prywatny. P A x : E Q «access» E

30 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 30 Odwołania; import publiczny/prywatny 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» Q P R S «access» «import» E {import } {access }

31 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 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 E R E Podklasa klasy E «import» «merge»

32 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 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 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 33 Reguły widoczności (2) 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: A +X -Y B +U -V « import » 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).

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

35 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 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 przypadków użycia «model» Model przypadków użycia

36 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 11b, Slajd 36 Specjalne rodzaje pakietów (2) «subsystem» Zamówienia 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 Zamówienia

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


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

Podobne prezentacje


Reklamy Google