Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00360 005930 14492208 na godz. na dobę w sumie
Architektura oprogramowania w praktyce. Wydanie II - książka
Architektura oprogramowania w praktyce. Wydanie II - książka
Autor: , , Liczba stron: 464
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-3302-9 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> techniki programowania
Porównaj ceny (książka, ebook, audiobook).

Twórz doskonałe projekty architektoniczne oprogramowania!

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.

Poznaj najlepsze metodologie projektowania architektury!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

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! 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 Spis treĂci Przedmowa ................................................................................................................9 PodziÚkowania ........................................................................................................13 WstÚp .......................................................................................................................15 I. Wizja architektury .............................................................................. 21 1. Cykl biznesowy architektury ................................................................................23 1.1. SkÈd 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 waĝna? ................................................................................................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. Poïoĝenie w cyklu biznesowym architektury .....................................................................................62 3.2. Wymagania i atrybuty jakoĂciowe .......................................................................................................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 TRE¥CI II. Tworzenie architektury ................................................................... 81 4. Atrybuty jakoĂciowe ..............................................................................................83 4.1. Architektura a funkcje systemu ...........................................................................................................84 4.2. Architektura a atrybuty jakoĂciowe .....................................................................................................84 4.3. Atrybuty jakoĂciowe systemu ..............................................................................................................85 4.4. Scenariusze atrybutów jakoĂciowych w praktyce ..............................................................................89 4.5. Inne atrybuty jakoĂciowe systemu .....................................................................................................103 4.6. Biznesowe atrybuty jakoĂciowe .........................................................................................................103 4.7. Atrybuty jakoĂciowe architektury .....................................................................................................104 4.8. Podsumowanie .....................................................................................................................................105 4.9. Literatura .............................................................................................................................................105 4.10. Pytania do dyskusji ...........................................................................................................................106 5. Uzyskiwanie atrybutów jakoĂciowych ..............................................................107 5.1. Taktyki atrybutów jakoĂciowych .......................................................................................................107 5.2. Taktyki dostÚpnoĂci ............................................................................................................................109 5.3. Taktyki modyfikowalnoĂci ................................................................................................................112 5.4. Taktyki wydajnoĂci .............................................................................................................................118 5.5. Taktyki bezpieczeñstwa ......................................................................................................................122 5.6. Taktyki testowalnoĂci .........................................................................................................................124 5.7. Taktyki funkcjonalnoĂci ....................................................................................................................126 5.8. Taktyki atrybutów jakoĂciowych 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 kÈtem wysokiej dostÚpnoĂci ........................................133 6.1. PowiÈzania w cyklu biznesowym architektury ................................................................................135 6.2. Wymagania i atrybuty jakoĂciowe .....................................................................................................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. Ksztaïtowanie 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. PowiÈzania w cyklu biznesowym architektury ................................................................................176 8.2. Wymagania funkcjonalne i jakoĂciowe .............................................................................................177 8.3. Architektura ........................................................................................................................................180 SPIS TRE¥CI 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 jÚzyk 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. Przykïad .............................................................................................................................................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. Materiaïy wyjĂciowe 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 — iloĂciowe podejĂcie 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óïdziaïanie w World Wide Web — studium przypadku ..........................301 13.1. PowiÈzania z cyklem biznesowym architektury ............................................................................301 13.2. Wymagania funkcjonalne i atrybuty jakoĂciowe ...........................................................................303 13.3. Architektura ......................................................................................................................................307 13.4. Nowy cykl ABC — ewolucja architektur handlu elektronicznego w WWW .............................313 6 SPIS TRE¥CI 13.5. Wymagania jakoĂciowe .....................................................................................................................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 uĝycie elementów architektury .................325 14.1. Wprowadzenie ...................................................................................................................................325 14.2. Co sprawia, ĝe linia oprogramowania jest udana? .........................................................................326 14.3. OkreĂlanie 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. ZwiÈzki z cyklem ABC .....................................................................................................................339 15.2. Wymagania i atrybuty jakoĂciowe ...................................................................................................355 15.3. RozwiÈzanie architektoniczne .........................................................................................................357 15.4. Podsumowanie ...................................................................................................................................364 15.5. Literatura ...........................................................................................................................................365 15.6. Pytania do dyskusji ...........................................................................................................................365 16. J2EE/EJB. Studium przypadku — standardowa dla branĝy infrastruktura obliczeniowa ................................367 16.1. ZwiÈzki z cyklem biznesowym architektury ..................................................................................368 16.2. Wymagania i atrybuty jakoĂciowe ...................................................................................................368 16.3. RozwiÈzanie architektoniczne .........................................................................................................371 16.4. Decyzje zwiÈzane z wdraĝaniem systemu .......................................................................................383 16.5. Podsumowanie ...................................................................................................................................388 16.6. Literatura ...........................................................................................................................................388 16.7. Pytania do dyskusji ...........................................................................................................................388 17. Architektura Luther. Studium przypadku — aplikacje przenoĂne oparte na J2EE .............................................................389 17.1. ZwiÈzki z cyklem ABC .....................................................................................................................390 17.2. Wymagania i atrybuty jakoĂciowe ...................................................................................................393 17.3. RozwiÈzanie architektoniczne .........................................................................................................396 17.4. Jak w architekturze Luther zrealizowano cele z obszaru jakoĂci? ...............................................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. Wpïyw komponentów na architekturÚ ...........................................................................................415 18.2. Niedopasowanie architektury ..........................................................................................................416 18.3. Budowa z gotowych komponentów jako proces poszukiwañ .......................................................421 SPIS TRE¥CI 7 18.4. Przykïad — system ASEILM ..........................................................................................................424 18.5. Podsumowanie ...................................................................................................................................433 18.6. Literatura ...........................................................................................................................................433 19. PrzyszïoĂÊ architektury oprogramowania .........................................................435 19.1. Cykl biznesowy architektury ...........................................................................................................436 19.2. Budowa architektury ........................................................................................................................437 19.3. Architektura w cyklu ĝycia oprogramowania .................................................................................438 19.4. Wpïyw komponentów komercyjnych .............................................................................................439 19.5. Podsumowanie ...................................................................................................................................441 Skróty .....................................................................................................................443 Bibliografia ............................................................................................................449 Skorowidz ..............................................................................................................455 5 Uzyskiwanie atrybutów jakoĂciowych Felix Bachmann, Mark Klein i Bill Wood1 W pewnym stÚĝeniu kaĝda dobra jakoĂÊ staje siÚ szkodliwa. — Ralph Waldo Emerson W rozdziale 4. omówiliĂmy róĝne atrybuty jakoĂciowe systemu. Naszym podstawowym narzÚ- dziem byïy scenariusze. Dokïadne zrozumienie znaczenia kaĝdego z atrybutów pozwala for- muïowaÊ praktyczne wymagania jakoĂciowe. WciÈĝ nie jest to jednak rozwiÈzaniem problemu tego, jak zapewniÊ, by system faktycznie posiadaï tÚ czy innÈ cechÚ. Temu wïaĂnie poĂwiÚcony jest niniejszy rozdziaï. Dla kaĝdego z szeĂciu atrybutów jakoĂciowych opisywanych w rozdziale 4. przedstawimy praktyczne wskazówki, które mogÈ byÊ istotnÈ pomocÈ w odpowiednim kon- struowaniu architektury. Nie próbujemy przy tym odnieĂÊ siÚ do wszystkich moĝliwych cech systemu. Warto zwróciÊ uwagÚ, ĝe analogiczne porady dotyczÈce zapewniania ïatwoĂci integra- cji zostanÈ przedstawione w rozdziale 8. W tym rozdziale interesuje nas to, w jaki sposób architekt zapewnia uzyskanie róĝnych cech jakoĂciowych. Wymagania jakoĂciowe opisujÈ reakcje oprogramowania niezbÚdne do re- alizacji celów biznesowych. W centrum naszego zainteresowania sÈ techniki, z których moĝe skorzystaÊ architekt, by utworzyÊ odpowiedni projekt, stosujÈc pewne wzorce konstrukcyjne, wzorce architektury i strategie architektury — bÚdziemy nazywaÊ je taktykami atrybutów ja- koĂciowych. Przykïadowo celem biznesowym moĝe byÊ przygotowanie linii produktów. ¥rod- kiem do osiÈgniÚcia tego celu jest zapewnienie wymiennoĂci pewnych klas funkcji. Przed podjÚciem decyzji o zastosowaniu pewnego systemu wzorców architekt powinien rozwaĝyÊ poĝÈdane taktyki modyfikowalnoĂci. StajÈ siÚ one podstawÈ podejmowanych wybo- rów. Wzorzec lub strategia architektury to zbiór pewnych taktyk. Temat tego rozdziaïu to po- wiÈzania miÚdzy wymaganiami jakoĂciowymi (opisanymi w rozdziale 4.) a decyzjami dotyczÈ- cymi architektury. 5.1. Taktyki atrybutów jakoĂciowych Co daje projektowi przenoĂnoĂÊ, duĝÈ wydajnoĂÊ czy ïatwoĂÊ integracji? Kaĝda z tych cech ma swoje ěródïo w kluczowych decyzjach konstrukcyjnych. W tym rozdziale przyjrzymy siÚ do- kïadniej tym decyzjom. BÚdziemy operowaÊ pojÚciem taktyk atrybutów jakoĂciowych (ang. 1 Pracownicy Instytutu Inĝynierii Oprogramowania Carnegie Mellon University. 108 5. UZYSKIWANIE ATRYBUTÓW JAKO¥CIOWYCH quality attribute tactics). Taktyka pewnej cechy to pewien wybór o znaczÈcym wpïywie na kontrolÚ uzyskiwanÈ nad danym atrybutem. Zbiór taktyk nazywamy strategiÈ architektury (ang. archi- tectural strategy). Zajmiemy siÚ nimi w rozdziale 12. Z kolei wzorzec architektury (ang. archi- tectural pattern) to poïÈczenie taktyk w sposób, który opiszemy dokïadniej w podrozdziale 5.8. Projekt systemu to zbiór decyzji konstrukcyjnych. Niektóre z nich pozwalajÈ uzyskaÊ wpïyw na poziom, w jakim system uzyskuje pewne atrybuty jakoĂciowe. Inne prowadzÈ do uzyskania funkcji systemu. W tym rozdziale sprowadzamy decyzje dotyczÈce atrybutów jako- Ăciowych do pojÚcia 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 dziaïañ znanych z praktyki. Rysunek 5.1. Taktyki wyznaczajÈ kontrolÚ nad reakcjÈ na bodziec Kaĝda taktyka jest dla architekta pewnÈ moĝliwoĂciÈ. Przykïadowo jedna z taktyk wiÈĝe siÚ z wprowadzeniem redundancji w celu zwiÚkszenia dostÚpnoĂci systemu. Jest to jedna z moĝli- woĂci zwiÚkszenia dostÚpnoĂci, ale w ĝadnym wypadku jedyna. ZwiÚkszanie dostÚpnoĂci drogÈ redundancji wiÈĝe siÚ zazwyczaj z koniecznoĂciÈ wprowadzenia mechanizmów synchronizacji (by kopia nadawaïa siÚ do uĝytku w przypadku zakïócenia dostÚpnoĂci oryginaïu). W tym pro- stym przykïadzie widaÊ dwie podstawowe zaleĝnoĂci: 1. Taktyka ogólniejsza podlega specjalizacji. ZidentyfikowaliĂmy ogólnÈ taktykÚ redun- dancji. Moĝna jednak mówiÊ o nadmiarowoĂci danych (w bazie) lub nadmiarowoĂci obliczeñ (w osadzonym systemie sterowania). Kaĝde z tych podejĂÊ jest pewnÈ taktykÈ. Kaĝde z nich moĝna uĂciĂlaÊ dalej, definiujÈc precyzyjniej okreĂlone taktyki. Dla kaĝdego atrybutu jako- Ăciowego moĝna wskazaÊ pewnÈ hierarchiÚ taktyk. 2. Wzorce to praktyczne zbiory taktyk. SiÚgniÚcie po wzorzec zapewniajÈcy dostÚpnoĂÊ bÚdzie prawdopodobnie równoznaczne z poïÈczeniem zastosowania taktyki redundancji i taktyki syn- chronizacji. Co wiÚcej, we wzorcu pojawiÈ siÚ zapewne jeszcze precyzyjniej okreĂlone wersje tych taktyk. Na koñcu tego rozdziaïu przedstawimy przykïadowy opis wzorca projektowego w kate- goriach taktyk. Opis taktyk porzÈdkujemy jako hierarchie powiÈzane z kolejnymi atrybutami jakoĂciowymi. Naleĝy pamiÚtaÊ, ĝe ĝadna z tych hierarchii nie jest kompletna. MoĝliwoĂÊ stworzenia nowych taktyk istnieje zawsze, moĝna wiÚc jedynie mówiÊ o pewnych przykïadach. Dla kaĝdego z szeĂciu atrybutów opisanych w rozdziale 4. (dostÚpnoĂÊ, modyfikowalnoĂÊ, wydajnoĂÊ, bezpieczeñstwo, te- stowalnoĂÊ i funkcjonalnoĂÊ) przedstawiamy zbiór typowych rozwiÈzañ. Dla kaĝdego propo- nujemy pewnÈ hierarchiÚ taktyk, która — w poïÈczeniu z krótkim omówieniem zagadnienia — powinna byÊ dla architekta znaczÈcÈ pomocÈ w poszukiwaniu wïasnej Ăcieĝki. 5.2. TAKTYKI DOST}PNO¥CI 109 5.2. Taktyki dostÚpnoĂci Przypomnijmy sïownictwo zwiÈzane z dostÚpnoĂciÈ, którym operowaliĂmy w rozdziale 4. Awa- ria nastÚpuje wtedy, gdy system przestaje zapewniaÊ usïugÚ wynikajÈcÈ z jego specyfikacji; jest to widoczne dla uĝytkowników. AwariÚ moĝe spowodowaÊ uszkodzenie (lub pewne poïÈczenie uszkodzeñ). Waĝnym aspektem dostÚpnoĂci 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 umoĝliwiÊ naprawÚ. Ilu- struje to rysunek 5.2. Rysunek 5.2. Cel taktyk dostÚpnoĂci Wiele omawianych taktyk zapewnianych jest przez standardowe Ărodowiska wykonawcze, takie jak system operacyjny, serwer aplikacji lub system zarzÈdzania bazami danych. Nie umniejsza to znaczenia dobrego zrozumienia stosowanej taktyki, poniewaĝ efekty kaĝdej z nich majÈ istotne znaczenie przy projektowaniu i ocenie projektu. Kaĝda technika zwiÈzana z dostÚpnoĂciÈ wiÈĝe 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ñ zwiÈzanych z trzema podstawowymi skïadnikami do- stÚpnoĂci: wykrywaniem uszkodzeñ, przywracaniem stanu i zapobieganiem uszkodzeniom. Wykrywanie uszkodzeñ Trzy szeroko stosowane taktyki wykrywania uszkodzeñ to: ping/echo, puls i wyjÈtki. x Ping/echo. Pewien komponent wysyïa specjalny komunikat i oczekuje, ĝe komponent moni- torowany odeĂle w predefiniowanym czasie „echo” jego sygnaïu. Mechanizm taki moĝna zastosowaÊ w grupie komponentów wspólnie odpowiadajÈcych za pewne zadanie w systemie. Jest teĝ czÚsto wykorzystywany przez klienty do monitorowania parametrów wydajno- Ăciowych serwera i Ăcieĝki komunikacyjnej. Mechanizmy wykrywania uszkodzeñ moĝna ïÈczyÊ w hierarchie, w których mechanizm najniĝszego poziomu monitoruje procesy pra- cujÈce na tym samym procesorze, a mechanizm na wyĝszym poziomie monitoruje stan kontrolerów na niĝszym poziomie. Pozwala to uniknÈÊ obciÈĝania kanaïu komunikacyj- nego komunikacjÈ zdalnego monitora z wszystkimi procesami. x Puls. Komponent monitorowany wysyïa regularnie komunikat pulsu do komponentu moni- torujÈcego. Gdy komunikat pulsu nie zostaje odebrany, nastÚpuje powiadomienie komponen- tu odpowiedzialnego za usuniÚcie uszkodzenia. Komunikaty pulsu mogÈ zawieraÊ dane. RolÚ pulsu moĝe peïniÊ na przykïad przesyïany okresowo dziennik pracy bankomatu. Komunikat taki jest jednoczeĂnie komunikatem zawierajÈcym przekazywane do przetwarzania dane. x WyjÈtki. JednÈ z metod monitorowania uszkodzeñ jest przechwytywanie wyjÈtków, jak te zgïaszane przy wystÈpieniu bïÚdów naleĝÈcych do klas wymienionych w przykïadzie w rozdziale 4. Procedura obsïugi wyjÈtku jest zazwyczaj wykonywana w tym samym pro- cesie, w którym zostaï on wygenerowany. 110 5. UZYSKIWANIE ATRYBUTÓW JAKO¥CIOWYCH Taktyki ping/echo i pulsu bazujÈ na odrÚbnych procesach, mechanizm wyjÈtków dziaïa w ob- rÚbie jednego procesu. Procedura obsïugi wyjÈtku przeprowadza zazwyczaj transformacjÚ se- mantycznÈ uszkodzenia do postaci umoĝliwiajÈcej jego przetwarzanie. Przywracanie stanu systemu Na przywracanie stanu systemu skïada siÚ przygotowanie do przywracania i wïaĂciwa naprawa. Poniĝej przedstawiamy wybór taktyk przygotowania do przywracania i naprawy systemu. x Gïosowanie. Procesy pracujÈce na nadmiarowych procesorach przyjmujÈ takie same dane wejĂciowe i obliczajÈ prostÈ wartoĂÊ wyjĂciowÈ, która jest przekazywana do mechanizmu gïosowania. Jeĝeli mechanizm ten wykryje, ĝe zachowanie jednego procesora odbiega od wiÚkszoĂci, proces ten zostaje uznany za uszkodzony. Przy gïosowaniu moĝe byÊ stosowa- ny algorytm „rzÈdów wiÚkszoĂci”, „komponentu preferowanego” lub inny. Jest to metoda stosowana do wykrywania niepoprawnego dziaïania algorytmów i uszkodzeñ procesorów, czÚsto spotykana w systemach sterowania. Jeĝeli wszystkie procesory pracujÈ wedïug tych samych algorytmów, redundancja pozwala wykryÊ jedynie uszkodzenie procesora, ale nie chroni przed bïÚdami algorytmów. Jeĝeli konsekwencje awarii sÈ dotkliwe (na przykïad utrata ĝycia), zróĝnicowanie nadmiarowych komponentów moĝe byÊ bardzo duĝe. Skrajnym przykïadem zróĝnicowania jest przekazanie pracy nad kaĝdym z nadmiaro- wych komponentów innemu zespoïowi ze wskazaniem innej platformy. Nieco mniej wy- szukanym podejĂciem jest opracowywanie wersji tego samego skïadnika pracujÈcych na róĝnych platformach. Wprowadzanie zróĝnicowañ tego rodzaju jest zawsze kosztowne — zarówno na poczÈtku, jak i przy póěniejszej konserwacji systemu, wiÚc stosuje siÚ je tylko w wyjÈtkowych przypadkach, na przykïad w mechanizmach awioniki. Mechanizm gïoso- wania jest zazwyczaj stosowany w systemach sterowania, w których porównywane wyjĂcia sÈ proste i ïatwe w klasyfikacji jako zgodne lub nie, obliczenia majÈ charakter cykliczny, a wszystkie nadmiarowe komponenty mogÈ otrzymywaÊ równowaĝne dane wejĂciowe z czuj- ników. Taktyka ta nie wiÈĝe siÚ z przerwÈ w pracy, poniewaĝ system gïosowania moĝe dziaïaÊ takĝe po wykryciu awarii. ZnanÈ odmianÈ tego podejĂcia jest metoda Simplex, polega- jÈca na korzystaniu z wyników komponentu „preferowanego”, dopóki nie odbiegajÈ one od przesyïanych przez komponent „zaufany”. W przypadku awarii nastÚpuje przeïÈczenie na dane z komponentu zaufanego. Synchronizacja nadmiarowych komponentów nastÚ- puje automatycznie, poniewaĝ zakïada siÚ, ĝe wszystkie pracujÈ jednoczeĂnie z tym sa- mym zespoïem wejĂÊ. x Redundancja aktywna (gorÈcy restart). Wszystkie nadmiarowe komponenty reagujÈ na zdarzenia jednoczeĂnie. SÈ wiÚc w tym samym stanie. Wykorzystywana jest odpowiedě jednego komponentu (zazwyczaj pierwszego, który odpowie), a pozostaïe sÈ odrzucane. W przypadku wystÈpienia uszkodzeñ przerwa w pracy systemów stosujÈcych tÚ taktykÚ trwa zazwyczaj milisekundy, poniewaĝ komponent zapasowy jest aktywny, a jedyny potrzebny czas to czas przeïÈczania. Redundancja aktywna to metoda czÚsto stosowana w konfigura- cjach klient-serwer, takich jak systemy zarzÈdzania bazami danych, gdzie szybkie reakcje na wystÈpienie uszkodzenia sÈ niezbÚdne. W systemie rozproszonym o wysokiej dostÚpnoĂci nadmiarowoĂÊ moĝe dotyczyÊ Ăcieĝek komunikacyjnych. Przykïadowo poĝÈdane moĝe byÊ za- stosowanie sieci LAN o wielu równolegïych Ăcieĝkach i umieszczenie kaĝdego nadmiaro- wego komponentu na odrÚbnej Ăcieĝce. Wówczas pojedyncza awaria mostu lub Ăcieĝki nie powoduje, ĝe wszystkie skïadniki systemu stajÈ siÚ niedostÚpne. Synchronizacja polega na zapewnieniu, ĝe wszystkie komunikaty przesyïane do kompo- nentu z redundancjÈ sÈ przesyïane do wszystkich jego nadmiarowych wersji. Jeĝeli ko- munikacja moĝe ulec zakïóceniu (ze wzglÚdu na przeciÈĝone lub zawodne ïÈcza), przywraca- 5.2. TAKTYKI DOST}PNO¥CI 111 nie stanu moĝe umoĝliwiaÊ niezawodny protokóï transmisji. Protokóï taki wprowadza wymóg przesïania potwierdzenia przez wszystkich odbiorców. Towarzyszy temu pewna forma kontroli integralnoĂci komunikacji, na przykïad suma kontrolna. Jeĝeli nadawca nie moĝe stwierdziÊ, ĝe wszyscy odbiorcy otrzymali komunikat, to ponawia on próbÚ przesïa- nia do komponentów, które nie potwierdzajÈ odbioru. Ponowne wysyïanie nieodebranych komunikatów (czasem z uĝyciem róĝnych Ăcieĝek komunikacji) jest kontynuowane do chwili, gdy algorytm nadawcy pozwoli uznaÊ odbiorcÚ za wyïÈczonego. x Redundancja pasywna (ciepïy restart, podwójna redundancja, potrójna redundancja). Jeden komponent (komponent gïówny) reaguje na zdarzenia i informuje pozostaïe kompo- nenty (komponenty awaryjne) o wymaganych aktualizacjach stanu. Gdy nastÚpuje awaria, system musi przede wszystkim zweryfikowaÊ, czy kopia zapasowa jest wystarczajÈco aktual- na, by moĝna byïo wznowiÊ udostÚpnianie usïug. To podejĂcie takĝe stosuje siÚ w systemach sterowania, przede wszystkim wtedy, gdy dane wejĂciowe sÈ pobierane z kanaïów komuni- kacyjnych lub czujników, które muszÈ zostaÊ przeïÈczone w przypadku awarii na korzysta- nie z komponentów awaryjnych. W rozdziale 6., w którym jest omawiany przykïad systemu kontroli ruchu lotniczego, spotkamy siÚ z tÈ taktykÈ w praktyce. W tym przypadku kompo- nent pomocniczy decyduje o tym, kiedy przejÈÊ zadania komponentu gïównego, ale czÚsto moĝna spotkaÊ siÚ z tym, ĝe za tÚ decyzjÚ odpowiadajÈ inne skïadniki. O tym, czy taktyka speïnia swoje zadanie, w duĝej mierze decyduje zdolnoĂÊ komponentów awaryjnych do po- prawnego przejÚcia pracy. Okresowe wymuszanie przeïÈczania — na przykïad raz na dobÚ lub raz na tydzieñ — zwiÚksza dostÚpnoĂÊ systemu. Niektóre systemy baz danych wymu- szajÈ przeïÈczenie pamiÚci masowej dla kaĝdego nowego elementu danych. Nowy element jest zapisywany w stronie shadow, a jej wczeĂniejsza wersja stajÚ siÚ kopiÈ zapasowÈ. W ta- kich rozwiÈzaniach przerwa w pracy moĝe zostaÊ skrócona do kilku sekund. Za synchronizacjÚ odpowiada komponent gïówny, który moĝe zagwarantowaÊ jÈ po- przez atomowe emisje do komponentów awaryjnych. x Zapas. Przygotowanie zapasowej platformy obliczeniowej przeznaczonej do caïoĂciowego zastÚpowania grupy zróĝnicowanych komponentów. Po awarii musi ona zostaÊ uruchomiona, a jej stan zainicjalizowany. Uzyskanie wïaĂciwego stanu zapasu umoĝliwia regularne zapi- sywanie punktów kontrolnych systemu i zmian stanu z uĝyciem urzÈdzenia zapewniajÈcego trwaïe skïadowanie danych. PraktycznÈ formÈ zastosowania tej taktyki jest zapewnianie zapa- sowej stacji roboczej, z której moĝe korzystaÊ uĝytkownik w przypadku awarii jego gïów- nego stanowiska pracy. PrzerwÚ w pracy mierzy siÚ zazwyczaj w minutach. Niektóre taktyki uwzglÚdniajÈ wznawianie pracy komponentu — naprawiony po awa- rii komponent moĝe zostaÊ ponownie wprowadzony do systemu. Przykïady takich taktyk to: powielanie, resynchronizacja stanu i odwoïywanie. x Powielanie (ang. shadow operation). Komponent, który wczeĂniej ulegï awarii, moĝe przez pewien czas pracowaÊ w „trybie powielania” w celu weryfikacji, ĝe jego dziaïanie jest zgodne z dziaïaniem komponentów, których praca nie ulegïa zakïóceniu. x Resynchronizacja stanu. Taktyki redundancji aktywnej i pasywnej wymagajÈ, by przywraca- ny komponent zostaï przed wïÈczeniem do usïugi odpowiednio zaktualizowany. PodejĂcie do aktualizacji zaleĝy od dopuszczalnego czasu przerwy w pracy, rozmiaru aktualizacji i liczby niezbÚdnych do jej przeprowadzenia komunikatów. O ile to moĝliwe, najlepszym rozwiÈ- zaniem jest pojedynczy komunikat opisujÈcy stan. Przyrostowe aktualizowanie stanu ïÈ- czone z okresami aktywnoĂci komponentu prowadzi do znacznego wzrostu zïoĝonoĂci. x Punkty kontrolne i odwoïywanie (ang. rollback). Punkt kontrolny to zapis spójnego sta- nu, który tworzy siÚ okresowo lub w reakcji na pewne zdarzenia. Zdarza siÚ, ĝe system ulega nietypowej awarii i w zauwaĝalny sposób traci integralnoĂÊ. W takiej sytuacji funk- cjonowanie systemu moĝna przywróciÊ, uĝywajÈc wczeĂniejszego punktu kontrolnego oraz dziennika transakcji wykonanych od czasu jego zapisania. 112 5. UZYSKIWANIE ATRYBUTÓW JAKO¥CIOWYCH Zapobieganie uszkodzeniom Oto taktyki zapobiegania uszkodzeniom: x WyïÈczanie z systemu. Taktyka polegajÈca na usuwaniu z systemu wybranych kompo- nentów w celu poddania ich pewnym dziaïaniom majÈcym zapobiec typowym awariom. Przykïadem moĝe byÊ reinicjalizowanie komponentu w celu zabezpieczenia systemu przed katastrofalnymi skutkami potencjalnych „wycieków” pamiÚci. Jeĝeli wyïÈczanie z pracy nastÚpuje automatycznie, moĝna zaprojektowaÊ odpowiedniÈ strategiÚ architektu- ry. Jeĝeli wyïÈczanie ma byÊ rÚczne, równieĝ naleĝy zadbaÊ o to w konstrukcji systemu. x Transakcje. Transakcja to poïÈczenie sekwencji kroków, które zapewnia, ĝe sekwencja ta bÚdzie mogïa zostaÊ wycofana jako caïoĂÊ. Transakcje wykorzystuje siÚ w celu zabezpie- czenia przed wpïywem na jakiekolwiek dane, w sytuacji gdy jeden z kroków procesu nie zostaje poprawnie wykonany, a takĝe by zapobiegaÊ kolizjom wÈtków korzystajÈcych z tych samych danych. x Monitor procesów. Po wykryciu uszkodzenia w jednym z procesów proces monitorujÈcy moĝe go usunÈÊ i utworzyÊ nowy o odpowiednio zainicjalizowanym stanie. Rysunek 5.3 podsumowuje omówione taktyki. Rysunek 5.3. Taktyki dostÚpnoĂci 5.3. Taktyki modyfikowalnoĂci Przypomnijmy z rozdziaïu 4. — taktyki modyfikowalnoĂci majÈ na celu uzyskanie wpïywu na czas i koszty implementacji, testowania i wdraĝania. RelacjÚ tÚ ilustruje rysunek 5.4. Taktyki modyfikowalnoĂci ïÈczymy w grupy wedïug ich celów. Pierwszy zbiór ïÈczy cel zmniejszenia liczby moduïów, na które zmiana bezpoĂrednio wpïywa. Jest to nazywane lokali- zowaniem 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 ïañcucha zaleĝnoĂci, w którym zmiany w jednym miejscu prowadzÈ do zmian w innym. Operujemy przy tym istotnym rozróĝnieniem na moduïy, na które zmiana wpïywa 5.3. TAKTYKI MODYFIKOWALNO¥CI 113 Rysunek 5.4. Cel taktyk modyfikowalnoĂci bezpoĂrednio (pewnej modyfikacji ulega ich zakres odpowiedzialnoĂci), i takie, na które zmia- na wpïywa poĂrednio (zakres odpowiedzialnoĂci pozostaje, ale modyfikacja jest konieczna ze wzglÚdu na moduïy pod bezpoĂrednim wpïywem zmiany). Trzecia grupa taktyk ukierunkowa- na jest na czas i koszty wdraĝania. W tym przypadku chodzi przede wszystkim o opóěnienie czasu wiÈzania. Lokalizowanie modyfikacji ChoÊ nie moĝna ogólnie mówiÊ o Ăcisïej relacji miÚdzy liczbÈ moduïów, na które wpïywa pe- wien zespóï zmian, a kosztami wprowadzenia tych zmian, nie ulega wÈtpliwoĂci, ĝe ogranicza- nie zakresu koniecznych modyfikacji do jak najmniejszej liczby moduïów jest skutecznÈ meto- dÈ zmniejszania kosztów. Celem taktyk z opisywanej tu grupy jest uzyskanie takich przypisañ zakresów odpowiedzialnoĂci moduïów, by zakres przewidywanych zmian byï jak najmniejszy. Prezentujemy piÚÊ takich taktyk. x Utrzymywanie spójnoĂci semantycznej. SpójnoĂÊ semantyczna odnosi siÚ do relacji miÚdzy zakresami odpowiedzialnoĂci w module. Celem jest zapewnienie, ĝe wszystkie te zakresy wspóïdziaïajÈ bez nadmiernego uzaleĝnienia od innych moduïów. ¥rodkiem do osiÈgniÚcia tego celu jest przestrzeganie w formuïowaniu tych zakresów zasad spójnoĂci semantycznej. SÈ w tym pewnÈ pomocÈ róĝne miary siïy powiÈzañ i poziomu spójnoĂci. Brakuje im jednak odniesienia do kontekstu zmian. SpójnoĂÊ semantycznÈ naleĝy oceniaÊ w perspektywie pewnego zbioru zmian przewidywanych w przyszïoĂci. Szczególnie waĝnÈ taktykÈ w tej grupie jest tworzenie abstrakcji wspólnych usïug. Zapewnianie wspólnych usïug poprzez wprowadzenie wyspecjalizowanych moduïów jest zazwyczaj postrzegane jako skuteczny Ărodek uïatwiajÈcy ponowne wykorzystywanie elementów. Nie jest to je- dyna korzyĂÊ — uogólnienie wspólnych usïug sprzyja teĝ modyfikowalnoĂci. Po wyïÈcze- niu usïug wprowadzane w nich modyfikacje nie muszÈ byÊ powielane w kaĝdym wyko- rzystujÈcym je module. Co wiÚcej, modyfikacje w moduïach korzystajÈcych z tych usïug nie majÈ wpïywu na inne moduïy, których praca opiera siÚ na tych samych usïugach. Jest to wiÚc taktyka nie tylko sprzyjajÈca lokalizowaniu modyfikacji, ale teĝ zabezpieczajÈca przed efektem domina. Przykïady wyïÈczenia wspólnych usïug to miÚdzy innymi stoso- wanie platform aplikacji (ang. application frameworks) i korzystanie z innego rodzaju opro- gramowania middleware. x Przewidywanie prawdopodobnych zmian. Przewidywanie zbioru oczekiwanych zmian po- zwala oceniÊ zastosowany podziaï zakresów odpowiedzialnoĂci. Podstawowe pytanie brzmi: „Czy dla kaĝdej ze zmian proponowana dekompozycja ogranicza zespóï moduïów, które muszÈ zostaÊ zmodyfikowane w celu jej wprowadzenia?”. Towarzyszy mu równieĝ druga kwestia do rozwaĝenia: „Czy zasadniczo róĝniÈce siÚ zmiany wpïywajÈ na te same moduïy?”. Czym róĝni siÚ to od spójnoĂci semantycznej? Przypisywanie zakresów odpowiedzialnoĂci 114 5. UZYSKIWANIE ATRYBUTÓW JAKO¥CIOWYCH na bazie spójnoĂci semantycznej wiÈĝe siÚ z zaïoĝeniem, ĝe równieĝ oczekiwane zmiany bÚdÈ spójne semantycznie. Taktyka przewidywania zmian nie koncentruje siÚ na spójno- Ăci zadañ moduïu, ale na ograniczaniu skutków zmian. W praktyce jest ona trudna do zasto- sowania niezaleĝnie od innych, poniewaĝ nie jest moĝliwe przewidzenie kaĝdej zmiany. To powoduje, ĝe zazwyczaj stosuje siÚ jÈ w poïÈczeniu z taktykÈ spójnoĂci semantycznej. x Uogólnienie moduïu. Zapewnienie moduïowi wiÚkszej ogólnoĂci prowadzi do uzyskania obsïugi wiÚkszej liczby funkcji. Dane wejĂciowe moĝna traktowaÊ jak jÚzyk definiujÈcy moduï. Moĝe to sprowadzaÊ siÚ do zastÈpienia staïych parametrami. Moĝe teĝ prowadziÊ do rozwiÈzañ bardziej zïoĝonych, na przykïad implementowania moduïu w formie inter- pretera, kiedy to parametry wejĂciowe stajÈ siÚ jego jÚzykiem. Im bardziej ogólny moduï, tym bardziej prawdopodobne jest to, ĝe wymagane zmiany bÚdzie moĝna wprowadziÊ drogÈ dostosowania jÚzyka na wejĂciu, bez modyfikowania kodu. x Ograniczanie dostÚpnych moĝliwoĂci. Zmiany, zwïaszcza w przypadku linii produktów (patrz rozdziaï 14.), mogÈ mieÊ bardzo szeroko zakrojone skutki i wpïywaÊ na wiele mo- duïów. Ograniczanie zakresu dostÚpnych moĝliwoĂci pozwala na redukcjÚ wpïywu mody- fikacji. Przykïadowo punkt zróĝnicowania w projektowanej linii produktów moĝe pozwalaÊ na zmianÚ procesora — ograniczenie moĝliwoĂci wymiany procesora do podzespoïów na- leĝÈcych do tej samej rodziny zmniejsza zakres dostÚpnych moĝliwoĂci. Zapobieganie efektowi domina O efekcie domina mówimy wtedy, gdy zmiana wymusza modyfikacje w moduïach, na które nie ma bezpoĂredniego wpïywu. Przykïadowo moduï A zostaje zmodyfikowany w celu wprowa- dzenia pewnej zmiany, co prowadzi do koniecznoĂci modyfikacji moduïu 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 powiÈzany z moduïem A. Omówienie efektu domina zaczniemy od rozwaĝenia róĝnych rodzajów zaleĝnoĂci miÚdzy moduïami. Moĝna wyróĝniÊ osiem typów takiego powiÈzania: (1) Skïadnia: x 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; x usïug — aby moduï B byï poprawnie kompilowany i wykonywany, sygnatura usïug zapewnianych przez moduï A i wywoïywanych przez moduï B musi byÊ zgodna z zaïoĝeniami moduïu B. (2) Semantyka: (3) KolejnoĂÊ: x danych — aby moduï B byï poprawnie wykonywany, semantyka danych generowa- nych przez moduï A i pobieranych przez moduï B musi byÊ zgodna z zaïoĝeniami moduïu B; x usïug — aby moduï B byï poprawnie wykonywany, semantyka usïug zapewnianych przez moduï A i uĝywanych przez moduï B musi byÊ zgodna z zaïoĝeniami moduïu B. x danych — aby moduï B byï poprawnie wykonywany, musi on otrzymywaÊ dane ge- nerowane przez moduï A w ustalonej kolejnoĂci; na przykïad nagïówek pakietu da- nych musi w trakcie odbierania poprzedzaÊ wïaĂciwÈ treĂÊ (w przeciwieñstwie do protokoïów, które doïÈczajÈ do danych numery sekwencyjne); 5.3. TAKTYKI MODYFIKOWALNO¥CI 115 x sterowania — aby moduï B byï poprawnie wykonywany, wczeĂniej, w okreĂlonych ramach czasowych, muszÈ zostaÊ wykonane procedury moduïu A. Przykïadowo pro- cedury moduïu A muszÈ zostaÊ wykonane nie dïuĝej niĝ 5 milisekund przed rozpo- czÚciem wykonywania moduïu B. (4) ToĝsamoĂÊ interfejsu moduïu A — moduï A moĝe mieÊ wiele interfejsów. Aby moduï B byï poprawnie kompilowany i wykonywany, toĝsamoĂÊ (nazwa lub uchwyt) interfejsu musi byÊ zgodna z oczekiwaniami moduïu B. (5) Lokalizacja moduïu A w czasie wykonywania — aby moduï B byï poprawnie wykony- wany, lokalizacja moduïu A w czasie wykonywania musi byÊ zgodna z oczekiwaniami moduïu B. Przykïadowo moduï B moĝe zakïadaÊ, ĝe moduï A pracuje w innym procesie na tym samym procesorze. (6) JakoĂÊ usïug/danych zapewnianych przez moduï A — aby moduï B byï poprawnie wy- konywany, pewne wïasnoĂci dotyczÈce danych lub usïug zapewnianych przez moduï A muszÈ byÊ zgodne z zaïoĝeniami moduïu B. Przykïadowo dane dostarczane przez czujnik muszÈ mieÊ pewnÈ dokïadnoĂÊ, aby algorytmy w module B dziaïaïy poprawnie. (7) Istnienie moduïu A — aby moduï B byï poprawnie wykonywany, moduï A musi istnieÊ. Jeĝeli na przykïad obiekt B ĝÈda usïugi obiektu A, a obiekt ten nie istnieje lub nie moĝe zostaÊ dynamicznie utworzony, dziaïanie obiektu B nie bÚdzie poprawne. (8) Sposób korzystania z zasobów — aby moduï B byï poprawnie wykonywany, sposób ko- rzystania z zasobów przez moduï A musi byÊ zgodny z zaïoĝeniami moduïu B. Moĝe to dotyczyÊ uĝytkowania zasobów (A uĝywa tej samej pamiÚci co B) lub wïasnoĂci zasobów (B rezerwuje zasób, który A uwaĝa za wïasny). DysponujÈc tak sprecyzowanymi kategoriami zaleĝnoĂci, moĝemy przejĂÊ do omówienia dostÚp- nych architektowi taktyk pozwalajÈcych 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 odno- szÈ siÚ do interfejsów moduïu — ukrywania informacji i utrzymywania istniejÈcych juĝ inter- fejsów, aby nastÚpnie przejĂÊ do taktyk przerywania ïañcucha zaleĝnoĂci — uĝycia poĂrednika. x Ukrywanie informacji. Ukrywanie informacji to dekompozycja zakresu odpowiedzialno- Ăci pewnej jednostki (systemu lub czÚĂci systemu) na mniejsze elementy i okreĂlanie, które z nich majÈ mieÊ charakter prywatny, a które publiczny. Publiczny zakres odpowiedzialnoĂci to zakres dostÚpny za poĂrednictwem interfejsów. Celem jest doprowadzenie do izolacji zmian wewnÈtrz moduïu i zapobieĝenie ich propagacji na inne moduïy. Jest to najstarsza technika ograniczania skutków zmian. Jest ona mocno powiÈzana z przewidywaniem oczekiwanych modyfikacji, poniewaĝ modyfikacje te stajÈ siÚ podstawÈ dekompozycji. x Zachowywanie istniejÈcych interfejsów. Jeĝeli moduï B jest zaleĝny od nazwy i sygna- tury interfejsu moduïu A, utrzymanie tego interfejsu i jego skïadni pozwala uniknÈÊ zmian w module B. OczywiĂcie, nie jest to taktyka bezwzglÚdnie skuteczna, gdy moduï B jest zaleĝny od moduïu A semantycznie, poniewaĝ warstwa znaczeniowa danych i usïug jest trudniejsza do zamaskowania. To samo moĝna powiedzieÊ o maskowaniu zaleĝnoĂci bazujÈ- cych na jakoĂci danych lub usïug, poziomie wykorzystania zasobów lub wïasnoĂci zaso- bów. StabilnoĂÊ interfejsu moĝna teĝ osiÈgnÈÊ oddzielajÈc interfejs od implementacji. Pozwala to tworzyÊ abstrakcyjne interfejsy maskujÈce zróĝnicowanie. Odmiany moĝna realizowaÊ w ramach istniejÈcego zakresu odpowiedzialnoĂci lub przez zastÚpowanie implementacji. Wzorce bazujÈce na tej taktyce to przede wszystkim: x dodawanie interfejsów — wiÚkszoĂÊ jÚzyków programowania pozwala na stosowanie wielu interfejsów; nowe usïugi lub dane mogÈ byÊ udostÚpniane poprzez nowe in- terfejsy, dziÚki czemu starsze pozostajÈ niezmienione i zachowujÈ sygnatury; 116 5. UZYSKIWANIE ATRYBUTÓW JAKO¥CIOWYCH x dodawanie adaptera — polega na dodaniu do moduïu A adaptera, który go osïania i zapewnia pierwotnÈ sygnaturÚ; x korzystanie z wersji zastÚpczej — jeĝeli modyfikacja prowadzi do usuniÚcia moduïu A, to zapewnienie jego wersji zastÚpczej pozwoli zachowaÊ moduï B w niezmienionej postaci (jeĝeli moduï B jest zaleĝny tylko od sygnatury moduïu A). x Ograniczanie Ăcieĝek komunikacji. Taktyka polegajÈca na ograniczaniu liczby moduïów, z którymi dany moduï wymienia lub wspóïuĝytkuje dane — projektant dÈĝy do uzyskania jak najmniejszej liczby moduïów, które pobierajÈ dane z moduïu rozwaĝanego lub prze- kazujÈ je do niego. Efekt domina zostaje zredukowany, poniewaĝ generowanie i pobiera- nie danych odpowiada za wprowadzenie powodujÈcych go zaleĝnoĂci. Wzorzec korzysta- jÈcy z tej taktyki zostanie zaprezentowany w rozdziale 8. (symulator lotu). x Uĝycie poĂrednika. Jeĝeli moduï A ïÈczy z moduïem B pewien rodzaj zaleĝnoĂci inny niĝ semantyczna, to jest moĝliwe umieszczenie poĂrednika miÚdzy B i A, którego zadaniem jest zarzÈdzanie czynnoĂciami zwiÈzanymi z tÈ zaleĝnoĂciÈ. Nazw takich poĂredników jest wiele. Tutaj omówimy poszczególne z nich w kategoriach wyliczonych wczeĂniej typów zaleĝnoĂci. Podobnie jak wczeĂniej czarnym scenariuszem jest brak moĝliwoĂci kompen- sacji zmian semantycznych. x Dane (skïadnia). RolÚ poĂrednika miÚdzy producentem i konsumentem danych przyjmujÈ magazyny danych (pasywne lub typu podrÚcznej tablicy). Niektóre wzorce publikowania-subskrypcji (w których dane przepïywajÈ przez pewien komponent centralny) mogÈ teĝ zapewniaÊ konwersjÚ skïadni generowanej przez moduï A do tej, której oczekuje moduï B. Wzorce MVC i PAC zapewniajÈ konwersjÚ danych z jednej postaci (zwiÈzanej z urzÈdzeniem wejĂciowym lub wyjĂciowym) na innÈ (uĝywanÈ w modelu w MVC lub w abstrakcji w PAC). x Usïugi (skïadnia). Fasada, most, mediator, strategia, proxy i fabryka to wzorce wprowadzajÈce poĂrednika konwertujÈcego skïadniÚ usïugi. Kaĝdy z nich prowadzi do zabezpieczenia przed propagacjÈ zmian. x ToĝsamoĂÊ interfejsu moduïu A. Wzorzec brokera pozwala zamaskowaÊ zmiany w toĝsamoĂci interfejsu. Jeĝeli moduï B jest zaleĝny od toĝsamoĂci interfejsu moduïu A i toĝsamoĂÊ ta ulega zmianie, dodanie toĝsamoĂci do brokera i pozostawienie brokerowi tworzenia poïÈczenia z nowÈ toĝsamoĂciÈ A pozwala pozostawiÊ moduï B bez zmian. x Lokalizacja moduïu A w czasie wykonywania. Serwer nazw pozwala zmieniaÊ lo- kalizacjÚ A bez wpïywu na B. A odpowiada za rejestrowanie swojej bieĝÈcej lokaliza- cji na serwerze nazw, a B pobiera z niego aktualne informacje. x Sposób korzystania z zasobów lub kontrola zasobu przez moduï A. Menedĝer za- sobów to poĂrednik odpowiedzialny za ich alokowanie. IstniejÈ menedĝery gwaran- tujÈce zaspokojenie wszystkich ĝÈdañ mieszczÈcych siÚ w okreĂlonych ograniczeniach (na przykïad menedĝery z przypisywaniem monotonicznym wedïug czÚstotliwoĂci, sto- sowane w systemach czasu rzeczywistego). OczywiĂcie, zastosowanie menedĝera wiÈ- ĝe siÚ z przejÚciem przez niego kontroli nad zasobem. x Istnienie moduïu A. Wzorzec fabryki daje moĝliwoĂÊ tworzenia obiektów odpowied- nio do potrzeb, dziÚki czemu problem zaleĝnoĂci obiektu B od istnienia obiektu A roz- wiÈzuje specjalny moduï fabryki. 5.3. TAKTYKI MODYFIKOWALNO¥CI 117 Opóěnianie czasu wiÈzania Omówione kategorie taktyk prowadzÈ do zmniejszenia liczby moduïów wymagajÈcych mody- fikacji w celu wprowadzenia zmiany. W naszych scenariuszach modyfikowalnoĂci pojawiïy siÚ jed- nak dwa elementy, których nie moĝna sprowadziÊ do redukcji liczby modyfikowanych czÚĂci pro- gramu — czas wdroĝenia i umoĝliwienie wprowadzania zmian osobom innym niĝ programiĂci. RealizacjÚ tych scenariuszy umoĝliwia opóěnianie czasu wiÈzania. Z taktykami tego rodzaju niezmiennie wiÈĝe siÚ istotny koszt dodatkowej infrastruktury, która umoĝliwi póěne wiÈzanie. WiÈzanie pewnego wyboru z dziaïaniem systemu moĝe nastÈpiÊ w róĝnych momentach. Tutaj zajmiemy siÚ jedynie aspektami, które majÈ wpïyw na czas wdraĝania. Wdraĝanie systemu jest pewnym procesem — po wprowadzeniu przez programistÚ zmiany nastÚpujÈ zazwyczaj proce- dury testowania i dystrybucji. WystÚpuje wiÚc istotne opóěnienie miÚdzy modyfikacjÈ a do- stÚpnoĂciÈ nowej wersji czy konfiguracji programu. Wprowadzenie wiÈzania w czasie wykony- wania oznacza, ĝe system zostaï odpowiednio przygotowany i ukoñczono wszystkie kroki zwiÈzane z testowaniem i dystrybucjÈ. Taktyka opóěniania czasu wiÈzania prowadzi do po- wstawania mechanizmów umoĝliwiajÈcych uĝytkownikowi lub administratorowi operowanie parametrami, które zmieniajÈ zachowanie systemu. Wszystkie wymienione poniĝej taktyki majÈ wpïyw na system w czasie ïadowania lub w czasie wykonywania. x Rejestracja w czasie wykonywania umoĝliwia uzyskanie mechanizmu typu plug-and-play kosztem dodatkowego obciÈĝenia operacjami zwiÈzanymi z rejestrowaniem. Przykïadem moĝe byÊ rejestracja typu publikacja-subskrypcja, którÈ moĝna implementowaÊ w czasie wykonywania lub w czasie ïadowania. x Pliki konfiguracyjne okreĂlajÈ parametry uruchomieniowe. x Polimorfizm umoĝliwia póěne wiÈzanie wywoïañ metod. x WymiennoĂÊ komponentów pozwala na wiÈzanie w czasie ïadowania. x Przestrzeganie protokoïów pozwala wiÈzaÊ w czasie wykonywania niezaleĝne procesy. Taktyki modyfikowalnoĂci podsumowuje rysunek 5.5. Rysunek 5.5. Taktyki modyfikowalnoĂci 118 5. UZYSKIWANIE ATRYBUTÓW JAKO¥CIOWYCH 5.4. Taktyki wydajnoĂci Przypomnijmy z rozdziaïu 4., ĝe celem taktyk wydajnoĂci jest uzyskanie reakcji na odbierane przez system zdarzenie w ramach pewnych ograniczeñ czasowych. Zdarzenie lub ciÈg zdarzeñ inicjuje pewne obliczenia lub funkcje. Sygnaïem moĝe byÊ nadejĂcie komunikatu, upïyniÚcie pewnego czasu, wykrycie znaczÈcej zmiany stanu w Ărodowisku systemu itp. System przetwa- rza zdarzenia i generuje reakcjÚ. Taktyki wydajnoĂci pozwalajÈ uzyskaÊ kontrolÚ nad iloĂciÈ czasu, który musi upïynÈÊ miÚdzy zdarzeniem a reakcjÈ. Ilustruje to rysunek 5.6. Czas miÚdzy odebraniem zdarzenia a wygenerowaniem odpowiedzi okreĂla siÚ terminem latencja. Rysunek 5.6. Cel taktyk wydajnoĂci Po odebraniu zdarzenia nastÚpuje jego przetwarzanie. Moĝe ono zostaÊ z pewnych przy- czyn zablokowane. Dwa podstawowe czynniki o duĝym wpïywie na czas odpowiedzi to: po- ziom wykorzystania zasobów i czas blokad. 1. Poziom wykorzystania zasobów. Zasoby to przede wszystkim procesor, magazyny da- nych, pasmo komunikacyjne sieci i pamiÚÊ, ale pojÚcie to obejmuje teĝ obiekty definiowane w ramach konstrukcji systemu. Przykïadami mogÈ byÊ wymagajÈce zarzÈdzania bufory lub ko- niecznoĂÊ zapewnienia sekwencyjnego dostÚpu do sekcji krytycznych. Zdarzenia mogÈ mieÊ róĝny charakter i dla kaĝdego typu zdarzenia wymagana jest pewna sekwencja przetwarzania. Przykïadowo 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 przeksztaïcony (tak zwany marshalling w terminologii OMG); przetworzony zgodnie z pewnym algorytmem; przesïany do wyjĂcia; umieszczony w buforze wyjĂciowym i przekaza- ny dalej, do innego komponentu lub systemu albo do uĝytkownika. Kaĝda z tych faz ma swój udziaï w ogólnej latencji przetwarzania zdarzenia. 2. Czas blokad. Procedury przetwarzania mogÈ nie uzyskaÊ dostÚpu do zasobu — ze wzglÚdu na jego nadmierne obciÈĝenie, caïkowitÈ niedostÚpnoĂÊ lub poniewaĝ niezbÚdny jest wynik innych procedur, który nie jest jeszcze dostÚpny. x Spory o zasoby. Rysunek 5.6 przedstawia odbierane przez system zdarzenia. Odbiór moĝe nastÚpowaÊ w pojedynczym strumieniu lub wielu strumieniach. Róĝne stru- mienie potrzebujÈce tego samego zasobu lub róĝne zdarzenia w tym samym strumie- niu, k
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Architektura oprogramowania w praktyce. Wydanie II
Autor:
, ,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: