Strona poświęcona mojej pracy naukowej i usługom jakie świadczę polskim podmiotom. Zapraszam tych którzy szukają wiedzy i tych którzy szukają wsparcia w swoich projektach informatyzacji.
Cyfrowa Transformacja Organizacji: analizy systemowe przedsiębiorstw, projektowanie rozwiązań i przygotowanie do wdrożeń systemów standardowych i dedykowanych.
W 2015 roku pisałem o komponentowej architekturze w kontekście dużych aplikacji biznesowych:
Idąc w stronę komponentów i dużych złożonych systemów warto skorzystać z podejścia polegającego na tworzeniu (kupowaniu) tak zwanych mikroserwisów, czyli wąsko specjalizowanych dziedzinowych aplikacji (wręcz pojedynczych grup przypadków użycia). Paradoksalnie to bardzo ułatwia projektowanie, implementację a przede wszystkim obniża koszty utrzymania całego systemu. Brak złożonych połączeń między komponentami (współdzielona baza danych, złożone interfejsy) pozwala na to, by cykle ich życia były także niezależne (wprowadzane zmiany także). (Granice kontekstu i mikroserwisy )
Dwa lata później w tekście będącym kontynuacją:
Takie podejście pozwala tworzyć szybciej przy minimalnym ryzyku pojawienia się potrzeby re-faktoringu całości a także czyni aplikację łatwą do tworzenia w zespole i późniejszej rozbudowy ?(Gage, 2018)?. Rosnąca popularność tej architektury, tylnymi drzwiami powoli ruguje z rynku monolity ERP, które (niektóre) podlegają re-faktoringowi (ich producenci nie chwalą sie tym bo to powolny i bardzo kosztowny proces). Te systemy, które nadal są oparte na fundamencie jednej bazy danych z integracją bazująca na współdzieleniu danych, powoli przegrywają kosztami. (Mikroserwisy c.d.?)
Dzisiaj opiszę jak na etapie analizy i projektowania opracować model PIM (Platform Independent Model) , w taki sposób by stanowił projekt techniczny aplikacji webowej dla developera.
Aplikacja webowa czyli co?
Pod tą nazwą kryje się architektura fizycznie oparta na serwerze z właściwą aplikacją i prostym (cienkim) klientem uruchamianym w przeglądarce internetowej.
Od strony logiki działania jest to po prostu wielodostępna aplikacja na serwerze. To jak fizycznie rozlokujemy komponenty tej aplikacji, jest już zadaniem z obszaru optymalizacji.
W najprostszy sposób można to przedstawić jak poniżej:
Ta architektura pokazuje dwuczęściowe środowisko aplikacji webowych: środowisko aplikacji centralnej (serwer aplikacyjny), oraz środowisko odpowiedzialne za interakcję z użytkownikiem czyli przeglądarka internetowa. Jednak przeglądarka internetowa to także złożone środowisko:
Projektując aplikacje internetowe warto, na etapie projektowania mechanizmu działania logiki, idealizować projekt do modeli PIM.
Ważne jest to, że Strona WWW i Aplikacja, to tak na prawdę jeden system . Z perspektywy developera może to wyglądać np. tak:
Celowo przytaczam tu powyższy model, gdyż pokazuje on także komponenty „techniczne”. Z perspektywy wzorca MVC (Model, View, Controller) na powyższym diagramie View to „Prezentation”, Model to praktycznie tylko „Business”, cała reszta to Controller. Biorąc pod uwagę fakt, że poza komponentem Business, wszystkie pozostałe to wykorzystywany framework (biblioteki), developer ma dwa podstawowe zadania: zestawić środowisko i zabezpieczyć realizację wymagań pozafunkcjonalnych (w szczególności wydajność i bezpieczeństwo) oraz wykonać implementację dostarczonego mu projektu komponentu Business wyrażonego jako PIM (Model wg. MVC).
Od tego momentu zajmę sie wyłącznie komponentem PIM (czyli tak na prawdę Model Dziedziny Systemu).
Mikroserwisy
Jak już wspominałem na początku, mikro-serwisy to wzorzec architektoniczny zakładający realizację usług aplikacyjnych w postaci odrębnej (hermetyzowanej) implementacji każdej z nich. Poniżej często spotykane w sieci porównanie architektury monolitycznej z mikro-serwisami:
Bardzo ważne jest to, że żadna z tych wersji nie koliduje z przedstawionym na początku modelem aplikacji webowej. Innymi słowy: aplikacja webowa także może być ciężkim monolitem (i nie raz tak własnie jest). Bardzo ważne jest to, że aplikacje klasyfikowane jako SOA (Service Oriented Architecture, architektura zorientowana na usługi) to także bardzo często monolity, na co autor wyżej cytowanego artykułu wraca uwagę prezentując to tak:
Generalnie kluczową cechą micro-serwisów, czyniącą z nich tak zwaną zwinną architekturę, jest całkowita niezależność implementacji poszczególnych usług aplikacyjnych.
Rozwój wzorców architektonicznych jest często przyrównywany do darwinowskiej ewolucji gdyż, gorsze wzorce są wypierane przez lepsze a mikro-serwisy wydają się jednak znacznie lepszą architekturą, w czasach szybkiej zmienności wymagań i otoczenia biznesowego, niż monolity .
Podsumowanie
O obiektowym projektowaniu i stosowaniu przypadków użycia napisałem tu już wiele, dlatego na zakończenie pokaże kolejne etapy analizy i projektowania obiektowego z użyciem UML bez dokładnego omawiania.
Pokazano schematycznie mechanizm projektowania i funkcjonowania aplikacji internetowych i jedną z możliwych architektur jaką są mikro-serwisy. Uzupełnienie tego projektu o (opisywane nie raz na tym blogu): struktury formularzy, słownik etykiet pól, reguły ich walidacji, brakujące diagramy sekwencji, ewentualne algorytmy, być może struktury wewnętrzne (wewnętrzna architektura) mikro-serwisów, da w efekcie Projekt Techniczny Oprogramowania. .
Uwaga na zakończenie: wycena aplikacji metodą punktów funkcyjnych (lub COSMIC) nie jest tu możliwa, gdyż metody te opierają sie na monolitycznych architekturach opisywanych przypadkami użycia. Do wyceny wymagany jest projekt architektury jak wyżej. W przeciwnym wypadku pozostają metody T&M wraz z całym ich ryzykiem.
Wynaturzenia
Niestety development bez biznesowego zrozumienia specyfiki architektury modelu dziedziny systemu prowadzi do wynaturzeń. Uznanie, że mikroserwisy to samodzielne i niezależne implementacje operacji, prowadzi do zwykłego śmietnika. Mikroserwis to coś co opisano na początku tego pomysłu: to samodzielne mikroapliakcje, to co zaczęło powstawać pod nazwą mikroserwis niemile zaskakuj samych programistów (patrz ponizszy artykuł o NetFlix).
Dlatego chyba dla odróżnienia od powyższego bałaganu powstało pojęcie mikroaplikacji (MicroApp). Jest definiowane bardziej precyzyjnie. Na jednym z wielu blogów na ten temat czytamy:
Mikroaplikacja to aplikacja, która jest bardzo skoncentrowana na wykonywaniu tylko jednego zadania.
Pacheco, V. F. (2018). Microservice Patterns and Best Practices: Explore patterns like CQRS and event sourcing to create scalable, maintainable, and testable microservices. Packt Publishing Ltd.
Alan Grosskurth, & Michael W. Godfreyz. (2006). A reference architecture for web browsers. Journal of Software Maintenance and Evolution: Research and Practice.
Grosskurth, A., & Godfrey, M. W. (2005). A reference architecture for Web browsers. 21st IEEE International Conference on Software Maintenance (ICSM’05), 661 – 664. https://doi.org/10.1109/ICSM.2005.13
Miller, J., & Mukerji, J. (2003). MDA Guide Version 1.0.1. 62.
J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, & Akshay Bogawat. (2008). Application Architecture Guide 2.0 Designing Applications on the .NET Platform. Microsoft Corporation.
Gray, J., OOPSLA (21, 2006, Portland, Or. )., & Workshop on Domain Specific Modeling (6, 2006, Portland, Or. ). (2006). 6th OOPSLA workshop on domain specific modeling (DSM’06): October 22, 2006, Portland, Oregon USA. Univ. of Jyväskylä.
Sloman, A. (2011). Evolution of mind as a feat of computer systems engineering: Lessons from decades of development of self-monitoring virtual machinery. 24.
Sloman, A. (1978). The computer revolution in philosophy: philosophy, science, and models of mind. Harvester Press.
Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi 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. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).
Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione. Ewentualne użycie treści wymaga indywidualnej zgody autora.
Nie wykryto skryptu Javascript. Javascript wymagany do działania tej strony. Proszę włączyć go w ustawieniach przeglądarki i odświeżyć tę stronę.
Zarządzaj zgodami plików cookie
Aby zapewnić jak najlepsze wrażenia, korzystamy z technologii, takich jak pliki cookie, do przechowywania i/lub uzyskiwania dostępu do informacji o urządzeniu. Zgoda na te technologie pozwoli nam przetwarzać dane, takie jak zachowanie podczas przeglądania lub unikalne identyfikatory na tej stronie. Brak wyrażenia zgody lub wycofanie zgody może niekorzystnie wpłynąć na niektóre cechy i funkcje.
Funkcjonalne
Zawsze aktywne
Przechowywanie lub dostęp do danych technicznych jest ściśle konieczny do uzasadnionego celu umożliwienia korzystania z konkretnej usługi wyraźnie żądanej przez subskrybenta lub użytkownika, lub wyłącznie w celu przeprowadzenia transmisji komunikatu przez sieć łączności elektronicznej.
Preferencje
Przechowywanie lub dostęp techniczny jest niezbędny do uzasadnionego celu przechowywania preferencji, o które nie prosi subskrybent lub użytkownik.
Statystyka
Przechowywanie techniczne lub dostęp, który jest używany wyłącznie do celów statystycznych.Przechowywanie techniczne lub dostęp, który jest używany wyłącznie do anonimowych celów statystycznych. Bez wezwania do sądu, dobrowolnego podporządkowania się dostawcy usług internetowych lub dodatkowych zapisów od strony trzeciej, informacje przechowywane lub pobierane wyłącznie w tym celu zwykle nie mogą być wykorzystywane do identyfikacji użytkownika.
Marketing
Przechowywanie lub dostęp techniczny jest wymagany do tworzenia profili użytkowników w celu wysyłania reklam lub śledzenia użytkownika na stronie internetowej lub na kilku stronach internetowych w podobnych celach marketingowych.