1

Inżynieria oprogramowania

wykład 12

Projektowanie architektury systemów

2/31

Informacje podstawowe



projekt architektury → reprezentacja struktury programu i
danych



projekt architektury umożliwia i pomaga:



analizować zgodność projektu z wymaganiami



rozważać różne podejścia do tworzenia programu



ograniczyć ryzyko związane z konstruowaniem oprogramowania



architektura * :



ułatwia wymianę informacji między poszczególnymi uczestnikami
procesu wytwórczego



pozwala określić początkowe decyzje projektowe mające duży
wpływ na prowadzone później prace wytwórcze i sukces działania
systemu



stanowi model struktury systemu i współdziałania jego składników



style i wzorce architektury mogą być użyte w procesie
projektowania innych systemów (są przenośne)

* L. Bass, P. Clements, R. Kazman: „Software architecure in practice” , Addison-Wesley, 1998

3/31

Architektura oprogramowania



architektura oprogramowania* → struktura połączenia jego
składników programowych, widoczne z zewnątrz cechy
tych składników i związki, które między nimi zachodzą



składniki programowe → moduły programu, złożone
obiekty (bazy danych), oprogramowanie pośredniczące np.
w sieci typu klient-serwer



widoczne z zewnątrz cechy składników → pozwalają
zrozumieć współdziałanie składników programowych z
innymi, bez uwzględniania cech wewnętrznych np. użytych
algorytmów



związki między składnikami → wywołanie procedury z
innego modułu, protokoły dostępu do bazy danych, itp.

* L. Bass, P. Clements, R. Kazman: „Software architecture in practice” , Addison-Wesley, 1998

4/31

Projektowanie danych - opis



pierwszym krokiem jest opisanie danych oraz informacji
przetwarzanych przez oprogramowanie na wysokim poziomie
abstrakcji (z punktu widzenia użytkownika)



tak powstały opis w kolejnych krokach jest uszczegóławiany



architektura danych może mieć znaczący wpływ na architekturę
programu przetwarzającego te dane



na poziomie modułów i procedur poprawnie zaprojektowane struktury
danych mogą wpływać na jakość oprogramowania



na poziomie aplikacji struktura danych ma wpływ na realizację założeń
dotyczących funkcjonalności systemu



na poziomie przedsiębiorstwa/firmy dane zgromadzone w bazach
danych umożliwiają przeszukiwanie i gromadzenia danych/wiedzy,
kluczowe ze względu na działalność firmy

5/31

Projektowanie danych -realizacja



wynikiem modelowania analitycznego danych są
diagramy encja-związek i tzw. słowniki danych
(kompletny opis obiektu: nazwa, miejsca i sposób
użycia, zawartość, ograniczenia, wartości domyślne
itp.)



projektowanie danych polega na tłumaczeniu zapisów z
modelu analitycznego na konkretne struktury danych



realizacja odbywa się na poziomie pojedynczych
modułów i procedur, czasem (bazy danych) na
poziomie aplikacji

6/31

Zasady specyfikowania danych*



do specyfikowania danych powinny być stosowane zasady analizy stosowane do
opisu funkcji i zachowań systemu, z uwzględnieniem zawartości danych,
przepływu danych, organizacji danych i ich wpływu na projektowany system



niezbędna jest identyfikacja wszystkich struktur danych i operacji na nich



zalecane jest wykorzystywanie gotowych słowników danych



decyzje „niskopoziomowe” powinny być podejmowane możliwie najpóźniej –
wstępnie określanie ogólne architektury i uściślanie przy projektowaniu
konkretnych modułów



wewnętrzna struktura danych widoczna tylko wewnątrz modułów jej używających



w miarę możliwości gotowe struktury i wzorce operacji można gromadzić w
postaci szablonów w bibliotekach i wykorzystywać w innych projektach



zalecane jest posługiwanie się językami projektowania i programowania
udostępniającymi mechanizmy specyfikowania i realizowania abstrakcyjnych
typów danych

* A. Wasserman: „ Principles of systematic data design and implementation”, w: P. Freeman, A. Wasserman
„Software design techniques”, IEEE Computer Society Press, 1980

7/31

Style architektury



architektura skoncentrowana na danych



architektura oparta na przepływie danych



architektura wywołań i powrotów



architektura obiektowa



architektura warstwowa

8/31

Architektura skoncentrowana
na danych



głównym elementem jest magazyn danych, w formie pliku lub bazy
danych



z magazynu danych mogą korzystać inne moduły systemu (klienci),
wykonując operacje dodawania, usuwania i modyfikowania danych



magazyn pasywny → każdy klient może korzystać z zawartości
magazynu niezależnie od działań i modyfikacji wykonywanych przez
innych klientów



systemy o takiej architekturze można łatwo integrować – dodawać i
modyfikować składniki będące klientami – nie ma to wpływu na
działanie innych klientów (działają niezależnie)



dane przekazywane są między klientami poprzez magazyn



klient samodzielnie uruchamia potrzebne mu inne moduły klienckie

9/31

Architektura skoncentrowana
na danych - schemat

magazyn

danych

klient

klient

klient

klient

klient

10/31

Architektura oparta na
przepływie danych



przydatna szczególnie w systemach przetwarzających
dane wejściowe na wyjściowe w formie ciągu operacji
wykonywanych przez różne moduły systemu (filtry)



moduły działają niezależnie od siebie



moduły obierają dane w pewnym formacie a przekazują
dane w innym



potoki → połączenia przekazujące dane między
modułami



systemy z modułami powiązanymi w linii nazywane są
systemami sekwencyjnego przetwarzania wsadowego

11/31

Architektura oparta
na przepływie danych - przykład

filtr

filtr

filtr

filtr

filtr

filtr

filtr

filtr

filtr

filtr

filtr

filtr

filtr

architektura oparta

na przepływie

architektura

przetwarzania

sekwencyjnego

potoki

12/31

Architektura wywołań i powrotów



charakteryzują się możliwością łatwych zmian i
rozbudowy



rodzaje



architektura głównego programu → stosowana
często w programach komputerowych, wykorzystuje
hierarchię sterowania, program główny wywołuje
pewną liczbę procedur, które mogą wywoływać inne
procedury – projektowanie strukturalne



architektura zdalnego wywoływania procedur →
program główny i podprogramy rozmieszczone na
wielu komputerach połączonych w sieć

13/31

Architektura głównego
programu - przykład

M

a

b

e

d

c

f

h

g

i

j

l

k

n

m

o

p

14/31

Architektura obiektowa



system składa się z:



danych



operacji manipulowania danymi



komunikacja i koordynacja między składnikami
→ prowadzona poprzez przesyłanie
komunikatów

15/31

Architektura warstwowa



system zbudowany jest z kilku warstw



warstwy odpowiedzialne są za różne zadania



składniki w warstwie wewnętrznej
odpowiedzialne są za komunikację z systemem
operacyjnym



składniki zewnętrzne odpowiedzialne są za
interfejs użytkownika



składniki warstw pośrednich realizują zadania
pomocnicze i funkcje programu

16/31

Architektura warstwowa - schemat

warstwa

jądra

warstwa

narzędzi

warstwa

aplikacji

warstwa interfejsu

użytkownika

składniki

warstwy

warstwy

architektury

17/31

Analiza wyboru projektu
architektury



analiza jakościowa metodą ATAM



analiza ilościowa



analiza złożoności architektury

18/31

Analiza jakościowa projektu
architektury metodą ATAM



ATAM (architecture trade-off analysis method) → metoda analizy
kompromisów w architekturze*



czynności analizy, wykonywane (powtarzane) wielokrotnie:



zebranie scenariuszy użycia – z punktu widzenia użytkownika



ustalenie wymagań, ograniczeń i opisów otoczenia



opis stylów/wzorców architektury wybranych do realizacji ustalonych
scenariuszy i spełnienia wymagań z perspektywy: modułów (ocena podziału
zadań i ukrywania danych), procesów (ocena efektywności systemu) i
przepływu danych (oceny czy architektura odpowiada wymaganiom
funkcjonalnym)



ocena kryteriów jakości (niezawodność, efektywność, bezpieczeństwo,
łatwość pielęgnacji, elastyczność, łatwość testowania)



ustalenie wrażliwości kryteriów jakości na cechy stylu architektury (np.
poprzez wprowadzenie drobnych zmian, kryteria jakości ulegające wtedy
zmianie to punkty wrażliwości)



porównanie różnych możliwych stylów architektury ze względu na
wrażliwość na zmiany

* R. Kazman i inni: „The architectural tradeoff analysis method” , Software Engineering Institute, 1998

19/31

Analiza ilościowa projektu
architektury* - analiza spektrum



polega na ulokowaniu analizowanego projektu między najlepszymi i
najgorszymi rozwiązaniami na podstawie oceny poszczególnych
kryteriów jakości



suma ocen kryteriów jakości implikuje ocenę całkowitą S



oblicza się również ocenę S

w

dla hipotetycznego najsłabszego

możliwego projektu i ocenę S

b

dla optymalnego projektu



indeks spektrum I

S

=[(S-S

W

)/(S

b

-Sw)]∙100



wartość I

S

– określa stopień zbliżenia projektu na optymalnego



indeks usprawnienia I

mp

=I

S1

-I

S2

w przypadku wprowadzania zmian w

projekcie, I

mp

>0 oznacza że system S1 jest lepszy niż S2.

* T. Asada i inni: „The quantified design space” , w M.Shaw, D. Garlan :„Software architecture”, Prentice-Hall,
1996

20/31

Analiza ilościowa projektu architektury* -
indeks wyboru projektu



d=(N

s

/N

a

)∙100



N

s

– liczba kryteriów spełnionych przez analizowane

rozwiązanie



N

a

– liczba wszystkich rozważanych kryteriów



im większa wartość d tym analizowany projekt bardziej
zbliżony jest do ideału

* T. Asada i inni: „The quantified design space” , w M.Shaw, D. Garlan :„Software architecture”, Prentice-Hall,
1996

21/31

Analiza ilościowa projektu architektury* -
analiza wkładu



pomaga określić przyczyny pogorszenia wyników będące
następstwem określonych decyzji projektowych



wykonuje się analizę podobną do QFD (jakość rozwijania
funkcji, wymagania normalne, oczekiwane i ekscytujące)



identyfikowane są wymagania klienta i mechanizmy ich
realizacji w postaci cech architektury



dla każdej analizowanej architektury ocenia się (1-10)
wagę związków między mechanizmami realizacji a
wymaganiami

* T. Asada i inni: „The quantified design space” , w M.Shaw, D. Garlan :„Software architecture”, Prentice-Hall,
1996

22/31

Analiza ilościowa projektu architektury* -
złożoność architektury



ocena ogólnej złożoności architektury na podstawie
zależności między składnikami architektury



związki ustalane na podstawie przepływu informacji i
sterowania w programie



zależności*:



dzielenia danych → przypadek korzystania przez dwa składniki z
tych samych zasobów lub dostarczania danych do tego samego
składnika



przepływu danych → przypadek gdy moduł x musi zakończyć
działanie przed przekazaniem sterowania do modułu y lub gdy
moduł x wywołuje moduł y z odpowiednimi parametrami



ograniczająca → ograniczenia na przepływ sterowania (np.
wykluczenie jednoczesnego wykonywania)

* J. Zhao: „On assessing the complxity of software architectures”, ACM, 1998

23/31

Miary złożoności projektów
architektury* (1)



złożoność strukturalna modułu i
S(i)=f

2

out

(i)

f

out

(i) – rozgałęzienie wyjściowe modułu i



złożoność danych – stopień skomplikowania interfejsu
modułu i
D(i)=v(i)/[f

in

(i) +1]

v(i) – liczba zmiennych wejściowych oraz wyjściowych
modułu i
f

in

(i) – rozgałęzienie wejściowe modułu i



złożoność systemowa
C(i)=S(i)+D(i)

--
rosnące wartości miar → rosnąca złożoność architektury

* D. N. Card, R. L.Glass: „Measuring software design quality”, Prentice-Hall, 1990

24/31

Miary złożoności projektów
architektury* (2)



miara oparta na liczeniu rozgałęzień wejściowych i
wyjściowych dla architektury wywołań i powrotów *
HKM = l(i)∙[f

in

(i) + f

out

(i)]

2

l(i) – liczba instrukcji w module i
f

in

(i), f

out

(i) – rozgał. wejściowych/wyjściowych modułu i



miary morfologii (kształtu) architektury **



wielkość = liczba wierzchołków + liczba krawędzi



głębokość – najdłuższa ścieżka między modułami na najwyższymi
najniższym poziomie



szerokość – największa liczba wierzchołków na jednym poziomie



liczba krawędzi/liczba wierzchołków – gęstość struktury wywołań,
oszacowanie liczby sprzężeń między modułami

* S. Henry, D. Kafura: „Software structure metrics based on information flow”, IEEE Trans. Software
Engineering , 1981

** N. Fenton: „Software metrics”, Chapman and Hall, 1991

25/31

Odwzorowanie wymagań dla
systemu na jego architekturę



wykorzystuje się tu diagramy przepływu danych
(DFD)



etapy:



określenie rodzaju przepływu informacji (transformacja,
przepływ transakcji)



określenie granic przepływu informacji



odwzorowanie diagramów DFD na strukturę systemu



zdefiniowanie hierarchii sterowania



ulepszanie struktury na bazie miar jakości



rozwinięcie i uściślenie architektury

26/31

Transformacja



dane zewnętrzne wpływają do systemu i są
przekształcane na format wewnętrzny
(przepływy wejściowe)



przekształcone wstępnie dane wpływają do
jądra systemu (centrum transformacji) i zostają
przetwarzane



przetworzone dane przepływają do
zewnętrznych odbiorców (przepływ wyjściowy)



przepływ zachodzi wzdłuż jednej lub maks.
kilku prostych ścieżek

27/31

Przepływ transakcji



przepływ danych opisany względem pojedynczego
elementu danych (transakcja)



przepływ danych realizowany jedną z wielu możliwych
ścieżek



istnieje jedna wejściowa ścieżka przepływu danych,
gdzie dane zewnętrzne zamieniane są na transakcję



transakcja podlega analizie, otrzymana wartość
powoduje skierowanie transakcji na jedną z wielu
możliwych ścieżek akcji



węzeł z którego wychodzą możliwe ścieżki akcji →
centrum przetwarzania transakcji



diagramy dużych systemów mogą zawierać zarówno
elementy przepływu transakcji jak i transformacji

28/31

Odwzorowanie transformacji –
czynności projektowe



przegląd podstawowego modelu systemu (DFD zerowego poziomu,
analiza specyfikacji systemu i specyfikacji wymagań)



przegląd i uściślenie DFD – uzupełnienie szczegółami



określenie czy DFD ma cechy transformacji czy przepływu transakcji
(mogą występować oba)



określenie granic centrum transformacji przez zaznaczenie granic
przepływów wejściowych i wyjściowych



faktoryzacja 1. poziomu – zdefiniowanie hierarchii architektury w której
moduły na górze hierarchii mają cechy sterujące, moduły na dole
hierarchii przetwarzają dane a moduły pośrednie częściowo sterują a
częściowo przetwarzają dane



faktoryzacja 2. poziomu – odwzorowanie wszystkich procedur z DFD
na moduły w strukturze systemu



uściślenie wstępnej wersji architektury w oparciu o zasady poprawy
jakości oprogramowania

29/31

Odwzorowanie przepływu
transakcji – czynności projektowe



przegląd podstawowego modelu systemu



przegląd i uściślenie DFD



określenie czy DFD ma cechy transformacji czy przepływu
transakcji (mogą występować oba)



określenie granic przetwarzania transakcji i rodzaju
przepływu na ścieżkach akcji



odwzorowanie DFD na strukturę systemu odpowiednią do
przetwarzania transakcji (faktoryzacja 1. poziomu) –
zdefiniowanie gałęzi wejściowej i rozdzielającej



faktoryzacja i uściślanie struktury przetwarzania transakcji i
struktury ścieżek akcji



udoskonalanie wstępnej wersji architektury w oparciu o
zasady poprawy jakości oprogramowania

30/31

Uściślanie projektu architektury



wykonywane po przygotowaniu i udoskonaleniu
struktury programu



obejmuje czynności



opis działania modułów (sposób przetwarzania danych)



opis interfejsów modułów (zewnętrznych i wewnętrznych)



definicja lokalnych i globalnych struktur danych



określenie ograniczeń i limitów projektu (typy danych, rozmiar,
wartości skrajne, sytuacje nie przewidziane w projekcie)



przegląd elementów projektu (zwrócenie uwagi na wymaganie
stawiane systemowi, łatwość testowania, pielęgnacji, itp.)



analiza zasadności udoskonalenia projektu

31

Dziękuję za uwagę

źródło: „Praktyczne podejście do inżynierii oprogramowania”, R.S. Pressman