Tym razem o mode­lu, a kon­kret­nie kom­po­nen­cie Model, w archi­tek­tu­rze sys­te­mu. W poprzed­nim arty­ku­le pod koniec napisał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

Podstawowym wzor­cem archi­tek­to­nicz­nym w sys­te­mach o obiek­to­wej archi­tek­tu­rze, jest wzo­rzec MVC (Model, View, Controller). Architektura tego wzor­ca w ogól­nej posta­ci ta ma taką oto postać:

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­tu ​„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 tego kom­po­nen­tu. 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 wszyst­ko? W 2011 roku pisałem:

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 a dane w kom­po­nen­cie Model.

Ale praw­dą jest, że wyma­ga­niem wobec opro­gra­mo­wa­nia powin­no być 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 niż dzie­siąt­ki czy set­ki przy­kła­do­wych zacho­wań systsemu.

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