Wstęp

W 2017 roku pisa­łem dość ogól­nie o logi­ce wzor­ca archi­tek­to­nicz­ne­go MVC koń­cząc arty­kuł 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 – kom­po­nent Model w archi­tek­tu­rze sys­te­mu – Jarosław Żeliński IT-Consulting

W sie­ci jest wie­le opi­sów tego wzor­ca, jed­nak nie wszyst­kie są popraw­ne, szcze­gól­nie tam gdzie auto­rzy piszą, że to odpo­wied­nik trój­war­stwo­wej archi­tek­tu­ry: war­stwy pre­zen­ta­cji, logi­ki i danych czy też, że wzo­rzec ten sepa­ru­je logi­kę biz­ne­so­wą i dane jako odpo­wied­nio con­trol­ler i model. Gdyby tak było, była­by to trój­war­stwo­wa archi­tek­tu­ra, a nie obiek­to­wy wzo­rzec archi­tek­to­nicz­ny. Model-View-Controller. Nie jest też praw­dą, że te trzy kom­po­nen­ty są połą­czo­ne w trój­kąt, gdzie aktor ma jakieś bez­po­śred­nie inte­rak­cje z kom­po­nen­tem Controller czy Model (pyta­nie jak?). 

Co moż­na spo­tkać w sie­ci? Po wpi­sa­niu do wyszu­ki­war­ki model view con­trol­ler pat­tern” na pierw­szej stro­nie zoba­czy­my np. to:

Jak widać róż­no­rod­ność jest dość duża. Co cie­ka­we, nadal wzor­ce MVC i BCE bywa­ją mylo­ne lub uzna­wa­ne za ten sam wzo­rzec, co jest ogrom­nym błę­dem. Warto też zwró­cić uwa­gę na czę­ste nad­uży­wa­nie i nie­pra­wi­dło­we sto­so­wa­nie przez pro­jek­tan­tów i deve­lo­pe­rów nota­cji UML .

Ten arty­kuł powstał mię­dzy inny­mi na bazie wybra­nych for­mal­nych (lite­ra­tu­ra na koń­cu) i nie­for­mal­nych (poniż­sze) źró­deł opi­su­ją­cych wzor­ce i frameworki:

Chrome Developers. MVC Architecture’. Accessed 18 November 2022. https://​deve​lo​per​.chro​me​.com/​d​o​c​s​/​a​p​p​s​/​a​p​p​_​f​r​a​m​e​w​o​r​ks/.

InterviewBit. MVC Architecture – Detailed Explanation’, 27 May 2022. https://​www​.inte​rview​bit​.com/​b​l​o​g​/​m​v​c​-​a​r​c​h​i​t​e​c​t​u​re/.

Prabhu, John. MVC Architecture & Its Benefits in Web Application Development’. Tech Blogs by TechAffinity (blog), 18 July 2019. https://​techaf​fi​ni​ty​.com/​b​l​o​g​/​m​v​c​-​a​r​c​h​i​t​e​c​t​u​r​e​-​b​e​n​e​f​i​t​s​-​o​f​-​m​vc/.

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

Svirca, Zanfina. Everything You Need to Know abo­ut MVC Architecture’. Medium, 30 May 2020. https://​towards​da​ta​scien​ce​.com/​e​v​e​r​y​t​h​i​n​g​-​y​o​u​-​n​e​e​d​-​t​o​-​k​n​o​w​-​a​b​o​u​t​-​m​v​c​-​a​r​c​h​i​t​e​c​t​u​r​e​-​3​c​8​2​7​9​3​0​b​4c1.

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

Opisywane tu meto­dy pra­cy i ich pro­duk­ty wywo­dzą sie z zali­cza­nej do zwin­nych, obiek­to­wo-zorien­to­wa­nej meto­dy­ki ICONIX i jej pochod­nych. Jej pod­sta­wą jest orien­ta­cja na przy­pad­ki uży­cia i kom­po­nen­to­wo-obiek­to­wy cha­rak­ter archi­tek­tu­ry dzie­lo­nej na HLD (archi­tek­tu­ra apli­ka­cji) i LLD (wewnętrz­na archi­tek­tu­ra kom­po­nen­tów). Co cie­ka­we meto­da ta od począt­ku jej powsta­nia abs­tra­hu­je od tech­no­lo­gii i mode­lu danych . Swego cza­su pod­ją­łem pró­bę usys­te­ma­ty­zo­wa­nia pod­sta­wo­wych wzor­ców pro­jek­to­wych na tle MDA . Ta, potrój­nie recen­zo­wa­na, publi­ka­cja jest dostęp­na w IGI Global (IGI Global jest wio­dą­cym, śred­niej wiel­ko­ści, nie­za­leż­nym wydaw­cą aka­de­mic­kim mię­dzy­na­ro­do­wych badań nauko­wych). Poniżej klu­czo­we ele­men­ty tego opra­co­wa­nia doty­czą­ce wzor­ca MVC i pokrew­nych. Osobom zain­te­re­so­wa­nym deta­la­mi pole­cam lek­tu­rę tej publikacji. 

Zakres projektu

Zawieranie umo­wy na zakres pro­jek­tu i pro­jek­to­wa­nie to inży­nie­ria (a nie inży­nie­ria wyma­gań, po pro­stu inży­nie­ria, ewen­tu­al­nie inży­nie­ria opro­gra­mo­wa­nia, albo ogól­niej inży­nie­ria systemów). 

Diagram Przypadków uży­cia (nota­cja UML)

Zakres pro­jek­tu to usłu­gi apli­ka­cyj­ne jakie ma świad­czyć System. Kontekst sys­te­mu to jego oto­cze­nie wyra­żo­ne w posta­ci akto­rów (User, Application 1, Application 2). Powyższy System reali­zu­je dwie usłu­gi: jed­ną użyt­kow­ni­ko­wi, dru­gą wewnętrz­ne­mu sys­te­mo­wi (Application 2). Sam zaś korzy­sta z usług zewnętrz­ne­go sys­te­mu Application 1. 

Kolejny etap to opra­co­wa­nie archi­tek­tu­ry Systemu. Tu naj­czę­ściej korzy­sta­my wła­śnie z wzor­ca MVC. 

Wzorzec MVC

Jest to tak na praw­dę podział apli­ka­cji na śro­do­wi­sko wyko­naw­cze (Controller, to prak­tycz­nie run­ti­me sys­te­mu), śro­do­wi­sko pra­cy użyt­kow­ni­ka (View) oraz motor sys­te­mu” czy­li logi­ka zde­fi­nio­wa­na jako mecha­nizm dzia­ła­nia sys­te­mu”: jest to wła­ści­wy pro­jekt PIM apli­ka­cji i potem jej ser­ce .

Architektura apli­ka­cja reali­zo­wa­nych na bazie wzor­ca MVC (dia­gram kom­po­nen­tów UML, wzo­rzec MVC)

Powyższy dia­gram to wewnętrz­na archi­tek­tu­ra Systemu poka­za­ne­go wcze­śniej na dia­gra­mie przy­pad­ków uży­cia. Działająca apli­ka­cja to śro­do­wi­sko (View i Controller) oraz wła­ści­wy pro­gram apli­ka­cji (Model, patrz też Domanin Model).

Model PIM naszej apli­ka­cji to spe­cy­fi­ka­cja, wyra­żo­na jako mode­le w nota­cji UML. Na powyż­szym dia­gra­mie jest to ele­ment Domanin Model, ozna­czo­ny na dia­gra­mie ste­reo­ty­pem «arti­fact». Jest to w nomen­kla­tu­rze praw­nej (prze­tar­gi) tak zwa­ny Opis Techniczny Oprogramowania czy­li: struk­tu­ra i dyna­mi­ka apli­ka­cji, algo­ryt­my, mode­le danych, itp., wyra­żo­ne w spo­sób tech­nicz­ny, czy­li w posta­ci sche­ma­tów blo­ko­wych wyko­na­nych w nota­cji UML. Developer, w wybra­nej przez sie­bie tech­no­lo­gii, wyko­nu­je imple­men­ta­cję, czy­li opro­gra­mo­wa­nie reali­zu­ją­ce ten model. Jest to wyra­ża­nie wyma­gań w for­mie mode­lu sys­te­mu (MBSE).

Powyższa for­ma to logicz­na postać tego wzor­ca (MVC) poka­zu­ją­ca komu­ni­ka­cję mię­dzy tymi trze­ma kom­po­nen­ta­mi. Znacznie wła­ściw­sze było by poka­za­nie kom­po­nen­tu Controller jako śro­do­wi­ska wyko­naw­cze­go (biblio­te­ki i API do oto­cze­nia sys­te­mo­we­go) co zobra­zo­wa­no poniżej:

Controller jako śro­do­wi­sko wyko­naw­cze run­ti­me (dia­gram wdro­że­nia nota­cji UML)

Wzorzec BCE

Wzorzec BCE ma swój rodo­wód w meto­dy­ce ICONIX . Pierwotnie opar­ty był na fra­me­wor­ku EJB i wspie­rał pro­jek­to­wa­nie w tym śro­do­wi­sku (robust­ness dia­gram, odno­śni­ki do POJO, DAO, model dzie­dzi­ny, dla­te­go teraz EJB nazwa­ny ane­micz­nym mode­lem i antyw­zor­cem). Kluczową ideą wzor­ca ICONIX orien­ta­cja archi­tek­tu­ry i pro­ce­su pro­jek­to­we­go na przy­pad­ki uży­cia, roz­wi­ja­na póź­niej przez Jacobsona i innych pod nazwą Use Case 2.0 .

Każda usłu­ga apli­ka­cji w tym podej­ściu (jej przy­pa­dek uży­cia) to nie­za­leż­ny zamknię­ty kom­po­nent, dostęp­ny przez jego wła­sne API. Komponent taki może mieć (i z regu­ły ma) udo­ku­men­to­wa­ną wła­sną wewnętrz­ną, nie raz nie­try­wial­ną, architekturę:

Architektura reali­za­cji poje­dyń­czej usłu­gi apliak­cji (dia­gram klas UML, wzo­rzec BCE + Repository + Envelope)

Każda usłu­ga jest reali­zo­wa­na przez klu­czo­we typy kom­po­nen­tów: inter­fejs kom­po­nen­tu, reali­za­cja logi­ki biz­ne­so­wej (dzie­dzi­no­wej), reali­za­cja dostę­pu do obiek­tów w repo­zy­to­rium, obiek­ty w repo­zy­to­rium (nośni­ki danych zapi­sy­wa­nych tu w posta­ci doku­men­tów). Wzorzec BCE był tu opi­sy­wa­ny sze­rzej w arty­ku­le Wzorce pro­jek­to­we w ana­li­zie i pro­jek­to­wa­niu mode­lu dzie­dzi­ny sys­te­mu.

Wiele emo­cji i kon­tro­wer­sji budzi doku­men­to­wa meto­da zarzą­dza­nia dany­mi. Dane są tu zapi­sy­wa­ne w zwar­tej zma­te­ria­li­zo­wa­nej posta­ci. Najczęściej w for­ma­cie JSON lub XML (ele­ment DataForm ozna­czo­ny ste­reo­ty­pem «Document»). Jeżeli jest to nowy kom­po­nent sta­rej apli­ka­cji, zbu­do­wa­nej na rela­cyj­nym mode­lu danych, naj­czę­ściej sto­so­wa­ny jest w tym miej­scu wzo­rzec pro­jek­to­wy Active Record, rza­dziej Active Table. Z jego pomo­cą ope­ra­cje upda­te i retrie­ve obiek­tów kla­sy Data enve­lo­pe”, są imple­men­to­wa­ne jako zapy­ta­nia SQL do rela­cyj­nej bazy danych. Klasa Data enve­lo­pe” sta­no­wi wte­dy API do tej sta­rej bazy danych. Takie podej­ście unie­za­leż­nia pro­jek­tan­ta i pro­jekt, od meto­dy i tech­no­lo­gii utrwa­la­nia danych oraz od potrze­by zna­jo­mo­ści SQL. Jako pro­jek­tant uwa­żam, że jest to dobre wyj­ście przy roz­bu­do­wie sta­rych sys­te­mów lega­cy. Jednak model rela­cyj­ny, szcze­gól­nie w sys­te­mach biz­ne­so­wych, sta­no­wi ogrom­ne ogra­ni­cze­nie roz­wo­jo­we na przy­szłość i unie­moż­li­wia sto­so­wa­nie repo­zy­to­riów NoSQL w chmurze.

Podsumowanie

Podstawową zale­cą wzor­ca MVC jest odse­pa­ro­wa­nie (her­me­ty­za­cja) logi­ki dzie­dzi­no­wej od śro­do­wi­ska wyko­naw­cze­go apli­ka­cji. Dzięki cze­mu moż­li­we jest pro­jek­to­wa­nie wyłącz­nie mode­lu dzie­dzi­ny sys­te­mu i jego póź­niej­sza, nie­za­leż­na od tech­no­lo­gii, imple­men­ta­cja. Dodatkową korzy­ścią jest tu powsta­ją­ca doku­men­ta­cja, sta­no­wią­ca ochro­nę know-how spon­so­ra pro­jek­tu, co w obec­nych cza­sach nabie­ra coraz więk­sze­go znaczenia. 

Dostępne w lite­ra­tu­rze sche­ma­ty blo­ko­we poka­zu­ją­ce ideę wzor­ca MVC, poka­zu­ją czę­sto logi­kę dzia­ła­nia tego wzor­ca, rozu­mia­ną jako prze­sy­ła­nie komu­ni­ka­tów. Stąd praw­do­po­dob­nie sche­ma­ty w posta­ci trój­ką­ta. Jednak war­to wie­dzeć, że fizycz­nie jest to podział apli­ka­cji na jej śro­do­wi­sko (biblio­te­ki, API to oto­cze­nia) i kom­po­nent reali­zu­ją­cy dzie­dzi­no­wą logi­kę, któ­ra odpo­wia­da za reali­za­cję funk­cjo­nal­no­ści opro­gra­mo­wa­nia. Odmianą tego wzor­ca jest MV-VM. Jest to wzo­rzec uwzgled­nia­ją­cy fakt, że śro­do­wi­sko wyko­naw­cze może być podzie­lo­ne na część ser­we­ro­wą i część wyko­ny­wa­ną np. w prze­glą­dar­ce WWW (patrz arty­kuł Aplikacje webo­we i mikro­ser­wi­sy czy­li archi­tek­tu­ra sys­te­mów webo­wych) lub w smart­fo­nie. Przeglądarka WWW, czy sys­tem ope­ra­cyj­ny (śro­do­wi­sko) smart­fo­na, to kolej­ny run­ti­me: zestaw lokal­nych biblio­tek i API do oto­cze­nia (np. lokal­na pamięć, dysk twar­dy, dane z modu­łu GPS, itp.). 

Dodatek: inżynier vs. developer

Dlatego od pew­ne­go cza­su już roz­róż­nia­my poję­cie softwa­re engi­ne­er” i softwa­re deve­lo­per”. Drugi opra­co­wu­je i wyko­nu­je imple­men­ta­cje tego co zapro­jek­tu­je pierw­szy. Pojęcie pro­gra­mi­sty ma od pew­ne­go już cza­su nie­co inny kontekst:

Programming is not sole­ly abo­ut con­struc­ting softwa­re — pro­gram­ming is abo­ut desi­gning software.

Pamiętajmy więc, że pro­gra­mo­wa­nie to opra­co­wa­nie tego jak ma być prze­twa­rza­na infor­ma­cja repre­zen­to­wa­na jako dane w apli­ka­cji, a nie tego jaką tech­no­lo­gią mają być prze­twa­rza­ne dane. To dru­gie reali­zu­je deve­lo­per, pierw­sze inży­nier, archi­tekt całe­go systemu. 

softwa­re deve­lo­per vs softwa­re engi­ne­er
Generally, softwa­re engi­ne­ers look after the big­ger pic­tu­re, whi­le softwa­re deve­lo­pers focus on one area to exe­cu­te the­ir plans. Engineers can act as deve­lo­pers, too, or sim­ply over­see deve­lo­pers who cre­ate func­tio­nal programs.

https://​www​.rand​stad​.co​.uk/​c​a​r​e​e​r​-​a​d​v​i​c​e​/​c​a​r​e​e​r​-​g​u​i​d​a​n​c​e​/​f​u​l​l​-​s​t​a​c​k​-​d​e​v​e​l​o​p​e​r​-​v​s​-​s​o​f​t​w​a​r​e​-​e​n​g​i​n​e​er/

Tak więc opra­co­wa­nie mode­lu dzie­dzi­ny sys­te­mu, czy­li zapro­jek­to­wa­nie sys­te­mu, to rola inży­nie­ra, któ­ry tu jest archi­tek­tem sys­te­mu infor­ma­cyj­ne­go. Zaprojektowanie śro­do­wi­ska wyko­naw­cze­go o opra­co­wa­nie imple­men­ta­cji to rola developera:

Software Engineer vs. Developer

Źródła

Ogedebe, M., & Silas, F. (2015). Abuse of Unified Modeling Language Diagrams in Software Development. British Journal of Mathematics & Computer Science, 10(1), 1 – 9. https://​doi​.org/​1​0​.​9​7​3​4​/​B​J​M​C​S​/​2​0​1​5​/​1​7​075
Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software, 37(2), 3 – 5. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​1​9​.​2​9​5​9​049
Ozkaya, M., & Fidandan, I. (2020). MVCLang: A Software Modeling Language for the Model-View-Controller Design Pattern: Proceedings of the 15th International Conference on Software Technologies, 75 – 83. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​9​5​7​1​4​0​0​7​5​0​083
Rosenberg, D., & Stephens, M. (2007). Introduction to ICONIX Process. Use Case Driven Object Modeling with UML: Theory and Practice, 1 – 20.
Rosenberg, D., Stephens, M., & Collins-Cope, M. (2005). Agile deve­lop­ment with ICONIX pro­cess: people, pro­cess, and prag­ma­tism. Apress.
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

Jarosław Żeliński

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.

Dodaj komentarz

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