Dokument a kumulacja faktów: OOAD i model dziedziny systemu

Tym razem o czymś co potra­fi zabić 😉 czy­li czym jest doku­ment oraz fakt i obiekt. Czym się róż­ni zakup kil­ku pro­duk­tów, w tym samym skle­pie, w np. godzin­nych odstę­pach cza­su, od zaku­pu wszyst­kich razem? Poza for­mą udo­ku­men­to­wa­nia, niczym: w skle­pie to samo i tyle samo zeszło ze sta­nu maga­zy­nu, a my wyda­li­śmy w obu przy­pad­kach tyle samo pie­nię­dzy (o pro­mo­cjach póź­niej)! W pierw­szym przy­pad­ku mamy kil­ka fak­tów zaku­pu, w dru­gim, jeden, ale zawsze tyle samo obiek­tów (pro­dukt). Faktura (para­gon) to doku­ment opi­sją­cy fakt, przed­miot sprze­da­ży jest obiek­tem. Tu obiek­tem jest opi­sy­wa­ny przed­miot zaku­pu. Ten arty­kuł to przy­kład archi­tek­tu­ry usłu­gi apli­ka­cji, któ­ra jest nie­czu­ła na takie różnice. 

Wprowadzenie

Żeby upo­rząd­ko­wać treść, w sto­sun­ku to archi­tek­tu­ry apli­ka­cji tu nie będę uży­wał pojęć kla­sa i obiekt” a kom­po­nent i doku­ment. Pojęcia obiekt i fakt tu będą doty­czy­ły świa­ta real­ne­go, to odpo­wied­nio: opi­sy­wa­ny przed­miot i zda­rze­nie z nim powią­za­ne. Innymi sło­wy: doku­ment może opi­sy­wać obiekt lub zda­rze­nie z nim powią­za­ne. Np. pro­dukt oraz fakt jego sprze­da­nia (dwa byty: sepa­ro­wa­nie kon­tek­stu doku­men­tów). Konkretne opro­gra­mo­wa­nie jako sys­tem, to kom­po­nen­ty (w UML obiek­ty okre­ślo­nej kla­sy) oraz dane zor­ga­ni­zo­wa­ne np. jako doku­men­ty (doku­ment: nazwa­na, okre­ślo­na struk­tu­ra danych). Aplikacje prze­twa­rza­ją dane opi­su­ją­ce real­ny świat, co ład­nie poka­zał i opi­sał Smith :

computer model real world
Smith, B. C. (1985). Computers, Models, and the Embedding World, The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18?26. doi: 10.1145/379486.379512

Projektowanie opro­gra­mo­wa­nia to two­rze­nie jego mode­lu, potem pozo­sta­je już tyl­ko jego imple­men­ta­cja. Obecnie pra­ce pro­jek­to­we i przy­go­to­wa­nie do imple­men­ta­cji tak­że są zali­cza­ne do pro­gra­mo­wa­nia” .

Projekt systemu sprzedaży

Każda ana­li­za powin­na być opar­ta na onto­lo­gii z dzie­dzi­ny pro­ble­mu. Dzięki cze­mu nazwy doku­men­tów, atry­bu­tów i ich war­to­ści będą spój­ne, jed­no­znacz­ne i nie­sprzecz­ne. Poniżej pro­sty model poję­cio­wy dla dzie­dzi­ny opi­sy­wa­ne­go tu problemu:

Model poję­cio­wy (dia­gram fak­tów SBVR lub model poję­cio­wy, dia­gram klas UML)

(UWAGA! Powyższy model nie jest żad­nym mode­lem dzie­dzi­ny” ani mode­lem danych”. To model pojęciowy). 

Modele poję­cio­we słu­żą do zarzą­dza­nia sys­te­mem pojęć (onto­lo­gia) dla dane­go mode­lu opro­gra­mo­wa­nia. Testowanie tego mode­lu pole­ga na spraw­dze­niu czy każ­da para połą­czo­nych seman­tycz­nie pojęć two­rzy popraw­ne i praw­dzi­we(!) zda­nie w języ­ku natu­ral­nym (tu musi­my brać popraw­kę na flek­sję języ­ka pol­skie­go), np. «sprze­da­ją­cy wysta­wia fak­tu­rę» (fakt) lub «fak­tu­ra jest doku­men­tem» (typ).

Oprogramowanie słu­ży do prze­twa­rza­nia danych, dla­te­go war­to opi­sać jak się to odby­wa. Bardzo wygod­ną meto­dą pro­jek­to­wa­nia struk­tur danych doku­men­ty (w tym opi­sie dia­gram struk­tur zło­żo­nych nota­cji UML). Po pierw­sze są one zro­zu­mia­łe dla przy­szłe­go użyt­kow­ni­ka, po dru­gie meto­da ta pozwa­la uwol­nić się od wad mode­li rela­cyj­nych: usu­nię­cie redun­dan­cji nazw co pro­wa­dzi do utra­ty ich kon­tek­stu. Dokumenty czę­sto mają róż­ny kon­tekst, zna­cze­nie pojęć zale­ży od kon­tek­stu. Relacyjny model danych, pozba­wio­ny redun­dan­cji, jest strat­ny: utrwa­lo­ne dane nie sta­no­wią żad­nej infor­ma­cji a doku­men­tem jest dopie­ro wynik zapy­ta­nia SQL do tabel. 

W przy­pad­ku opi­sy­wa­ne­go tu pro­jek­tu wyglą­da to tak:

Struktury danych zor­ga­ni­zo­wa­nych w doku­men­ty (nota­cja UML)

Mamy tu dwa doku­men­ty: Oferta i Faktura. Pojęcie Produkt ma swo­ją defi­ni­cję real­na (defi­ni­cja atry­bu­to­wa: poprzez cechy): jest to cos co ma nazwę, cenę i ilość”. Atrybuty Produktu na doku­men­tach przyj­mu­ją war­to­ści opi­sa­ne tym typem. Po dru­gie doku­ment nie­sie kon­tekst więc nada­je nazwie zna­cze­nie: np. data to data fak­tu­ry i data ofer­ty. To nie są te same daty, a pro­dukt ofe­ro­wa­ny (jako atry­but ofer­ty) nie musi być tym samym pro­duk­tem sprze­da­nym (jako atry­but Faktury).

Projekt powyż­szy poka­zu­je tak­że waż­ną rzecz: sepa­ro­wa­nie danych o obiek­tach (pro­duk­ty) i fak­tach (fak­tu­ra). Nie nale­ży na jed­nym doku­men­cie łączyć (mie­szać) kon­tek­stów (uwspól­nia­nie danych w mode­lu rela­cyj­nym). (Więcej na temat sepa­ra­cji kon­tek­stów obiek­tu i fak­tu w publi­ka­cji Chapter 3 Digital Documents as Data Carriers and a Method of Data Management Guaranteeing the Unambiguity of the Recorded Information: Ontology-Oriented Data Management and Document Databases”).

Poniżej, na dia­gra­mie sekwen­cji, widać, że dla kom­po­nen­tu zarzą­dza­ją­ce­go sta­na­mi maga­zy­no­wy­mi nie ma żad­ne­go zna­cze­nia ile jest (było) fak­tur, ope­ra­cje zmia­ny ilo­ści to poje­dyn­cze ope­ra­cje. Tak zapro­jek­to­wa­na apli­ka­cja jest odpor­na na to ile pro­duk­tów jest na ofer­cie i fak­tu­rze, mogą to być róż­ne ilo­ści. Oba te doku­men­ty: ofer­ta i fak­tu­ra, to cał­ko­wi­cie odręb­ne kon­struk­cje, to doku­men­ty rzą­dzą­ce się każ­dy inną logi­ką i mają­ce każ­dy inny cykl życia (tu np. Oferta nie jest utrwa­la­na). Często sto­so­wa­ne kon­struk­cje, takie jak dzie­dzi­cze­nie fak­tu­ry i ofer­ty po doku­men­cie” są tu naj­gor­szym pomysłem. 

Architektura. Nasza apli­ka­cja to kil­ka współ­pra­cu­ją­cych komponentów:

Obiektowy (kom­po­nen­to­wy) model dziedziny. 

Klasy ozna­czo­ne ste­reo­ty­pem «Document» to cią­gi zna­ków (np. XML) sta­no­wią­ce war­to­ści atry­bu­tów i para­me­try wywo­łań ope­ra­cji. (w UML: ?Document? A human-reada­ble file. Subclass of ?File?. )

Model archi­tek­tu­ry to sta­tycz­ny model, a ten może być nie­zro­zu­mia­ły, dla­te­go zawsze wzbo­ga­ca­my pro­jekt tech­nicz­ny archi­tek­tu­ry mode­lem dyna­mi­ki sys­te­mu: dia­gra­mem sekwen­cji. Diagram taki powi­nien powstać dla każ­dej usłu­gi apli­ka­cji (przy­pad­ku użycia):

Scenariusz reali­za­cji sprze­da­ży (dia­gram sekwen­cji UML)

Powyższy dia­gram poka­zu­je współ­pra­cę kom­po­nen­tów, opi­sa­ne wcze­śniej doku­men­ty są war­to­ścia­mi atry­bu­tów i para­me­tra­mi wywo­ły­wa­nych ope­ra­cji i ich odpo­wie­dzi. Powyższa archi­tek­tu­ra z powo­dze­niem wyko­na tak­że usłu­gi wglą­du do histo­rycz­nych fak­tur czy aktu­ali­za­cję cennika. 

Poprawna obiek­to­wa archi­tek­tu­ra i kom­plet­ny pro­jekt tech­nicz­ny apli­ka­cji (model PIM) opi­su­je pre­cy­zyj­nie jak wyko­nać imple­men­ta­cje i nie zawie­ra pro­jek­tu żad­nej bazy danych, ani tym bar­dziej zapy­tań SQL. Implementacja utrwa­la­nia nie może mieć wpły­wu na logi­kę biz­ne­so­wą sys­te­mu ani nawet zawie­rać jej! 

Samo opra­co­wa­nie rela­cyj­ne­go mode­lu danych oraz zapy­tań SQL, by gene­ro­wać powyż­sze doku­men­ty z warian­ta­mi doty­czą­cy­mi róż­nych ilo­ści ofe­ro­wa­nych i zama­wia­nych, zaj­mie kil­ka­krot­nie wię­cej cza­su niż opra­co­wa­nie powyż­sze­go, goto­we­go do imple­men­ta­cji, pro­jek­tu. Opracowanie mode­lu rela­cyj­ne­go bazy danych, wyma­ga­ło by dodat­ko­wo wie­dzy o wszyst­kich pozo­sta­łych doku­men­tach w tym sys­te­mie, a tego z regu­ły nigdy nie wie­my na początku!

Powyższy model to w peł­ni współ­pra­cu­ją­ce obiek­ty mają­ce ope­ra­cje, a pod­sta­wo­wym związ­kiem mode­lu obiek­to­we­go jest zwią­zek uży­cia (wywo­ła­nia ope­ra­cji), czy­li nie jest to tak zwa­ny ane­micz­ny model dzie­dzi­ny.

Tu tak­że war­to zwró­cić uwa­gę na kolej­ny czę­sty błąd i antyw­zo­rzec w pro­jek­tach dekla­ro­wa­nych jako obiek­to­we: sto­so­wa­nie dzie­dzi­cze­nia. Jest to mie­sza­nie mode­li poję­cio­wych i archi­tek­tu­ry (dzie­dzi­cze­nie, jako współ­dzie­le­nie, łamie pod­sta­wo­wą zasa­dę para­dyg­ma­tu obiek­to­we­go jaką jest her­me­ty­za­cja). Dlatego model poję­cio­wy i model archi­tek­tu­ry to z zasa­dy dwa odręb­ne mode­le z powo­dów jak wyżej opisane.

Modelowanie archi­tek­tu­ry systemu 

Podsumowanie

Powyższy opis to krót­ki ale prak­tycz­nie kom­plet­ny Opis Techniczny Oprogramowania. Wymaga nie­wiel­kich uzu­peł­nień (ewen­tu­al­ne sche­ma­ty opi­su­ją­ce meto­dy ope­ra­cji). Wykonanie imple­men­ta­cji na jego pod­sta­wie nie powin­no spra­wić pro­ble­mu oso­bie radzą­cej sobie z czy­ta­niem nota­cji UML. Projekt jest na tyle pre­cy­zyj­ny, że sta­no­wi utwór w rozu­mie­niu pra­wa autor­skie­go (pro­gra­mi­sta nie ma tu żad­nej swo­bo­dy decy­zji w pisa­niu kodu dla tej czę­ści). Projekt taki to tak­że opis okre­ślo­ne­go mecha­ni­zmu dzia­ła­nia, zawie­ra więc opis know-how i jako jego udo­ku­men­to­wa­na for­ma chro­ni to know-how (usta­wa o prze­ciw­dzia­ła­niu nie­uczci­wej konkurencji). 

Dlatego każ­dy pro­gram kom­pu­te­ro­wy napi­sa­ny na pod­sta­wie takiej doku­men­ta­cji, z zasa­dy jest utwo­rem zależ­nym. Developer ma pra­wa autor­skie oso­bi­ste do kodu jaki napi­sze, ale nie ma pra­wa do dys­po­no­wa­nia tym kodem: ma je posia­dacz praw mająt­ko­wych do pro­jek­tu, któ­ry jest tu utwo­rem pier­wot­nym. Jedyny wybór jaki ma tu deve­lo­per to wybór tech­no­lo­gii jakiej użyje.

https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​e​m​e​r​g​i​n​g​-​c​h​a​l​l​e​n​g​e​s​-​s​o​l​u​t​i​o​n​s​-​b​e​s​t​-​p​r​a​c​t​i​c​e​s​/​2​7​1​7​3​3​#​t​a​b​l​e​-​o​f​-​c​o​n​t​e​nts

Powyższy pro­jekt wyko­na­no z uży­ciem Visual Paradigm.

Źródła

OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
Weilkiens, T. (2007). Systems engi­ne­ering with SysML/UML: mode­ling, ana­ly­sis, design (1. Aufl). Morgan Kaufmann OMG Press/Elsevier.
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
Smith, B. C. (1985). The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18 – 26. https://​doi​.org/​1​0​.​1​1​4​5​/​3​7​9​4​8​6​.​3​7​9​512

MVC – komponent Model w architekturze systemu

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:

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

Model dziedziny jako mechanizm

W 2013 roku, arty­kuł o tym czym jest model dzie­dzi­ny, zakoń­czy­łem słowami:

Metody obiek­to­we pole­ga­ją na mode­lo­wa­nia świa­ta rze­czy­wi­ste­go (dome­ny sys­te­mu), w efek­cie nie tra­ci­my żad­nej wie­dzy mode­lu­jąc (zapi­su­jąc) ?świat? w posta­ci mode­lu dzie­dzi­ny. Tu war­to zwró­cić uwa­gę, że wie­dzę o tym jak wyglą­da fak­tu­ra jako doku­ment, musi jakiś obiekt posia­dać: to obiekt fak­tu­ra, posia­da­ją­cy np. ope­ra­cję (meto­dę) ?dru­kuj?. Ale to temat na inny wpis :). (Źródło: Czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny sys­te­mu | | Jarosław Żeliński IT-Consulting).

Mamy rok 2017, więc czte­ry lata czekało 😉 … 

Czytaj dalej… Model dzie­dzi­ny jako mecha­nizm”

TDD – czy same testy to wymagania?

Na nie­daw­no zakoń­czo­nej kon­fe­ren­cji beIT orga­ni­zo­wa­nej na Politechnice Gdańskiej przez Wydział Elektrotechniki, Telekomunikacji i Informatyki, wygło­si­łem refe­rat zaty­tu­ło­wa­ny Filozofia czy­li Aplikacja jako ele­ment biz­ne­so­wej rze­czy­wi­sto­ści (a nie gra kom­pu­te­ro­wa). Przesłanie tej pre­zen­ta­cji to:

Oprogramowanie bar­dzo czę­sto zastę­pu­je kon­struk­cje rze­czy­wi­ste takie jak zega­rek, kar­to­te­ka, biblio­te­ka, księ­gi han­dlo­we, pro­gra­ma­tor pral­ki i wie­le innych rze­czy. Dlatego ana­li­za powin­na pole­gać na zro­zu­mie­niu i udo­ku­men­to­wa­niu mecha­ni­zmu dzia­ła­nia tego cze­goś” a nie jedy­nie na spi­sa­niu zewnętrz­nych oznak tego dzia­ła­nia i zarzą­dza­nie tym spisem. 

Referat miał lek­kie pod­ło­że filozoficzne :).

Ten arty­kuł nie będzie jed­nak powtó­rze­niem refe­ra­tu (wyżej link do pobra­nia). Do jego napi­sa­nia skło­ni­ło mnie jed­no z pytań z sali:

Stosujemy TDD, czy to nie wystar­czy? Po co więc robić to o czym Pan mówi?”

Otóż odpo­wiedź brzmia­ła: TDD nie zastę­pu­je opi­su mecha­ni­zmu dzia­ła­nia. Innymi sło­wy: sam zestaw testów bar­dzo czę­sto nie sta­no­wi żad­nej infor­ma­cji o tym co ma powstać.

Niedawno pisa­łem:

Mechanizm jed­nak to nie zawsze tyl­ko same regu­ły, bar­dzo czę­sto (prak­tycz­nie zawsze dla nie­try­wial­nych sys­te­mów) powi­nien powstać dia­gram poka­zu­ją­cy wewnętrz­ną budo­wę (archi­tek­tu­rę) sys­te­mu, zestaw kom­po­nen­tów odpo­wie­dzial­nych za logi­kę reali­zo­wa­nia tych reguł (a jed­ną z nich jest np. ?treść doku­men­tów musi być zapa­mię­ty­wa­na z moż­li­wo­ścią przy­wo­ła­nia jej w dowol­nym momen­cie?). Taki dia­gram nazy­wa się Model dzie­dzi­ny. Jak go two­rzyć pisa­łem nap. w arty­ku­le Model dzie­dzi­ny jako wyma­ga­nie. (Źródło: Model To Mechanizm | | Jarosław Żeliński IT-Consulting)

A teraz jako przy­kład przy­to­czę dość zło­żo­ny kom­po­nent wie­lu sys­te­mów (pogru­bie­nie moje):

Jak dzia­ła sco­ring w Banku. Klient zain­te­re­so­wa­ny uzy­ska­niem kre­dy­tu wypeł­nia wnio­sek kre­dy­to­wy dla wybra­ne­go pro­duk­tu kre­dy­to­we­go. Dane z wnio­sku reje­stro­wa­ne są w sys­te­mie infor­ma­tycz­nym, któ­ry wspo­ma­ga pro­ces obsłu­gi wnio­sków kre­dy­to­wych w Banku. Podczas prze­twa­rza­nia wnio­sku nastę­pu­je wery­fi­ka­cja danych oraz zapy­ta­nie o auto­ma­tycz­ną reko­men­da­cję kre­dy­to­wą kie­ro­wa­ną do sil­ni­ka decy­zyj­ne­go. Silnik decy­zyj­ny wyko­nu­je zde­fi­nio­wa­ny w posta­ci reguł prze­twa­rza­nia algo­rytm sco­rin­go­wy: gro­ma­dzi dodat­ko­we infor­ma­cje z dostęp­nych źró­deł (np. Biuro Informacji Kredytowej SA, bazy nie­so­lid­nych klien­tów oraz dowo­dów zastrze­żo­nych ? MIG BR, MIG DZ), wyzna­cza wskaź­ni­ki, okre­śla przy­dział do klas ryzy­ka oraz wyli­cza oce­nę punk­to­wą w opar­ciu o kar­ty sco­rin­go­we. (Źródło: Scoring – meto­da oce­ny wia­ry­god­no­ści kre­dy­to­wej – ERP​-view​.pl – ERP, CRM, MRP, Business Intelligence, MRP)

Odpowiadając na pyta­nie o TDD powiem tak: nie da się jed­no­znacz­nie zamó­wić” Systemu sco­rin­go­we­go, poda­jąc jedy­nie par­tię danych wej­ścio­wych i spo­dzie­wa­nych danych wyj­ścio­wych. Testy moż­na opra­co­wać zna­jąc mecha­nizm dzia­ła­nia tego sys­te­mu, two­rzy­my wte­dy repre­zen­ta­tyw­ny zestaw testów pokry­wa­ją­cy cały kod”, o ile zna­my struk­tu­rę tego kodu (pro­jekt). Sam kod nie musi ist­nieć w momen­cie pro­jek­to­wa­nia tych testów, ale opra­co­wa­ny mecha­nizm tak, bo jak już pisa­łem model dzie­dzi­ny to struk­tu­ra kodu reali­zu­ją­ce­go logi­kę biz­ne­so­wą wraz z metodami”.

Można tu powie­dzieć, że nie każ­dy sys­tem to zło­żo­ność sys­te­mu sco­rin­go­we­go. To praw­da, ale to co nazy­wa­my biz­ne­sem to regu­ły biz­ne­so­we, mecha­nizm dzia­ła­nia orga­ni­za­cji, a ten nigdy nie jest try­wial­ny. Reguły udzie­la­nia upu­stów, regu­ły przy­dzie­la­nia kre­dy­tów kupiec­kich, regu­ły nagra­dza­nia w sys­te­mach lojal­no­ścio­wych, regu­ły roz­li­cza­nia kosz­tów i wie­le, wie­le innych w pra­wie każ­dej fir­mie, orga­ni­za­cji czy insty­tu­cji publicznej.

Prawdopodobieństwo tego, że powsta­nie popraw­ne” opro­gra­mo­wa­nie tyl­ko na pod­sta­wie zapi­su sze­re­gu zewnętrz­nych obser­wa­cji” (bo czym są wyma­ga­nia jako zapis burz mózgów, ankiet, wywia­dów, itp.?) jest tym bar­dziej bli­skie zeru im bar­dziej orga­ni­za­cja ma zło­żo­ny mecha­nizm dzia­ła­nia (czy­li większość).

Zjawisko to jest zna­ne już od dzie­siąt­ków lat:

Problemy, w któ­rych roz­wią­za­niu mają pomóc budo­wa­ne zło­żo­ne sys­te­my są zwy­kle ?pro­ble­ma­mi zło­śli­wy­mi? (Rittel i Webber, 1973). ?Problem zło­śli­wy? to taki skom­pli­ko­wa­ny pro­blem, w któ­rym jest tak wie­le powią­za­nych ze sobą bytów, że nie ist­nie­je jego osta­tecz­na spe­cy­fi­ka­cja. Prawdziwy cha­rak­ter pro­ble­mu obja­wia się dopie­ro w mia­rę opra­co­wy­wa­nia rozwiązania.

Dlatego roz­wią­za­nie nie­try­wial­ne­go pro­ble­mu nie pole­ga na spe­cy­fi­ko­wa­niu tego co zna­my, a na pod­ję­ciu pró­by zapro­jek­to­wa­nia roz­wią­za­nia. Tym pro­jek­tem nie jest jed­nak opis reak­cji syst­se­mu na bodź­ce” (czar­na skrzyn­ka). Projektem jest opi­sa­ny (jed­no­znacz­nie udo­ku­men­to­wa­ny) mecha­nizm dzia­ła­nia roz­wią­za­nia (bia­ła skrzynka).

Dlatego wyma­ga­nia spe­cy­fi­ku­je­my sku­tecz­nie poprzez pro­jekt pro­duk­tu a nie poprzez listę cech pro­duk­tu. Zamówienie dla deve­lo­pe­ra powin­no zawie­rać pro­jekt a nie wizu­ali­za­cję efek­tu koń­co­we­go, dokład­nie tak jak w bran­ży budow­la­nej, elek­tro­nicz­nej czy nawet mecha­nicz­nej (nawet wyko­naw­ca wału kor­bo­we­go dosta­je rysun­ki tech­nicz­ne a nie roz­wle­kłą proś­bę o faj­ny wał do samochodu).

Zilustrować to moż­na tak:

Wymagania

  1. Wymagania biz­ne­so­we zgła­sza biz­nes, są one for­mą opi­su i kon­se­kwen­cją pro­ble­mu biz­ne­so­we­go, wyma­ga­nia wobec roz­wią­za­nia to usta­lo­ny zakres projektu.
  2. Jeżeli jest to pro­jekt z obsza­ru inży­nie­rii opro­gra­mo­wa­nia, ma powstać opro­gra­mo­wa­nie opi­sa­ne z uży­ciem Przypadków uży­cia i Modelu dziedziny.
  3. Jak przejść od wyma­gań biz­ne­so­wych do Przypadków uży­cia i mode­lu dzie­dzi­ny i kto ma tego dokonać?

Kto ma opra­co­wać to ostat­nie? Programista? A na jakiej pod­sta­wie, sko­ro nie zna tego biz­ne­su” (to pro­gra­mi­sta a nie ana­li­tyk biz­ne­so­wy)? Czy same przy­pad­ki uży­cia opi­su­ją regu­ły (mecha­nizm dzia­ła­nia) dzia­ła­nia syst­se­mu sco­rin­go­we­go czy sys­te­mu upu­stów w pro­mo­cji (to jed­na licz­ba, war­tość upu­stu, na fak­tu­rze)? Nie. Czy da się na bazie par­tii testów (czy­li skoń­czo­nej, ale z regu­ły nie­zu­peł­nej liście bodziec-odpo­wiedź) stwo­rzyć cokol­wiek? Mało kie­dy. Oznacza to, że wyma­ga­nia zebra­ne tyl­ko jako przy­pad­ki uży­cia mało kie­dy” dają szan­sę na powsta­nie opro­gra­mo­wa­nia za pierw­szym razem”, tu pro­to­ty­pów nie jest nigdy prze­wi­dy­wal­na. To dla­te­go meto­dy zwa­ne zwin­ny­mi, bazu­ją­ce wyłącz­nie na user sto­ry i pro­to­ty­pach, nada­ją się do pro­ble­mów pro­stych. Kompletnie nie spraw­dza­ją się w przy­pad­kach zło­żo­nych sys­te­mów, rozu­mia­nych jako zło­żo­ne mecha­ni­zmy. Te ostat­nie trze­ba nie raz od zera” odkryć i opisać.

Paradygmat i metody obiektowe

Kluczem metod obiek­to­wych (i para­dyg­ma­tu obiek­to­we­go) jest her­me­ty­za­cja. Oznacza to, że zło­żo­ność obiek­tu z zewnątrz” nie jest zna­na nigdy, nie ma zna­cze­nia wiel­kość obiek­tu (mała kla­sa czy mega-kom­po­nent), na zewnątrz postrze­ga­ny jest wyłącz­nie jako inter­fejs. Rozważania na począt­ku poka­za­ły, że odpo­wie­dzi na bodź­ce to ocze­ki­wa­ne (wyma­ga­ne) cechy roz­wią­za­nia, któ­re jed­nak nie deter­mi­nu­ją jego mechanizmu.

Oprogramowanie poma­ga­ją­ce w nauce tablicz­ki mno­że­nia do 100, może zawie­rać sta­tycz­ną tabli­cę zna­ną z ostat­nich stron sta­rych zeszy­tów, a może to być mecha­nizm będą­cy imple­men­ta­cją algo­ryt­mu mno­że­nia. Po pierw­sze zestaw testów, jak widać, nie deter­mi­nu­je żad­nej z tych metod imple­men­ta­cji. Po dru­gie spe­cy­fi­ka­cja w pierw­szym wypad­ku będzie duża” (kosz­tow­na), w dru­gim bar­dzo pro­sta. Po trze­cie roz­wi­ja­nie (tablicz­ka mno­że­nia do 1000) opro­gra­mo­wa­nia w wer­sji z tabli­cą sta­tycz­ną będzie znacz­nie droż­sze niż pier­wot­ne wytwo­rze­nie wer­sji z mno­że­niem do 100. W dru­gim przy­pad­ku będzie pole­ga­ło wyłącz­nie na zdję­ciu blo­ka­dy mno­że­nia liczb więk­szych niż 10.

Tak więc co z tym TDD? Popatrzmy na to jak jest definiowane:

Co to jest Test Driven Development

Test Driven Development, czy­li TDD, to tech­ni­ka two­rze­nia opro­gra­mo­wa­nia ste­ro­wa­na przez testy. Tworzenie kodu skła­da się z wie­lo­krot­nie wyko­ny­wa­nych trzech głów­nych kroków:

  1. Stworzenie testu jed­nost­ko­we­go, któ­ry powi­nien być moż­li­wie naj­prost­szy, aby unik­nąć moż­li­wo­ści popeł­nie­nia błę­du w samym teście. Test ma spraw­dzać funk­cjo­nal­ność, któ­ra będzie imple­men­to­wa­na w kro­ku 2.
  2. Implementacja funk­cjo­nal­no­ści ? two­rzy­my funk­cjo­nal­ność, któ­rą chce­my zaim­ple­men­to­wać. Funkcjonalność ta powin­na speł­niać zało­że­nia testu jed­nost­ko­we­go, a wyko­na­nie testu jed­nost­ko­we­go powin­no koń­czyć się sukcesem.
  3. Refaktoryzacja, czy­li porząd­ki w stwo­rzo­nej funk­cjo­nal­no­ści. Ma to na celu upo­rząd­ko­wa­nie kodu, tak aby speł­nio­ne były stan­dar­dy. Czynności wyko­ny­wa­ne w tym kro­ku nie mogą zmie­nić wyni­ku testów.

Źródło: Test Driven Development

Pod poję­ciem funk­cjo­nal­ność tu rozu­mia­ny jest ocze­ki­wa­ny efekt”, bo test nie jest niczym innym. Czy testy to są (zastę­pu­ją) pro­jekt wewnętrz­nej logi­ki? W przy­pad­kach try­wial­nych pew­nie tak, tam gdzie logi­ka jest pro­sta lub nie wystę­pu­je (przy­pad­ki uży­cia typu CRUD), albo tam gdzie logi­ka” jest powszech­nie zna­na” zna ją tak­że pro­gra­mi­sta (np. spo­sób dzia­ła­nia zegara).

Jednak sys­tem o nie­try­wial­nej logi­ce dzia­ła­nia, nie da się wyspe­cy­fi­ko­wać w posta­ci skoń­czo­nej (lub roz­sąd­nie krót­kiej) listy bodziec-efekt (np. przy­kła­do­wych par­tii gry w sza­chy). W jed­nej ze swo­ich ksią­żek Martin Fowler napi­sał, że żad­na ilość godzin fil­mu znad sto­łu bilar­do­we­go, jako wyma­ga­nie, nie da w efek­cie nawet namiast­ki dobrej gry w bilar­da. Ale sche­mat sto­łu, wymia­ry kul, kija oraz pra­wa fizy­ki rzą­dzą­ce ruchem kul, pozwo­lą na napi­sa­nie wręcz dosko­na­łej symu­la­cyj­nej gry. Taki opis to wła­śnie model dzie­dzi­ny gry w sza­chy, dokład­ny opis mecha­ni­zmu tego co dzie­je się na sto­le bilardowym.

Ostatnie pyta­nie brzmia­ło: Jak przejść od wyma­gań biz­ne­so­wych do Przypadków uży­cia i mode­lu dzie­dzi­ny i kto ma tego dokonać?

Odpowiedź na to pyta­nie zawie­ra pewien arty­kuł, napi­sa­ny w 2014 roku na nie­co inny temat:

…rolą ana­li­ty­ka biz­ne­so­we­go nie jest spi­sa­nie prze­bie­gu dzie­sią­tek wywia­dów i setek indy­wi­du­al­nych wyma­gań. Nie mają więk­sze­go sen­su doku­men­ty na dwa, trzy tysią­ce stron (nikt ich nie czy­ta!). Rolą ana­li­ty­ka biz­ne­so­we­go jest prze­ana­li­zo­wa­nie dostęp­nych doku­men­tów, infor­ma­cji, i stwo­rze­nie opi­su mecha­ni­zmu dzia­ła­nia orga­ni­za­cji oraz opi­su roz­wią­za­nia, narzę­dzia mogą­ce­go uspraw­nić dzia­ła­nie orga­ni­za­cji. Opisu zawie­ra­ją­ce­go regu­ły biz­ne­so­we, prze­twa­rza­ne infor­ma­cje (wzo­ry doku­men­tów) oraz listą usług jakie ma świad­czyć pla­no­wa­na do wdro­że­nia apli­ka­cja wraz z opi­sem tego, jak te usłu­gi mają być reali­zo­wa­ne (umie­jęt­no­ści, któ­re moż­na zauto­ma­ty­zo­wać). Sens mają więc zwię­złe opi­sy i mode­le mecha­ni­zmów dzia­ła­nia orga­ni­za­cji oraz opi­sy tego jakie infor­ma­cje i jak mają być prze­twa­rza­ne z uwzględ­nie­niem tego, że część tych prac nadal będą wyko­ny­wa­li ludzie. Takie jak regu­ły gry w sza­chy: waż­ne są dwie stro­ny opi­su reguł gry a nie set­ki stron opi­sów przy­kła­do­wych par­tii. (Źródło: Warsztaty Analityczne ? Czyli Malowanie Trawy | | Jarosław Żeliński IT-Consulting)

Tak więc robi­my to tak, jak w innych dzie­dzi­nach inży­nie­rii: ana­li­zu­je­my, pro­jek­tu­je­my i zle­ca­my wyko­na­nie (imple­men­ta­cję).

Na zakończenie

Kim jest, człon­kiem któ­re­go zespo­łu jest (powi­nien być) pro­jek­tant? Przewrotnie odpo­wiem, że prak­ty­ka poka­zu­je, że – z powo­du ryzy­ka pro­jek­to­we­go – wyko­naw­ca nie powi­nien sam sobie sta­wiać wyma­gań. To dla­te­go zło­żo­ne i ryzy­kow­ne pro­jek­ty mają wydzie­lo­ną rolę ana­li­ty­ka pro­jek­tan­ta, nie jest to czło­nek zespo­łu biz­ne­su ani deve­lo­pe­ra bo obie te stro­ny mają sprzecz­ne inte­re­sy (zakres i koszt). W bran­ży budow­la­nej jest to Biuro Projektowe (tu archi­tekt), trze­ci nie­za­leż­na rola, poza inwe­sto­rem i wyko­naw­cą (z uwa­gi na ryzy­ko, pra­wo budow­la­ne zabra­nia łącze­nia jakiej­kol­wiek z tych trzech ról). W meto­dy­kach takich jak SCRUM, jest to Product Owner, i z powyż­sze­go powo­du nie jest dobrze gdy jest to czło­wiek developera”.

Demo System Szachownica

Z uwa­gi na zain­te­re­so­wa­nie moim pro­jek­tem demo” stwo­rzy­łem tę stro­nę. Tu będą się poja­wia­ły infor­ma­cje o kolej­nych eta­pach two­rze­nia tego doku­men­tu. Powiadomienia o postę­pach będą wysy­ła­ne mailem do subskrybentów.

Projekt Szachy ma na celu poka­za­nie na pro­stym przy­kła­dzie, toku ana­li­zy i pro­duk­tów jakie two­rzę w roli ana­li­ty­ka i pro­jek­tan­ta. Dokument ten może zawie­rać pew­ne bra­ki (brak pew­nych szcze­gó­łów) gdyż celem tego doku­men­tu jest zade­mon­stro­wa­nie zawar­to­ści tego rodza­ju doku­men­ta­cji a nie szcze­gó­ło­we opra­co­wa­nie real­ne­go pro­jek­tu, będzie to jed­nak zazna­czo­ne w treści.

Kliknij i pobierz aktu­al­ny plik projektu

Wszelkie pyta­nia i suge­stie na temat tre­ści pro­jek­tu pro­szę zgła­szać poni­żej, będę na nie sys­te­ma­tycz­nie odpowiadał.

Dane są nieważne bo liczy się przede wszystkim mechanizm działania

Tym prze­wrot­nym tytu­łem chcę dziś zwró­cić uwa­gę na dwa waż­ne i bar­dzo pomoc­ne wzor­ce ana­li­tycz­ne (sło­wo ana­li­tycz­ne ode mnie, w książ­kach na temat wzor­ców bar­dzo rzad­ko uży­wa­na jest nazwa wzor­ce ana­li­tycz­ne”) opi­sa­ne w książ­ce M.Fowlera. Wzorcami ana­li­tycz­ny­mi nazy­wam te wzor­ce pro­jek­to­we, któ­re poma­ga­ją w ana­li­zie i pro­jek­to­wa­niu mode­lu dzie­dzi­ny sys­te­mu (biz­ne­so­wy model obiektowy).

MFowlerWzorceProjektowePolecam oczy­wi­ście lek­tu­rę całej książ­ki Martina Fowlera Architektura Systemów Zarządzania Przedsiębiorstwem Wzorce Projektowe.[1] Opisuje on w niej wła­snie wzor­ce pro­jek­to­we bar­dzo przy­dat­ne już na eta­pie pro­jek­to­wa­nia. Fowler nie uży­wa poję­cia wzor­ca ana­li­tycz­ne­go” ale książ­ka jest podzie­lo­na na obsza­ry zasto­so­wa­nia wzor­ców, wśród nich znaj­dzie­cie więc wzor­ce logi­ki dzie­dzi­ny, wzor­ce pre­zen­ta­cji inter­ne­to­wych czy omó­wio­ne tu wzor­ce dys­try­bu­cji a tak­że bar­dzo przy­dat­ne wzor­ce okre­ślo­ne jako pod­sta­wo­we”.

Poza wzor­ca­mi typo­wy­mi dla sys­te­mów obiek­to­wych w ogó­le, war­to zwró­cić uwa­gę na dwa. Opiszę krót­ko dwa bar­dzo przy­dat­ne na eta­pie ana­li­zy wzor­ce pro­jek­to­we (odno­śni­ki do stro­ny M.Fowlera): Transfer Object oraz Value Object.

Przykład użycia Value Object i Transfer Object

Na eta­pie ana­li­zy pro­ble­mu (ana­li­zy i mode­lo­wa­niu dzie­dzi­ny sys­te­mu) powin­no nas inte­re­so­wać przede wszyst­kim co i po co się dzie­je. Wielu ana­li­ty­ków o rodo­wo­dzie pro­gra­mi­stycz­nym zaczy­na pra­cę od pytań w rodza­ju ile nazwi­sko ma zna­ków, czy mogą to być tyl­ko lite­ry czy coś jesz­cze”, itd. Jest to moim zda­niem kom­plet­ne nie­po­ro­zu­mie­nie. Zabieranie się za opra­co­wa­nie mode­lu od tej stro­ny (mode­lo­wa­nie danych) cał­ko­wi­cie przy­ćmi roz­wią­zy­wa­ny pro­blem. Np. sta­ra­jąc się zro­zu­mieć sys­tem sprze­da­ży bile­tów na samo­lot istot­ne jest na począt­ku nie to, ile zna­ków może mieć nazwi­sko a to, że bar­dzo istot­na jest iden­ty­fi­ka­cja pasa­że­rów i miejsc jakie mają zająć w samo­lo­cie. To nie jest to samo, bo iden­ty­fi­ka­cja pasa­że­rów ma za cel kon­tro­lę, kogo wpusz­cza­my na pokład samo­lo­tu, a nazwi­sko to jed­na z cech pasa­że­ra i na eta­pie ana­li­zy nie nale­ży zakła­dać, że to jedy­ny i naj­lep­szy spo­sób na to roz­róż­nie­nie. Brzmi jak here­zja? Zapewne, bo więk­szość” ana­li­ty­ków zaczy­na wła­śnie od bada­nia np. nazwiska.

A kie­dy zając się nazwi­skiem? Dopiero wte­dy gdy zro­zu­mie­my pro­blem i opra­cu­je­my sys­te­mo­we jego roz­wią­za­nie. Po pierw­sze dla­te­go, że na począt­ku nie mamy wie­dzy (za wcze­śnie na taką decy­zję) by usta­lić na jakich kon­kret­nie danych będzie opie­ra­ła się iden­ty­fi­ka­cja pasa­że­rów (a nuż poja­wi się [[bio­me­tria]]), po dru­gie nie­po­trzeb­nie skom­pli­ku­je­my doku­men­ta­cję zamu­la­jąc ją od same­go począt­ku dużą ilo­ścią zbęd­nych atry­bu­tów”.

Druga istot­na rzecz, to komu­ni­ka­cja. Wiemy, że fir­ma sprze­da­ją­ca bile­ty lot­ni­cze ope­ru­je róż­ny­mi dany­mi (lokal­ny model biz­ne­so­wy tej fir­my) na temat rezer­wo­wa­nych bile­tów. Wiemy, że te dane – o sprze­da­nych bile­tach – muszą być prze­ka­za­ne linii lot­ni­czej, ta zaś wcze­śniej musi jakoś prze­ka­zać infor­ma­cje o tym, na jakie loty i jakie bile­ty oferuje.

Co cie­ka­we, dosko­na­le to pasu­je to opi­sów wyko­ny­wa­nych przez zama­wia­ją­ce­go (albo jak kto woli user sto­ry). Normalny czło­wiek raczej powie nam, że zapi­su­je dane pasa­że­ra”, ale raczej nie powie nam, że reje­stru­je 25 zna­ków nazwi­ska, 20 zna­ków imie­nia i cza­sem 20 zna­ków dru­gie­go imie­nia.….”. Ten sam czło­wiek powie następ­nie, że prze­ka­zu­je dane o sprze­da­nych bile­tach do odpo­wied­nich linii lot­ni­czych a nie, że doko­nu­je trans­fe­ru kolek­cji danych zawierających.….”.

Analiza i projektowanie

Na bazie wywia­dów, doku­men­tów itp. sta­ra­my się zro­zu­mieć co jest gra­ne”, jak ten sys­tem funk­cjo­nu­je. Powstaje np. taki dia­gram. Tu zakła­dam już, że mode­lu­je­my sys­tem sprze­da­ży bile­tów, ale sys­tem ozna­cza wszyst­ko to, co bie­rze w tym udział” a nie kon­kret­ne oprogramowanie”:

Transfer biletów do linii lotniczej

Mamy model cze­goś co ma się wyda­rzyć. Na tym eta­pie kom­plet­nie nie ma sen­su zaj­mo­wa­nie się tym ile zna­ków ma nazwi­sko. To może się zmie­nić w toku ana­li­zy a nawet imple­men­ta­cji, ale nie powin­na ulec zmia­nie logi­ka tej operacji.

Jak już opa­nu­je­my logi­kę (zro­zu­mie­my co i jak ma dzia­łać i zapro­jek­tu­je­my jak to zre­ali­zo­wać) zabie­ra­my się za szcze­gó­ły. Model dzie­dzi­ny (frag­ment):

Model dziedziny

Jak widać, np. danePasażera jako zawar­tość to daneOsoby a nie pola i typy danych”. Czym są DaneOsoby znaj­dzie­my tu:

ValueObject

Zamiast pro­stych typów danych (np. zna­ko­we) sto­su­je­my obiekt jako typ danych. To zna­ko­mi­cie uła­twia póź­niej­sze roz­sze­rze­nia i zmia­ny (nie musi­my nic zmie­niać w mode­lu dzie­dzi­ny by np. dodać dru­gie imię do danych oso­by, mody­fi­ku­je­my w jed­nym miej­scu jedy­nie dekla­ra­cję kla­sy DaneOsoby).

Wywołanie ope­ra­cji podajDaneBiletu zwra­ca obiekt DaneBiletuLitniczego (lub agre­gat zawie­ra­ją­cy wszyst­kie bilety):

Transfer ObjectNie jest to ten sam obiekt co wcze­śniej, ValueObject to typ danych, Transfer Object to seria­li­za­cja, któ­rej celem jest jedy­nie prze­nie­sie­nie w moż­li­wie naj­prost­szy do odczy­ta­nia spo­sób okre­ślo­nych infor­ma­cji (oba te obiek­ty nie mają jed­nak toż­sa­mo­ści). Nie nale­ży tych wzor­ców mylić ani utoż­sa­miać, gdyż Value Object to typ danych” zaś Transfer Object to jedy­nie para­metr wywo­łań, Value Object powi­nien mieć ope­ra­cje sparw­dza­ja­ce jego popraw­ność (wali­da­cja), Transfer Object słu­ży wyłącz­nie do prze­ka­zy­wa­nia infor­ma­cji jako para­metr wywo­łań i odpo­wie­dzi (w pew­nym sen­sie defi­niu­je pro­to­kół wymia­ny danych).

Korzyści ze sto­so­wa­nia tych wzor­ców to mię­dzy innymi:

  1. szcze­gó­ły danych odkła­da­my na koniec pro­jek­tu co jest bez­piecz­ne (nie musi­my mody­fi­ko­wać pro­jek­tu w mia­rę postę­pu pozy­ski­wa­nia wie­dzy o szczegółach),
  2. zmia­na tych szcze­gó­łów nie spo­wo­du­je potrze­by zmia­ny szkie­le­tu mode­lu dziedziny,
  3. może­my pro­wa­dzić spo­koj­ną upo­rząd­ko­wa­ną ana­li­zę top-down” (od ogó­łu do szczegółu),
  4. może­my się umó­wić z deve­lo­pe­rem, że jako ana­li­ty­cy nie będzie­my wni­ka­li w szcze­gó­ły danych, nadal może­my ope­ro­wać kla­sa­mi ValueObject i TransferObject (kla­sy te będą w począt­ko­wej fazie pro­jek­tu bez atrybutów),
  5. mimo to może­my umie­ścić w kla­sach ValueObject warun­ki wali­da­cji (ope­ra­cje klas, któ­rych tu nie poka­zy­wa­łem) i do tego one mię­dzy inny­mi słu­żą (to się nazy­wa okre­śla­nie wyma­gań poprzez testy czy­li TDD),
  6. już na samym począt­ku może­my uzgod­nić postać danych wymie­nia­nych na inter­fej­sach (np. zdal­na komu­ni­ka­cja) i korzy­stać z tej umowy.

Tak zapro­jek­to­wa­ny sys­tem speł­nia tak­że jed­ną z klu­czo­wych zasad pro­jek­to­wa­nia obiek­to­we­go: sys­tem jest zamknię­ty na zmia­ny i otwar­ty na rozszerzenia”.

Na zakończenie

Często sły­szę, że to trud­ne i pra­co­chłon­ne (dodat­ko­we kla­sy w mode­lu), nie­ste­ty zbyt pro­sty pro­jekt potra­fi być kosz­tow­niej­szy w roz­bu­do­wie w porów­na­niu z pier­wot­nym wytwo­rze­niem, dla­te­go jak klient w ramach wyma­gań wpi­su­je (a wpi­su­je coraz czę­ściej): sys­tem ma umoż­li­wiać łatwe roz­sze­rze­nia funk­cjo­nal­no­ści, to nale­ży go tak pro­jek­to­wać, w prze­ciw­nym wypad­ku wyma­ga­nie to nie jest spełnione…

Druga uwa­ga: czę­sto sami klien­ci zabi­ja­ją swo­je pro­jek­ty żąda­jąc na samym począt­ku udo­ku­men­to­wa­nia wszyst­kich szcze­gó­łów jakie im do gło­wy przyj­dą nie potra­fiąc jed­no­cze­śnie opi­sać mecha­ni­zmu dzia­ła­nia ich orga­ni­za­cji (lub nowe­go pomy­słu). To nie­ste­ty czę­sto spo­ty­ka­ne zja­wi­sko, z któ­rym moim zda­niem nale­ży wal­czyć. Paradoksalnie zło­żo­ność sys­te­mów biz­ne­so­wych tkwi w mecha­ni­zmie ich funk­cjo­no­wa­nia a nie w danych, któ­re zbie­ra­ją (któ­rych nie raz jest po pro­stu za dużo…).

Dane to fak­ty jakie chce­my znać, te fak­ty są kon­se­kwen­cją dzia­ła­nia a nie odwrotnie. 

Na ryn­ku w Polsce są jesz­cze mię­dzy inny­mi książ­ki o wzorcach:

Moim zda­niem jed­nak nie przy­dat­ne ana­li­ty­kom. Pierwsza to wzor­ce tech­nicz­ne”, sto­so­wa­ne głów­nie z kom­po­nen­tach Controller i View (archi­tek­tu­ra MVC). Druga to w zasa­dzie doku­men­ta­cja [[J2EE]]. Tak więc obie raczej dla pro­gra­mi­stów i archi­tek­tów. Książkę Fowlera pole­cam ana­li­ty­kom i archi­tek­tom tak­że. Wszystkim pole­cam tak­że UML i Wzorce pro­jek­to­we Larmana.

(UWAGA! Pokazano pro­jekt poglą­do­wy, wyssa­ny z pal­ca, nie ujaw­ni­łem tre­ści żad­ne­go z moich real­nych projektów).

Footnotes
[1]M. Fowler, Architektura sys­te­mów zarzą­dza­nia przed­się­bior­stwem. Wzorce pro­jek­to­we [na:] ?helion​.pl?, http://​helion​.pl/​k​s​i​a​z​k​i​/​a​r​c​h​i​t​e​k​t​u​r​a​-​s​y​s​t​e​m​o​w​-​z​a​r​z​a​d​z​a​n​i​a​-​p​r​z​e​d​s​i​e​b​i​o​r​s​t​w​e​m​-​w​z​o​r​c​e​-​p​r​o​j​e​k​t​o​w​e​-​m​a​r​t​i​n​-​f​o​w​l​e​r​,​s​z​a​b​k​o​.​htm, udo­stęp­nio­no 16 lipiec 2017.
[2]H. SA, J2EE. Wzorce pro­jek­to­we. Wydanie 2 [na:] ?helion​.pl?, http://​helion​.pl/​k​s​i​a​z​k​i​/​j​2​e​e​-​w​z​o​r​c​e​-​p​r​o​j​e​k​t​o​w​e​-​w​y​d​a​n​i​e​-​2​-​d​e​e​p​a​k​-​a​l​u​r​-​j​o​h​n​-​c​r​u​p​i​-​d​a​n​-​m​a​l​k​s​,​j​2​e​e​w​2​.​htm, udo­stęp­nio­no 16 lipiec 2017.