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 aktywności
Diagramy implementacyjne i pakietów

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

Zagadnienia

Diagramy aktywności

 Diagramy komponentów

 Diagramy wdrożeniowe

Diagramy pakietów

Diagramy implementacyjne:

 Notacja

 Swimlanes

 Modelowanie iteracji

 Podsumowanie diagramów dynamicznych

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

Diagramy aktywności

Diagramy aktywności nie posiadają wyraźnego pierwowzoru w
poprzednich pracach “trzech przyjaciół” (Jacobsona, Boocha i
Rumbaugha). Łącząc idee pochodzące z trzech źródeł: diagramów
zdarzeń J. Odell’a, technik modelowania stanów i sieci Petriego i są
szczególnie użyteczne przy modelowaniu przepływów operacji czy też w
opisie zachowań z przewagą przetwarzania współbieżnego.

Graf aktywności to maszyna stanów, której podstawowym zadaniem
nie jest analiza stanów obiektu, ale modelowanie przetwarzania
(przepływów operacji). Wierzchołki grafu aktywności odpowiadają
stanom wyróżnialnym w trakcie przetwarzania, a nie stanom obiektu i
noszą nazwę aktywności. Aktywność może być interpretowana różnie,
w zależności od perspektywy: jako zadanie do wykonania i to zarówno
przez człowieka, jak i przez komputer (z perspektywy pojęciowej) czy
też np. jako pojedyncza metoda (z perspektywy projektowej). Podobnie,
przejścia między wierzchołkami nie są tu wiązane z nadejściem
zdarzenia, ale z zakończeniem przetwarzania wyspecyfikowanego dla
danej aktywności (odpowiednik przejścia automatycznego dla
diagramów stanu).

Diagramy aktywności z zasady nie pokazują wszystkich szczegółów
przetwarzania.

Pokazują

aktywności

bez

pokazywania

bytów,

realizujących daną aktywność i dlatego z reguły używane są jako punkt
startowy dla procesu modelowania zachowań. Dla skompletowania
projektu każda aktywność powinna być rozpisana na szereg operacji, z
których każdą trzeba będzie na późniejszym etapie przydzielić do
odpowiedniej klasy.

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

Notacja

Notacja przyjęta w UML dla diagramów aktywności:

nazwa

aktywności

aktywność

(z

zaokrąglonymi

bokami)
przejście, rzadko opisywane nazwą zdarzenia,
ponieważ z reguły oznacza zakończenie aktywności;
może być opatrzone warunkiem, może też być
oznaczone symbolem iteracji; akcje opisujące przejścia
powinny być raczej dołączane do którejś z aktywności;
kreska ciągła oznacza przepływ sterowania, a
przerywana − przepływ obiektu

romb decyzyjny, który może rozdzielać jedno
przejście na kilka innych (opatrzonych warunkami) lub
łączyć kilka alternatywnych przejść w jedno
sztabka synchronizująca (ang. synchronization bar);
może być typu “fork” (rozdzielenie jednej operacji na
kilka przebiegających równolegle) lub typu “join”
(złączenie kilku operacji równoległych w jedną)

aktywność początkowa

aktywność końcowa

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

Diagramy aktywności; przykład

Osoba::Przygotowanie Napoju

Znajdź
Napój

Nasyp
kawy
do filtru

Dolej wody
do
zbiornika

Włóż filtr
do
maszynki

Włącz
maszynkę

Gotowanie
kawy

Nale
j
kawę

Zrób
herbatę

Weź sobie
wody

[nie ma kawy]

[kawa znaleziona]

[nie ma herbaty]

[herbata
znaleziona]

światełko zgasło

Weź
filiżank
i

Wypi
j

*[dla 3 filiżanek]

join

fork

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

Swimlanes (1)

Diagramy aktywności opisują przepływy operacji, ale nie specyfikują,
kto jest odpowiedzialny za ich wykonanie, np. którzy ludzie czy które
komórki organizacyjne (z perspektywy pojęciowej) czy też które klasy
(z perspektywy projektowej). Można opisywać każdą aktywność podając
osobę czy klasę odpowiedzialną za jej wykonanie, ale być może
wygodniejszym sposobem przenoszenia informacji tego rodzaju jest
grupowanie aktywności odpowiednio do odpowiedzialności i
umieszczanie ich w oddzielnych regionach rozdzielonych pionowymi
liniami (jak na następnej folii). Regiony − z powodu swojego wyglądu −
są traktowane jak tory dla przepływów (tory pływackie, ang.
swimlanes). Nazwy regionów mogą odpowiadać nazwom osób, komórek
organizacyjnych czy klas odpowiedzialnych za wykonanie aktywności.

Na diagramach aktywności, oprócz przepływów sterowania można też
pokazywać przepływy obiektów. Obiekt może stanowić daną wejściową
dla aktywności (linia przerywana prowadzi wtedy od obiektu do
aktywności) czy też daną wyjściową (linia przerywana idzie od
aktywności do obiektu). W takim przypadku nie zamieszczamy na
diagramie przepływu sterowania (patrz następna folia).

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

Swimlanes (2)

Pobierz

zamówieni

e

Wyślij to,

co

zamówiono

Pamiętaj,

co

wysłano

Skompletuj

zamówieni

e

Pła

ć

Klient

Dział Sprzedaży

Magazyn

:Zamówienie

[wprowadzone]

:Zamówienie

[skompletowane]

:Zamówienie

[wysłane]

:Zamówienie

[umieszczone]

Wystaw

zamówieni

e

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

Modelowanie iteracji; przykład (1)

Wyszukiwanie serwisantów,

którzy potrafią naprawiać

dane uszkodzenie

* [ dla wszystkich serwisantów ]

Wyszukiwanie

serwisanta

z najlepszym terminem

{multiple

trigger

−

wszystkie

aktywności są odpalane jednocześnie }

{synchronizacja

aktywności,

które

zostały

jednocześnie

odpalone;

może

być

opuszczona}

Przydzielanie naprawy

wybranemu

serwisantowi

Wyszukiwanie 1-szego wolnego terminu

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

Modelowanie iteracji; przykład (2)

Wyszukanie serwisantów,

którzy potrafią naprawiać

dane uszkodzenie

Przydzielenie

naprawy

serwisantowi

Sprawdzenie, czy

serwisant

ma czas w ciągu

najbliższego tygodnia

{nie ma/ma/sprawdzono
wszystkich serwisantów}

[ma]

[nie ma]

{rozwiązanie

z

wykorzystaniem

rombu

decyzyjnego}

[sprawdzono
wszystkich
serwisantów ]

Anulowani

e

zgłoszenia

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

Przykład dla wymagań z biblioteką (1)

Uproszczony scenariusz dla przypadku użycia: wypożyczenie egzemplarza książki

 Sprawdzenie, czy można wypożyczyć danemu czytelnikowi
o ile można, to:

 Sprawdzenie, czy książka jest dostępna (czy jest wolny egzemplarz)
o ile jest dostępny egzemplarz, to:

 Rejestracja wypożyczenia

Personel

biblioteczny

Wypożyczenie

egzemplarza książki

Sprawdzenie, czy można

wypożyczyć danemu czytelnikowi

Sprawdzenie

dostępności książki

Rejestracja wypożyczenia

egzemplarza

«include»

«extend»

«exten
d»

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

Przykład dla wymagań z biblioteką (2)

Sprawdzenie,

czy można

wypożyczyć

danemu czytelnikowi

Sprawdzenie

dostępności

książki

Rejestracja

wypożyczenia

egzemplarza

książki

[ można]

[ nie można ]

[ dostępna ]

[ niedostępna ]

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

Podsumowanie diagramów

dynamicznych

Kiedy używać diagramów aktywności:

 Do analizowania przypadków użycia − gdy interesują nas bardziej
operacje niezbędne do realizacji danego przypadku (czy też wzajemne
zależności między tymi operacjami), a nie to, kto jest odpowiedzialny
za ich przeprowadzenie. Przypisanie operacji do obiektów jest
wykonywane na etapie późniejszym z wykorzystaniem diagramów
interakcji.

 Do zrozumienia interakcji zachodzących między przypadkami użycia
(ważne zastosowanie).

 Do modelowania przetwarzania wielowątkowego.

Kiedy nie używać diagramów aktywności:

 Do pokazywania współpracy między obiektami w trakcie realizacji
przypadku użycia − do tego bardziej nadają się diagramy interakcji.

 Do pokazywania zachowań obiektów w trakcie ich życia, w tym celu
powinno się wykorzystywać diagramy stanów.

Prosta reguła na wykorzystywanie diagramów dynamicznych w
procesie modelowania zachowań:
 jeden przypadek użycia, wiele obiektów − diagramy interakcji,

 wiele przypadków użycia, jeden obiekt − diagramy stanów,

 wiele przypadków użycia, wiele obiektów − diagramy aktywności.

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

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 14

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 15

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 16

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 17

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 18

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 19

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 20

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 21

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 22

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 23

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 24

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 25

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 26

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.