Wykład 7: Diagramy implementacyjne oraz diagramy pakietów

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.
7.2.1
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.
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.
cod Ticket reservation system
component
named interface
IReservations
Ticket reservation
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.
cod SHOP
IOrder
«delegate»
IPerson
«component»
«component»
IOrder
Orders
IPerson
Clients
IAccount
IProduct
ball&socket
IProduct
«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.
7.2.2
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).
cod Law office
People handling
User interface
Cases handling
Rys. 3 Diagram komponentów dla systemu wspierającego pracę kancelarii prawniczej
7.2.3
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
node
:Ticket
reservation
:User
interface
IReservations
Rys. 4 Przykładowy diagram wdroŜeniowy
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
Web Client
Accounting
server
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
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 B1
Package B2
Package B2
Package B3
Package B3
Package B4
Package B4
Package A
+
Package B1
Package B2
Package B3
Package B4
Rys. 6 RóŜne sposoby prezentowania zagnieŜdŜania pakietów
7.3.1
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.
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
«import»
A
E
X: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
«access»
E
X:Q::E
Rys. 8 Ilustracja zaleŜności typu «access»
7.3.2
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.
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
+U
«access»
-Y
-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
«access»
+X
«access»
+X
C
B
C
+K
+K
B
-L
-L
«access»
Rys. 10 Wykorzystanie zaleŜności poprowadzonej od wewnętrznej granicy pakietu
7.3.3
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
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.
7.3.4
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.
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».
Są
środkiem
ogólnego
przeznaczenia
•
7.5
W praktyce, podsystemy są implementowane jako komponenty, co upraszcza transformację modelu
logicznego w model implementacyjny.
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.