............................................................................................... 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 czynniki, 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, Journey of the Software Professional:
Architektura systemu określa podstawową „strukturę” systemu (moduły wysokiego poziomu, które realizują główne funkcje systemu, zarządzanie i rozkład danych, rodzaj i charakter 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 wymagania użytkowników systemu. Mój współpracownik, Myron Ahn, stworzył definicję architektury oprogramowania, którą przytaczam poniżej. Jest nieco bardziej rozbudowana i szersza niż ta, którą przedstawił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 zagadnień, 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 biznesowej. 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 decyzji jest fakt, że pracę nad podsystemami rzadko dzieli się pomiędzy różnych wykonawców.
Podsystemy a motywacje i dążenia