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.

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.