Zwinne projektowanie interfejsu użytkownika

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]