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

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

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.

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

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

Reguły widoczności; przykład

-L

access

-L

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.

Document Outline