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

Dokumenty czy niedokumenty.… czyli zarządzanie informacją i jej standaryzacja

Nie raz tu już pisa­łem, że ana­li­zy i pro­jek­ty zwią­za­ne bez­po­śred­nio z wyma­ga­nia­mi na opro­gra­mo­wa­nie to tyl­ko” ok. 3/4 moich pro­jek­tów. Jednak nawet, jeże­li pro­jekt nie jest nazwa­ny” infor­ma­tycz­nym, to zawsze jest infor­ma­cyj­ny” w rozu­mie­niu zarzą­dza­nia infor­ma­cją (tak­że zarzą­dza­nie wie­dzą). Tym razem kil­ka słów na temat doku­men­tów. Stanowią one pod­sta­wo­wą jed­nost­kę infor­ma­cji (i danych) w każ­dym sys­te­mie biz­ne­so­wym. Są tak­że źró­dłem danych dla hur­tow­ni danych.

Wstęp

Wiele pro­jek­tów zwią­za­nych z doku­men­ta­mi jest spro­wa­dza­nych do problemu:

jakie mamy doku­men­ty i co z nimi robimy?”

Zaniedbuje się bar­dzo waż­ny ele­ment: odpo­wiedź na pytanie:

czy nasze obec­ne doku­men­ty, ich ilość i treść, są właściwe?”

Otóż prak­ty­ka poka­zu­je, że dość czę­sto pro­ble­mem są doku­men­ty opra­co­wa­ne kie­dyś tam”. Inicjuje się pro­jekt z róż­ny­mi wyma­ga­nia­mi ale niko­mu nie przy­cho­dzi do gło­wy by zasta­no­wić się nad tym czy obec­ne doku­men­ty, w ich obec­nej posta­ci, są dobrym pomy­słem i powin­ny takie pozostać.

Czy doku­men­ty są nie­zmie­nial­nym bytem? Nie, nie są.

Każda orga­ni­za­cja obra­ca skoń­czo­ną licz­bą doku­men­tów, są to róż­ne­go rodza­ju for­mu­la­rze, w naj­ogól­niej­szym przy­pad­ku doku­men­tem jest po pro­stu każ­da treść, tak­że zwy­kła pro­za” np. notat­ka. Warto jed­nak zwró­cić uwa­gę na to, że nawet ona ma pew­ną struk­tu­rę: np. auto­ra, adre­sa­ta, temat, datę i treść. Dokumenty to okre­ślo­na kon­kret­na treść utrwa­lo­na z okre­ślo­ne­go powo­du (w prze­ciw­nym wypad­ku doku­ment nie by powstał). Osiem lat temu opi­sy­wa­łem kwe­stie róż­ni­cy mię­dzy doku­men­tem, wie­dzą, infor­ma­cją a danymi:

Czy baza danych to wie­dza?[?] Model jaw­nie poka­zu­je, że bez­po­śred­ni zwią­zek z Bazą Danych mają Dane. Dalej już są wyłącz­nie nie­ma­te­rial­ne poję­cia czym więc jest Zarządzanie Wiedzą (mil­czą­co zakła­dam, że zarzą­dzać moż­na czymś mate­rial­nym)? Jest to ?prze­cho­wy­wa­nie danych jed­no­znacz­nie zro­zu­mia­łych, opi­su­ją­cych okre­ślo­ne i ogra­ni­czo­ne licz­bą fak­ty inter­pre­to­wa­ne jako poj­mo­wal­na przez adre­sa­ta infor­ma­cja?. (Źródło: Potrzeby infor­ma­cyj­ne fir­my ? Zarządzanie wie­dzą | Jarosław Żeliński IT-Consulting)

Dzisiaj co nie­co o tym, dla­cze­go od cza­su do cza­su war­to się pochy­lić nad wzo­ra­mi doku­men­tów i czy cza­sem nie zmie­nić nie­co podej­ścia do nich.

Dokumenty w organizacji

Swego cza­su u jed­ne­go z moich klien­tów odkry­łem” cie­ka­wy doku­ment. Była to fak­tu­ra z doda­nym zesta­wem danych odpo­wia­da­ją­cym doku­men­tom WZ oraz ana­lo­gicz­nym zesta­wie­niem doty­czą­cym opa­ko­wań zwrot­nych. Ten super doku­ment był pomy­słem z przed wie­lu lat oso­by odpo­wie­dzial­nej za wyda­wa­nie i zarzą­dza­nie opa­ko­wa­nia­mi zwrot­ny­mi w maga­zy­nie. Uzasadnienie brzmia­ło: na jed­nym doku­men­cie będą wszyst­kie infor­ma­cje zwią­za­ne z kon­kret­ną sprze­da­żą i dosta­wą. Brzmi ład­nie jed­nak: prak­tycz­nie każ­dy kto miał z tym doku­men­tem do czy­nie­nia, w toku obsłu­gi zamó­wie­nia, dosta­wał nad­mia­ro­we dane, nie raz nie­jaw­ne (nie­któ­re) ceny, szcze­gó­ły zawar­to­ści paczek, war­tość towa­ru (po co ta wie­dza kie­row­com), ilo­ści i sal­da (tak) opa­ko­wań zwrot­nych (jak się oka­za­ło doku­ment nie raz poma­gał w nad­uży­ciach, nie­któ­rzy pra­cow­ni­cy zaś zama­zy­wa­li cza­sa­mi część danych prze­ka­zu­jąc doku­ment dalej, by ich nie ujaw­niać). Ale naj­więk­szym pro­ble­mem było to, że ta oso­ba uczy­ni­ła z tego wzo­ru doku­men­tu wyma­ga­nie wobec opro­gra­mo­wa­nia ERP. Jak się nie trud­no domy­śleć, żaden ryn­ko­wy sys­tem nie ma takie­go doku­men­tu stan­dar­do­wo, dostaw­ca ERP uznał to wyma­ga­nie bez zastrze­żeń, co przy­czy­ni­ło się do wie­lu mody­fi­ka­cji opro­gra­mo­wa­nia tak­że w innych miej­scach, znacz­ne­go wzro­stu budże­tu (współ­dzie­lo­na baza danych pro­pa­gu­je zmia­ny prak­tycz­nie na całą apli­ka­cję). Nie będę tu opi­sy­wał dal­szych losów tego wzo­ru doku­men­tu bo celem moim było jedy­nie poka­za­nie pro­ble­mu na real­nym przykładzie.

Każdy pro­jekt, czy to wdro­że­nie nowych zasad zarzą­dza­nia czy nowe­go opro­gra­mo­wa­nia, zwią­za­ny z zarzą­dza­niem orga­ni­za­cją, to (powi­nien być) tak­że co naj­mniej prze­gląd doku­men­tów i ich obie­gu. Kluczowym ele­men­tem tego prze­glą­du powin­na być ana­li­za tre­ści tych doku­men­tów, ich opty­mal­ność, nie tyl­ko obie­gu ale tak­że tre­ści i jej struk­tu­ry. Owszem, wie­le doku­men­tów ma narzu­co­ną struk­tu­rę np. w odpo­wied­niej usta­wie, jed­nak są to mini­mal­ne zawar­to­ści (np. fak­tu­ra) nie ma zaka­zu uzu­peł­nie­nia tej struk­tu­ry i np. doda­nia do fak­tu­ry nume­ru zamó­wie­nia, z któ­rym jest związana.

Ogólnie moż­na okre­ślić pew­ne pra­wi­dło­wo­ści: jeże­li doku­men­ty są prze­cią­ża­ne tre­ścią, czy­li idzie­my w kie­run­ku małej ilo­ści doku­men­tów zawie­ra­ją­cych dużo danych, rośnie zło­żo­ność reguł pra­cy z takim doku­men­tem. Jeżeli zaś idzie­my w kie­run­ku doku­men­tów bar­dzo pro­stych”, rośnie ilość ich typów i rośnie licz­ba reguł koja­rzą­cych te doku­men­ty ze sobą w celu ich uży­cia. Ogólnie obra­zu­je to poniż­szy diagram:

Liczba dokumentów vs ilośc treści na nich

Tak więc skraj­nym roz­wią­za­niem będzie stwo­rze­nie jed­ne­go doku­men­tu, na któ­rym będą wszyst­kie infor­ma­cje np. zwią­za­ne z danym zamó­wie­niem. Drugą skraj­no­ścią jest podzie­le­nie infor­ma­cji na odręb­ne małe nie­po­dziel­ne już grup­ki, jak to ma miej­sce w znor­ma­li­zo­wa­nych rela­cyj­nych bazach danych. Jeżeli mega­do­ku­men­ty to raczej bar­dzo rzad­kie zja­wi­sko, to przy­pa­dek dru­gi jest dość powszech­ny. To co nazy­wa­my czę­sto doku­men­tem to tu tak na praw­dę nie­ist­nie­ją­cy byt w rela­cyj­nej bazie danych, gene­ro­wa­ny ad-hoc w locie” z sze­re­gu roz­drob­nio­nych tablic danych. Innymi sło­wy nie są to sta­łe struk­tu­ry” a pew­na okre­ślo­na zło­żo­na logi­ka, two­rzą­ca z pro­stych danych pobie­ra­nych z tablic, kon­kret­ne zesta­wy infor­ma­cji np. fak­tu­ry (to dla­te­go czę­sto w języ­ku dostaw­cy” fak­tu­ra to raport a nie doku­ment!). Ta zło­żo­na logi­ka reali­zo­wa­na jest (wyko­ny­wa­na w pamię­ci kom­pu­te­ra) za każ­dym razem gdy odwo­ła­my się do takie­go dokumentu.

Optymalna sytu­acja to rodzaj kom­pro­mi­su pomię­dzy zło­żo­no­ścią logi­ki two­rze­nia i korzy­sta­nia z doku­men­tu a jego zawar­to­ścią. Na powyż­szym dia­gra­mie jest to obszar sta­no­wią­cy oko­li­ce mini­mum krzy­wej opi­su­ją­cej zależ­ność pomię­dzy licz­bą doku­men­tów a zło­żo­no­ścią ope­ro­wa­nia nimi. Nie ma pro­stej regu­ły na opra­co­wy­wa­nie i opty­ma­li­za­cje tre­ści i licz­by doku­men­tów jed­nak są pew­ne spraw­dzo­ne dobre prak­ty­ki, a mia­no­wi­cie jeden doku­ment, o okre­ślo­nej struk­tu­rze, powi­nien zawie­rać dane o okre­ślo­nym zda­rze­niu w okre­ślo­nym kon­tek­ście [powsta­je teraz publi­ka­cja na ten temat, wyda­je się moż­na to jed­nak zde­fi­nio­wać, przyp auto­ra 2019]. Dokumenty te, podob­nie jak fak­ty któ­re doku­men­tu­ją, mogą mieć każ­dy wła­sny i róż­ny od innych cykl życia, dla­te­go czę­sto bywa bar­dzo szko­dli­we roz­dzie­la­nie” ich na pola bazy danych i pozby­cie się redundancji.

Przykładem mogą być: zamó­wie­nie jako udo­ku­men­to­wa­nie fak­tu zawar­cia umo­wy na dosta­wę, fak­tu­ra jako udo­ku­men­to­wa­nie fak­tu sprze­da­ży (prze­nie­sie­nia wła­sno­ści) oraz doku­ment WZ doku­men­tu­ją­cy fakt wyda­nia z maga­zy­nu okre­ślo­nych pro­duk­tów. Bardzo czę­sto spe­cy­fi­ka­cja tego co wyda­no z maga­zy­nu nie jest toż­sa­ma z tre­ścią fak­tu­ry (sprze­da­no odku­rzacz a wyda­no odku­rzacz i zapa­so­we wor­ki), na zamó­wie­niu mógł być wyszcze­gól­nio­ny odku­rzacz, wor­ki oraz wyma­ga­ne koń­ców­ki (któ­re są np. u pro­du­cen­ta pako­wa­ne w stan­dar­dzie więc nie ma ich ani na fak­tu­rze ani na WZ). Dlatego ma głę­bo­ki sens by te doku­men­ty były jed­nak osob­ny­mi doku­men­ta­mi” a nie zacho­wy­wa­ny­mi w bazie danych dany­mi jako odręb­ne pola pozba­wio­ne redun­dan­cji, wyma­ga­ją­ce skom­pli­ko­wa­nej logi­ki (pole­ce­nia SQL) by je (te doku­men­ty”) poka­zać na ekra­nie czy wydrukować.

To dość try­wial­ny przy­kład, bo opi­sa­ne doku­men­ty są wyma­ga­ne prze­pi­sa­mi jako dowo­dy księ­go­we, jed­nak każ­da więk­sza orga­ni­za­cja ma swo­je wewnętrz­ne doku­men­ty, na któ­rych ilość i treść ma peł­ny wpływ. Po dru­gie nawet te doku­men­ty są czę­sto wła­śnie zapi­sy­wa­ne w rela­cyj­nych bazach danych jako roz­pro­szo­ne po małych tabe­lach dane, wyma­ga­ją­ce skom­pli­ko­wa­nych ope­ra­cji łącze­nia w jeden doku­ment”, każ­do­ra­zo­wo przy pró­bie jego uży­cia. Tu zacho­dzi bar­dzo duże ryzy­ko, że postać i treść takie­go doku­men­tu ule­gnie zmia­nie np. po reor­ga­ni­za­cji bazy danych. Takich doku­men­tów” nie da się (w tej posta­ci) pod­pi­sać elek­tro­nicz­nie, bo one po pro­tu fizycz­nie na praw­dę nie istnieją.

A jak ina­czej? Nie ma żad­ne­go pro­ble­mu by dowol­ny doku­ment sta­no­wił sobą jed­no­li­ty byt np. zestaw danych w for­ma­cie XML, sko­ja­rzo­ny ewen­tu­al­nie ze swo­ją posta­cią goto­wą do dru­ku albo np. plik PDF sko­ja­rzo­ny z meta­da­ny­mi opi­su­ją­cy­mi go (wybór jest na praw­dę duży). Nie nale­ży zapo­mi­nać, że poza doku­men­ta­mi, któ­re są two­rzo­ne w orga­ni­za­cji ope­ru­je­my doku­men­ta­mi obcy­mi, otrzy­ma­ny­mi z zewnątrz i wypa­da­ło by mieć taki doku­ment w posta­ci takiej jaką prze­słał nam ich twór­ca. Owszem poja­wia się redun­dan­cja danych ale ona nie sta­no­wi sobą nic złe­go. Ogromną korzy­ścią takie­go podej­ścia jest roz­wią­za­nie pro­ble­mu pole­ga­ją­ce­go na nie­moż­no­ści roz­dzie­le­nia doku­men­tów” i logi­ki ope­ro­wa­nia nimi jeże­li są zapi­sa­ne w posta­ci odręb­nych pól w rela­cyj­nej bazie danych. Np. sta­je się nie­moż­li­we pozo­sta­wie­nie fak­tur i wynie­sie­nie doku­men­tów maga­zy­no­wych do odręb­ne­go sys­te­mu (w tym zmia­na ich struk­tu­ry) co ma miej­sce nie raz przy wdra­ża­niu sys­te­mów WMS (sys­te­my logi­stycz­no-maga­zy­no­we). Takie ope­ra­cji pra­wie żaden duży zin­te­gro­wa­ny ERP nie wytrzy­ma (usły­szy­my raczej, że my dosto­su­je­my do Państwa potrzeb nas moduł magazynowy…).

Podejście takie ma tak­że inna cie­ka­wą zale­tę: jeże­li udo­ku­men­tu­je­my osob­no struk­tu­ry doku­men­tów i logi­kę ope­ro­wa­nia nimi (tak­że ich two­rze­nia), to otrzy­ma­my obiek­to­wy model orga­ni­za­cji: model poka­zu­ją­cy wza­jem­ną współ­pra­cę obiek­tów biz­ne­so­wych (doku­men­tów) odpo­wie­dzial­nych za prze­cho­wy­wa­nie infor­ma­cji, obiek­tów odpo­wie­dzial­nych za reje­stro­wa­nie tych infor­ma­cji, obiek­tów mają­cych wie­dzę jak ope­ro­wać tymi infor­ma­cja­mi, obiek­tów udo­stęp­nia­ją­cych to wszyst­ko zgod­nie z okre­ślo­ną logi­ką. Poniżej obiek­to­wy model na któ­rym od pra­wej mamy: doku­men­ty z ich tre­ścią oraz logi­kę ich two­rze­nia i udo­stęp­nia­nia (repo­zy­to­ria czy­li kuwet­ki na doku­men­ty), logi­kę korzy­sta­nia z infor­ma­cji w repo­zy­to­riach, tak­że ich wza­jem­ne­go koja­rze­nia (samo­dziel­ne usłu­gi) oraz logi­kę dostę­pu do tego sys­te­mu (reali­za­cja sce­na­riu­szy przy­pad­ków uży­cia). Jeżeli w toku ana­li­zy uzna­my, że jakieś ele­men­ty tej logi­ki to zada­nia pod­da­ją­ce się w 100% algo­ryt­mi­za­cji, to poniż­szy model jest jed­no­cze­śnie mode­lem logi­ki apli­ka­cji i nazy­wa­my go Modelem Dziedziny Systemu. Nie jest to abso­lut­nie żad­na baza danych, poniż­sze repo­zy­to­ria nicze­go nie współ­dzie­lą (moż­na je w dowol­nym momen­cie zamie­niać na inne bez kon­se­kwen­cji dla resz­ty systemu).

Obiektowy model dziedziny Zasada SOLID

Model ten powstał z uży­ciem blo­ków funk­cjo­nal­nych wzor­ca BCE (opi­sa­łem go tu: Wzorzec ana­li­tycz­ny Boundary Control Entity). Dla wyja­śnie­nia: powyż­szy dia­gram to w peł­ni popraw­ny Model dzie­dzi­ny wyko­na­ny z uży­ciem dia­gra­mu klas UML, kla­sy mają ste­reo­ty­py boun­da­ry, con­trol i enti­ty (powy­żej od lewej do pra­wej), ste­reo­ty­py te są repre­zen­to­wa­ne sym­bo­la­mi opi­sa­ny­mi (iko­na­mi) w BCE. (Źródło: Krzywe i kosz­ty? archi­tek­tu­ry | | Jarosław Żeliński IT-Consulting

Prawie zawsze obser­wu­ję, że pod­sta­wo­wym domyśl­nym zało­że­niem wdro­żeń sys­te­mów wspo­ma­ga­ją­cych zarzą­dza­nie, jest uzna­nie a prio­ri nie­zmien­no­ści struk­tu­ry i wzo­rów dokumentów. 

Z doświad­cze­nia mogę powie­dzieć, że ana­li­za i opty­ma­li­za­cja tre­ści doku­men­tów wewnętrz­nych może przy­nieść bar­dzo duże korzy­ści prze­kła­da­ją­ce się na duży wzrost wewnętrz­nej efek­tyw­no­ści i jako­ści pra­cy, a w przy­pad­ku wdro­żeń opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzą­dza­nie, pozwa­la nie raz cał­ko­wi­cie unik­nąć bar­dzo kosz­tow­nych i ryzy­kow­nych kasto­mi­za­cji. Zaryzykuje tezę, że kil­ka pro­jek­tów w ten spo­sób wręcz uratowałem… 

Plansza do gry w szachy czyli analiza i projektowanie

Na ten wpis pew­nie wie­lu z Was cze­ka, tak przy­naj­mniej suge­ru­ją listy do mnie i gło­sy na forach, a tak­że poten­cjal­ni klien­ci. Ci, któ­rych nie­ste­ty cza­sem kry­ty­ku­ję, tak­że pew­nie cze­ka­ją. Pokażę na pro­stym przy­kła­dzie, pro­ces od ana­li­zy przez wyma­ga­nia aż do pro­jek­tu dedy­ko­wa­ne­go opro­gra­mo­wa­nia. Całość będzie zgod­na z faza­mi CIM/PIM (www​.omg​.org/​mda). Projekt dzie­dzi­ny, któ­ry powsta­nie będzie speł­niał zasa­dy SOLID pro­jek­to­wa­nia obiek­to­we­go, pro­jek­to­wa­nia przez kom­po­zy­cje (zamiast dzie­dzi­cze­nia) (pole­cam arty­kuł Łukasza Barana) i DDD. Opis doty­czy każ­de­go pro­jek­tu zwią­za­ne­go z opro­gra­mo­wa­niem, tak­że goto­wym np. ERP, CRM, EOD itp.

Korzystałem z opi­su zasad gry w sza­chy zamiesz­czo­ne­go na WIKI:

Zasady gry w sza­chy ? pra­wi­dła regu­lu­ją­ce spo­sób roz­gry­wa­nia par­tii sza­chów. Choć pocho­dze­nie gry nie zosta­ło dokład­nie wyja­śnio­ne, to współ­cze­sne zasa­dy ukształ­to­wa­ły się w śre­dnio­wie­czu. Ewoluowały one do począt­ków XIX wie­ku, kie­dy to osią­gnę­ły wła­ści­wie swą bie­żą­cą postać. W zależ­no­ści od miej­sca zasa­dy gry róż­ni­ły się od sie­bie, współ­cze­śnie za prze­pi­sy gry odpo­wia­da Międzynarodowa Federacja Szachowa (Fédération Internationale des Échecs, FIDE). Przepisy te mogą się róż­nić w przy­pad­ku róż­nych warian­tów gry, np. dla sza­chów szyb­kich, bły­ska­wicz­nych czy kore­spon­den­cyj­nych. (Zasady gry w sza­chy ? Wikipedia, wol­na ency­klo­pe­dia).

To na co chcę zwró­cić tu uwa­gę w szcze­gól­no­ści, to metafora:

pro­jek­tu­jąc (mode­lu­jąc) opro­gra­mo­wa­nie dla czło­wie­ka, mode­lu­je­my narzę­dzie dla tego czło­wie­ka a nie jego samego.

Swego cza­su pisa­łem, w arty­ku­le o nazy­wa­niu klas, że opro­gra­mo­wa­nie z regu­ły zastę­pu­je dotych­cza­so­we narzę­dzie czło­wie­ka a nie czło­wie­ka jako takie­go. Druga waż­na rzecz: aktor jest rów­no­praw­nym ele­men­tem sys­te­mu (tu sys­te­mem jest orga­ni­za­cja z jej ludź­mi i uży­wa­ny­mi przez nich narzę­dzia­mi). No to zaczynamy.

Czytaj dalej… Plansza do gry w sza­chy czy­li ana­li­za i pro­jek­to­wa­nie”

Analiza wymagań – zrozumienie

Dzisiaj krót­ki arty­kuł o wyma­ga­niach dzie­dzi­no­wych. W jed­nym z poprzed­nich arty­ku­łów pisa­łem o wyma­ga­niach, że pro­blem tkwi w ich zro­zu­mie­niu i o tym, że przy­szły użyt­kow­nik nie powi­nien pisać jaki ma być ten pro­gram”, bo popy­cha pro­jekt w stro­nę cha­otycz­nych oczekiwań.

I tu jest sed­no: ana­li­za nie powin­na być tyl­ko pasmem wywia­dów, któ­re­go pro­duk­tem będę set­ki stron zapi­sów z ankiet i prze­pro­wa­dzo­nych roz­mów. Analiza, to duża pra­ca, któ­rej celem powin­no być zro­zu­mie­nie a nie tyl­ko opi­sa­nie. (Analiza wyma­gań na opro­gra­mo­wa­nie czy­li opi­sa­nie czy zro­zu­mie­nie).

Wymagania naj­czę­ściej dzie­li­my na funk­cjo­nal­ne i poza-funk­cjo­nal­ne. Warto jed­nak upo­rząd­ko­wać pro­jekt i ukie­run­ko­wać ana­li­zę naj­pierw na wyma­ga­nia biz­ne­so­we a potem do już wymie­nio­nych dodać wyma­ga­nia dzie­dzi­no­we. Te ostat­nie są tak na praw­dę wydzie­le­niem z cha­osu ocze­ki­wań cze­goś co nazwę jak to jest robio­ne” ale nie w kon­tek­ście opro­gra­mo­wa­nia (pro­gra­mi­ści wie­dzą jak pro­gra­mo­wać), a w kon­tek­ście reguł biz­ne­so­wych i decy­zyj­nych (wie­dzy o tym jak się rze­czy dzieją).

Oprogramowania bez­po­śred­nio doty­czą tyl­ko wyma­ga­nia funk­cjo­nal­ne, poza-funk­cjo­nal­ne i dzie­dzi­no­we. Wymagania biz­ne­so­we to cele jakie ma przed sobą orga­ni­za­cja, dla któ­rej ma powstać (ma zostać jej dostar­czo­ne) opro­gra­mo­wa­nie. Zresztą, nie nale­ży o tym zapo­mi­nać, że może ist­nieć inne roz­wią­za­nie pro­ble­mu orga­ni­za­cji, niż oprogramowanie.

Oprogramowanie pro­jek­to­wa­ne meto­da­mi obiek­to­wy­mi wg. naj­lep­szych prak­tyk i wzor­ców ma nastę­pu­ją­ca strukturę:

Model systemu wymagania

Aktor to oczy­wi­ście jego użyt­kow­nik. Oprogramowanie, jako narzę­dzie pra­cy, świad­czy usłu­gi jego użyt­kow­ni­kom – akto­rom, jest ich narzę­dziem pra­cy. Oprogramowanie zawiera:

  1. kla­sy (struk­tu­ry opro­gra­mo­wa­nia) odpo­wia­da­ją­ce za jakość świad­czo­nych usług, to kla­sy reali­zu­ją­ce przy­pad­ki uży­cia tego oprogramowania,
  2. kla­sy (struk­tu­ry opro­gra­mo­wa­nia) odpo­wia­da­ją­ce za logi­kę biznesową,
  3. kla­sy (struk­tu­ry opro­gra­mo­wa­nia) odpo­wia­da­ją­ce za utrwa­la­nie infor­ma­cji (obiek­ty biznesowe).

Wymagania to warun­ki jakie ma speł­niać opro­gra­mo­wa­nie by było przy­dat­ne. Tak więc Analityk biz­ne­so­wy powi­nien zro­zu­mieć jak dzia­ła orga­ni­za­cja, zde­fi­nio­wać narzę­dzie jakie jej pomo­że, opi­sać wyma­ga­nia na to narzę­dzie. Jak? Powiem ina­czej, nie jest rolą pro­gra­mi­stów odkry­wa­nie” logi­ki biz­ne­so­wej, pro­gra­mi­sta odpo­wia­da za jej imple­men­ta­cję. Dlatego war­to pamię­tać o wyma­ga­niach dzie­dzi­no­wych… nie jest to nie­ste­ty miej­sce na szcze­gó­ło­wy ich opis, tu zapra­szam na szko­le­nie o wyma­ga­niach, któ­re pro­wa­dzę.

Praktyka nie­ste­ty poka­zu­je, że zapis ocze­ki­wań użyt­kow­ni­ka i prze­ka­za­nie ich pro­gra­mi­stom to dro­ga na manow­ce… Oczekiwania w rodza­ju roz­wi­ja­ne listy, mysz­ko­lo­gia”, łatwe w uży­ciu ekra­ny” i cała masa innych szcze­gó­łów nijak się ma do tego jak to opro­gra­mo­wa­nie ma dzia­łać. To tyl­ko cechy użyt­ko­we inter­fej­su użyt­kow­ni­ka, te jed­nak bez wewnętrz­nej logi­ki po pierw­sze o niczym nie mówią, a po dru­gie i tak są efek­tem goto­wych ele­men­tów z jakich budu­je się inter­fejs użyt­kow­ni­ka. Warto o ich wspo­mnieć by zama­wia­ją­cy miał ich świa­do­mość ale nie oszu­kuj­my się, opi­su­je­my tak tyl­ko to co zna­my już z innych apli­ka­cji a to w pew­nym sen­sie stan­dard (np. doty­ko­wy ekran smart­fo­na czy tabletu).

Zapisanie zaś, że sys­tem ma pozwa­lać na dobór pro­mo­cji dla klien­tów o róż­nych pozio­mach zaku­pów, po pierw­sze nic nie mówi, po dru­gie wyma­ga ana­li­zy o co cho­dzi” i są to wła­śnie wyma­ga­nia dzie­dzi­no­we­go. Wymaganiem funk­cjo­nal­nym będzie tu to: System pozwa­la na zarzą­dza­nie listą upu­stów. W języ­ku pol­skim i nie tyl­ko funk­cja to zada­nie, któ­re speł­nia lub ma speł­nić jakaś oso­ba lub rzecz. Innymi sło­wy wyma­ga­nie funk­cjo­nal­ne to to do cze­go ma słu­żyć opro­gra­mo­wa­nie a nie to jak ma to robić.

Przypomnę na zakoń­cze­nie: powyż­sze to tyl­ko pew­ne dobre prak­ty­ki 🙂 bazu­ją­ce na meto­dach obiek­to­wych (a w zasa­dzie takie głów­nie są teraz a w uży­ciu) i wzor­cach projektowych.

Wymagania biznesowe a wymagania wobec produktu – rola analityka

Na począ­tek histo­ryj­ka. Stolarz ma zwy­kły mło­tek, któ­re­go uży­wa do wbi­ja­nia gwoź­dzi. Prosty mło­tek to trzo­nek i pro­sty pobi­jak. W mia­rę roz­wo­ju fir­my poja­wia się pro­blem: sto­la­rze mają pro­blem z otwar­ciem piwa pod­czas pra­cy, zaczy­na­ją szu­kać spo­so­bu, czę­sto odbi­ja­ją kap­sle młot­kiem, nie raz uszka­dza­jąc butel­kę. Z uszko­dzo­nej butel­ki picie jest nie­bez­piecz­ne więc odpo­wie­dzial­ni pra­cow­ni­cy, w takich przy­pad­kach, muszą iść do skle­pu po dru­gie piwo. Powoduje to stra­tę cza­su i spa­dek wydaj­no­ści. Pojawia się wyma­ga­nie biz­ne­so­we: popra­wić wydaj­ność sto­la­rzy w pro­ce­sie prac budow­la­nych. Strategia: uspraw­nić narzę­dzia. Taktyka: zapro­jek­to­wać mło­tek, któ­ry nie uszka­dza kap­slo­wa­nych bute­lek pod­czas otwierania.

Analityk musi zro­zu­mieć pro­blem i zapro­po­no­wać rozwiązanie

No to do robo­ty: czyn­no­ści wyko­ny­wa­ne przez sto­la­rzy w pro­ce­sie kon­stru­owa­nia drew­nia­nych kon­struk­cji to wbi­ja­nie gwoź­dzi (czy­li ogól­nie pobi­ja­nie”) oraz otwie­ra­nie kap­slo­wa­nych bute­lek z piwem. Obie czyn­no­ści ma reali­zo­wać mło­tek” (przy­ję­ta tak­ty­ka roz­wią­za­nia pro­ble­mu). Czynności te więc sta­ją jego, młot­ka, przy­pad­ka­mi użycia.

Młotek świad­czy jed­ną usłu­gę: wspar­cie sto­la­rza w czyn­no­ściach, któ­rych nie moż­na wyko­nać dłoń­mi. Decydujemy (decy­zja pro­jek­to­wa), że oba przy­pad­ki uży­cia (usłu­gę tę) będzie reali­zo­wa­ła głów­ka młot­ka (kla­sa usłu­go­wa), a nie np. trzo­nek zakoń­czo­ny otwie­ra­czem. Tak więc na bazie wyko­ny­wa­nych czyn­no­ści i wie­dzy, że ma to być to samo narzę­dzie pra­cy, uzna­je­my, że mło­tek ma mieć dwa przy­pad­ki uży­cia: pobi­ja­nie oraz odkap­slo­wa­nie. Projektujemy mło­tek, model dzie­dzi­ny ma dwie kla­sy: trzo­nek i głów­ka. Główka to usłu­go­wa kla­sa i będzie mia­ła dwie ope­ra­cje: pobi­ja­nie i otwie­ra­nie kap­slo­wa­nych bute­lek.
Implementacja (obraz po lewej) to dzie­ło pro­du­cen­ta narzę­dzi: mło­tek typu dru­gie­go. Jak widać głów­ka świad­czy usłu­gę (trwa­ły meta­lo­wy ele­ment robo­czy) uży­tecz­ną do pobi­ja­nia i otwie­ra­nia bute­lek (ma dwie operacje).

Co więc mamy? Wymaganie biz­ne­so­we, pro­dukt wraz z tym jakie usłu­gi potra­fi świad­czyć, przy­pad­ki uży­cia czy­li to, do cze­go fak­tycz­nie moż­na (chce­my) użyć tego młot­ka oraz pro­jekt realizacji.

Czynności w pro­ce­sie biz­ne­so­wym (model biz­ne­so­wy) mapu­ją się na przy­pad­ki uży­cia pro­duk­tu (model – [[pro­jekt jako czar­na skrzyn­ka]] – tego produktu).

Jednak nicze­go nie wie­my o tym, co nale­ży zro­bić do cza­su, gdy ktoś nie opra­cu­je pro­jek­tu pro­duk­tu. Autor pomy­słu zawarł w pro­jek­cie dwa ele­men­ty: trzo­nek i dwu-funk­cyj­ną głów­kę czy­li dwie kla­sy dzie­dzi­no­we i ich ope­ra­cje (głów­ka: Uderz oraz Zerwij kap­sel i trzo­nek: połącz dłoń z głów­ką młot­ka). Implementacja (design, dobór mate­ria­łów itp. to inży­nier­ska robo­ta” czy­li reali­za­cja pro­jek­tu. Tu są reali­zo­wa­ne wyma­ga­nia poza-funk­cjo­nal­ne np. mło­tek ma wytrzy­my­wać 1 mln. ude­rzeń, nie może ważyć wię­cej niż 1,5 kg.

Można było sto­la­rza zaopa­trzyć w stan­dar­do­wy otwie­racz do bute­lek, jed­nak mamy tu ogra­ni­cze­nie stra­te­gicz­ne: nie chce­my powięk­szać licz­by przed­mio­tów w wypo­sa­że­niu sto­la­rza. Tak więc tak­ty­ka musia­ła być taka jaką tu wybrano.

Mam nadzie­ję, że ten pro­sty przy­kład obra­zu­je tak­so­no­mię” (kla­sy­fi­ka­cję) wyma­gań. Sam kie­dyś mie­wa­łem z tym pro­blem, szcze­gól­nie gdy pro­jekt się rozrastał.

Problemem więk­szo­ści pro­jek­tów pro­gra­mi­stycz­nych jest nie tyle lista wyma­gań (choć może być nie­kom­plet­na lub nie­spój­na, jeże­li powsta­nie jako dekla­ra­tyw­na lista ręka­mi pra­cow­ni­ków), pro­ble­mem pro­jek­to­wym jest zamia­na wyma­gań na usłu­gi sys­te­mu i pro­jekt ich realizacji.

Co więc mamy w pro­jek­tach, któ­rych celem jest dostar­cze­nie oprogramowania:

  1. wyma­ga­nia biz­ne­so­we – wyma­ga­nia wzglę­dem nowe­go lub zmie­nia­ne­go mode­lu biz­ne­so­we­go lub stra­te­gii czy­li co chce­my osią­gnąć w orga­ni­za­cji,
  2. wyma­ga­nia pro­duk­to­we – to cze­go ocze­ku­je­my od nowe­go pro­duk­tu (narzę­dzia pra­cy) czy­li jak to chce­my osią­gnąć (zapa­dła ewen­tu­al­na decy­zja o potrze­bie posia­da­nia sto­sow­ne­go produktu),
  3. usłu­gi pro­duk­tu – to co pro­dukt potra­fi zro­bić dla jego użyt­kow­ni­ka czy­li co pro­dukt powi­nien umieć”,
  4. pro­ces biz­ne­so­wy – lista czyn­no­ści jakie wyko­nu­ją przy­szli użyt­kow­ni­cy pro­duk­tu czy­li kie­dy będzie­my uży­wać pro­duk­tu,
  5. przy­pad­ki uży­cia wywo­dzo­ne z pro­ce­sów – to do cze­go użyt­kow­nik chce użyć pro­duk­tu,
  6. model pro­duk­tu – struk­tu­ra opi­su­ją­ca wewnętrz­ne ele­men­ty pro­duk­tu (modu­ły) i ich moż­li­wo­ści (ope­ra­cje jakie potra­fią wyko­nać) oraz ich wza­jem­ną współ­pra­cę (sce­na­riu­sze współ­dzia­ła­nia), pozwa­la­ją­cą na wyko­na­nie usłu­gi (zre­ali­zo­wa­nie kolej­nych przy­pad­ków uży­cia) czy­li jak powi­nien być skon­stru­owa­ny pro­dukt (jego obiek­to­wy model – dzie­dzi­na sys­te­mu); model pro­duk­tu to wyma­ga­nia dzie­dzi­no­we.
Tu pora na kon­klu­zję: wyma­ga­nia wyma­ga­niom nie­rów­ne, nie impli­ku­ją tak­że roz­wią­za­nia i jego jako­ści, więc jedy­nym spo­so­bem jed­no­znacz­ne­go zamó­wie­nia” opro­gra­mo­wa­nia jest opi­sa­nie tego jak powi­nien być skon­stru­owa­ny pro­dukt.

Odpowiedzialność za wyma­ga­nia w pro­jek­tach programistycznych

Projekty pro­gra­mi­stycz­ne i ana­li­za poprze­dza­ją­ca ich reali­za­cję, powin­ny być dosto­so­wa­ne (poczy­nio­ne pew­ne zało­że­nia) do dostęp­nej na ryn­ku tech­no­lo­gii i metod wytwa­rza­nia opro­gra­mo­wa­nia. Wśród nich są meto­dy obiek­to­we ana­li­zy i pro­jek­to­wa­nia oraz obiek­to­we języ­ki pro­gra­mo­wa­nia i szkie­le­ty opro­gra­mo­wa­nia (fra­me­wor­ki), pozwa­la­ją­ce na imple­men­ta­cję pro­jek­tów wyko­na­nych w obiek­to­wym paradygmacie.

Wydaje się, że obiek­to­we meto­dy są naj­sku­tecz­niej­sze w przy­pad­ku opro­gra­mo­wa­nia dla biz­ne­su. Bardzo popu­lar­ny i chy­ba naj­star­szy obiek­to­wy wzo­rzec pro­jek­to­wy to wzo­rzec [[Model, View, Controller (MVC)]]. W dużym uproszczeniu:

  • Model opi­su­je dzie­dzi­nę systemu,
  • View opi­su­je to co widzi użytkownik,
  • Control­ler ste­ru­je tym wszystkim.

Stosuję ten wzo­rzec do podzia­łu zadań (odpo­wie­dzial­no­ści) w pro­jek­tach z nastę­pu­ją­cy­mi konsekwencjami:

  1. View (widok): klient zama­wia” for­mu­larz (papier/ekran), bo klient wie co chce mieć”,
  2. Analityk two­rzy Model Dziedziny: 100% obiek­tów dzie­dzi­no­wych z regu­ła­mi (atry­bu­ty i ope­ra­cje biznesowe),
  3. Analityk dostar­cza listę wyma­gań poza-funk­cjo­nal­nych (ocze­ki­wa­ne wydaj­ność, bez­pie­czeń­stwo, dostęp­ność itp.),
  4. Developer imple­men­tu­je Model Dziedziny two­rząc opro­gra­mo­wa­nie, z pomo­cą uży­wa­ne­go szkie­le­tu opro­gra­mo­wa­nia roz­wią­zu­je pro­ble­my poza-funk­cjo­nal­ne lub zgła­sza ogra­ni­cze­nia ich realizacji.

I tak mamy: 100% inter­fej­su użyt­kow­ni­ka zama­wia użyt­kow­nik (sam lub z pomo­cą spe­cja­li­stów), 100% wyma­gań funk­cjo­nal­nych reali­zu­je Model Dziedziny (pro­jekt ana­li­ty­ka-pro­jek­tan­ta), 100% wyma­gań poza-funk­cjo­nal­nych reali­zu­je deve­lo­per (pro­jekt i imple­men­ta­cja). Developer tak­że imple­men­tu­je model dzie­dzi­ny z pomo­cą tech­no­lo­gii jakiej używa.

A jeże­li klient powie: nie mamy tych wzo­rów doku­men­tów i ekra­nów! To pierw­szy sygnał, że nie ma pod­staw do zama­wia­nia jakie­go­kol­wiek opro­gra­mo­wa­nia, bo naj­pierw trze­ba wie­dzieć co się chce”.

Jak to zro­bić? Tu kła­nia się ana­li­za biz­ne­so­wa: mode­lu­je­my pro­ce­sy biz­ne­so­we, dla każ­de­go z nich usta­la­my wej­ście oraz efekt (pro­dukt) czy­li wła­śnie owe wzo­ry doku­men­tów”. Po upo­rząd­ko­wa­niu tego i upew­nie­niu się, że nie ma w tym bała­ga­nu (powtór­ki, bra­ki, nie­kon­se­kwen­cje, sprzecz­no­ści itp.) może­my pytać o goto­we opro­gra­mo­wa­nie lub zama­wiać” jego wytwo­rze­nie. Produktem pra­cy ana­li­ty­ka powin­ny być, poza mode­la­mi pro­ce­sów bo one są narzę­dziem a nie celem, obiek­to­wy model dzie­dzi­ny czy­li model tego jaki­mi infor­ma­cja­mi i jak zor­ga­ni­zo­wa­ny­mi ope­ru­je orga­ni­za­cja, oraz to jak pra­cow­ni­cy tej orga­ni­za­cji chcą się komu­ni­ko­wać z opro­gra­mo­wa­niem (źro­dłem infor­ma­cji jest jed­nak klient).

Mamy czy­sty podział odpo­wie­dzial­no­ści i łatwość roz­li­cze­nia pro­jek­tu. Na czym pole­ga haczyk? Klient nie może uni­kać odpo­wie­dzial­no­ści za skut­ki swo­ich decy­zji i udzie­la­nych infor­ma­cji. Ale też, co jest klu­czo­we: Analityk musi zro­zu­mieć pro­blem i zapro­po­no­wać rozwiązanie. 

Jednak nie jest rolą ana­li­ty­ka wyko­na­nie opro­gra­mo­wa­nia! To jak – tech­no­lo­gia – ma to zostać zre­ali­zo­wa­ne” jest decy­zją deve­lo­pe­ra. Ma dużo pra­cy. Nie zapo­mi­naj­my, że kod reali­zu­ją­cy tak zwa­ną logi­kę biz­ne­so­wą to led­wie kil­ka pro­cent cało­ści kodu apli­ka­cji, jed­nak nie zapo­mi­naj­my tak­że (pro­gra­mi­ści), że zła logi­ka biz­ne­so­wa dys­kwa­li­fi­ku­je całe to opro­gra­mo­wa­nie z pro­ste­go powo­du: sta­je się nieprzydatne.

___

Po wie­lu dys­ku­sjach na szko­le­niach pre­zen­tu­ję zgod­ny z UML dia­gram przy­pad­ków uży­cia dla młotka: