Tag: MVC

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

1 komentarz

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

Zwinne projektowanie interfejsu użytkownika

4 komentarze

W ostat­nim arty­ku­le zwra­ca­łem uwa­gę mię­dzy inny­mi na bar­dzo waż­ny ele­ment ana­li­zy i pro­jek­to­wa­nia jakim jest abs­tra­ho­wa­nie od deta­li, ponieważ: 

…ana­li­tyk musi abs­tra­ho­wać od wszel­kich deta­li, bez tego pro­jekt zosta­nie już na samym począt­ku ?zabi­ty? ich ilo­ścią. [1]

Nieco wcze­śniej (2013 r.) pisa­łem o tym, kie­dy uzgad­niać deta­le, któ­re i gdzie one są: 

Cała logi­ka biz­ne­so­wa jest wyko­ny­wa­na wewnątrz apli­ka­cji (infor­ma­cje o ewen­tu­al­nych błę­dach poja­wią się po zatwier­dze­niu for­mu­la­rza), np. upust może być spraw­dzo­ny (albo nali­czo­ny) dopie­ro po skom­ple­to­wa­niu danych wyma­ga­nych do jego wyli­cze­nia, czy­li będzie to kil­ka róż­nych pól (naj­mniej dwa :)). Bywa, że do wyli­cze­nia cze­goś potrzeb­ne będą dane nie wpro­wa­dza­ne do danej for­mat­ki fak­tu­ry, np. sal­do klien­ta. [2]

Tym razem kil­ka słów o tym jak skom­pli­ko­wać i zabić pro­jekt już pierw­sze­go dnia. Jednym z naj­bar­dziej ryzy­kow­nych spo­so­bów roz­po­czy­na­nia pro­jek­tu jest roz­po­czy­na­nie od kon­sul­ta­cji z użyt­kow­ni­kiem w kwe­stii inter­fej­su użyt­kow­ni­ka. Prowadzi to do sytu­acji, w któ­rej jesz­cze nie mamy żad­ne­go poję­cia o logi­ce biz­ne­so­wej i archi­tek­tu­rze apli­ka­cji, a już dekla­ru­je­my to jak będzie się ona komu­ni­ko­wa­ła z użyt­kow­ni­kiem (cie­ka­we na jakiej podstawie?). 

Do napi­sa­nia tego arty­ku­łu skło­nił mnie ten wpis:

The role of design still puz­zles many agi­le teams I work with. When sho­uld the design acti­vi­ties take pla­ce? Who sho­uld car­ry them out? How are design deci­sions best cap­tu­red? This blog tries to answer the questions by discus­sing a user-cen­tric, ite­ra­ti­ve, and col­la­bo­ra­ti­ve design pro­cess for Scrum and Kanban teams. [3]

Autor poka­zu­je jak ​„wal­czy” ze zło­żo­no­ścią na tym eta­pie, ja pra­gnę zasu­ge­ro­wać by do tej zło­żo­no­ści na tym eta­pie po pro­stu nie dopusz­czać. Powyższy dia­gram poka­zu­je z czym wal­czy ana­li­tyk, któ­ry dopro­wa­dzi do zebra­nia wyrwa­nych z kon­tek­stu (tak, nie ma mode­lu logi­ki więc dys­ku­sje o GUI są ode­rwa­ne od kon­tek­stu) ​„wyma­gań” (histo­ryj­ki użyt­kow­ni­ka, lewa kolum­na tabli­cy Story Area), któ­rych zama­wia­ją­cy może ​„naopo­wia­dać” bar­dzo dużo.

A jak ina­czej? Pomoże nam sto­so­wa­nie wzor­ców archi­tek­to­nicz­nych. Są one od lat dostęp­ne w więk­szo­ści fra­me­wor­ków (szko­da, że bar­dzo czę­sto deve­lo­pe­rzy je igno­ru­ją). Poniżej pro­sty, abs­trak­cyj­ny model kla­sycz­ne­go wzor­ca MVC.

W archi­tek­tu­rze wydzie­la się kom­po­nen­ty (sepa­ro­wa­nie odpo­wie­dzial­no­ści): odpo­wie­dzial­ny za obsłu­gę dia­lo­gu z użyt­kow­ni­kiem (View), odpo­wie­dzial­ny za tech­no­lo­gie, jakość, bez­pie­czeń­stwo, ste­ro­wa­nie itp. (Controler) oraz odpo­wie­dzial­ny za (całą a nie tyl­ko dane!) logi­kę biz­ne­so­wą (Model). 

Zarządzanie zło­żo­no­ścią pole­ga tu na tym, by na począt­ku ana­li­zy i pro­jek­to­wa­nia abs­tra­ho­wać cał­ko­wi­cie od deta­li GUI! (a dokład­nie od całej tech­no­lo­gii czy­li ele­men­tów View i Contoler). Kluczową odpo­wie­dzial­no­ścią apli­ka­cji jest reali­za­cja okre­ślo­nej logi­ki biz­ne­so­wej. Na tym eta­pie powi­nien powstać model przy­pad­ków uży­cia rozu­mia­ny jako pro­sty dia­log pomię­dzy użyt­kow­ni­kiem a apli­ka­cją, tu celem jest uchwy­ce­nie klu­czo­wych wyma­gań jaki­mi są wyma­ga­ne usłu­gi apli­ka­cyj­ne reali­zo­wa­ne przez apli­ka­cję oraz opra­co­wa­nie wewnętrz­nej archi­tek­tu­ry – Modelu, któ­ra te usłu­gi zre­ali­zu­je. Dopiero po prze­te­sto­wa­niu całej logi­ki biz­ne­so­wej na mode­lach, war­to się zabie­rać na kom­pli­ko­wa­nie pro­jek­tu poprzez opra­co­wa­nie deta­li GUI, ste­ro­wa­nia, bez­pie­czeń­stwa itp.. Postępowanie takie umoż­li­wia wzo­rzec archi­tek­to­nicz­ny MVVM opra­co­wa­ny ponad 10 lat temu. Wzorzec ten wpro­wa­dza dodat­ko­wy kom­po­nent pomię­dzy kom­po­nen­ty View i Model: View-Model, któ­ry reali­zu­je logi­kę dia­lo­gu GUI-użyt­kow­nik. Dzięki temu może­my wydzie­lić etap pra­cy nad GUI, jako osob­ny w pro­jek­cie, któ­ry zre­ali­zu­je (póź­niej) tak zwa­ny ​„UX desi­gner”, a deve­lo­per zamie­ni pier­wot­nie abs­trak­cyj­ny kom­po­nent View na imple­men­ta­cje ​„View-View Model”.

Bardzo dobry opis tego podejścia:

W przy­pad­ku war­stwy pre­zen­ta­cji moż­na wyko­rzy­stać m. in. nastę­pu­ją­ce roz­wią­za­nia: MVC, MVP czy Model-View-ViewModel. Ze wzglę­du na mecha­nizm wią­zań (bin­ding), pro­gra­mi­stom WPF oraz Silverlight, pole­ca­ny jest wzo­rzec MVVM ? jest to tech­no­lo­gia umoż­li­wia­ją­ca bar­dzo łatwą imple­men­ta­cję wzor­ca. […] …po co utrud­niać sobie zada­nie poprzez wyko­rzy­sty­wa­nie MVVM, zamiast pisać apli­ka­cję w kla­sycz­ny spo­sób (za pomo­cą code-behind)? W koń­cu wdro­że­nie prak­tycz­nie każ­de­go wzor­ca pro­jek­to­we­go wyma­ga tro­chę więk­szych począt­ko­wych nakła­dów pra­cy.

Podejście Code-Behind (auto­no­mo­us view ? AV) ma poważ­ną wadę ? nie gwa­ran­tu­je ela­stycz­no­ści oraz testo­wal­no­ści. Podsumowując, wpro­wa­dze­nie wzor­ca [MVVM, przy­pis auto­ra] umożliwia:

  • nie­za­leż­ność logi­ki od spo­so­bu wyświe­tla­nia danych,
  • nie­za­leż­ność kodu od tech­no­lo­gii, w któ­rej wyko­na­na jest war­stwa prezentacji,
  • wyko­ny­wa­nie testów ? za pomo­cą MVVM czy MVP moż­li­we jest wyko­na­nie testów zauto­ma­ty­zo­wa­nych (np. jednostkowych),
  • łatwą zamia­nę wido­ków (brak sztyw­nych powią­zań mię­dzy wido­kiem a logi­ką). [4]

(Tak: sto­so­wa­nie wzor­ców pod­no­si począt­ko­wą pra­co­chłon­ność ale zwra­ca się z nawiąz­ką w dal­szych cyklach życia pro­jek­tu.) Strukturę i histo­rię powsta­nia tej archi­tek­tu­ry zain­te­re­so­wa­ni mogą poznać tak­że tu: 

Model View View Model (MVVM) 
In 2005, John Gossman, Architect at Microsoft, unve­iled the Model-View-ViewModel (MVVM) pat­tern on his blog. MVVM is iden­ti­cal to Fowler?s Presentation Model, in that both pat­terns featu­re an abs­trac­tion of a View, which con­ta­ins a View?s sta­te and beha­vior. Fowler intro­du­ced Presentation Model as a means of cre­ating a UI plat­form-inde­pen­dent abs­trac­tion of a View, whe­re­as Gossman intro­du­ced MVVM as a stan­dar­di­zed way to leve­ra­ge core featu­res of WPF and Silverlight to sim­pli­fy the cre­ation of user inter­fa­ces. MVVM is a spe­cia­li­za­tion of the more gene­ral PM pat­tern, tailor-made for the WPF and Silverlight plat­forms to leve­ra­ge core featu­res of WPF such as data bin­ding, com­mands , templates.

This dia­gram take from MSDN depicts MVVM Pattern in action.

image[5]

Tak więc ana­li­zę i pro­jek­to­wa­nie war­to zacząć od logi­ki i szkie­le­tu archi­tek­tu­ry, a ta to przede wszyst­kim Model (dzie­dzi­ny) sys­te­mu czy­li kom­plet­na logi­ka biz­ne­so­wa (utoż­sa­mia­nie mode­lu dzie­dzi­ny z rela­cyj­ną bazą danych to poważ­ny błąd i nie­po­ro­zu­mie­nie). Po upo­ra­niu się z tym eta­pem pro­jek­tu ma sens opra­co­wy­wa­nie deta­li komu­ni­ka­cji z użyt­kow­ni­kiem, bo dopie­ro teraz zna­my wyma­ga­nia i ogra­ni­cze­nia logi­ki biz­ne­so­wej. Odkrywanie ich dopie­ro na eta­pie pro­to­ty­po­wa­nia to sta­now­czo za póź­no, bo gene­ru­je to ogrom­ne kosz­ty cyklicz­ne­go refak­to­rin­gu kodu (albo kod szyb­ko sta­je się ​„bry­łą błota”). 

Bardzo czę­sto sły­szę, że klient chce jak naj­szyb­ciej coś zoba­czyć. Rzecz w tym, że jeże­li się na to zgo­dzi­my, powsta­je i jest akcep­to­wa­na masa tak zwa­nych ​„poboż­nych życzeń”, a klient bar­dzo szyb­ko się przy­wią­zu­je do tego co zoba­czył na pre­zen­ta­cji (i nie chce odpu­ścić). W efek­cie two­rzy się spi­ra­la żądań, testów i popra­wek, któ­re szyb­ko prze­kształ­ca­ją ​„agi­le” w poraż­kę budże­tu i har­mo­no­gra­mu. Praktyka poka­zu­je, że budżet zawsze ma limit, dla­te­go bar­dzo wie­le takich pro­jek­tów koń­czy albo w koszu na śmie­ci albo efek­ty sta­no­wią tyl­ko namiast­kę tego co opi­sy­wa­ła pier­wot­na wizja. Jeżeli zaś zacznie­my od jądra sys­te­mu a na koniec zosta­wi­my sobie ​„maki­jaż” jakim jest GUI, szan­sa na suk­ces będzie znacz­nie więk­sza. Problem pole­ga na tym, że moda na ​„user-cen­tric, ite­ra­ti­ve, and col­la­bo­ra­ti­ve design” jest sil­na mimo tego, że jest przy­czy­ną wie­lu porażek. 

Tak więc odpo­wiedź na pyta­nie jak pora­dzić sobie z życze­nia­mi biz­ne­su, brzmi: nie dopusz­czać do ich wyar­ty­ku­ło­wa­nia :). Projektowanie i two­rze­nie samo­cho­du roz­po­czy­na się od pod­wo­zia i napę­du a nie od deski rozdzielczej…

Bibliografia

[1]
J. Zelinski, ?Model czy abs­trak­cja?, Jarosław Żeliński IT-Consulting, 22-wrz-2017. [Online]. Available: https://it-consulting.pl//2017/09/22/model-czy-abstrakcja/. [Udostępniono: 25-wrz-2017]
[2]
J. Zelinski, ?Gdzie są te cho­ler­ne szcze­gó­ły?, Jarosław Żeliński IT-Consulting, 18-cze-2014. [Online]. Available: https://it-consulting.pl//2014/06/18/gdzie-sa-te-cholerne-szczegoly/. [Udostępniono: 25-wrz-2017]

MVC – komponent Model w architekturze systemu

Dodaj komentarz

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

Panowanie nad złożonością czyli gdzie są Przypadki Użycia czyli MVVM-MVC

Dodaj komentarz

Niedawno w arty­ku­le o dość wyzy­wa­ją­cym tytu­le 😉 Gdzie są te cho­ler­ne szcze­gó­ły pisa­łem o zło­żo­no­ści wyma­gań i tym, gdzie ta zło­żo­ność jest (mogła by być, powin­na być doku­men­to­wa­na, jak kto woli). Tam sku­pi­łem się na takich szcze­gó­łach jak regu­ły biz­ne­so­we i zło­żo­ne typy danych, czy­li tym co potocz­nie (i nie do koń­ca słusz­nie) nazy­wa się ​„wali­da­cja­mi” ([[wali­da­cja]]).

Drugim ele­men­tem ​„nio­są­cym” szcze­gó­ły jest dia­log użyt­kow­ni­ka z apli­ka­cją czy­li ​„ekra­ny”. Tu poja­wia się kolej­na por­cja wyma­gań, nie raz bar­dzo szcze­gó­ło­wych, zaciem­nia­ją­cych nie raz głów­ny sens two­rze­nia dane­go opro­gra­mo­wa­nia: sce­na­riu­sze pra­cy z ekra­nem (for­mat­ką ekra­no­wą itp.).

Jak już nie raz pisa­łem, ogól­na zasa­dą (dobrą prak­ty­ką) w inży­nie­rii jest abs­tra­ho­wa­nie oraz zarzą­dza­nie pozio­mem szcze­gó­ło­wo­ści każ­de­go eta­pu pra­cy na pro­jek­tem. Operowanie poję­cia­mi (ter­mi­na­mi) zamiast ich defi­ni­cja­mi, to abs­tra­ho­wa­nie od szcze­gó­łów czy­li ich her­me­ty­za­cja, np. ​„Kontrahent” to ​„nazwa pod­mio­tu, jego NIP, adres”.

Wymagania wobec apli­ka­cji zwią­za­ne z inte­rak­cją aktor-sys­tem, ich defi­nio­wa­nie i pro­jek­to­wa­nie reali­za­cji, nie nale­żą do łatwych eta­pów ana­li­zy i pro­jek­tu, są nie raz bar­dzo szcze­gó­ło­we. To powód dla któ­re­go war­to je tak­że ​„her­me­ty­zo­wać”. Jak? Pomagają w tym dwie rze­czy: wyod­ręb­nie­nie pro­jek­to­wa­nia (doku­men­to­wa­nia) szcze­gó­łów inte­rak­cji jako etap pro­jek­to­wa­nia nazy­wa­ny [[User Experience]] (dalej UX) oraz uży­cie wzor­ca pro­jek­to­we­go MVVM-MVC.

Najpierw jed­nak wzor­ce, bo te dadzą nam kon­tekst i gra­ni­ce her­me­ty­za­cji. Wzorzec MVVM i korzy­ści pły­ną­ce z jego uży­cia, przy­stęp­nie opi­sa­no na stro­nie MSDN:

Przed omó­wie­niem wzor­ca, war­to zasta­no­wić się, po co utrud­niać sobie zada­nie poprzez wyko­rzy­sty­wa­nie MVVM, zamiast pisać apli­ka­cję w kla­sycz­ny spo­sób (za pomo­cą code-behind)? W koń­cu wdro­że­nie prak­tycz­nie każ­de­go wzor­ca pro­jek­to­we­go wyma­ga tro­chę więk­szych począt­ko­wych nakła­dów pracy.

Podejście Code-Behind (auto­no­mo­us view ? AV) ma poważ­ną wadę ? nie gwa­ran­tu­je ela­stycz­no­ści oraz testo­wal­no­ści. Podsumowując, wpro­wa­dze­nie wzor­ca umożliwia:

  1. nie­za­leż­ność logi­ki od spo­so­bu wyświe­tla­nia danych,
  2. nie­za­leż­ność kodu od tech­no­lo­gii, w któ­rej wyko­na­na jest war­stwa prezentacji,
  3. wyko­ny­wa­nie testów ? za pomo­cą MVVM czy MVP moż­li­we jest wyko­na­nie testów zauto­ma­ty­zo­wa­nych (np. jednostkowych),
  4. łatwą zamia­nę wido­ków (brak sztyw­nych powią­zań mię­dzy wido­kiem a logiką).

(Wprowadzenie do wzor­ca pro­jek­to­we­go Model-View-ViewModel na przy­kła­dzie apli­ka­cji WPF | MSDN (Polska).)

Z per­spek­ty­wy ana­li­zy i pro­jek­to­wa­nia ([[OOAD]]) naj­istot­niej­sze są pierw­sze dwa punk­ty, bo umoż­li­wia­ją her­me­ty­za­cję (oddzie­le­nie) logi­ki biz­ne­so­wej i pro­jek­tu opi­su­ją­ce­go inte­rak­cje aktor-sys­tem czy­li UX. Punkt czwar­ty daje speł­nie­nie jed­nej z zasad SOLID czy­li ​„łatwość roz­sze­rze­nia bez potrze­by mody­fi­ka­cji”. Ta ostat­nia cecha to np. doda­wa­nie nowych inter­fej­sów użyt­kow­ni­ka do kolej­nych nowych urzą­dzeń (smart­fon, tablet, dedy­ko­wa­ne urzą­dze­nia i wyświe­tla­cze), bez potrze­by inge­ro­wa­nia w kod obsłu­gu­ją­cy już opro­gra­mo­wa­ne urządzenia.

Jak to wyglą­da z per­spek­ty­wy archi­tek­tu­ry apli­ka­cji i jej pro­jek­tan­ta? Poniżej model:

MVVM i MVC

Co tu mamy? Mamy MVVM i MVC na jed­nym dia­gra­mie. MVVM pole­ga na wsta­wie­niu pomię­dzy widok (View) a Model dodat­ko­we kom­po­nen­tu, któ­ry sta­no­wi wer­sję logi­ki biz­ne­so­wej zawie­ra­ją­cą ogra­ni­cze­nia ​„wyświe­tla­cza” i dedy­ko­wa­ne (spe­cy­fiacz­ne) tyl­ko dla nie­go zacho­wa­nia (to tak­że pozwa­la uni­ka­nia bar­dzo złej prak­ty­ki jaką jest umiesz­cza­nie logi­ki biz­ne­so­wej w kom­po­nen­cie View). Innymi sło­wy, jeże­li jakieś zacho­wa­nia sys­te­mu są spe­cy­ficz­ne dla kon­kret­ne­go typu wyświe­tla­cza (ale może to być spe­cy­fi­ka akto­ra o czym dalej), logi­kę tę her­me­ty­zu­je­my w kom­po­nen­cie ViewModel.

Mając taką abs­trak­cję apli­ka­cji jak powy­żej, łatwo będzie osob­no opi­sać ją przy­pad­ka­mi uży­cia, uzna­jąc je za ​„usłu­gi sys­te­mu (te świad­czy kom­po­nent Model) oraz osob­no szcze­gó­ło­wy­mi sce­na­riu­sza­mi UX zamknię­ty­mi w parze kom­po­nen­tów View-ViewModel. Oba te ele­men­ty pro­jek­tu – UX i Use Case, są więc ​„ład­nie” odse­pa­ro­wa­ne, nie wpły­wa­ją na sie­bie nawza­jem i pozwa­la­ją na łatwą roz­bu­do­wę całe­go sys­te­mu, nie­wy­ma­ga­ją­cą mody­fi­ko­wa­nia już powsta­łe­go kodu (i dokumentacji).

Nawiąże jesz­cze do ​„spe­cy­fi­ki akto­ra”. Bardzo czę­sto w sys­te­mach inter­ne­to­wych, mamy potrze­bę sepa­ra­cji użyt­kow­ni­ków ​„z poza fir­my” (np. klien­ci skle­pu inter­ne­to­we­go, inter­fej­sy samo­ob­słu­gi dla klien­tów ser­wi­su itp.). Wiąże się to nie raz z bar­dzo zło­żo­ny­mi zasa­da­mi kon­tro­li dostę­pu do ele­men­tów mode­lu 9czyli dość głę­bo­ko w sys­te­mie). Potrafi to bar­dzo skom­pli­ko­wać cały pro­jekt kom­po­nen­tu Model, a nie raz potrze­by jego istot­nej prze­bu­do­wy. Można tego unik­nąć, her­me­ty­zu­jąc ten obszar. Bardzo czę­sto oso­ba (użyt­kow­nik, aktor sys­te­mu) z zewnątrz ma bar­dzo ogra­ni­czo­ne moż­li­wo­ści korzy­sta­nia z logi­ki całe­go sys­te­mu. Łatwiej jest zapro­jek­to­wać dedy­ko­wa­ny, rela­tyw­nie pro­sty kom­po­nent ViewModel i połą­czyć go z Modelem, niż mody­fi­ko­wać Model Dziedziny sys­te­mu by obsłu­gi­wał, nowe, nie raz bar­dzo wyra­fi­no­wa­ne, ogra­ni­cze­nia dostępu.

Tak więc przy­pad­ka­mi uży­cia opi­su­je­my abs­trak­cję jaką jest [[Model Dziedziny Systemu]]. Są one wte­dy pro­ste, zawie­ra­ją sce­na­riusz, któ­ry w skró­cie ma postać: aktor ini­cju­je usłu­gę, sys­tem pre­zen­tu­je for­mu­larz do wypeł­nie­nia, aktor wypeł­nia go i potwier­dza, sys­tem potwier­dza ode­bra­nie danych i poka­zu­je wynik swo­jej pra­cy (lub komu­ni­ka­ty o błę­dach). Tu sku­pia­my się na opi­sie tego jakie usłu­gi są wyma­ga­ne od sys­te­mu. Kolejny etap to ​„kom­pli­ko­wa­nie” każ­de­go sce­na­riu­sza w posta­ci pro­jek­to­wa­nia, dla każ­de­go przy­pad­ku uży­cia, któ­ry tego wyma­ga, róż­ne­go rodza­ju wizar­dów lub wpro­wa­dza­my ogra­ni­cze­nia zwią­za­ne z upraw­nie­nia­mi użyt­kow­ni­ków. Ten etap to pra­ca pro­jek­tan­tów UX i gra­fi­ków, spe­cja­li­stów od ergo­no­mii itp.

Wymagania pozafunkcjonane czyli jaka architektura

10 komentarzy

Poza wyma­ga­nia­mi funk­cjo­nal­ny­mi, poda­je­my tak zwa­ne wyma­ga­nia poza-funk­cjo­nal­ne. Mają one, mię­dzy inny­mi, waż­na rolę do speł­nie­nia. Jaką?

Najpierw cytat:

Technologia klient/serwer jest zależ­na od komu­ni­ka­cji pomię­dzy poszcze­gól­ny­mi kom­pu­te­ra­mi. Sieci LAN i WAN sta­ją się znacz­nym wydat­kiem oraz wyma­ga­ją dużych nakła­dów pra­cy w związ­ku z zarzą­dza­niem nimi. Co wię­cej, zmia­na wer­sji opro­gra­mo­wa­nia na wie­lu kom­pu­te­rach, co szcze­gól­nie widocz­ne jest w przy­pad­ku prze­twa­rza­nia roz­pro­szo­ne­go, sta­je się istot­nym pro­ble­mem. Wielokrotnie dzia­ły IT zasta­na­wia­ją się nad przej­ściem na struk­tu­rę Internet/Intranet w celu roz­wią­za­nia tego pro­ble­mu. (Wstęp do ERP – tech­no­lo­gia u pod­wa­lin przedsiębiorstwa).

Pomijając ​„pro­sto­tę” tego tłu­ma­cze­nia, chcę zwró­cić uwa­gę na waż­ną rzecz: bar­dzo duże znacz­nie ma archi­tek­tu­ra sys­te­mu, nie­ste­ty wie­lu pro­du­cen­tów ukry­wa zasto­so­wa­ną tech­no­lo­gię i archi­tek­tu­rę. Jedną z przy­czyn jest to, że są to nie raz tech­no­lo­gie rodem z lat 90-tych a bywa, że nawet wcze­śniej­sze. Jedną z takich ​„sta­ro­ci” jest archi­tek­tu­ra client-server (tak zwa­ny gru­by klient). Innym typem ​„dino­zau­ra” tech­no­lo­gicz­ne­go jest two­rze­nie opro­gra­mo­wa­nia, w któ­rym logi­ka biz­ne­so­wa jest w jakiejś czę­ści w pro­ce­du­rach wbu­do­wa­nych bazy danych (w rozu­mie­niu kon­kret­ne­go tak zwa­ne­go moto­ra SQL bazy).

Jaki mamy wybór?

Zanim powie­my sobie o wybo­rze, kil­ka słów na temat kla­sycz­nej trój­war­stwo­wej archi­tek­tu­ry jako fun­da­men­cie dal­szych roz­wa­żań. Struktura taka wyglą­da następująco:

Architektura trójwarstwowa

Mamy tu trzy war­stwy: Warstwa pre­zen­ta­cji, czy­li kom­po­nent odpo­wie­dzial­ny za wyświe­tla­nie infor­ma­cji na ekra­nie użyt­kow­ni­ko­wi i ich przyj­mo­wa­nie. Warstwa logi­ki apli­ka­cji podzie­lo­na na Logikę dzie­dzi­no­wą (część spe­cy­ficz­na dla dzie­dzi­ny pro­ble­mu, tu są np. fak­tu­ry, spo­sób nali­cza­nia podat­ków, raba­tów itp. ta część reali­zu­je wyma­ga­nia funk­cjo­nal­ne) oraz Logikę poza-dzie­dzi­no­wą (wydaj­ność, nie­za­wod­ność, bez­pie­czeń­stwo, inte­gra­cja z inny­mi apli­ka­cja­mi itp.). Najniżej jest war­stwa Utrwalania, coraz czę­ściej w para­dyg­ma­cie obiek­to­wym pomi­ja­na na tym pozio­mie abs­trak­cji (utoż­sa­mia­na z reali­za­cją wyma­gań poza-funk­cjo­nal­nych zwią­za­nych z zacho­wy­wa­niem informacji).

Praca w sie­ci wie­lu użyt­kow­ni­ków to wie­lo­do­stęp (wie­le sta­cji robo­czych korzy­sta z jed­ne­go serwera):

Wielodostęp

Gruby klient

Gruby klient to archi­tek­tu­ra w któ­rej każ­dy użyt­kow­nik ma na swo­im lokal­nym kom­pu­te­rze nie tyl­ko war­stwę pre­zen­ta­cji ale tak­że całą logi­kę apli­ka­cji. Każde takie sta­no­wi­sko komu­ni­ku­je się z ser­we­rem danych:

Architektura Gruby klient

Do powyż­szej archi­tek­tu­ry odno­szą się głów­ne uwa­gi o wadach z cyta­tu na począt­ku. Cechy archi­tek­tu­ry po lewej stro­nie: kosz­tow­ne sta­cje robo­cze (muszą, każ­da, udźwi­gnąć całe opro­gra­mo­wa­nie), kosz­tow­na admi­ni­stra­cja (nie­zgod­ność wer­sji na sta­cjach robo­czych może pro­wa­dzić do kra­chu sys­te­mu), kosz­tow­ne mody­fi­ka­cje (tak­że z uwa­gi na wyma­ga­ną zgod­ność opro­gra­mo­wa­nia na sta­cjach robo­czych), bar­dzo duże wyma­ga­nia na pasmo i nie­za­wod­ność sie­ci (duże trans­fe­ry danych pomię­dzy sta­cja­mi robo­czy­mi i ser­we­rem, zerwa­nie połą­cze­nia powo­du­je blo­ka­dy dostę­pu do danych) powo­du­ją, że pra­ca w sie­ci roz­le­głej tery­to­rial­nie może być wręcz nie­moż­li­wa (wte­dy wyma­ga powie­la­nia insta­la­cji w każ­dej loka­li­za­cji i syn­chro­ni­za­cji danych, kolej­ne nie­ma­łe kosz­ty). Pewną odmia­ną jest wariant po pra­wej stro­nie, gdzie część logi­ki apli­ka­cji jest umiesz­czo­na na ser­we­rze danych (kon­kret­nie bazy danych), powo­du­je to nie­co zmniej­szo­ny ruch w sie­ci ale dodat­ko­wo kom­pli­ku­je wszel­kie roz­sze­rze­nia funk­cjo­nal­no­ści i upgra­de oraz prak­tycz­nie unie­moż­li­wia zmia­nę (wybór) pro­du­cen­ta bazy danych. Duże kosz­ty tej archi­tek­tu­ry dodat­ko­wo potę­gu­je wymóg wyku­pie­nia licen­cji na bazę danych dla każ­de­go użytkownika.

W więk­szo­ści przy­pad­ków tej archi­tek­tu­ry, logi­ka biz­ne­so­wa (dzie­dzi­no­wa) nie jest sepa­ro­wa­na od resz­ty, w efek­cie dodat­ko­wo wszel­kie pra­ce dosto­so­waw­cze są bar­dzo kosz­tow­ne (inge­ren­cja w całą aplikację).

Architektura internetowa – cienki klient

Taką nazwę od pew­ne­go cza­su nada­je się archi­tek­tu­rze opar­tej na dostę­pie do apli­ka­cji z pomo­cą prze­glą­dar­ki WWW:

Architektura Cienki klient

Powyższa archi­tek­tu­ra prak­tycz­nie nie ma żad­nej wady poprzed­nie­go roz­wią­za­nia. Dodatkowo baza danych licen­cjo­no­wa­na jest z regu­ły na apli­ka­cję a nie na każ­de­go użyt­kow­ni­ka (czy­li jest taniej). Stosując tak zwa­ne meto­dy i archi­tek­to­nicz­ne wzor­ce obiek­to­we (naj­po­pu­lar­niej­szy to MVC: Model, View, Controller) sepa­ru­je się kom­po­nent logi­ki biz­ne­so­wej od logi­ki ste­ro­wa­nia apli­ka­cją. W efek­cie dosto­so­wa­nie apli­ka­cji nie pole­ga na kosz­tow­nym mody­fi­ko­wa­niu logi­ki apli­ka­cji, doda­je się i inte­gru­je nie­za­leż­ny kom­po­nent Logiki biz­ne­so­wej, co dodat­ko­wo pozwa­la zacho­wać sepa­ra­cję praw autor­skich do kodu logi­ki biz­ne­so­wej (know-how fir­my). Korzyścią takiej archi­tek­tu­ry jest tak­że moż­li­wość łatwe­go doda­wa­nia moż­li­wo­ści dostę­pu z innych niż kom­pu­ter PC, urzą­dzeń (smart­fo­ny, table­ty, itp.) gdyż wyma­ga to wyłącz­nie nowej war­stwy pre­zen­ta­cji, logia pozo­sta­je spój­na na serwerze.

Kolejna korzyść to łatwa inte­gra­cja z inny­mi apli­ka­cja­mi. Oprogramowanie w tej archi­tek­tu­rze ​„ukry­wa” dane, dostęp do nich jest wyłącz­nie przez Logikę apli­ka­cji za pośred­nic­twem tak zwa­nych API (inter­fejs pro­gra­mi­stycz­ny) meto­da­mi zna­ny­mi w sie­ci WWW, uni­ka­my kosz­tow­nych i ryzy­kow­nych łączy bez­po­śred­nich do baz danych (niska pra­co­chłon­ność inte­gra­cji, bar­dzo wyso­kie kosz­ty utrzy­ma­nia i rozwoju).

W efek­cie reko­men­do­wa­na archi­tek­tu­ra mogła by wyglą­dać tak:

Rekomendowana architektura aplikacji

Zalety: niskie kosz­ty utrzy­ma­nia sys­te­mu i infra­struk­tu­ry, sepa­ra­cja logi­ki biz­ne­so­wej (dzie­dzi­no­wej) dedy­ko­wa­nej od ​„kupio­nej”, łatwość i niski koszt upgra­de, pra­ca z pomo­cą prze­glą­dar­ki WWW, łatwa inte­gra­cja z inny­mi apli­ka­cja­mi, łatwość pra­cy w sie­ci lokal­nej i roz­le­głej (w tym łatwy zdal­ny dostęp z dowol­ne­go cudze­go kom­pu­te­ra). To tyl­ko głów­ne korzyści.

Wymagania pozafunkcjonalne

Jak wspo­mnia­łem, wie­lu dostaw­ców opro­gra­mo­wa­nia jak Rejtan, bro­ni się przed ujaw­nia­niem archi­tek­tu­ry, swo­ich pro­duk­tów. Głównym powo­dem jest zapo­bie­ga­nie przed­wcze­sne­go wyja­wie­nia opi­sa­nych wyżej wad sys­te­mów z gru­bym klien­tem (znacz­nie rza­dziej spek­ta­ku­lar­ny pomysł, w koń­cu mamy jed­nak jakieś stan­dar­dy). Przypadki, w któ­rych zakup sys­te­mu był rela­tyw­nie niski ale koszt utrzy­ma­nia, roz­wo­ju i dosto­so­wa­nia nie raz wręcz ogrom­ny, to z regu­ły wła­śnie zakup sys­te­mu w tej kosz­tow­nej architekturze.

Jak sta­rać się tego uni­kać? Na eta­pie defi­nio­wa­nia wyma­gań poza-funk­cjo­nal­nych, żądać takich cech jak opi­sa­ne powy­żej czy­li wła­snie: dostęp do cało­ści przez prze­glą­dar­kę WWW, niskie wyma­ga­nia na łącza przy zdal­nej pra­cy i pra­cy w sie­ci roz­pro­szo­nej tery­to­rial­nie, oddzie­le­nie kom­po­nen­tu z wła­sną dedy­ko­wa­ną logi­ką biznesową.

[2015]

Polecam poga­dan­ke M.Fowlera na temat roli architektury:

Pojęcia, reguły i fakty czyli o czym oni mówią…

3 komentarze

Niedawno napi­sa­łem:

opro­gra­mo­wa­nie repre­zen­tu­je narzę­dzie pra­cy, więc pro­jekt tego opro­gra­mo­wa­nia raczej powi­nien zawie­rać poję­cie (kla­sę) Kartoteka Pracowników a nie Pracownicy. (Dlaczego nie podo­ba mi się kla­sa Pracownik?).

To sta­ły temat wie­lu dys­ku­sji z pro­gra­mi­sta­mi. Ostatnio, po pew­nym szko­le­niu, w ramach wspar­cia po szko­le­niu jakie zawsze świad­czę, zno­wu padło pytanie:

Czy zda­rza Ci się robić analizy/projekty, gdzie byty wystę­pu­ją pod nazwa­mi inny­mi niż uży­wa­ny­mi potocz­nie przez Biznes.

Z tym – uży­wa­ne poję­cia – jest regu­lar­nie duży pro­blem, dla­te­go od pew­ne­go cza­su orto­dok­syj­nie sto­su­ję budo­wa­nie ​„prze­strze­ni poję­cio­wej” dla pro­jek­tu ([[Semantics of Business Vocabulary and Business Rules]]). Buduję słow­nik pojęć, listę reguł biz­ne­so­wych (to nie to samo co regu­ły decy­zyj­ne) oraz tak zwa­ny dia­gram fak­tów, któ­ry słu­ży do testo­wa­nia (i doku­men­to­wa­nia słow­ni­ka) – upew­nie­nia się, że poję­cia nie koli­du­ją ze sobą a ich defi­ni­cje nie nakła­da­ją się na sie­bie oraz, że lista jest dzie­dzi­no­wo kom­plet­na. Po co to? Właśnie po to,

by żad­ne zde­fi­nio­wa­ne sło­wo nie mia­ło w pro­jek­cie (w wyma­ga­niach, w kodzie) wię­cej niż jed­ne­go zna­cze­nia i by zna­cze­nie każ­de­go zefi­nio­wa­ne­go poję­cia nie budzi­ło żad­nych wątpliwości

(co nie­co o słow­ni­kach ter­mi­nów: Reguły biz­ne­so­we jako motor ste­ru­ją­cy orga­ni­za­cji: fak­ty + defi­ni­cje pojęć).

Jedna uwa­ga na począ­tek: jeże­li ​„byty” (kla­sy) w kodzie (pro­jek­cie) opro­gra­mo­wa­nia wystę­pu­ją pod inny­mi nazwa­mi niż w rze­czy­wi­sto­ści, to jest to abso­lut­na poraż­ka, bo pro­gra­mi­sta zupeł­nie tra­ci kon­takt z klien­tem i (lub) doku­men­ta­cją opi­su­ją­ca wyma­ga­nia. Jeżeli już koniecz­nie pro­gra­mi­sta musi ulżyć sobie w ambi­cji uży­wa­nia wyłącz­nie j.angielskiego w kodzie, powi­nien ten kod być boga­to komen­to­wa­ny, by nie było wąt­pli­wo­ści jakie znacz­nie nie­sie np. nazwa kla­sy czy atry­bu­tu (tym bar­dziej, że np. sło­wo name to nie tyl­ko nazwisko.….)

http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471
źr. http://​www​.moder​na​na​lyst​.com/​R​e​s​o​u​r​c​e​s​/​B​u​s​i​n​e​s​s​A​n​a​l​y​s​t​H​u​m​o​r​/​t​a​b​i​d​/​2​1​8​/​D​e​f​a​u​l​t​.​a​s​p​x​?​A​r​t​i​c​l​e​T​y​p​e​=​A​r​t​i​c​l​e​V​i​e​w​&​A​r​t​i​c​l​e​I​D​=​2​471

Słownik pojęć (czę­sto wystę­pu­je w doku­men­tach jako czy­sto pol­skie sło­wo glos­sa­riusz ;)) bywa czę­sto przed­mio­tem burz­li­wych nego­cja­cji, bo nie raz (a w zasa­dzie zawsze ;)) biz­nes sto­su­je slang, w któ­rym to samo sło­wo ma róż­ne zna­cze­nie, zależ­nie od kon­tek­stu uży­cia. Może to mieć sens w języ­ku mówio­nym gdy peł­na treść wypo­wie­dzi daje ten kon­tekst, ale na pozio­mie ana­li­zy i pro­jek­tu każ­de poję­cie musi mieć jed­no uni­kal­ne znacz­nie mimo bra­ku kon­tek­stu (tym bar­dziej, że np. nazwy klas nie są ele­men­ta­mi peł­nych zdań ani opowieści :)).

Pamiętam pro­jekt, w któ­rym wice­pre­zes pew­nej fir­my na każ­de dzia­ła­nie takie jak nowa umo­wa, nowy pro­jekt, nowy klient, uży­wał sło­wa ​„temat”, nikt nie miał odwa­gi powie­dzieć mu, że nie raz nie rozu­mie o czym on mówi … Ja – obcy – się odwa­ży­łem 🙂 i upo­rząd­ko­wa­li­śmy to, był opór ;). Pamiętam, że dyplo­ma­tycz­nie popro­si­łem go by zbu­do­wał hie­rar­chię ​„tema­tów” nazy­wa­jąc każ­dy ele­ment tej hie­rar­chii jed­nym lub dwo­ma sło­wa­mi sło­wa­mi i pomo­gło :), Słownik pojęć to negocjacje 🙂

Evans (DDD ) zapo­cząt­ko­wał bar­dzo cie­ka­we podej­ście, ono się roz­wi­ja. Co cie­ka­we Evans nie wymy­ślił idei a sys­tem wzor­ców DDD. Wspólny język to dwa ele­men­ty: uży­wa­nie biz­ne­so­wych nazw (bez skró­tów) na ele­men­ty rze­czy­wi­ste i kla­sy w sys­te­mie, ale tak­że uży­wa­nie np. poję­cia ​„fabry­ka” przez biz­nes i przez deve­lo­pe­ra jako ​„kon­te­ner” na pewien rodzaj kom­pe­ten­cji (wie­dza o tym jak powsta­ją pew­ne obiek­ty biznesowe).

Elementy wzor­ca DDD to nie tyl­ko blo­ki kodu, to tak­że ele­men­ty (kla­sy­fi­ka­to­ry) wie­dzy o biz­ne­sie. Faktura VAT to agre­gat – struk­tu­ra infor­ma­cji, to tyl­ko wie­dza o tym co ten doku­ment zawie­ra, ale FabrykaFaktur to odręb­na wie­dza o tym jak ten doku­ment jest two­rzo­ny. Należy świa­do­mie udo­ku­men­to­wać oba byty: doku­ment i recep­ta jego two­rze­nia. Dlaczego osob­no? Bo po pierw­sze wysta­wio­ne fak­tu­ry żyją wła­snym, życiem i obcią­ża­nie każ­dej z nich (np. tysiąc fak­tur mie­sięcz­nie) całą wie­dza jak powsta­ła nie ma więk­sze­go sen­su. Po dru­gie zmia­na prze­pi­sów nie powin­na się odbić na doku­men­tach już wysta­wio­nych ani docią­żyć nowo powstających.

Biznes tak­że musi zro­zu­mieć, że ma dwa róż­ne ele­men­ty opi­su swo­ich dzia­łań: pra­ca z doku­men­ta­mi i two­rze­nie doku­men­tów. Jednak uzna­nie tego fak­tu to jed­no, nie wie­rzę w to, że biz­nes się tego nauczy, bo nie nauczył się for­mal­ne­go opi­su lub mode­lo­wa­nia pro­ce­sów pod­czas wdro­żeń ISO, jed­nak uwa­żam, że biz­nes nie ma takiej potrze­by. Moim zda­niem od dobre­go ana­li­ty­ka nie ma uciecz­ki, to inna kom­pe­ten­cja. Nie ma uciecz­ki od pro­jek­tan­tów mody mimo ist­nie­nia kobiet chcą­cych mieć ład­ne sukien­ki i bar­dzo dobrych kraw­ców. Nikt tu niko­go nie zastąpi.

Czy Model dziedziny ma stan?

(to część bar­dziej techniczna)

W kwe­stii cze­goś takie­go jak Stan Modelu w MVC (czy model biz­ne­so­wy ma stan?) jestem ostroż­ny z uży­wa­niem poję­cia ​„stan”, popa­trz­my na gry kom­pu­te­ro­we… Czym jest stan? Stan na pewien moment w cza­sie (snap­shot) czy stan ​„biz­ne­so­wy” trwa­ją­cy minu­ty, godzi­ny a nie raz dłu­żej? Model to sys­tem: zespół ele­men­tów współ­dzia­ła­ją­cych. Z per­spek­ty­wy biz­ne­su, reagu­je on na akcje (sta­bil­ny ekran ocze­ki­wa­nia na OK, to per­ma­nent­ny maszy­no­wy prze­bieg spraw­dza­nia sta­nu przy­ci­sków). Osobiście trak­tu­ję kla­sy Modelu jako samo­dziel­ne żyją­ce byty, kon­struk­cja metod musi zagwa­ran­to­wać brak błę­dów i radzić sobie z tym co ​„sta­łe” dla użyt­kow­ni­ka i ​„zmien­ne” dla sys­te­mu (zegar bez sekund­ni­ka jest z per­spek­ty­wy minut mar­twym przed­mio­tem a mimo to ​„cho­dzi”).

Podejście do MVC, któ­re prak­ty­ku­ję: Model powi­nien reali­zo­wać 100% funk­cjo­nal­no­ści i dać się testo­wać bez war­stwy V i C. Konkretnym sta­nem raczej cha­rak­te­ry­zu­je się kon­kret­ny obiekt a nie cały sys­tem. Cały sys­tem moż­na zapew­ne opi­sać maszy­ną sta­no­wą ale po co, sko­ro są ich nie­zli­czo­ne ilo­ści? Model żyje jak mro­wi­sko, wystar­czy zro­zu­mieć mrów­ki, mro­wi­sko to sku­tek na któ­ry za bar­dzo nie mamy wpływu.

Model DDD ​„ana­li­tycz­ny” to meta­mo­del imple­men­ta­cji, Evans trak­tu­je go jako ​„blo­ki kodu” zro­zu­mia­łe przez biz­nes, idąc dalej: ana­li­tyk trak­tu­je DDD jako wie­dzę o biz­ne­sie w posta­ci zro­zu­mia­łej przez deve­lo­pe­ra. Obie stro­ny uzna­ją, że ta struk­tu­ra jest wza­jem­ną ​„umo­wą”. Jestem zwo­len­ni­kiem takie­go podej­ścia do DDD :), Evans się z tym w moich oczach nie kło­ci, on w zasa­dzie nie pisał o ana­li­zie biz­ne­so­wej :). Wielu pro­gra­mi­stów, auto­rów dosko­na­łych ksią­żek, zakła­da, że ​„ana­li­zę wyma­gań ma popraw­nie wyko­na­ną”, co by to nie mia­ło zna­czyć :), ale to ogrom­ne uprosz­cze­nie bo tu – błę­dy – tkwi więk­szość ryzyk projektu.

Więcej o słow­ni­kach i regu­łach biznesowych:

(OMG, Glossary, Business Rules, http://​en​.wiki​pe​dia​.org/​w​i​k​i​/​S​e​m​a​n​t​i​c​s​_​o​f​_​B​u​s​i​n​e​s​s​_​V​o​c​a​b​u​l​a​r​y​_​a​n​d​_​B​u​s​i​n​e​s​s​_​R​u​les oraz http://​en​.wiki​pe​dia​.org/​w​i​k​i​/​B​u​s​i​n​e​s​s​_​r​ule, http://​www​.visu​al​-para​digm​.com/​s​u​p​p​o​r​t​/​d​o​c​u​m​e​n​t​s​/​b​p​v​a​u​s​e​r​g​u​i​d​e​/​2​0​1​7​/​2​1​8​1​/​5​7​0​4​3​_​c​r​e​a​t​i​n​g​f​a​c​t​.​h​tml).