(ź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.

Inżynieria oprogramowania z użyciem narzędzia CASE – przykładowy projekt Biblioteka

W dniu 11.12.2020, uda­ło mi się w koń­cu prze­pro­wa­dzić pre­zen­ta­cję on-line. Celem była pre­zen­ta­cja reali­za­cji meto­dy MBSE z narzę­dziem CASE (tu Visual-Paradigm) i jej efek­tów. Adresatem są zarów­no ana­li­ty­cy, archi­tek­ci opro­gra­mo­wa­na jak i deve­lo­per (pro­gra­mi­ści) jako osta­tecz­ny adre­sat doku­men­tu. Podobną pre­zen­ta­cję pro­wa­dzi­łem wcze­śniej na Konferencji beIT 2020. Popularność tych pre­zen­ta­cji spo­wo­do­wa­ła, że całość prze­ro­dzi­ła się w pro­jekt badawczy. 

Czytaj dalej… Inżynieria opro­gra­mo­wa­nia z uży­ciem narzę­dzia CASE – przy­kła­do­wy pro­jekt Biblioteka”

Projekt aplikacji – przykład

Wstęp

Napisałem o orien­ta­cji na doku­men­ty w toku analiz:

Często jestem i ja pyta­ny o to ??Jak wyja­śnić zło­żo­ne roz­wią­za­nie tech­nicz­ne inte­re­sa­riu­szom nie­tech­nicz­nym?? Jak wie­lu mi podob­nych odpo­wia­dam: roz­ma­wiaj doku­men­ta­mi. Sponsor pro­jek­tu, przy­szli użyt­kow­ni­cy, postrze­ga­ją swo­ją pra­cę poprzez doku­men­ty: ich treść i układ. (Wymagania na for­mu­la­rze czy­li dia­gra­my struk­tur zło­żo­nych i XML)

Dzisiaj pój­dzie­my dalej, omó­wi­my to gdzie i jak zacho­wać tę infor­ma­cję. Posłużę się pro­stym przy­kła­dem przy­chod­ni wete­ry­na­ryj­nej. Artykuł będzie opi­sem meto­dy podej­ścia do ana­li­zy zorien­to­wa­nej na pro­ce­sy i dokumenty. 

Tekst ma dwie czę­ści: pierw­sza jest opi­sem dro­gi jaka pro­wa­dzi nas do zde­fi­nio­wa­nia tego jakie doku­men­ty, jaką mają (mieć) zawar­tość i struk­tu­rę. Praktycznie jest to opis ana­li­zy i pro­jek­to­wa­nia. Druga – krót­ka – to przy­kła­do­wa archi­tek­tu­ra logi­ki reali­za­cji apli­ka­cji, poka­zu­ją­ca miej­sce doku­men­to­wej bazy danych w archi­tek­tu­rze i pro­jek­cie, czy­li tak­że projektowanie. 

Celem tego wpi­su jest poka­za­nie czym może być ana­li­za oraz jej pro­dukt jakim jest Techniczny Projekt Oprogramowania.

Czytaj dalej… Projekt apli­ka­cji – przy­kład”

Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns

Miło mi poin­for­mo­wać, że moja publi­ka­cja nauko­wa (tu była zapo­wiedź) na temat syn­te­zy wzor­ców archi­tek­to­nicz­nych i wzor­ców pro­jek­to­wych, sys­te­mów obiek­to­wo-zorien­to­wa­nych zatytułowana:

Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns

po dłu­gim pro­ce­sie selek­cji i recen­zo­wa­nia, zosta­ła zakwa­li­fi­ko­wa­na do publi­ka­cji i wła­śnie się uka­za­ła jako jeden z roz­dzia­łów książki:

Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities.

Jeszcze milej mi poin­for­mo­wać, że – jako współ­au­tor – mogę Wam zaofe­ro­wać kod pro­mo­cyj­ny dają­cy 40% zniż­ki na zakup: IGI40.

Poniżej infor­ma­cje o książ­ce i o wydawcy. 

O książce

Ch. 3: Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities:
Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns (050719 – 041004) (J.Żeliński)

DescriptionIn today?s moder­ni­zed envi­ron­ment, a gro­wing num­ber of softwa­re com­pa­nies are chan­ging the­ir tra­di­tio­nal engi­ne­ering appro­aches in respon­se to the rapid deve­lop­ment of com­pu­ting tech­no­lo­gies. As the­se busi­nesses adopt modern softwa­re engi­ne­ering prac­ti­ces, they face vario­us chal­len­ges inc­lu­ding the inte­gra­tion of cur­rent metho­do­lo­gies and con­tem­po­ra­ry design models and the refac­to­ring of exi­sting sys­tems using advan­ced approaches.Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities is a pivo­tal refe­ren­ce sour­ce that pro­vi­des vital rese­arch on the deve­lop­ment of modern softwa­re prac­ti­ces that impact main­te­nan­ce, design, and deve­lo­per pro­duc­ti­vi­ty. While high­li­gh­ting topics such as augmen­ted reali­ty, distri­bu­ted com­pu­ting, and big data pro­ces­sing, this publi­ca­tion explo­res the cur­rent infra­struc­tu­re of softwa­re sys­tems as well as futu­re advan­ce­ments. This book is ide­al­ly desi­gned for softwa­re engi­ne­ers, IT spe­cia­li­sts, data scien­ti­sts, busi­ness pro­fes­sio­nals, deve­lo­pers, rese­ar­chers, stu­dents, and aca­de­mi­cians seeking cur­rent rese­arch on con­tem­po­ra­ry softwa­re engi­ne­ering methods. Source: Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities: 9781799821427: Computer Science & IT Books | IGI Global

O wydawcy

IGI Global is a leading inter­na­tio­nal aca­de­mic publi­sher com­mit­ted to faci­li­ta­ting the disco­ve­ry of pio­ne­ering rese­arch that enhan­ces and expands the body of know­led­ge ava­ila­ble to the rese­arch com­mu­ni­ty. Working in clo­se col­la­bo­ra­tion with expert rese­ar­chers and pro­fes­sio­nals from leading insti­tu­tions, inc­lu­ding Massachusetts Institute of Technology (MIT), Harvard University, Stanford University, University of Cambridge, University of Oxford, Tsinghua University, and Australian National University, IGI Global dis­se­mi­na­tes quali­ty con­tent across 350+ topics in 11 core sub­ject are­as. Source: About IGI Global | IGI Global

Synteza pojęć i wzorców MOF, MDA, PIM, MVC i BCE. Zintegrowany model struktury procesu projektowania aplikacji.

Streszczenie: Wiele publi­ka­cji, w tym pod­ręcz­ni­ki aka­de­mic­kie, zawie­ra nie­spój­no­ści w opi­sach zasto­so­wań metod i wzor­ców archi­tek­to­nicz­nych, kry­ją­cych się pod skró­ta­mi MOF, MDA, PIM, MVC, BCE. Skuteczna ana­li­za oraz nastę­pu­ją­ce po niej pro­jek­to­wa­nie opro­gra­mo­wa­nia, szcze­gól­nie gdy są to pro­jek­ty reali­zo­wa­ne w dużych zespo­łach, wyma­ga stan­da­ry­za­cji pro­ce­su wytwór­cze­go i sto­so­wa­nych wzor­ców i fra­me­wor­ków. W pra­cy tej pod­ję­to pró­bę upo­rząd­ko­wa­nia sys­te­mu pojęć opi­su­ją­cych ten pro­ces , sto­so­wa­nych do opi­su wzor­ców archi­tek­to­nicz­nych. Przeprowadzono ana­li­zę klu­czo­wych pojęć MOF i MDA, wzor­ców MVC i BCE, stwo­rzo­no spój­ny opis łączą­cy je w jeden system.

1. Wprowadzenie

Celem badań było zwe­ry­fi­ko­wa­nie obec­ne­go sta­nu metod pro­jek­to­wa­nia i opra­co­wa­nie spój­ne­go sys­te­mu pojęć i wzor­ców pro­jek­to­wych w obsza­rze pro­jek­to­wa­nia logi­ki opro­gra­mo­wa­nia, jako jej abs­trak­cyj­ne­go mode­lu. Wiele publi­ka­cji na temat ana­liz i pro­jek­to­wa­nia, w obsza­rze inży­nie­rii opro­gra­mo­wa­nia, przy­wo­łu­je nazwy wzor­ców pro­jek­to­wych MVC i BCE oraz model PIM (patrz OMG MDA, OMG MOF 2016). Z uwa­gi na, nie raz, nie małe roz­bież­no­ści w inter­pre­ta­cji tych metod i wzor­ców, autor pod­jął pró­bę upo­rząd­ko­wa­nia ich wza­jem­nych zależności.

2. Metody

Wykorzystano sys­te­my nota­cyj­ne Object Management Group (OMG​.org). Specyfikacja MOF opi­su­je trzy pozio­my abs­trak­cji: M1, M2, M3 oraz poziom M0 czy­li real­ne rze­czy (patrz struk­tu­ra pozio­mów abs­trak­cji, OMG MOF 2016). M0 to real­ny sys­tem, poziom M1 to abs­trak­cja obiek­tów tego sys­te­mu (jego model) . Poziom M2 to związ­ki pomię­dzy kla­sa­mi tych obiek­tów (nazwy ich zbio­rów) czy­li meta­mo­del sys­te­mu. Poziom M3 to meta-meta­mo­del poziom opi­su­ją­cy meto­dę mode­lo­wa­nia z uży­ciem nazwa­nych ele­men­tów o okre­ślo­nej seman­ty­ce i syntaktyce.

Proces ana­li­zy i pro­jek­to­wa­nia został opar­ty na spe­cy­fi­ka­cji MDA (OMG MDA). Proces ten ma trzy fazy rozu­mia­ne jako two­rze­nie kolej­nych mode­li: CIM, PIM, PSM oraz fazę two­rze­nie kodu. Model CIM jest doku­men­to­wa­ny z uży­ciem nota­cji BPMN (OMG BPMN 2013) i SBVR (OMG SBVR 2017). Są to odpo­wied­nio: mode­le pro­ce­sów biz­ne­so­wych oraz mode­le poję­cio­we i regu­ły biz­ne­so­we. Modele PIM i PSM doku­men­to­wa­ne są z uży­ciem nota­cji UML (OMG UML 2017). Pomiędzy mode­lem CIM a PIM ma miej­sce usta­le­nie listy usług apli­ka­cyj­nych (reak­cje sys­te­mu), któ­rych mecha­nizm reali­za­cji opi­su­je model PIM. Standardowym wzor­cem uży­wa­nym do mode­lo­wa­nia archi­tek­tu­ry apli­ka­cji jest wzo­rzec MVC. Komponent Model tego wzor­ca jest mode­lo­wa­ny z uży­ciem wzor­cza archi­tek­to­nicz­ne­go BCE.

[…]

Spis tre­ści
1. Wprowadzenie 1
2. Metody 2
2.1. Semiotyka a UML 2
2.2. Specyfikacja MOF Poziomy abs­trak­cji 3
2.3. Specyfikacja MDA i model PIM 4
2.4. Wzorzec archi­tek­to­nicz­ny MVC 5
2.5. Wzorzec archi­tek­to­nicz­ny BCE 5
3. Rezultaty 6
3.1. Założenie uprosz­cza­ją­ce 6
3.2. Zintegrowany model struk­tu­ry pro­ce­su pro­jek­to­wa­nia apli­ka­cji 7
4. Dyskusja 8
5. Dalsze pra­ce 8
6. Bibliografia 9
7. Kluczowe poję­cia meto­dycz­ne 11

Cała publi­ka­cja …

Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns
Jaroslaw Zelinski (Independent Researcher, Poland)

Source Title: Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities
Copyright: ? 2020 |Pages: 12
DOI: 10.4018/978 – 1‑7998 – 2142‑7.ch003

TOGAF or not TOGAF więc może Zachman

Badanie przy­dat­no­ści TOGAF/ArchiMate mam chy­ba za sobą (zapew­ne nie na mia­rę dok­to­ra­tu ale trosz­kę jed­nak tak, cho­ciaż…;)). Na stro­nie moje­go kole­gi: ArchitekturaKorporacyjna​.pl (pole­cam ana­li­ty­kom), w jed­nym z arty­ku­łów poja­wia się cie­ka­we stwierdzenie:

TOGAF wska­zu­je, że nie­wła­ści­we pod­czas mode­lo­wa­nia jest bez­po­śred­nie wią­za­nie pro­ce­su [biz­ne­so­we­go, jak sądzę] z apli­ka­cją go wspie­ra­ją­cą ? ele­men­tem pośred­nim powin­na być funk­cja ? czy­li: apli­ka­cja wspie­ra reali­za­cję funk­cji, a funk­cja obej­mu­je cały pro­ces lub jego frag­ment (w zależ­no­ści od pozio­mu dekom­po­zy­cji funk­cji biz­ne­so­wej). (Komentarze do TOGAF ? meta­mo­del zawar­to­ści (cz. II) | Architektura Korporacyjna).

i to jest coś co jako pierw­sze mnie zra­zi­ło w nota­cji ArchiMate: prze­rost poję­cio­wy (roz­drob­nie­nie albo jak kto woli nad­mier­na gra­da­cja). Umieszczenie dodat­ko­we­go poję­cia – funk­cja – pomię­dzy pro­ce­sem biz­ne­so­wym (pamię­ta­my, że samo­dziel­na czyn­ność to tak­że pro­ces) a narzę­dziem pra­cy jakim jest opro­gra­mo­wa­nie wyda­je się sztucz­ne. To trosz­kę jak umiesz­cze­nie pomię­dzy młot­kiem a pro­ce­sem wbi­ja­nia gwoź­dzia funk­cji wbi­ja­nie”, nie wiem jaką war­tość wno­si to do mode­lu, sko­ro mło­tek ma funk­cję (przy­pa­dek uży­cia) wbi­ja­nie” (pamię­taj­my, że opro­gra­mo­wa­nie to narzę­dzie pra­cy akto­ra, zasób).

Prowadzi to do nie­kom­pa­ty­bil­no­ści z sys­te­mem poję­cio­wym para­dyg­ma­tu obiek­to­we­go (MDA/OMG), na któ­ry ArchiMate się powo­łu­je, tym bar­dziej, że jed­nak MDA to stan­dard pro­ce­su obiek­to­we­go two­rze­nia opro­gra­mo­wa­nia więc po co z nim wal­czyć? Testowałem mode­le ArchiMate na ludziach” i oka­zy­wa­ło się, że dla wie­lu z nich tak­że są one nie­in­tu­icyj­ne. Trudno mi też wytłu­ma­czyć ten nad­miar poję­cio­wy: sko­ro w natu­rze” czyn­ność jest wspie­ra­na usłu­gą sys­te­mu” to po co pako­wać mię­dzy nie, mię­dzy tę wód­kę a zaką­skę” ;), poję­cie biz­ne­so­wej funk­cji opro­gra­mo­wa­nia sko­ro ono świad­czy jakąś usłu­gę, bo jest ona funk­cjo­nal­no­ścią tego oprogramowania.

Trzy warstwy modelowaniaAutorzy ArchiMate wska­zu­ją, że tam gdzie ArchiMate jest zbyt ogól­ne, nale­ży użyć odpo­wied­nio BPMN lub UML. Ale tu poja­wia się pro­blem: w UML usłu­ga opro­gra­mo­wa­nia to przy­pa­dek uży­cia powią­za­ny bez­po­śred­nio z akto­rem, któ­ry ma swój cel dzia­ła­nia (uży­cia sys­te­mu w trak­cie reali­za­cji pro­ce­su biz­ne­so­we­go). Czyli usłu­ga opro­gra­mo­wa­nia jest jed­nak poję­cio­wo bez­po­śred­nio zwią­za­na z czyn­no­ścią w pro­ce­sie, któ­rą wspie­ra (cel pra­cy akto­ra). To tyl­ko jed­na z nie­spój­no­ści. Jeżeli uznać, że pro­ces two­rze­nia opro­gra­mo­wa­nia to trzy fazy MDA opi­sa­ne przez OMG czy­li CIM, PIM i PSM (model biz­ne­so­wy, model logi­ki sys­te­mu, model jego imple­men­ta­cji), to nie­ste­ty TOGAF i ArchiMate są z nim nie­kom­pa­ty­bil­ne a TOGAF/ArchiMate nie daje nic w zamian, więc jest problem…

Z dru­giej stro­ny potrzeb­ne jest w każ­dym więk­szym pro­jek­cie upo­rząd­ko­wa­nie wie­dzy o orga­ni­za­cji z pomo­cą mode­li (któ­rych tu będzie wię­cej nią jeden) czy­li zro­zu­mie­nie jej zacho­wa­nia, wyma­ga to uję­cia tych mode­li w struk­tu­rę. Po co? By mieć mier­nik pozwa­la­ją­cy odpo­wie­dzieć na pyta­nie: Czy mamy już wszyst­kie potrzeb­ne mode­le, czy rozu­mie­my tę orga­ni­za­cję. Modele te to: pro­ce­sy biz­ne­so­we oraz obiek­to­we struk­tu­ry opro­gra­mo­wa­nia. Do tego mode­le poję­cio­we i regu­ły biz­ne­so­we. Wszystko to – nota­cje i ich mode­le poję­cio­we – jest bar­dzo dobrze opra­co­wa­ne w przez OMG. Czego bra­ku­je? Metamodelu cało­ści. Tu z pomo­cą przy­cho­dzi tak zwa­na [[Siatka Zachmana]]. Cóż to jest?

Siatka Zachmana (ang. Zachman Framework) ? sza­blon i spo­sób postę­po­wa­nia, któ­ry pozwa­la w spo­sób for­mal­ny i ści­śle ustruk­tu­ra­li­zo­wa­ny defi­nio­wać archi­tek­tu­rę sys­te­mów kor­po­ra­cyj­nych. Używa siat­ki bazu­jąc na sze­ściu pod­sta­wo­wych pyta­niach (Co, Jak, Gdzie, Kto, Kiedy, Dlaczego) zada­nych pię­ciu gru­pom użyt­kow­ni­ków (Planujący, Właściciel, Projektant, Twórca, Podwykonawca) aby przed­sta­wić holi­stycz­ny obraz przed­się­bior­stwa, któ­re jest mode­lo­wa­ne. (Siatka Zachmana ? Wikipedia, wol­na ency­klo­pe­dia).

Taka kom­plet­na siat­ka (matry­ca) wyglą­da tak:

Siatka Zachmana zakres analizy

Jest to peł­ny opis orga­ni­za­cji. Nie zawsze jest potrze­ba two­rze­nia cało­ści. Na eta­pie typo­wej ana­li­zy biz­ne­so­wej i ana­li­zy wyma­gań potrzeb­ne są eta­py CIM i PIM. W siat­ce Zachmana moż­na pomi­nąć zbęd­ne (tu nad­mia­ro­we, Zachman dopusz­cza czę­ścio­we struk­tu­ry) kolum­ny i wier­sze nadal zacho­wu­jąc kom­pa­ty­bil­ność z MDA:

Siatka Zachmana zakres analizy CIM PIM

Powyższe to nic inne­go jak matry­ca pozwa­la­ją­ca zbu­do­wać upo­rząd­ko­wa­ny model orga­ni­za­cji i umie­ścić w nim ist­nie­ją­ce, wspie­ra­ją­ca ją opro­gra­mo­wa­nie i (lub) opi­sać to, któ­re powin­no się w niej poja­wić czy­li wyma­ga­nia. Powyższe mapu­je się w 100% na model MDA: CIM i PIM. Nie trze­ba więc nicze­go zmie­niać a model poję­cio­wy jest spój­ny. Jeżeli ktoś korzy­sta z mode­lu MDA/OMG, bez pro­ble­mu może przy­po­rząd­ko­wać polom (prze­cię­cia wier­szy i kolumn) mode­le nota­cji BPMN, UML i BMM, a tak­że sys­te­my reguł biz­ne­so­wych i słow­nik pojęć dzie­dzi­no­wych. (powyż­sze zrzu­ty ekra­no­we narzę­dzia Agilian)

Z każ­dym kolej­nym pro­jek­tem skła­niam się ku tezie, że Architektura Korporacyjna, jako cało­ścio­we (lub jak kto woli: holi­stycz­ne) podej­ście do doku­men­to­wa­nia (mode­lo­wa­nia) orga­ni­za­cji, bliż­sza jest Siatce Zachmana niż TOGAF’owi, któ­ry w moich oczach jest po pro­tu prze­kom­bi­no­wa­ny i nie­kom­pa­ty­bil­ny z nota­cja­mi, od któ­rych raczej nie ma uciecz­ki (BPMN, UML, BMM a nawet struk­tu­ral­ne ERD i DFD).

Powyższy uprosz­czo­ny (wyłą­czo­ne nie­uży­wa­ne wier­sze i kolum­ny) kształt Siatki Zachmana, coraz czę­ściej słu­ży mi jako zakres pro­jek­tu ana­li­tycz­ne­go i korzeń jego struk­tu­ry. Poszukując mate­ria­łów na ten temat zna­la­złem opra­co­wa­nie opu­bli­ko­wa­ne na stro­nie Business Process Trends już w 2003 roku o wdzięcz­nym tytu­le: [[The Zachman Framework and the OMG’s Model Driven Architecture]]. Poniżej, na zakoń­cze­nie, dwa dia­gra­my zapo­ży­czo­ne z tego opracowania:

- mapo­wa­nie MDA na Siatkę Zachmana:

MDA2Zachman

oraz wska­za­nie, gdzie zasto­so­wać nota­cje UML:

UML2ZachmanPowyższy dia­gram war­to uzu­peł­nić uwa­gą, że zasto­so­wa­nie nota­cji BPMN w obsza­rze pro­ce­sów biz­ne­so­wych wyda­je się być obec­nie znacz­nie roz­sąd­niej­sze (w 2003 roku, nie była sto­so­wa­na), zaś w obsza­rze moty­wa­cji dosko­na­le spra­wu­je się BMM. OMG daje tak­że upo­rząd­ko­wa­ne sys­te­mu zapi­su reguł biz­ne­so­wych i słow­ni­ków pojęć.

TOGAF ma ambi­cje porów­ny­wa­nia się z Siatką Zachmana, jed­nak w moim odczu­ciu obsza­ro­we porów­na­nie – zgod­ność – to nie to samo z kom­pa­ty­bil­ność (tu już jej brak) z sys­te­ma­mi poję­cio­wy­mi (uzna­ny­mi za stan­dar­dy nota­cja­mi), bo to tu tkwi sens i sed­no pro­ble­mu. Jak na razie nie sądzę, by nota­cja ArchiMate – język wyra­zu TOGAF’a – wypar­ło doro­bek OMG, a nie­ste­ty nie jest w sta­nie go zastą­pić. Obecna postać Siatki Zachman v.3.0. to już ugrun­to­wa­na onto­lo­gia. (czy­sty pla­kat ZachmaFramework 3.0, widać na nim bar­dzo waż­ną rzecz: śla­do­wa­nie, mapo­wa­nie pomię­dzy modelami).

Siatka Zachmana w uży­ciu – pakiet Visual-Paradigm.

c.d.n.