
Wymagania pozafunkcjonane czyli jaka architektura
Poza wymaganiami funkcjonalnymi, podajemy tak zwane wymagania poza-funkcjonalne. Mają one, między innymi, ważna rolę do spełnienia. Jaką?
Najpierw cytat:
Technologia klient/serwer jest zależna od komunikacji pomiędzy poszczególnymi komputerami. Sieci LAN i WAN stają się znacznym wydatkiem oraz wymagają dużych nakładów pracy w związku z zarządzaniem nimi. Co więcej, zmiana wersji oprogramowania na wielu komputerach, co szczególnie widoczne jest w przypadku przetwarzania rozproszonego, staje się istotnym problemem. Wielokrotnie działy IT zastanawiają się nad przejściem na strukturę Internet/Intranet w celu rozwiązania tego problemu. (Wstęp do ERP – technologia u podwalin przedsiębiorstwa).
Pomijając „prostotę” tego tłumaczenia, chcę zwrócić uwagę na ważną rzecz: bardzo duże znacznie ma architektura systemu, niestety wielu producentów ukrywa zastosowaną technologię i architekturę. Jedną z przyczyn jest to, że są to nie raz technologie rodem z lat 90-tych a bywa, że nawet wcześniejsze. Jedną z takich „staroci” jest architektura client-server (tak zwany gruby klient). Innym typem „dinozaura” technologicznego jest tworzenie oprogramowania, w którym logika biznesowa jest w jakiejś części w procedurach wbudowanych bazy danych (w rozumieniu konkretnego tak zwanego motora SQL bazy).
Jaki mamy wybór?
Zanim powiemy sobie o wyborze, kilka słów na temat klasycznej trójwarstwowej architektury jako fundamencie dalszych rozważań. Struktura taka wygląda następująco:
Mamy tu trzy warstwy: Warstwa prezentacji, czyli komponent odpowiedzialny za wyświetlanie informacji na ekranie użytkownikowi i ich przyjmowanie. Warstwa logiki aplikacji podzielona na Logikę dziedzinową (część specyficzna dla dziedziny problemu, tu są np. faktury, sposób naliczania podatków, rabatów itp. ta część realizuje wymagania funkcjonalne) oraz Logikę poza-dziedzinową (wydajność, niezawodność, bezpieczeństwo, integracja z innymi aplikacjami itp.). Najniżej jest warstwa Utrwalania, coraz częściej w paradygmacie obiektowym pomijana na tym poziomie abstrakcji (utożsamiana z realizacją wymagań poza-funkcjonalnych związanych z zachowywaniem informacji).
Praca w sieci wielu użytkowników to wielodostęp (wiele stacji roboczych korzysta z jednego serwera):
Gruby klient
Gruby klient to architektura w której każdy użytkownik ma na swoim lokalnym komputerze nie tylko warstwę prezentacji ale także całą logikę aplikacji. Każde takie stanowisko komunikuje się z serwerem danych:
Do powyższej architektury odnoszą się główne uwagi o wadach z cytatu na początku. Cechy architektury po lewej stronie: kosztowne stacje robocze (muszą, każda, udźwignąć całe oprogramowanie), kosztowna administracja (niezgodność wersji na stacjach roboczych może prowadzić do krachu systemu), kosztowne modyfikacje (także z uwagi na wymaganą zgodność oprogramowania na stacjach roboczych), bardzo duże wymagania na pasmo i niezawodność sieci (duże transfery danych pomiędzy stacjami roboczymi i serwerem, zerwanie połączenia powoduje blokady dostępu do danych) powodują, że praca w sieci rozległej terytorialnie może być wręcz niemożliwa (wtedy wymaga powielania instalacji w każdej lokalizacji i synchronizacji danych, kolejne niemałe koszty). Pewną odmianą jest wariant po prawej stronie, gdzie część logiki aplikacji jest umieszczona na serwerze danych (konkretnie bazy danych), powoduje to nieco zmniejszony ruch w sieci ale dodatkowo komplikuje wszelkie rozszerzenia funkcjonalności i upgrade oraz praktycznie uniemożliwia zmianę (wybór) producenta bazy danych. Duże koszty tej architektury dodatkowo potęguje wymóg wykupienia licencji na bazę danych dla każdego użytkownika.
W większości przypadków tej architektury, logika biznesowa (dziedzinowa) nie jest separowana od reszty, w efekcie dodatkowo wszelkie prace dostosowawcze są bardzo kosztowne (ingerencja w całą aplikację).
Architektura internetowa – cienki klient
Taką nazwę od pewnego czasu nadaje się architekturze opartej na dostępie do aplikacji z pomocą przeglądarki WWW:
Powyższa architektura praktycznie nie ma żadnej wady poprzedniego rozwiązania. Dodatkowo baza danych licencjonowana jest z reguły na aplikację a nie na każdego użytkownika (czyli jest taniej). Stosując tak zwane metody i architektoniczne wzorce obiektowe (najpopularniejszy to MVC: Model, View, Controller) separuje się komponent logiki biznesowej od logiki sterowania aplikacją. W efekcie dostosowanie aplikacji nie polega na kosztownym modyfikowaniu logiki aplikacji, dodaje się i integruje niezależny komponent Logiki biznesowej, co dodatkowo pozwala zachować separację praw autorskich do kodu logiki biznesowej (know-how firmy). Korzyścią takiej architektury jest także możliwość łatwego dodawania możliwości dostępu z innych niż komputer PC, urządzeń (smartfony, tablety, itp.) gdyż wymaga to wyłącznie nowej warstwy prezentacji, logia pozostaje spójna na serwerze.
Kolejna korzyść to łatwa integracja z innymi aplikacjami. Oprogramowanie w tej architekturze „ukrywa” dane, dostęp do nich jest wyłącznie przez Logikę aplikacji za pośrednictwem tak zwanych API (interfejs programistyczny) metodami znanymi w sieci WWW, unikamy kosztownych i ryzykownych łączy bezpośrednich do baz danych (niska pracochłonność integracji, bardzo wysokie koszty utrzymania i rozwoju).
W efekcie rekomendowana architektura mogła by wyglądać tak:
Zalety: niskie koszty utrzymania systemu i infrastruktury, separacja logiki biznesowej (dziedzinowej) dedykowanej od „kupionej”, łatwość i niski koszt upgrade, praca z pomocą przeglądarki WWW, łatwa integracja z innymi aplikacjami, łatwość pracy w sieci lokalnej i rozległej (w tym łatwy zdalny dostęp z dowolnego cudzego komputera). To tylko główne korzyści.
Wymagania pozafunkcjonalne
Jak wspomniałem, wielu dostawców oprogramowania jak Rejtan, broni się przed ujawnianiem architektury, swoich produktów. Głównym powodem jest zapobieganie przedwczesnego wyjawienia opisanych wyżej wad systemów z grubym klientem (znacznie rzadziej spektakularny pomysł, w końcu mamy jednak jakieś standardy). Przypadki, w których zakup systemu był relatywnie niski ale koszt utrzymania, rozwoju i dostosowania nie raz wręcz ogromny, to z reguły właśnie zakup systemu w tej kosztownej architekturze.
Jak starać się tego unikać? Na etapie definiowania wymagań poza-funkcjonalnych, żądać takich cech jak opisane powyżej czyli własnie: dostęp do całości przez przeglądarkę WWW, niskie wymagania na łącza przy zdalnej pracy i pracy w sieci rozproszonej terytorialnie, oddzielenie komponentu z własną dedykowaną logiką biznesową.
[2015]
Polecam pogadanke M.Fowlera na temat roli architektury:

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.