Inżynieria oprogramowania
wykład 12
Projektowanie architektury systemów
1
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óz
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
2/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
3/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
4/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
5/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óz
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
6/31
Style architektury
architektura skoncentrowana na danych
architektura oparta na przepływie danych
architektura wywołań i powrotów
architektura obiektowa
architektura warstwowa
7/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
8/31
Architektura skoncentrowana
na danych - schemat
klient
klient
magazyn
danych
klient
klient
klient
9/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
10/31
Architektura oparta
na przepływie danych - przykład
filtr
architektura oparta
na przepływie
filtr
filtr
filtr
filtr
filtr
filtr
filtr
potoki
filtr
architektura
przetwarzania
sekwencyjnego
filtr filtr filtr filtr
11/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ć
12/31
Architektura głównego
programu - przykład
M
a b c
d
e j
k l
h
f g
m n
o
i
p
13/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
14/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
15/31
Architektura warstwowa - schemat
warstwa interfejsu
użytkownika
składniki
warstwa
warstwy
aplikacji
warstwa
narzędzi
warstwa
jÄ…dra
warstwy
architektury
16/31
Analiza wyboru projektu
architektury
analiza jakościowa metodą ATAM
analiza ilościowa
analiza złożoności architektury
17/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
18/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ę Sw dla hipotetycznego najsłabszego
możliwego projektu i ocenę Sb dla optymalnego projektu
indeks spektrum IS=[(S-SW)/(Sb-Sw)]"100
wartość IS  określa stopień zbliżenia projektu na optymalnego
indeks usprawnienia Imp=IS1-IS2 w przypadku wprowadzania zmian w
projekcie, Imp>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
19/31
Analiza ilościowa projektu architektury* -
indeks wyboru projektu
d=(Ns/Na)"100
Ns  liczba kryteriów spełnionych przez analizowane
rozwiÄ…zanie
Na  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
20/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
21/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
22/31
Miary złożoności projektów
architektury* (1)
złożoność strukturalna modułu i
S(i)=f2 (i)
out
fout(i)  rozgałęzienie wyjściowe modułu i
złożoność danych  stopień skomplikowania interfejsu
modułu i
D(i)=v(i)/[fin(i) +1]
v(i)  liczba zmiennych wejściowych oraz wyjściowych
modułu i
fin(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
23/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)"[fin(i) + fout(i)]2
l(i)  liczba instrukcji w module i
fin(i), fout(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
24/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
25/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
26/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
27/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
28/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
29/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
30/31
Dziękuję za uwagę
z
ródło:  Praktyczne podejście do inżynierii oprogramowania , R.S. Pressman
31