W perspektywie krótkoterminowej architektura oprogramowania pomaga zredukować czas i koszty rozwoju.
W dłuższej perspektywie architektura oprogramowania pomaga zredukować koszty utrzymaniu.

https://medium.com/@learnwithwhiteboard_digest/basics-of-software-architecture-a-guide-for-developers-8098a76881ca

Wstęp

W 2017 roku pisałem dość ogólnie o logice wzorca architektonicznego MVC kończąc artykuł słowami:

A gdzie mitycz­na baza danych? Tam gdzie jej miej­sce: zarzą­dza dany­mi utrwa­la­ny­mi w pamię­ci. Baza danych i sys­te­my zarzą­dza­nia dany­mi w archi­tek­tu­rze obiek­to­wej nie sta­no­wią miej­sca na logi­kę biz­ne­so­wą, stan­dar­do­wym wzor­cem pro­jek­to­wym jest tu acti­ve records. Podstawową zale­tą sto­so­wa­nie tego wzor­ca jest sepa­ra­cja utrwa­lo­nych danych od apli­ka­cji. To pozwa­la sku­pić całą logi­kę i jej zmien­ność w kodzie apli­ka­cji i jego archi­tek­tu­rze. Dzięki temu moż­na speł­nić zasa­dę Open Close prin­ci­pia bez refak­to­rin­gu bazy danych i migra­cji danych, co mia­ło by miej­sce gdy­by była to jed­no­li­ta rela­cyj­na baza danych dla całej apli­ka­cji. Zachowanie sepa­ra­cji i her­me­ty­za­cji obiek­tów do pozio­mu danych włącz­nie (jeże­li obiek­ty współ­dzie­lą dane w bazie danych nisz­czy to ich sepa­ra­cję), uwal­nia nas od pro­ble­mu ??jed­no­li­te­go mode­lu danych?.

Source: MVC – komponent Model w architekturze systemu – Jarosław Żeliński IT-Consulting

W sieci jest wiele opisów tego wzorca, jednak nie wszystkie są poprawne, szczególnie tam gdzie autorzy piszą, że to odpowiednik trójwarstwowej architektury: warstwy prezentacji, logiki i danych czy też, że wzorzec ten separuje logikę biznesową i dane jako odpowiednio controller i model. Gdyby tak było, byłaby to trójwarstwowa architektura, a nie obiektowy wzorzec architektoniczny. Model-View-Controller. Nie jest też prawdą, że te trzy komponenty są połączone w trójkąt, gdzie aktor ma jakieś bezpośrednie interakcje z komponentem Controller czy Model (pytanie jak?).

Co można spotkać w sieci? Po wpisaniu do wyszukiwarki “model view controller pattern” na pierwszej stronie zobaczymy np. to:

Jak widać różnorodność jest dość duża. Co ciekawe, nadal wzorce MVC i BCE bywają mylone lub uznawane za ten sam wzorzec, co jest ogromnym błędem. Warto też zwrócić uwagę na częste nadużywanie i nieprawidłowe stosowanie przez projektantów i developerów notacji UML [zotpressInText item=”{5085975:9RYKUZ67}”].

Ten artykuł powstał między innymi na bazie wybranych formalnych (literatura na końcu) i nieformalnych (poniższe) źródeł opisujących wzorce i frameworki:

Chrome Developers. ?MVC Architecture?. Accessed 18 November 2022. https://developer.chrome.com/docs/apps/app_frameworks/.

InterviewBit. ?MVC Architecture – Detailed Explanation?, 27 May 2022. https://www.interviewbit.com/blog/mvc-architecture/.

Prabhu, John. ?MVC Architecture & Its Benefits in Web Application Development?. Tech Blogs by TechAffinity (blog), 18 July 2019. https://techaffinity.com/blog/mvc-architecture-benefits-of-mvc/.

Shishkov, Boris. Designing Enterprise Information Systems Merging Enterprise Modeling and Software Specification, 2020.\

Svirca, Zanfina. ?Everything You Need to Know about MVC Architecture?. Medium, 30 May 2020. https://towardsdatascience.com/everything-you-need-to-know-about-mvc-architecture-3c827930b4c1.

Od przypadków użycia, przez MVC do ICONIX/BCE

Opisywane tu metody pracy i ich produkty wywodzą sie z zaliczanej do zwinnych, obiektowo-zorientowanej metodyki ICONIX i jej pochodnych. Jej podstawą jest orientacja na przypadki użycia i komponentowo-obiektowy charakter architektury dzielonej na HLD (architektura aplikacji) i LLD (wewnętrzna architektura komponentów). Co ciekawe metoda ta od początku jej powstania abstrahuje od technologii i modelu danych [zotpressInText item=”{5085975:KID8ZABH},{5085975:P7WIX63W}”]. Swego czasu podjąłem próbę usystematyzowania podstawowych wzorców projektowych na tle MDA [zotpressInText item=”{5085975:TBT7B5D2}”]. Ta, potrójnie recenzowana, publikacja jest dostępna w IGI Global (IGI Global jest wiodącym, średniej wielkości, niezależnym wydawcą akademickim międzynarodowych badań naukowych). Poniżej kluczowe elementy tego opracowania dotyczące wzorca MVC i pokrewnych. Osobom zainteresowanym detalami polecam lekturę tej publikacji.

Zakres projektu

Zawieranie umowy na zakres projektu i projektowanie to inżynieria (a nie inżynieria wymagań, po prostu inżynieria, ewentualnie inżynieria oprogramowania, albo ogólniej inżynieria systemów).

Zakres projektu to usługi aplikacyjne jakie ma świadczyć System. Kontekst systemu to jego otoczenie wyrażone w postaci aktorów (User, Application 1, Application 2). Powyższy System realizuje dwie usługi: jedną użytkownikowi, drugą wewnętrznemu systemowi (Application 2). Sam zaś korzysta z usług zewnętrznego systemu Application 1.

Kolejny etap to opracowanie architektury Systemu. Tu najczęściej korzystamy właśnie z wzorca MVC.

Wzorzec MVC

Jest to tak na prawdę podział aplikacji na środowisko wykonawcze (Controller, to praktycznie runtime systemu), środowisko pracy użytkownika (View) oraz “motor systemu” czyli logika zdefiniowana jako “mechanizm działania systemu”: jest to właściwy projekt PIM aplikacji i potem jej serce [zotpressInText item=”{5085975:AH5MN5KL}”].

Powyższy diagram to wewnętrzna architektura Systemu pokazanego wcześniej na diagramie przypadków użycia. Działająca aplikacja to środowisko (View i Controller) oraz właściwy program aplikacji (Model, patrz też Domanin Model).

Model PIM naszej aplikacji to specyfikacja, wyrażona jako modele w notacji UML. Na powyższym diagramie jest to element Domanin Model, oznaczony na diagramie stereotypem ‘artifact’. Jest to w nomenklaturze prawnej (przetargi) tak zwany Opis Techniczny Oprogramowania czyli: struktura i dynamika aplikacji, algorytmy, modele danych, itp., wyrażone w sposób techniczny, czyli w postaci schematów blokowych wykonanych w notacji UML. Developer, w wybranej przez siebie technologii, wykonuje implementację, czyli oprogramowanie realizujące ten model. Jest to wyrażanie wymagań w formie modelu systemu (MBSE).

Powyższa forma to logiczna postać tego wzorca (MVC) pokazująca komunikację między tymi trzema komponentami. Znacznie właściwsze było by pokazanie komponentu Controller jako środowiska wykonawczego (biblioteki i API do otoczenia systemowego) co zobrazowano poniżej:

ICONIX i wzorzec BCE

Wzorzec BCE ma swój rodowód w metodyce ICONIX [zotpressInText item=”{5085975:KID8ZABH},{5085975:P7WIX63W}”]. Pierwotnie oparty był na frameworku EJB i wspierał projektowanie w tym środowisku (robustness diagram, odnośniki do POJO, DAO, model dziedziny, dlatego teraz EJB nazwany anemicznym modelem i antywzorcem). Kluczową ideą wzorca ICONIX orientacja architektury i procesu projektowego na przypadki użycia, rozwijana później przez Jacobsona i innych pod nazwą Use Case 2.0 [zotpressInText item=”{5085975:IENSXKK5},{5085975:XSXM2FP8}”].

Każda usługa aplikacji w tym podejściu (jej przypadek użycia) to niezależny zamknięty komponent, dostępny przez jego własne API. Komponent taki może mieć (i z reguły ma) udokumentowaną własną wewnętrzną, nie raz nietrywialną, architekturę:

Każda usługa jest realizowana przez kluczowe typy komponentów: interfejs komponentu, realizacja logiki biznesowej (dziedzinowej), realizacja dostępu do obiektów w repozytorium, obiekty w repozytorium (nośniki danych zapisywanych tu w postaci dokumentów). Wzorzec BCE był tu opisywany szerzej w artykule Wzorce projektowe w analizie i projektowaniu modelu dziedziny systemu.

Wiele emocji i kontrowersji budzi dokumentowa metoda zarządzania danymi. Dane są tu zapisywane w zwartej zmaterializowanej postaci. Najczęściej w formacie JSON lub XML (element DataForm oznaczony stereotypem ‘Document’). Jeżeli jest to nowy komponent starej aplikacji, zbudowanej na relacyjnym modelu danych, najczęściej stosowany jest w tym miejscu wzorzec projektowy Active Record, rzadziej Active Table. Z jego pomocą operacje update i retrieve obiektów klasy “Data envelope”, są implementowane jako zapytania SQL do relacyjnej bazy danych. Klasa “Data envelope” stanowi wtedy API do tej starej bazy danych. Takie podejście uniezależnia projektanta i projekt, od metody i technologii utrwalania danych oraz od potrzeby znajomości SQL. Jako projektant uważam, że jest to dobre wyjście przy rozbudowie starych systemów legacy. Jednak model relacyjny, szczególnie w systemach biznesowych, stanowi ogromne ograniczenie rozwojowe na przyszłość i uniemożliwia stosowanie repozytoriów NoSQL w chmurze.

Podsumowanie

Podstawową zalecą wzorca MVC jest odseparowanie (hermetyzacja) logiki dziedzinowej od środowiska wykonawczego aplikacji. Dzięki czemu możliwe jest projektowanie wyłącznie modelu dziedziny systemu i jego późniejsza, niezależna od technologii, implementacja. Dodatkową korzyścią jest tu powstająca dokumentacja, stanowiąca ochronę know-how sponsora projektu, co w obecnych czasach nabiera coraz większego znaczenia.

Dostępne w literaturze schematy blokowe pokazujące ideę wzorca MVC, pokazują często logikę działania tego wzorca, rozumianą jako przesyłanie komunikatów. Stąd prawdopodobnie schematy w postaci trójkąta. Jednak warto wiedzeć, że fizycznie jest to podział aplikacji na jej środowisko (biblioteki, API to otoczenia) i komponent realizujący dziedzinową logikę, która odpowiada za realizację funkcjonalności oprogramowania. Odmianą tego wzorca jest MV-VM. Jest to wzorzec uwzgledniający fakt, że środowisko wykonawcze może być podzielone na część serwerową i część wykonywaną np. w przeglądarce WWW (patrz artykuł Aplikacje webowe i mikroserwisy czyli architektura systemów webowych) lub w smartfonie. Przeglądarka WWW, czy system operacyjny (środowisko) smartfona, to kolejny runtime: zestaw lokalnych bibliotek i API do otoczenia (np. lokalna pamięć, dysk twardy, dane z modułu GPS, itp.).

Dodatek: inżynier vs. developer

Dlatego od pewnego czasu już rozróżniamy pojęcie “software engineer” i “software developer”. Drugi opracowuje i wykonuje implementacje tego co zaprojektuje pierwszy. Pojęcie programisty ma od pewnego już czasu nieco inny kontekst:

Programming is not solely about constructing software?programming is about designing software.

[zotpressInText item=”{5085975:NZCQDD79}”]

Pamiętajmy więc, że programowanie to opracowanie tego jak ma być przetwarzana informacja reprezentowana jako dane w aplikacji, a nie tego jaką technologią mają być przetwarzane dane. To drugie realizuje developer, pierwsze inżynier, architekt całego systemu.

software developer vs software engineer
Generally, software engineers look after the bigger picture, while software developers focus on one area to execute their plans. Engineers can act as developers, too, or simply oversee developers who create functional programs.

https://www.randstad.co.uk/career-advice/career-guidance/full-stack-developer-vs-software-engineer/

Tak więc opracowanie modelu dziedziny systemu, czyli zaprojektowanie systemu, to rola inżyniera, który tu jest architektem systemu informacyjnego. Zaprojektowanie środowiska wykonawczego o opracowanie implementacji to rola developera:

Źródła

[zotpressInTextBib style=”apa” sortby=”author” sort=”ASC”]

Architektura

Projekty informatyczne się rozrastają, cała branża ewoluuje. Ostatnie 20 lat doświadczeń pokazało, że owszem sztuką jest stworzyć i wdrożyć oprogramowanie, ale jeszcze większą sztuką jest je konserwować, zmieniać i rozwijać. Wiele firm boryka się z powtarzanymi długotrwałymi i kosztownymi “analizami przedwdrożeniowymi” poprzedzającymi każdy kolejny projekt wdrażania zmian. To skutek braku aktualnej dokumentacji posiadanego systemu. To jak planowanie nowej budowy w mieście nie mając aktualnych planów urbanistycznych tego miasta: każdy nowy projekt to ponowne dokumentowanie stanu obecnego, tylko dlatego, że ktoś nie udokumentował zmian wprowadzonych ostatnim razem (być może poprzednio udokumentował jakiś stan zastany, jednak nie aktualizował tej dokumentacji). Podobno developer pamięta co mają jego klienci, jednak zmiana developera staje się wtedy trudna, a nie raz niemożliwa z powodu złej umowy (prawo autorskie) i braku dokumentacji (wiedza w głowach programistów, wdrożeniowców, bywa, że nigdzie), to efekt znany jako vendor lock-in.

Rozwiązaniem jest dokumentacja systemu. Co jest głównym wyzwaniem w tworzeniu dokumentacji systemu? Ustalenie kompromisu między szczegółowością dokumentacji a czasem i kosztem jej opracowania a potem aktualizacji. Tym kompromisem jest architektura: struktura opisująca co i do czego służy: elementy systemu i ich wzajemne powiązania, ale bez angażowania się w dokumentowanie detali tych elementów (hermetyzacja). To dlatego bardzo przydatne jest komponentowe podejście do projektowania i obiektowy paradygmat tworzenia oprogramowania.

Dzisiaj kilka słów o trzech książkach, każda z nich była na tym blogu krótko recenzowana, razem stanowią moim zdaniem podstawowy zestaw projektanta. Pod pojęciem projektowania rozumiemy tworzenie projektu systemu czyli dokumentowanie tego jakim ma być, lub jakim jest i co w nim zmienimy.

Dokumentowanie architektury

Ta książka to rodzaj podsumowania. We wstępie czytamy:

“Architektura oprogramowania – koncepcyjny klej, który spaja każdą fazę projektu, dla jego wielu interesariuszy – jest powszechnie uznawana za krytyczny element współczesnego rozwoju oprogramowania. Praktycy coraz częściej przekonują się, że poświęcanie szczególnej uwagi architekturze systemu oprogramowania przynosi wymierne korzyści. Bez architektury, która jest odpowiednia dla rozwiązywanego problemu, projekt będzie się potykał, a najprawdopodobniej zakończy się niepowodzeniem. Ale nawet przy doskonałej architekturze, jeśli nie jest ona dobrze rozumiana i przekazywana, projekt ma małe szanse powodzenia.

Książka Documenting Software Architectures, dostarcza najbardziej kompletnych i aktualnych wskazówek, niezależnie od języka czy notacji, jak ująć architekturę w powszechnie zrozumiałej formie. Bazując na swoim bogatym doświadczeniu, autorzy najpierw pomagają zdecydować, jakie informacje należy udokumentować, a następnie, za pomocą wskazówek i przykładów (w różnych notacjach, w tym UML), pokazują, jak wyrazić architekturę, aby inni mogli na jej podstawie z powodzeniem budować, używać i utrzymywać system. Książka zawiera zasady tworzenia solidnej dokumentacji, cele i strategie dokumentacji, widoki i style architektoniczne, dokumentację interfejsów oprogramowania i zachowania oprogramowania oraz szablony do zbierania i organizowania informacji w celu stworzenia spójnego pakietu.

[zotpressInText item=”{5085975:ITC82TM7}”]

Zdaniem autorów kluczem są pojęcia: element systemu, jego cechy i związki między tymi elementami. Zwracają uwagę na to, że związek między elementami to ich wzajemne wywoływanie się (współpraca to nie relacje a użycie). Mając model pojawia się druga ważna rzecz: adresaci informacji czyli perspektywy opisu systemu. Dlatego kolejna istotna rzecz to treść i forma prezentowania kontekstu.

Kolejna książka to Architektura Oprogramowania w Praktyce [zotpressInText item=”{5085975:EDMVWKQS}”]. Ze wstęu: “Wielokrotnie nagradzana i ciesząca się dużym zainteresowaniem Architektura oprogramowania w praktyce, wydanie trzecie, została znacząco zmienione, aby odzwierciedlić najnowsze osiągnięcia w tej dziedzinie. W książce po raz kolejny przedstawiono koncepcje i najlepsze praktyki architektury oprogramowania – strukturę systemu oprogramowania oraz sposób, w jaki jego elementy mają ze sobą współdziałać.

W tym wydaniu autorzy skupili się na koncepcji rozwoju architektury. Każdy cykl rozwoju pokazuje, w jaki sposób architektura wpływa na określony kontekst, w którym odgrywa kluczową rolę, oraz jak jest kształtowana przez ten kontekst. Konteksty te obejmują środowisko techniczne, cykl życia projektu, profil biznesowy organizacji oraz praktyki zawodowe architekta. Autorzy znacznie rozszerzyli także omówienie atrybutów jakości, które pozostają centralnym elementem ich filozofii architektury – każdemu z atrybutów poświęcili cały rozdział – oraz rozszerzyli omówienie wzorców architektonicznych.”

Autorzy ciekawie prezentują to jak i po co powstaje dokumentacja: procesowo. Streszczają (prezentują) treść książki w postaci kilku prostych modeli procesów:

Ta forma bardzo mi się spodobała: pokazuje bodźce, model (artifact) logiki i efekt uzyskany. Generalnie autorzy w swojej książce prezentują praktyczne aspekty dokumentowania oprogramowania i stosowania tej dokumentacji. Pamiętajmy także, że dokumentacja oprogramowania to przede wszystkim jego modele.

Na koniec zostawiłem książkę najstarszą: Large-Scale Software Architecture [zotpressInText item=”{5085975:P4896CWC}”].

Jak piszą autorzy, celem projektowania (dokumentowania) architektury dużych aplikacji jest uchwycenie i opisanie praktycznych metod jego zobrazowania (udokumentowania), mających na celu zwiększyć efektywność komunikacji zespołów programistów i ich zrozumienia kontekstu systemu.

W tej książce autorzy pokazują, jak wykorzystać architekturę oprogramowania już jako narzędzie na etapie zarządzania rozwojem aplikacji, nie tylko jako powykonawczą dokumentację po podjęciu wszystkich decyzji projektowych. Prezentują w swojej książce:

• Zwięzły opis wykorzystania języka UML w architekturze dużych aplikacji,
• Architekturę oprogramowania i zasady jej projektowania,
• Zwracają uwagę na jej niezależność od technologii i dostawców.

Tę książkę można podsumować tak: każda architekturę należy dokumentować od ogółu do szczegółu, każdy model powinien być prosty i zwięzły ale modeli tych może być wiele, każdy system to jego kluczowa rola, jego wewnętrzna struktura i zachowania jego składowych elementów oraz jego pojęciowy dziedzinowy ogólny opis.

Podsumowanie

Powyższe opisy to kluczowe cechy każdej z tych trzech pozycji. Moją intencją było polecenie tych trzech pozycji jako zestawu prezentującego dość kompletną wiedzę na temat stanu wiedzy na temat projektowania oprogramowania skupiającego się na jego architekturze. Jako efekt uzyskujemy dokumentację relatywnie szczupłą objętościowo, więc będzie czytana. Stosowanie standardu notacyjnego, jakim jest UML, uzyskujemy szeroki zasięg odbiorców i uniwersalność. Zwracają na to uwagę autorzy wszystkich tych trzech pozycji.

Ostatnia pozycja to klasyka komponentowego podejścia do projektowania. Pierwsze dwie powstały kilka lat po fascynacji autorów zwinnym podejściem (agile). Podobnie jak Scott Ambler [zotpressInText item=”{5085975:NZTIUBEK},{5085975:P5PE3C3R}”], odkryli że zbytnie przykładanie wagi do “działającego oprogramowania” na niekorzyść jego dokumentacji, powoduje szkody na kolejnych etapach cyklu życia produktu jakim jest aplikacja.

Żadne oprogramowanie nie powstaje tylko na jeden dzień, będzie komuś służyło miesiącami, latami, a świat nie stoi w miejscu. stawianie tezy, że celem tworzenia oprogramowania jego powstanie jest szkodliwe. Kluczem jest cykl życia oprogramowania, a jego dokumentacja to jedyna forma komunikowania się zmieniających się osób, latami zaangażowanych w utrzymanie i rozwój aplikacji.

Te trzy książki to moim zdaniem mały zbiór rzetelnej wiedzy, który powinien pomóc każdemu początkującemu i zagubionemu “juniorowi analizy biznesowej” w nauce tworzenia wysokiej jakości dokumentacji. To także wiedza przydatna dla doświadczonych analityków i projektantów: zawsze warto wiedzieć jak robią to inni, mający ogromny dorobek. Dokumentacja systemu to jedyne trwałe źródło wiedzy o nim, jednak zła i nieaktualna dokumentacja jest gorsza od jej braku…

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Wprowadzenie

Niedawno napisał do mnie czytelnik pod jednym z artykułów:

Załóż­my, że reali­zu­je­my pro­ces biz­ne­so­wy: zarzą­dza­nie kur­sa­mi walut. W ramach pro­ce­su pra­cow­nik musi przy­go­to­wać plik csv zawie­ra­ją­cy wyłącz­nie listę słow­ni­ko­wą par walut (np. usdpln, eurpln, eurusd). Nazwa pli­ku to np bie­żą­cą data. Następnie systemX łączy się z API zewnętrz­nej plat­for­my i pobie­ra tabe­le kur­sów tych par walut (aktu­al­ne i histo­rycz­ne mie­siąc wstecz) i wysta­wia plik xls zawie­ra­ją­cy dane: nazwa pary walut, data kur­su, war­tość kursy) Plik ten sys­tem X wysy­ła do szy­by ESB. Szyna prze­sy­ła ten plik do systemuY. SystemY wyko­rzy­stu­je te dane do wyzna­cze­nia wewnętrz­nych kur­sów walut wg. usta­lo­ne­go mode­lu mate­ma­tycz­ne­go. Wynik obli­czeń odkła­da­ny jest w bazie danych tego systemu. Na koń­cu pro­ce­su jest pra­cow­nik, któ­ry wyko­rzy­stu­je te infor­ma­cje za pośred­nic­twem SystemuZ. Wybiera parę walut, okre­śla datę i sys­tem zwra­ca mu wewnętrz­ny kurs wyzna­czo­ny przez SystemY. Technicznie odby­wa się poprzez odpy­ta­nie sys­te­mu Y poprzez jego API. Czyli mamy SystemX, SystemY, SystemZ, pra­cow­ni­ka, szy­nę, plik csv, plix xls, 2XAPI no i prze­pływ danych (naj­pierw pli­ków, potem poszcze­gól­nych atry­bu­tów) . I jak to wszyst­kim poka­zać żeby było czytelne? (źr.: : Model pojęciowy, model danych, model dziedziny systemu)

Prawdę mówiąc, mniej więcej w takiej formie dostaje materiały od moich klientów.. ;). Co możemy zrobić? Pomyślałem, że dobry reprezentatywny przykład pomoże. Popatrzmy…

(more…)

Wprowadzenie

W 2019 opisałem swoistą próbę rewitalizacji wzorca BCE (Boundary, Control, Entity). Po wielu latach używania tego wzorca i dwóch latach prób jego rewitalizacji uznałem jednak, że

Zarzucam pra­ce nad wzor­cem BCE. Podstawowy powód to boga­ta lite­ra­tu­ra i utrwa­lo­ne zna­cze­nia pojęć opi­su­ją­cych ten wzo­rzec. Co do zasa­dy rede­fi­nio­wa­nie utrwa­lo­nych pojęć nie wno­si nicze­go do nauki. Moja publi­ka­cja zawie­ra­ją­ca tak­że opis tego wzor­ca [zotpressInText item=”{5085975:TBT7B5D2}”] bazo­wa­ła na pier­wot­nych zna­cze­niach pojęć Boundary, Control, Entity. Sprawiły one jed­nak nie­co pro­ble­mu w kolej­nej publi­ka­cji na temat dokumentów [zotpressInText item=”{5085975:9KMR85JV}”]. Dlatego w mode­lu poję­cio­wym opi­su­ją­cym role kom­po­nen­tów przy­ją­łem nastę­pu­ją­ce bazo­we stwierdzenie:

Implementacja usłu­gi apli­ka­cyj­nej wyma­ga wymia­ny danych z oto­cze­niem (?Interface?), prze­twa­rza­nia danych (?Processing?) i ich prze­cho­wy­wa­nia (?Storage?) danych. Działania te to role kom­po­nen­tów (ich typy). Dane, dla uła­twie­nia zarzą­dza­nia nimi, są orga­ni­zo­wa­ne w doku­men­ty (?Document?). Całość może wyma­gać zarzą­dza­nia (?Management?).

Dalsze pra­ce pój­dą więc w kie­run­ku nowe­go wzor­ca a nie roz­sze­rza­nia wzor­ca BCE. (Koncepcja rozszerzenia wzorca projektowego BCE)

BCE powstał w czasach świetności metod RUP (Rational Unified Process) i ICONIX [zotpressInText item=”{5085975:7NUD7FFT},{5085975:P7WIX63W}”]. Metody te doskonale pasowały do implementacji realizowanych w środowisku EJB (Enterprise JavaBeans). Pojęcia Boundary, Control, Entity (BCE) przylgnęły do trójwarstwowego pojmowania architektury aplikacji (interfejs użytkownika, logika, bada danych) a pojęcie “robustness diagram” także ma utrwalone znaczenie w literaturze. Początkowo wydawało się, że przeniesienie tych pojęć na grunt metod obiektowych i odpowiedzialności klas [zotpressInText item=”{5085975:CDZ44929}”] uda sie bez kolizji z wcześniejszym stosowaniem wzorca BCE, jednak prace badawcze i praktyka (szczególnie komunikacja tych modeli) pokazały, że pojęcia te, i ich znaczenia, są tak mocno ugruntowane w literaturze, że pozostaje jedynie używanie ich w pierwotnych znaczeniach, jakie nadano im prawie 20 lat temu (Philippe Kruchten, Rational Unified Process). Więcej na ten temat w artykule: ICONIX and Use Case Driven Object Modeling with UML.

Dużym problemem jest także migracja istniejących aplikacji z lokalnych baz danych w modelu relacyjnym do chmury NoSQL [zotpressInText item=”{5085975:WG8FBWQ9},{5085975:TLXPTGGP}”].

Metody

Wszystkie moje projekty badawcze są poprzedzane analizą pojęciową i metamodelowaniem. Dzięki temu każdy projekt analityczny jest obiektywizowany w maksymalnie możliwy sposób, zaś produkty projektowania odporne na zmienność środowiska. Ta odporność, bierze się stad, że prawidłowo opisane dane to określone zamknięte struktury danych wraz z ich kontekstem: dokumenty (formularze). Jeżeli uznamy, że nasz język (np. polski) się nie zmienia, a zmienia sie jedynie to co z jego użyciem opisujemy, to znaczy, że możliwe jest zapisanie i przetwarzanie informacji o świecie, i że nie opis ten (jego struktura) nie będzie wymagał zmian w przyszłości. Dane opisujące świat to zbiory pojęć stanowiące określone struktury (zdania, akapity, dokumenty) a nie pojedyncze słowa połączone relacjami [zotpressInText item=”{5085975:9KMR85JV}”]. Trudna do przetłumaczenia na język polski nazwa dziedziny nauki: information science [zotpressInText item=”{5085975:M5XF9L4L},{5085975:2H38RDA7},{5085975:FZX9ZH26}”], to obszar wiedzy zajmujący się informacją i jej przetwarzaniem, co nie jest tożsame z przetwarzaniem danych (w języku polskim nazywane informatyka). Korzystam tu także z dorobku tej dziedziny nauki: są nią modele pojęciowe, ontologie i rachunek zdań (analiza i budowanie struktur dokumentów).

Rezultat

Ten opis to wstępna wersja, generalizacja doświadczenia zakończonych sukcesem implementacji i wdrożeń. Praktyka pokazała, że klasyfikując komponenty aplikacji, kierując się ich odpowiedzialnością [zotpressInText item=”{5085975:CDZ44929}”], otrzymamy trzy kluczowe role komponentów: przetwarzanie, zarządzanie przetwarzaniem, przechowywanie. To ostatnie to przechowanie danych w “paczkach” zorganizowanych kontekstowo jako dokumenty [zotpressInText item=”{5085975:9KMR85JV}”]. Z uwagi na to, że inicjatorem użycia usługi jest aktor “użytkownik”, obligatoryjnym elementem aplikacji jest interfejs użytkownika (GUI, Graphical User Interface). Opis ten można zobrazować tak (UML):

Tym co różni ten model od wzorca BCE jest rezygnacja z warstwowości (narzuconej kolejności wywoływania komponentów). Wzorzec BCE (poniżej) jest zorganizowany w “linię produkcyjną” z zakazem omijania jej elementów:

Wzorzec, który wstępnie nazwałem MPS, to przede wszystkim specjalizowane komponenty przetwarzające, których użycie jest zarządzane. Utrwalanie zostało całkowicie pozbawione przetwarzania: logika biznesowa jest w 100% realizowana w komponentach ‘processing’. To kluczowa zaleta takiego podejścia: niezależność od implementacji przechowywania. Z tego powodu w tytule dodałem słowo “chmura”, gdyż to czy jest to chmura prywatna czy publiczna nie powinno mieć tu znaczenia, i nie ma.

Wieloletnie doświadczenie projektowe nauczyło mnie także, że znane od lat podejście znane jako mikroserwisy, zakładające w usługach “własność lokalnej bazy danych”, stanowi takie samo ograniczenie jak “własne baza danych” w systemach monolitycznych, tyle że na nieco mniejszą skalę.

Opisane tu komponenty są częścią architektury całej aplikacji. Opierając się na założeniach MDA (Model Driven Architecture) oraz wzorcu architektonicznym MVC (Model, View, Controller) [zotpressInText item=”{5085975:TBT7B5D2},{5085975:X7Z9RCAV},{5085975:UWH8D5UI}”], można wstępnie tak zobrazować abstrakcyjną architekturę aplikacji:

Dolna część diagramu to prezentowany na początku artykułu model PIM. Jednak po uzupełnieniu go o strukturę wzorca MVC mozna uznać, że: 1. GUI to realizacja komponentu View, 2. Model jest realizowany przez logikę reprezentowaną przez komponenty ‘Management’ oraz ‘Processing’, element ‘Document’ to nazwana struktura danych (formularz) stanowiący zawsze argument wywołań (pełni tu DTO: Data Transfer Object). Komponent ‘Storage’ to albo własny system utrwalania aplikacji (jej środowiska), albo API systemu utrwalania w chmurze prywatnej lub publicznej (patrz artykuł Repozytorium w chmurze). To dzięki temu migracja z lokalnej do publicznej chmury stanowi wyłącznie przeadresowanie wywołań i jednorazowe przeniesienie danych. Dość powszechnie stosowany wzorzec projektowy “repository” tu jest podzielony na dwie części: ‘Management’ Kontrola dostępu do danych oraz ‘Storage’ jako Repozytorium danych. To ostatnie to właśnie opisane wcześniej chmurowe repozytoria. 3. Controller to środowisko wykonawcze odpowiadające za komunikację z otoczeniem aplikacji, np. integrację z innymi aplikacjami: Aktor ‘application’.

Model PIM: to co należy zaprojektować, tworząc nową aplikację, jako wymaganie na etapie poprzedzającym implementację (czyli wybór technologii także), wygląda tu tak:

Oczywiście liczba poszczególnych typów komponentów zależy od konkretnego przypadku.

Po co nam takie wzorce? Przed wszystkim by mieć od czego zacząć, coś co u wielu autorów nazywa jest “starting point” (punkt wyjścia). Po drugie narzuca pewien porządek, oraz pozwala uzyskać podstawową cechę dobrego oprogramowania: aplikacja (jej architektura) jest otwarta na rozszerzenia i zamknięta na modyfikacje (patrz Open Closed Principle). No i po trzecie, stosowanie reguły mówiącej, że jeden komponent ma jedną dedykowaną rolę w systemie, bardzo ułatwia stosowanie dostępnych na rynku, gotowych komponentów (zarówno płatnych i opensource). Uzyskujemy także łatwość zarządzania licencjami (odseparowane komponenty to odseparowane prawa do nich, łatwo nimi zarządzać, a w razie konieczności zastąpić innymi). Warto tu podkreślić, że z perspektywy kosztów: od kosztów wytworzenia aplikacji, znacznie ważniejsze są koszty jej utrzymanie i rozwoju.

Podsumowanie i dalsze prace

Opisany tu wzorzec architektoniczny to wstępna propozycja uporządkowania architektury aplikacji. Wprowadzony tu element ‘Management’ to uogólnienie wzorca znanego jako “saga“. Jest to rozwiązanie problemu transakcyjności w systemach opartych na mikroserwisach i także systemach NoSQL, gdzie repozytoria nie realizują żadnej logiki, nawet tej odpowiedzialnej za spójność danych (co często jest wskazywane jako wada tych repozytoriów).

Dalsze prace są obecnie ukierunkowane na testy skuteczności tego wzorca w rozwiązywaniu problemów systemów, przetrzymujących dane w chmurach. Celem autora jest opracowanie metamodelu stanowiącego rozwiązanie problemów zarządzania dużymi, wielodziedzinowymi zbiorami danych.

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Dwa lata temu pisałem o mikroserwisach:

Obecnie mamy już dość dobrze wypracowane wzorce projektowe ale nadal jest problem ze zrozumieniem  ?kiedy i jak?. Ładnie to opisał swego czasu E.Evans przy okazji wzorca DDD, Tu poprzestanę jedynie na pojęciu bounded context czyli ?granica kontekstu?. Granica ta ma podwójne znaczenie: kontekst nadaje (zmienia) znaczenia w modelu pojęciowym (bałwan w kontekście zimy to co innego niż bałwan w kontekście członków zespołu projektowego) oraz kontekst  (bardzo często) wyznacza zakres projektu (inne aspekty wzorca DDD tu pominę). Pierwsza uwaga: kontekst dziedzinowy (pojęciowy) jest ważniejszy (powinien być nadrzędny) wobec zakresu projektu, ten drugi jest ustalany, drugi wynika z systemu pojęciowego (bałwan z okazji zimy będzie trwalszym pojęciem w projekcie niż bałwan z okazji członków doraźnego spotkania zespołu). (Źródło: Granice kontekstu i mikroserwisy)

Mikroserwisy to bardzo wygodna architektura. Wymaga całkowitej rezygnacji z jednego, relacyjnego systemu danych dla dużej aplikacji, dzięki czemu możliwe jest niezależne, iteracyjno-przyrostowe (zwinne) implementowanie kolejnych usług.?(Woodie, 2018)? ?(Arsov, 2017)? Powyższy artykuł zawiera kilka przykładów (polecam lekturę całości), które pokazują przyczyny problemów z tradycyjnymi “całościowo” zintegrowanymi systemami (np. ERP).

Ogólna idea to budowanie aplikacji tak, by każdy przypadek użycia stanowił praktycznie odrębny mały komponent. W efekcie mamy dużą swobodę zarządzania kolejnością ich implementacji a lokalne modyfikacje nie przenoszą się na resztę systemu. Ewentualne współdzielone komponenty to wyłącznie elementy logiki biznesowej, co nie ogranicza zbyt mocno kolejności implementowanych i wdrażanych usług aplikacyjnych. 

Architektura ta jest znana od lat, dość precyzyjnie opisał ją Fowler w 2014 roku (Microservices). 

Czym są mikrousługi? Zwrot w kierunku oprogramowania opartego o mikrousługi i kontenery to cicha rewolucja, która w ostatnich miesiącach dokonuje się na globalnym rynku IT. Mikrousługi stanowią alternatywę dla monolitycznego stylu tworzenia oprogramowania. Tworząc aplikacje z wykorzystaniem architektury mikrousług i kontenerów, programiści mogą odpowiednio dobrać jej poszczególne elementy, nie zajmując się całością aplikacji, co ma miejsce w przypadku podejścia monolitycznego. Tym samym cykl produkcyjny ulega skróceniu, a związane z nim koszty obniżeniu nawet o 60 proc. Zwiększa się także elastyczność oraz szybkość wprowadzania innowacji? ? tłumaczy Rafał Głąb, Business Technology Unit Director, odpowiedzialny za rozwój Onwelo Microservices Lab, największego w Polsce centrum kompetencyjnego dotyczącego mikrousług. (Źródło: Słyszałeś o mikrousługach? Twoje ulubione aplikacje działają w oparciu o nie! – ERP-view.pl – ERP, CRM, MRP, Business Intelligence, MRP)

Aplikacje budowane w oparciu o tradycyjny monolityczny relacyjny model danych wymagają zaprojektowania całościowego modelu danych co jest dużym wyzwaniem, obecnie graniczącym z cudem (niedawno o tym pisałem w Biznesowy model danych – nie chcemy).

Prawdopodobieństwo zmian pierwotnych (z dnia rozpoczęcia projektu) wymagań na “całość systemu”, dla projektów trwających ponad rok, obecnie graniczy z pewnością, dlatego po prostu nie sensu tego robić.

Projekt może być realizowany przyrostowo tylko pod warunkiem, że pozwala na to architektura całego systemu, ta więc nie może mieć monolitycznej podstawy jaką jest jeden relacyjny model danych. Implementacja (proces) bazująca na mikroserwisach wygląda tak:

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. Mit “monolitycznego zintegrowanego” systemu powoli przestaje działać na rynku… powoli… bo nadal jest żywy w ofertach.?(D., 2019)?

W nieco innej formie, ale bardzo zbliżonej mówimy też o mikro aplikacjach (microapp). Pojęcie mikroserwisów zostało nieco zawłaszczone przez dostawców technologii (VMWare, dokery, itp.), pojęciem bliższym opisanej wyżej architektury jest pojęcie mikroaplikacji. W tym kontekście spotykane jest także pojęcie “modularyzacja”. Więcej o tym innym razem …

Bibliografia

1. Arsov, K. (2017, March 17). What Are Microservices, Actually? Retrieved from DZone website: https://dzone.com/articles/what-are-microservices-actually
2. D., A. (2019, April 18). Best Architecture for an MVP: Monolith, SOA, Microservices, or Serverless? Retrieved July 7, 2019, from RubbyGarage website: https://rubygarage.org/blog/monolith-soa-microservices-serverless
3. Gage, J. (2018, April 23). Introduction to Microservices: What are Microservices? Use Cases and Examples. Retrieved September 5, 2019, from Algorithmia website:
4. Woodie, A. (2018, November 7). Modernizing IBM i Apps with Microservices. Retrieved from IT Jungle website: https://www.itjungle.com/2018/11/07/modernizing-ibm-i-apps-with-microservices/