Kategoria modelowania

Transkrypt

1 7 Diagramy implementacyjne oraz diagramy pakietów 7.1 Wstęp Diagramy implementacyjne słuŝą do ilustracji dwóch aspektów implementacji systemu informatycznego: struktury kodu i konfiguracji elementów czasu wykonania. Diagramy pakietów z kolei, są budowane przede wszystkim dla duŝych projektów, tworzonych przez duŝą grupę współpracujących osób, projektów składających się z wielu jednostek funkcjonalnych, ze złoŝonymi zaleŝnościami pomiędzy tymi jednostkami. Zadaniem pakietów jest grupowanie elementów danego (jednego) modelu, wraz z występującymi pomiędzy tymi elementami relacjami. Istnieje co najmniej kilka powodów, dla których warto jest uŝywać diagramów pakietów: W celu ukrycia mniej istotnych elementów modelu (podobnie jak zilustrowano to w przykładzie o subkolaboracji umieszczonym w wykładzie dotyczącym diagramów interakcji). Dla ułatwienia podziału pracy między członkami zespołu czy teŝ róŝnymi zespołami. Dla ułatwienia procesu zarządzania budową produktu informatycznego. 7.2 Diagramy implementacyjne UML definiuje dwa rodzaje diagramów implementacyjnych: Diagramy komponentów ilustrują strukturę kodu projektowanego systemu poprzez specyfikowanie implementacji elementów projektu (np. klas czy podsystemów) za pomocą komponentów i ich interfejsów, oraz wskazanie zaleŝności występujących pomiędzy komponentami. Celem identyfikacji komponentów jest budowa systemów o odpowiednio wysokiej jakości, wypełniających poŝądane potrzeby biznesowe i budowanych szybko raczej poprzez składanie z gotowych części niŝ poprzez wypracowywanie kaŝdego elementu samodzielnie. Taki sposób pracy jest korzystny dla budowy np. rodziny aplikacji: niektóre komponenty opłaca się opracować samodzielnie, a niektóre warto odszukać wśród gotowych, istniejących juŝ w organizacji czy na rynku i ewentualnie zaadaptować do aktualnych potrzeb. Diagramy wdroŝeniowe pokazują konfigurację systemu czasu wykonania, czyli rozmieszczenie komponentów i obiektów na węzłach. Węzły modelują obliczeniowe zasoby czasu wykonania. Taka konfiguracja moŝe być zarówno statyczna, jak i dynamiczna: komponenty i obiekty mogą migrować między węzłami w czasie wykonania. Omówienie diagramów implementacyjnych rozpoczniemy od diagramów komponentów Diagramy komponentów Komponent stanowi nietrywialną, dobrze wyizolowaną z kontekstu jednostkę implementacji, spójną ze względu na wypełniane funkcje (wysoka kohezja, słabe sprzęŝenia) i posiadającą dobrze zdefiniowany interfejs; z załoŝenia, komponent nadaje się do wielokrotnego uŝycia. Prawidłowo 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. MoŜna wyróŝnić kilka rodzajów komponentów: komponenty z perspektywy jednego projektu, komponenty z perspektywy całości rozwoju oprogramowania w danej organizacji oraz komponenty biznesowe (np. do obsługi zamówień, sprzedaŝy, itp.). Kategorie modelowania, wykorzystywane przy konstruowaniu diagramów komponentów w UML 2.*, przedstawiono w Tab. 1.

2 Kategoria modelowania Notacja komponent interfejs udostępniający interfejs pozyskujący port Port złoŝony zaleŝność realizacja «realize» Konektor delegowany «delegate» Konektor składany Tab. 1 Kategorie modelowania dla diagramu komponentów w UML 2.* Komponenty mogą być opatrywane stereotypami. Przykładowe stereotypy to: podsystem (ang. subsystem), program wykonywalny (ang. executable), biblioteka (ang. library) i baza danych/tabela bazy danych (ang. table). Przykładowe diagramy komponentów przedstawiają Rys. 1 i Rys. 2.

3 cod Ticket reservation system component named interface Ticket reservation IReservations dependency User interface Repertoire updating unnamed interface Rys. 1 Przykładowy diagram komponentów (1) Diagramy komponentów pokazują zaleŝności pomiędzy komponentami oprogramowania. Komponenty mogą istnieć w róŝnym czasie: niektóre z nich w czasie kompilacji (komponenty kodu źródłowego), niektóre w czasie konsolidacji (komponenty kodu binarnego), zaś niektóre tylko w czasie wykonania (komponenty kodu wykonywalnego). Diagram komponentów jest przedstawiany w postaci grafu skierowanego, gdzie węzłami są komponenty, a łuki w postaci strzałek z przerywaną linią modelują zaleŝności występujące pomiędzy klientami i dostawcami pewnej informacji. Bezpośrednia specyfikacja klientów i dostawców informacji ma duŝe znaczenie dla przeprowadzania modyfikacji elementów systemu: zmiany wprowadzane do elementu modelującego dostawcę pewnej informacji mogą skutkować koniecznością wprowadzania zmian do elementów modelujących jej klienta.

4 cod SHOP IOrder «delegate» IOrder «component» Orders IPerson IPerson «component» Clients IProduct IProduct ball&socket IAccount «delegate» «component» Products IAccount Rys. 2 Przykładowy diagram komponentów (2) Zbiór komponentów składających się na kod systemu moŝe być opisany na dwa sposoby: Poprzez utworzenie listy komponentów wraz ze specyfikacją ich zaleŝności jest to tzw. biblioteka komponentów. W tym przypadku bardzo pomocne jest nazywanie interfejsów. Poprzez diagram komponentów ilustrujący sieć ich wzajemnych zaleŝności. Diagram komponentów pokazuje takŝe, za realizację jakiego interfejsu jest odpowiedzialny kaŝdy z komponentów Przykład z kancelarią prawniczą Na Rys. 3 zaprezentowano diagram komponentów skonstruowany w oparciu o tekst specyfikujący wymagania dla systemu wspierajacego pracę kancelarii prawniczej (rozdział 2, podrozdział 2.10).

5 cod Law office People handling User interface Cases handling Rys. 3 Diagram komponentów dla systemu wspierającego pracę kancelarii prawniczej Diagramy wdroŝeniowe Diagramy wdroŝeniowe przedstawiają konfigurację następujących elementów czasu wykonania: komponentów sprzętowych, czyli fizycznych jednostek posiadających pamięć, a często równieŝ moc obliczeniową; komponentów oprogramowania (kod wykonywalny); obiektów związanych z komponentami. Diagram wdroŝeniowy jest grafem, gdzie wierzchołki, zwane tu węzłami, połączone są liniami odwzorowującymi połączenia komunikacyjne komponentów sprzętowych (Rys. 4). Węzły, podobnie jak połączenia komunikacyjne, mogą być opatrzone stereotypami, np.: «CPU», «pamięć». Węzły przechowują obiekty i wystąpienia komponentów; węzły mogą brać udział w związkach generalizacji. dd Ticket reservation system communication channel :Server :Laptop :Ticket reservation IReservations :User interface node Rys. 4 Przykładowy diagram wdroŝeniowy

6 W UML istnieje moŝliwość zastąpienia symboli standardowych symbolami specjalnymi, które mogą znacząco ułatwiać percepcję diagramów (Rys. 5). Main server Corporate Ethernet Internet Accounting server Web Client Local branch Ethernet Windows-based PC Windows-based PC Rys. 5 Diagram wdroŝeniowy z wykorzystaniem specjalnych symboli 7.3 Diagramy pakietów Pakiety grupują elementy danego (jednego) modelu wraz z występującymi pomiędzy tymi elementami relacjami. Elementy, wchodzące w skład pakietu, to tzw. elementy wysokiego poziomu, 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, wnętrza stanów zagnieŝdŝonych, linie Ŝycia, komunikaty, itp., z reguły nie pojawia się jako bezpośrednia zawartość pakietów. Pakiet zazwyczaj nie posiada swojego interfejsu (oprócz specjalnego rodzaju pakietu zwanego podsystemem patrz podpunkt omawiający specjalne rodzaje pakietów 7.3.3) a zaleŝności występujące pomiędzy pakietami wynikają z relacji między ich elementami składowymi. ZaleŜności są przedstawiane na diagramach pakietów w postaci strzałek z przerywaną linią i mogą być opatrywane stereotypami. Relacje między elementami, opisywane pośrednio przez zaleŝności, mogą być róŝnego rodzaju, ale tego typu informacja zazwyczaj nie jest przenoszona przez diagramy pakietów dzięki specyfikacji zaleŝności uwidaczniany jest jedynie fakt występowania relacji, a nie jej rodzaj, np. fakt istnienia asocjacji między dwiema klasami umieszczonymi w dwóch róŝnych pakietach. Bezpośrednie pokazywanie relacji pomiędzy elementami zawartymi w róŝnych pakietach nie jest zabronione, zaleca się raczej jedynie podkreślanie faktu ich występowania. Dla diagramów pakietów obowiązuje taka sama zasada abstrakcji, jak wszystkich poprzednio omawianych rodzajów diagramów: szczegóły nigdy nie powinny utrudniać rozumienia całości. Pakiety mogą być zagnieŝdŝane oraz mogą brać udział w związkach dziedziczenia, co jest zaznaczane analogicznie jak na diagramach klas. Dany model zazwyczaj opisywany jest przez wiele pakietów. Definicja kaŝdego elementu wchodzącego w skład modelu moŝe znajdować się tylko w jednym z pakietów opisujących model. Podział modelu na pakiety jest arbitralny, ale u jego podstaw powinny leŝeć racjonalne przesłanki, np. wspólna funkcjonalność, silne skojarzenia, itp. Kategorie modelowania, wykorzystywane przy konstruowaniu diagramów pakietów w UML 2.*, przedstawiono w Tab. 2. Jak widać, pakiet jest przedstawiany w postaci duŝego prostokąta z małym prostokątem, zwanym etykietą, umieszczonym w lewym górnym rogu. JeŜeli zawartość pakietu nie jest pokazana, wówczas nazwa pakietu jest wpisana do większego prostokąta; w przeciwnym przypadku nazwa pakietu jest umieszczana w etykiecie. Kategoria modelowania Notacja

7 pakiet zaleŝność zagnieŝdŝanie + Tab. 2 Kategorie modelowania dla diagramów pakietów w UML 2.* Rys. 6 przedstawia róŝne sposoby prezentowania zagnieŝdŝania pakietów. Package A Package A Package B1 Package B2 Package B1 Package B2 Package B3 Package B4 Package B3 Package B4 Package A + Package B1 Package B2 Package B3 Package B4 Rys. 6 RóŜne sposoby prezentowania zagnieŝdŝania pakietów Odwołania między pakietami Pakiet (klient), który odwołuje się do elementu w innym pakiecie (dostawcy informacji), moŝe wykorzystać pakiet zawierający ten element, uŝywając zaleŝności typu «import» albo «access» (będących rodzajami zaleŝności typu «usage»). Główną cechą róŝniącą oba rodzaje zaleŝności jest odmienny sposób traktowania nazw elementów.

8 Nazwy z pakietów zaimportowanych za pomocą zaleŝności typu «import» są dodawane do przestrzeni nazw pakietu importującego. Na przykład na diagramie z Rys. 7 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 (uwaga: moŝe tutaj wystąpić konflikt nazw). Class notion P Q A X:E «import» E Rys. 7 Ilustracja zaleŝności typu «import» Dla zaleŝności typu «access» nazwa, do której następuje odwołanie, musi być poprzedzona nazwą pakietu, w którym jest zdefiniowana. Na Rys. 8 pokazano, Ŝe atrybut X w klasie A zawartej w pakiecie P będzie wystąpieniem klasy E, której definicja została umieszczona w pakiecie Q. Nazwa klasy E została poprzedzona nazwą pakietu Q, co ma zapobiec wystąpieniu konfliktu nazw. P Q A X:Q::E «access» E Rys. 8 Ilustracja zaleŝności typu «access» Reguły widoczności Pakiet widzi wszystkie zewnętrzne dla niego pakiety poprzez pakiet, wewnątrz którego jest zagnieŝdŝony; innymi słowy, zagnieŝdŝony pakiet widzi wszystko to, co widzi pakiet, który go zawiera. Specjalne symbole + (publiczny), (prywatny) oraz # (chroniony) są uŝywane na oznaczenie widoczności elementu zawartego w pakiecie na zewnątrz pakietu. Zasady widoczności dla elementów zawartych w pakietach są następujące: 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 pakiet B jest powiązany zaleŝnością z pakietem A, to wtedy wszystkie elementy o widoczności publicznej w A są widoczne w B. Jeśli pakiet B dziedziczy z pakietu A, to wtedy wszystkie elementy w A o widoczności publicznej lub chronionej są widoczne w B. ZaleŜności nie są przechodnie, tzn. jeśli A jest połączone zaleŝnością z B, a B z C, to nie znaczy, Ŝe A jest połączone zaleŝnością z C. ZaleŜności nie są teŝ symetryczne. Ponadto, UML określa następujące reguły widoczności dla elementów klas w pakietach: 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.

9 Rys. 9 stanowi ilustrację powyŝszych reguł. Pakiet A jest powiązany zaleŝnością typu «access» z pakietem B; zaleŝność odwrotna nie występuje. Klasa U w pakiecie B o widoczności publicznej jest dostępna dla klas X i Y w pakiecie A. Klasa V, jako klasa o widoczności prywatnej, nie jest dostępna dla klas z pakietu A. Klasy U i V nie mają dostępu do Ŝadnej klasy w pakiecie A pomimo publicznej widoczności klasy X (brak odpowiedniej zaleŝności pakiet B nie ma dostępu do pakietu A). Klasy X i Y, podobnie jak U i V, jako klasy zdefiniowane w tym samym pakiecie widzą nawzajem swoje publiczne elementy. A B +X -Y «access» +U -V Rys. 9 Ilustracja reguł widoczności dla pakietów Z kolei Rys. 10 pokazuje sposób, w jaki moŝna uczynić diagram bardziej czytelnym prowadząc zaleŝność od wewnętrznej granicy pakietu; zaleŝność ta oznacza, Ŝe wszystkie elementy zawarte w pakiecie A odwołują się do publicznych elementów pakietu C. Podobny sposób upraszczania diagramów polegający na zmniejszeniu liczby elementów bez utraty informacji był juŝ prezentowany dla diagramów stanów przy opisie stanów złoŝonych. A A +X «access» +X «access» C C B +K B +K -L -L «access» Rys. 10 Wykorzystanie zaleŝności poprowadzonej od wewnętrznej granicy pakietu Specjalne rodzaje pakietów UML wyróŝnia następujące specjalne rodzaje pakietów: «fasada» (ang. «facade») zawiera wyłącznie odwołania do elementów zdefiniowanych w innych pakietach. «model» stanowi abstrakcję systemu widzianą z pewnej perspektywy. Zwykle zawiera 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ę na przykład ilością detali, co moŝe wymuszać potrzebę łączenia ich zaleŝnością typu «trace» czy «refinement». «podsystem» (ang. «subsystem») reprezentuje pewien spójny, logiczny, wyizolowany z kontekstu fragment systemu oraz posiada dobrze wyspecyfikowany zbiór interfejsów do interakcji z otoczeniem. Podsystem podzielony jest na dwie części: specyfikacyjną i realizacyjną. Część specyfikacyjna zawiera

10 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 specyfikowanych w pierwszej części opisu podsystemu. Podsystemy mogą być zbudowane z innych podsystemów, przy czym podsystemy najniŝszego poziomu muszą zawierać elementy modelu. Podsystem stanowi zgrupowanie elementów modelu logicznego, podczas gdy komponent jest zgrupowaniem elementów modelu implementacyjnego. W wielu przypadkach podsystemy są implementowane jako komponenty, co upraszcza transformację modelu logicznego w implementacyjny i przez to jest powszechnie stosowanym podejściem Przykład z kancelarią prawniczą Na Rys. 11 zaprezentowano diagram pakietów skonstruowany w oparciu o tekst specyfikujący wymagania dla systemu wspierajacego pracę kancelarii prawniczej (rozdział 2, podrozdział 2.10). pd Law office People handling Cases handling User interface Rys. 11 Diagram pakietów dla systemu wspierającego pracę kancelarii prawniczej 7.4 Podsumowanie Konstruowanie diagramów implementacji jest uŝyteczne zarówno ze względu na ponowne uŝycie, jak i ze względu na moŝliwość uzyskania za ich pomocą odpowiednich parametrów wydajnościowych projektowanego systemu. Z kolei stosowanie pakietów ułatwia zarządzanie przechowywaniem, konfiguracjami oraz modyfikowaniem elementów systemu dobrze przeprowadzony podział na pakiety moŝe znacząco ułatwić zarządzanie procesem budowy produktu programistycznego. Problematykę diagramów pakietów moŝna podsumować następująco: Pakiety stanowią zgrupowanie elementów modelu. Są środkiem ogólnego przeznaczenia wykorzystywanym do budowy 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 (ang. home package). Oprócz elementów modelu pakiet moŝe takŝe zawierać inne pakiety (poprzez zagnieŝdŝanie). Pakiety mogą brać udział w związkach dziedziczenia. WyróŜnia się pakiety specjalnego rodzaju, m.in. «fasada», «model» oraz «podsystem».

11 W praktyce, podsystemy są implementowane jako komponenty, co upraszcza transformację modelu logicznego w model implementacyjny. 7.5 Przykładowe pytania i problemy do rozwiązania 1. Krótko scharakteryzuj cel budowy diagramów implementacyjnych. 2. Wymień i omów rodzaje diagramów implementacyjnych. 3. Zdefiniuj pojęcia: komponent, wystąpienie komponentu, interfejs, port, zaleŝność, węzeł. 4. Kiedy, w jakich sytuacjach i w jakim celu wykorzystywane są diagramy pakietów? 5. Podaj notację UML dla pakietu w oparciu o prosty przykładowy diagram. 6. Jakie rodzaje związków mogą występować między pakietami? 7. Wymień i krótko omów specjalne rodzaje pakietów. 8. Co oznacza pojęcie: home package? 9. Jaka zaleŝność występuje pomiędzy pojęciami: podsystem i komponent? Na jakim etapie cyklu Ŝyciowego produktu informatycznego funkcjonuje kaŝde z tych pojęć? 10. W oparciu o tekst specyfikujący wymagania dla systemu wspierającego pracę wypoŝyczalni płyt dvd (rozdział 2, podrozdział 2.12), skonstruuj diagram pakietów oraz diagram komponentów.