Architektura
Projekty informatyczne się rozrastają, cała branża ewoluuje. Ostatnie 20 lat doświadczeń pokazało, że owszem sztuką jest stworzyć i wdrożyć oprogramowanie, ale jeszcze większą sztuką jest je konserwować, zmieniać i rozwijać. Wiele firm boryka się z powtarzanymi długotrwałymi i kosztownymi „analizami przedwdrożeniowymi” poprzedzającymi każdy kolejny projekt wdrażania zmian. To skutek braku aktualnej dokumentacji posiadanego systemu. To jak planowanie nowej budowy w mieście nie mając aktualnych planów urbanistycznych tego miasta: każdy nowy projekt to ponowne dokumentowanie stanu obecnego, tylko dlatego, że ktoś nie udokumentował zmian wprowadzonych ostatnim razem (być może poprzednio udokumentował jakiś stan zastany, jednak nie aktualizował tej dokumentacji). Podobno developer pamięta co mają jego klienci, jednak zmiana developera staje się wtedy trudna, a nie raz niemożliwa z powodu złej umowy (prawo autorskie) i braku dokumentacji (wiedza w głowach programistów, wdrożeniowców, bywa, że nigdzie), to efekt znany jako vendor lock-in.
Rozwiązaniem jest dokumentacja systemu. Co jest głównym wyzwaniem w tworzeniu dokumentacji systemu? Ustalenie kompromisu między szczegółowością dokumentacji a czasem i kosztem jej opracowania a potem aktualizacji. Tym kompromisem jest architektura: struktura opisująca co i do czego służy: elementy systemu i ich wzajemne powiązania, ale bez angażowania się w dokumentowanie detali tych elementów (hermetyzacja). To dlatego bardzo przydatne jest komponentowe podejście do projektowania i obiektowy paradygmat tworzenia oprogramowania.
Dzisiaj kilka słów o trzech książkach, każda z nich była na tym blogu krótko recenzowana, razem stanowią moim zdaniem podstawowy zestaw projektanta. Pod pojęciem projektowania rozumiemy tworzenie projektu systemu czyli dokumentowanie tego jakim ma być, lub jakim jest i co w nim zmienimy.
Dokumentowanie architektury
Ta książka to rodzaj podsumowania. We wstępie czytamy:
„Architektura oprogramowania – koncepcyjny klej, który spaja każdą fazę projektu, dla jego wielu interesariuszy – jest powszechnie uznawana za krytyczny element współczesnego rozwoju oprogramowania. Praktycy coraz częściej przekonują się, że poświęcanie szczególnej uwagi architekturze systemu oprogramowania przynosi wymierne korzyści. Bez architektury, która jest odpowiednia dla rozwiązywanego problemu, projekt będzie się potykał, a najprawdopodobniej zakończy się niepowodzeniem. Ale nawet przy doskonałej architekturze, jeśli nie jest ona dobrze rozumiana i przekazywana, projekt ma małe szanse powodzenia.
Książka Documenting Software Architectures, dostarcza najbardziej kompletnych i aktualnych wskazówek, niezależnie od języka czy notacji, jak ująć architekturę w powszechnie zrozumiałej formie. Bazując na swoim bogatym doświadczeniu, autorzy najpierw pomagają zdecydować, jakie informacje należy udokumentować, a następnie, za pomocą wskazówek i przykładów (w różnych notacjach, w tym UML), pokazują, jak wyrazić architekturę, aby inni mogli na jej podstawie z powodzeniem budować, używać i utrzymywać system. Książka zawiera zasady tworzenia solidnej dokumentacji, cele i strategie dokumentacji, widoki i style architektoniczne, dokumentację interfejsów oprogramowania i zachowania oprogramowania oraz szablony do zbierania i organizowania informacji w celu stworzenia spójnego pakietu.
Zdaniem autorów kluczem są pojęcia: element systemu, jego cechy i związki między tymi elementami. Zwracają uwagę na to, że związek między elementami to ich wzajemne wywoływanie się (współpraca to nie relacje a użycie). Mając model pojawia się druga ważna rzecz: adresaci informacji czyli perspektywy opisu systemu. Dlatego kolejna istotna rzecz to treść i forma prezentowania kontekstu.
Kolejna książka to Architektura Oprogramowania w Praktyce . Ze wstęu: „Wielokrotnie nagradzana i ciesząca się dużym zainteresowaniem Architektura oprogramowania w praktyce, wydanie trzecie, została znacząco zmienione, aby odzwierciedlić najnowsze osiągnięcia w tej dziedzinie. W książce po raz kolejny przedstawiono koncepcje i najlepsze praktyki architektury oprogramowania – strukturę systemu oprogramowania oraz sposób, w jaki jego elementy mają ze sobą współdziałać.
W tym wydaniu autorzy skupili się na koncepcji rozwoju architektury. Każdy cykl rozwoju pokazuje, w jaki sposób architektura wpływa na określony kontekst, w którym odgrywa kluczową rolę, oraz jak jest kształtowana przez ten kontekst. Konteksty te obejmują środowisko techniczne, cykl życia projektu, profil biznesowy organizacji oraz praktyki zawodowe architekta. Autorzy znacznie rozszerzyli także omówienie atrybutów jakości, które pozostają centralnym elementem ich filozofii architektury – każdemu z atrybutów poświęcili cały rozdział – oraz rozszerzyli omówienie wzorców architektonicznych.”
Autorzy ciekawie prezentują to jak i po co powstaje dokumentacja: procesowo. Streszczają (prezentują) treść książki w postaci kilku prostych modeli procesów:
Ta forma bardzo mi się spodobała: pokazuje bodźce, model (artifact) logiki i efekt uzyskany. Generalnie autorzy w swojej książce prezentują praktyczne aspekty dokumentowania oprogramowania i stosowania tej dokumentacji. Pamiętajmy także, że dokumentacja oprogramowania to przede wszystkim jego modele.
Na koniec zostawiłem książkę najstarszą: Large-Scale Software Architecture .
Jak piszą autorzy, celem projektowania (dokumentowania) architektury dużych aplikacji jest uchwycenie i opisanie praktycznych metod jego zobrazowania (udokumentowania), mających na celu zwiększyć efektywność komunikacji zespołów programistów i ich zrozumienia kontekstu systemu.
W tej książce autorzy pokazują, jak wykorzystać architekturę oprogramowania już jako narzędzie na etapie zarządzania rozwojem aplikacji, nie tylko jako powykonawczą dokumentację po podjęciu wszystkich decyzji projektowych. Prezentują w swojej książce:
- Zwięzły opis wykorzystania języka UML w architekturze dużych aplikacji,
- Architekturę oprogramowania i zasady jej projektowania,
- Zwracają uwagę na jej niezależność od technologii i dostawców.
Tę książkę można podsumować tak: każda architekturę należy dokumentować od ogółu do szczegółu, każdy model powinien być prosty i zwięzły ale modeli tych może być wiele, każdy system to jego kluczowa rola, jego wewnętrzna struktura i zachowania jego składowych elementów oraz jego pojęciowy dziedzinowy ogólny opis.
Podsumowanie
Powyższe opisy to kluczowe cechy każdej z tych trzech pozycji. Moją intencją było polecenie tych trzech pozycji jako zestawu prezentującego dość kompletną wiedzę na temat stanu wiedzy na temat projektowania oprogramowania skupiającego się na jego architekturze. Jako efekt uzyskujemy dokumentację relatywnie szczupłą objętościowo, więc będzie czytana. Stosowanie standardu notacyjnego, jakim jest UML, uzyskujemy szeroki zasięg odbiorców i uniwersalność. Zwracają na to uwagę autorzy wszystkich tych trzech pozycji.
Ostatnia pozycja to klasyka komponentowego podejścia do projektowania. Pierwsze dwie powstały kilka lat po fascynacji autorów zwinnym podejściem (agile). Podobnie jak Scott Ambler , odkryli że zbytnie przykładanie wagi do „działającego oprogramowania” na niekorzyść jego dokumentacji, powoduje szkody na kolejnych etapach cyklu życia produktu jakim jest aplikacja.
Żadne oprogramowanie nie powstaje tylko na jeden dzień, będzie komuś służyło miesiącami, latami, a świat nie stoi w miejscu. stawianie tezy, że celem tworzenia oprogramowania jego powstanie jest szkodliwe. Kluczem jest cykl życia oprogramowania, a jego dokumentacja to jedyna forma komunikowania się zmieniających się osób, latami zaangażowanych w utrzymanie i rozwój aplikacji.
Te trzy książki to moim zdaniem mały zbiór rzetelnej wiedzy, który powinien pomóc każdemu początkującemu i zagubionemu „juniorowi analizy biznesowej” w nauce tworzenia wysokiej jakości dokumentacji. To także wiedza przydatna dla doświadczonych analityków i projektantów: zawsze warto wiedzieć jak robią to inni, mający ogromny dorobek. Dokumentacja systemu to jedyne trwałe źródło wiedzy o nim, jednak zła i nieaktualna dokumentacja jest gorsza od jej braku…
