Architektura Oprogramowania

Dlaczego warto tworzyć Architekturę Oprogramowania?

Podstawowym celem tworzenia Architektury Oprogramowania jest identyfikacja wymagań, które bezpośrednio wpływają na strukturę, sposób działania oprogramowania.

Pozwala także określić przypadki użycia oraz scenariusze użycia.

Daje możliwość uzgodnienia wymagań funkcjonalnych oraz niefunkcjonalnych, głównie odnoszących się do jakości. 

Architektura Oprogramowania jest narzędziem pozwalającym:

• poprawić, usprawnić komunikację w zespole developerskim oraz szerzej, jest przydatna wszystkim interesariuszom
• pozwala racjonalnie analizować oraz dopasować tworzony system do wymogów technicznych, biznesowych i operacyjnych
• przyspieszyć prace programistyczne
• precyzyjniej zaplanować prace, określić ich poszczególne etapy
• trafniej ewaluować postępy prac
• lepiej zarządzać projektem
• zmniejszyć ilość błędów oraz obniżyć kosztowność poprawek
• nadać projektowi ramy czasowe i organizacyjne, określić zakres ról, kompetencji, działań.

Generalnie, użyteczność tworzenia Architektury Oprogramowania rośnie wraz ze złożonością projektu.

Stworzenie Architektury Oprogramowania nie jest zadaniem łatwym. 

Trudność Architektury Oprogramowania wynika przede wszystkim z:

• złożoności tworzonego systemu
• różnorodności oczekiwań, celów oraz środków, używanych do ich osiągnięcia
• wielości interesariuszy, którzy reprezentują różne oczekiwania (np. business managers, owners, users).

Architektura Oprogramowania, by spełniała swoją funkcję, powinna być tworzona przez doświadczonego architekta oprogramowania, który dysponując wiedzą ekspercką jest w stanie stworzyć wysokopoziomowy projekt systemu oraz zarządzać jego wytworzeniem.

Efektem jego prac powinien być dokument (Software Architecture Description), w którym uwzględniono wymagania biznesowe oraz technologiczne.

Sam dokument jest tworzony na bazie zebranych od poszczególnych interesariuszy wymagań, w szczególności chodzi o wymagania:

• funkcjonalne
• niefunkcjonalne.

Architektura Oprogramowania powinna także zawierać informacje dotyczące wszelkich ograniczeń, jakim projekt, przyszła aplikacja będzie podlegać. 

Do najbardziej typowych ograniczeń należą:

• brak metod analitycznych, które jednoznacznie rozstrzygają, czy system spełnia oczekiwania
• problemy komunikacyjne między interesariuszami
• brak dedykowanego architekta oprogramowania.

Warto także pamiętać, że aplikacje mobilne i aplikacje webowe mogą być budowane w różny sposób.

Wybór najbardziej adekwatnego, wydajnego, użytecznego sposobu jest uwarunkowany:

• doświadczeniem i wiedzą architekta oprogramowania
• zakresem kompetencji zespołu developerskiego
• kosztem, budżetem projektu
• czasem dostępnym na jego wykonanie
• czasem koniecznym do implementacji konkretnych rozwiązań
• otoczeniem biznesowym, w jakim firma funkcjonuje.

W literaturze przedmiotu znajdziemy wiele:

• koncepcji opisu Architektury Oprogramowania
• metodyk budowy systemów informatycznych
• języków opisu Architektury Oprogramowania.

Również wybór najlepszej, najbardziej pomocnej formuły jest kwestią doświadczenia, wiedzy oraz specyfiki samego oprogramowania i celów biznesowych, jakie ma realizować. 

Każda z koncepcji, metodyk, każdy język nie jest pozbawiony wad, stąd też bardzo istotne jest doświadczenie, które pozwala korzystać z tych narzędzi w sposób bardziej świadomy ryzyk, konsekwencji oraz ograniczeń.

W procesie projektowania Architektury Oprogramowania istotną rolę odgrywa:

• analiza architektoniczna
• synteza architektoniczna
• ocena architektury
• ewolucja architektury.

Synteza architektoniczna skupia się na wymaganiach określonych w wyniku analizy i łączy je z aktualnym stanem projektu, z oceną, w jaki sposób projekt jest tworzony.

Podobnym celom służy ocena architektury, przy czym jest ona dokonywana najczęściej po zakończeniu danego etapu tworzenia systemu.

Z kolei ewolucja architektury jest procesem utrzymywania i dostosowywania istniejącej architektur oprogramowania do zmian zachodzących w środowisku.

Ewolucja architektury najczęściej polega na poszerzaniu funkcji oraz utrzymaniu dotychczasowych funkcjonalności. Na ich wzajemnym dostosowywaniu.

Jakie są najważniejsze rodzaje Architektury Oprogramowania?

Wraz z rozwojem technologii programistycznych, zmieniających się standardów zmieniało się także podejście do projektowania Architektury Oprogramowania.

Aktualnie najbardziej popularnymi sposobami tworzenia Architektury Oprogramowania są:

• architektura monolityczna (monolit)
• Architektura Zorientowana na Usługi (SOA - Service-Oriented Architecture)
• architektura mikroserwisów

Architektura monolityczna charakteryzuje się połączeniem i współzależnością wszystkich jej elementów składowych.

Monolity działają w oparciu o pojedynczy plik, co oznacza, że wszystkie funkcje aplikacji są wdrażane w ramach pojedynczej jednostki.

Do głównych zalet architektury monolitycznej należy większa wydajność, brak modułowości, prostota wdrożenia, także większa łatwość jej testowania i wykrywania błędów.

Niestety to rozwiązanie ma także swoje wady. 

Każda zmiana kodu wpływa na działanie całego systemu. A to oznacza konieczność sprawdzania całego kodu aplikacji, po każdej aktualizacji.

Architektury monolityczne są także bardziej problemowe pod względem skalowalności. Skalowaniu podlega cała aplikacja, nie ma możliwości skalowania jej poszczególnych elementów. Co nie zawsze jest pożądane. 

Istotą architektury SOA, jak sama nazwa wskazuje, są usługi, a więc te elementy oprogramowania, które są niezależne od pozostałych oraz, które posiadają osobny interfejs.

Mówiąc jeszcze nieco innym językiem, usługami są te funkcje, które pozwalają ich użytkownikom wykonywać zadania oraz osiągać cele.

Architektura SOA pozwala realizować różnorodne cele biznesowe za pomocą zintegrowanych, ale niezależnych elementów.

Najważniejszą zaletą tego rodzaju architektury jest możliwość szybkiej, stosunkowo nie problematycznej integracji systemu z nowymi, dodatkowymi komponentami.

Architektura SOA daje także możliwość wykorzystywania różnorodnych technologii, które są udostępniane za pomocą niezależnego protokołu komunikacyjnego.

Najprościej rzecz ujmując, architektura mikroserwisów polega na tworzeniu aplikacji za pomocą wielu, luźno, bądź wcale ze sobą nie powiązanych usług.

Jest ona rekomendowana organizacjom, które dynamicznie rozwijają swoje produkty cyfrowe, którym zależy na skalowalności biznesu.

Niezależność poszczególnych usług, pozwala je rozwijać, bez ryzyka wpływu zaimplementowanych zmian na całość systemu.

Co jeszcze ważniejsze, poszczególne usługi mogą być tworzone w różnych technologiach, przez różnorodnych dostawców. 

Architektura mikroserwisów zapewnia także większe bezpieczeństwo, wydajność oraz stabilność systemu. Błąd w danej usłudze nie wpływa, nie zakłóca działania pozostałych.

Wadą tego rodzaju architektury jest jej złożoność technologiczna, wiążąca się z koniecznością posiadania szerokich kompetencji, doświadczeń technologicznych.

Także związanych z integracją oprogramowania z zewnętrznymi usługami. Architektura tego rodzaju może być także problematyczna w czasie testów. 

Dobre praktyki związane Architekturą Oprogramowania

Projektowanie Architektury Oprogramowania doczekało się wielu omówień oraz obfituje we wzorce dobrych praktyk, które pozwalają:

• minimalizować błędy
• czynić dokument Architektury Oprogramowania bardziej komunikatywnym
• poprawiać przepływ pracy oraz wiedzy
• zarządzać projektem
• optymalizować procesy analizy, syntezy, oceny oraz ewolucji
• sprawniej podejmować decyzje.

Dobre wzorce najczęściej odnoszą się do:

• zarządzania wiedzą
• zarządzania komunikacją wewnątrz zespołu oraz komunikacją wszystkich interesariuszy
• sposobów podejmowania decyzji projektowych
• wytwarzania dokumentacji projektu.

Niezwykle istotny w tym procesie jest przepływ wiedzy, której niekompletność może skutkować błędnym lub niekompletnym projektem Architektury Oprogramowania.

Znaczącą rolę w usprawnieniu tego procesu odgrywają wzorce projektowe, prototypy, analizy analogicznych produktów cyfrowych, które powinny być dokumentowane i udostępniane wszystkim interesariuszom.

Podejmowanie decyzji projektowych jest kwestią skutkującą wieloma problemami oraz ryzykami.

Warto pamiętać, że podejmowanie decyzji jest działaniem wielowymiarowym o różnym zakresie skutków oraz odbywa się na różnych poziomach ogólności / szczegółowości.

Świadomość różnorodnych konsekwencji pozwala uzyskiwać w sposób efektywniejszy, szybszy kompromisy między różnymi oczekiwaniami, uwarunkowaniami.

Dokumentowanie wszelkich informacji, działań, materiałów pomocniczych jest niezwykle istotne.

Dokument zawierający Architekturę Oprogramowania powinien zawierać widoki statyczne (struktury kodu) i dynamiczne (działanie systemu), opisy, notacje, specyfikacje.