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. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl
COM+. Kompendium
programisty
Autor: Luke Hohmann
T³umaczenie: Pawe³ Koronkiewicz
ISBN: 83-246-0110-4
Tytu³ orygina³u: Beyond Software Architecture:
Creating and Sustaining Winning Solutions
Format: B5, stron: 320
Przygotuj projekt systemu informatycznego,
który naprawdê spe³ni oczekiwania u¿ytkowników
(cid:127) Wybierz technologiê, platformê sprzêtow¹ i model licencjonowania
(cid:129) Zadbaj o funkcjonalnoœæ i ³atwoœæ rozbudowy systemu
(cid:129) Zabezpiecz system przed piractwem, kradzie¿¹ i utrat¹ danych
Termin „architektura oprogramowania” kojarzy siê zwykle z doborem jêzyka
programowania, wzajemnymi zale¿noœciami miêdzy komponentami powstaj¹cego
systemu informatycznego, wyborem platformy bazodanowej i zaplanowaniem innych
elementów zwi¹zanych wy³¹cznie z zagadnieniami technicznymi. Tymczasem w opisie
architektury systemu nie wolno pomijaæ tak¿e innych kwestii: modelu licencjonowania,
sposobu wdra¿ania i konserwacji systemu, a przede wszystkim jego u¿ytecznoœci.
Te pozornie niezwi¹zane z projektem elementy mog¹ mieæ du¿y wp³yw na powodzenie
przedsiêwziêcia, jakim jest stworzenie i sprzeda¿ oprogramowania. Odpowiednio
przygotowany projekt systemu informatycznego powinien wiêc obejmowaæ zarówno
zagadnienia techniczne, jak i ekonomiczne.
Ksi¹¿ka „Wiêcej ni¿ architektura oprogramowania” to poradnik, dziêki któremu
stworzenie odpowiedniej relacji miêdzy technologi¹ a biznesem jest ³atwiejsze, ni¿
mog³oby siê wydawaæ. Mo¿e siê przydaæ zarówno mened¿erowi, jak i programiœcie.
Autor ksi¹¿ki, doœwiadczony kierownik projektów i twórca oprogramowania,
przedstawia zwi¹zki miêdzy zagadnieniami technicznymi a innymi aspektami.
Znajdziesz w niej opisy dobrych i skutecznych rozwi¹zañ oraz zaczerpniête
z rynku przyk³ady planowania produkcji oprogramowania.
(cid:129) Znaczenie architektury oprogramowania
(cid:129) Zarz¹dzanie oprogramowaniem jako produktem
(cid:129) Modele licencjonowania
(cid:129) Wykorzystywanie obcych technologii w projekcie
(cid:129) Wdra¿anie systemu
(cid:129) Obs³uga techniczna
(cid:129) Dobór marki
(cid:129) Funkcjonalnoœæ i ³atwoœæ obs³ugi
(cid:129) Zabezpieczanie aplikacji
Sprawy z pozoru ma³o wa¿ne czêsto powoduj¹ najwiêksze problemy. Nie ignoruj ich.
Pracuj nad projektem kompleksowo.
Przedmowa Martina Fowlera................................................................................ 13
Przedmowa Guya Kawasaki ................................................................................. 15
Wstęp .................................................................................................................... 17
1.
Architektura oprogramowania .............................................................................. 21
Definicja architektury oprogramowania........................................................................................................... 21
Inne spojrzenia na architekturę oprogramowania ............................................................................................ 22
Znaczenie architektury oprogramowania ......................................................................................................... 24
Tworzenie architektury .................................................................................................................................... 27
Wzorce i architektura ....................................................................................................................................... 28
Ewolucja i dojrzewanie architektury — funkcje a możliwości........................................................................ 29
Opieka nad architekturą ................................................................................................................................... 32
Ogólne zasady .................................................................................................................................................. 36
Pełne zrozumienie architektury........................................................................................................................ 38
Zespół ............................................................................................................................................................... 39
Podsumowanie rozdziału.................................................................................................................................. 40
2.
Oprogramowanie jako produkt ............................................................................. 43
Czym jest zarządzanie produktem?.................................................................................................................. 43
Znaczenie zarządzania produktem ................................................................................................................... 44
Proces tworzenia produktu — do wersji 1.0 .................................................................................................... 44
Wcale tak nie jest ............................................................................................................................................. 50
Biznesplan ........................................................................................................................................................ 53
Proces tworzenia produktu — wersja n.n.n...................................................................................................... 53
Wspomaganie procesu tworzenia produktu ..................................................................................................... 55
Zarządzanie produktem — najważniejsze pojęcia ........................................................................................... 57
Podsumowanie rozdziału.................................................................................................................................. 64
!spis-03.doc
06-06-27
7
8
3.
SPIS TREŚCI
Różnica między m-architekturą i t-architekturą ................................................... 67
Jaki jest podział odpowiedzialności? ............................................................................................................... 67
Siły działające na początku projektu................................................................................................................ 68
Praca w długim okresie i wyniki w krótkim okresie........................................................................................ 72
Wizja przyszłości ............................................................................................................................................. 73
Zarządzanie informacjami zwrotnymi ............................................................................................................. 74
Budowanie przejrzystości ................................................................................................................................ 74
Jednomyślność działań..................................................................................................................................... 76
Diagramy kontekstowe i produkty docelowe................................................................................................... 78
Podsumowanie rozdziału.................................................................................................................................. 79
4.
Symbioza modelu biznesowego i modelu licencjonowania ................................. 81
Typowe modele biznesowe oprogramowania .................................................................................................. 82
Prawa licencjobiorcy ........................................................................................................................................ 92
Wpływ modelu biznesowego na t-architekturę................................................................................................ 95
Stosowanie modeli licencjonowania ................................................................................................................ 99
Dojrzałość rynku a model biznesowy ............................................................................................................ 104
Podsumowanie rozdziału................................................................................................................................ 106
5.
Korzystanie z technologii licencjonowanych ..................................................... 109
Licencjonowanie — zagrożenia i korzyści .................................................................................................... 109
Umowa ........................................................................................................................................................... 112
Niezgodność modeli biznesowych i negocjacje............................................................................................. 117
Honorowanie umów licencyjnych.................................................................................................................. 118
Włączanie technologii licencjonowanej......................................................................................................... 119
Licencjonowanie Open Source....................................................................................................................... 119
Opłaty licencyjne............................................................................................................................................ 120
Ekonomika licencjonowania .......................................................................................................................... 122
Podsumowanie rozdziału................................................................................................................................ 122
6.
Wieloplatformowość........................................................................................... 125
Rzekome korzyści z wieloplatformowości .................................................................................................... 125
Uzasadnienie biznesowe wieloplatformowości ............................................................................................. 126
Tworzenie aplikacji wieloplatformowej......................................................................................................... 129
Macierz trudów pracy..................................................................................................................................... 131
Niebezpieczne obietnice................................................................................................................................. 135
Podsumowanie rozdziału................................................................................................................................ 135
8
06-06-27
!spis-03.doc
SPIS TREŚCI
7.
9
Architektura wdrożeniowa.................................................................................. 137
Rodzaje architektury wdrożeniowej............................................................................................................... 137
Wpływ klienta ................................................................................................................................................ 140
Wpływ rodzimej organizacji .......................................................................................................................... 142
Wybór architektury wdrożeniowej................................................................................................................. 145
Architektury wdrożeniowe i podział pracy .................................................................................................... 146
Urządzenia informatyczne typu IA ................................................................................................................ 147
Wpływ na architekturę oprogramowania ....................................................................................................... 147
Przyszłość oprogramowania powszechnego użytku ...................................................................................... 149
Podsumowanie rozdziału................................................................................................................................ 149
8.
Integracja i rozbudowa........................................................................................ 151
Kontrola w rękach klienta, czyli siła przewodnia .......................................................................................... 151
Architektura warstwowa — struktury logiczne ............................................................................................. 153
Projektowanie i implementacja architektury warstwowej ............................................................................. 157
Integracja i rozbudowa warstw logiki biznesowej ......................................................................................... 159
Integrowanie i rozbudowa magazynu danych................................................................................................ 164
Konsekwencje natury biznesowej .................................................................................................................. 168
Interfejs API a kolejne wersje ........................................................................................................................ 174
Podsumowanie rozdziału................................................................................................................................ 175
9.
Marka i elementy marki ...................................................................................... 177
Elementy marki .............................................................................................................................................. 177
Marki produktów licencjonowanych.............................................................................................................. 182
Dostosowywanie elementów marki ............................................................................................................... 182
Zmiana elementów marki............................................................................................................................... 183
Podsumowanie rozdziału................................................................................................................................ 185
10.
Funkcjonalność („usability”) .............................................................................. 187
Funkcjonalność = pieniądze ........................................................................................................................... 187
Modele myślowe, metafory i funkcjonalność ................................................................................................ 189
Wpływ t-architektury na interfejs użytkownika............................................................................................. 190
Szybciej, wyżej, mocniej................................................................................................................................ 196
Podsumowanie rozdziału................................................................................................................................ 203
11.
Instalacja ............................................................................................................. 205
Wyjmij z pudełka i rozpocznij pracę.............................................................................................................. 205
Au! Może boleć.............................................................................................................................................. 207
Instalacja a architektura.................................................................................................................................. 208
!spis-03.doc
06-06-27
9
10
SPIS TREŚCI
Jak instalować ................................................................................................................................................ 210
Ostatnie szlify................................................................................................................................................. 214
Podsumowanie rozdziału................................................................................................................................ 216
12.
Aktualizacja ........................................................................................................ 219
Jak instalacja, tyle że gorsza .......................................................................................................................... 219
Mniej kłopotliwe uaktualnienie...................................................................................................................... 222
Aktualizacje a dojrzałość rynku ..................................................................................................................... 225
Podsumowanie rozdziału................................................................................................................................ 226
13.
Konfiguracja ....................................................................................................... 229
Konfigurowalność — element funkcjonalności............................................................................................. 229
Kontekst systemu ........................................................................................................................................... 230
W trakcie inicjalizacji i w trakcie pracy......................................................................................................... 231
Ustawianie wartości ....................................................................................................................................... 232
Ustawianie właściwej wartości ...................................................................................................................... 233
Ogólne zasady pracy z parametrami .............................................................................................................. 234
Podsumowanie rozdziału................................................................................................................................ 235
14.
Dzienniki............................................................................................................. 237
Chcę wiedzieć, co jest grane .......................................................................................................................... 238
Nie tylko fakty................................................................................................................................................ 239
Format i zarządzanie dziennikiem.................................................................................................................. 241
Przetwarzanie danych dziennika .................................................................................................................... 245
Usługi rejestrowania....................................................................................................................................... 245
Podsumowanie rozdziału................................................................................................................................ 246
15.
Zarządzanie wersjami ......................................................................................... 249
Tak, to jest potrzebne ..................................................................................................................................... 249
Nasz punkt wyjścia ........................................................................................................................................ 250
Zarządzanie wersjami..................................................................................................................................... 251
Identyfikacja wersji ........................................................................................................................................ 252
Oznaczenia SKU i numery seryjne ................................................................................................................ 257
Zarządzanie wersjami a t-architektura ........................................................................................................... 260
Podsumowanie rozdziału................................................................................................................................ 262
16.
Zabezpieczenia.................................................................................................... 263
Wirusy, hakerzy i piraci ................................................................................................................................. 264
Zarządzanie cyfrową tożsamością.................................................................................................................. 266
Bezpieczeństwo transakcji ............................................................................................................................. 269
10
06-06-27
!spis-03.doc
SPIS TREŚCI
11
Bezpieczeństwo oprogramowania.................................................................................................................. 271
Bezpieczeństwo informacji ............................................................................................................................ 273
Ukrywanie algorytmów czy ukrywanie kluczy?............................................................................................ 274
Tylne wejście.................................................................................................................................................. 274
Bezpieczeństwo i m-architektura ................................................................................................................... 275
Podsumowanie rozdziału................................................................................................................................ 277
A
Release — lista kontrolna ................................................................................... 281
Identyfikacja................................................................................................................................................... 281
Programowanie .............................................................................................................................................. 281
Zapewnienie jakości....................................................................................................................................... 281
Publikacje techniczne..................................................................................................................................... 282
Produkt ........................................................................................................................................................... 282
Przekaz informacji — usługi.......................................................................................................................... 282
Przekaz informacji — sprzedaż i dystrybucja................................................................................................ 282
Przekaz informacji — pomoc techniczna....................................................................................................... 283
Przygotowanie dystrybucji............................................................................................................................. 283
B
Język wzorców strategicznego zarządzania produktem ..................................... 285
Stosowanie wzorców...................................................................................................................................... 285
Prezentacja wyników...................................................................................................................................... 287
Mapa rynku .................................................................................................................................................... 287
Wydarzenia i rytmy rynku.............................................................................................................................. 289
Mapa funkcji i korzyści.................................................................................................................................. 291
Plan rozwoju t-architektury............................................................................................................................ 292
Bibliografia ......................................................................................................... 295
Literatura............................................................................................................. 297
O autorze............................................................................................................. 301
Skorowidz ........................................................................................................... 303
!spis-03.doc
06-06-27
11
Podstawą udanego rozwiązania jest architektura, która pozwala je stworzyć, a potem rozwijać. W tym
rozdziale spróbuję określić, czym jest architektura oprogramowania, jak powstaje i jak ewoluuje.
Jednocześnie zwrócę uwagę na wzorce architektury, ponadczasowe zasady jej projektowania i czyn-
niki, które wpływają na jej kształt. Na końcu poruszę zagadnienie zależności między architekturą
a zespołem, który tworzy ją i rozwija.
Definicja architektury oprogramowania
Architektura oprogramowania to złożone zagadnienie. Z tej złożoności wynika różnorodność definicji.
Ich użyteczność zależy od przyjmowanej perspektywy. Oto definicja z mojej pierwszej książki, Jour-
ney of the Software Professional:
Architektura systemu określa podstawową „strukturę” systemu (moduły wysokiego po-
ziomu, które realizują główne funkcje systemu, zarządzanie i rozkład danych, rodzaj i cha-
rakter interfejsu użytkownika, platformę docelową itp.).
Jest to definicja, która w dużej mierze pokrywa się z wieloma innymi, na przykład [Bass], [Larman]
i [POSA]. Jednak brakuje w niej kilku ważnych elementów, takich jak wybór technologii i wymaga-
nia użytkowników systemu. Mój współpracownik, Myron Ahn, stworzył definicję architektury opro-
gramowania, którą przytaczam poniżej. Jest nieco bardziej rozbudowana i szersza niż ta, którą przed-
stawiłem wcześniej (2002, z rozmów):
Architektura oprogramowania to suma znaczących modułów, procesów i danych systemu,
ich struktury i wzajemnych zależności, tego, jak mogą być i jak będą rozbudowywane i mo-
dyfikowane, a także wykorzystywanych technologii. Wynikają z niej funkcje i możliwo-
ści systemu, może też służyć jako podstawa do jego implementacji lub modyfikacji.
Te dwie definicje można dalej rozbudowywać technicznie, ale to już nie zwiększyłoby znacząco ich
wartości. Architektura, bardziej niż jakikolwiek inny aspekt systemu, dotyczy jego „widoku ogólnego”.
Aby naprawdę ją rozumieć, niezbędne jest spojrzenie z perspektywy całości.
R01-03.doc
06-06-27
21
22
WIĘCEJ NIŻ ARCHITEKTURA OPROGRAMOWANIA
Inne spojrzenia na architekturę oprogramowania
Choć powyższe definicje architektury oprogramowania są użyteczne, są zdecydowanie zbyt proste, aby
uwzględnić pełen zbiór sił, które kształtują architekturę i, z drugiej strony, są kształtowane przez nią.
Szczerze mówiąc, wątpię, aby jakakolwiek definicja architektury miała szansę uchwycić wszystko to,
co uważamy za istotne. Aby uzasadnić to stwierdzenie, w tym podrozdziale przedstawię kilka zagad-
nień, których nie obejmują tradycyjne definicje architektury oprogramowania, a którym trudno odmó-
wić znaczenia. W przeciwieństwie do wcześniejszych definicji, które koncentrują się na aspektach
technicznych, są to zagadnienia bardziej związane z „czynnikiem ludzkim” i kwestiami natury bizne-
sowej. Te również są częścią nierozerwalnie związanego z architekturą „spojrzenia całościowego”.
Podsystemy a zależności
Doświadczenie w zarządzaniu rozproszonymi zespołami, których członkowie pracowali na wszystkich
kontynentach Ziemi, nauczyło mnie, że ważnym kryterium w dekompozycji do podsystemów jest
uzyskanie możliwie najprostszych zależności między współpracującymi organizacjami. Przez „proste”
rozumiem takie, które nie utrudniają pracy osób tworzących system. Pracując jako konsultant, zauwa-
żyłem, że — w przeciwieństwie do uzasadnień natury technicznej — wiele związanych z architekturą
decyzji dotyczących projektowania podsystemów to decyzje, których osią było dążenie do stworzenia
jasnych i przejrzystych zależności między grupami programistów. Praktycznym skutkiem takich decy-
zji jest fakt, że pracę nad podsystemami rzadko dzieli się pomiędzy różnych wykonawców.
Podsystemy a motywacje i dążenia
Wiele książek poświęconych architekturze usuwa z procesu jej projektowania niemal cały bagaż
związany z „czynnikiem ludzkim”. Przykładowo, wzorce architektury są świetnym początkiem procesu
projektowania. Jednak tworzenie architektury nie sprowadza się do przyjęcia pewnego rodzaju struk-
tury początkowej, takiej jak wzorzec, i obiektywnego dopasowywania jej do potrzeb danej organiza-
cji. Trzeba rozumieć i uwzględniać nadzieje, doświadczenia, marzenia, obawy i upodobania zespołu,
który odpowiada za budowę systemu. Techniczna struktura architektury kształtuje strukturę społeczną
(i odwrotnie), a towarzyszą temu ciągłe konflikty obiektywnych i subiektywnych przesłanek podej-
mowanych decyzji.
Aby nieco lepiej zrozumieć ten problem, przypomnijmy sobie sytuację, w której zdecydowanie
zależało nam na pracy nad określonym aspektem architektury, bo wiedzieliśmy, że zrobimy to lepiej
niż ktokolwiek inny (pewność siebie oparta na doświadczeniu); w której chcieliśmy lepiej poznać
wykorzystywaną technologię (pragnienie); w której wierzyliśmy, że przyłożenie się do pracy pozwoli
uzyskać premię lub awans (aspiracje), albo taką, w której obawialiśmy się, że nikt inny w zespole nie
ma wystarczających umiejętności lub doświadczenia, aby rozwiązać problem we właściwy sposób
(obawa, strach).
22
06-06-27
R01-03.doc
INNE SPOJRZENIA NA ARCHITEKTURĘ OPROGRAMOWANIA
23
Projektowanie podsystemów a poczucie całości
Niewielu programistów chciałoby specjalizacji sprowadzającej ich pracę do jednego rodzaju
działań — analizy, projektowania, pisania kodu czy poprawiania błędów. Dużo bardziej typowe
jest dążenie do zaangażowania w pełen zakres czynności programisty: omawianie wymagań
z klientem lub menedżerem produktu, opracowywanie i realizowanie artefaktów analizy i pro-
jektu, poprawianie błędów, optymalizowanie wydajności itd. Uważam, że jest to wyraz stosun-
kowo silnego dążenia do poczucia „kompletności” wykonywanej pracy. Dążenie to ma głębokie
implikacje. Dobra decyzja projektowa to często decyzja, która pozwala je zaspokoić.
Pojęcie „kompletności” wykonywanej pracy jest różnie rozumiane przez różne osoby.
Kierownictwo musi być dobrze zorientowane w tym, jak jest postrzegane przez dany zespół.
W pewnej aplikacji typu klient-serwer rozważaliśmy kilka różnych konstrukcji klienta. Przytoczę
tutaj dwie z nich, aby zilustrować naszą interpretację kompletności pracy i to, jak wpłynęła na
podjęty wybór.
W pierwszej wersji jeden zespół odpowiadał za zagadnienia „związane z klientem”, a drugi
za „infrastrukturę”. W drugiej wersji projektu każdy zespół przyjmował odpowiedzialność za
komponenty z obu tych obszarów.
O ile pierwszy projekt mógł wydawać się nieco bardziej przejrzysty na papierze, zdecydo-
wanie psuł morale zespołu infrastruktury, który skłaniał się ku opinii, że pozbawiłoby to ich peł-
nego uczestnictwa w procesie przygotowywania kolejnych wersji. Mówiąc ściślej, zespół ten
tracił wówczas okazję do bezpośredniej pracy z osobami odpowiedzialnymi za kierowanie pro-
duktem, publikacjami technicznymi i potencjalnymi klientami. Należało to do jego obowiązków
wcześniej i wszyscy chcieli, żeby tak zostało. W efekcie wybraliśmy drugą wersję architektury,
ponieważ tylko ona pozwalała obu zespołom zachować to samo poczucie kompletności wyko-
nywanej pracy, tak bardzo ważne dla programistów. Dla nich oznaczało ono, między innymi,
kontakt z osobami kierującymi rozwojem produktu i udział w procesie przygotowywania kolej-
nych wersji.
Poddawanie się dobrej architekturze
Używam czasownika „poddawać się”, gdy architekt lub zespół programistów odsuwa od siebie, tak
daleko jak to możliwe, własne doświadczenia i wyobrażenia o tym, co jest poprawne i właściwe,
pozwalając, aby ich pracą nad architekturą kierowały siły właściwe dziedzinie problemu. Niektórzy
twierdzą, że nie jest to problemem i że oni lub ich zespół zawsze tworzą architekturą opartą wyłącznie
na obiektywnej analizie problemu klienta i najlepszych metodach prowadzących do jego rozwiązania.
Słowo-klucz to oczywiście najlepsze. Zdanie Czytelnika o tym, co jest najlepsze, może różnić się od
mojego. Różnice tego rodzaju biorą się przede wszystkim z posiadanego zasobu doświadczeń. Nie
wynikają bezpośrednio z dziedziny problemu (z wyjątkiem sytuacji, kiedy zdobywamy doświadczenia
w obrębie danej dziedziny). Jednym z aspektów „poddawania się” dobrej architekturze jest ciągłe wery-
fikowanie, czy podejmowane decyzje mają na uwadze przede wszystkim potrzeby klienta, i zgoda
na zmienianie tych decyzji, jeżeli weryfikacja taka będzie miała skutek negatywny.
R01-03.doc
06-06-27
23
24
WIĘCEJ NIŻ ARCHITEKTURA OPROGRAMOWANIA
Nie to ładne, co ładne, ale co się komu podoba!
Wszyscy możemy podać po kilka definicji udanych architektur oprogramowania. Podczas gdy firma
może uważać, że system jest udany, bo wspiera produkcję lub sprzedaż dochodowego produktu, doglą-
dający go programiści mogą w tym samym czasie załamywać ręce nad archaicznymi rozwiązaniami
technicznymi. Analogicznie, wiele zgrabnych i eleganckich rozwiązań technicznych kończy jako
mniejsze lub większe niepowodzenia. Co więcej, elegancja techniczna rozwiązań to pojęcie subiek-
tywne. Dwóch najlepszych programistów mojego zespołu miało skrajne różnie podejścia do stosowania
procedur przechowywanych w bazach danych. Jestem pewien, że każdy z nich potrafiłby stworzyć
dobre rozwiązanie praktycznie każdego problemu związanego z bazami danych. Jestem równie
pewien, że ich aplikacje byłyby różne, a każdy z nich potrafiłby uzasadnić podjęte decyzje, przedsta-
wiając zarazem poprawną krytykę architektury zastosowanej przez drugiego. Niewielu programistów
potrafi wyjść poza ograniczenia narzucane im przez własne rozumienie estetyki architektury.
Znaczenie architektury oprogramowania
Architektura oprogramowania jest ważna, ponieważ, gdy jest dobra, staje się czynnikiem decydującym
o przyszłym powodzeniu projektu. Architektura wpływa na sukces przedsięwzięcia w różny sposób.
Nie każdy z tych wpływów jest równie ważny, ale wszystkie mają swój początek w architekturze.
Trwałość
Większość architektur trwa dużo dłużej niż zespoły, które je tworzyły. Ogólne szacunki trwałości sys-
temu lub architektury wskazują na okres od 12 do 30 lub więcej lat, podczas gdy typowy czas aktywnej
pracy programisty nad tym samym systemem mieści się w granicach od 2 do 4 lat.
Stabilność
Wiele korzyści z dobrej architektury można wywieść właśnie od jej trwałości. Jedną z najważniejszych
jest stabilność. Stabilność architektury sprzyja ograniczeniu ilości poważnych modyfikacji w trakcie
rozbudowy zakresu funkcji systemu w kolejnych wersjach. W efekcie, maleje całkowity koszt imple-
mentacji. Stabilność to dla zespołu programistów ważna podstawa i znaczne ułatwienie. Pracę nad ule-
gającym ciągłym przemianom kodem zastępuje dzięki niej koncentracja na zmianach o największej
wartości.
Stopień i natura zmian
Architektura wyznacza naturę zmian w systemie. Pewne zmiany wydają się proste. Inne są postrzegane
jako trudne. Gdy prostota silnie koreluje z pożądanym zbiorem zmian zwiększających zadowolenie
klienta lub pozwala nam dodawać funkcje przyciągające nowych klientów, zazwyczaj nie wzbraniamy
się przed określeniem architektury przymiotnikiem „dobra”.
24
06-06-27
R01-03.doc
ZNACZENIE ARCHITEKTURY OPROGRAMOWANIA
25
W jednej z aplikacji, nad którymi pracowałem, stworzyliśmy architekturę pluginów, które pozwa-
lały rozbudowywać narzędzia analityczne operujące na różnych, zarządzanych przez system danych.
Dodawanie nowego narzędzia było stosunkowo proste. Cecha ta była wartościowa, ponieważ głównym
celem kierownictwa projektu było dodanie do aplikacji możliwie dużej liczby narzędzi.
Opłacalność
Dobra architektura to architektura opłacalna. Rozumiem przez to, że firma, która ją stworzyła, może
pielęgnować ją, zachowując akceptowalny poziom kosztów. Jeżeli koszty dalszego utrzymywania
architektury stają się zbyt wielkie, architektura zostaje porzucona.
Nie oznacza to, że opłacalna architektura jest architekturą elegancką czy ładną. Jedną z najbardziej
dochodowych architektur w historii jest rodzina systemów operacyjnych Microsoft Windows. Mimo
to krytycznych opinii na temat elegancji zastosowanych rozwiązań nie brakuje.
Warto zwrócić uwagę, że opłacalność określonych rozwiązań technicznych często niewiele ma
wspólnego z samą architekturą. Firma Microsoft decydowała ogromną przewagą w obszarach marke-
tingu, dystrybucji czy marki. Wszystko to miało duży udział w niezwykłej opłacalności Windows.
Nie usprawiedliwiam tutaj architektur źle zaprojektowanych i brzydkich, których budowa i utrzy-
manie kosztuje więcej niż to konieczne! W długim okresie, bazą dla opłacalnych rozwiązań są zdecy-
dowanie architektury proste i eleganckie.
Struktura społeczna
Dobra architektura jest korzystna dla zespołu jej twórców. Pozwala w pełni wykorzystać jego silne
strony, a niekiedy też ograniczyć wpływ słabych. Dobrym przykładem jest częsty brak umiejętności
niezbędnych do właściwego korzystania z języków C i C++. Typowym wynikiem popełnianych wtedy
błędów w zarządzaniu pamięcią są pozornie zupełnie przypadkowe błędy aplikacji. Dla zespołów, które
nie wymagają niepowtarzalnych cech C lub C++, lepszym wyborem jest bezpieczniejszy język, jak
Java, Visual Basic, Perl lub C#, wyręczający programistę w zarządzaniu pamięcią.
Raz zdefiniowana architektura wywiera silny wpływ na dalszą pracę zespołu i jego kształtowanie.
Bez względu na to, jaki język wybierzemy, do podjętej decyzji dostosujemy dalsze, przede wszystkim
związane z zatrudnianiem nowych programistów i szkoleniami. Ponieważ architektury trwają dłużej niż
zespoły, skutki mogą dawać się we znaki przez lata (przypomnijmy sobie niewiarygodny wzrost zapo-
trzebowania na programistów języka COBOL w ostatnich trzech latach przed rokiem 2000, kiedy
wciąż działające aplikacje musiały zostać dostosowane do pracy w nowym millenium).
Wyznaczone granice
W procesie projektowania architektury nieustannie podejmowane są decyzje o tym, co stanie się czę-
ścią systemu, a co nie. Wyznaczane w ten sposób granice, ich uwarunkowania i to, jak są traktowane, to
kolejny ważny czynnik wpływający na powodzenie architektury. Związanych z nimi pytań nie brakuje.
Czy pisać własną warstwę dostępu do bazy danych, czy wykorzystać gotowy produkt? Czy korzystać
z serwera Open Source, czy komercyjnego? Który podzespół będzie odpowiedzialny za interfejs użyt-
kownika? Dobre systemy mają ściśle określone granice, odpowiadające rzeczywistym potrzebom ich
R01-03.doc
06-06-27
25
26
WIĘCEJ NIŻ ARCHITEKTURA OPROGRAMOWANIA
Ilu programistów, żeby to wymienić?
Jedną z najtrudniejszych decyzji stojących przed starszymi członkami każdego zespołu progra-
mistów jest określenie właściwego momentu zastąpienia starej architektury nową.
Istotnych jest wiele czynników, takich jak koszt utrzymywania bieżącej architektury, wy-
magania klientów, możliwości spełnienia tych wymagań czy działania konkurencji. Wyznaczenie
formalnego zestawu reguł, który pozwalałby określić, kiedy zmienić architekturę, jest oczywiście
niemożliwe. Czynników do uwzględnienia jest zbyt wiele, a większość z nich jest niemierzalna.
Poniżej wymieniam kilka prostych zasad postępowania, które sprawdziły się w mojej praktyce.
Jeżeli sądzisz, że nową architekturę może przygotować w czasie krótszym niż rok zespół
programistów o połowę mniejszy od obecnego, możliwość przeprowadzenia takiej zmiany warto
poważnie rozważyć. Mówiąc bardzo ogólnie, jest to sytuacja, w której zespół można podzielić na
grupę zajmującą się nowym systemem i grupę odpowiedzialną za konserwację starego, bez
wprowadzania zmian w strukturze kosztów.
Zasoby wykorzystywane w tworzeniu nowej architektury wykraczają zazwyczaj poza to,
co może zapewnić bieżący zespół. Nie można się oszukiwać, tworzenie nowej architektury przez
mniejszą liczbę osób to sytuacja wymuszająca radykalne zmiany w procesie budowy oprogra-
mowania. Nie każdy zespół ma niezbędne umiejętności. Nie każdy zespół chce je zdobyć i nie
każdemu to się udaje. Gotowość do zmiany w składzie zespołu jest często warunkiem powodze-
nia zmiany architektury systemu.
O ile niewielkie zmiany w składzie zespołu programistów są często wymagane, szaleń-
stwem będzie próba wymiany całego składu. Im system starszy i bardziej złożony, tym istot-
niejsza jest rola współpracy z co najmniej jednym, a najlepiej kilkoma „weteranami”. Zapew-
niają oni przede wszystkim wierne odwzorowanie zestawu funkcji starego systemu. W starym
kodzie zawsze znajdą się zagadki, których rozwiązania znają tylko najstarsi programiści.
Oczywiście, wszystkie tradycyjne ostrzeżenia — „ostrożność przede wszystkim”, „to nie
będzie takie proste i zajmie więcej czasu, niż się spodziewamy” — pozostają aktualne. Tak, duże
zmiany wymagają wyważonych decyzji, a większość okazuje się trudniejsza i trwa dłużej, niż
planowano. Wciąż zapominamy o pełnych kosztach zmiany, które poza samym programowa-
niem obejmują przeróżne konsultacje, pisanie dokumentacji, szkolenia i aktualizacje. Pewną
wskazówką może być uproszczona reguła, że nowa architektura, funkcjonalnie równoważna
wcześniejszej, będzie kosztować co najmniej 20 procent całkowitej sumy wydanej na starą archi-
tekturę, o ile programiści są doświadczeni, nie wystąpią zakłócenia w realizacji projektu, a sam
proces budowy oprogramowania zostanie wydatnie poprawiony. Jeżeli mamy do czynienia
z czwartą iteracją systemu budowanego przez 5 lat, kosztem 23 milionów dolarów, plan stworze-
nia pierwszej wersji nowego systemu za mniej niż 3 do 5 milionów jest najprawdopodobniej
zanadto optymistyczny. Koszt stworzenia nowej, funkcjonalnie równoważnej architektury to
zazwyczaj od 40 do 60 procent całkowitych wydatków poniesionych na starą. Zależy on w dużej
mierze od wielkości zespołu i złożoności wymienianego systemu.
użytkowników. Warunek ten nie zawsze jest spełniony, zwłaszcza w środowisku nowego rynku, gdy
projektanci nie mogą liczyć na dużą pomoc i muszą tworzyć większość architektury od podstaw. Złe
decyzje mogą zaprowadzić ich w ślepą uliczkę, z której bardzo trudno wyjść.
26
06-06-27
R01-03.doc
TWORZENIE ARCHITEKTURY
27
Trwała, niesprawiedliwa przewaga
Ten ostatni punkt podsumowuje poprzednie i jest zdecydowanie najważniejszy. Bardzo dobra archi-
tektura zapewnia trudną do powielenia, trwałą i opartą na solidnych, technicznych podstawach prze-
wagę konkurencyjną. Jeżeli techniczne aspekty architektury są łatwe do powielenia, muszą istnieć inne
czynniki wyróżniające system (na przykład lepsze wsparcie techniczne lub dystrybucja). Nawet wów-
czas jednak architektura pozostaje ważna — gdy jest dobra, ułatwi budowanie przewagi w oparciu
o takie aspekty jak szybkość pracy lub zakres zastosowań.
Tworzenie architektury
Architektura oprogramowania (ang. software architecture) to na początku zbiór decyzji zespołu,
który projektuje pierwszą wersję. Te początki, znaczone szkicami na tablicy i diagramami w notesie
(lub na serwetce), reprezentują zamiary pierwszego zespołu programistów. Gdy system zostaje ukoń-
czony, jego budowa może w niczym nie przypominać wczesnych pomysłów. Z drugiej strony, retro-
spektywna analiza jest często jedyną drogą wyjaśnienia konstrukcji systemu. Jest niezbędna, aby
powiązać to, co powstało, z pierwotnymi planami.
Pierwsza wersja architektury przypomina często małe dziecko: wymagana jest kompletność, ale
brakuje dojrzałości i stabilności. Dopiero z czasem, w miarę używania oprogramowania i tworzenia
kolejnych wersji, architektura nabiera tejże dojrzałości, a zarazem trwałości. Jednocześnie użytkownicy
i twórcy budują swoją wiarę w możliwości systemu, uświadamiają sobie i rozwiązują problemy jego
ograniczeń. Podstawą tego procesu jest rzetelne gromadzenie informacji zwrotnych i reagowanie na nie
odpowiednimi, sprzyjającymi sukcesowi produktu, zmianami. Oczywiście, gdy brakuje informacji
zwrotnych, niedojrzała architektura może taką pozostać, jej rozwój może ulec stagnacji. Decyduje
zazwyczaj rynek.
Miałem szczęście uczestniczyć w tworzeniu kilku nowych architektur od podstaw. Były to
doświadczenia o tyle ciekawe, że pozwoliły mi zauważyć, że faktyczny przebieg procesu projektowania
i budowania nowej architektury odbiega w pewnym stopniu od zaleceń podręcznikowych. Mówią one
między innymi, że gdy system jest jeszcze zupełną nowością i rozwiązywane problemy są jeszcze mało
znane, projektanci powinni „badać architektury alternatywne w poszukiwaniu tej, która najlepiej
sprawdza się w danym przypadku”. Jest to bardzo rozsądna rada. Jest też zarazem mało przydatna.
Jest wiele przyczyn, które sprawiają, że przytoczone zalecenie jest mało użyteczne w praktyce.
Najważniejsze wydają się trzy z nich. Każda jest w zupełności wystarczająca w roli czynnika, który
powstrzymuje przed badaniem alternatyw. Zazwyczaj mamy do czynienia ze wszystkimi trzema jedno-
cześnie. Każda wywiera swój wpływ, czasem w połączeniu z innymi czynnikami. Wszystkie prowadzą
do nieco innego, bardziej pragmatycznego podejścia do budowania nowej architektury. Nie chodzi o to,
że są to siły złe. Są to siły, które są.
Pierwsza siła to charakterystyczny dla przedsięwzięć komercyjnych brak czasu na rzetelną wery-
fikację wielu ścieżek do rozwiązania tego samego problemu. Zasada „czas to pieniądz” sprawdza się
zawsze, i o ile pierwsza wersja nie jest w oczywisty sposób katastrofą, będzie to niemal na pewno wer-
sja, którą trzeba przedstawić klientowi. Odbiorca nie może czekać! Siła ta jest na tyle duża, że już przy
kompletowaniu zespołu programistów dbamy o to, aby architekt pierwszego systemu dysponował
wystarczającym doświadczeniem, aby podjąć właściwe decyzje bez badania alternatyw. Innymi słowy,
zatrudniamy osobę, które spotkała się z alternatywami w poprzednich miejscach pracy.
Druga siła, wyraźnie mocniejsza niż pierwsza, to natura problemu i towarzyszących mu warun-
ków, mocno zawężające dostępne opcje. Witryna WWW, która ma być szybka i obsługiwać wielu
użytkowników, musi być oparta na względnie standardowej architekturze. Można stosować różne
R01-03.doc
06-06-27
27
28
WIĘCEJ NIŻ ARCHITEKTURA OPROGRAMOWANIA
Gdy już wiesz, że się nie uda…
Doświadczenia z różnymi architekturami ułatwiają rozpoznawanie błędnych decyzji jeszcze
przed etapem implementacji. Można wtedy zrezygnować z architektury i odesłać programistów
z powrotem do tablicy albo też zrezygnować z projektu w ogóle. Rezygnacja z projektu może
wydawać się posunięciem drastycznym, ale jest w pewnych sytuacjach decyzją konieczną,
zwłaszcza gdy złe decyzje znacząco zmieniają perspektywy ekonomiczne systemu.
W jednym ze znanych mi przedsięwzięć podjęto decyzję o zastosowaniu pełnej implemen-
tacji J2EE do rozwiązania problemu, z którym bez trudu poradziłoby sobie kilkadziesiąt skryptów
w Perlu — o ile tylko zostałaby zmieniona druga część aplikacji. W tym klasycznym przypadku
„projektowania kierowanego CV” szef zespołu technicznego, który przyjął rolę architekta, zdołał
przekonać co ważniejsze osoby, że implementacja oparta na J2EE będzie najlepsza. Dodatkowo,
na architekturze ciążyło kilka wyraźnie błędnych założeń. Najbardziej zapadł mi w pamięć
pomysł przesyłania obrazów CD o rozmiarze do 600 MB pocztą elektroniczną, w postaci załącz-
ników! Ostatecznie doszedłem do przekonania, że nie ma w tej sytuacji niczego wartego rato-
wania i doprowadziłem do zamknięcia projektu. Było już po prostu za późno, aby przygotować
i wprowadzić do sprzedaży planowany produkt.
systemy operacyjne, ale i tu obowiązują pewne kanony. Poszukiwanie nowych architektur wyso-
kiego poziomu nie ma zazwyczaj wielkiej wartości, ale często warto zwrócić uwagę na inne roz-
wiązania w bardziej zawężonych obszarach projektu. U podstaw takich poszukiwań powinna leżeć
rzetelna analiza zagrożeń stojących przed budowanym rozwiązaniem, a wybierane środki powinny
być dobrze przemyślane.
Trzecia, najsilniejsza siła to problem z określeniem tego, czy dana architektura jest faktycznie
dobra w danym zastosowaniu. Dopóki nie rozpocznie ona pracy w środowisku, dla którego została
zaprojektowana, nie można mieć pewności, czy zastosowano właściwe rozwiązania. Zdobycie wiedzy
na ten temat wymaga czasu, zazwyczaj liczonego w latach.
Wzorce i architektura
Główną konsekwencją działania wymienionych sił jest to, że tworzenie wstępnej wersji architektury
musi opierać się na podejściu zdecydowanie pragmatycznym. Podejściu takiemu sprzyjają wzorce
projektowe. Jest to próba uchwycenia dobrych rozwiązań powtarzalnych problemów w taki sposób,
aby zgromadzoną wiedzę można było zastosować w nowych sytuacjach. Dobre wzorce znalazły zasto-
sowanie w kilku czy kilkunastu systemach, najlepsze — w dziesiątkach i setkach rozwiązań. Ktoś, czę-
sto więcej niż jedna osoba, zadał sobie trud, aby zbadać, przeanalizować i dokładnie opisać problem
oraz sprawdzoną metodę jego rozwiązania. Dzięki temu inni mogą korzystać z doświadczeń zdoby-
tych w pracy nad systemami, które zdały egzamin w praktyce. Wzorzec projektowy to rodzaj „wstępnie
przetrawionej” wiedzy.
Wzorce architektury mają za zadanie uchwycić podstawowe organizacje struktury oprogramo-
wania. Odnoszą się głównie do technicznych aspektów architektury wymienionych wcześniej w tym
rozdziale i dostarczają opisów podsystemów oraz ich zakresów odpowiedzialności, a także interakcji
między nimi. Koncentracja na ściśle określonej klasie problemu sprawia, że wzorzec architektury
pomaga podjąć decyzję o tym, jaki rodzaj lub styl architektury jest właściwy.
28
06-06-27
R01-03.doc
EWOLUCJA I DOJRZEWANIE ARCHITEKTURY — FUNKCJE A MOŻLIWOŚCI
29
Podejście pragmatyczne w tworzeniu architektury oprogramowania oznacza badanie wielu róż-
nych udokumentowanych wzorców i wybór tego, który odnosi się do rozpatrywanej sytuacji. Jest to
punkt wyjścia do dalszego kształtowania architektury pod kątem konkretnych potrzeb. Kształtowa-
niem architektury i podejmowanym przy tym decyzjom towarzyszą zasady, które opisuję w dalszej
części tego rozdziału. Dla Czytelnika, który miał okazję poznać skatalogowane wzorce architektury,
dalsza część tej książki może być istotnym uzupełnieniem, bo zwraca uwagę na elementy, których
wzorce nie opisują. Przykładowo, każda architektura skorzysta na dopracowanej procedurze instalacji
i aktualizacji czy rozsądnie zaprojektowanych plikach konfiguracyjnych. Celem nadrzędnym jest sto-
sowanie wszystkich dobrych reguł, które prowadzą do rozwiązań udanych i trwałych.
Ewolucja i dojrzewanie architektury
— funkcje a możliwości
Choć wiele uwagi poświęca się projektowaniu i wczesnym wersjom architektury, w rzeczywistości
większość czasu spędzamy, pracując nad architekturą, która już istnieje. Ewolucja architektury może
być dużo bardziej interesującym procesem niż tworzenie jej pierwszej wersji. To w trakcie tej ewolucji
dowiadujemy się co jest dobre, a co złe, zwłaszcza gdy kierują nią informacje pozyskiwane bezpośred-
nio od klientów. Osobiście, jako największe wyzwania i przynoszące najwięcej satysfakcji osiągnięcia
wspominam pracę z zespołami programistów, której celem było zmodyfikowanie istniejącej architektu-
ry w taki sposób, aby lepiej dopasować ją do potrzeb rynku i stworzyć warunki dla dalszego powodze-
nia produktu.
Procesem tym, na który składa się ewolucja i dojrzewanie architektury, kieruje przede wszystkim
informacja od klientów, którzy faktycznie używają systemu. Wiele firm twierdzi, że nieustannie sta-
rają się o informacje zwrotne. Rzeczywistość jest jednak taka, że są to dane najbardziej cenione i naj-
intensywniej pozyskiwane w okresie planowania następnej wersji systemu. Ta następna wersja jest
definiowana pewnym zestawem funkcji, wymienianych (możliwie często) w materiałach marketingo-
wych. O tym, czy dana funkcja może zostać włączona do systemu, decydują możliwości architektury.
Właśnie zależności między pożądanymi funkcjami a możliwościami architektury kształtują ewolucję
tej ostatniej.
Taka gra wzajemnych zależności jest o tyle ciekawa, że ma miejsce w środowisku nieustającej
ewolucji technicznej. Innymi słowy, pozyskiwana od klienta informacja zwrotna nie zawsze odwołuje
się do aspektów systemu, nad którym pracujemy. Jej pochodzenie często można wywieść od docierają-
cych do aktywnego użytkownika wiadomości o różnych, potencjalnie użytecznych technikach pracy.
Źródłem takich danych nie musi być nawet klient, często dostarcza ich sam zespół programistów. Bez
względu jednak na źródło czy kontekst informacji, praktycznym podejściem jest rozpatrywanie ewolu-
cji i dojrzewania architektury w kategoriach funkcji i możliwości.
Funkcja (ang. feature lub function) definiuje to, co produkt robi lub powinien robić (a zarazem to,
co zwraca uwagę klienta). Pełen zestaw wymaganych funkcji określa wymagania wobec produktu.
Może być budowany, dokumentowany i modyfikowany wieloma metodami. Na wypadek, gdyby Czy-
telnik zastanawiał się, czym dokładnie jest funkcja w znaczeniu, do którego się tutaj odwołuję, oto
sprawdzona definicja z Exploring Requirements: Quality Before Design [Weinberg i Gause, 1989]:
„Aby sprawdzić, czy wymaganie jest [funkcją], umieść sformułowanie ‘Produkt ma…’ lub ‘Produkt
powinien…’ przed opisem tego wymagania”. Podejście to prowadzi do zakwalifikowania jako funkcje
bardzo zróżnicowanych wymagań. Oto kilka przykładów:
R01-03.doc
06-06-27
29
30
WIĘCEJ NIŻ ARCHITEKTURA OPROGRAMOWANIA
·
Obsługiwane platformy. „Produkt ma pracować w systemach Solaris 2.8 i Windows XP.”
Przypadki użycia. „Produkt powinien umożliwiać zarejestrowanie nowego użytkownika.”
Działanie. „Produkt powinien dostarczać sygnał wybierania numeru w czasie nie dłuższym niż
·
·
100 milisekund od odebrania sygnału podniesienia słuchawki.”
Zwróćmy uwagę, że gdy rozpatrujemy opisy funkcji, przypadki użycia mają znaczącą przewagę
nad innymi postaciami dokumentacji, bo osadzają opisywaną funkcję w określonym kontekście.
Najlepszym wyznacznikiem kontekstu są cele aktorów przypadku — ich zamiary. Gdy je znamy i gdy
wiemy, że system pozwala realizować cele aktorów, dysponujemy danymi potrzebnymi kierownictwu
produktu do stworzenia oferty informującej o strategiach sprzedaży, licencjonowania i cen.
Funkcje dobrze jest uporządkować. Dział marketingu określa ich priorytety. Zespół programistów
powinien rozpoznać występujące między nimi zależności natury technicznej. Wynika to stąd, że funk-
cje są zazwyczaj powiązane — wprowadzenie jednej opiera się na wprowadzeniu drugiej. Jak pisałem
wcześniej, ponieważ architektura systemu określa to, jak łatwe (lub jak trudne) będzie implemento-
wanie przyszłych funkcji, dobrą architekturą będzie ta, w której implementowanie wymaganych funkcji
jest proste.
Możliwość (ang. capability) architektury to jej zdolność do zapewnienia obsługi pewnego zakresu
funkcji. Znaczenie możliwości systemu daje się we znaki, gdy dział marketingu regularnie otrzymuje
informacje, że pewna klasa funkcji (albo też zbiór funkcji pozornie niepowiązanych, a w rzeczywistości
bliskich sobie w implementacji) jest trudna lub niemożliwa do zaimplementowania w obrębie stosowa-
nej architektury. W ramce opisuję kilka przykładów takich sytuacji.
Zależności między dojrzałością i ewolucją architektury zmieniają się w czasie i wraz z kolejnymi
wersjami systemu. Raczej nie zdarza się, żeby programiści zaimplementowali wszystkie czy nawet
większość funkcji już w pierwszej wersji, zwłaszcza gdy menedżer produktu potrafi przedstawić
jasną i przejrzystą specyfikację tych funkcji. Problem implementacji dalszych funkcji powraca bardzo
szybko. Ponieważ nie ma jeszcze wielu klientów, którzy mogliby dostarczyć informacji zwrotnej,
zespół pracuje nad pozostałymi funkcjami i ich ukończenie nie sprawia dużego problemu. Cała praca
koncentruje się wtedy na wprowadzeniu pełnego zestawu cech produktu. W tym okresie niewiele czasu
i uwagi poświęca się zmienianiu architektury. Jest to czas, w którym pierwotna architektura nabiera
dojrzałości. Oczywiście, pewne zmiany następują, mają jednak zazwyczaj dość ograniczony charakter.
Kiedy system jest w ciągłym użyciu przez trzy lub więcej kolejnych wersji, albo przez dwa lub
więcej lat, jego początkowe funkcje, przewidziane przez twórców, wyczerpują swój potencjał
i menedżer produktu potrzebuje w procesie planowania dalszej pracy coraz większych ilości informacji
od klientów. Te informacje zwrotne, mówiące o nowych funkcjach albo znaczących modyfikacjach
funkcji istniejących, wyznaczają najczęściej początek ewolucji architektury, zmuszają bowiem progra-
mistów do stworzenia w niej niezbędnych możliwości. Proste implementowanie funkcji nie jest już
wystarczające.
Oczywiście, ewolucję architektury nie zawsze napędzają potrzeby zgłaszane przez klientów.
Firma, która proaktywnie kieruje rozwojem swoich produktów, stale poszukuje nowych technologii
i metod pozwalających uzyskać przewagę konkurencyjną. Praktyka włączania do ewoluującej archi-
tektury najważniejszych z nowych technologii może zapewnić, że taka przewaga będzie względnie
trwała. Piszę o tym szerzej w rozdziale 3. W dodatku B przedstawiam język wzorców, który jest jedną
z metod porządkowania takiego procesu.
Dojrzewanie i ewolucja architektury mają charakter cykliczny. Każda faza cyklu wykorzystuje
osiągnięcia poprzedniej. W dojrzałym produkcie rzadko wprowadza się nowe możliwości, a tylko
praktyka pozwala poznać ich rzeczywistą wartość. Dzięki informacjom zwrotnym, nowe możliwości
stają się coraz bardziej dojrzałe. W wyjątkowo dobrze ukierunkowanej architekturze możemy spotkać
się z tym, że pewne możliwości są usuwane.
30
06-06-27
R01-03.doc
EWOLUCJA I DOJRZEWANIE ARCHITEKTURY — FUNKCJE A MOŻLIWOŚCI
31
Możliwości architektury czy dynamika funkcji
W jednym z systemów, nad którymi pracowałem, użytkownicy mogli kooperatywnie porządko-
wać wspólny zbiór dokumentów w foldery i przeszukiwać je. Regularnie napływały też nowe
dokumenty z zewnątrz. Jedna z grup wymagań dotyczyła przechowywania i wykonywania okre-
ślonych zapytań, operujących na nowych dokumentach. Druga grupa wymagań mówiła, że gdy
użytkownik zmodyfikuje zawartość folderu, inny użytkownik otrzyma wiadomość e-mail z opi-
sem wprowadzonych zmian. Obie grupy wymagały mechanizmu powiadamiania, czyli specy-
ficznej możliwości architektury. Do czasu zaimplementowania tej możliwości żadna z wymaga-
nych funkcji nie mogła zostać zapewniona.
Głównym rynkiem docelowym systemu były firmy z listy Fortune 2000. Pierwotny model
biznesowy opierał się na licencjach bezterminowych lub rocznych, udzielanych konkretnemu
użytkownikowi lub na określoną liczbę jednoczesnych użytkowników. O ile jest to model popu-
larny w przypadku oprogramowania dla przedsiębiorstw, uniemożliwiał sprzedaż produktu fir-
mom prawniczym, które w rozliczeniach wymagają śledzenia użycia systemu. Dzięki współpracy
z kierownictwem produktu, zdaliśmy sobie sprawę, że moglibyśmy otworzyć się na nowy seg-
ment rynku, o ile tylko zapewniona byłaby obsługa specyficznego dla niego modelu biznesowego.
Niestety, zdefiniowanie nowego modelu biznesowego było znacznie łatwiejsze niż jego imple-
mentacja, która wymagała istotnych zmian w możliwościach wykorzystywanej architektury.
W miejsce prostego zliczania jednoczesnych użytkowników (lub rozpoznawania ich), niezbędne
było wprowadzenie kilku nowych możliwości, takich jak rejestrowanie pojedynczych zdarzeń
w zabezpieczonych plikach dziennika, które potem byłyby przetwarzane przez system księgowy.
Dopóki to nie było zapewnione, dostęp do nowego segmentu rynku pozostawał zamknięty.
Inny system, z którym miałem do czynienia, odpowiadał za tworzenie próbnych wersji
oprogramowania. Wersje próbne to potężne narzędzie marketingowe, powstające w drodze
modyfikacji gotowego produktu przy użyciu specjalnych narzędzi, zapewniających jego
trwałą ochronę. Klienci naszego systemu prosili o zwiększenie swobody w doborze ograniczeń
użytkowania. Niestety, tego pozornie prostego wymagania nie przewidywała wykorzystywana
architektura. Musiałem więc rozpocząć wprowadzanie w niej poważnych zmian, koniecznych do
wyposażenia systemu w nowe możliwości.
Typowym przykładem różnicy między funkcjami a możliwościami jest sytuacja, w której
dział marketingu żąda, aby interfejs użytkownika został zlokalizowany i był dostępny w wielu
wersjach językowych. Każdy język może być postrzegany jako osobna funkcja. Odpowiada to
często zamierzeniom marketingowym. Jednak dopóki wykorzystywana architektura nie posiada
możliwości związanych z internacjonalizacją produktu, obsługa wielu języków łatwo może stać
się koszmarem prześladującym całą organizację. Można też przytoczyć wiele innych przykładów,
zwłaszcza w obrębie oprogramowania dla przedsiębiorstw: przepływ pracy, elastyczne reguły
sprawdzania poprawności, rosnące zapotrzebowanie na dostosowywanie aplikacji i inne.
Jest jedna szczególna sytuacja, gdy cykl dojrzewania i ewolucji musi zostać złamany, a w pracach
zespołu dominują rozważania na temat możliwości, a nie funkcji. Dzieje się tak, gdy trzeba przeprowa-
dzić całkowite przeprojektowanie (przepisanie) systemu. Może to
Pobierz darmowy fragment (pdf)
