Wprowadzenie

bar­dzo czę­sto mozna spo­tkać opi­su typu: 

MVC archi­tec­tu­re. AngularJS divi­des your web app into three distinct parts — Model (data), View (the UI lay­er), and Controller (busi­ness logic). The three units can be deve­lo­ped in paral­lel and sepa­ra­te­ly tested. As a result, the code beco­mes easier to under­stand, main­ta­in, and extend.

(https://​www​.alte​xsoft​.com/​b​l​o​g​/​t​h​e​-​g​o​o​d​-​a​n​d​-​t​h​e​-​b​a​d​-​o​f​-​a​n​g​u​l​a​r​-​d​e​v​e​l​o​p​m​e​nt/)

Niestety jest to powie­la­nie podej­ścia z cza­sów lat 90-tych i JavaEE/SE. Patrząc na te trzy poję­cia View to owszem wido­ki” czy­li GUI, nie­po­ro­zu­mie­nia doty­czą Model’u i Controler’a. Poniżej obec­ne źró­dło (jed­no z wie­lu) tego nieporozumienia:

Model to klu­czo­wa część apli­ka­cji: to imple­men­ta­cja mode­lu PIM (Platform Independent Model) czy­li kom­po­nen­tu reali­zu­ją­ce­go wyma­ga­nia funk­cjo­nal­ne; tu są biz­ne­so­we dane i logi­ka. Controller to śro­do­wi­sko wyko­naw­cze ste­ru­ją­ce cało­ścią, np. tak­że logo­wa­niem czy infor­mo­wa­niem mode­lu o tym jaką mamy teraz datę. Taki podział: sepa­ro­wa­nie kodu śro­do­wi­ska od kodu reali­zu­ją­ce­go logi­kę biz­ne­so­wą, ma głę­bo­ki sens, gdyż zmien­ność śro­do­wi­ska jest mała (upgra­de fra­me­wor­ka to raczej rzad­kie zja­wi­sko) a zmien­ność biz­ne­so­wy” duża. To ozna­cza, że w obu tych czę­ściach nale­ży sto­so­wać zupeł­nie inne wzor­ce pro­jek­to­we. Separujemy tu (her­me­ty­zu­je­my) tak­że dane biz­ne­so­we, któ­re real­nie orga­ni­zo­wa­ne są w doku­men­ty a nie w tabe­le. Dlatego utrwa­la­nie danych nie jest czę­ścią logi­ki biznesowej. 

Podział taki i jego zale­ty opi­sał już Cockburn w 2005 roku . Jest to lekar­stwo na tak zwa­ne roz­sma­ro­wa­nie” logi­ki biz­ne­so­wej po całym kodzie: od GUI aż po bazę danych SQL. W tym arty­ku­le wyja­śniam to nie­po­ro­zu­mie­nie, jego przy­czy­ny i skut­ki. Nie przy­pad­kiem też akro­nim MVC bywa roz­wi­ja­ny jako: Mechanizm, View, Controller. 

Model

O mode­lu, a kon­kret­nie o kom­po­nen­cie Model, w archi­tek­tu­rze sys­te­mu. W 2017 roku pisałem:

Czy musi­my znać opis wszel­kich zacho­wań sys­te­mu? Nie, i z regu­ły nie jeste­śmy w sta­nie ich wszyst­kich opi­sać, zresz­tą nie ma takiej potrze­by. Jednak mecha­nizm (wie­dza jak coś dzia­ła) pozwa­la nam wyja­śnić zaob­ser­wo­wa­ne zacho­wa­nia oraz prze­wi­dzieć przy­szłe (dokład­nie tak jak teo­ria nauko­wa). Niewątpliwie mło­tek został stwo­rzo­ny do wbi­ja­nia gwoź­dzi i ten jego ?przy­pa­dek uży­cia? był przy­czy­ną (wyma­ga­nie) jego skon­stru­owa­nia, jed­nak wie­dząc jak jest skon­stru­owa­ny i zna­jąc pra­wa fizy­ki, jeste­śmy w sta­nie prze­wi­dzieć prak­tycz­nie wszel­kie inne skut­ki nawet nie obser­wo­wa­ne wcze­śniej, np. nie musi­my usły­szeć od niko­go ?user sto­ry? by prze­wi­dzieć co się sta­nie gdy rzu­ci­my młot­kiem w szy­bę okna sąsia­da. (Źródło: Czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny czy­li model obiek­to­wy sys­te­mu | | Jarosław Żeliński IT-Consulting

Istotą zro­zu­mie­nia okre­ślo­nej rze­czy­wi­sto­ści jest jej mecha­nizm dzia­ła­nia. Dokładnie tak jak w przy­pad­ku przy­ro­dy i jej praw. Zrozumienie ota­cza­ją­ce­go świa­ta to odkry­cie i stwo­rze­nie jego – lub kon­kret­nej jego czę­ści – mode­lu. Jest nim tak­że każ­da organizacja.

Jak już wyżej wspo­mnia­no, spe­cy­fi­ko­wa­nie opro­gra­mo­wa­nia meto­dą zbie­ra­nia wyma­gań” od jego przy­szłych użyt­kow­ni­ków, przy­po­mi­na pró­by opi­sa­nia sło­nia przez gru­pę nie­wi­do­mych jak w zna­nej anegdocie.

Tak zebra­ny i upo­rząd­ko­wa­ny mate­riał” to zle­pek spe­ku­la­cji, i nie ma zna­cze­nia jak dłu­go trwa to owo zbie­ra­nie wyma­gań” ani jakich wyra­fi­no­wa­nych form zarzą­dza­nia uży­je­my. Herbata nie będzie słod­sza od same­go mieszania.

Czym jest wyma­ga­nie wobec sys­te­mu? Jest try­wial­ne w swej defi­ni­cji: od sys­te­mu wyma­ga­my by zacho­wy­wał się tak jak chce­my. Jednak, jak już wyżej napi­sa­no, sko­ro nie ma sen­su spi­sy­wać wszyst­kich zna­nych nam reak­cji na bodź­ce, nale­ży stwo­rzyć model czy­li opis mecha­ni­zmu jego działania.

Wzorzec MVC i projektowanie systemu

Pomysł

MVC czy­li Model, View, Controller. Architektura tego wzor­ca w ogól­nej posta­ci ta ma taką oto postać:

Komponenty Model, View, Controller i komu­ni­ka­cja mię­dzy nimi (oraz z otoczeniem)

Wzorzec ten powstał w cza­sach two­rze­nia języ­ka Smalltalk, dzi­siaj ta sepa­ra­cja jest wyja­śnia­na na bazie tak zwa­nej archi­tek­tu­ry heksagonalnej:

Wewnątrz jest apli­ka­cja: kod (kom­po­nent) reali­zu­ją­cy logi­kę dzie­dzi­no­wą, to Model (mecha­nizm dzia­ła­nia, funk­cjo­nal­no­ści). Jest on oto­czo­ny, oddzie­lo­ny od resz­ty świa­ta”, śro­do­wi­skiem wyko­naw­czym. Z uwa­gi na spe­cy­fi­kę pra­cy z czło­wie­kiem, ze śro­do­wi­ska wydziel­my część obsłu­gu­ją­cą dia­log czło­wiek-maszy­na: View. Idea wzor­ca jest taka: cały sys­tem to trzy klu­czo­we komponenty:

  1. View: to kom­po­nent odpo­wie­dzial­ny za pośred­ni­cze­nie w komu­ni­ka­cji pomię­dzy źró­dłem bodź­ców jakim jest jego użyt­kow­nik (aktor) a resz­tą systemu.
  2. Controller: to kom­po­nent ste­ru­ją­cy sys­te­mem, odpo­wia­da za wewnętrz­ne ste­ro­wa­nie i komu­ni­ka­cję z otoczeniem.
  3. Model: to ów klu­czo­wy kom­po­nent sys­te­mu, zależ­nie od celu two­rze­nia sys­te­mu (tu apli­ka­cji) albo jest symu­la­to­rem albo odwzo­ro­wa­niem rzeczywistości.

Ideą tego wzor­ca jest sepa­ra­cja i her­me­ty­za­cja tych trzech dzie­dzi­no­wych obsza­rów. Każdy z tych kom­po­nen­tów może być reali­zo­wa­ny osob­no albo po pro­stu kupio­ny”. Z regu­ły View i Controller to goto­we biblio­te­ki (fra­me­work) wyma­ga­ją­ce głów­nie kon­fi­gu­ra­cji i opra­co­wa­nia okre­ślo­nych sza­blo­nów. Sercem sys­te­mu jest Model, kom­po­nent reali­zu­ją­cy to do cze­go on słu­ży: dzie­dzi­na sys­te­mu. Kupując np. goto­wy pro­gram do księ­go­wa­nia, kom­po­nent ten jest goto­wy. Oprogramowanie, od któ­re­go wyma­ga­my usług nie­stan­dar­do­wych, wyma­ga zapro­jek­to­wa­nia tyl­ko tego kom­po­nen­tu. Bardzo obra­zo­wo poka­zał to Adam Wattis:

Na czym to polega?

Jeżeli apli­ka­cja lub jej kom­po­nent, zastę­pu­je jakąś rze­czy­wi­stość i auto­ma­ty­zu­je jakieś pra­ce, odwzo­ro­wu­je ona okre­ślo­ną rze­czy­wi­stość. Jeżeli słu­ży ona do pro­wa­dze­nia skom­pli­ko­wa­nych obli­czeń, symu­lu­je ona okre­ślo­ną rze­czy­wi­stość. Np. apli­ka­cja wspie­ra­ją­ca pra­cę biblio­te­ki odwzo­ro­wu­je papie­ro­we kar­to­te­ki i ich treść, a nie raz tak­że reali­zu­je okre­ślo­ne regu­ły biz­ne­so­we regu­lu­ją­ce wypo­ży­cza­niem ksią­żek, wspie­ra­jąc tym samym pra­cę biblio­te­ka­rza. Aplikacja, któ­ra mię­dzy inny­mi wyko­nu­je zło­żo­ne obli­cze­nia, nie raz zawie­ra kom­po­nent będą­cy symu­la­to­rem repre­zen­tu­ją­cym rze­czy­wi­stość będą­cą przed­mio­tem tych obli­czeń, np. obli­cza­ją­cym czas reali­za­cji pro­jek­tu czy koszt pro­ce­su biz­ne­so­we­go. Typowymi symu­la­to­ra­mi są gry kom­pu­te­ro­we czy tre­na­że­ry (symu­la­to­ry kabin samolotów).

Po co to wszystko? 

Figure 1: Computers, Models, and the Embedding World (Smith 1985)

Otóż nie da się czymś tak zło­żo­nym jak opro­gra­mo­wa­nie (zakła­dam, że to nie try­wial­ny sys­tem), zarzą­dzać na pozio­mie deta­licz­nych szcze­gó­łów. Jedynym spo­so­bem jest uprasz­cza­nie i pra­ca z abs­trak­cja­mi. Czym są owe abs­trak­cje? Modele! Już w 1984 roku zauwa­żo­no, że: ?the idea that a phy­si­cal the­ory or world pic­tu­re is a model (gene­ral­ly of a mathe­ma­ti­cal natu­re) and a set of rules that con­nect the ele­ments of the model to obse­rva­tions.” (Stephen Hawking and Leonard Mlodinow, cal­led Model-Dependent Realism)? (za Model-Dependent Realism: Is This the Worldview of Software Engineering? ? THINK IN MODELS). (Źródło: Czynniki suk­ce­su w pro­jek­tach pro­gra­mi­stycz­nych | | Jarosław Żeliński IT-Consulting

Realizacją te idei jest wła­śnie archi­tek­tu­ra MVC i wydzie­lo­ny kom­po­nent, jakim jest Model, któ­re­go rolą jest odwzo­ro­wa­nie okre­ślo­nej rze­czy­wi­sto­ści. Ta okre­ślo­na rze­czy­wi­stość mają­ca swój kon­tekst to dome­na (dzie­dzi­na) sys­te­mu. Model opi­su­ją­cy jej zacho­wa­nie (symu­la­tor) to Model Dziedziny Systemu. Grafika, jaką widzi­my obok powyż­sze­go cyta­tu, odda­je tę ideę. Po pra­wej stro­nie jest kon­kret­na rze­czy­wi­stość (Real World), jej zro­zu­mie­nie (okre­ślo­nej czę­ści) w posta­ci udo­ku­men­to­wa­nej to wła­śnie Model. Implementacja to sys­tem (tu COMPUTER) czy­li apli­ka­cja wraz ze swo­im śro­do­wi­skiem wykonawczym.

Na tle powyż­sze­go war­to zwró­cić uwa­gę na to, że nie­praw­dą jest:

  1. to, że Model to baza danych,
  2. to, że regu­ły biz­ne­so­we są w kom­po­nen­cie Controller.

Ale praw­dą jest, że wyma­ga­niem wobec opro­gra­mo­wa­nia jest to, by zacho­wy­wa­ło się ono w pożą­da­ny spo­sób, i znacz­nie lepiej by wyma­ga­niem był Model (PIM) niż dzie­siąt­ki czy set­ki przy­kła­do­wych zacho­wań systemu.

Model wyra­żo­ny w nota­cji UML to struk­tu­ra opi­sa­na dia­gra­mem klas, z kla­sa­mi obiek­tów mają­cych atry­bu­ty i ope­ra­cje, obiek­ty połą­czo­ne związ­ka­mi uży­cia… Szczegóły inter­fej­su użyt­kow­ni­ka opra­cu­je gra­fik UX-desi­gner, zaś wszel­kie tech­nicz­ne kwe­stie (logo­wa­nie, bez­pie­czeń­stwo, inte­gra­cja itp.) opra­cu­je już developer.

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 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”.

Źródła

Ahmad, S. I., Rana, T., & Maqbool, A. (2021). A Model-Driven Framework for the Development of MVC-Based (Web) Application. Arabian Journal for Science and Engineering. https://​doi​.org/​1​0​.​1​0​0​7​/​s​1​3​3​6​9​-​021 – 06087‑4

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

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