Architektura oprogramowania w praktyce ... - Czytelnia - Helion

Idź do
• Spis treści
• Przykładowy rozdział
• Skorowidz
Katalog książek
• Katalog online
• Zamów drukowany
katalog
Twój koszyk
• Dodaj do koszyka
Cennik i informacje
• Zamów informacje
o nowościach
• Zamów cennik
Czytelnia
• Fragmenty książek
online
Kontakt
Helion SA
ul. Kościuszki 1c
44-100 Gliwice
tel. 32 230 98 63
e-mail: helion@helion.pl
© Helion 1991–2011
Architektura
oprogramowania
w praktyce. Wydanie II
Autorzy: Len Bass, Paul Clements, Rick Kazman
Tłumaczenie: Paweł Koronkiewicz, Tomasz Walczak
ISBN: 978-83-246-3302-9
Tytuł oryginału: Software Architecture in Practice, Second Edition
Format: 172×245, stron: 464
Twórz doskonałe projekty architektoniczne oprogramowania!
•Czym charakteryzuje się dobra architektura oprogramowania?
•Jak przebiega proces jej projektowania?
•Jak ją dokumentować?
Współczesne systemy informatyczne to zaawansowane, skomplikowane mechanizmy, składające
się z wielu współdziałających ze sobą komponentów. Ich wyodrębnienie, a także określenie
sposobu komunikacji i interakcji między poszczególnymi elementami, jest nie lada wyzwaniem
dla architektów. Od ich decyzji zależy, czy system uda się zrealizować, czy będzie on efektywny,
stabilny i łatwy w utrzymaniu.
Na szczęście istnieją metodologie, narzędzia oraz sposoby analizy efektów ułatwiające
i porządkujące cały ten proces. W tej książce znajdziesz wszystko, o czym trzeba pamiętać przy
projektowaniu oprogramowania. Poznasz sposoby projektowania z wykorzystaniem Metody
Analizy Kompromisów w Architekturze (ATAM) oraz oceniania aspektów finansowych przy użyciu
Metody Analizy Kosztów i Korzyści (CBAM). Autorzy przedstawią wiele studiów przypadków, które
pozwolą Ci na zapoznanie się z rzeczywistymi problemami i ich rozwiązaniami. Ponadto nauczysz
się stosować język UML do wizualnej reprezentacji architektury systemu oraz zobaczysz, jak
przygotować dobrą dokumentację projektu. Książka ta sprawdzi się idealnie w rękach każdego
architekta oprogramowania.
•Proces wytwarzania oprogramowania a cykl biznesowy architektury
•Wzorce architektury
•Struktury i perspektywy architektury
•Określenie i uzyskanie atrybutów jakościowych
•Projektowanie architektury pod kątem wysokiej dostępności
•Proces projektowania architektury
•Dokumentowanie architektury oprogramowania
•Język UML
•Metody rekonstrukcji architektury i inżynierii odwrotnej
•Metoda Analizy Kompromisów w Architekturze (ATAM)
•Metoda Analizy Kosztów i Korzyści (CBAM)
•Ponowne wykorzystanie elementów architektury
•Dokumentowanie architektury
Poznaj najlepsze metodologie projektowania architektury!

Spis treci
Przedmowa ................................................................................................................9
Podzikowania ........................................................................................................13
Wstp .......................................................................................................................15
I. Wizja architektury .............................................................................. 21
1. Cykl biznesowy architektury ................................................................................23
1.1. Skd si bior architektury? .................................................................................................................26
1.2. Proces wytwarzania oprogramowania a cykl biznesowy architektury .............................................31
1.3. Czym si charakteryzuje dobra architektura? ....................................................................................33
1.4. Podsumowanie .......................................................................................................................................35
1.5. Pytania do dyskusji ...............................................................................................................................35
2. Czym jest architektura oprogramowania? ..........................................................37
2.1. Czym jest, a czym nie jest architektura oprogramowania? ...............................................................37
2.2. Inne perspektywy ..................................................................................................................................40
2.3. Wzorce architektury, modele referencyjne i architektury referencyjne ..........................................41
2.4. Dlaczego architektura jest tak wana? ................................................................................................43
2.5. Struktury i perspektywy architektury .................................................................................................50
2.6. Podsumowanie .......................................................................................................................................56
2.7. Literatura ...............................................................................................................................................57
2.8. Pytania do dyskusji ...............................................................................................................................59
3. System awioniki A-7E — studium wykorzystania struktur architektury .......61
3.1. Pooenie w cyklu biznesowym architektury .....................................................................................62
3.2. Wymagania i atrybuty jakociowe .......................................................................................................62
3.3. Architektura systemu awioniki A-7E ..................................................................................................67
3.4. Podsumowanie .......................................................................................................................................78
3.5. Literatura ...............................................................................................................................................79
3.6. Pytania do dyskusji ...............................................................................................................................79

4 SPIS TRECI
II. Tworzenie architektury ................................................................... 81
4. Atrybuty jakociowe ..............................................................................................83
4.1. Architektura a funkcje systemu ...........................................................................................................84
4.2. Architektura a atrybuty jakociowe .....................................................................................................84
4.3. Atrybuty jakociowe systemu ..............................................................................................................85
4.4. Scenariusze atrybutów jakociowych w praktyce ..............................................................................89
4.5. Inne atrybuty jakociowe systemu .....................................................................................................103
4.6. Biznesowe atrybuty jakociowe .........................................................................................................103
4.7. Atrybuty jakociowe architektury .....................................................................................................104
4.8. Podsumowanie .....................................................................................................................................105
4.9. Literatura .............................................................................................................................................105
4.10. Pytania do dyskusji ...........................................................................................................................106
5. Uzyskiwanie atrybutów jakociowych ..............................................................107
5.1. Taktyki atrybutów jakociowych .......................................................................................................107
5.2. Taktyki dostpnoci ............................................................................................................................109
5.3. Taktyki modyfikowalnoci ................................................................................................................112
5.4. Taktyki wydajnoci .............................................................................................................................118
5.5. Taktyki bezpieczestwa ......................................................................................................................122
5.6. Taktyki testowalnoci .........................................................................................................................124
5.7. Taktyki funkcjonalnoci ....................................................................................................................126
5.8. Taktyki atrybutów jakociowych a wzorce architektury .................................................................128
5.9. Wzorce i style architektury ................................................................................................................129
5.10. Podsumowanie ...................................................................................................................................130
5.11. Pytania do dyskusji ...........................................................................................................................131
5.12. Literatura ...........................................................................................................................................131
6. Kontrola ruchu lotniczego
— projektowanie pod ktem wysokiej dostpnoci ........................................133
6.1. Powizania w cyklu biznesowym architektury ................................................................................135
6.2. Wymagania i atrybuty jakociowe .....................................................................................................135
6.3. Architektura systemu .........................................................................................................................138
6.4. Podsumowanie .....................................................................................................................................152
6.5. Literatura .............................................................................................................................................152
6.6. Pytania do dyskusji .............................................................................................................................153
7. Projektowanie architektury ................................................................................155
7.1. Architektura w cyklu ycia oprogramowania ...................................................................................155
7.2. Projektowanie architektury ................................................................................................................157
7.3. Ksztatowanie struktury zespoów ....................................................................................................167
7.4. Tworzenie systemu szkieletowego .....................................................................................................170
7.5. Podsumowanie .....................................................................................................................................171
7.6. Literatura .............................................................................................................................................172
7.7. Pytania do dyskusji .............................................................................................................................173
8. Symulator lotniczy — architektura
ukierunkowana na atwo integracji ................................................................175
8.1. Powizania w cyklu biznesowym architektury ................................................................................176
8.2. Wymagania funkcjonalne i jakociowe .............................................................................................177
8.3. Architektura ........................................................................................................................................180

SPIS TRECI 5
8.4. Podsumowanie .....................................................................................................................................193
8.5. Literatura .............................................................................................................................................195
8.6. Pytania do dyskusji .............................................................................................................................195
9. Dokumentacja architektury oprogramowania .................................................197
9.1. Funkcje dokumentacji ........................................................................................................................198
9.2. Perspektywy architektury ..................................................................................................................200
9.3. Wybieranie perspektyw architektury ................................................................................................201
9.4. Opisywanie perspektywy architektury ..............................................................................................202
9.5. Ogólna cz dokumentacji ................................................................................................................208
9.6. Zunifikowany jzyk modelowania — UML .....................................................................................211
9.7. Podsumowanie .....................................................................................................................................220
9.8. Literatura .............................................................................................................................................221
9.9. Pytania do dyskusji .............................................................................................................................221
10. Rekonstrukcja architektury oprogramowania .................................................223
10.1. Wprowadzenie ...................................................................................................................................223
10.2. Ekstrakcja informacji ........................................................................................................................226
10.3. Budowanie bazy danych ...................................................................................................................228
10.4. Scalanie informacji ............................................................................................................................230
10.5. Rekonstrukcja ....................................................................................................................................232
10.6. Przykad .............................................................................................................................................237
10.7. Podsumowanie ...................................................................................................................................245
10.8. Literatura ...........................................................................................................................................245
10.9. Pytania do dyskusji ...........................................................................................................................246
III. Analiza i weryfikacja architektury .............................................. 247
11. ATAM — kompleksowa metoda analizy architektury ...................................253
11.1. Uczestnicy procesu ATAM ..............................................................................................................253
11.2. Materiay wyjciowe procesu ATAM ..............................................................................................255
11.3. Fazy procesu ATAM .........................................................................................................................256
11.4. Studium przypadku — weryfikacja metod ATAM systemu Nightingale .................................267
11.5. Podsumowanie ...................................................................................................................................281
11.6. Literatura ...........................................................................................................................................282
11.7. Pytania do dyskusji ...........................................................................................................................282
12. CBAM — ilociowe podejcie do decyzji konstrukcyjnych ...........................283
12.1. Kontekst podejmowania decyzji ......................................................................................................284
12.2. Podstawy metody CBAM .................................................................................................................285
12.3. Stosowanie metody CBAM ..............................................................................................................289
12.4. Studium przypadku — projekt ECS w agencji NASA ..................................................................291
12.5. Rezultaty analizy CBAM ..................................................................................................................298
12.6. Podsumowanie ...................................................................................................................................299
12.7. Literatura ...........................................................................................................................................299
12.8. Pytania do dyskusji ...........................................................................................................................299
13. Wspódziaanie w World Wide Web — studium przypadku ..........................301
13.1. Powizania z cyklem biznesowym architektury ............................................................................301
13.2. Wymagania funkcjonalne i atrybuty jakociowe ...........................................................................303
13.3. Architektura ......................................................................................................................................307
13.4. Nowy cykl ABC — ewolucja architektur handlu elektronicznego w WWW .............................313

6 SPIS TRECI
13.5. Wymagania jakociowe .....................................................................................................................317
13.6. Wspóczesny cykl biznesowy architektury .....................................................................................318
13.7. Podsumowanie ...................................................................................................................................319
13.8. Literatura ...........................................................................................................................................320
13.9. Pytania do dyskusji ...........................................................................................................................321
IV. Od jednego systemu do wielu ...................................................... 323
14. Rodziny produktów — ponowne uycie elementów architektury .................325
14.1. Wprowadzenie ...................................................................................................................................325
14.2. Co sprawia, e linia oprogramowania jest udana? .........................................................................326
14.3. Okrelanie zakresu ............................................................................................................................328
14.4. Architektury linii produktów ..........................................................................................................331
14.5. Co sprawia, e rozwijanie linii oprogramowania jest trudne? ......................................................334
14.6. Podsumowanie ...................................................................................................................................337
14.7. Literatura ...........................................................................................................................................337
14.8. Pytania do dyskusji ...........................................................................................................................337
15. CelsiusTech — studium przypadku rodziny produktów ................................339
15.1. Zwizki z cyklem ABC .....................................................................................................................339
15.2. Wymagania i atrybuty jakociowe ...................................................................................................355
15.3. Rozwizanie architektoniczne .........................................................................................................357
15.4. Podsumowanie ...................................................................................................................................364
15.5. Literatura ...........................................................................................................................................365
15.6. Pytania do dyskusji ...........................................................................................................................365
16. J2EE/EJB. Studium przypadku
— standardowa dla brany infrastruktura obliczeniowa ................................367
16.1. Zwizki z cyklem biznesowym architektury ..................................................................................368
16.2. Wymagania i atrybuty jakociowe ...................................................................................................368
16.3. Rozwizanie architektoniczne .........................................................................................................371
16.4. Decyzje zwizane z wdraaniem systemu .......................................................................................383
16.5. Podsumowanie ...................................................................................................................................388
16.6. Literatura ...........................................................................................................................................388
16.7. Pytania do dyskusji ...........................................................................................................................388
17. Architektura Luther. Studium przypadku
— aplikacje przenone oparte na J2EE .............................................................389
17.1. Zwizki z cyklem ABC .....................................................................................................................390
17.2. Wymagania i atrybuty jakociowe ...................................................................................................393
17.3. Rozwizanie architektoniczne .........................................................................................................396
17.4. Jak w architekturze Luther zrealizowano cele z obszaru jakoci? ...............................................410
17.5. Podsumowanie ...................................................................................................................................410
17.6. Literatura ...........................................................................................................................................411
17.7. Pytania do dyskusji ...........................................................................................................................411
18. Budowanie systemów z gotowych komponentów ............................................413
18.1. Wpyw komponentów na architektur ...........................................................................................415
18.2. Niedopasowanie architektury ..........................................................................................................416
18.3. Budowa z gotowych komponentów jako proces poszukiwa .......................................................421

SPIS TRECI 7
18.4. Przykad — system ASEILM ..........................................................................................................424
18.5. Podsumowanie ...................................................................................................................................433
18.6. Literatura ...........................................................................................................................................433
19. Przyszo architektury oprogramowania .........................................................435
19.1. Cykl biznesowy architektury ...........................................................................................................436
19.2. Budowa architektury ........................................................................................................................437
19.3. Architektura w cyklu ycia oprogramowania .................................................................................438
19.4. Wpyw komponentów komercyjnych .............................................................................................439
19.5. Podsumowanie ...................................................................................................................................441
Skróty .....................................................................................................................443
Bibliografia ............................................................................................................449
Skorowidz ..............................................................................................................455

5
Uzyskiwanie
atrybutów jakociowych
Felix Bachmann, Mark Klein i Bill Wood 1
W pewnym steniu kada dobra jako staje si szkodliwa.
— Ralph Waldo Emerson
W rozdziale 4. omówilimy róne atrybuty jakociowe systemu. Naszym podstawowym narzdziem
byy scenariusze. Dokadne zrozumienie znaczenia kadego z atrybutów pozwala formuowa
praktyczne wymagania jakociowe. Wci nie jest to jednak rozwizaniem problemu
tego, jak zapewni, by system faktycznie posiada t czy inn cech. Temu wanie powicony
jest niniejszy rozdzia. Dla kadego z szeciu atrybutów jakociowych opisywanych w rozdziale
4. przedstawimy praktyczne wskazówki, które mog by istotn pomoc w odpowiednim konstruowaniu
architektury. Nie próbujemy przy tym odnie si do wszystkich moliwych cech
systemu. Warto zwróci uwag, e analogiczne porady dotyczce zapewniania atwoci integracji
zostan przedstawione w rozdziale 8.
W tym rozdziale interesuje nas to, w jaki sposób architekt zapewnia uzyskanie rónych
cech jakociowych. Wymagania jakociowe opisuj reakcje oprogramowania niezbdne do realizacji
celów biznesowych. W centrum naszego zainteresowania s techniki, z których moe
skorzysta architekt, by utworzy odpowiedni projekt, stosujc pewne wzorce konstrukcyjne,
wzorce architektury i strategie architektury — bdziemy nazywa je taktykami atrybutów jakociowych.
Przykadowo celem biznesowym moe by przygotowanie linii produktów. rodkiem
do osignicia tego celu jest zapewnienie wymiennoci pewnych klas funkcji.
Przed podjciem decyzji o zastosowaniu pewnego systemu wzorców architekt powinien
rozway podane taktyki modyfikowalnoci. Staj si one podstaw podejmowanych wyborów.
Wzorzec lub strategia architektury to zbiór pewnych taktyk. Temat tego rozdziau to powizania
midzy wymaganiami jakociowymi (opisanymi w rozdziale 4.) a decyzjami dotyczcymi
architektury.
5.1. Taktyki atrybutów jakociowych
Co daje projektowi przenono, du wydajno czy atwo integracji? Kada z tych cech ma
swoje ródo w kluczowych decyzjach konstrukcyjnych. W tym rozdziale przyjrzymy si dokadniej
tym decyzjom. Bdziemy operowa pojciem taktyk atrybutów jakociowych (ang.
1 Pracownicy Instytutu Inynierii Oprogramowania Carnegie Mellon University.

108 5. UZYSKIWANIE ATRYBUTÓW JAKOCIOWYCH
quality attribute tactics). Taktyka pewnej cechy to pewien wybór o znaczcym wpywie na kontrol
uzyskiwan nad danym atrybutem. Zbiór taktyk nazywamy strategi architektury (ang. architectural
strategy). Zajmiemy si nimi w rozdziale 12. Z kolei wzorzec architektury (ang. architectural
pattern) to poczenie taktyk w sposób, który opiszemy dokadniej w podrozdziale 5.8.
Projekt systemu to zbiór decyzji konstrukcyjnych. Niektóre z nich pozwalaj uzyska
wpyw na poziom, w jakim system uzyskuje pewne atrybuty jakociowe. Inne prowadz do
uzyskania funkcji systemu. W tym rozdziale sprowadzamy decyzje dotyczce atrybutów jako-
ciowych do pojcia taktyk. Ich rol ilustruje rysunek 5.1. Taktyki te nie s bynajmniej nowo-
ci. Architekci stosuj je od lat, a my podejmujemy jedynie prób ich identyfikacji i opisu.
Nie jest naszym celem prezentowanie nowych metod pracy, a jedynie systematyzacja dziaa
znanych z praktyki.
Rysunek 5.1. Taktyki wyznaczaj kontrol nad reakcj na bodziec
Kada taktyka jest dla architekta pewn moliwoci. Przykadowo jedna z taktyk wie si
z wprowadzeniem redundancji w celu zwikszenia dostpnoci systemu. Jest to jedna z moliwoci
zwikszenia dostpnoci, ale w adnym wypadku jedyna. Zwikszanie dostpnoci drog
redundancji wie si zazwyczaj z koniecznoci wprowadzenia mechanizmów synchronizacji
(by kopia nadawaa si do uytku w przypadku zakócenia dostpnoci oryginau). W tym prostym
przykadzie wida dwie podstawowe zalenoci:
1. Taktyka ogólniejsza podlega specjalizacji. Zidentyfikowalimy ogóln taktyk redundancji.
Mona jednak mówi o nadmiarowoci danych (w bazie) lub nadmiarowoci oblicze
(w osadzonym systemie sterowania). Kade z tych podej jest pewn taktyk. Kade z nich
mona ucila dalej, definiujc precyzyjniej okrelone taktyki. Dla kadego atrybutu jako-
ciowego mona wskaza pewn hierarchi taktyk.
2. Wzorce to praktyczne zbiory taktyk. Signicie po wzorzec zapewniajcy dostpno bdzie
prawdopodobnie równoznaczne z poczeniem zastosowania taktyki redundancji i taktyki synchronizacji.
Co wicej, we wzorcu pojawi si zapewne jeszcze precyzyjniej okrelone wersje tych
taktyk. Na kocu tego rozdziau przedstawimy przykadowy opis wzorca projektowego w kategoriach
taktyk.
Opis taktyk porzdkujemy jako hierarchie powizane z kolejnymi atrybutami jakociowymi.
Naley pamita, e adna z tych hierarchii nie jest kompletna. Moliwo stworzenia nowych
taktyk istnieje zawsze, mona wic jedynie mówi o pewnych przykadach. Dla kadego z szeciu
atrybutów opisanych w rozdziale 4. (dostpno, modyfikowalno, wydajno, bezpieczestwo, testowalno
i funkcjonalno) przedstawiamy zbiór typowych rozwiza. Dla kadego proponujemy
pewn hierarchi taktyk, która — w poczeniu z krótkim omówieniem zagadnienia —
powinna by dla architekta znaczc pomoc w poszukiwaniu wasnej cieki.

5.2. TAKTYKI DOSTPNOCI 109
5.2. Taktyki dostpnoci
Przypomnijmy sownictwo zwizane z dostpnoci, którym operowalimy w rozdziale 4. Awaria
nastpuje wtedy, gdy system przestaje zapewnia usug wynikajc z jego specyfikacji; jest
to widoczne dla uytkowników. Awari moe spowodowa uszkodzenie (lub pewne poczenie
uszkodze). Wanym aspektem dostpnoci jest przywrócenie funkcjonowania systemu, czyli
jego naprawa. Taktyki opisywane w tym podrozdziale maj zabezpieczy przed awari systemu
w przypadku uszkodzenia, a przynajmniej ograniczy jego skutki i umoliwi napraw. Ilustruje
to rysunek 5.2.
Rysunek 5.2. Cel taktyk dostpnoci
Wiele omawianych taktyk zapewnianych jest przez standardowe rodowiska wykonawcze, takie
jak system operacyjny, serwer aplikacji lub system zarzdzania bazami danych. Nie umniejsza
to znaczenia dobrego zrozumienia stosowanej taktyki, poniewa efekty kadej z nich maj istotne
znaczenie przy projektowaniu i ocenie projektu. Kada technika zwizana z dostpnoci wie
si z pewnym rodzajem redundancji, monitorowaniem stanu w celu wykrycia awarii i schematem
przywracania stanu systemu. Monitorowanie i przywracanie mog by zautomatyzowane lub nie.
Rozpoczniemy od omówienia zagadnie zwizanych z trzema podstawowymi skadnikami dostpnoci:
wykrywaniem uszkodze, przywracaniem stanu i zapobieganiem uszkodzeniom.
Wykrywanie uszkodze
Trzy szeroko stosowane taktyki wykrywania uszkodze to: ping/echo, puls i wyjtki.
Ping/echo. Pewien komponent wysya specjalny komunikat i oczekuje, e komponent monitorowany
odele w predefiniowanym czasie „echo” jego sygnau. Mechanizm taki mona
zastosowa w grupie komponentów wspólnie odpowiadajcych za pewne zadanie w systemie.
Jest te czsto wykorzystywany przez klienty do monitorowania parametrów wydajno-
ciowych serwera i cieki komunikacyjnej. Mechanizmy wykrywania uszkodze mona
czy w hierarchie, w których mechanizm najniszego poziomu monitoruje procesy pracujce
na tym samym procesorze, a mechanizm na wyszym poziomie monitoruje stan
kontrolerów na niszym poziomie. Pozwala to unikn obciania kanau komunikacyjnego
komunikacj zdalnego monitora z wszystkimi procesami.
Puls. Komponent monitorowany wysya regularnie komunikat pulsu do komponentu monitorujcego.
Gdy komunikat pulsu nie zostaje odebrany, nastpuje powiadomienie komponentu
odpowiedzialnego za usunicie uszkodzenia. Komunikaty pulsu mog zawiera dane. Rol
pulsu moe peni na przykad przesyany okresowo dziennik pracy bankomatu. Komunikat
taki jest jednoczenie komunikatem zawierajcym przekazywane do przetwarzania dane.
Wyjtki. Jedn z metod monitorowania uszkodze jest przechwytywanie wyjtków, jak te
zgaszane przy wystpieniu bdów nalecych do klas wymienionych w przykadzie
w rozdziale 4. Procedura obsugi wyjtku jest zazwyczaj wykonywana w tym samym procesie,
w którym zosta on wygenerowany.

110 5. UZYSKIWANIE ATRYBUTÓW JAKOCIOWYCH
Taktyki ping/echo i pulsu bazuj na odrbnych procesach, mechanizm wyjtków dziaa w obrbie
jednego procesu. Procedura obsugi wyjtku przeprowadza zazwyczaj transformacj semantyczn
uszkodzenia do postaci umoliwiajcej jego przetwarzanie.
Przywracanie stanu systemu
Na przywracanie stanu systemu skada si przygotowanie do przywracania i waciwa naprawa.
Poniej przedstawiamy wybór taktyk przygotowania do przywracania i naprawy systemu.
Gosowanie. Procesy pracujce na nadmiarowych procesorach przyjmuj takie same dane
wejciowe i obliczaj prost warto wyjciow, która jest przekazywana do mechanizmu
gosowania. Jeeli mechanizm ten wykryje, e zachowanie jednego procesora odbiega od
wikszoci, proces ten zostaje uznany za uszkodzony. Przy gosowaniu moe by stosowany
algorytm „rzdów wikszoci”, „komponentu preferowanego” lub inny. Jest to metoda
stosowana do wykrywania niepoprawnego dziaania algorytmów i uszkodze procesorów,
czsto spotykana w systemach sterowania. Jeeli wszystkie procesory pracuj wedug tych
samych algorytmów, redundancja pozwala wykry jedynie uszkodzenie procesora, ale nie
chroni przed bdami algorytmów. Jeeli konsekwencje awarii s dotkliwe (na przykad
utrata ycia), zrónicowanie nadmiarowych komponentów moe by bardzo due.
Skrajnym przykadem zrónicowania jest przekazanie pracy nad kadym z nadmiarowych
komponentów innemu zespoowi ze wskazaniem innej platformy. Nieco mniej wyszukanym
podejciem jest opracowywanie wersji tego samego skadnika pracujcych na
rónych platformach. Wprowadzanie zrónicowa tego rodzaju jest zawsze kosztowne —
zarówno na pocztku, jak i przy póniejszej konserwacji systemu, wic stosuje si je tylko
w wyjtkowych przypadkach, na przykad w mechanizmach awioniki. Mechanizm gosowania
jest zazwyczaj stosowany w systemach sterowania, w których porównywane wyjcia
s proste i atwe w klasyfikacji jako zgodne lub nie, obliczenia maj charakter cykliczny,
a wszystkie nadmiarowe komponenty mog otrzymywa równowane dane wejciowe z czujników.
Taktyka ta nie wie si z przerw w pracy, poniewa system gosowania moe
dziaa take po wykryciu awarii. Znan odmian tego podejcia jest metoda Simplex, polegajca
na korzystaniu z wyników komponentu „preferowanego”, dopóki nie odbiegaj one
od przesyanych przez komponent „zaufany”. W przypadku awarii nastpuje przeczenie
na dane z komponentu zaufanego. Synchronizacja nadmiarowych komponentów nastpuje
automatycznie, poniewa zakada si, e wszystkie pracuj jednoczenie z tym samym
zespoem wej.
Redundancja aktywna (gorcy restart). Wszystkie nadmiarowe komponenty reaguj na
zdarzenia jednoczenie. S wic w tym samym stanie. Wykorzystywana jest odpowied
jednego komponentu (zazwyczaj pierwszego, który odpowie), a pozostae s odrzucane.
W przypadku wystpienia uszkodze przerwa w pracy systemów stosujcych t taktyk trwa
zazwyczaj milisekundy, poniewa komponent zapasowy jest aktywny, a jedyny potrzebny
czas to czas przeczania. Redundancja aktywna to metoda czsto stosowana w konfiguracjach
klient-serwer, takich jak systemy zarzdzania bazami danych, gdzie szybkie reakcje
na wystpienie uszkodzenia s niezbdne. W systemie rozproszonym o wysokiej dostpnoci
nadmiarowo moe dotyczy cieek komunikacyjnych. Przykadowo podane moe by zastosowanie
sieci LAN o wielu równolegych ciekach i umieszczenie kadego nadmiarowego
komponentu na odrbnej ciece. Wówczas pojedyncza awaria mostu lub cieki nie
powoduje, e wszystkie skadniki systemu staj si niedostpne.
Synchronizacja polega na zapewnieniu, e wszystkie komunikaty przesyane do komponentu
z redundancj s przesyane do wszystkich jego nadmiarowych wersji. Jeeli komunikacja
moe ulec zakóceniu (ze wzgldu na przecione lub zawodne cza), przywraca-

5.2. TAKTYKI DOSTPNOCI 111
nie stanu moe umoliwia niezawodny protokó transmisji. Protokó taki wprowadza
wymóg przesania potwierdzenia przez wszystkich odbiorców. Towarzyszy temu pewna
forma kontroli integralnoci komunikacji, na przykad suma kontrolna. Jeeli nadawca nie
moe stwierdzi, e wszyscy odbiorcy otrzymali komunikat, to ponawia on prób przesania
do komponentów, które nie potwierdzaj odbioru. Ponowne wysyanie nieodebranych
komunikatów (czasem z uyciem rónych cieek komunikacji) jest kontynuowane do
chwili, gdy algorytm nadawcy pozwoli uzna odbiorc za wyczonego.
Redundancja pasywna (ciepy restart, podwójna redundancja, potrójna redundancja).
Jeden komponent (komponent gówny) reaguje na zdarzenia i informuje pozostae komponenty
(komponenty awaryjne) o wymaganych aktualizacjach stanu. Gdy nastpuje awaria,
system musi przede wszystkim zweryfikowa, czy kopia zapasowa jest wystarczajco aktualna,
by mona byo wznowi udostpnianie usug. To podejcie take stosuje si w systemach
sterowania, przede wszystkim wtedy, gdy dane wejciowe s pobierane z kanaów komunikacyjnych
lub czujników, które musz zosta przeczone w przypadku awarii na korzystanie
z komponentów awaryjnych. W rozdziale 6., w którym jest omawiany przykad systemu
kontroli ruchu lotniczego, spotkamy si z t taktyk w praktyce. W tym przypadku komponent
pomocniczy decyduje o tym, kiedy przej zadania komponentu gównego, ale czsto
mona spotka si z tym, e za t decyzj odpowiadaj inne skadniki. O tym, czy taktyka
spenia swoje zadanie, w duej mierze decyduje zdolno komponentów awaryjnych do poprawnego
przejcia pracy. Okresowe wymuszanie przeczania — na przykad raz na dob
lub raz na tydzie — zwiksza dostpno systemu. Niektóre systemy baz danych wymuszaj
przeczenie pamici masowej dla kadego nowego elementu danych. Nowy element
jest zapisywany w stronie shadow, a jej wczeniejsza wersja staj si kopi zapasow. W takich
rozwizaniach przerwa w pracy moe zosta skrócona do kilku sekund.
Za synchronizacj odpowiada komponent gówny, który moe zagwarantowa j poprzez
atomowe emisje do komponentów awaryjnych.
Zapas. Przygotowanie zapasowej platformy obliczeniowej przeznaczonej do caociowego
zastpowania grupy zrónicowanych komponentów. Po awarii musi ona zosta uruchomiona,
a jej stan zainicjalizowany. Uzyskanie waciwego stanu zapasu umoliwia regularne zapisywanie
punktów kontrolnych systemu i zmian stanu z uyciem urzdzenia zapewniajcego
trwae skadowanie danych. Praktyczn form zastosowania tej taktyki jest zapewnianie zapasowej
stacji roboczej, z której moe korzysta uytkownik w przypadku awarii jego gównego
stanowiska pracy. Przerw w pracy mierzy si zazwyczaj w minutach.
Niektóre taktyki uwzgldniaj wznawianie pracy komponentu — naprawiony po awarii
komponent moe zosta ponownie wprowadzony do systemu. Przykady takich taktyk
to: powielanie, resynchronizacja stanu i odwoywanie.
Powielanie (ang. shadow operation). Komponent, który wczeniej uleg awarii, moe przez
pewien czas pracowa w „trybie powielania” w celu weryfikacji, e jego dziaanie jest
zgodne z dziaaniem komponentów, których praca nie ulega zakóceniu.
Resynchronizacja stanu. Taktyki redundancji aktywnej i pasywnej wymagaj, by przywracany
komponent zosta przed wczeniem do usugi odpowiednio zaktualizowany. Podejcie
do aktualizacji zaley od dopuszczalnego czasu przerwy w pracy, rozmiaru aktualizacji i liczby
niezbdnych do jej przeprowadzenia komunikatów. O ile to moliwe, najlepszym rozwizaniem
jest pojedynczy komunikat opisujcy stan. Przyrostowe aktualizowanie stanu czone
z okresami aktywnoci komponentu prowadzi do znacznego wzrostu zoonoci.
Punkty kontrolne i odwoywanie (ang. rollback). Punkt kontrolny to zapis spójnego stanu,
który tworzy si okresowo lub w reakcji na pewne zdarzenia. Zdarza si, e system
ulega nietypowej awarii i w zauwaalny sposób traci integralno. W takiej sytuacji funkcjonowanie
systemu mona przywróci, uywajc wczeniejszego punktu kontrolnego
oraz dziennika transakcji wykonanych od czasu jego zapisania.

112 5. UZYSKIWANIE ATRYBUTÓW JAKOCIOWYCH
Zapobieganie uszkodzeniom
Oto taktyki zapobiegania uszkodzeniom:
Wyczanie z systemu. Taktyka polegajca na usuwaniu z systemu wybranych komponentów
w celu poddania ich pewnym dziaaniom majcym zapobiec typowym awariom.
Przykadem moe by reinicjalizowanie komponentu w celu zabezpieczenia systemu
przed katastrofalnymi skutkami potencjalnych „wycieków” pamici. Jeeli wyczanie
z pracy nastpuje automatycznie, mona zaprojektowa odpowiedni strategi architektury.
Jeeli wyczanie ma by rczne, równie naley zadba o to w konstrukcji systemu.
Transakcje. Transakcja to poczenie sekwencji kroków, które zapewnia, e sekwencja ta
bdzie moga zosta wycofana jako cao. Transakcje wykorzystuje si w celu zabezpieczenia
przed wpywem na jakiekolwiek dane, w sytuacji gdy jeden z kroków procesu nie
zostaje poprawnie wykonany, a take by zapobiega kolizjom wtków korzystajcych z tych
samych danych.
Monitor procesów. Po wykryciu uszkodzenia w jednym z procesów proces monitorujcy
moe go usun i utworzy nowy o odpowiednio zainicjalizowanym stanie.
Rysunek 5.3 podsumowuje omówione taktyki.
Rysunek 5.3. Taktyki dostpnoci
5.3. Taktyki modyfikowalnoci
Przypomnijmy z rozdziau 4. — taktyki modyfikowalnoci maj na celu uzyskanie wpywu na
czas i koszty implementacji, testowania i wdraania. Relacj t ilustruje rysunek 5.4.
Taktyki modyfikowalnoci czymy w grupy wedug ich celów. Pierwszy zbiór czy cel
zmniejszenia liczby moduów, na które zmiana bezporednio wpywa. Jest to nazywane lokalizowaniem
modyfikacji. Drugi zbiór taktyk ma na celu ograniczenie zakresu zmian w modu-
ach, które nie mog pozosta nienaruszone. S to taktyki, które zapobiegaj efektowi domina
— powstawaniu acucha zalenoci, w którym zmiany w jednym miejscu prowadz do zmian
w innym. Operujemy przy tym istotnym rozrónieniem na moduy, na które zmiana wpywa

5.3. TAKTYKI MODYFIKOWALNOCI 113
Rysunek 5.4. Cel taktyk modyfikowalnoci
bezporednio (pewnej modyfikacji ulega ich zakres odpowiedzialnoci), i takie, na które zmiana
wpywa porednio (zakres odpowiedzialnoci pozostaje, ale modyfikacja jest konieczna ze
wzgldu na moduy pod bezporednim wpywem zmiany). Trzecia grupa taktyk ukierunkowana
jest na czas i koszty wdraania. W tym przypadku chodzi przede wszystkim o opónienie
czasu wizania.
Lokalizowanie modyfikacji
Cho nie mona ogólnie mówi o cisej relacji midzy liczb moduów, na które wpywa pewien
zespó zmian, a kosztami wprowadzenia tych zmian, nie ulega wtpliwoci, e ograniczanie
zakresu koniecznych modyfikacji do jak najmniejszej liczby moduów jest skuteczn metod
zmniejszania kosztów. Celem taktyk z opisywanej tu grupy jest uzyskanie takich przypisa
zakresów odpowiedzialnoci moduów, by zakres przewidywanych zmian by jak najmniejszy.
Prezentujemy pi takich taktyk.
Utrzymywanie spójnoci semantycznej. Spójno semantyczna odnosi si do relacji
midzy zakresami odpowiedzialnoci w module. Celem jest zapewnienie, e wszystkie te
zakresy wspódziaaj bez nadmiernego uzalenienia od innych moduów. rodkiem do
osignicia tego celu jest przestrzeganie w formuowaniu tych zakresów zasad spójnoci
semantycznej. S w tym pewn pomoc róne miary siy powiza i poziomu spójnoci.
Brakuje im jednak odniesienia do kontekstu zmian. Spójno semantyczn naley ocenia
w perspektywie pewnego zbioru zmian przewidywanych w przyszoci. Szczególnie wan
taktyk w tej grupie jest tworzenie abstrakcji wspólnych usug. Zapewnianie wspólnych
usug poprzez wprowadzenie wyspecjalizowanych moduów jest zazwyczaj postrzegane
jako skuteczny rodek uatwiajcy ponowne wykorzystywanie elementów. Nie jest to jedyna
korzy — uogólnienie wspólnych usug sprzyja te modyfikowalnoci. Po wyczeniu
usug wprowadzane w nich modyfikacje nie musz by powielane w kadym wykorzystujcym
je module. Co wicej, modyfikacje w moduach korzystajcych z tych usug
nie maj wpywu na inne moduy, których praca opiera si na tych samych usugach. Jest
to wic taktyka nie tylko sprzyjajca lokalizowaniu modyfikacji, ale te zabezpieczajca
przed efektem domina. Przykady wyczenia wspólnych usug to midzy innymi stosowanie
platform aplikacji (ang. application frameworks) i korzystanie z innego rodzaju oprogramowania
middleware.
Przewidywanie prawdopodobnych zmian. Przewidywanie zbioru oczekiwanych zmian pozwala
oceni zastosowany podzia zakresów odpowiedzialnoci. Podstawowe pytanie brzmi:
„Czy dla kadej ze zmian proponowana dekompozycja ogranicza zespó moduów, które
musz zosta zmodyfikowane w celu jej wprowadzenia?”. Towarzyszy mu równie druga
kwestia do rozwaenia: „Czy zasadniczo rónice si zmiany wpywaj na te same moduy?”.
Czym róni si to od spójnoci semantycznej? Przypisywanie zakresów odpowiedzialnoci

114 5. UZYSKIWANIE ATRYBUTÓW JAKOCIOWYCH
na bazie spójnoci semantycznej wie si z zaoeniem, e równie oczekiwane zmiany
bd spójne semantycznie. Taktyka przewidywania zmian nie koncentruje si na spójno-
ci zada moduu, ale na ograniczaniu skutków zmian. W praktyce jest ona trudna do zastosowania
niezalenie od innych, poniewa nie jest moliwe przewidzenie kadej zmiany.
To powoduje, e zazwyczaj stosuje si j w poczeniu z taktyk spójnoci semantycznej.
Uogólnienie moduu. Zapewnienie moduowi wikszej ogólnoci prowadzi do uzyskania
obsugi wikszej liczby funkcji. Dane wejciowe mona traktowa jak jzyk definiujcy
modu. Moe to sprowadza si do zastpienia staych parametrami. Moe te prowadzi
do rozwiza bardziej zoonych, na przykad implementowania moduu w formie interpretera,
kiedy to parametry wejciowe staj si jego jzykiem. Im bardziej ogólny modu,
tym bardziej prawdopodobne jest to, e wymagane zmiany bdzie mona wprowadzi
drog dostosowania jzyka na wejciu, bez modyfikowania kodu.
Ograniczanie dostpnych moliwoci. Zmiany, zwaszcza w przypadku linii produktów
(patrz rozdzia 14.), mog mie bardzo szeroko zakrojone skutki i wpywa na wiele moduów.
Ograniczanie zakresu dostpnych moliwoci pozwala na redukcj wpywu modyfikacji.
Przykadowo punkt zrónicowania w projektowanej linii produktów moe pozwala
na zmian procesora — ograniczenie moliwoci wymiany procesora do podzespoów nalecych
do tej samej rodziny zmniejsza zakres dostpnych moliwoci.
Zapobieganie efektowi domina
O efekcie domina mówimy wtedy, gdy zmiana wymusza modyfikacje w moduach, na które nie
ma bezporedniego wpywu. Przykadowo modu A zostaje zmodyfikowany w celu wprowadzenia
pewnej zmiany, co prowadzi do koniecznoci modyfikacji moduu B, która wynika wy-
cznie z tego, e zmieni si modu A. Modu B wymaga zmiany, poniewa jest w taki czy inny
sposób powizany z moduem A.
Omówienie efektu domina zaczniemy od rozwaenia rónych rodzajów zalenoci midzy
moduami. Mona wyróni osiem typów takiego powizania:
(1) Skadnia:
danych — aby modu B by poprawnie kompilowany (lub wykonywany), typ (lub
format) danych generowanych przez modu A i pobieranych przez modu B musi by
zgodny z typem (lub formatem) danych, których oczekuje modu B;
usug — aby modu B by poprawnie kompilowany i wykonywany, sygnatura usug
zapewnianych przez modu A i wywoywanych przez modu B musi by zgodna
z zaoeniami moduu B.
(2) Semantyka:
danych — aby modu B by poprawnie wykonywany, semantyka danych generowanych
przez modu A i pobieranych przez modu B musi by zgodna z zaoeniami
moduu B;
usug — aby modu B by poprawnie wykonywany, semantyka usug zapewnianych
przez modu A i uywanych przez modu B musi by zgodna z zaoeniami moduu B.
(3) Kolejno:
danych — aby modu B by poprawnie wykonywany, musi on otrzymywa dane generowane
przez modu A w ustalonej kolejnoci; na przykad nagówek pakietu danych
musi w trakcie odbierania poprzedza waciw tre (w przeciwiestwie do
protokoów, które doczaj do danych numery sekwencyjne);

5.3. TAKTYKI MODYFIKOWALNOCI 115
sterowania — aby modu B by poprawnie wykonywany, wczeniej, w okrelonych
ramach czasowych, musz zosta wykonane procedury moduu A. Przykadowo procedury
moduu A musz zosta wykonane nie duej ni 5 milisekund przed rozpoczciem
wykonywania moduu B.
(4) Tosamo interfejsu moduu A — modu A moe mie wiele interfejsów. Aby modu B
by poprawnie kompilowany i wykonywany, tosamo (nazwa lub uchwyt) interfejsu
musi by zgodna z oczekiwaniami moduu B.
(5) Lokalizacja moduu A w czasie wykonywania — aby modu B by poprawnie wykonywany,
lokalizacja moduu A w czasie wykonywania musi by zgodna z oczekiwaniami
moduu B. Przykadowo modu B moe zakada, e modu A pracuje w innym procesie
na tym samym procesorze.
(6) Jako usug/danych zapewnianych przez modu A — aby modu B by poprawnie wykonywany,
pewne wasnoci dotyczce danych lub usug zapewnianych przez modu A musz
by zgodne z zaoeniami moduu B. Przykadowo dane dostarczane przez czujnik musz
mie pewn dokadno, aby algorytmy w module B dziaay poprawnie.
(7) Istnienie moduu A — aby modu B by poprawnie wykonywany, modu A musi istnie.
Jeeli na przykad obiekt B da usugi obiektu A, a obiekt ten nie istnieje lub nie moe
zosta dynamicznie utworzony, dziaanie obiektu B nie bdzie poprawne.
(8) Sposób korzystania z zasobów — aby modu B by poprawnie wykonywany, sposób korzystania
z zasobów przez modu A musi by zgodny z zaoeniami moduu B. Moe to
dotyczy uytkowania zasobów (A uywa tej samej pamici co B) lub wasnoci zasobów
(B rezerwuje zasób, który A uwaa za wasny).
Dysponujc tak sprecyzowanymi kategoriami zalenoci, moemy przej do omówienia dostpnych
architektowi taktyk pozwalajcych zapobiega efektowi domina dla wybranych z nich.
Warto zwróci uwag, e adna z prezentowanych taktyk nie zapewnia zabezpieczenia przed
efektem domina dla zmian semantycznych. Rozpoczniemy omówienie od taktyk, które odnosz
si do interfejsów moduu — ukrywania informacji i utrzymywania istniejcych ju interfejsów,
aby nastpnie przej do taktyk przerywania acucha zalenoci — uycia porednika.
Ukrywanie informacji. Ukrywanie informacji to dekompozycja zakresu odpowiedzialno-
ci pewnej jednostki (systemu lub czci systemu) na mniejsze elementy i okrelanie, które
z nich maj mie charakter prywatny, a które publiczny. Publiczny zakres odpowiedzialnoci
to zakres dostpny za porednictwem interfejsów. Celem jest doprowadzenie do izolacji
zmian wewntrz moduu i zapobieenie ich propagacji na inne moduy. Jest to najstarsza
technika ograniczania skutków zmian. Jest ona mocno powizana z przewidywaniem
oczekiwanych modyfikacji, poniewa modyfikacje te staj si podstaw dekompozycji.
Zachowywanie istniejcych interfejsów. Jeeli modu B jest zaleny od nazwy i sygnatury
interfejsu moduu A, utrzymanie tego interfejsu i jego skadni pozwala unikn
zmian w module B. Oczywicie, nie jest to taktyka bezwzgldnie skuteczna, gdy modu B
jest zaleny od moduu A semantycznie, poniewa warstwa znaczeniowa danych i usug jest
trudniejsza do zamaskowania. To samo mona powiedzie o maskowaniu zalenoci bazujcych
na jakoci danych lub usug, poziomie wykorzystania zasobów lub wasnoci zasobów.
Stabilno interfejsu mona te osign oddzielajc interfejs od implementacji. Pozwala
to tworzy abstrakcyjne interfejsy maskujce zrónicowanie. Odmiany mona realizowa
w ramach istniejcego zakresu odpowiedzialnoci lub przez zastpowanie implementacji.
Wzorce bazujce na tej taktyce to przede wszystkim:
dodawanie interfejsów — wikszo jzyków programowania pozwala na stosowanie
wielu interfejsów; nowe usugi lub dane mog by udostpniane poprzez nowe interfejsy,
dziki czemu starsze pozostaj niezmienione i zachowuj sygnatury;

116 5. UZYSKIWANIE ATRYBUTÓW JAKOCIOWYCH
dodawanie adaptera — polega na dodaniu do moduu A adaptera, który go osania
i zapewnia pierwotn sygnatur;
korzystanie z wersji zastpczej — jeeli modyfikacja prowadzi do usunicia moduu
A, to zapewnienie jego wersji zastpczej pozwoli zachowa modu B w niezmienionej
postaci (jeeli modu B jest zaleny tylko od sygnatury moduu A).
Ograniczanie cieek komunikacji. Taktyka polegajca na ograniczaniu liczby moduów,
z którymi dany modu wymienia lub wspóuytkuje dane — projektant dy do uzyskania
jak najmniejszej liczby moduów, które pobieraj dane z moduu rozwaanego lub przekazuj
je do niego. Efekt domina zostaje zredukowany, poniewa generowanie i pobieranie
danych odpowiada za wprowadzenie powodujcych go zalenoci. Wzorzec korzystajcy
z tej taktyki zostanie zaprezentowany w rozdziale 8. (symulator lotu).
Uycie porednika. Jeeli modu A czy z moduem B pewien rodzaj zalenoci inny ni
semantyczna, to jest moliwe umieszczenie porednika midzy B i A, którego zadaniem
jest zarzdzanie czynnociami zwizanymi z t zalenoci. Nazw takich poredników jest
wiele. Tutaj omówimy poszczególne z nich w kategoriach wyliczonych wczeniej typów
zalenoci. Podobnie jak wczeniej czarnym scenariuszem jest brak moliwoci kompensacji
zmian semantycznych.
Dane (skadnia). Rol porednika midzy producentem i konsumentem danych
przyjmuj magazyny danych (pasywne lub typu podrcznej tablicy). Niektóre wzorce
publikowania-subskrypcji (w których dane przepywaj przez pewien komponent
centralny) mog te zapewnia konwersj skadni generowanej przez modu A do tej,
której oczekuje modu B. Wzorce MVC i PAC zapewniaj konwersj danych z jednej
postaci (zwizanej z urzdzeniem wejciowym lub wyjciowym) na inn (uywan
w modelu w MVC lub w abstrakcji w PAC).
Usugi (skadnia). Fasada, most, mediator, strategia, proxy i fabryka to wzorce
wprowadzajce porednika konwertujcego skadni usugi. Kady z nich prowadzi
do zabezpieczenia przed propagacj zmian.
Tosamo interfejsu moduu A. Wzorzec brokera pozwala zamaskowa zmiany
w tosamoci interfejsu. Jeeli modu B jest zaleny od tosamoci interfejsu moduu A
i tosamo ta ulega zmianie, dodanie tosamoci do brokera i pozostawienie brokerowi
tworzenia poczenia z now tosamoci A pozwala pozostawi modu B bez zmian.
Lokalizacja moduu A w czasie wykonywania. Serwer nazw pozwala zmienia lokalizacj
A bez wpywu na B. A odpowiada za rejestrowanie swojej biecej lokalizacji
na serwerze nazw, a B pobiera z niego aktualne informacje.
Sposób korzystania z zasobów lub kontrola zasobu przez modu A. Meneder zasobów
to porednik odpowiedzialny za ich alokowanie. Istniej menedery gwarantujce
zaspokojenie wszystkich da mieszczcych si w okrelonych ograniczeniach (na
przykad menedery z przypisywaniem monotonicznym wedug czstotliwoci, stosowane
w systemach czasu rzeczywistego). Oczywicie, zastosowanie menedera wi-
e si z przejciem przez niego kontroli nad zasobem.
Istnienie moduu A. Wzorzec fabryki daje moliwo tworzenia obiektów odpowiednio
do potrzeb, dziki czemu problem zalenoci obiektu B od istnienia obiektu A rozwizuje
specjalny modu fabryki.

5.3. TAKTYKI MODYFIKOWALNOCI 117
Opónianie czasu wizania
Omówione kategorie taktyk prowadz do zmniejszenia liczby moduów wymagajcych modyfikacji
w celu wprowadzenia zmiany. W naszych scenariuszach modyfikowalnoci pojawiy si jednak
dwa elementy, których nie mona sprowadzi do redukcji liczby modyfikowanych czci programu
— czas wdroenia i umoliwienie wprowadzania zmian osobom innym ni programici.
Realizacj tych scenariuszy umoliwia opónianie czasu wizania. Z taktykami tego rodzaju
niezmiennie wie si istotny koszt dodatkowej infrastruktury, która umoliwi póne wizanie.
Wizanie pewnego wyboru z dziaaniem systemu moe nastpi w rónych momentach. Tutaj
zajmiemy si jedynie aspektami, które maj wpyw na czas wdraania. Wdraanie systemu jest
pewnym procesem — po wprowadzeniu przez programist zmiany nastpuj zazwyczaj procedury
testowania i dystrybucji. Wystpuje wic istotne opónienie midzy modyfikacj a dostpnoci
nowej wersji czy konfiguracji programu. Wprowadzenie wizania w czasie wykonywania
oznacza, e system zosta odpowiednio przygotowany i ukoczono wszystkie kroki
zwizane z testowaniem i dystrybucj. Taktyka opóniania czasu wizania prowadzi do powstawania
mechanizmów umoliwiajcych uytkownikowi lub administratorowi operowanie
parametrami, które zmieniaj zachowanie systemu.
Wszystkie wymienione poniej taktyki maj wpyw na system w czasie adowania lub w czasie
wykonywania.
Rejestracja w czasie wykonywania umoliwia uzyskanie mechanizmu typu plug-and-play
kosztem dodatkowego obcienia operacjami zwizanymi z rejestrowaniem. Przykadem
moe by rejestracja typu publikacja-subskrypcja, któr mona implementowa w czasie
wykonywania lub w czasie adowania.
Pliki konfiguracyjne okrelaj parametry uruchomieniowe.
Polimorfizm umoliwia póne wizanie wywoa metod.
Wymienno komponentów pozwala na wizanie w czasie adowania.
Przestrzeganie protokoów pozwala wiza w czasie wykonywania niezalene procesy.
Taktyki modyfikowalnoci podsumowuje rysunek 5.5.
Rysunek 5.5. Taktyki modyfikowalnoci

118 5. UZYSKIWANIE ATRYBUTÓW JAKOCIOWYCH
5.4. Taktyki wydajnoci
Przypomnijmy z rozdziau 4., e celem taktyk wydajnoci jest uzyskanie reakcji na odbierane
przez system zdarzenie w ramach pewnych ogranicze czasowych. Zdarzenie lub cig zdarze
inicjuje pewne obliczenia lub funkcje. Sygnaem moe by nadejcie komunikatu, upynicie
pewnego czasu, wykrycie znaczcej zmiany stanu w rodowisku systemu itp. System przetwarza
zdarzenia i generuje reakcj. Taktyki wydajnoci pozwalaj uzyska kontrol nad iloci
czasu, który musi upyn midzy zdarzeniem a reakcj. Ilustruje to rysunek 5.6. Czas midzy
odebraniem zdarzenia a wygenerowaniem odpowiedzi okrela si terminem latencja.
Rysunek 5.6. Cel taktyk wydajnoci
Po odebraniu zdarzenia nastpuje jego przetwarzanie. Moe ono zosta z pewnych przyczyn
zablokowane. Dwa podstawowe czynniki o duym wpywie na czas odpowiedzi to: poziom
wykorzystania zasobów i czas blokad.
1. Poziom wykorzystania zasobów. Zasoby to przede wszystkim procesor, magazyny danych,
pasmo komunikacyjne sieci i pami, ale pojcie to obejmuje te obiekty definiowane
w ramach konstrukcji systemu. Przykadami mog by wymagajce zarzdzania bufory lub konieczno
zapewnienia sekwencyjnego dostpu do sekcji krytycznych. Zdarzenia mog mie
róny charakter i dla kadego typu zdarzenia wymagana jest pewna sekwencja przetwarzania.
Przykadowo jeden komponent generuje komunikat, przekazuje go do sieci i komunikat ten
zostaje odebrany przez inny komponent. Zostaje wówczas umieszczony w buforze; w pewien
sposób przeksztacony (tak zwany marshalling w terminologii OMG); przetworzony zgodnie
z pewnym algorytmem; przesany do wyjcia; umieszczony w buforze wyjciowym i przekazany
dalej, do innego komponentu lub systemu albo do uytkownika. Kada z tych faz ma swój
udzia w ogólnej latencji przetwarzania zdarzenia.
2. Czas blokad. Procedury przetwarzania mog nie uzyska dostpu do zasobu — ze
wzgldu na jego nadmierne obcienie, cakowit niedostpno lub poniewa niezbdny jest
wynik innych procedur, który nie jest jeszcze dostpny.
Spory o zasoby. Rysunek 5.6 przedstawia odbierane przez system zdarzenia. Odbiór
moe nastpowa w pojedynczym strumieniu lub wielu strumieniach. Róne strumienie
potrzebujce tego samego zasobu lub róne zdarzenia w tym samym strumieniu,
które potrzebuj tego samego zasobu, wprowadzaj czsto istotne opónienia.
Ogólnie — im wicej sporów o zasoby, tym wiksze prawdopodobiestwo wystpienia
dodatkowej latencji. Zaley to jednak od metod arbitrau sporów i sposobu traktowania
poszczególnych da.
Dostpno zasobów. Nawet gdy nie wystpuj spory o zasoby, obliczenia mog zosta
zablokowane przez ich niedostpno. Przyczyn moe by na przykad wyczenie
lub awaria. Architekt powinien zawsze zidentyfikowa miejsca, w których
niedostpno zasobów moe mie znaczcy wpyw na ogóln latencj reakcji.

5.4. TAKTYKI WYDAJNOCI 119
Zaleno od innych oblicze. Obliczenia mog zosta wstrzymane przez konieczno
synchronizacji z wynikami innych oblicze lub oczekiwanie na wynik operacji
skadowych. Przykadowo w trakcie odczytu z dwóch rónych róde, gdy ich odczytywanie
jest sekwencyjne, latencja jest wiksza ni przy równolegym odczycie z obu.
Na tym koczymy wprowadzenie i przechodzimy do omówienia trzech kategorii taktyk. Operuj
one w trzech obszarach: zapotrzebowania na zasoby, zarzdzania zasobami i arbitrau dostpu
do zasobów.
Zapotrzebowanie na zasoby
Strumienie zdarze stanowi ródo zapotrzebowania na zasoby. Dwa parametry opisujce to
zapotrzebowanie to odstp czasu midzy zdarzeniami (jak czsto w strumieniu pojawia si nowe
danie) oraz stopie wykorzystania zasobu przez poszczególne dania.
Jedn z taktyk zmniejszania latencji jest redukowanie wymaganych do przetwarzania zdarze
zasobów. Metody ograniczania zapotrzebowania na zasoby to midzy innymi:
Zwikszenie efektywnoci przetwarzania. Jednym z kroków przetwarzania zdarzenia
lub komunikatu jest uycie pewnego algorytmu. Usprawnianie algorytmów wykorzystywanych
w krytycznych miejscach moe doprowadzi do zmniejszenia latencji. Czasem
mona zmniejszy poziom wykorzystania jednego zasobu kosztem innego. Przykadowo
wartoci porednie mona przechowywa w repozytorium lub generowa — zaley to od
dostpnego miejsca i czasu. Jest to taktyka zwizana przede wszystkim z procesorem, ale
mona korzysta z niej take w odniesieniu do innych zasobów, na przykad dysku.
Zmniejszenie obcienia. Jeeli nie nadchodz dania zwizane z pewnym zasobem, zapotrzebowanie
maleje. W rozdziale 17. zobaczymy przykad wykorzystania klas jzyka Java
w miejsce zdalnych wywoa metod (ang. Remote Method Invocation — RMI) — pozwala
to zredukowa wymagania dotyczce komunikacji. Korzystanie z poredników (tak wane
dla modyfikowalnoci) zwiksza poziom wykorzystania zasobów w trakcie przetwarzania
strumienia zdarze. Usunicie porednika moe wic by skuteczn metod zmniejszenia
latencji. Jest to typowy przykad kompromisu midzy modyfikowalnoci a wydajnoci.
Kolejna grupa taktyk redukowania latencji opiera si na zmniejszaniu liczby wymagajcych
przetwarzania zdarze. Mona to osign dwiema drogami:
Zarzdzanie czstoci zdarze. Jeeli jest moliwe zredukowanie czstotliwoci próbkowania
danych przechowywanych w opisujcych rodowisko zmiennych, jest to prosta
droga do zmniejszenia zapotrzebowania na zasoby. Czasem moliwo zmniejszenia czstoci
zdarze jest skutkiem nadmiernej, niepotrzebnej zoonoci. Niekiedy zawyon
czstotliwo próbkowania uzasadnia potrzeba uzyskania zharmonizowanych odstpów
dla rónych strumieni zdarze — niektóre z nich s odczytywane czciej jedynie dla zachowania
synchronizacji z innymi.
Sterowanie czstotliwoci próbkowania. Jeeli nie mona uzyska kontroli nad odbieraniem
generowanych zewntrznie zdarze, mona próbkowa z mniejsz czstotliwoci dania
przechowywane w kolejce — z uwzgldnieniem ewentualnej utraty danych lub nie.

120 5. UZYSKIWANIE ATRYBUTÓW JAKOCIOWYCH
Jeszcze inn drog do opanowania zapotrzebowania na zasoby jest sterowanie korzystaniem
z tych zasobów.
Ograniczanie czasu wykonania. Mona okreli limit czasu reakcji na zdarzenie. W przypadku
algorytmów iteracyjnych, bazujcych na danych tak metod jest wyznaczenie limitu
liczby powtórze.
Ograniczenie rozmiaru kolejki. Jest to okrelenie maksymalnego rozmiaru kolejki odbioru,
a wic bezporednie ograniczenie zasobów wykorzystywanych do przetwarzania
zawartoci tej kolejki.
Zarzdzanie zasobami
Nawet jeeli zapotrzebowanie na zasoby nie moe zosta poddane wystarczajcej kontroli,
skrócenie czasu reakcji mona uzyska przez odpowiednie zarzdzanie tymi zasobami. Do takich
taktyk nale:
Wprowadzenie wspóbienoci. Jeeli dania mog by przetwarzane równolegle, czas
blokad moe ulec skróceniu. Wspóbieno mona wprowadzi dwoma metodami: poprzez
przetwarzanie rónych strumieni zdarze w odrbnych wtkach lub tworzenie wtków
wykonujcych pewne zbiory operacji. Po wprowadzeniu wspóbienoci wane jest
waciwe przypisywanie wtków do zasobów (równowaenie obcienia).
Przechowywanie wielu kopii danych lub funkcji obliczeniowych. W schemacie klientserwer
klienty s replikami funkcji obliczeniowych. Zapewniaj one zmniejszenie rywalizacji
o zasoby, która byaby znaczcym problemem w przypadku wykonywania caoci
przetwarzania na serwerze. Metod replikacji danych jest buforowanie (pami podrczna)
— niezalenie od tego, czy szybko pracy magazynów danych jest jednolita, czy róna,
zmniejsza ono spory o dostp do zasobów. Poniewa buforowane dane to zazwyczaj
kopia przechowywanych we waciwym magazynie danych, system obcia dodatkowa
odpowiedzialno za utrzymanie spójnoci i synchronizacji pamici podrcznej.
Zwikszenie dostpnych zasobów. Szybsze procesory, dodatkowe procesory, dodatkowa
pami, szybsza sie — to proste rozwizania o istotnym potencjale zmniejszania latencji.
Wie si z nimi zazwyczaj problem kosztów. Do tego rodzaju kompromisu midzy kosztem
a wydajnoci powrócimy jeszcze w rozdziale 12.
Arbitra dostpu do zasobów
Zawsze, gdy pojawia si spór o pewien zasób, pojawia si te szeregowanie. Szereguje si dostp
do procesorów, buforów i sieci. Zadaniem architekta jest poznanie specyfiki wykorzystania
kadego zasobu i wybranie dopasowanej do niego strategii szeregowania.
Schemat szeregowania skada si z dwóch elementów: przypisywania priorytetów i przydzielania
zasobu. O okrelaniu priorytetów mona mówi w kadym schemacie. Najprostsza
regua to FIFO (ang. first-in/first-out — pierwszy wchodzi, pierwszy wychodzi). O priorytecie
moe decydowa limit czasu dania lub wynikajcy z semantyki poziom wanoci. Lista potencjalnych
kryteriów — które z reguy konkuruj ze sob — obejmuje midzy innymi wano
dania, denie do optymalnego wykorzystania zasobów, minimalizowanie liczby uywanych
zasobów, minimalizowanie latencji, maksymalizowanie przepustowoci i denie do
uniknicia „zagodzenia” (równo traktowania klientów). Architekt musi zdawa sobie spraw
z tego, które z nich s istotne i jaki wpyw ma na nie wybierana taktyka.

5.4. TAKTYKI WYDAJNOCI 121
Strumie zdarze o wysokim priorytecie moe zosta przydzielony tylko wtedy, gdy jest
dostpny odpowiedni zasób. Czasem wymaga to wywaszczenia biecego uytkownika zasobu.
Mona wybra jeden z trzech schematów wywaszczania: w dowolnym momencie, w cile
okrelonych punktach lub bez wywaszczania pracujcych procesów. Jako popularne schematy
szeregowania warto wymieni:
1. FIFO (pierwszy wchodzi, pierwszy wychodzi). Kolejka FIFO traktuje wszystkie dania
jednakowo i zaspokaja je kolejno. Podstawowym problemem jest w tym przypadku potencjalne
opónienie przetwarzania dania, które nastpuje po takim, które okazuje si wyjtkowo
czasochonne. Jeeli komunikaty s faktycznie równorzdne, nie jest to zazwyczaj
kopotliwe. Jeeli jednak w strumieniu s dania waniejsze od innych, metoda FIFO bywa
niewystarczajca.
2. Szeregowanie ze staym priorytetem. W tym schemacie kademu ródu da dostpu
do zasobów przypisywany jest pewien priorytet, który decyduje nastpnie o kolejnoci przypisa.
Zapewnia to lepsz obsug da o wysokim priorytecie, ale dopuszcza moliwo, e danie
o niskim priorytecie, ale wci istotne bdzie oczekiwa na obsug bardzo dugo — jeeli poprzedzi
je seria da ze róda uprzywilejowanego. Trzy popularne klucze przypisywania
priorytetów to:
Waga semantyczna. Strumienie otrzymuj statyczne priorytety oparte na cechach
zada, z którymi s powizane (cechach z dziedziny problemu). Takie podejcie do
szeregowania stosuje si w systemach mainframe, gdzie cech z dziedziny problemu
jest czas zainicjowania zadania.
Przypisywanie monotoniczne wedug limitu czasu. Statyczna metoda przypisywania
priorytetów, w której preferowane s strumienie o krótszych limitach czasu przetwarzania.
Stosowana najczciej przy szeregowaniu strumieni o rónych priorytetach
powizanych z limitami przetwarzania w czasie rzeczywistym.
Przypisywanie monotoniczne wedug czstotliwoci. Statyczna metoda przypisywania
priorytetów strumieniom o charakterze okresowym, w której preferowane s
strumienie o krótszym okresie. Jest to szczególny przypadek przypisywania wedug
limitu czasu, a zarazem metoda bardziej znana i czciej dostpna w rónych systemach
operacyjnych.
3. Szeregowanie z dynamicznie okrelanym priorytetem.
Karuzelowe. Strategia polegajca na uporzdkowaniu da, które nastpnie kolejno
otrzymuj zasoby — za kadym razem, gdy pojawia si moliwo przypisania dania.
Szczególn form szeregowania karuzelowego jest zasada inicjowania nowych przypisa
w staych odstpach czasu.
Wedug terminów wykonania. Najwyszy priorytet otrzymuj dania z najbliszym
terminem wykonania.
4. Szeregowanie statyczne. Cykliczny mechanizm oparty na strategii, dla której punkty
wywaszczania i sekwencja przypisa zostay okrelone przed uruchomieniem systemu.
Lista polecanej literatury na kocu rozdziau zawiera tytuy ksiek powiconych szeregowaniu.
Rysunek 5.7 przedstawia podsumowanie taktyk wydajnoci.

122 5. UZYSKIWANIE ATRYBUTÓW JAKOCIOWYCH
Rysunek 5.7. Podsumowanie taktyk wydajnoci
5.5. Taktyki bezpieczestwa
Taktyki ukierunkowane na zapewnienie bezpieczestwa operuj w trzech obszarach: odpierania
ataków, wykrywania ataków i przywracania stanu po ataku. Kady z nich jest istotny. Mona
przytoczy czyteln analogi — zamek w drzwiach to metoda obrony przed atakami, czujnik
ruchu wewntrz domu to system wykrywania ataków, a posiadanie ubezpieczenia to rozwizanie
umoliwiajce przywrócenie stanu. Rysunek 5.8 ilustruje cele taktyk bezpieczestwa.
Rysunek 5.8. Cel taktyk bezpieczestwa
Obrona przed atakami
Przedstawiona w rozdziale 4. lista celów opisujcych bezpieczestwo obejmuje niezaprzeczalno,
poufno, integralno (spójno) i pewno tosamoci. W deniu do ich osignicia
pomocne jest czenie poniszych taktyk:
Uwierzytelnianie uytkowników. Uwierzytelnianie to sprawdzanie, czy uytkownik lub
komputer jest tym, za kogo si podaje. Mona stosowa hasa, hasa jednorazowe, certyfikaty
lub identyfikacj biometryczn.

5.5. TAKTYKI BEZPIECZESTWA 123
Autoryzowanie uytkowników. Autoryzowanie to sprawdzanie, czy uwierzytelniony
uytkownik ma prawa dostpu i modyfikacji danych lub usug. Jest to zazwyczaj zapewniane
przez wprowadzenie w systemie pewnych schematów kontroli dostpu. Prawa dostpu
przyznaje si uytkownikom lub klasom uytkowników. Definiowanie klas uytkowników
moe opiera si na pojciu grupy bd roli lub listach uytkowników.
Poufno danych. Dane powinny by zabezpieczone przed nieautoryzowanym dostpem.
Poufno uzyskuje si zazwyczaj przez wprowadzenie szyfrowania danych i pocze komunikacyjnych.
Szyfrowanie jest dodatkowym zabezpieczeniem danych trwaych, które
w znaczcy sposób uzupenia mechanizmy autoryzowania dostpu. Co wicej, cza komunikacyjne
nie zapewniaj zwykle autoryzacji. Szyfrowanie jest jedyn oson przy przekazywaniu
danych przez cza dostpne publicznie. Poczenie szyfrowane mona implementowa
jako prywatn sie wirtualn (ang. virtual private network — VPN) lub, w przypadku
komunikacji WWW, jako warstw gniazd z zabezpieczeniami, czyli SSL (ang. Secure
Sockets Layer). Szyfrowanie moe by symetryczne (obie strony uywaj tego samego klucza)
lub niesymetryczne (klucze publiczny i prywatny).
Utrzymywanie integralnoci. Dane powinny zosta dostarczone w postaci zgodnej z oczekiwaniami.
Ich poprawno mona weryfikowa w oparciu o doczane informacje nadmiarowe
— takie jak sumy kontrolne i skróty — szyfrowane niezalenie od waciwych danych
lub w poczeniu z nimi.
Redukcja naraenia na atak. Podstaw ataku jest zazwyczaj moliwo wykorzystania jednego
sabo chronionego punktu, który pozwala uzyska dostp do wszystkich danych i usug
stacji. Architekt moe tak zaprojektowa przypisania komponentów do stacji, by kada z nich
oferowaa jak najwszy zespó usug.
Ograniczanie dostpu. Zapory sieciowe ograniczaj dostp w oparciu o ródo komunikatu
lub port docelowy. Komunikaty z nieznanych róde mog by form ataku. Nie zawsze
jednak mona ograniczy dostp wycznie do znanych róde. Publiczna witryna WWW mo-
e oczekiwa da z dowolnych stacji sieciowych. Jedn z uywanych w takich przypadkach
konfiguracji jest tak zwana strefa zdemilitaryzowana (ang. demilitarized zone —
DMZ). Konfiguracja DMZ daje dostp do usug internetowych, ale nie do sieci lokalnej.
Strefa zdemilitaryzowana to obszar funkcjonujcy pomidzy internetem a zapor chronic
sie wewntrzn. Umieszcza si w nim urzdzenia, które powinny odbiera komunikaty
z dowolnych róde. Pracuj na nich gównie usugi WWW, pocztowe i DNS.
Wykrywanie ataków
Wykrywanie ataku zapewnia zazwyczaj specjalny system wykrywania wama (ang. intrusion
detection system). Jego dziaanie opiera si na porównywaniu schematów ruch sieciowego z wzorcami
w bazie danych. Wykrywanie naduy oznacza porównywanie z wzorcami znanych ataków.
Wykrywanie anomalii z kolei polega na porównywaniu biecego ruchu w sieci z zarejestrowanymi
wczeniej schematami tego ruchu. Aby porównanie byo moliwe, czsto konieczne jest
filtrowanie pakietów. Filtrowanie moe opiera si na protokole, znacznikach TCP, rozmiarach
adunku, adresie ródowym, adresie docelowym lub numerze portu.
System wykrywania wama musi dysponowa pewnego rodzaju czujnikiem wykrywajcym
ataki, oprogramowaniem zarzdzajcym, które analizuje informacje i podejmuje odpowiednie
czynnoci, baz danych do przechowywania rejestru zdarze w celu póniejszej analizy,
narzdziami do budowania analiz i raportów oraz konsol sterujc, która umoliwia
analitykowi modyfikowanie podejmowanych w przypadku wamania dziaa.

124 5. UZYSKIWANIE ATRYBUTÓW JAKOCIOWYCH
Przywracanie do pracy po ataku
Taktyki wspomagajce przywracanie stanu systemu po ataku mona podzieli na bezporednio
zwizane z przywróceniem normalnego funkcjonowania oraz ukierunkowane na identyfikacj
atakujcego (jeeli nie w celu ukarania, to po to, by zabezpieczy si przed ponownymi atakami).
Taktyki przywracania systemu lub danych do waciwego stanu pokrywaj si z taktykami
zapewniajcymi dostpno — w obu przypadkach chodzi o przywrócenie spójnoci. Gówn
rónic jest konieczno szczególnego traktowania nadmiarowych kopii danych o charakterze
administracyjnym, takich jak hasa, listy kontroli dostpu, konfiguracje usug nazw i dane
profili uytkowników.
Podstawowa taktyka wspomagajca identyfikowanie atakujcych to utrzymywanie zapisu
przebiegu zdarze (ang. audit trail). Jest to kopia kadej transakcji na danych w systemie wraz
z informacjami umoliwiajcymi identyfikacj. Informacje te mona wykorzystywa do ledzenia
dziaa atakujcego, w realizacji zasady niezaprzeczalnoci (jest to dowód odebrania okre-
lonego dania) lub przy operacjach przywracania stanu systemu. Dzienniki zdarze s czsto
jednym z celów ataku, wic powinny by odpowiednio przechowywane.
Rysunek 5.9 przedstawia podsumowanie taktyk bezpieczestwa.
Rysunek 5.9. Taktyki bezpieczestwa
5.6. Taktyki testowalnoci
Celem taktyk testowalnoci jest umoliwienie atwiejszego testowania, gdy koczona jest praca
nad kolejn czci oprogramowania. Rysunek 5.10 ilustruje zasad ich stosowania. Budowie
architektury pod ktem wysokiej testowalnoci oprogramowania nie powica si tyle uwagi co
lepiej zbadanym aspektom jakoci — modyfikowalnoci, wydajnoci czy dostpnoci, ale — jak
pisalimy w rozdziale 4. — poniewa testowanie odpowiada za du cz kosztów systemu, to
wszystko, co mona zrobi w kierunku jego usprawnienia, przyniesie znaczce korzyci.

5.6. TAKTYKI TESTOWALNOCI 125
Rysunek 5.10. Cel taktyk testowalnoci
Cho w rozdziale 4. wspomnielimy o przegldach projektu jako metodzie testowania, tutaj
zajmiemy si jedynie testowaniem uruchomionego systemu. Celem procedur testowania jest
wykrycie usterek. Wie si to z koniecznoci zapewnienia dla testowanego oprogramowania
danych wejciowych oraz mechanizmu przechwytywania danych wyjciowych.
Do uruchamiania testów jest potrzebne dodatkowe oprogramowanie przekazujce dane
wejciowe i odbierajce dane wyjciowe — jest to tak zwane jarzmo testów (ang. test harness).
Nie bdziemy tu szczegóowo rozpatrywa problemów zwizanych z jego konstrukcj i generowaniem.
Czasem praca nad jarzmem testów jest znaczc czci pracy nad caym systemem.
Omówimy dwie kategorie taktyk wspomagajcych testowanie: zwizane z przekazywaniem
i odbieraniem danych oraz zwizane z wewntrznym monitorowaniem systemu.
Wejcie-wyjcie
Mona wyróni trzy taktyki zarzdzania wejciami i wyjciami:
Rejestrowanie-odtwarzanie. Metoda, w której informacje przechodzce przez interfejs s
przechwytywane i wykorzystywane jako dane dla jarzma testów. Informacje przechodzce
przez interfejs w trakcie normalnej pracy zostaj zapisane w pewnym magazynie — reprezentuj
one dane wyjciowe jednego komponentu, a zarazem dane wejciowe innego. Ich rejestrowanie
rozwizuje problem generowania danych wejciowych dla drugiego z tych komponentów
oraz problem dostpnoci do porówna danych opisujcych prac pierwszego.
Oddzielanie interfejsu od implementacji. Oddzielenie interfejsu od implementacji pozwala
wymienia implementacje na czas rónego rodzaju testów. Elementy zastpcze
umoliwiaj testowanie pozostaej czci systemu, mimo e waciwe wersje tych elementów
nie s jeszcze gotowe. Po wprowadzeniu ukoczonych elementów wycofywany kod
moe zosta doczony do jarzma testów.
Specjalne kanay dostpu/interfejsy. Przygotowanie specjalnego interfejsu wspomagajcego
testowanie pozwala przechwytywa lub okrela wartoci zmiennych komponentu niezalenie
od jego normalnej pracy. Przykadem moe by udostpnienie specjalnego interfejsu
dostpu do metadanych, wykorzystywanego w pracy jarzma testów. Interfejsy i kanay
dostpu przeznaczone do tego rodzaju zastosowa powinny by wyranie oddzielone od
tych, które wykorzystuje si w realizacji wyspecyfikowanych funkcji systemu. Wprowadzenie
w architekturze hierarchii interfejsów sucych do testowania prowadzi do sytuacji,
kiedy testy mog by uruchamiane na rónych poziomach oprogramowania, które
dysponuj ogólnymi mechanizmami umoliwiajcymi badanie reakcji.

126 5. UZYSKIWANIE ATRYBUTÓW JAKOCIOWYCH
Wewntrzne monitorowanie pracy
Testowanie mog wspomaga taktyki dotyczce wewntrznych informacji o stanie:
Wbudowany mechanizm monitorowania. Interfejs moe udostpnia informacje o stanie,
obcieniu, dopuszczalnym obcieniu, zabezpieczeniach i inne. Moe to by trway
interfejs komponentu lub interfejs wprowadzany tymczasowo — przy uyciu takich metod,
jak makra preprocesora lub programowanie aspektowe. Wczenie monitorowania
oznacza zazwyczaj rozpoczcie rejestrowania zdarze. Warto zwróci uwag, e korzystanie
z takiego rozwizania moe doprowadzi do wyduenia testów, poniewa musz one
by powtarzane take po wyczeniu ledzenia. Jednak korzyci z uwidocznienia przebiegu
pracy komponentu bardzo czsto przewyszaj koszty dodatkowego testowania.
Rysunek 5.11 przedstawia podsumowanie taktyk testowalnoci.
Rysunek 5.11. Taktyki testowalnoci
5.7. Taktyki funkcjonalnoci
Przypomnijmy z rozdziau 4., e pojcie funkcjonalnoci odnosi si do tego, jak atwo uytkownik
moe wykonywa swoje zadania oraz na jak pomoc ze strony systemu moe liczy. Do
zwikszenia funkcjonalnoci prowadz dwie kategorie taktyk. Kada z nich dotyczy innej klasy
„uytkowników”. Pierwsza kategoria, taktyki czasu wykonywania, polega na wspomaganiu dzia-
a uytkownika w trakcie pracy systemu. Druga wie si z iteracyjnym charakterem procedur
projektowania interfejsu uytkownika. Jest to pomoc dla twórcy interfejsu w czasie projektowania.
Jest ona zbliona w swoim charakterze do omawianych wczeniej taktyk modyfikowalnoci.
Rysunek 5.12 przedstawia cel taktyk funkcjonalnoci dla czasu wykonywania.
Rysunek 5.12. Cel taktyk funkcjonalnoci dla czasu wykonywania

5.7. TAKTYKI FUNKCJONALNOCI 127
Taktyki dla czasu wykonywania
W trakcie pracy systemu podstawowym mechanizmem sprzyjajcym funkcjonalnoci jest
przekazywanie uytkownikowi informacji zwrotnych, które opisuj wykonywane przez system
czynnoci i daj uytkownikowi moliwo korzystania ze specjalnych polece (o kilku wspomnielimy
w rozdziale 4.). Anuluj, Cofnij, Scal i Poka wiele widoków jednoczenie to typowe
funkcje wspierajce uytkownika w korygowaniu bdów lub deniu do efektywnej pracy.
Badacze interakcji midzy czowiekiem a komputerem uywaj poj „inicjatywa uytkownika”,
„inicjatywa systemu” i „inicjatywa mieszana” — wskazuj one, która strona utrzymuje
inicjatyw w trakcie wykonywania rónych czynnoci i decyduje o ich przebiegu. Scenariusze
przedstawione w rozdziale 4. cz obie perspektywy. Przykadowo w celu anulowania komendy
uytkownik korzysta z polecenia Anuluj, co powoduje reakcj systemu — jest to inicjatywa
uytkownika. Ju w trakcie anulowania system moe wywietli pasek postpu — jest to ju
inicjatywa systemu. Przy anulowaniu polecenia mamy wic do czynienia z inicjatyw mieszan.
Rozrónienie to przydaje si przy omawianiu taktyk, które mona zastosowa w celu realizacji
tego czy innego scenariusza.
Gdy inicjatyw podejmuje uytkownik, architekt projektuje reakcj, podobnie jak przy
kadej innej funkcji systemu. Niezbdne jest okrelenie obowizków systemu w zakresie reakcji
na polecenie. Wracajc do przykadu polecenia Anuluj: gdy uytkownik wydaje polecenie,
system musi by gotowy do jego odbioru (odpowiada za zapewnienie obserwatora, który nie
bdzie zablokowany w zwizku z wykonywaniem anulowanych operacji); anulowana operacja
musi zosta przerwana; zasoby uywane przez t operacj musz zosta zwolnione; wszystkie
komponenty, których praca wie si z anulowan operacj, musz zosta poinformowane, by
mogy podj odpowiednie w takiej sytuacji dziaania.
Gdy inicjatyw podejmuje system, podstaw s pewne informacje o uytkowniku, wykonywanym
przez uytkownika zadaniu lub stanie samego systemu. S to róne modele, z których kady
wymaga innego rodzaju danych wejciowych. Taktyki zwizane z inicjatyw systemu okrelaj
modele stosowane przez system do przewidywania albo wasnych zachowa, albo zamierze uytkownika.
Zahermetyzowanie takich informacji uatwia architektowi dopracowywanie i modyfikowanie
modeli. Dostosowanie i modyfikacja mog by dynamiczne, oparte na zachowaniach
uytkownika albo bardziej tradycyjne, wykonywane w trakcie budowy oprogramowania.
Utrzymywanie modelu zadania. Model zadania suy do ledzenia kontekstu pracy w sposób
umoliwiajcy systemowi okrelenie zamiarów uytkownika i uaktywnienie waciwych
mechanizmów pomocy. Przykadowo wiedza o tym, e zdania rozpoczyna si zazwyczaj
wielk liter, pozwala aplikacji korygowa zdania, w których uytkownik nie dostosowa si
do tej reguy.
Utrzymywanie modelu uytkownika. Model uytkownika suy do okrelania jego znajomoci
systemu, jego zachowa w kategoriach oczekiwanego czasu reakcji lub innych
charakterystyk specyficznych dla pewnej osoby czy klasy osób. Przykadem zastosowania
modelu uytkownika jest dopasowanie szybkoci przewijania do szybkoci czytania.
Utrzymywanie modelu systemu. Model systemu suy do okrelania oczekiwanego zachowania
systemu po to, by przekaza odpowiednie informacje zwrotne uytkownikowi.
Jest to na przykad oszacowanie czasu potrzebnego do skoczenia biecej operacji.
Taktyki dla czasu projektowania
Procedury testowania wi si czsto z wieloma zmianami w interfejsie uytkownika — specjalista
zajmujcy si funkcjonalnoci regularnie przekazuje programistom poprawki do bie-
cego projektu interfejsu, a ci wprowadzaj odpowiednie zmiany. W usprawnieniu tego schematu
pomaga taktyka, która jest specjalizacj opisanej wczeniej taktyki spójnoci semantycznej:

128 5. UZYSKIWANIE ATRYBUTÓW JAKOCIOWYCH
Oddzielenie interfejsu uytkownika od reszty aplikacji. Lokalizacja oczekiwanych
zmian jest gównym uzasadnieniem spójnoci semantycznej. Poniewa interfejs uytkownika
ulega czstym zmianom zarówno przed wdroeniem, jak i po nim, odseparowanie jego
kodu jest pierwszym krokiem w kierunku lokalizacji. Mona wymieni kilka wzorców
architektury, które wykorzystuj t taktyk i uatwiaj modyfikowanie interfejsu:
Model-View-Controller (model-widok-kontroler),
Presentation-Abstraction-Control (prezentacja-abstrakcja-sterowanie),
Seeheim,
Arch/Slinky.
Rysunek 5.13 przedstawia podsumowanie taktyk funkcjonalnoci dla czasu wykonywania
Rysunek 5.13. Taktyki funkcjonalnoci dla czasu wykonywania
5.8. Taktyki atrybutów jakociowych
a wzorce architektury
Przedstawilimy zbiór taktyk, których stosowanie pomaga architektowi uzyska rónego rodzaju
atrybuty jakociowe. W praktyce podejmowana decyzja konstrukcyjna to najczciej wybór
pewnego wzorca lub zbioru wzorców, które maj zapewni uycie jednej lub wikszej liczby
taktyk. Jednak kady wzorzec nieodmiennie wprowadza zbiór wielu taktyk — podanych
lub nie. Niech ilustracj bdzie analiza wzorca projektowego Active Object (aktywny obiekt),
opisanego w [Schmidt 00]:
Wzorzec Active Object usuwa cise powizanie midzy wykonywaniem metody a jej wywoaniem,
aby zwikszy wspóbieno i uproci synchronizowany dostp do obiektów
we wasnym wtku sterowania.
Wzorzec skada si z szeciu elementów: porednika, który zapewnia interfejs pozwalajcy
klientom wywoywa publicznie dostpne metody aktywnego obiektu; dania metody, które
definiuje interfejs wykonywania metod aktywnego obiektu; listy aktywacyjnej, przechowujcej
bufor oczekujcych da metod; jednostki szeregujcej decydujcej o tym, które danie
metody zostanie wykonane jako nastpne; wykonawcy definiujcego zachowania i stan, modelowane
przez aktywny obiekt; a take przyszej wartoci, która pozwala klientowi pobra
wynik wywoania metody.

5.9. WZORCE I STYLE ARCHITEKTURY 129
Celem stosowania tego wzorca jest uzyskanie wspóbienoci. Jest to cel dotyczcy wydajnoci.
Architekt stosuje wic taktyk wydajnoci „wprowadzenie wspóbienoci”. Zwrómy
jednak uwag na inne taktyki, które wprowadza wzorzec.
Ukrywanie informacji (modyfikowalno). Kady element ma pewien zakres odpowiedzialnoci,
ale ukrywa sposób dziaania.
Porednik (modyfikowalno). Porednik buforuje zmiany w sposobie wywoywania metod.
Czas wizania (modyfikowalno). Wzorzec aktywnego obiektu opiera si na zaoeniu,
e dania docieraj do obiektu w czasie wykonywania. Kwestia czasu wizania klienta
z porednikiem pozostaje otwarta.
Zasady szeregowania (wydajno). Jednostka szeregujca posuguje si pewnym zbiorem
zasad.
Kady wzorzec to poczenie taktyk, czsto powizanych z rónymi atrybutami jakociowymi,
i kada implementacja wzorca wie si z wyborami dotyczcymi tych taktyk. Przykadowo
implementacja dziennika da moe jednoczenie umoliwia przywracanie systemu, zapewnia
zapis przebiegu pracy i uatwia testowanie.
Architekt musi dobrze zna i rozumie wprowadzone w konstrukcji systemu taktyki, a jego
prac jest poszukiwanie takiego ich poczenia, które pozwoli uzyska wszystkie wymagane
cechy systemu.
5.9. Wzorce i style architektury
Wzorce architektury oprogramowania nazywa si czasem stylami architektury. Jest to trafna
analogia ze stylami architektury w budownictwie, takimi jak gotyk, secesja czy barok. Styl buduje
kilka istotnych elementów i regu czenia ich w sposób niezakócajcy spójnoci. Wzorzec
architektury jest okrelany przez:
zespó typów elementów (takich jak magazyn danych lub komponent, który oblicza funkcj
matematyczn),
topologi elementów, która wyraa zwizki midzy nimi,
zespó ogranicze semantycznych (na przykad filtry w stylu z potokami i filtrami to czyste
przetworniki danych — przeksztacaj one strumie wejciowy w strumie wyjciowy,
ale nie maj kontroli nad elementami wczeniejszymi lub póniejszymi),
zespó mechanizmów interakcji (jak wywoanie procedury, subskrypcja zdarze, tablica
podrczna), które okrelaj sposób koordynacji elementów w ramach dozwolonej topologii.
Mary Shaw i David Garlan podjli znaczc prób skatalogowania zbiorów wzorców architektury,
które nazwali stylami lub idiomami. W toku ewolucji inynierii oprogramowania
z podejcia tego wyoniy si lepiej znane dzisiaj wzorce architektury, analogiczne do wzorców
projektowych i wzorców pisania kodu.
Inspiracj dla autorów [Shaw 96] byo spostrzeenie, e istnieje wiele znanych wysokopoziomowych
abstrakcji zoonych systemów, ale nie zostay one wczeniej systematycznie zbadane
i skatalogowane, podobnie jak robi si w innych dziedzinach technicznych.
Poza bardzo regularnym wystpowaniem w projektach systemów drug charakterystyczn
cech wzorców architektury jest to, e nie s one atwo rozpoznawalne — przede wszystkim
dlatego, e róne zastosowania prowadz do rónego nazewnictwa. Odpowiedzi byo powstanie
katalogów zawierajcych opisy typowych wzorców, ich wasnoci i znaczenia dla systemu.
Przykad takiego katalogu wida na rysunku 5.14.

130 5. UZYSKIWANIE ATRYBUTÓW JAKOCIOWYCH
Rysunek 5.14. May katalog wzorców architektury uporzdkowany wedug relacji „jest…”
Widoczne na rysunku wzorce zostay sklasyfikowane w grupy tworzce pewn hierarchi
dziedziczenia. Na przykad system zdarzeniowy jest „podstylem” ogólniejszego stylu niezalenoci
elementów. Z kolei wród systemów zdarzeniowych mona wyróni dwie podkategorie:
z wywoaniem jawnym i z wywoaniem niejawnym.
Jaka jest relacja midzy wzorcami architektury a taktykami? Jak pisalimy wczeniej, traktujemy
taktyk jako podstawowy „blok konstrukcyjny” projektu, z którego budowane s wzorce
i strategie.
5.10. Podsumowanie
W tym rozdziale pokazalimy, w jaki sposób architekt osiga wymagane przez specyfikacj
atrybuty jakociowe niezbdne do realizacji celów systemu. Zajmowalimy si taktykami stosowanymi
przez architekta w celu skonstruowania waciwego projektu z uyciem rónych
wzorców i strategii architektury.
Przedstawilimy list szeroko znanych taktyk osigania szeciu atrybutów omówionych w rozdziale
4.: dostpnoci, modyfikowalnoci, wydajnoci, bezpieczestwa, testowalnoci i funkcjonalnoci.
Taktyki podane dla kadego z nich s w powszechnym uyciu i atwo zastosowa
je w praktyce.
Jak napisalimy, stosowanie wzorców architektury rozpoczyna si od wyboru podanych
taktyk. W kadym projekcie pojawia si wiele taktyk i wiedza o tym, na które atrybuty wpywaj
one pozytywnie, jakie s ich skutki uboczne oraz czym grozi rezygnacja z innych, ma kluczowe
znaczenie w pracy kadego architekta.

5.11. PYTANIA DO DYSKUSJI 131
5.11. Pytania do dyskusji
(1) Zastanów si nad popularn witryn WWW, tak jak na przykad Amazon lub eBay. Podobnie
jak przy pytaniu 3. w rozdziale 4. utwórz kilka scenariuszy atrybutów jakociowych.
Jakie taktyki powiniene rozway przy wybieraniu wzorców i strategii architektury,
aby uatwi spenienie zidentyfikowanych wymaga?
(2) Dla zbioru taktyk utworzonego w odpowiedzi na pytanie 1.: jakich kompromisów z innymi
atrybutami jakociowymi (na przykad bezpieczestwem, dostpnoci lub modyfikowalnoci)
moesz oczekiwa po zastosowaniu tych taktyk?
(3) Funkcjonalnoci nie powica si czsto wystarczajcej uwagi przy projektowaniu architektury.
Takie traktowanie utrudnia osignicie istotnych celów jakociowych. Zastanów
si nad systemem, którego architektur dobrze znasz, i spróbuj wyliczy zastosowane
w nim taktyki funkcjonalnoci.
5.12. Literatura
Wicej informacji o zabezpieczeniach systemu mona znale w [Ramachandran 02]. Zwizki
midzy funkcjonalnoci a wzorcami architektury oprogramowania s omawiane w [Bass 01a].
O technikach dostpnoci systemów rozproszonych traktuje [Jalote 94]. Z kolei [McGregor 01]
jest dobrym ródem informacji o zagadnieniach zwizanych z testowalnoci.
Dwuczciowy katalog wzorców architektury, [Buschmann 96] i [Schmidt 00], zawiera omówienie
wzorców MVC i PAC (tom 1.) i koncepcji architektury opartej na wzorcach (tom 2.).
Opis wspomagajcej uzyskiwanie wysokiej dostpnoci architektury Simplex mona znale na
stronie http://www.sei.cmu.edu/simplex/.
W [Bachmann 02] omówienie stosowania taktyk jest podstaw do analizy modyfikowalnoci
i wydajnoci, [Chretienne 95] zawiera opisy mechanizmów szeregowania, a w [Briand 99] mona
znale opis miar siy powiza moduów.
Pen dokumentacj wzorca Model-View-Controller mona znale w [Gamma 95], wzorca
Presentation-Abstraction-Control — w [Buschmann 96], wzorca Seeheim — w [Pfaff 85],
a Arch/Slinky — w [UIMS 92].

Skorowidz
A
ABC, Patrz cykl biznesowy architektury
Active Object, 128
adaptation data, Patrz dane adaptacji
ADD, Patrz metoda Projektowania wedug Atrybutów
algorytm
komponentu preferowanego, 110
rzdów wikszoci, 110
allocation structure, Patrz struktura alokacji
analiza wymaga, Patrz wymagania analiza
analizator
abstrakcyjnego drzewa skadniowego, 227
leksykalny, 227
aplikacja, 183, 335, 401
application, Patrz aplikacja
architectural
mismatch, Patrz architektura oprogramowania
niedopasowanie
pattern, Patrz architektura oprogramowania
wzorzec
strategy, Patrz architektura oprogramowania
strategia
Architecture Business Cycle, Patrz cykl biznesowy
architektury
architecture reconstruction, Patrz
architektura oprogramowania rekonstrukcja
Architecture Tradeoff Analysis Method, Patrz
metoda Analizy Kompromisów w Architekturze
architekt, 25, 26, 29, 32, 34, 42, 50, 56, 101, 198,
223, 415, 437, 439
architektura
J2EE, Patrz J2EE
systemowa, 49
architektura oprogramowania, 23, 25, 26, 29, 30,
34, 37, 38, 40, 45, 46, 47, 49, 57, 59, 61, 83, 84,
155, 169, 197, 357, 435
analiza, 33, 248
czynniki ksztatujce, 156, 158, 159
diagram kontekstu, 203
dokumentacja, 39, 149, 167, 198, 202, 208,
210, 438
implementacja, 45
implementacja przyrostowa, 34
instrukcja rónicowania, 203
katalog elementów, 203
linia produktów, 331
ocena, 333
Luther, 389, 390, 391, 396, 400, 401, 402, 403,
409, 410
miary, 250
niedopasowanie, 49, 416
obiektowa, 435
ocena, 247, 250, 251, 252
metody, 250, 252
perspektywa, Patrz perspektywa
prezentacja, 32
projektowanie, 157, 438
przegldy, 29
referencyjna, 42, 66
rekonstrukcja, 39, 199, 223, 225, 228, 233, 237
baza danych, 228, 229, 237
ekstrakcja informacji, 226, 237
identyfikacja wzorców, 232
interakcje, 232
konflikt nazw, 231
metoda warsztatowa, 224, 229
narzdzia, 224, 227
scalanie informacji, 230, 231, 238
wizualizacja, 232, 234, 235

456 SKOROWIDZ
architektura oprogramowania
reprezentacja, 39, 51
schemat gówny, 203
sownik terminów, 204
strategia, 108, 287, 288, 291, 295, 298
struktura, 169, Patrz struktura
styl, Patrz architektura oprogramowania
wzorzec
tworzenie, 32, 33, 51
uzasadnienie, 204
warstwowa, 74
weryfikacja, Patrz architektura
oprogramowania ocena
wzorzec, 41, 42, 49, 108, 128, 129, 130, 157,
159, 183, 232, 420, 438
zgodno, 33
znaczenie, 43
artefakt, Patrz atrybuty jakociowe artefakt
AST, Patrz analizator abstrakcyjnego drzewa
skadniowego
atak, 122
obrona, 122
przywracanie systemu, 124
wykrywanie, 123
ATAM, Patrz metoda Analizy Kompromisów
w Architekturze
atrybuty jakociowe, 32, 34, 42, 46, 58, 64, 67, 81,
83, 85, 128, 147, 199, 274, 275, 284, 285, 295, 299,
369, 370, 375, 383, 390, 393, 421, 425, 437
artefakt, 86, 87, 90, 92, 94, 96, 98, 101
bezpieczestwo, 81, 85, 95, 122, 284, 313, 315
biznesowe, 103
bodziec, 86, 90, 92, 94, 96, 98, 100
czas projektowania, 127
dostpno, 81, 89, 90, 109, 124, 136, 138, 284,
313, 316, 317
funkcjonalno, 81, 84, 85, 99, 100, 102, 104,
126, 284
integrowalno, 194
kompletno, 105
atwo testowania, 81
atwo wprowadzania zmian, Patrz atrybuty
jakociowe modyfikowalno
miara reakcji, 86, 87, 91, 92, 94, 97, 99, 101
modyfikowalno, 61, 68, 81, 85, 88, 91, 112,
149, 160, 194, 195, 284, 313, 315, 317
niezawodno, 85
poprawno, 105
przenono, 103
reakcja, 86, 87, 91, 92, 94, 96, 98, 101, 118
scenariusz, 86, 88, 89, 90, 92, 94, 96, 98, 100,
101, 157, 158, 165, 166
skalowalno, 103, 313, 316, 317, 395
spójno koncepcyjna, 104
rodowisko, 86, 87, 90, 92, 94, 96, 98, 101, 135, 177
taktyka, 107, 109, 110, 112, 113, 115, 118, 119,
122, 124, 126, 130, 149, 157, 159, 437, 438
testowalno, 97, 124
wydajno, 81, 85, 93, 95, 104, 118, 136, 160,
178, 194, 284, 313, 315, 316, 317
wykonalno, 105
ródo bodca, 86, 87, 90, 92, 94, 96, 98, 100
Attribute Driven Design, Patrz metoda
Projektowania wedug Atrybutów
availability, Patrz atrybuty jakociowe dostpno
awaria, 90, 109, 110, 143, 148
B
bezpieczestwo, Patrz atrybuty jakociowe
bezpieczestwo
biblioteka WWW, Patrz libWWW
bd, Patrz obsuga bdów
Bohr Niels, 435, 436
bridge, Patrz most
Brooks Fred, 57, 168, 441
C
CBAM, Patrz metoda Analizy Kosztów i Korzyci
cele biznesowe, 156, 414
CGI, 311
choroba symulatorowa, 179
ciepy restart, Patrz redundancja pasywna
collaboration, Patrz system wspódziaajce zespoy
COM, 317
Common Object Request Broker Architecture,
Patrz CORBA
component-and-connector structure, Patrz
struktura komponenty-zcza
CORBA, 317, 367, 368, 418
Cost Benefit Analysis Method, Patrz metoda
Analizy Kosztów i Korzyci
cross-side scripting, 431
cykl
ycia oprogramowania, 438
biznesowy architektury, 25, 26, 30, 31, 35, 62,
135, 176, 247, 301, 313, 318, 339, 368, 411,
436, 437
czas reakcji, 26
D
Dali, 225, 229, 232, 237
dane
adaptacji, 148, 149
trwae, 53
wspóuytkowane, 53, 54
dekompozycja, 52, 84, 113, 149, 157, 159, 166, 190,
191, 192

SKOROWIDZ 457
deskryptor wdroenia, 381, 383
diagram, Patrz schemat
Dijkstra Edsger, 58, 59, 141
dostpno, Patrz atrybuty jakociowe dostpno
E
efekt domina, 112, 113, 114, 115, 160
EJB, 367, 371, 373
F
filtr, 123, 129, 215, 217, 219, 240, 316
framework, Patrz platforma
FTP, 309
funkcja, 83, 84
funkcjonalno, Patrz atrybuty jakociowe
funkcjonalno
G
Garlan David, 49, 129
Glass Bob, 77
gorcy restart, Patrz redundancja aktywna
grupa
docelowa, 32, 198
interesu, 26, 28, 34, 35, 43, 101, 135, 198, 199,
201, 202, 255, 285, 339, 437
H
hermetyzowanie informacji, Patrz ukrywanie
informacji
Hybertsson Henryk, 24
I
IDE, 317
idiom, Patrz architektura oprogramowania wzorzec
implementacja, 84, 189
ograniczenia, 422, 427
instrumentacja kodu, 227
integrated development environment, Patrz IDE
interface, Patrz interfejs
interface mismatch, Patrz interfejs niedopasowanie
interfejs, 205, 377, 378, 394, 416
API, 397, 401, 402
komponentów, 215
negocjowany, 421
niedopasowanie, 416, 417, 419, 420
parametryzowany, 421
publiczny, 68
semantyka, 206
skadnia, 206
szablon opisu, 206
uytkownika, 393, 396, 397, 399, 400, 401, 415
wariantowo, 208
interoperacyjno, 436
intrusion detection system, Patrz system
wykrywania wama
inynieria odwrotna, 223
Iverson Ken, 57
J2EE, 317, 367, 368, 371, 375, 388, 396, 403, 409, 411
J2EE/EJB, 367, 383, 388
jarzmo testów, 98, 125
Java, 368
Java 2 Enterprise Edition, Patrz J2EE
Jzyk UML, Patrz UML
J
K
kernel, 85, 145
klasa, 53, 215, 217, 403
kod
adaptacyjny, 421
korygujcy, 417, 418
kompletno, Patrz atrybuty jakociowe
kompletno
komponent, 51, 53, 55, 58, 110, 111, 118, 204, 215,
401, 402, 416
aktualizacja, 111
bezstanowy sesyjny, 374, 383, 384, 387, 408
EJB, 373, 377, 379, 381, 384, 387, 403
encyjny, 374, 375, 380, 384, 385, 386, 387, 407,
408
funkcji ogólnych, 402
komercyjny, 439
kompatybilno, 416
kwalifikacja, 419
pakiet, 403
podstawowy, 402
selekcja, 413
specyficzny dla dziedziny, 402
stanowy sesyjny, 374, 383, 384, 387
z funkcjami wielokrotnego uytku, 404
zarzdzania organizacj pracy, 402, 404
zastpczy, 170
komputer ubraniowy, 390
konflikt, 34
Kruchten Philippe, 56
latencja, 119
libWWW, 307, 309
L

458 SKOROWIDZ
linia oprogramowania, 325, 326, 328, 344
ewolucja, 335
narzdzia, 329
ocena, 333
trudnoci, 334
wdraanie, 334
zakres, 328
zrónicowanie, 331
linia produktów, 48, 59, 339, 341, 437
lokalizowanie modyfikacji, 112, 113, 160
M
mapowanie, 54, 76, 144, 185, 189, 211, 218, 225,
234, 255, 431, 439
mechanizm wywoa niejawnych, 28
mediator, 417, 418, 421
meneder
dostpu, 310
interfejsu uytkownika, 310
pamici, 310
protokoów, 310
strumieni, 310, 311
metoda, 420
Analizy Kompromisów w Architekturze, 33,
47, 156, 199, 252, 253, 255, 267, 281, 283,
284, 285, 298
faza analizy, 257
faza procesu, 256, 268, 269
Analizy Kosztów i Korzyci, 252, 283, 285,
291, 298, 333, 437
fazy, 289, 292
podstawy, 285
ATAM, Patrz metoda Analizy Kompromisów
w Architekturze
CBAM, Patrz metoda Analizy Kosztów
i Korzyci
oceniania architektury przed rozpoczciem
budowy, 25
oparta na pomiarach, 250
oparta na pytaniach, 250
parametryzacji, 421
Projektowania wedug Atrybutów, 157, 158, 199
przyrostowej budowy oprogramowania, 25
Rational Unified Process, 157
Simplex, 110
warsztatowa, Patrz architektura
oprogramowania rekonstrukcja metoda
warsztatowa
miara ilociowa, 34
miara reakcji, Patrz atrybuty jakociowe miara reakcji
middleware, 91, 113, 157, 170, 436
model
jednowtkowy, 309
programowania, 317
referencyjny, 42, 180
strukturalny, 175, 177, 180, 183, 186
modifiability, Patrz atrybuty jakociowe
modyfikowalno
module structure, Patrz struktura moduów
modu, 34, 51, 52, 113, 168, 212 Patrz te procedura
brokera danych, 70
decyzji, 69
dekompozycja, 67, 68, 158, 159
filtrów, 70
generowania systemu, 71
generujcy dane, 34, 37
interfejs, 34, 71, 164
kopia, 164
modeli fizycznych, 70
narzdziowy, 71
obsugi funkcji, 71
opis, 68
pobierajcy dane, 34
rozszerzajcy, 308
sekret, Patrz sekret
typu danych aplikacji, 70
ukrywania warstwy sprztowej, 69
ukrywania zachowa, 69
uogólnienie, 114
zalenoci, 114
modyfikowalno, Patrz atrybuty jakociowe
modyfikowalno
most, 417, 418
N
NET, 317, 367
niedopasowanie architekturalne, Patrz architektura
oprogramowania niedopasowanie
O
obiekty rozproszone, 28
obsuga bdów, 58, 72, 148
odwoywanie, 111
opónienie czasu wizania, 113, 117
oprogramowanie
samokonfigurujce si, 421
wytwarzanie, 31
organizacja, 25, 392
cele, 25, 30
struktura, 27, 29, 46, 167, 169, 336, 348, 392
osona, 417, 418, 421
osoby zainteresowane, Patrz grupa interesu
P
parametryzacja, 421
Parnas David, 58, 65, 416, 441
parser, 227, 308

SKOROWIDZ 459
perspektywa, 51, 55, 162, 200, 201, 203, 229, 439
alokacji, 56, 201, 220
budowy oprogramowania, 56
dekompozycji, 140, 149, 162, 164, 201, 206,
310, 359
dynamiczna, 34
fizyczna, 56
implementacji, 201
katalog, 210
klient-serwer, 143, 149, 201
kodu, 56, 144
komponenty-zcza, 56, 162, 201, 202, 206, 215
koncepcyjna, 56
logiczna, 56
mapowanie, 210
moduów, 56, 164, 201, 212
odpornoci na bdy, 149
odporno na uszkodzenia, 147
powiza moduów, 56
procesów, 55, 56, 141, 149, 202, 357
relacje, 149
rozmieszczenia, 55, 162, 163, 164, 201
statyczna, 34
szablon, 210
uycia, 201, 202, 206
warstwowa, 145, 201, 202, 359
wspóbienoci, 162, 164
wykonawcza, 56
PICS, 306
Platform for Internet Content Selection, Patrz PICS
platforma, 48, 50, 69, 73, 91, 103, 104, 110, 111,
113, 171, 175, 180, 195, 241, 303, 304, 308, 309,
323, 353, 355, 357, 359, 368, 370, 435
poprawno, Patrz atrybuty jakociowe poprawno
port, Patrz interfejs komponentów
porednik, 116, 128
potok, 41, 129, 215, 219
powielanie, 111
praca w czasie rzeczywistym, 26, 177, 179
problem modelowy, 422, 427
procedura, Patrz te modu
dostpowa, 68
interfejsów urzdze, 75
modeli fizycznych, 75
obsugi bdów, Patrz obsuga bdów
usug wspólnych, 75
proces, 35, 53, 75, 141
inicjowany na danie, 76
okresowy, 75
profilowanie, 227
projektowanie obiektowe, 58, 68
protokó
HTTP, 307, 309, 315, 316, 396, 398
HTTPS, 305, 309, 315, 316
NNTP, 309
SSL, 315
Usenet, 309
WAP, 399
prototyp, 47
budowa iteracyjna, 29
przenono, Patrz atrybuty jakociowe
przenono
przetwarzanie
rozproszone, 386, 395
równolege, 34
przewidywanie zmian, 113
przybornik, Patrz warsztat
przywracanie stanu systemu, 110
punkt kontrolny, 111
Q
quality attribute scenario, Patrz atrybuty
jakociowe scenariusz
quality attribute tactics, Patrz atrybuty jakociowe
taktyka
R
Rational Unified Process, 56
reakcja, Patrz atrybuty jakociowe reakcja
redundancja, 148, 150
aktywna, 110, 111
pasywna, 111
podwójna, Patrz redundancja pasywna
sprztowa, 284
reference model, Patrz model referencyjny
rekonstrukcja, Patrz architektura oprogramowania
rekonstrukcja
relacja
ma prawo uywa, 73
uywa, 71, 72
wywouje, 71
repozytorium, 53, 119, 232, 258, 331, 355, 357,
363, 408
resynchronizacja stanu, 111
return on investment, Patrz zwrot z inwestycji
reverse engineering, Patrz inynieria odwrotna
Rigi, 232
ROI, Patrz zwrot z inwestycji
rola, 177, 180
rollback, Patrz odwoywanie
rozwizanie modelowe, 422, 427, 428, 429
scenariusz, 81, 156, 255, 256, 260, 261, 262, 264,
266, 273, 274, 276, 278, 279, 285, 286, 290, 291,
293, 294, 408, 437
schemat
karuzelowy, 316
macierzowy, 191
sekwencji, 204
stanów, 204
S

460 SKOROWIDZ
sekret, 67, 69, 70, 71
sequence diagram, Patrz schemat sekwencji
serwlet, 372, 379, 393, 400, 403, 409, 429, 431
shadow operation, Patrz powielanie
Shaw Mary, 129
signature, Patrz sygnatura
skalowalno, Patrz atrybuty jakociowe
skalowalno
skalowanie
pionowe, 386
poziome, 386
skrypt CGI, Patrz CGI
software product line, Patrz linia oprogramowania
specyfikacja wymaga, 26, 66
spójno
koncepcyjna, Patrz atrybuty jakociowe
spójno koncepcyjna
semantyczna, 113, 127, 141, 160
stakeholders, Patrz grupa interesu
statechart, Patrz schemat stanów
sterta, 387
strona shadow, 111
Structural Model, Patrz model strukturalny
struktura, 51, 54, 61, 201
alokacji, 51, 53
dekompozycji, 52, 54, 55, 61, 67, 68, 69
dominujc, 55
implementacja, 54
klasy, 53, 54
klient-serwer, 53, 54
komponenty-zcza, 51, 53, 55
moduów, 51, 52
podzia pracy, 54
proces, 53, 54
procesów, 61, 67, 75, 77
rozmieszczenie, 53
uycia, 52, 54, 61, 66, 67, 71, 73, 74
warstwowa, 58
wspóbieno, 53, 54
stub, 170
styl, Patrz architektura oprogramowania wzorzec
styl architektury, Patrz architektura
oprogramowania wzorzec
sygnatura, 206
system
czasu rzeczywistego, 170
klient-serwer, 170
podsystem UML, 218
reguowy, 170
szkieletowy, 34, 170, 189
wieloprocesowy, 170
wspódziaajce zespoy, 219
wykrywania wama, 123
zamknity obiekt, 218
szablon, 50
S
cieka komunikacji, 34
rodowisko, Patrz atrybuty jakociowe rodowisko
techniczne, 24, 25, 28, 29, 31
T
tajemnica, Patrz sekret
taktyka, Patrz atrybuty jakociowe taktyka
TELNET, 309
test harness, Patrz jarzmo testów
testability, Patrz atrybuty jakociowe testowalno
testowalno, Patrz atrybuty jakociowe
testowalno
transakcja, 403, 404, 409
transakcje rozproszone, Patrz przetwarzanie
rozproszone
tworzenie abstrakcji wspólnych usug, 113
U
ukrywanie
informacji, 54, 58, 62, 65, 66, 67, 68, 69, 78, 115,
160, 168
warstwy sprztowej, 69
zachowa, 69
UML, 211, 212, 214, 215, 217, 220
Unified Modeling Language, Patrz UML
urzdzenie przenone, 394, 398
usability, Patrz atrybuty jakociowe
funkcjonalno
usugi wspólne, 113
uszkodzenie, 90, 109, 148
wykrywanie, 109
zapobieganie, 112
utility, Patrz warto uytkowa
uzasadnienie biznesowe systemu, 32
uyteczno, Patrz warto uytkowa
V
Vasa, 24
virtual threads, Patrz wtek wirtualny
W
warstwa, 74, 145, 168, 310, 314, 402
globalnych systemów informacyjnych, 373
internetowa, 372
klienta, 371
komponentów biznesowych, 373
warsztat, 224
warto uytkowa, 285, 286, 287, 288, 291, 294, 296

SKOROWIDZ 461
wtek, 40, 53, 387, 439
fizyczny, 53
logiczny, 53
pseudowtek, 309
wirtualny, 162
wze, 220, 356
wizanie, 117
workbench, Patrz warsztat
wrapper, Patrz osona
wspóbieno, 204, 431
wydajno, Patrz atrybuty jakociowe wydajno
wykonalno, Patrz atrybuty jakociowe
wykonalno
wymagania, 23, 25, 26, 28, 30, 362, 368, 375, 393,
410, 425, 437
analiza, 32, 157
jakociowe, 158
specyfikacja, 25, 26, 32
techniki gromadzenia, 32
wzorzec, 232
interakcji, 35
model strukturalny, Patrz model strukturalny
wzorzec architektury, Patrz architektura
oprogramowania wzorzec
Z
zachowanie, 204
zaoenie, 420
lista, 420
wymaga, 416, 419, 420, 421
zapewnia, 416, 419, 420, 421
zapas, 111
zapora, 315
zarzdzanie czasem, 181, 183
zasoby, 162, 404, 420
blokada, 118
ograniczanie zapotrzebowania, 119, 120
poziom wykorzystania, 118, 416
priorytet dostpu, 120
pula, 387
zarzdzanie, 120
zespó sektora, 137
zintegrowane rodowisko programowania, Patrz IDE
zcze, 51, 53
zunifikowany jzyk modelowania, Patrz UML
zwrot z inwestycji, 285, 288, 296, 298, 325
ródo bodca, Patrz atrybuty jakociowe ródo
bodca
Z