No Slide Title

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

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

Wyślij to,

zamówiono

Pamiętaj,

wysłano

Skompletuj

zamówieni

Pła

Klient

Dział Sprzedaży

Magazyn

:Zamówienie

[wprowadzone]

:Zamówienie

[skompletowane]

:Zamówienie

[wysłane]

:Zamówienie

[umieszczone]

Wystaw

zamówieni

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

wykorzystaniem

rombu

decyzyjnego}

[sprawdzono
wszystkich
serwisantów ]

Anulowani

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

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.

x:E

«import»

Nazwy z pakietów zaimportowanych
za pomocą zależności typu

import

są dodawane do przestrzeni nazw
pakietu

importującego.

diagramie: nazwy z pakietu Q są
dodawane

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

x: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:

-Y

-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

(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

-L

access

-L

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.

Document Outline