E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 11, Slajd 1

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 implementacyjne i pakietów

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 11, Slajd 2

Zagadnienia

 Diagramy komponentów

 Diagramy wdrożeniowe

Diagramy pakietów

Diagramy implementacyjne:

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 11, Slajd 3

Diagramy implementacyjne

 Diagramy komponentów pokazujące zarówno implementację
elementów projektu (np. grupy 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 za ich pomocą odpowiednich parametrów
wydajnościowych.

UML wprowadza dwa rodzaje takich diagramów:

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 11, Slajd 4

Diagramy komponentów (1)

interfejs bez nazwy

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

komponent

interfejs nazwany

zależność

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 11, Slajd 5

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ć
wzajemnych

zależności

między

komponentami;

diagram

komponentów pokazuje również, 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:

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 11, Slajd 6

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

rezerwacje

KomputerJacka:PC

:Program

planujący

połączenie komunikacyjne

komponent sprzętowy

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 11, Slajd 7

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

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 11, Slajd 8

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, itp. z
reguły nie pojawia się jako bezpośrednia zawartość pakietu.
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ą (ang. dependency).
Strzałki wyznaczają kierunek przepływu informacji pomiędzy pakietami.
Pakiety mogą być zagnieżdżane.
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) oraz tworzonych przez grupę
współpracujących osób.

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 11, Slajd 9

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.

Ostatni przypadek dotyczy 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 (jak dla
każdego rodzaju diagramów) szczegóły nie powinny utrudniać
rozumienia.

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 11, Slajd 10

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ść

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 11, Slajd 11

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 elementów drugiego pakietu.

P

A

x:E

Q

E

«import»

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

E

«access»

Dla zależności typu

«

access

»

nazwa,

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

oznaczenie
klasy

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 11, Slajd 12

Reguły widoczności

Pakiet widzi zawartość tych pakietów, które są 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. Symbole + (publiczna), - (prywatna), # (chroniona) są
używane na oznaczenie widoczności elementu zawartego w pakiecie 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 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 B dziedziczy po pakiecie A, wtedy wszystkie elementy w
A, o widoczności publicznej lub chronionej, są widoczne w B.

 Jeśli element jest widoczny w pakiecie A, to jest widoczny we
wszystkich pakietach, które są w A zagnieżdżone.

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.

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 11, Slajd 13

Reguły widoczności (2)

Reguły widoczności dla elementów klas:

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

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

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 11, Slajd 14

Reguły widoczności; przykład

A

+X

B

C

+K

-L

«

access

»

A

+X

B

C

+K

-L

«

access

»

«

access

»

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 11, Slajd 15

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.

E. Stemposz, Analiza i Projektowanie Systemów Informatycznych,
Wykład 11, Slajd 16

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