(źr. Martin Fowler, Analysis Patterns, 1997)

Koncepcja wzorca projektowego dla systemów w chmurze

Wprowadzenie

W 2019 opi­sa­łem swo­istą pró­bę rewi­ta­li­za­cji wzor­ca BCE (Boundary, Control, Entity). Po wie­lu latach uży­wa­nia tego wzor­ca i dwóch latach prób jego rewi­ta­li­za­cji uzna­łem jed­nak, ż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 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 doku­men­tów . 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 roz­sze­rze­nia wzor­ca pro­jek­to­we­go BCE)

BCE powstał w cza­sach świet­no­ści metod RUP (Rational Unified Process) i ICONIX . Metody te dosko­na­le paso­wa­ły do imple­men­ta­cji reali­zo­wa­nych w śro­do­wi­sku EJB (Enterprise JavaBeans). Pojęcia Boundary, Control, Entity (BCE) przy­lgnę­ły do trój­war­stwo­we­go poj­mo­wa­nia archi­tek­tu­ry apli­ka­cji (inter­fejs użyt­kow­ni­ka, logi­ka, bada danych) a poję­cie robust­ness dia­gram” tak­że ma utrwa­lo­ne zna­cze­nie w lite­ra­tu­rze. Początkowo wyda­wa­ło się, że prze­nie­sie­nie tych pojęć na grunt metod obiek­to­wych i odpo­wie­dzial­no­ści klas uda sie bez koli­zji z wcze­śniej­szym sto­so­wa­niem wzor­ca BCE, jed­nak pra­ce badaw­cze i prak­ty­ka (szcze­gól­nie komu­ni­ka­cja tych mode­li) poka­za­ły, że poję­cia te, i ich zna­cze­nia, są tak moc­no ugrun­to­wa­ne w lite­ra­tu­rze, że pozo­sta­je jedy­nie uży­wa­nie ich w pier­wot­nych zna­cze­niach, jakie nada­no im pra­wie 20 lat temu (Philippe Kruchten, Rational Unified Process). Więcej na ten temat w arty­ku­le: ICONIX and Use Case Driven Object Modeling with UML.

Dużym pro­ble­mem jest tak­że migra­cja ist­nie­ją­cych apli­ka­cji z lokal­nych baz danych w mode­lu rela­cyj­nym do chmu­ry NoSQL .

Metody

Wszystkie moje pro­jek­ty badaw­cze są poprze­dza­ne ana­li­zą poję­cio­wą i meta­mo­de­lo­wa­niem. Dzięki temu każ­dy pro­jekt ana­li­tycz­ny jest obiek­ty­wi­zo­wa­ny w mak­sy­mal­nie moż­li­wy spo­sób, zaś pro­duk­ty pro­jek­to­wa­nia odpor­ne na zmien­ność śro­do­wi­ska. Ta odpor­ność, bie­rze się stad, że pra­wi­dło­wo opi­sa­ne dane to okre­ślo­ne zamknię­te struk­tu­ry danych wraz z ich kon­tek­stem: doku­men­ty (for­mu­la­rze). Jeżeli uzna­my, że nasz język (np. pol­ski) się nie zmie­nia, a zmie­nia sie jedy­nie to co z jego uży­ciem opi­su­je­my, to zna­czy, że moż­li­we jest zapi­sa­nie i prze­twa­rza­nie infor­ma­cji o świe­cie, i że nie opis ten (jego struk­tu­ra) nie będzie wyma­gał zmian w przy­szło­ści. Dane opi­su­ją­ce świat to zbio­ry pojęć sta­no­wią­ce okre­ślo­ne struk­tu­ry (zda­nia, aka­pi­ty, doku­men­ty) a nie poje­dyn­cze sło­wa połą­czo­ne rela­cja­mi . Trudna do prze­tłu­ma­cze­nia na język pol­ski nazwa dzie­dzi­ny nauki: infor­ma­tion scien­ce , to obszar wie­dzy zaj­mu­ją­cy się infor­ma­cją i jej prze­twa­rza­niem, co nie jest toż­sa­me z prze­twa­rza­niem danych (w języ­ku pol­skim nazy­wa­ne infor­ma­ty­ka). Korzystam tu tak­że z dorob­ku tej dzie­dzi­ny nauki: są nią mode­le poję­cio­we, onto­lo­gie i rachu­nek zdań (ana­li­za i budo­wa­nie struk­tur dokumentów). 

Rezultat

Ten opis to wstęp­na wer­sja, gene­ra­li­za­cja doświad­cze­nia zakoń­czo­nych suk­ce­sem imple­men­ta­cji i wdro­żeń. Praktyka poka­za­ła, że kla­sy­fi­ku­jąc kom­po­nen­ty apli­ka­cji, kie­ru­jąc się ich odpo­wie­dzial­no­ścią , otrzy­ma­my trzy klu­czo­we role kom­po­nen­tów: prze­twa­rza­nie, zarzą­dza­nie prze­twa­rza­niem, prze­cho­wy­wa­nie. To ostat­nie to prze­cho­wa­nie danych w pacz­kach” zor­ga­ni­zo­wa­nych kon­tek­sto­wo jako doku­men­ty . Z uwa­gi na to, że ini­cja­to­rem uży­cia usłu­gi jest aktor użyt­kow­nik”, obli­ga­to­ryj­nym ele­men­tem apli­ka­cji jest inter­fejs użyt­kow­ni­ka (GUI, Graphical User Interface). Opis ten moż­na zobra­zo­wać tak (UML):

Struktura klu­czo­wych kom­po­nen­tów apli­ka­cji (robo­cza nasza MPS: Management, Processing, Storage) jako PIM (Platform Independent Model)

Tym co róż­ni ten model od wzor­ca BCE jest rezy­gna­cja z war­stwo­wo­ści (narzu­co­nej kolej­no­ści wywo­ły­wa­nia kom­po­nen­tów). Wzorzec BCE (poni­żej) jest zor­ga­ni­zo­wa­ny w linię pro­duk­cyj­ną” z zaka­zem omi­ja­nia jej elementów:

Diagram: Wzorzec architektoniczny BCE Wzorzec BCE (Boundary, Control, Entity) w swojej pierwotnej wersji (Rosenberg 2005) zakłada, że komponenty aplikacyjne mają (realizują) jedną z trzech odpowiedzialności: Boundary to interfejs komponentu, Control to logika biznesowa, Entity to utrwalanie. Początkowo był interpretowany jako trójwarstwowe podejście do aplikacji (odpowiednio: interfejs, logika, dane) zgodnie z podejściem "aplikacja to funkcje i dane". Później rozszerzono zastosowanie wraz ze wzorcem MVC (Rosenberg 2007). Wzorzec ten jednak jest bardzo ogólny i nie pozwala na precyzyjniejsze modelowanie ról. Z tego powodu bardzo szybko projektanci przechodzili do modelowania detali takich jak operacje i atrybuty klas i do implementacji, co w dużych projektach często prowadzi do szybkiego "zalania" projektu szczegółami. Ikony na diagramie Wzorzec architektoniczny BCE to graficzne reprezentacje stereotypów, klasy notacji UML.
Struktura archi­tek­tu­ry usłu­gi apli­ka­cji na bazie wzor­ca BCE

Wzorzec, któ­ry wstęp­nie nazwa­łem MPS, to przede wszyst­kim spe­cja­li­zo­wa­ne kom­po­nen­ty prze­twa­rza­ją­ce, któ­rych uży­cie jest zarzą­dza­ne. Utrwalanie zosta­ło cał­ko­wi­cie pozba­wio­ne prze­twa­rza­nia: logi­ka biz­ne­so­wa jest w 100% reali­zo­wa­na w kom­po­nen­tach «pro­ces­sing». To klu­czo­wa zale­ta takie­go podej­ścia: nie­za­leż­ność od imple­men­ta­cji prze­cho­wy­wa­nia. Z tego powo­du w tytu­le doda­łem sło­wo chmu­ra”, gdyż to czy jest to chmu­ra pry­wat­na czy publicz­na nie powin­no mieć tu zna­cze­nia, i nie ma.

Wieloletnie doświad­cze­nie pro­jek­to­we nauczy­ło mnie tak­że, że zna­ne od lat podej­ście zna­ne jako mikro­ser­wi­sy, zakła­da­ją­ce w usłu­gach wła­sność lokal­nej bazy danych”, sta­no­wi takie samo ogra­ni­cze­nie jak wła­sne baza danych” w sys­te­mach mono­li­tycz­nych, tyle że na nie­co mniej­szą skalę.

Opisane tu kom­po­nen­ty są czę­ścią archi­tek­tu­ry całej apli­ka­cji. Opierając się na zało­że­niach MDA (Model Driven Architecture) oraz wzor­cu archi­tek­to­nicz­nym MVC (Model, View, Controller) , moż­na wstęp­nie tak zobra­zo­wać abs­trak­cyj­ną archi­tek­tu­rę aplikacji:

Abstrakcja archi­tek­tu­ry aplikacji.

Dolna część dia­gra­mu to pre­zen­to­wa­ny na począt­ku arty­ku­łu model PIM. Jednak po uzu­peł­nie­niu go o struk­tu­rę wzor­ca MVC mozna uznać, że: 1. GUI to reali­za­cja kom­po­nen­tu View, 2. Model jest reali­zo­wa­ny przez logi­kę repre­zen­to­wa­ną przez kom­po­nen­ty «Management» oraz «Processing», ele­ment «Document» to nazwa­na struk­tu­ra danych (for­mu­larz) sta­no­wią­cy zawsze argu­ment wywo­łań (peł­ni tu DTO: Data Transfer Object). Komponent «Storage» to albo wła­sny sys­tem utrwa­la­nia apli­ka­cji (jej śro­do­wi­ska), albo API sys­te­mu utrwa­la­nia w chmu­rze pry­wat­nej lub publicz­nej (patrz arty­kuł Repozytorium w chmu­rze). To dzię­ki temu migra­cja z lokal­nej do publicz­nej chmu­ry sta­no­wi wyłącz­nie prze­adre­so­wa­nie wywo­łań i jed­no­ra­zo­we prze­nie­sie­nie danych. Dość powszech­nie sto­so­wa­ny wzo­rzec pro­jek­to­wy repo­si­to­ry” tu jest podzie­lo­ny na dwie czę­ści: «Management» Kontrola dostę­pu do danych oraz «Storage» jako Repozytorium danych. To ostat­nie to wła­śnie opi­sa­ne wcze­śniej chmu­ro­we repo­zy­to­ria. 3. Controller to śro­do­wi­sko wyko­naw­cze odpo­wia­da­ją­ce za komu­ni­ka­cję z oto­cze­niem apli­ka­cji, np. inte­gra­cję z inny­mi apli­ka­cja­mi: Aktor «appli­ca­tion».

Model PIM: to co nale­ży zapro­jek­to­wać, two­rząc nową apli­ka­cję, jako wyma­ga­nie na eta­pie poprze­dza­ją­cym imple­men­ta­cję (czy­li wybór tech­no­lo­gii tak­że), wyglą­da tu tak:

Uproszczona struk­tu­ra wzor­ca archi­tek­to­nicz­ne­go MPS

Oczywiście licz­ba poszcze­gól­nych typów kom­po­nen­tów zale­ży od kon­kret­ne­go przypadku. 

Po co nam takie wzor­ce? Przed wszyst­kim by mieć od cze­go zacząć, coś co u wie­lu auto­rów nazy­wa jest star­ting point” (punkt wyj­ścia). Po dru­gie narzu­ca pewien porzą­dek, oraz pozwa­la uzy­skać pod­sta­wo­wą cechę dobre­go opro­gra­mo­wa­nia: apli­ka­cja (jej archi­tek­tu­ra) jest otwar­ta na roz­sze­rze­nia i zamknię­ta na mody­fi­ka­cje (patrz Open Closed Principle). No i po trze­cie, sto­so­wa­nie regu­ły mówią­cej, że jeden kom­po­nent ma jed­ną dedy­ko­wa­ną rolę w sys­te­mie, bar­dzo uła­twia sto­so­wa­nie dostęp­nych na ryn­ku, goto­wych kom­po­nen­tów (zarów­no płat­nych i open­so­ur­ce). Uzyskujemy tak­że łatwość zarzą­dza­nia licen­cja­mi (odse­pa­ro­wa­ne kom­po­nen­ty to odse­pa­ro­wa­ne pra­wa do nich, łatwo nimi zarzą­dzać, a w razie koniecz­no­ści zastą­pić inny­mi). Warto tu pod­kre­ślić, że z per­spek­ty­wy kosz­tów: od kosz­tów wytwo­rze­nia apli­ka­cji, znacz­nie waż­niej­sze są kosz­ty jej utrzy­ma­nie i rozwoju. 

Podsumowanie i dalsze prace

Opisany tu wzo­rzec archi­tek­to­nicz­ny to wstęp­na pro­po­zy­cja upo­rząd­ko­wa­nia archi­tek­tu­ry apli­ka­cji. Wprowadzony tu ele­ment «Management» to uogól­nie­nie wzor­ca zna­ne­go jako saga”. Jest to roz­wią­za­nie pro­ble­mu trans­ak­cyj­no­ści w sys­te­mach opar­tych na mikro­ser­wi­sach i tak­że sys­te­mach NoSQL, gdzie repo­zy­to­ria nie reali­zu­ją żad­nej logi­ki, nawet tej odpo­wie­dzial­nej za spój­ność danych (co czę­sto jest wska­zy­wa­ne jako wada tych repozytoriów).

Dalsze pra­ce są obec­nie ukie­run­ko­wa­ne na testy sku­tecz­no­ści tego wzor­ca w roz­wią­zy­wa­niu pro­ble­mów sys­te­mów, prze­trzy­mu­ją­cych dane w chmu­rach. Celem auto­ra jest opra­co­wa­nie meta­mo­de­lu sta­no­wią­ce­go roz­wią­za­nie pro­ble­mów zarzą­dza­nia duży­mi, wie­lo­dzie­dzi­no­wy­mi zbio­ra­mi danych.

Źródła

OMG​.org. (2014, June 18). Model Driven Architecture (MDA). https://​www​.omg​.org/​m​da/
Zelinski, J. (2020). Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns. In Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities (pp. 78 – 89). IGI Global. https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699
Hjørland, B. (2021). Information Retrieval and Knowledge Organization: A Perspective from the Philosophy of Science. Information, 12(3), 135. https://​doi​.org/​1​0​.​3​3​9​0​/​i​n​f​o​1​2​0​3​0​135
Hjùrland, B. (2001). Domain ana­ly­sis in infor­ma­tion scien­ce.
Borko, H. (1968). Information scien­ce: what is it? American Documentation, 19(1), 3 – 5.
Hamouda, S., & Zainol, Z. (2017). Document-Oriented Data Schema for Relational Database Migration to NoSQL. https://​doi​.org/​1​0​.​1​1​0​9​/​I​n​n​o​v​a​t​e​-​D​a​t​a​.​2​0​1​7​.13
Rosenberg, D., & Scott, K. (1999). Use case dri­ven object mode­ling with UML. Springer.
Karnitis, G., & Arnicans, G. (2015). Migration of Relational Database to Document-Oriented Database: Structure Denormalization and Data Transformation. 2015 7th International Conference on Computational Intelligence, Communication Systems and Networks, 113 – 118. https://​doi​.org/​1​0​.​1​1​0​9​/​C​I​C​S​y​N​.​2​0​1​5​.30
Steve Burbeck. (2012, July 29). How to use Model-View-Controller (MVC). https://web.archive.org/web/20120729161926/http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html
Wirfs-Brock, R., & McKean, A. (2009). Object design: roles, respon­si­bi­li­ties, and col­la­bo­ra­tions. Addison-Wesley.
Rosenberg, D., Stephens, M., & Collins-Cope, M. (2005). Agile deve­lop­ment with ICONIX pro­cess: people, pro­cess, and prag­ma­tism. Apress.

Inne artykuły na podobny temat

Komentarze

  1. ksacharczuk 18 listopada 2021 at 12:47

    Panie Jarku, Pana podej­ście jest bar­dzo podob­ne do tego, któ­re opi­su­je Robert C. Martin w publi­ka­cji Czysta archi­tek­tu­ra…”. Tak też Martin okre­śla swój wzo­rzec. Różni Was jego scep­ty­cyzm doty­czą­cy podej­ścia usłu­go­we­go. Pozdrawiam

    • Jarosław Żeliński 18 listopada 2021 at 13:35

      Wiem, też czy­ta­łem. Wzorce usług są róż­ne, dla­te­go naj­wyż­sze kry­te­rium” oce­ny podej­ścia to kosz­ty w całym cyklu życia. Cały czas obra­ca­my się w krę­gu kosz­tów dru­kar­ki atra­men­to­wej: koszt wytwo­rze­nia i zaku­pu, czy łącz­ny koszt wraz z pię­cio­let­nią eks­plo­ata­cją w okre­ślo­nych warun­kach zmien­no­ści śro­do­wi­ska pra­cy. Martin trak­tu­je bazę danych danych jak daw­ny dża­wo­wiec”, czy­li jako mono­li­tycz­ny byt (zbiór encji). To dzi­siaj naj­gor­sze podej­ście. Wzorzec MVC to wbrew temu co on twier­dzi, jest archi­tek­tu­ra, ale Model to nie baza danych” a logi­ka biz­ne­so­wa CAŁA (dane i ich logi­ka w okre­ślo­nym kon­tek­ście). W kon­se­kwen­cji u nie­go usłu­ga to wewnętrz­na funk­cja. W mode­lu usłu­go­wym usłu­ga apli­ka­cji to kon­tekst użyt­kow­ni­ka a nie wnę­trza sys­te­mu (Polecam publi­ka­cje o Use Case 2.0). Warto zwró­cić uwa­gę, że poza nim (i jego ucznia­mi) nikt inny nie krze­wi jego pomy­słów tezy (ja zaś w 100% cytu­ję lite­ra­tu­rę rónych auto­rów). Pojęcie usług i kom­po­nen­tów ma swo­ją defi­ni­cje od cza­sów Souzy i jego publi­ka­cji Aplikacje kom­po­nen­to­we” (2003). Martin w swo­ich wystą­pie­niach naj­pierw rede­fi­niu­je te poję­cia (usłu­ga itp.), a potem je zwal­cza, ale zwal­cza już inne, swo­je pojęcia.

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.