Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00423 007387 11264272 na godz. na dobę w sumie
Architektura oprogramowania. Metody oceny oraz analiza przypadków - książka
Architektura oprogramowania. Metody oceny oraz analiza przypadków - książka
Autor: , , Liczba stron: 332
Wydawca: Helion Język publikacji: polski
ISBN: 83-7197-929-0 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> inne - programowanie
Porównaj ceny (książka, ebook, audiobook).
Podstawą każdego systemu oprogramowania jest jego architektura, czyli sposób, w jaki oprogramowanie jest tworzone z niezależnie rozwijanych komponentów oraz mechanizmy interakcji i wzajemne zależności pomiędzy nimi. Jeśli system ma być tworzony przez więcej niż jedną osobę, właśnie architektura pozwala im na wzajemną komunikację. Choć architektura jest postrzegana jako jeden z najważniejszych aspektów rozwoju współczesnych systemów, to jej ewaluacja niemal nigdy nie staje się standardową częścią procesu rozwojowego.

Wykorzystując wyraźnie określone związki między decyzjami dotyczącymi architektury projektu a wynikającymi z nich właściwościami oprogramowania, niniejsza książka opisuje metody ewaluacji architektury oraz przypadki ich praktycznego zastosowania. Książka 'Architektura oprogramowania. Metody oceny oraz analiza przypadków' prezentuje podstawową wiedzę pojęciową z zakresu metod oceny architektury i stanowi podręcznik opisujący krok po kroku proces takich ewaluacji przeprowadzanych w przypadku wielu organizacji rządowych i przemysłowych.

Architektura oprogramowania to gwałtownie rozwijająca się dziedzina badań i działań praktycznych w zakresie inżynierii oprogramowania. Książka prezentuje w szczególności trzy metody jej ewaluacji:

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

Darmowy fragment publikacji:

IDZ DO IDZ DO PRZYK£ADOWY ROZDZIA£ PRZYK£ADOWY ROZDZIA£ SPIS TREœCI SPIS TREœCI KATALOG KSI¥¯EK KATALOG KSI¥¯EK KATALOG ONLINE KATALOG ONLINE ZAMÓW DRUKOWANY KATALOG ZAMÓW DRUKOWANY KATALOG TWÓJ KOSZYK TWÓJ KOSZYK DODAJ DO KOSZYKA DODAJ DO KOSZYKA CENNIK I INFORMACJE CENNIK I INFORMACJE ZAMÓW INFORMACJE ZAMÓW INFORMACJE O NOWOœCIACH O NOWOœCIACH ZAMÓW CENNIK ZAMÓW CENNIK CZYTELNIA CZYTELNIA FRAGMENTY KSI¥¯EK ONLINE FRAGMENTY KSI¥¯EK ONLINE Wydawnictwo Helion ul. Koœciuszki 1c 44-100 Gliwice tel. 032 230 98 63 e-mail: helion@helion.pl Architektura oprogramowania. Metody oceny oraz analiza przypadków Autorzy: Paul Clements, Rick Kazman, Mark Klein T³umaczenie: Bart³omiej Garbacz ISBN: 83-7197-929-0 Tytu³ orygina³u: Evaluating Software Architectures Format: B5, stron: 330 Podstaw¹ ka¿dego systemu oprogramowania jest jego architektura, czyli sposób, w jaki oprogramowanie jest tworzone z niezale¿nie rozwijanych komponentów oraz mechanizmy interakcji i wzajemne zale¿noœci pomiêdzy nimi. Jeœli system ma byæ tworzony przez wiêcej ni¿ jedn¹ osobê, w³aœnie architektura pozwala im na wzajemn¹ komunikacjê. Choæ architektura jest postrzegana jako jeden z najwa¿niejszych aspektów rozwoju wspó³czesnych systemów, to jej ewaluacja niemal nigdy nie staje siê standardow¹ czêœci¹ procesu rozwojowego. Wykorzystuj¹c wyraŸnie okreœlone zwi¹zki miêdzy decyzjami dotycz¹cymi architektury projektu a wynikaj¹cymi z nich w³aœciwoœciami oprogramowania, niniejsza ksi¹¿ka opisuje metody ewaluacji architektury oraz przypadki ich praktycznego zastosowania. Ksi¹¿ka „Architektura oprogramowania. Metody oceny oraz analiza przypadków” prezentuje podstawow¹ wiedzê pojêciow¹ z zakresu metod oceny architektury i stanowi podrêcznik opisuj¹cy krok po kroku proces takich ewaluacji przeprowadzanych w przypadku wielu organizacji rz¹dowych i przemys³owych. Architektura oprogramowania to gwa³townie rozwijaj¹ca siê dziedzina badañ i dzia³añ praktycznych w zakresie in¿ynierii oprogramowania. Ksi¹¿ka prezentuje w szczególnoœci trzy metody jej ewaluacji: (cid:129) metodê analizy kompromisów architektonicznych (Architecture Tradeoff Analysis Method, ATAM) (cid:129) metodê analizy architektury programowej (Software Architecture Analysis Method, SAAM) (cid:129) czynne przegl¹dy projektów poœrednich (Active Reviews for Intermediate Designs, ARID) Spis treści Wskazówki dla Czytelnika...................................................d.............................15 Wstęp ...................................................d...................................................d..............19 1 Istota architektury oprogramowania...................................................d............23 1.1. Architektura jako medium komunikacyjne pomiędzy głównymi zainteresowanymi ................ 25 1.1.1. Architektura i jej wpływ na głównych zainteresowanych ...................................................e 25 1.1.2. Perspektywy architektoniczne ...................................................e............................................... 26 1.1.3. Języki opisu architektury ...................................................e........................................................ 31 1.2. Architektura jako forma ukazania najwcześniejszych decyzji projektowych ............................... 32 1.2.1. Style architektur ...................................................e...................................................e.................... 34 1.3. Architektura jako możliwa do wielokrotnego wykorzystania i przenoszenia abstrakcja systemu... 35 1.4. Podsumowanie ...................................................e...................................................e.................................. 36 1.5. Dalsza lektura ...................................................e...................................................e.................................... 36 1.6. Pytania dyskusyjne ...................................................e...................................................e........................... 38 2 Ocena architektury oprogramowania...................................................d...........39 2.1. Cele dokonywania oceny architektury...................................................e............................................. 43 2.2. Moment dokonywania oceny architektury...................................................e...................................... 44 2.3. Zainteresowane strony ...................................................e........................................................................ 46 2.4. Rezultaty procesu oceny architektury ...................................................e.............................................. 47 2.5. Właściwości, pod względem których architektura może podlegać ocenie ................................... 50 2.6. Przyczyny dużej niejasności analiz atrybutów jakościowych ...................................................e...... 53 2.7. Wyniki ewaluacji architektury oprogramowania...................................................e......................... 54 2.7.1. Wyniki metod ATAM, SAAM oraz ARID ...................................................e........................... 54 2.7.2. Wyniki związane tylko z metodą ATAM...................................................e............................. 56 2.8. Korzyści oraz koszta związane z przeprowadzaniem ewaluacji architektury ............................. 57 2.9. Dalsza lektura ...................................................e...................................................e.................................... 62 2.10. Pytania dyskusyjne ...................................................e...................................................e......................... 63 4 3 SPIS TREŚCI ATAM — metoda ewaluacji architektury...................................................d....65 3.1. Ogólny opis etapów metody ATAM ...................................................e................................................ 66 3.2. Szczegółowy opis etapów metody ATAM ...................................................e...................................... 67 3.2.1. Etap 1.: prezentacja metody ATAM ...................................................e...................................... 67 3.2.2. Etap 2.: prezentacja biznesowych czynników motywujących ............................................. 68 3.2.3. Etap 3.: prezentacja architektury ...................................................e........................................... 68 3.2.4. Etap 4.: identyfikacja stosowanych podejść architektonicznych ......................................... 69 3.2.5. Etap 5.: utworzenie drzewa użyteczności atrybutów jakościowych .................................. 71 3.2.6. Etap 6.: analiza metod architektonicznych...................................................e........................... 78 3.2.7. Etap 7.: „burza mózgów” i nadanie scenariuszom priorytetów ......................................... 81 3.2.8. Etap 8.: analiza metod architektonicznych...................................................e........................... 89 3.2.9. Etap 9.: prezentacja rezultatów ...................................................e.............................................. 90 3.3. Fazy metody ATAM ...................................................e...................................................e......................... 93 3.3.1. Działania fazy 0. ...................................................e...................................................e.................... 93 3.3.2. Działania fazy 1. ...................................................e...................................................e.................... 97 3.3.3. Działania fazy 2. ...................................................e...................................................e.................... 98 3.3.4. Działania fazy 3. ...................................................e...................................................e.................. 101 3.4. Dalsza lektura ...................................................e...................................................e.................................. 105 3.5. Pytania dyskusyjne ...................................................e...................................................e......................... 106 4 System kierowania polem walki — pierwsza analiza przdypadku dla metody ATAM...................................................d.........................................107 4.1. Czynności przygotowawcze...................................................e............................................................. 107 4.2. Faza 1. ...................................................e...................................................e............................................... 108 4.2.1. Etap 1.: przedstawienie metody ATAM ...................................................e............................. 108 4.2.2. Etap 2.: przedstawienie wyznaczników działania ...................................................e............ 109 4..2.3. Etap 3.: prezentacja architektury systemu...................................................e......................... 109 4.2.4. Etap 4.: identyfikacja rozwiązań strukturalnych...................................................e............... 109 4.2.5. Etap 5.: utworzenie drzewa atrybutów użytecznoścei...................................................e........... 110 4.2.6. Etap 6.: analiza rozwiązań architektury systemu ...................................................e............. 112 4.3. Faza 2. ...................................................e...................................................e............................................... 120 4.3.1. Etap 7.: „burza mózgów” i określenie priorytetów scenariuszy ....................................... 120 4.3.2. Etap 8.: analiza podejść architektonicznych...................................................e....................... 122 4.3.3. Etap 9.: prezentacja rezultatów ...................................................e............................................ 122 4.4. Rezultaty procesu ewaluacji systemu BCS ...................................................e.................................... 123 4.4.1. Dokumentacja ...................................................e...................................................e...................... 123 4.4.2. Wymagania ...................................................e...................................................e.......................... 126 4.4.3. Punkty wrażliwości i kompromisowe ...................................................e................................ 126 4.4.4. Zagrożenia dla architektury ...................................................e................................................. 126 4.5. Podsumowanie ...................................................e...................................................e................................ 127 4.6. Pytania dyskusyjne ...................................................e...................................................e......................... 127 SPIS TREŚCI 5 5 Istota atrybutów jakościowych ...................................................d....................129 5.1. Charakterystyki atrybutów jakościowych ...................................................e..................................... 130 5.1.1. Wydajność ...................................................e...................................................e............................ 131 5.1.2. Dostępność ...................................................e...................................................e........................... 135 5.1.3. Modyfikowalność...................................................e...................................................e................ 137 5.1.4. Pytania sugerowane przez charakterystyki ...................................................e....................... 140 5.2. Wykorzystanie charakterystyk atrybutów jakościowych w metodzie ATAM ........................... 141 5.3. Style architektoniczne oparte na atrybutach ...................................................e................................. 143 5.4. Podsumowanie ...................................................e...................................................e................................ 144 5.5. Dalsza lektura ...................................................e...................................................e.................................. 145 5.6. Pytania dyskusyjne ...................................................e...................................................e......................... 145 6 Analiza przypadku wykorzystania metody ATAM ...................................147 6.1. Tło ewaluacji ...................................................e...................................................e.................................... 148 6.2. Faza 0.: kwestie umowy i sprawy przygotowawcze...................................................e.................... 149 6.2.1. Faza 0., etap 1.: prezentacja metody ATAM ...................................................e...................... 150 6.2.2. Faza 0., etap 2.: opis systemu kandydującego ...................................................e................... 152 6.2.3. Faza 0., etap 3.: podjęcie decyzji o kontynuowaniu lub zaprzestaniu dalszych prac .... 154 6.2.4. Faza 0., etap 4.: wynegocjowanie harmonogramu prac...................................................e... 156 6.2.5. Faza 0., etap 5.: utworzenie zespołu ewaluacyjnego ...................................................e........ 158 6.2.6. Faza 0., etap 6.: przeprowadzenie wstępnego spotkania zespołu ewaluacyjnego ......... 161 6.2.7. Faza 0., etap 7.: przygotowanie do fazy 1. ...................................................e......................... 164 6.2.8. Faza 0., etap 8.: dokonanie przeglądu architektury...................................................e.......... 167 6.3. Faza 1.: Ewaluacja wstępna ...................................................e.............................................................. 169 6.3.1. Faza 1., etap 1.: prezentacja metody ATAM ...................................................e...................... 170 6.3.2. Faza 1., etap 2.: prezentacja wyznaczników dziaełania...................................................e............. 173 6.3.3. Faza 1., etap 3.: prezentacja architektury ...................................................e...........................178 6.3.4. Faza 1., etap 4.: identyfikacja podejść architektonicznych ................................................. 183 6.3.5. Faza 1., etap 5.: utworzenie drzewa użyteczności atrybutów jakościowych................... 186 6.3.6. Faza 1., etap 6.: analiza podejść architektonicznych...................................................e......... 193 6.4. Przerwa między fazą 1. a fazą 2. ...................................................e..................................................... 204 6.5. Faza 2.: ewaluacja szczegółowa ...................................................e....................................................... 204 6.5.1. Faza 2., etap 0.: przygotowanie do fazy 2. ...................................................e......................... 205 6.5.2. Faza 2., etapy od 1. do 6....................................................e....................................................... 207 6.5.3. Faza 2., etap 7.: „burza mózgów” i nadanie scenariuszom priorytetów.......................... 208 6.5.4. Faza 2., etap 8.: analiza podejść architektonicznych...................................................e......... 216 6.5.5. Faza 2., etap 9.: prezentacja rezultatów ...................................................e.............................. 220 6.6. Faza 3.: Działania uzupełniające...................................................e...................................................... 223 6.6.1. Faza 3., etap 1.: utworzenie raportu końcowego ...................................................e.............. 223 6.6.2. Faza 3., etap 2.: przeprowadzenie spotkania końcowego...................................................e 224 6.6.3. Faza 3., etap 3.: utworzenie teczki i aktualizacja repozytoriów danych .......................... 227 6.7. Dalsza lektura ...................................................e...................................................e.................................. 229 6.8. Pytania dyskusyjne ...................................................e...................................................e......................... 230 6 7 SPIS TREŚCI Wykorzystanie metody SAAM w ewaluacji przykładowej architektury ....231 7.1. Przegląd metody SAAM ...................................................e...................................................e................ 232 7.1.1. Dane wejściowe ewaluacji opartej na metodzie SAAM...................................................e... 232 7.1.2. Dane wyjściowe ewaluacji opartej na metodzie SAAM ...................................................e.. 233 7.2. Etapy ewaluacji opartej na metodzie SAAM...................................................e................................. 234 7.2.1. Etap 1.: opracowanie scenariuszy...................................................e........................................ 234 7.2.2. Etap 2.: opisanie architektur(y) ...................................................e............................................ 236 7.2.3. Etap 3.: sklasyfikowanie i nadanie priorytetów scenariuszom.......................................... 237 7.2.4. Etap 4.: indywidualna ocena scenariuszy pośrednich ...................................................e..... 238 7.2.5. Etap 5.: określenie interakcji scenariuszy ...................................................e...........................238 7.2.6. Etap 6.: utworzenie ewaluacji ogólnej ...................................................e................................239 7.3. Przykładowy program dzienny procesu ewaluacji metodą SAAM ............................................. 240 7.4. Analiza przypadku zastosowania metody SAAM ...................................................e....................... 241 7.4.1. Przegląd systemu ATAT ...................................................e....................................................... 242 7.4.2. Etap 1.: opracowanie scenariuszy, pierwsze przejście ...................................................e..... 243 7.4.3. Etap 2.: opis architektur(y), pierwsze przejście...................................................e................. 243 7.4.4. Etap 1.: opracowanie scenariuszy, drugie przejście ...................................................e......... 245 7.4.5. Etap 2.: opis architektur(y), drugie przejście ...................................................e..................... 246 7.4.6. Etap 3.: sklasyfikowanie i nadanie priorytetów scenariuszom.......................................... 248 7.4.7. Etap 4.: indywidualna ewaluacja scenariuszy pośrednich ................................................. 249 7.4.8. Etap 5.: określenie interakcji scenariuszy ...................................................e...........................249 7.4.9. Etap 6.: utworzenie ewaluacji ogólnej — rezultaty i zalecenia.......................................... 253 7.5. Podsumowanie ...................................................e...................................................e................................ 256 7.6. Dalsza lektura ...................................................e...................................................e.................................. 256 7.7. Pytania dyskusyjne ...................................................e...................................................e......................... 256 8 ARID — metoda ewaluacji architektur częściowych..................................259 8.1. Czynne przeglądy projektów...................................................e........................................................... 260 8.2. ARID: Hybryda metod ADR i ATAM ...................................................e............................................ 262 8.3. Etapy metody ARID ...................................................e...................................................e....................... 263 8.3.1. Faza 1.: próba ...................................................e...................................................e....................... 263 8.3.2. Faza 2.: przegląd...................................................e...................................................e.................. 264 8.4. Analiza przypadku zastosowania metody ARID ...................................................e......................... 266 8.4.1. Przeprowadzenie działań poszczególnych etapów...................................................e.......... 267 8.4.2. Rezultaty działań...................................................e...................................................e................. 269 8.5. Podsumowanie ...................................................e...................................................e................................ 270 8.6. Dalsza lektura ...................................................e...................................................e.................................. 270 8.7. Pytania dyskusyjne ...................................................e...................................................e......................... 271 9 Porównanie metod ewaluacji architektur oprogramowania .....................273 9.1. Techniki pytające...................................................e...................................................e............................. 274 9.1.1. Kwestionariusze i listy kontrolne ...................................................e........................................ 275 9.1.2. Scenariusze i metody oparte na scenariuszach ...................................................e................. 278 SPIS TREŚCI 7 9.2. Techniki pomiarowe ...................................................e...................................................e....................... 280 9.2.1. Miary ...................................................e...................................................e..................................... 281 9.2.2. Symulacje, prototypy i eksperymenty ...................................................e................................ 282 9.2.3. Analiza o stałym tempie ...................................................e....................................................... 283 9.2.4. Zautomatyzowane narzędzia i języki opisu architektur ...................................................e. 283 9.3. Techniki hybrydowe...................................................e...................................................e....................... 284 9.3.1. Inżynieria wydajności oprogramowania...................................................e............................ 284 9.3.2. Metoda ATAM...................................................e...................................................e..................... 285 9.4. Podsumowanie ...................................................e...................................................e................................ 285 9.5. Dalsza lektura ...................................................e...................................................e.................................. 290 9.6. Pytania dyskusyjne ...................................................e...................................................e......................... 290 10 Rozwijanie możliwości dokonywania ewaluacji architektudr we własnym przedsiębiorstwie ...................................................d...................291 10.1. Budowanie organizacyjnego zaangażowania...................................................e.............................. 291 10.2. Zwiększanie grona oceniających ...................................................e................................................... 292 10.3. Tworzenie zasobów zbiorczych...................................................e..................................................... 293 10.3.1. Dane o kosztach i korzyściach ...................................................e........................................... 294 10.3.2. Wskazówki dotyczące metod...................................................e............................................. 295 10.3.3. Elementy możliwe do wielokrotnego wykorzystania...................................................e.... 299 10.4. Podsumowanie ...................................................e...................................................e.............................. 300 10.5. Pytania dyskusyjne ...................................................e...................................................e....................... 301 11 Wnioski...................................................d...................................................d.........303 11.1. Można zaczynać! ...................................................e...................................................e........................... 303 11.2. Poznane metody...................................................e...................................................e............................ 304 11.3. Zasadność dokonywania ewaluacji architektur...................................................e.......................... 305 11.4. Przyczyny skuteczności metody ATAM ...................................................e...................................... 306 11.5. Uwagi końcowe...................................................e...................................................e............................. 312 A Przykład stylu architektonicznego opartego na atrybutach ......................313 A.1. Opis problemu...................................................e...................................................e................................ 313 A.2. Bodziec-odpowiedź ...................................................e...................................................e....................... 314 A.3. Styl architektoniczny ...................................................e........................................................................ 314 A.4. Analiza...................................................e...................................................e............................................. 314 A.4.1. Rozumowanie ...................................................e...................................................e..................... 315 A.4.2. Przypisanie priorytetów...................................................e....................................................... 316 A.4.3. Inwersja priorytetów ...................................................e............................................................ 316 A.4.4. Czas blokowania ...................................................e...................................................e................ 317 A.5. Dalsza lektura ...................................................e...................................................e................................. 318 Bibliografia...................................................d...................................................d...319 Skorowidz ...................................................d...................................................d....323 2 Ocena architektury oprogramowania Jeśli opracowujesz swoją architekturę w pośpiechu, możesz później tego żałować. — Barry Boehm fragment przemówienia: And Very Few Lead Bullets Either Kwestią o podstawowym znaczeniu jest określenie, czy dla danego oprogramowania wy- brano odpowiednią architekturę. Dokonanie odpowiedniego wyboru nie doprowadzi do katastrofy, ale raczej utoruje drogę do bezproblemowego rozwoju i w efekcie opracowa- nia udanego produktu. Jest to złożony problem i na obserwowane efekty działań ma wpływ wiele czynni- ków. Podstawą każdego systemu programistycznego jest jego architektura. To ona właśnie decyduje o możliwościach i ograniczeniach związanych z wszelkimi aspektami jakościo- wymi systemu. Modyfikowalność, wydajność, bezpieczeństwo, dostępność, niezawod- ność — wszystkie te cechy zostają określone po zdefiniowaniu architektury. W przy- padku systemu o nieprawidłowej architekturze właściwości tych nie poprawi żadne strojenie lub zastosowanie pewnych sztuczek implementacyjnych. Mówiąc wprost, architektura stanowi podstawę sukcesu danego systemu. Zapewne dużo lepiej jest z góry wiedzieć, czy dokonało się trafnych wyborów zamiast czekać niemal do momentu zakończenia prac nad systemem i dopiero wówczas mieć możli- wość określenia, czy spełnia on stawiane wymagania. Kupując system lub płacąc za jego opracowanie z pewnością warto posiadać pewne gwarancje, że od samego początku prace będą posuwać się w odpowiednim kierunku. Natomiast architekt bez wątpienia doceni możliwość weryfikacji własnych przeczuć i doświadczeń, co pozwoli mu na nabranie przeświadczenia, że zaufanie pokładane w utworzonym projekcie opiera się na solidnych podstawach. Do niedawna nie istniały niemal żadne ogólnoużytkowe metody służące do weryfikacji poprawności architektury oprogramowania. Stosowane sposoby oceniania, o ile w ogóle istniały, były niespójne, formułowane ad hoc i nie zapewniały powtarzalności wyników. Z tego względu nie były one zbyt wiarygodne. Okazuje się jednak, że można znaleźć lepsze rozwiązania. Niniejsza książka stanowi przewodnik po metodach oceny architektur oprogramo- wania. Jej treść oparto na zestawie trzech metod, które zostały opracowane w Software Engineering Institute i które mogą znaleźć zastosowanie w przypadku każdego systemu intensywnie wykorzystującego oprogramowanie: 40 2. OCENA ARCHITEKTURY OPROGRAMOWANIA • metoda analizy kompromisów architektury (ATAM, Architecture Tradeoff Analysis • metoda analizy architektury oprogramowania (SAAM, Software Architecture Analysis • aktywne przeglądanie projektów pośrednich (ARID, Active Reviews for Intermediate Method); Method); Designs). Wszystkie z wymienionych metod mają solidne podstawy i były stosowane przez lata w przypadku dziesiątków projektów o różnym poziomie złożoności oraz w szero- kim zakresie obszarów zainteresowania. Dzięki nim jasnym się stało, że nadszedł czas, aby ewaluacja architektury oprogramowania stała się jednym ze standardowych etapów każdego paradygmatu konstrukcyjnego. Tego rodzaju oceny stanowią rozsądny sposób zmniejszania ryzyka i są względnie niedrogie. Rekompensatę za włożony wysiłek sta- nowi możliwość uniknięcia kosztownych błędów i nieprzespanych nocy. W poprzednim rozdziale przedstawiono zarys pojęcia architektury oprogramowania, w niniejszym zaś zostaną zaprezentowane podstawowe wiadomości dotyczące oceny archi- tektur. Zdefiniowano tu pojęcie architektury oprogramowania oraz omówiono właściwości, pod względem których można (lub nie można) dokonywać oceny danej architektury. W pierwszej kolejności należy zdefiniować przedmiot oceny: Architektura oprogramowania danego programu lub systemu informatycznego to struktura lub struktury systemu, które obejmują komponenty programowe, widoczne na zewnątrz właściwości tych komponentów oraz istniejące między nimi relacje. [Bass 98] Przez właściwości „widoczne na zewnątrz” należy tu rozumieć założenia, które mogą przyjmować inne komponenty względem danego komponentu, na przykład w kwestii oferowanych przez niego usług, charakterystyk wydajnościowych, obsługi błędów, wyko- rzystanie zasobów współużytkowanych i tak dalej. Powyższa definicja sugeruje, że archi- tektura oprogramowania musi abstrahować od pewnych informacji dotyczących systemu (w przeciwnym wypadku nie miałoby sensu zajmowanie się architekturą — byłoby to po prostu badanie systemu jako całości), ale jednocześnie zapewniać taką ilość informacji, aby mogły one stanowić podstawę przeprowadzanych analiz, podejmowanych decyzji, a przez to redukcji ryzyka (patrz ramka Co jest związane z architekturą oprogramowania?). Architektura definiuje komponenty (takie jak moduły, obiekty, procesy, podsystemy, jednostki kompilacji i tak dalej) oraz odpowiednie, występujące między nimi zależności (takie jak wywołania, przesyłanie danych, mechanizmy synchronizacji, użycia, zależności, konkretyzacje i wiele innych). Architektura jest rezultatem wczesnych decyzji projektowych, których podjęcie jest niezbędne, aby możliwe stało się wspólne skonstruowanie przez grupę ludzi systemu programistycznego. Im większa lub bardziej rozproszona jest owa grupa, tym większego znaczenia nabiera architektura (należy jednak podkreślić, że grupa ta wcale nie musi być bardzo duża, aby architektura oprogramowania stała się istotna). Jedną z uwag, dotyczących architektury z rozdziału 1., którą Czytelnik musi w pełni zrozumieć, zanim metody jej oceny staną się jasne, jest poniższa: Architektura decyduje o istnieniu lub braku niemal wszystkich atrybutów jakościowych danego systemu. 2.1. CELE DOKONYWANIA OCENY ARCHITEKTURY 2. OCENA ARCHITEKTURY OPROGRAMOWANIA 41 Prowadzi to do sformułowania podstawowej zasady dotyczącej oceny architektur: skoro decyzje związane z architekturą determinują atrybuty jakościowe systemu, moż- liwa staje się ocena tych decyzji pod względem ich wpływu na owe atrybuty. Co jest związane z architekturą? Wcześniej czy później każdy zadaje pytanie: co należy do architektury? Niektórzy za- dają sobie to pytanie z intelektualnej ciekawości, jednak w przypadku osób odpo- wiedzialnych za ocenianie architektur jest to raczej paląca potrzeba zrozumienia, jakie informacje stanowią dane wejściowe, a jakie wyjściowe w procesie, którym się zajmują. Pytanie to można przeformułować, na przykład do postaci przedstawio- nych poniżej: • Jaka różnica istnieje między architekturą a projektem wysokiego poziomu? • Czy szczegóły, takie jak priorytety procesów, także są związane z architekturą? • Dlaczego kwestie implementacyjne, takie jak przepełnienia bufora, powinny być traktowane jako związane z architekturą? • Czy interfejsy komponentów stanowią część architektury? • Jeśli jest się w posiadaniu diagramów klas, czy jest potrzebne cokolwiek więcej? • Czy architektura jest związana z działaniami fazy wykonania, czy też jest struk- turą statyczną? • Czy system operacyjny stanowi część architektury? A język programowania? • Jeśli jest się zmuszonym do używania konkretnego produktu komercyjnego, to czy jest on częścią architektury? Jeśli ma się swobodę w zakresie wyboru spośród szerokiej gamy produktów komercyjnych, to czy jest to część architektury? Istnieją dwa sposoby rozważania tego zagadnienia. Po pierwsze, warto przyjrzeć się definicji architektury podanej w rozdziale 1. Parafrazując: architektura oprogramowania jest związana z ogólną organizacją sys- temu opisanego pod względem tworzących go komponentów, ich widocznych na zewnątrz właściwości oraz istniejących między nimi zależności. Oczywiście, definicja ta jest jak najbardziej prawidłowa, jednak nie obejmuje ona w sposób bezpośredni koncepcji kontekstu. Jeśli obszar bieżącego zainteresowania ogranicza się do pod- systemu systemu, stanowiącego część systemu systemów, wówczas to, co postrzega się jako związane z architekturą będzie różne od analogicznego przedmiotu zainte- resowania architekta systemu systemów. Stąd też kontekst ma ogromny wpływ na to, co jest związane z architekturą. Po drugie, można zapytać, co nie jest związane z architekturą. Jak stwierdzono, algorytmy nie stanowią części architektury. Podobnie jest ze strukturami danych lub szczegółami dotyczącymi przepływu danych. Ponownie okazuje się jednak, że powyższe uwagi są tylko częściowo poprawne. Niektóre cechy algorytmów, takie jak ich złożoność, mogą mieć ogromny wpływ na wydajność. Niektóre z cech struktur danych, na przykład fakt, czy muszą umożliwiać dostęp współbieżny, w bezpośredni sposób wpływają na wydajność i niezawodność. Pewne szczegóły dotyczące przepływu 42 2. OCENA ARCHITEKTURY OPROGRAMOWANIA danych, takie jak zależności komponentów od komunikatów o określonym typie lub kwestia dostępu określonych komponentów do określonych typów danych, wpły- wają, odpowiednio, na modyfikowalność oraz poziom zabezpieczeń systemu. Pojawia się zatem pytanie, czy istnieje ogólna reguła, którą można by wyko- rzystać w celu określenia elementów związanych z architekturą. Aby sformułować taką zasadę, można odwołać się do sposobów wykorzystania architektury. Przyjęte kryterium istnienia związku danego element z architekturą będzie następujące: musi być to albo komponent, albo relacja pomiędzy komponentami, albo właściwości (komponentów lub relacji), które muszą być widoczne na zewnątrz, aby umożliwić wartościowanie systemu pod względem spełniania stawianych wobec niego wymagań dotyczących jakości lub wspieranie dekompozycji systemu na elementy możliwe do niezależnego wdrażania. Poniżej wymieniono kilka wniosków, jakie można wysnuć na podstawie tej reguły: • Architektura opisuje zawartość systemu. Po określeniu bieżącego kontekstu użyt- kownik określa jednocześnie granicę, która precyzuje elementy wchodzące oraz niewchodzące w skład danego systemu (który może stanowić jednocześnie podsystem innego użytkownika). Architektura opisuje te elementy, które wchodzą w skład systemu. • Architektura stanowi abstrakcyjny opis danego systemu. Informacje, które niesie ze sobą architektura to najbardziej abstrakcyjny, a jednocześnie znaczący opis danej postaci systemu. Posiadanie specyfikacji danej architektury powinno elimino- wać konieczność sporządzania bardziej abstrakcyjnego opisu. Nie oznacza to, że wszystkie aspekty danej architektury są abstrakcyjne, ani że istnieje pewna wartość graniczna poziomu abstrakcji, którą należy przekroczyć w celu uznania danego elementu projektu za część architektury. Nie należy przejmować się faktem, że pewna architektura sięga do detalów, które inni mogą uważać za część bardziej szczegółowego projektu. • Elementy związane z architekturą oprogramowania powinny stanowić główne kryte- rium decydowania o najważniejszych wymaganiach. Architektura stanowi pomost łączący zdefiniowane wymagania z całą resztą danego projektu. Jeśli projek- tant stwierdza, że pewne informacje mają podstawowe znaczenie pod wzglę- dem definiowania stopnia spełniania przez system stawianych mu wymagań, wówczas stają się one częścią architektury. Architekt jest tu najlepszym sędzią. Z drugiej strony, jeśli okazuje się, że pewne szczegóły można wyeliminować, a i tak poprzez modelowanie, symulacje, przeglądy i inne podobne działania wciąż można w przekonujący sposób pokazać, że dana architektura spełnia kluczowe wymagania, wówczas szczegóły takie do architektury nie należą. Jednakże, jeśli architektura zawiera zbyt wiele szczegółów, to może okazać się, że nie spełnia kolejnej reguły. • Specyfikacja architektury powinna być zrozumiała. Istota stosowania opisu systemu na poziomie globalnym polega na tym, że można go zrozumieć i wyciągać na tej podstawie pewne wnioski. Zbyt duża liczba szczegółów stanowi w tym wzglę- dzie dużą przeszkodę. 2. OCENA ARCHITEKTURY OPROGRAMOWANIA 2.1. CELE DOKONYWANIA OCENY ARCHITEKTURY 43 • Architektura wprowadza ograniczenia. Nakłada ona wymagania na wszelkie nisko- poziomowe specyfikacje projektowe. Warto wprowadzić w tym miejscu rozróż- nienie na proces podejmowania decyzji oraz faktycznej ich realizacji. Przykła- dowo, w trakcie projektowania architektury można określić strategię ustalania priorytetów procesów, strategię redukcji nadmiarowości komponentów lub zbiór reguł hermetyzacji. Jednak faktycznie przez dość długi czas można by nie podejmować żadnych działań związanych z przydzieleniem priorytetów, nie zdefiniować żadnego algorytmu służącego do obliczeń określających nadmia- rowość ani nie określić szczegółów interfejsu. Mówiąc w skrócie: To, co stanowi część architektury, jest najbardziej abstrakcyjnym odwzorowaniem systemu, które pozwala na wyciąganie wniosków związanych z najważniejszymi wymaganiami oraz determinuje wszelkie wprowadzane w przyszłości udoskonalenia. Jeśli Czytelnik odnosi wrażenie, że odkrycie wszystkich cech danego systemu, które są związane z architekturą jest zadaniem niełatwym, to ma rację. Jest mało praw- dopodobne, że od razu uda się odnaleźć wszystkie elementy związane z architekturą, a poza tym raczej nie warto się o to starać. Specyfikacja architektury ewoluuje z upływem czasu, co jest jedną z konsekwencji stosowania opisanych reguł w celu określenia elementów składowych architektury. — MHK 2.1. Cele dokonywania oceny architektury Im wcześniej udaje się znaleźć problem związany z projektem programistycznym, w tym lepszej jest się sytuacji. Koszt naprawienia błędu odkrytego w czasie definiowania wyma- gań lub wczesnych faz projektowania jest o rzędy wielkości niższy, niż ma to miejsce w przypadku tego samego błędu odnalezionego w trakcie testowania. Architektura oprogramowania stanowi efekt wczesnych faz projektowania i jej wpływ na system oraz projekt jest znaczny. Nieodpowiednia architektura przyspiesza załamanie się projektu. W takiej sytuacji nie da się osiągnąć celów związanych z wydajnością. Także cele związane z zapewnie- niem bezpieczeństwa nie zostaną osiągnięte. Klient zacznie się niecierpliwić, kiedy pewne schematy działania będą niedostępne, zaś dodanie ich do systemu okaże się zbyt trudne. Harmonogramy i budżety staną się nieaktualne, gdyż zespół konstrukcyjny będzie zmu- szony do pokonywania licznych problemów. Po upływie miesięcy lub lat będzie trzeba zrezygnować ze zmian, które można było przewidzieć i zaplanować, ponieważ wówczas będą już wiązać się ze zbyt dużymi kosztami. Chyba trudno jest sobie wyobrazić gorszy scenariusz. 44 2. OCENA ARCHITEKTURY OPROGRAMOWANIA Architektura oprogramowania determinuje również strukturę projektu: biblioteki kontroli konfiguracji, harmonogramy i budżety, cele wydajnościowe, struktura zespołu, organizacja dokumentacji, a także działania związane z testowaniem oraz konserwacją — wszystkie one są zorganizowane wokół architektury. Jeśli główny schemat działania musi ulec zmianie wskutek pewnych późno odkrytych wad, to może się okazać, że w całym projekcie zapanuje chaos. Znacznie lepiej jest zmienić architekturę zanim zostanie już ona poddana procesowi realizacji. Ocena architektury stanowi mało kosztowny sposób uniknięcia poważnych proble- mów. Metody opisane w niniejszej książce mają w zamierzeniu być stosowane w sytu- acji, gdy architekturę stanowi tylko specyfikacja zapisana na papierze (oczywiście mogą jednak być stosowane także w późniejszym okresie) i polegają na wykonaniu serii pro- stych, ale przemyślanych eksperymentów. Wszystkie wymagają wspólnej pracy głów- nych zainteresowanych w formie przemyślanych sesji „burzy mózgów”, prezentacji oraz analiz. Ogólnie rzecz biorąc dokonanie oceny architektury oznacza zazwyczaj dodanie do harmonogramu projektu nie więcej niż kilku dni. Ujmując rzecz nieco inaczej — gdyby Czytelnik budował dom, z pewnością nie roz- począłby odpowiednich działań konstrukcyjnych przed dokładnym zapoznaniem się z planami. Nikt nie zawaha się poświęcić pewnego dodatkowego czasu w tym celu, ponie- waż jest oczywiste, że znacznie lepiej jest odkryć brak sypialni w momencie, gdy archi- tektura opiera się wyłącznie na planach, nie zaś w dniu przeprowadzki. 2.2. Moment dokonywania oceny architektury Klasyczny przypadek oceny architektury istnieje w sytuacji, gdy architektura została już określona, ale nie rozpoczęto jeszcze procesu jej wdrażania. Użytkownicy iteracyjnych lub przyrostowych modeli okresu użytkowania mogą oceniać decyzje dotyczące architektury podjęte w trakcie ostatniego cyklu. Jedną z istotnych cech metod oceny architektury jest jed- nak fakt, że można je stosować w dowolnym stadium istnienia danej architektury. Ist- nieją dwie użyteczne odmiany metody klasycznej: wczesna oraz późna. Odmiana wczesna. Z oceną wcale nie trzeba czekać do momentu pełnego określenia danej architektury. Z metody tej można korzystać na dowolnym etapie procesu tworzenia architektury w celu zbadania już podjętych decyzji projektowych oraz dokonywania wyboru spośród dostępnych opcji architektonicznych, które wciąż nie zostały rozstrzy- gnięte. Znaczy to tyle, że w takim samym stopniu nadaje się ona do oceniania decyzji architektonicznych, które już podjęto, jak i tych, które są dopiero rozważane. Oczywiście, zupełność oraz dokładność oceny są bezpośrednio zależne od zupełności i dokładności opisu architektury utworzonego przez architekta. W praktyce koszty oraz wysiłek logistyczny związane z przygotowaniem pełnej ewaluacji są rzadko podejmowane, jeśli stan przygotowania architektury oprogramowania nie uzasadnia takich działań. Nie jest po prostu opłacalne zebranie kilkunastu lub kilkudziesięciu osób bezpośrednio zainte- resowanych projektem oraz analityków po to, aby dokonali oceny wstępnych notatek architekta zapisanych na skrawku papieru, nawet jeśli tego rodzaju notatki dają w rze- czywistości pogląd na wiele istotnych ścieżek projektowych — takich, które obrano oraz takich, które odrzucono. 2.2. MOMENT DOKONYWANIA OCENY ARCHITEKTURY 45 Niektóre instytucje zalecają stosowanie tak zwanego przeglądu odkryć (ang. discovery review), który stanowi w istocie bardzo wczesny proces wstępnej oceny. Jego celem jest zarówno osiągnięcie porozumienia oraz ustalenie priorytetów związanych z kłopotli- wymi wymaganiami, jak również dokonanie analizy utworzonego dotąd prototypu archi- tektury. W przypadku przeglądu odkryć grupa uczestników jest mniej liczna, ale muszą do niej należeć osoby upoważnione do podejmowania decyzji związanych ze stawianymi wymaganiami. Celem takiego spotkania jest rozpatrzenie wszelkich wątpliwości, jakie może mieć architekt w związku z koniecznością zapewnienia spełniania przez daną archi- tekturę połączonych wymagań. Wymagania te dotyczą kwestii jakościowych oraz zwią- zanych z zachowaniem systemu i są narzucane w momencie, kiedy wciąż jeszcze jest czas na to, aby złagodzić te najbardziej kłopotliwe lub najmniej istotne. Efektem przeglądu odkryć jest znacznie bardziej uściślony zbiór wymagań oraz opis wstępnych działań mających zapewnić ich spełnienie. Taki opis, po bliższym sprecyzowaniu, może stanowić w przyszłości przedmiot pełnej oceny. Przeglądy odkryć nie zostaną w tym miejscu szczegółowo opisane, ponieważ stanowią one jedynie pewną odmianę metod oceny architektury. Jeśli działanie takie ma mieć miejsce, należy zapewnić, aby: • odbyło się zanim stawiane wymagania zostaną definitywnie określone oraz kiedy architekt ma dobry pomysł dotyczący rozwiązania problemu; • w grupie uczestników znajdowała się osoba upoważniona do podejmowania decyzji związanych ze stawianymi wymaganiami; • w materiałach końcowych wyszczególniono zbiór wymagań z uwzględnieniem ich priorytetów, jeśli nie istnieje żaden oczywisty sposób zapewnienia spełnienia ich wszystkich. W przypadku przeglądu odkryć warto także mieć w pamięci słowa słynnego pro- jektanta samolotów, Willy’ego Messerschmitta, któremu nieobce były problemy związane ze stawianiem wymaganiami: Można spełnić wszelkie życzenia Ministerstwa Lotnictwa dotyczące uwzględnienia dodat- kowych możliwości, pod warunkiem jednak, że zrezygnuje się z wymagania, aby projek- towany samolot latał. Odmiana późna. Druga odmiana znajduje zastosowanie w momencie, gdy nie tylko określono architekturę, ale zakończono także sam proces wdrażania. Przypadek taki ma miejsce w sytuacji, gdy instytucja dziedziczy pewien istniejący system. Mógł on zostać kupiony na rynku lub utworzony na podstawie własnych materiałów archiwalnych. Techni- ki oceniania architektury już istniejącej (ang. legacy architecture) nie różnią się od tych, które stosuje się w przypadku architektury nowo powstającej. Proces oceny jest poży- teczny ze względu na fakt, że pomaga nowym właścicielom systemu w jego zrozumieniu i pozwala im na sprawdzenie, czy można na nim polegać w zakresie spełnienia stawia- nych wymagań jakościowych i zachowaniowych. Pojawia się w tym momencie pytanie natury ogólnej, dotyczące tego, kiedy można przeprowadzić proces oceny architektury. Najlepiej wówczas, gdy utworzona dotąd struktura architektury uzasadnia takie działanie. Różne instytucje mogą w różny sposób 46 2. OCENA ARCHITEKTURY OPROGRAMOWANIA definiować kryteria takiej zasadności, jednak przydatna praktyczna zasada brzmi: proces oceniania należy przeprowadzić wówczas, gdy zespół konstrukcyjny zaczyna podejmo- wać decyzje, które uwarunkowane są architekturą, zaś koszt ewentualnego anulowania tych decyzji przewyższałby koszty związane z przeprowadzeniem oceny. 2.3. Zainteresowane strony Można wyróżnić dwie grupy osób związanych z przeprowadzaniem oceny architektury. (1) Zespół oceniający. Są to osoby odpowiedzialne za proces oceniania oraz przeprowadzenie analiz. Członkowie zespołu oraz szczegółowy opis ich zadań zostaną opisane w dalszej części niniejszego rozdziału. Na razie wystarczy powiedzieć, że reprezentują oni po prostu jedną z grup uczestników. (2) Główni zainteresowani. Głównymi zainteresowanymi (ang. stakeholders) są osoby, które wniosły pewien kapitał w rozwój architektury oraz systemu budowanego na jej pod- stawie. We wszystkich trzech metodach oceniania, które opisano w niniejszej książce, osoby te mają za zadanie wyrażać określone wymagania stawiane wobec architektury. Nie dotyczy to wymagań, które definiują oczekiwany sposób działania systemu. Nie- którzy zainteresowani są członkami zespołu konstrukcyjnego: koderzy, integratorzy, testerzy, konserwatorzy i tak dalej. Z przeprowadzeniem oceny architektury w szczególny sposób są związane osoby odpowiedzialne za podejmowanie decyzji projektowych. Są to osoby zainteresowane wynikami procesu oceny. Posiadają one uprawnienia do podejmowania decyzji i mają wpływ na przyszły kształt projektu. Należą do nich architekci, projektanci kompo- nentów oraz kierownictwo projektu. Kierownictwo jest odpowiedzialne za podejmo- wanie decyzji dotyczących reakcji na problemy odkryte w wyniku oceny. W przypadku pewnych ustaleń (szczególnie jeśli chodzi o projekty rządowe), osobą odpowiedzialną za podejmowanie decyzji projektowych może być również klient lub sponsor. Zwykły zainteresowany wyraża swoje życzenia dotyczące powstającej archi- tektury, z kolei osoba odpowiedzialna za podejmowanie decyzji ma możliwość takiego zadysponowania zasobami, aby można było je urzeczywistnić. Tak więc kierownik projektu może (jako zainteresowany) stwierdzić: „Chciałbym, aby architektura była możliwa do ponownego wykorzystania w innym podobnym projekcie, którym kie- ruję”. Z kolei jako osoba odpowiedzialna za podejmowanie decyzji może stwierdzić: „Z moich obserwacji wynika, że zmiany, których wprowadzenie zidentyfikowano jako konieczne do zapewnienia możliwości ponownego wykorzystania architektury w moim drugim projekcie są zbyt kosztowne i dlatego nie mogę na nie pozwolić”. Inna różnica polega na tym, że osoby odpowiedzialne za podejmowanie decyzji pro- jektowych są upoważnione do autorytatywnego wypowiadania się w kwestii pro- jektu i, przykładowo, niektóre etapy metody ATAM bezpośrednio tego od nich wymagają. Z drugiej strony, zwykli zainteresowani mogą jedynie mieć nadzieję, że będą mieć wpływ (choć na pewno nie będzie to równoznaczne z podjęciem decyzji) na projekt. Więcej informacji na ten temat zawiera ramka Główni zainteresowani na stronie 85. w rozdziale 3. 2.4. REZULTATY PROCESU OCENY ARCHITEKTURY 47 Beneficjentem procesu oceny architektury zwykle jest osoba odpowiedzialna za po- dejmowanie decyzji projektowych, bezpośrednio zainteresowana wynikami oceny oraz posiadająca pewną kontrolę nad projektem. Czasem zespół oceniający składa się z pracowników związanych z projektem, w której to sytuacji są oni jednocześnie zainteresowanymi systemem. Nie jest to jednak zalecany schemat działania, ponieważ będzie im wówczas brak obiektywizmu w kwestii oceny architektury. 2.4. Rezultaty procesu oceny architektury Mówiąc konkretnie, efektem procesu oceny architektury oprogramowania jest sporządzenie raportu, którego forma i zawartość zależą od wykorzystanej metody. Dodatkowym re- zultatem oceny architektury jest także uzyskanie pewnych informacji. W szczególności chodzi tu o odpowiedzi na dwa rodzaje pytań. (1) Czy dana architektura jest odpowiednia dla systemu, dla którego została zaprojek- towana? (2) Która z dwóch lub większej liczby konkurencyjnych architektur najlepiej odpowia- da wymaganiom danego systemu? Badaniu podlega przydatność architektury oprogramowania do wykonania danego zadania. Jest ona odpowiednia, jeśli spełnia dwa kryteria. (1) System zbudowany na jej podstawie spełni stawiane mu cele jakościowe. Oznacza to, że system będzie pracował w sposób przewidywalny oraz wystarczająco szybko, aby mógł spełniać wymagania czasowe (ang. timing). Będzie mógł być modyfikowany w zaplanowany sposób. Będzie zgodny z nałożonymi ograniczeniami dotyczącymi zabezpieczeń. Będzie oferował wymagane funkcje definiujące sposób zachowania. Nie każda jakościowa cecha systemu stanowi bezpośredni rezultat jego architektury, ale w wiele przypadkach tak właśnie jest. Architektura jest odpowiednia wówczas, gdy zapewnia odpowiedni plan budowy systemu, który będzie się charakteryzował tymi cechami. (2) System można zbudować z wykorzystaniem dostępnych zasobów: zespołu pracow- ników, budżetu, istniejącego oprogramowania (jeśli takie jest) oraz w wyznaczonym czasie. Oznacza to, że architektura umożliwia jego zbudowanie. Tak zdefiniowane pojęcie odpowiedniości (ang. suitability) określać sferę zaintereso- wania dalej prezentowanych materiałów. Wynika z niego kilka istotnych implikacji. Po pierwsze, odpowiedniość ma zastosowanie tylko w kontekście określonych (i bezpo- średnio wyrażonych) celów stawianych architekturze i tworzonemu na jej podstawie systemowi. Architektura, którą zaprojektowano mając na względzie głównie kwestie wydaj- ności, może dać w efekcie system, który działa bardzo szybko, ale wymaga miesięcy pracy całych zespołów programistów w przypadku konieczności wprowadzenia do niego pew- nych modyfikacji. Gdyby to właśnie modyfikowalność była dla takiego systemu ważniejsza 48 2. OCENA ARCHITEKTURY OPROGRAMOWANIA od wydajności, wówczas architektura ta byłaby nieodpowiednia (choć mogłaby stanowić podstawę dla jeszcze innej). W książce Alicja w Krainie Czarów Alicja spotyka Kota z Cheshire i pyta go o drogę. Kot odpowiada, że zależy to od miejsca, do którego chce się udać. Alicja mówi, że nie wie, na co kot odpowiada, że w takim razie nie ma znaczenia, gdzie się skieruje. A zatem: Jeśli osoba za to odpowiedzialna nie potrafi określić żadnych celów jakościowych, jakie należy postawić systemowi, wówczas zadanie to spełni dowolna architektura. Najważniejszą częścią procesu oceny architektury jest zidentyfikowanie i nadanie prio- rytetów określonym wymaganiom, które dana architektura musi spełniać. W sytuacji idealnej wszystkie wymagania zostałyby określone w odpowiednim dokumencie, jednak koncepcja taka nie sprawdza się z dwóch powodów. Po pierwsze, kompletne i aktualne dokumenty definiujące wymagania nie zawsze istnieją, a po drugie, dokumenty takie określają wymagania dotyczące systemu. W przypadku architektury oprogramowania oprócz uwzględnienia wymagań stawianych systemowi nakładane są także pewne dodat- kowe wymagania (jako przykład można w tym miejscu podać możliwość zbudowania — ang. buildability). Drugim wnioskiem wynikającym z oceny odpowiedniości architektury jest fakt, że odpowiedź wynikająca z przeprowadzonej ewaluacji nie jest pewnego rodzaju rezultatem skalarnym, który można by już znać na podstawie przeprowadzonych ocen innego rodzaju artefaktów programistycznych. W przeciwieństwie do, przykładowo, metryki kodu (ang. code metrics), w którym to przypadku poszukiwana odpowiedź mogłaby stwier- dzać, że wartość 7,2 oraz każda inna większa od 6,5 jest nie do zaakceptowania, ewalu- acja architektury daje w wyniku bardziej dogłębne rezultaty. Nie istnieje potrzeba precyzyjnego charakteryzowania jakiegokolwiek atrybutu jako- ściowego (stosując miary, takie jak czas do awarii lub średni całościowy czas opóźnienia). Byłoby to działaniem pozbawionym sensu we wczesnej fazie projektowania, ponieważ fak- tyczne parametry, które determinują te wartości (na przykład faktyczny czas wykonania danego komponentu) są często zależne od implementacji. To, co należy zrobić — w atmosfe- rze działań mających na celu uniknięcie ryzyka — to określenie punktu, w którym na badany atrybut oddziałują decyzje projektowe związane z architekturą. Ma to umożliwić dokładne przeanalizowanie tych decyzji, ich bardziej szczegółowe wymodelowanie w trakcie później- szych analiz, a także spowodować poświęcenie większej ilości wysiłku związanego z pro- jektowaniem, analizą oraz tworzeniem prototypów przy podejmowaniu takich decyzji. Ocena architektury oprogramowania mówi o tym, że dana architektura okazała się być odpowiednią pod względem jednego zestawu zakładanych celów oraz problema- tyczna pod względem innego zestawu. Czasem cele takie są wobec siebie przeciwstawne lub przynajmniej pewne cele będą ważniejsze od innych. Kierownik projektu będzie zmuszony do podejmowania pewnych decyzji, jeśli okaże się, że ocena architektury jest pozytywna pod pewnymi względami, a pod innymi negatywna. Czy kierownik może pozwolić sobie na akceptowanie stanu charakteryzującego się określonymi słabościami? Czy można architekturę umocnić w tych obszarach? A może należy podjąć decyzję o rozpoczęciu prac nad projektem od początku? Ewaluacja pomaga w określaniu sła- bych punktów architektury, ale porównanie kosztów i korzyści związanych z projektem ulepszenia architektury stanowi całkowicie funkcję kontekstu danego projektu i znajduje się w rękach kierownictwa. Tak więc: 2.4. REZULTATY PROCESU OCENY ARCHITEKTURY 49 Dlaczego należy w to wierzyć? Często osoba zajmująca się metodami oceniania jest traktowana jako outsider. Może zostać wynajęta przez lidera projektu, kierownika lub klienta w celu dokonania oce- ny projektu. Może to być postrzegane jako działania audytorskie lub po prostu element działań zmierzających do ulepszenia metod inżynierii programowania w danej jednostce organizacyjnej. Bez względu na przyczynę, o ile proces oceniania nie jest częścią długoterminowych założeń, specjalista nie zna zazwyczaj osobiście archi- tekta albo głównych zainteresowanych. Czasem taki wzajemny dystans nie stanowi problemu — uczestnicy są otwarci i podchodzą do problemu z entuzjazmem, są chętni do nauki oraz ulepszania swoich architektur. Jednak w pewnych sytuacjach można się spotkać ze swego rodzaju opo- rem, a nawet obawami. Główni zainteresowaniu siedzą wówczas z rękami skrzyżo- wanymi na piersiach, najwyraźniej rozdrażnieni, że odciąga się ich od zasadniczej pracy związanej z projektowaniem architektury i zmusza do zajmowania „tymi głupimi” ocenami nadzorowanymi przez kierownictwo. W jeszcze innych sytuacjach są nastawieni przychylnie, jednak wykazują duży sceptycyzm. Są oni wszakże eks- pertami w swoich dziedzinach i nad danym zagadnieniem lub nawet konkretnym system pracują od lat. W każdym bądź razie ich nastawienie, czy to przychylne, czy wrogie, wyka- zuje znaczną ilość sceptycyzmu w kwestii szans, że ewaluacja konkretnej architek- tury może faktycznie okazać się pomocną. W efekcie mówią oni: „Co, czego sami nie wiemy, może nam powiedzieć o naszym własnym systemie grupa specjalistów z zewnątrz?”. Prawdopodobnie każdemu specjaliście ds. oceny architektur zdarzy się kiedyś zmierzyć z tego rodzaju opozycją lub oporem. Należy pamiętać o dwóch sprawach w przypadku konieczności przeciwdzia- łania takiej opozycji. Po pierwsze, należy przezwyciężyć obawy. Dlatego też należy zachować spokój. Jeśli będzie się przyjaznym i pozwoli oponentom zrozumieć, że celem spotkania jest poznanie i ulepszenie architektury (nie zaś obwinianie kogo- kolwiek), wówczas okaże się, że ich opór szybko zacznie słabnąć. W rzeczywistości większość ludzi bawi proces ewaluacji i bardzo szybko dostrzegają oni wynikające z niego korzyści. Po drugie, należy przezwyciężyć sceptycyzm. Oczywiście człon- kowie zespołu są ekspertami w swojej dziedzinie. Wie o tym oceniający i wiedzą to oni sami, więc warto z góry to podkreślić. Jednak oceniający jest ekspertem w zakresie architektury oraz atrybutów jakościowych. Bez względu na dziedzinę zaintereso- wania, podejścia architektoniczne służące do usprawniania zarządzania oraz analizy atrybutów jakościowych nie podlegają zbytnim zmianom. Istnieje stosunkowo nie- wiele sposobów podejścia do zagadnień wydajności, dostępności lub bezpieczeństwa na poziomie architektonicznym. Doświadczony specjalista w zakresie ewaluacji (z po- mocą społeczności specjalistów w zakresie atrybutów jakościowych) spotyka się z nimi niejednokrotnie i nie zmieniają się one zbytnio przy przechodzeniu z jednej dziedziny do drugiej. Ponadto, jako człowiek z zewnątrz, oceniający przynosi ze sobą świeże spojrzenie i choćby tylko ten jeden fakt często może pozwolić na odkrycie nowej cechy projektu. Oceniający postępuje zgodnie z regułami procesu, który był udoskonalany w trakcie 50 2. OCENA ARCHITEKTURY OPROGRAMOWANIA przeprowadzania dziesiątków ewaluacji dotyczących dziesiątków różnych dziedzin wiedzy bądź techniki. Był on udoskonalany w celu umożliwienia wykorzystania doświadczeń wielu osób, w celu odkrycia, udokumentowania i skontrolowania wyma- gań dotyczących atrybutów jakościowych oraz informacji o architekturze. Już nawet tylko to może przynieść korzyści danemu projektowi — nie raz już się tak zdarzyło. Cały proces po prostu funkcjonuje poprawnie! — R.K. Ewaluacja architektury nie daje odpowiedzi typu „tak” lub „nie”, „dobrze” lub „źle”, czy też „6,75 z 10”. Mówi raczej, gdzie czyhają pewne niebezpieczeństwa. Ewaluacja architektury może być wykorzystana wobec pojedynczej architektury lub całej grupy współzawodniczących architektur. W tym drugim przypadku może pomóc w odkryciu silnych i słabych punktów każdej z nich. Oczywiście można założyć, że żadna architektura nie zdobędzie oceny lepszej od wszystkich innych pod każdym względem. Raczej każda z nich otrzyma lepsze oceny pod jednymi względami, zaś pod innymi gor- sze w porównaniu z pozostałymi architekturami. Proces ew
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Architektura oprogramowania. Metody oceny oraz analiza przypadków
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ą: