Wprowadzenie
Bardzo wiele emocji budzą kwestie styku aplikacji i jej środowiska: mój wpis na LinkedIn “Czy logowanie jest przypadkiem użycia” wzbudził burzliwą dyskusję i wiele kontrowersji. Ten artykuł to opis modelu aplikacji i jej środowiska.
Kluczowe pojęcia
Pojęcie aplikacja jest definiowane (SJP) jako “komputerowy program użytkowy”. Biorąc pod uwagę fakt, że słownikowo “użytkownik” to osoba (użytkownik – osoba lub instytucja użytkująca coś, SJP), aplikacja to “program użytkowy dla człowieka”.
W specyfikacji notacji UML czytamy:
Przypadki Użycia są środkiem do uchwycenia wymagań systemów, tj. tego, co systemy mają robić. Kluczowymi pojęciami
w tym rozdziale są aktor, przypadek użycia i system (modelowany podmiot). […] Użytkownicy i wszelkie inne systemy, które mogą wchodzić w interakcje z systemem, są reprezentowane jako aktor. Przypadek użycia reprezentuje specyfikacje zachowania. Instancja Przypadku Użycia odnosi się do wystąpienia pojawiającego się zachowania, które jest zgodne z odpowiednim Przypadkiem Użycia. Takie instancje są często opisywane przez Interakcje.
Pozostaje pojęcie środowisko, które definiujemy jako ogół elementów otoczenia (SJP). Tak więc można napisać: aplikacja instalowana jest w określonymi środowisku systemowym, korzystają z niej (aktor) ludzie i inne systemy.
Architektura heksagonalna
Jest to, opisany przez Cocburn’a , wzorzec architektoniczny zakładający całkowitą separację kodu aplikacji od kodu środowiska.
Wzorzec ten jest przywoływany obecnie także pod nazwą “Porty i adaptery”:
Na powyższym diagramie zilustrowano wybrane detale środowiska aplikacji. Aplikacja (jej kod) to część realizująca wymagania funkcjonalne. Środowisko realizuje wymagania poza-funkcjonalne. Środowisko to najczęściej produkty standardowe: to systemy operacyjne, środowiska programistyczne i frameworki, motory baz danych, sterowniki urządzeń (dostarczają je zwykle ich producenci) itp.
Chronologicznie wcześniej opisanym wzorcem architektonicznym jest wzorzec MVC (Model, View, Controller) . Podział na trzy części ma uzasadnienie z uwagi na typ aktora: człowiek wymaga do komunikacji klawiatury i ekranu monitora, inna maszyna (a konkretnie inna aplikacja lub komponent) jedynie wymienia komunikaty na poziomie zwanym API (Application Programming Interface). Dlatego Środowisko aplikacji jest dzielone na część User Interface (View) oraz Instrastructure (Controller). Cała logika i jej dane to Model (Application Core).
Powyższe można zilustrować tak:
Podstawowe środowisko to system operacyjny. Stanowi on standardowe środowisko dla aplikacji. System operacyjny dla aplikacji to API do sprzętu (dysku, sieć, itp.) i usług systemowych (data, sesje użytkowników, peryferia itp.) oraz sieciowych (dostęp do Internetu). Kolejne ważne pojęcie to sesja: to uwierzytelniony “dialog” ze zidentyfikowanym użytkownikiem (anonim to też forma identyfikacji sesji), i jest to funkcja środowiska. Na poniższym diagramie pokazano idee tego czym jest sesja (Application serwer to środowisko aplikacji na nim uruchamianych). Ważne: logowanie to funkcja środowiska a nie aplikacji, co pokazano np, na tym diagramie:
“Sesja” to termin odnoszący się do czasu przeglądania strony internetowej przez użytkownika. Sesja oznacza czas pomiędzy pierwszym wejściem użytkownika na stronę witryny a momentem, w którym przestaje on z niej korzystać. (https://hazelcast.com/foundations/caching/web-session/)
Kroki 4 i 5 to trwający dialog użytkownika z serwerem, jest nim najczęściej praca z aplikacją, udostępnianą przez ten serwer (który jest kontrolerem sesji, patrz Control w MVC). Zalogowanie się i praca z aplikacją wygląda tak:
Patrząc na Architekturę Oprogramowania i powyższy diagram można stwierdzić, że:
- logujemy się do środowiska, w których wykonuje się aplikacja,
- przypadki użycia aplikacji to to, co się dzieje od momentu pojawienia się na ekranie jej menu (pętla Loop na powyższym diagramie),
- zmiana sposobu uwierzytelnienia to zmiana (dodanie, wymiana) komponentu środowiska (np. dodatnie czytnika linii papilarnych i jego sterownika czy zastąpienie logowania parą login i hasło, sprzętowym kluczem, itp.),
- wiele aplikacji korzysta z bibliotek systemowych, także tych dostarczanych producentów języków programowania i frameworków,
- serwery webowe to bardzo często serwery jednej aplikacji, dlatego granica między logowaniem a pracą z aplikacją jest z reguły niewidoczna,
- środowisko uwierzytelnia sesję użytkownika, jest możliwe by aplikacja – mając numer sesji (ID użytkownika) – zarządzała własną tablicą “imię nazwisko – ID użytkownika”,
- środowisko przechowuje procedury autoryzacji do zasobów systemowych,
- aplikacja przechowuje procedury autoryzacji do komponentów (funkcji) w obszarze logiki biznesowej (dostęp do danych biznesowych itp.),
- jest możliwa komunikacja aplikacji ze środowiskiem w celu wymiany danych np. o autoryzacji do określonych zasobów (wtedy ta aplikacja musi mieć w środowisku autoryzację do takich działań).
Podsumowanie
Wzorce architektoniczne pomagają zrozumieć działania oprogramowania. Pomagają także identyfikować ryzyka związane z cyberbezpieczeństwem. Bardzo ważna jest ich znajomość i rozumienie, a jeszcze ważniejsze jest świadome stosowanie. Jednym z kluczowych zaleceń architektonicznych, także dotyczącym bezpieczeństwa, jest nie umieszczanie logiki biznesowej poza aplikacją, np. w systemie tabel baz danych (logika biznesowa i w aplikacji i w środowisku).
Bardzo znanym przypadkiem pokazującym skutki umieszczania “czegoś” w środowisku, jest firma CrowdStrike i jej produkt Falcon, który podmieniał bibliotekę systemową Windows by zmienić zachowanie się kilku funkcji bezpieczeństwa. Niestety błąd CrowdStrike spowodował, że upgrade Falcon powodował “wieszanie się” Windows: ta awaria nie była winą Microsoft (“CrowdStrike IT Outage Explained by a Windows Developer”), była winą dostawcy oprogramowania ingerującego w środowisko.
