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

Teoria a praktyka – czyli kompetencyjna tragedia

Od cza­su do cza­su spo­ty­kam się w pro­jek­tach z taki­mi oto teza­mi, wypo­wia­da­ny­mi przez kie­row­ni­ków pro­jek­tów, głów­nych archi­tek­tów itp.:

Wiedza aka­de­mic­ka to jed­no a wie­dza prak­tycz­na to dru­gie 😉 Nie da się tego połączyć :(„

To objaw tra­ge­dii kom­pe­ten­cyj­nej… takie zda­nie może wypo­wie­dzieć tyl­ko kom­plet­ny igno­rant, któ­re­go jedy­ną kom­pe­ten­cją (bo zakła­dam, że jakąś musi mieć, sko­ro zaj­mu­je to sta­no­wi­sko) jest chy­ba peł­na lojal­ność wobec pra­co­daw­cy i sku­tecz­ne wycią­ga­nie pro­to­ko­łów odbio­ru z klien­tów (czy­taj wycią­ga­nie pie­nię­dzy), nie dam gło­wy jak z ety­ką pracy.

Co jakiś czas czy­ta­my o poraż­kach pro­jek­tów w sfe­rze publicz­nej, zapew­niam, że są one nie takim rzad­kim zja­wi­skiem w sfe­rze pry­wat­nej. Dlaczego nie czy­ta­my o tym? Bo, na szczę­ście dla firm pry­wat­nych, nie doty­czy ich usta­wa o dostę­pie do infor­ma­cji publicz­nej itp., pro­jekt naby­wa sta­tus tajem­ni­ca kor­po­ra­cji„ « i nikt nie wie poza tymi, co bra­li udział w projekcie.

Miewam kon­sul­ta­cje, kore­pe­ty­cje, coaching itp. Pytany jestem czę­sto: czy zda­rza się Panu w pro­jek­tach, że np. kie­row­nik pro­jek­tu mówi, że nie waż­na jest jakość tych pro­jek­tów tyl­ko ter­min i pro­to­kół odbio­ru, klient i tak nie potra­fi tego skon­tro­lo­wać”. Powiem tak, zda­rza mi się i wte­dy – o ile to ja nie nad­zo­ru­je pro­jekt po stro­nie kupu­ją­ce­go – odma­wiam albo rezy­gnu­je z udzia­łu w pro­jek­cie, jed­nak ja nie mam umo­wy o pra­ce i nie jestem nią szan­ta­żo­wa­ny (jej utra­tą). Prawdę mówiąc nie wiem co mam tym ludziom mówić, poza powyż­szym oczy­wi­ście, ale i tak zawsze mówię: bądź uczci­wy (co jest bar­dzo trudne).

Ale co z ta teo­rią i prak­ty­ką? To trosz­kę jak z samo­cho­dem, wie­lu ludzi nimi jeź­dzi ale nie każ­dy rozu­mie dzia­ła­nie skrzy­ni bie­gów. Wielu ludzi wyuczy­ło się przy jakiej pręd­ko­ści zmie­niać bieg na wyż­szy, kie­dy redu­ko­wać, ale już nie każ­dy wie jak się zacho­wać jadąc pod gór­kę, z gór­ki, co to jest hamo­wa­nie sil­ni­kiem i kie­dy się to robi, dla­cze­go chcąc przy­śpie­szyć wrzu­ca­my wyż­szy bieg póź­niej… aby to wie­dzieć, nale­ży rozu­mieć. Dlatego wie­lu ludzi bez pro­ble­mu jeź­dzi samo­cho­dem do pra­cy czy na wcza­sy, ale już nie tak wie­lu radzi sobie z sytu­acja­mi nietypowymi…

Owszem moż­na się wie­lu rze­czy nauczyć na pamięć i teo­ria tu nie jest potrzeb­na, ale pro­stych sytu­acji na dro­dze jest mało, owszem są to te naj­pow­szech­niej­sze ale tyl­ko te. Każdy nie­try­wial­ny przy­pa­dek wyma­ga… no cze­go? Na pamięć? Nie – zro­zu­mie­nia tego czym się zaj­mu­je­my. Człowiek ma ogra­ni­czo­ne moż­li­wo­ści zapa­mię­ty­wa­nia, para­dok­sal­nie to, cze­go uży­wa­my rzad­ko, szyb­ko ula­tu­je z naszej gło­wy, to natu­ral­ny mecha­nizm mózgu.

Dlatego, nie­ste­ty, wie­dza teo­re­tycz­na, rozu­mie­nie, to pod­sta­wa w każ­dym nie­try­wial­nym pro­jek­cie. Nauka na pamięć to bar­dzo ogra­ni­czo­ne moż­li­wo­ści, ruty­niar­stwo i zupeł­ny brak moż­li­wo­ści roz­wią­zy­wa­nia nowych pro­ble­mów. Zrozumienie powo­du­je, że nicze­go nie musi­my się uczyć na pamięć i radzi­my sobie w nowych sytu­acjach, tak samo jak ze skrzy­nią bie­gów: kto rozu­mie temu nie gaśnie sil­nik… kto nie rozu­mie – zawsze będzie zwy­kłym kierowcą”…

kamien przepowiada pogode

Ignorowanie wie­dzy aka­de­mic­kiej, jest przy­czy­ną więk­szo­ści pora­żek, bar­dzo wie­le pro­jek­tów IT to jak lecze­nie ludzi przez zna­cho­rów: nie ma poję­cia o ana­to­mii i wpły­wie sub­stan­cji che­micz­nych na ludzi ale z upo­rem mania­ka ser­wu­je ludziom pijaw­ki, suple­men­ty, pseu­do­le­ki, upusz­cza­nie krwi itp. wie­lu z takich zna­cho­rów do koń­ca życia uwa­ża, że aka­de­mia medycz­na szko­dzi i tych leka­rzy” nale­ży się bać…

Zacytuję: praw­dzi­wa wie­dza to zna­jo­mość przy­czyn” (Arystoteles), bez tego wie­lu PM,ów dosko­na­le ope­ru­je ryzy­ka­mi oce­nia­ny­mi z ich boga­te­go doświad­cze­nia ale nie ma bla­de­go poję­cia od cze­go one zale­żą… tak powsta­ła cała AGILE meto­dy­ka: reagu­je­my na to co zaob­ser­wu­je­my, dokład­nie tak jak góra­le pro­gno­zu­ją pogodę…

Swego cza­su pewien, jak sam o sobie mówi, bar­dzo doświad­czo­ny tester opro­gra­mo­wa­nia (czy­taj dłu­go pra­cu­je) napi­sał do mnie, że dobre testy to … i tu lita­nia metod. Doskonale rozu­miem spoj­rze­nie tego teste­ra, takie «kom­pe­ten­cje” widu­ję czę­sto. Z per­spek­ty­wy teste­ra w zasa­dzie ma on rację twier­dząc, że pod­no­sze­nie jako­ści opro­gra­mo­wa­nia to pod­no­sze­nie jako­ści testów”. Zapomniał jed­nak, że są dwa spo­so­by na pod­no­sze­nie jakości:

  1. coraz sku­tecz­niej­sze wykry­wa­nie błędów
  2. robie­nie coraz mniej­szej ilo­ści błędów

Niestety w gestii teste­ra leży wyłącz­nie to pierw­sze i tu go rozumiem.…ale dodam, że dru­gie jest znacz­nie tań­sze. Tylko do takiej decy­zji potrze­ba po pierw­sze zro­zu­mie­nia a po dru­gie spoj­rze­nia z szer­szej perspektywy.

I nie­ste­ty nie liczę na zro­zu­mie­nie u więk­szo­ści PM’ów (ich wie­dza jest czę­sto taka jak powyż­szy kamień pogo­do­wy), reali­zu­ją cele swo­je­go pra­co­daw­cy a nie cele kupu­ją­ce­go, a Ci ostat­ni albo mają kom­pe­ten­cje by nad­zo­ro­wać wła­sne pro­jek­ty albo nie…