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

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:

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:

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

Symbol

Znaczenie

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)

<nagłówek-diagramu> = (<wyróżnik_diagramu>) + <nazwa-diagramu> + {<parametr>}

dd Nazwa diagramu

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

Kategorie modelowania (1)

Kategoria

modelowania

Notacja

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)

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

Kategorie modelowania (2)

Kategoria

modelowania

Notacja

zależność
(ang. dependency)

realizacja
(ang. realization)

Konektor delegowany
(ang. connector with

«delegate»

stereotype )

Konektor składany
(ang. ball & socket)

«realize»

«delegate»

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

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:

Stereotyp

Zawartość komponentu

«subsystem»

podsystem

«executable»

program wykonywalny

«library»

biblioteka oprogramowania

«table»

baza danych; tabela baz

danych

«executable»

Harmonogramy.exe

«table»

Harmonogramy.db

Przykłady:

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»

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

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

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

Alternatywna reprezentacja zawartości

komponentu

«component»

Zamówienia

Zamówienie

WierszZamówienia NagłówekZamówienia

1

*

IZamówienie

IOsoba

IFaktura

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»

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ówienia

NagłówekZamówienia

1

*

IZamówienie

IOsoba

IFaktura

«delegate»

«delegate»

port

konektor
delegowany

port
złożony

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»

«delegate»

konektor
składany

IKonto

IZamówienie

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

1

1..*

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

PC z Windows

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

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»

«deploy»

«deploy»

«deploy»

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

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.

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)

<nagłówek-diagramu> = (<wyróżnik_diagramu>) + <nazwa-diagramu> + {<parametr>}

pd Nazwa diagramu

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

Kategorie modelowania

Kategoria

modelowania

Notacja

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.

+

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

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

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)

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

+

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

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” <nazwa_kwalifikowana> ”}”
”{access” <nazwa_kwalifikowana> ”}”

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»

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.

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

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

»

«

import

»

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

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

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

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.