Podstawy architektury oprogramowania dla inżynierów #1 - parametry architektury

2021-06-14

Parametry architektury

Parametry architektury spełniają trzy kryteria:

  • określają pozadziedzinowe względy projektowe,
  • wpływają na niektóre strukturalne aspekty projektu,
  • mają decydujące lub duże znaczenie dla działania aplikacji.

To cytat z M. Richardsa i N. Forda, autorów ksiązki Podstawy architektury oprogramowania dla inżynierów. Co rozumieją przez te mądrze brzmiące frazy? Rozbijmy to na części.

“Określają pozadziedzinowe względy projektowe”

W skrócie chodzi o to, że “zwykłe” wymagania określają, co aplikacja ma robić (np. wysyłać mejle). Natomiast są też takie wymogi, zwane czasami “wymaganiami niefunkcjonalnymi”, które nie określają wprost działania aplikacji, ale mówią o jej cechach, np. jaka jest spodziewana wydajność aplikacji.

“Wpływają na niektóre strukturalne aspekty projektu”

Wybór konkretnej zewnętrznej usługi, która będzie wysyłać mejle (np. SendGrid) nie rzutuje na projekt tak, że zmiana dostawcy wywraca całą architekturę do góry nogami. Jeśli jednak warunkiem jest audytowalność (np. ze względów prawnych), wówczas może to wpływać na cały projekt.

“Mają decydujące lub duże znaczenie dla działania aplikacji”

Innymi słowy - nie każde “wymaganie niefunkcjonalne” jest tak samo ważne w danej aplikacji. W systemie do streamowania rozgrywek piłkarskich wydajność można być szczególnie ważna, gdy tymczasem w systemie bankowym jedną z głównych cech będzie bezpieczeństwo. Parametrami architektury będą dla danej aplikacji te cechy, które są szczególnie istotne - niby każdy projekt powinien być bezpieczny, ale np. w bankowości będzie to szczególnie istotne.

Typologia parametrów architektury

Istnieją dwa rodzaje parametrów architektury - sprecyzowane i dorozumiane. To ważne wyszczególnienie, bo nie wszystkie parametry architektury muszą być spisane na papierze explicite jako “wymagania niefunkcjonalne_.

Lista parametrów architektury

Niepełna lista parametrów architektury (moje własne “tłumaczenia” na angielski, gdyż w książce są stosowane polskie terminy, które sieją zamęt):

  • availability - czyli dostępność w czasie (jaką część czasu system może być wyłączony z użycia),
  • continuity - zdolność do przywrócenia do działania po awarii (tego trochę nie rozumiem…),
  • performance - wydajność, czyli jakie obciążenie ma system przyjmować,
  • recoverability - jak szybko system ma wracać do działania po awarii oraz czy możemy sobie pozwolić na utratę danych,
  • reliability - czy w przypadku nieprawdiłowego działania firma będzie narażona na duże koszty?
  • durability ? - odporność na błędy, np. brak połączenia sieciowego,
  • scalability - skalowalność,
  • configurability - konfigurowalność,
  • extendability - czy to się nie zawiera w poprzednim?
  • setupability - instalowalność na różnych platformach,
  • reusability
  • localizability - wsparcie dla wielu języków i regionalnych formatów danych,
  • supportability - łatwość w utrzymaniu (czy to nie jest za ogólne? i czy chodzi o wsparcie oferowane użytkownikom/klientom?),
  • portability - możliwość działania na różnych platformach (np. zmiana bazy danych - ?),
  • updateability - łatwość aktualizowania wersji aplikacji
  • accessibility - a11y
  • archivability - inaczej retencja danych
  • authenticaton - uwierzytelnianie
  • authorization
  • legal requirements - czy są jakieś sepcjalne wymagania prawne (np. RODO)?
  • privacy - możliwość ukrywania danych przed wewnętrznymi pracownikami firmy (np. dział IT w banku nie może zajrzeć Ci wprost na konto),
  • safety - bezpieczeństwo rozumiane jako zapobieganie przed nieautoryzowanym dostępem np. przez szyfrowanie danych,
  • usability - użyteczność

Lista jest długa, mnie dziwi obecność niektórych cech, które bardziej bym przypisał już do poziomu konkrentego rozwiązania technicznego, a nie do poziomu architektury (trudno mi wyobrazić sobie jak dostępność dla osób z niepełnosprawnościami miałaby wpływać znacząco na architekturą) - ale trzeba przyznać, że jest w miarę wyczerpująca.

P.S. Wpis jest częścią cyklu, będącego serią notatek z lektury książki pt. Podstawy architektury oprogramowania dla inżynierów, autorstwa Marka Richardsa i Neala Forda.


Robert Skarżycki - zdjęcie profilowe

Pisanina, której autorem jest Robert Skarżycki - programista .NET, mąż szczęśliwej żony, rodzic
moje bio
mój Twitter
mój LinkedIn
moje szkolenia i warsztaty

© 2022, Built with Gatsby & passion