[ Pobierz całość w formacie PDF ]
mechanizmów pomocy. Przyk adowo wiedza o tym, e zdania rozpoczyna si zazwyczaj wielk liter , pozwala aplikacji korygowa zdania, w których u ytkownik nie dostosowa si do tej regu y. Utrzymywanie modelu u ytkownika. Model u ytkownika s u y do okre lania jego zna- jomo ci systemu, jego zachowa w kategoriach oczekiwanego czasu reakcji lub innych charakterystyk specyficznych dla pewnej osoby czy klasy osób. Przyk adem zastosowania modelu u ytkownika jest dopasowanie szybko ci przewijania do szybko ci czytania. Utrzymywanie modelu systemu. Model systemu s u y do okre lania oczekiwanego za- chowania systemu po to, by przekaza odpowiednie informacje zwrotne u ytkownikowi. Jest to na przyk ad oszacowanie czasu potrzebnego do sko czenia bie cej operacji. Taktyki dla czasu projektowania Procedury testowania wi si cz sto z wieloma zmianami w interfejsie u ytkownika spe- cjalista zajmuj cy si funkcjonalno ci regularnie przekazuje programistom poprawki do bie- cego projektu interfejsu, a ci wprowadzaj odpowiednie zmiany. W usprawnieniu tego schematu pomaga taktyka, która jest specjalizacj opisanej wcze niej taktyki spójno ci semantycznej: 128 5. UZYSKIWANIE ATRYBUTÓW JAKO CIOWYCH Oddzielenie interfejsu u ytkownika od reszty aplikacji. Lokalizacja oczekiwanych zmian jest g ównym uzasadnieniem spójno ci semantycznej. Poniewa interfejs u ytkow- nika ulega cz stym zmianom zarówno przed wdro eniem, jak i po nim, odseparowanie je- go kodu jest pierwszym krokiem w kierunku lokalizacji. Mo na wymieni kilka wzorców architektury, które wykorzystuj t taktyk i u atwiaj modyfikowanie interfejsu: Model-View-Controller (model-widok-kontroler), Presentation-Abstraction-Control (prezentacja-abstrakcja-sterowanie), Seeheim, Arch/Slinky. Rysunek 5.13 przedstawia podsumowanie taktyk funkcjonalno ci dla czasu wykonywania Rysunek 5.13. Taktyki funkcjonalno ci dla czasu wykonywania 5.8. Taktyki atrybutów jako ciowych a wzorce architektury Przedstawili my zbiór taktyk, których stosowanie pomaga architektowi uzyska ró nego ro- dzaju atrybuty jako ciowe. W praktyce podejmowana decyzja konstrukcyjna to najcz ciej wy- bór pewnego wzorca lub zbioru wzorców, które maj zapewni u ycie jednej lub wi kszej licz- by taktyk. Jednak ka dy wzorzec nieodmiennie wprowadza zbiór wielu taktyk po danych lub nie. Niech ilustracj b dzie analiza wzorca projektowego Active Object (aktywny obiekt), opisanego w [Schmidt 00]: Wzorzec Active Object usuwa cis e powi zanie mi dzy wykonywaniem metody a jej wy- wo aniem, aby zwi kszy wspó bie no i upro ci synchronizowany dost p do obiektów we w asnym w tku sterowania. Wzorzec sk ada si z sze ciu elementów: po rednika, który zapewnia interfejs pozwalaj cy klientom wywo ywa publicznie dost pne metody aktywnego obiektu; dania metody, które definiuje interfejs wykonywania metod aktywnego obiektu; listy aktywacyjnej, przechowuj - cej bufor oczekuj cych da metod; jednostki szereguj cej decyduj cej o tym, które danie metody zostanie wykonane jako nast pne; wykonawcy definiuj cego zachowania i stan, mo- delowane przez aktywny obiekt; a tak e przysz ej warto ci, która pozwala klientowi pobra wynik wywo ania metody. 5.9. WZORCE I STYLE ARCHITEKTURY 129 Celem stosowania tego wzorca jest uzyskanie wspó bie no ci. Jest to cel dotycz cy wydaj- no ci. Architekt stosuje wi c taktyk wydajno ci wprowadzenie wspó bie no ci . Zwró my jednak uwag na inne taktyki, które wprowadza wzorzec. Ukrywanie informacji (modyfikowalno ). Ka dy element ma pewien zakres odpowie- dzialno ci, ale ukrywa sposób dzia ania. Po rednik (modyfikowalno ). Po rednik buforuje zmiany w sposobie wywo ywania metod. Czas wi zania (modyfikowalno ). Wzorzec aktywnego obiektu opiera si na za o eniu, e dania docieraj do obiektu w czasie wykonywania. Kwestia czasu wi zania klienta z po rednikiem pozostaje otwarta. Zasady szeregowania (wydajno ). Jednostka szereguj ca pos uguje si pewnym zbiorem zasad. Ka dy wzorzec to po czenie taktyk, cz sto powi zanych z ró nymi atrybutami jako ciowymi, i ka da implementacja wzorca wi e si z wyborami dotycz cymi tych taktyk. Przyk adowo implementacja dziennika da mo e jednocze nie umo liwia przywracanie systemu, zapew- nia zapis przebiegu pracy i u atwia testowanie. Architekt musi dobrze zna i rozumie wprowadzone w konstrukcji systemu taktyki, a jego prac jest poszukiwanie takiego ich po czenia, które pozwoli uzyska wszystkie wymagane cechy systemu. 5.9. Wzorce i style architektury Wzorce architektury oprogramowania nazywa si czasem stylami architektury. Jest to trafna analogia ze stylami architektury w budownictwie, takimi jak gotyk, secesja czy barok. Styl bu- duje kilka istotnych elementów i regu czenia ich w sposób niezak ócaj cy spójno ci. Wzo- rzec architektury jest okre lany przez: zespó typów elementów (takich jak magazyn danych lub komponent, który oblicza funk- cj matematyczn ), topologi elementów, która wyra a zwi zki mi dzy nimi, zespó ogranicze semantycznych (na przyk ad filtry w stylu z potokami i filtrami to czy- ste przetworniki danych przekszta caj one strumie wej ciowy w strumie wyj ciowy, ale nie maj kontroli nad elementami wcze niejszymi lub pó niejszymi), zespó mechanizmów interakcji (jak wywo anie procedury, subskrypcja zdarze , tablica podr czna), które okre laj sposób koordynacji elementów w ramach dozwolonej topologii. Mary Shaw i David Garlan podj li znacz c prób skatalogowania zbiorów wzorców archi- tektury, które nazwali stylami lub idiomami. W toku ewolucji in ynierii oprogramowania z podej cia tego wy oni y si lepiej znane dzisiaj wzorce architektury, analogiczne do wzorców projektowych i wzorców pisania kodu. Inspiracj dla autorów [Shaw 96] by o spostrze enie, e istnieje wiele znanych wysokopo- ziomowych abstrakcji z o onych systemów, ale nie zosta y one wcze niej systematycznie zba- dane i skatalogowane, podobnie jak robi si w innych dziedzinach technicznych. Poza bardzo regularnym wyst powaniem w projektach systemów drug charakterystyczn cech wzorców architektury jest to, e nie s one atwo rozpoznawalne przede wszystkim dlatego, e ró ne zastosowania prowadz do ró nego nazewnictwa. Odpowiedzi by o powsta- nie katalogów zawieraj cych opisy typowych wzorców, ich w asno ci i znaczenia dla systemu. Przyk ad takiego katalogu wida na rysunku 5.14. 130 5. UZYSKIWANIE ATRYBUTÓW JAKO CIOWYCH Rysunek 5.14. Ma y katalog wzorców architektury uporz dkowany wed ug relacji jest& Widoczne na rysunku wzorce zosta y sklasyfikowane w grupy tworz ce pewn hierarchi dziedziczenia. Na przyk ad system zdarzeniowy jest podstylem ogólniejszego stylu niezale - no ci elementów. Z kolei w ród systemów zdarzeniowych mo na wyró ni dwie podkategorie: z wywo aniem jawnym i z wywo aniem niejawnym. Jaka jest relacja mi dzy wzorcami architektury a taktykami? Jak pisali my wcze niej, trak- tujemy taktyk jako podstawowy blok konstrukcyjny projektu, z którego budowane s wzor- ce i strategie. 5.10. Podsumowanie W tym rozdziale pokazali my, w jaki sposób architekt osi ga wymagane przez specyfikacj atrybuty jako ciowe niezb dne do realizacji celów systemu. Zajmowali my si taktykami sto- sowanymi przez architekta w celu skonstruowania w a ciwego projektu z u yciem ró nych wzorców i strategii architektury. Przedstawili my list szeroko znanych taktyk osi gania sze ciu atrybutów omówionych w roz- dziale 4.: dost pno ci, modyfikowalno ci, wydajno ci, bezpiecze stwa, testowalno ci i funk- cjonalno ci. Taktyki podane dla ka dego z nich s w powszechnym u yciu i atwo zastosowa je w praktyce. Jak napisali my, stosowanie wzorców architektury rozpoczyna si od wyboru po danych [ Pobierz caÅ‚ość w formacie PDF ] |