Software architecture

Z perspektywy biznesu wymagania funkcjonalne definiują oprogramowanie, które ma powstać, tylko czy wymagania funkcjonalne wystarczą, aby wytworzyć oprogramowanie? Otóż nie, ponieważ systemy dodatkowo opisywane są przez wymagania niefunkcjonalne. Jest to dość dobrze znana nazwa, natomiast samo jej przeczytanie wzbudza negatywne emocje (jak coś może być NIEfunkcjonalne).

Tutaj wjeżdżają charakterystyki architektury, czyli wymagania niefunkcjonalne, które lepiej brzmią! Tak więc architekt podczas projektowania systemu oprócz wymagań systemu musi rozważyć inne aspekty i czynniki które wpływają na oprogramowanie, takie jak np.:

• Availability – jak długo system ma być dostępny (np. 24/7), jak system ma się zachować po awarii.

• Performance – jak szybko ma działać.

• Scalability – jak ma się skalować w przypadku wzrostu liczby użytkowników.

• Extensibility – jak ważna jest możliwość rozszerzania systemu o nowe funkcje.

• Configurability – jak ważna jest możliwość konfiguracji systemu przez użytkowników.

• Upgradeability – jak łatwa będzie możliwa aktualizacja do nowej wersji.

• Authentication – jak system rozpoznaje użytkowników.

• Legal – wszystko, co związane z prawem.

• Security – wymagania odnośnie do bezpieczeństwa.

Uwaga: każdy system może mieć inne charakterystyki, o czym więcej poniżej.

---

Definicja charakterystyki architektury

Charakterystyka architektury musi spełniać trzy kryteria.

1. Opisuje cechę oprogramowania niezwiązaną bezpośrednio z wymaganiami. Wymagania funkcjonalne opisują co system ma robić, a charakterystyki architektury opisują jak ma to robić.

2. Wpływa na aspekty konstrukcyjne projektu. Jeśli security będzie jedną z charakterystyk, która opisuje system to będzie miało to wpływ na projekt systemu, ponieważ będzie trzeba zapewnić odpowiedni poziom zabezpieczeń już na etapie projektu.

3. Jest krytyczna lub ważna dla powodzenia projektu. Na etapie designu architekt musi zazwyczaj odkryć charakterystyki, które mają opisywać system i negocjować je z klientem. Każda charakterystyka zwiększa złożoność systemu, a niektóre charakterystyki się wręcz wykluczają np. jeśli postawisz na performance, to bardzo trudno będzie Ci osiągnąć dobre usability.

---

Charakterystyki architektury w praktyce

Architekci oprogramowania wykorzystują charakterystyki architektury w praktyce na różne sposoby. Na początku projektu, architekci muszą zrozumieć wymagania biznesowe i funkcjonalne systemu, a następnie określić, jakie charakterystyki są niezbędne, aby sprostać tym wymaganiom. Na przykład, jeśli aplikacja ma działać 24 godziny na dobę, 7 dni w tygodniu, to charakterystyka dostępności powinna być kluczowa.

Po wybraniu charakterystyk, architekci muszą je zintegrować w projekt systemu. Dobre podejście polega na użyciu wzorców projektowych, które pomagają w zastosowaniu charakterystyk w sposób spójny i zrozumiały dla całego zespołu. Na przykład, wzorzec projektowy “Model-Widok-Kontroler” (MVC) pozwala oddzielić logikę biznesową od logiki prezentacji, co ułatwia skalowanie systemu i zwiększa jego elastyczność.

W trakcie projektowania systemu, architekci muszą również stale monitorować i testować, czy charakterystyki architektury są spełnione. Na przykład, jeśli charakterystyka wydajności jest kluczowa dla systemu, to architekci muszą regularnie monitorować wydajność systemu i wdrażać poprawki, jeśli zajdzie taka potrzeba.

W końcu, architekci muszą pamiętać, że charakterystyki architektury są elastyczne i mogą ulec zmianie w trakcie projektu. Na przykład, jeśli wymagania biznesowe ulegną zmianie, to architekci mogą musieć dostosować charakterystyki, aby sprostać nowym wymaganiom. Dlatego tak ważne jest, aby charakterystyki architektury były traktowane jako dynamiczny element projektu, a nie jako sztywna lista wymagań.

---

Narzędzia, metody i techniki używane to odkrycia charakterystyk architektury

Przy projektowaniu systemów z uwzględnieniem charakterystyk architektury, architekci oprogramowania często korzystają z różnych narzędzi, metod i technik. Oto kilka przykładów:

• Modelowanie koncepcyjne - metoda oparta na diagramach, która pomaga w zrozumieniu wymagań biznesowych systemu i określeniu, jakie charakterystyki architektury są potrzebne.

• Modelowanie architektury - metoda oparta na diagramach, która pomaga w zrozumieniu struktury systemu i relacji między jego elementami. Często wykorzystywana do projektowania systemów z uwzględnieniem charakterystyk architektury.

• Wzorce projektowe - sprawdzone rozwiązania dla często występujących problemów projektowych, które pomagają w zastosowaniu charakterystyk architektury w sposób spójny i zrozumiały dla całego zespołu.

• Testy wydajności - testy, które pozwalają na ocenę wydajności systemu pod kątem określonych charakterystyk, takich jak czas odpowiedzi, przepustowość, zużycie zasobów itp.

• Code review - proces sprawdzania kodu źródłowego systemu, który pomaga w identyfikacji potencjalnych problemów związanych z charakterystykami architektury, takimi jak bezpieczeństwo, wydajność itp.

• Analiza ryzyka - proces oceny ryzyka związanego z charakterystykami architektury i ich wpływem na projekt systemu. Pomaga w identyfikacji potencjalnych zagrożeń i podejmowaniu działań zapobiegawczych.

Oprócz tych konkretnych narzędzi, metod i technik, architekci oprogramowania często korzystają również z innych źródeł wiedzy, takich jak książki, artykuły branżowe, konferencje i szkolenia. Ważne jest, abyś jako architekt poszerzał swoją wiedzę i umiejętności w zakresie projektowania systemów z uwzględnieniem charakterystyk architektury, aby móc tworzyć coraz lepsze i bardziej innowacyjne rozwiązania.

---

Wpływ charakterystyk architektury na projektowanie systemu

Charakterystyki architektury mają wpływ na różne aspekty projektowania systemów. Poniżej przedstawione są niektóre z tych aspektów:

Wybór technologii

Charakterystyki architektury wpływają na wybór technologii, które zostaną użyte do zbudowania systemu. Na przykład, jeśli charakterystyka wydajności jest kluczowa dla systemu, to architekci mogą wybrać technologie, które są znane z ich szybkości lub udostępniają narzędzia do optymalizacji wydajności.

Wymagania funkcjonalne

Charakterystyki architektury wpływają również na wymagania funkcjonalne systemu. Na przykład, jeśli charakterystyka wydajności jest kluczowa dla systemu, to wymagania funkcjonalne muszą uwzględniać wymagania dotyczące wydajności, takie jak czas odpowiedzi lub przepustowość.

Koszty projektu

Charakterystyki architektury mają wpływ na koszty projektu. Na przykład, jeśli charakterystyka bezpieczeństwa jest kluczowa dla systemu, to architekci muszą zainwestować w narzędzia i technologie, które pozwalają na zapewnienie odpowiedniego poziomu bezpieczeństwa. To może zwiększyć koszty projektu, ale może również pomóc uniknąć kosztownych ataków z zewnątrz.

Utrzymanie systemu

Charakterystyki architektury mają również wpływ na utrzymanie systemu. Na przykład, jeśli charakterystyka łatwości rozbudowy jest kluczowa dla systemu, to architekci muszą zaprojektować system w taki sposób, aby był łatwy do modyfikacji i rozbudowy w przyszłości. To może pomóc w utrzymaniu systemu na dłuższą metę i uniknięciu kosztownych modernizacji.

---

Podsumowanie

Charakterystyki architektury określają pracę systemu „pod spodem” i mają wpływ na całe rozwiązanie oraz nadają ramy dla systemu. Opisują jak system ma działać, podczas gdy wymagania funkcjonalne opisują co system ma robić.

Charakterystyki architektury to wymagania niefunkcjonalne, które opisują cechy oprogramowania niezwiązane bezpośrednio z wymaganiami funkcjonalnymi.

Wpływają na aspekty konstrukcyjne projektu i są kluczowe dla powodzenia projektu. Najważniejsze charakterystyki architektury to: dostępność, wydajność, skalowalność, rozszerzalność, konfigurowalność , autentykacja i bezpieczeństwo.

Architekci oprogramowania korzystają z różnych narzędzi, metod i technik, aby projektować systemy z uwzględnieniem charakterystyk architektury. Charakterystyki architektury wpływają na wybór technologii, wymagania funkcjonalne, koszty projektu i utrzymanie systemu. Ważne jest, aby charakterystyki architektury były traktowane jako dynamiczny element projektu, a nie jako sztywna lista wymagań.

Źródła

• Fundamentals of Software Architecture: An Engineering Approach. A Comprehensive Guide to Patterns, Characteristics, and Best Practices – Neal Ford (Autor), Mark Richards (Autor

• Architektura opgrogramowania w praktyce - Len Bass, Paul Clements, Rick Kazman