Język czy notacja czyli co?

Od cza­su do cza­su jestem pyta­ny czy UML, BPMN, itp.. to nota­cje czy języ­ki, a pada­ją nawet pyta­nia czy to meto­dy. Otóż meto­dy na pew­no nie… (np. mamy dwie meto­dy mode­lo­wa­nia pro­ce­sów biz­ne­so­wych: z uży­ciem nota­cji BPMN i nota­cji eEPC). A pozo­sta­łe dwa?

Nie jest to pro­ste. Dzisiaj pój­dę może nie­co na skró­ty dla­te­go wni­kli­wym pole­cam lek­tu­rę przede wszyst­kim na temat semio­ty­ki, logi­ki i rachun­ku zdań.

Język i znaczenie

Na począ­tek kil­ka defi­ni­cji ogól­nych (wszyst­kie sł. j. pol­skie­go PWN):

język
5. ?utrwa­lo­ny spo­łecz­nie zespół zna­ków doty­czą­cych jakichś dzia­łań czło­wie­ka lub wyra­ża­ją­cych jego emo­cje oraz każ­dy układ ele­men­tów rze­czy­wi­sto­ści, któ­re­mu czło­wiek nadał jakąś treść?

Język jest więc okre­ślo­nym zespo­łem norm, są nimi jed­nak nie tyl­ko zna­ki ale tak­że to, co zna­czą i jaką treść nio­są. Wyrażanie emo­cji czy myśli w ogó­le, rzad­ko jest moż­li­we z uży­ciem tyl­ko jed­ne­go zna­ku. Dlatego w toku ich wyra­ża­nia ope­ru­je­my raczej zdaniami:

zda­nie
1. ?myśl wyra­żo­na słowami?
4. log. ?sen­sow­ne wyra­że­nie oznaj­mia­ją­ce pod­le­ga­ją­ce falsyfikacji?

Tu zaczy­na­my powo­li iść w porząd­ko­wa­nie tego o czym piszę. Każde zda­nie (w logi­ce) może być praw­dzi­we lub nie (tau­to­lo­gia jest zda­niem zawsze praw­dzi­wym, czy­li jest zna­ny fakt je fal­sy­fi­ku­ją­cy ale wie­my, że nigdy taki nie wystą­pi). Jeżeli więc, że treść naj­czę­ściej wyra­ża­my sło­wa­mi (a raczej rzad­ko nie jed­nym sło­wem) to zna­czy, że nale­ży umieć odczy­tać zna­cze­nie zło­że­nia wie­lu słów w jed­nym zda­niu. Jak wie­my o zro­zu­mia­ło­ści (zro­zu­mia­łość ozna­cza, że zda­nie ma dla czy­ta­ją­ce­go okre­ślo­ne zna­cze­nie) decy­du­je układ słów w zda­niu, zna­ki inter­punk­cyj­ne itp.

przecinek

Nawet prze­ci­nek ma zna­cze­nie (jest on ele­men­tem języ­ka) w zda­niu złożonym.

Jednoznaczność (zro­zu­mia­łość, zna­cze­nie) zdań jest tak­że efek­tem kontekstu:

kon­tekst
1. ?frag­ment tek­stu potrzeb­ny do dokład­ne­go rozu­mie­nia danych wyra­zów lub wyrażeń?
3. ?zespół jed­no­stek języ­ko­wych, któ­re sta­no­wią oto­cze­nie danej jednostki?
4. ?zespół odnie­sień nie­zbęd­nych do zro­zu­mie­nia utwo­ru lite­rac­kie­go, dzie­ła nauko­we­go itp.?

zakaz dobijania dziobem niejednoznacznoscJeżeli napi­szę Te dwie kro­wy są paskud­ne” to nadal nie ma pew­no­ści o czym mowa. Bez wie­dzy o tym, czy to roz­mo­wa dwóch rol­ni­ków o inwen­ta­rzu, czy też dwóch kole­ża­nek o dwóch innych, nie wie­my. Słowo palant” tak­że ma wię­cej niż jed­no zna­cze­nie i bez kon­tek­stu jego uży­cia nie wie­my o jakie zna­cze­nie cho­dzi (kole­ga czy mało już popu­lar­na gra) :). Bardzo czę­sto to wła­śnie kon­tekst nada­je znaczenie.

Jak widać zro­zu­mie­nie prze­ka­zu nie musi być pro­ste, a komu­ni­ka­cja pro­sta i łatwa (każ­dy kto się choć raz pokłó­cił z powo­du nie­po­ro­zu­mień o tym wie). Kontekstem zaj­mu­je się:

prag­ma­ty­ka
1. ?dział języ­ko­znaw­stwa, któ­re­go przed­mio­tem są spo­łecz­ne i sytu­acyj­ne warun­ki funk­cjo­no­wa­nia języ­ka oraz cele, jakie mówią­cy chce osią­gnąć przez uży­cie okre­ślo­nych wyra­zów i wyrażeń?

Należy pamię­tać, że zna­cze­nie mają nie tyl­ko poje­dyn­cze sło­wa (zna­ki) ale tak­że ich zło­że­nia („pro­ces biz­ne­so­wy” to jed­no poję­cie ale dwa sło­wa). Innymi sło­wy kon­kret­ne poję­cie może być zapi­sa­ne z uży­ciem jed­ne­go lub wię­cej znaków.

sło­wo
1. ?znak języ­ko­wy mają­cy jakieś znaczenie?

Dlatego zło­że­nie kil­ku zna­ków (słów) tak­że jest zna­kiem (defi­ni­cja sło­wa i słowo/pojęcie przez nią defi­nio­wa­ne, nio­są toż­sa­me zna­cze­nie). Słowo (rozu­mia­ne jako zapis: zło­że­nie liter) moż­na zastą­pić sym­bo­lem gra­ficz­nym (iko­na). O tym traktuje

semio­ty­ka
1. ?ogól­na teo­ria zna­ku w pro­ce­sie poro­zu­mie­wa­nia się ludzi?

w tym:

seman­ty­ka
1. ?dział języ­ko­znaw­stwa, któ­re­go przed­mio­tem jest ana­li­za zna­czeń wyrazów?
2. ?dział semio­ty­ki zaj­mu­ją­cy się bada­niem związ­ków, jakie zacho­dzą mię­dzy wyra­że­nia­mi języ­ka a przed­mio­ta­mi, do któ­rych się one odnoszą?

syn­tak­ty­ka
2. ?dział semio­ty­ki bada­ją­cy wza­jem­ne sto­sun­ki i wła­ści­wo­ści budo­wy wyra­żeń języ­ka w pro­ce­sie poro­zu­mie­wa­nia się ludzi?

Zapisując coś: treść, w celu prze­ka­za­nia jej dru­giej oso­bie komu­ni­ku­je­my się:

komu­ni­ka­cja
2. ?prze­pływ infor­ma­cji mię­dzy urzą­dze­nia­mi, np. tele­fo­na­mi lub komputerami?
3. ?prze­ka­zy­wa­nie i odbie­ra­nie infor­ma­cji w bez­po­śred­nim kon­tak­cie z dru­gą osobą?

treść
1. ?to, co jest zawar­te w czy­jejś wypo­wie­dzi; też: to, co prze­ka­zu­je odbior­cy dzie­ło sztu­ki, w prze­ciw­sta­wie­niu do formy?
2. ?to, co sta­no­wi isto­tę, sens czegoś?

Do komu­ni­ka­cji uży­wa­my znaków:

znak
1. ?kształt, któ­re­mu przy­pi­su­je się okre­ślo­ne znaczenie?
2. ?dźwięk, spoj­rze­nie, gest itp. słu­żą­cy do prze­ka­za­nia informacji?

Znak zna­czy, czy­li ma okre­ślo­ne znacz­nie (pamię­ta­my o kon­tek­ście). Znakiem może być wie­le rze­czy (tak­że gest). Znak ma (nie­sie) zna­cze­nie, znak lub ich zło­że­nie tak­że, prze­ka­zu­je okre­ślo­ną treść:

zna­cze­nie
1. ?myśl zawar­ta w czy­jejś wypo­wie­dzi, w czy­imś zacho­wa­niu itp.?
3. ?treść, któ­rej zna­kiem jest wyraz lub wyrażenie?

zna­czyć
1. ?być zna­kiem czegoś?
3. ?umiesz­czać na czymś lub na kimś znak?
4. ?zosta­wiać na czymś znak, ślad?

Na koniec zosta­wi­łem, spor­ne słowo:

nota­cja ?ozna­cze­nie cze­goś umow­ny­mi zna­ka­mi; też: zbiór takich znaków?

Notacja to zbiór zna­ków. Przypomnę też, że język to mie­dzy inny­mi okre­ślo­ny zbiór zna­ków wraz z opi­sem ich zna­czeń (seman­ty­ka) oraz tym, jakie mają zna­cze­nia ich okre­ślo­ne zło­że­nia (syn­tak­ty­ka). Wiemy już, że zna­cze­nie (treść) mają nie tyl­ko poje­dyn­cze sło­wa (to rzad­ko) ale ich kon­kret­ne zło­że­nia (zda­nia). Przekazanie kon­kret­nych, jed­no­znacz­nych tre­ści, poza rzad­ki­mi wyjąt­ka­mi, wyma­ga więc zbu­do­wa­nia kon­kret­nych zdań czy­li zło­żeń słów (zna­ków)”. Innymi sło­wy, nikt chy­ba nie powie, że książ­ka jaką jest słow­nik języ­ka pol­skie­go, wraz z zasa­da­mi gra­ma­ty­ki, to jest język pol­ski”. Język to jed­nak coś wię­cej”. Słowo język jest dość nie­pre­cy­zyj­ne i ozna­cza wręcz pewien zespół norm i spo­so­bów poro­zu­mie­wa­nia się (w tym idio­my, zespo­ły słów mają­ca inne zna­cze­nie niż każ­de z nich z osob­na). Poprawne (sku­tecz­ne) posłu­gi­wa­nie się danym języ­kiem ozna­cza, że adre­sat zro­zu­miał” treść nadaw­cy (mówią­ce­go).

Porządkujemy to wszystko

Zrobiło się cięż­ko :). Poniżej model poję­cio­wy: dia­gram w nota­cji SBVR poka­zu­ją­cy poję­cia i związ­ki mię­dzy nimi. Jednym z klu­czo­wych narzę­dzi w ana­li­zie jest wła­snie ana­li­za poję­cio­wa i budo­wa­nie słow­ni­ka pojęć dla okre­ślo­nej dzie­dzi­ny (tu wię­cej o tym czy jest dia­gram fak­tów opi­sa­ny w nota­cji SBVR).

jezyk-i-notacja-model-pojeciowy

Powyższy model obra­zu­je związ­ki pomię­dzy opi­sa­ny­mi wyżej poję­cia­mi, pre­cy­zu­je tak­że ich zna­cze­nia. Model poję­cio­wy dla danej dzie­dzi­ny (tu mowa o języ­kach i nota­cjach) powi­nien się cecho­wać mię­dzy inny­mi tym, że zna­cze­nia poszcze­gól­nych pojęć powin­ny być roz­łącz­ne, czy­li speł­niać ary­sto­te­le­sow­ską zasa­dę wyłą­czo­ne­go środ­ka” w logi­ce, brzmią­cą: jeże­li coś jest czymś, to nie jest niczym innym”. Dla zacho­wa­nia jed­no­znacz­no­ści zdań, defi­ni­cje pojęć muszą się więc wza­jem­nie wyklu­czać, tak zbu­do­wa­ny słow­nik nazy­wa­my prze­strze­nią nazw” (ang. namespace).

UML i BPMN to język czy notacja?

Skrót UML zawie­ra w sobie sło­wo lan­gu­age” (ang. język). Historycznie tłu­ma­czyć to moż­na tym, że obec­ne 14 typów dia­gra­mów to kon­kret­ne kon­tek­sty oraz narzu­co­ne kon­struk­cje, któ­re moż­na nazwać zda­nia­mi” (widać to szcze­gól­nie w przy­pad­ku dia­gra­mów Przypadków uży­cia czy Rozlokowania). Jednak obec­na spe­cy­fi­ka­cja UML 2.5 porząd­ku­je i to, sło­wo lan­gu­age” w zasa­dzie nie jest w niej sto­so­wa­ne wobec tego co nazwa­no tam mia­nem UML (W zasa­dzie dzi­siaj mogła by nosić nazwę Object-orien­ted Modeling and Notation 🙂 ).

Tak więc język czy nota­cja? To zale­ży od tego czy dana spe­cy­fi­ka­cja” opi­su­je wyłącz­nie sym­bo­le czy też ich okre­ślo­ne, i zale­ca­ne w okre­ślo­nych sytu­acjach, kon­struk­cje oraz ich zna­cze­nie. OMG (chy­ba) sta­ra się to ostat­nio jasno sygna­li­zo­wać: UML to jesz­cze lan­gu­age” ale BPMN to już nota­tion”. Specyfikacja UML zawie­ra okre­ślo­ne, seman­tycz­ne (nazwa­ne) kon­struk­cje, mają­ce okre­ślo­ne zna­cze­nia, zwią­za­ne z kon­kret­ny­mi dia­gra­ma­mi (nazwa dia­gra­mu nada­je kon­tekst uży­tym na nich sym­bo­lom, jest to potrzeb­ne bo pamię­taj­my, że w UML wszyst­ko jest kla­są”). W BPMN nie ma cze­goś takie­go (nawet poję­cie pro­ces biz­ne­so­wy” nie jest czę­ścią BPMN, jest ono zde­fi­nio­wa­ne dopie­ro w Dodatku A jako obja­śnie­nie i dodat­ko­wy kon­tekst, w nota­cji zaś BPMN nie ma sym­bo­lu pro­ces biz­ne­so­wy” 🙂 ). To czy dana spe­cy­fi­ka­cja to tyko opis nota­cji czy tak­że języ­ka, zale­ży więc od kon­kret­ne­go przypadku.

usuwanie dwuznaczosci i niejasnosciNiewątpliwie UML, BPMN, CMMN, SBVR, BMM itp., to wszyst­ko są nota­cje, bo są to spe­cy­fi­ka­cje sym­bo­li, ich zna­czeń oraz okre­ślo­na syn­tak­ty­ka. Natomiast o tym co i jak wyra­ża­ją (i czy w ogó­le ;)) two­rzo­ne z ich pomo­cą dia­gra­my, to już inna kwe­stia… To leży w gestii twór­cy dia­gra­mów. A testem jest mie­dzy inny­mi sku­tecz­ność komu­ni­ka­cji: porów­na­nie tego jaką kon­kret­ną treść chciał prze­ka­zać twór­ca dane­go dia­gra­mu i jaką treść ode­brał czy­ta­ją­cy… Analityk zaczy­na od ana­li­zy poję­cio­wej by unik­nąć nie­jed­no­znacz­no­ści w samym prze­ka­zie. Potem dopie­ro doku­men­tu­je, z uży­ciem mode­li two­rzo­nych z pomo­cą nota­cji, to co zastał oraz pro­jek­tu­je to, co chciał­by by, by powsta­ło spo­sób roz­wią­za­nie pro­ble­mu (tu pole­cam lek­tu­rę arty­ku­łu gdzie pisa­łem o tym, że wyma­ga­nia to pro­jekt).

Niewątpliwie więc wszyst­kie języ­ki pro­gra­mo­wa­nia” są języ­ka­mi: mają skład­nię i każ­de zda­nie coś wyra­ża (rozu­mie to i kole­ga pro­gra­mi­sta i kom­pi­la­tor). Wiele nota­cji jed­nak języ­kiem nie jest. O języ­ku moż­na mówić tyl­ko wte­dy, gdy jest samo­wy­star­czal­ny do wyra­ża­nia okre­ślo­nych myśli i tre­ści, do komu­ni­ko­wa­nia ich. Nie może­my tego raczej powie­dzieć o nota­cjach. Diagramy i mode­le wyko­na­ne z pomo­cą w. nota­cji wyma­ga­ją sto­so­wa­nia np. języ­ka” pol­skie­go, do nada­wa­nia nazw sym­bo­lom i dia­gra­mom, bez cze­go dia­gra­my te były by nie­zro­zu­mia­łe. Uważam więc, że uży­wa­nie wobec nota­cji obli­ga­to­ryj­nie nazwy język, jest poważ­nym nad­uży­ciem… Niektóre nota­cje mają swo­ją wer­sję wyko­ny­wal­ną (tu nawią­zu­je do tego że języ­ki pro­gra­mo­wa­nia są” języ­ka­mi”) o czym nie­daw­no pisa­łem (Analityczne i wyko­ny­wal­ne mode­le) jed­nak pamię­tać, nale­ży nota­cja jako taka nie jest języ­kiem pro­gra­mo­wa­nia”, jest tu raczej for­mą budo­wa­nia mecha­ni­zmu (mode­lo­wa­nie), któ­ry dopie­ro po doda­niu wie­lu para­me­trów (czy­li wpro­wa­dze­niu wie­lu słów” z poza nota­cji) pozwa­la taki model uru­cho­mić”.

Analiza a programowanie czyli gramy w chińczyka na szachownicy

Permanentne dys­ku­sje z wie­lo­ma pro­gra­mi­sta­mi utrwa­la­ją we mnie pewien ste­reo­typ: inży­nier to dobry wyko­naw­ca ale żaden ana­li­tyk. Czy to coś złe­go? Absolutnie nie, dobry inży­nier jest na wagę zło­ta ale dobry inży­nier powi­nien mieć jed­ną klu­czo­wą cechę: nie dys­ku­tu­je z pro­jek­tan­tem (jeże­li tyl­ko pro­jek­tant potra­fi uza­sad­nić cze­go chce). Ale po kolei.

Popatrzmy do Wikipedii bo w znacz­nej mie­rze jest two­rzo­na przez pro­gra­mi­stów i entu­zja­stów infor­ma­ty­ki, choć chy­ba nale­ży raczej powie­dzieć: pro­gra­mo­wa­nia (dodam, że w pra­wie każ­dej fir­mie obser­wu­ję dwa syn­dro­my: każ­dy kto nie jest infor­ma­ty­kiem zna się na mar­ke­tin­gu, pozo­sta­li zna­ją się i na pro­gra­mo­wa­niu i na marketingu).

Programowanie obiek­to­we (ang. object-orien­ted pro­gram­ming) ? para­dyg­mat pro­gra­mo­wa­nia, w któ­rym pro­gra­my defi­niu­je się za pomo­cą obiek­tów ? ele­men­tów łączą­cych stan (czy­li dane, nazy­wa­ne naj­czę­ściej pola­mi) i zacho­wa­nie (czy­li pro­ce­du­ry, tu: meto­dy). Obiektowy pro­gram kom­pu­te­ro­wy wyra­żo­ny jest jako zbiór takich obiek­tów, komu­ni­ku­ją­cych się pomię­dzy sobą w celu wyko­ny­wa­nia zadań. Podejście to róż­ni się od tra­dy­cyj­ne­go pro­gra­mo­wa­nia pro­ce­du­ral­ne­go, gdzie dane i pro­ce­du­ry nie są ze sobą bez­po­śred­nio zwią­za­ne. Programowanie obiek­to­we ma uła­twić pisa­nie, kon­ser­wa­cję i wie­lo­krot­ne uży­cie pro­gra­mów lub ich fragmentów.

Największym atu­tem pro­gra­mo­wa­nia, pro­jek­to­wa­nia oraz ana­li­zy obiek­to­wej jest zgod­ność takie­go podej­ścia z rze­czy­wi­sto­ścią – mózg ludz­ki jest w natu­ral­ny spo­sób naj­le­piej przy­sto­so­wa­ny do takie­go podej­ścia przy prze­twa­rza­niu infor­ma­cji. Już Platon postu­lo­wał dwo­istość: byt” – idea (wzo­rzec) bytu”, np. książ­ka jako idea ogól­na – w ter­mi­no­lo­gii pla­toń­skiej: dosko­na­ła (choć nie­do­okre­ślo­na), i książ­ka kon­kret­na np. zbiór baśni leżą­cy na pią­tej pół­ce. Podobnie, choć póź­niej Arystoteles ana­li­zu­jąc rze­czy­wi­stość wpro­wa­dził poję­cia for­my i mate­rii. (źr. WIKI)

Mamy tu więc dwa wąt­ki: tech­nicz­ny czy­li imple­men­ta­cja [[para­dyg­ma­tu]] obiek­to­we­go w języ­kach pro­gra­mo­wa­nia oraz huma­ni­stycz­ny czy­li opis (model) rze­czy­wi­sto­ści: byty i ich postrze­ga­nie przez czło­wie­ka (w zasa­dzie filo­zo­fia, a kon­kret­nie [[feno­me­no­lo­gia]]: wśród waż­nych pojęć feno­me­no­lo­gii znaj­du­je się [[ana­li­za eide­tycz­na]], czy­li dąże­nie do uchwy­ce­nia isto­ty tego, co dane, ide­acja, docie­ra­nie do isto­ty zja­wisk, widze­nie istot­no­ścio­we. W naocz­no­ści istot­no­ścio­wej dana jest czy­sta isto­ta zja­wi­ska. Uchwycenie tej isto­ty nie musi być prze­pro­wa­dzo­ne na wie­lu przy­kła­dach, wystar­czy nawet jeden lub tyl­ko naocz­ność wyobra­że­nio­wa (przy­kład wyobra­żo­ny)).

Modelowanie rze­czy­wi­stych bytów nie ma nic wspól­ne­go z pro­gra­mo­wa­niem czy infor­ma­ty­ką (przy­po­mi­nam tak­że, że [[teo­ria infor­ma­cji]] i [[infor­ma­ty­ka]] to nie toż­sa­me dzie­dzi­ny wie­dzy) . Raczej potrzeb­na jest do tego [[teo­ria pozna­nia czy­li epi­ste­mo­lo­gia]], [[onto­lo­gia]] czy seman­ty­ka a tak­że [[teo­ria komu­ni­ka­cji społecznej]].

Model dzie­dzi­ny więc, to nic inne­go jak zespół pojęć, związ­ków mię­dzy tymi poję­cia­mi, tego jak czło­wiek postrze­ga te byty rze­czy­wi­ste na bazie nazw, któ­rych uży­wa do ich ozna­cza­nia. Powszechnie pod­no­szo­ny brak wie­dzy klien­ta o tym co chce”, to tak na praw­dę brak kom­pe­ten­cji pro­gra­mi­stów do odczy­ta­nia tego co swo­imi poję­cia­mi prze­ka­zu­je im klient. 

Nie piszę o tym dla­te­go, co mi się cza­sa­mi zarzu­ca, by zamu­lić ana­li­zę teo­rią i udo­wad­niać coś pro­gra­mi­stom. Piszę o tym dla­te­go, że ana­li­za jako drą­że­nie tego co chcą ludzie powie­dzieć i co mówią, taka wła­śnie jest: nieinformatyczna.

Naturalnym więc bie­giem wyda­rzeń w two­rze­niu opro­gra­mo­wa­nia powin­no być więc mode­lo­wa­nie świa­ta opi­sy­wa­ne­go” a potem odtwo­rze­nie” go w kodzie opro­gra­mo­wa­nia. Wcześniej nale­ży okre­ślić co i po co ma zna­leźć odzwier­cie­dle­nie w pro­gra­mie. Być może ktoś dostrze­że tu ele­men­ty DDD ([[Domain Driven Design]], ang. pro­jek­to­wa­nie ste­ro­wa­ne mode­lem dzie­dzi­ny) i słusz­nie bo tak wła­snie jest.

Komponent opro­gra­mo­wa­nia odpo­wie­dzial­ny za reali­za­cję wyma­gań funk­cjo­nal­nych, omó­wio­ny dalej Model, to nic inne­go jak pro­gra­mo­wa symu­la­cja” kawał­ka rze­czy­wi­ste­go świa­ta. Nie moż­na jej abso­lut­nie uprasz­czać, w prze­ciw­nym wypad­ku psu­je­my pro­gram” odda­la­jąc go od rze­czy­wi­sto­ści. Paradoksalnie przy­kła­dem takie­go psu­cia jest nor­ma­li­za­cja rela­cyj­nej bazy danych (redun­dan­cje są typo­wym ele­men­tem rze­czy­wi­sto­ści, usu­wa­nie ich to nisz­cze­nie związ­ku pomię­dzy pro­gra­mem a świa­tem jaki pro­gram modeluje).

Jak zwró­co­no uwa­gę w przy­to­czo­nej defi­ni­cji: Największym atu­tem pro­gra­mo­wa­nia, pro­jek­to­wa­nia oraz ana­li­zy obiek­to­wej jest zgod­ność takie­go podej­ścia z rze­czy­wi­sto­ścią”. Tak więc nale­ży posiąść” tę zgod­ność i rze­czy­wi­stość i nie psuć jej.

Kto powi­nien mode­lo­wać nasz świat”? Dla pro­gra­mi­sty, jak sami to nie raz pod­kre­śla­ją, obiekt to struk­tu­ra łączą­ca w kodzie dane prze­twa­rza­ne z meto­da­mi ich prze­twa­rza­nia. Ale wokół nas są obiek­ty rze­czy­wi­ste: świat i jego zawi­ło­ści. To suge­ru­je raczej, że ana­li­za obiek­to­wa i two­rze­nie mode­lu rze­czy­wi­sto­ści” nie ma nic wspól­ne­go z pro­gra­mo­wa­niem. To raczej jest tak, że pro­gra­mi­sta powi­nien odtwo­rzyć” w kodzie otrzy­ma­ny od ana­li­ty­ka i pro­jek­tan­ta, model. Po to powsta­ły obiek­to­we narzę­dzia by wła­śnie uła­twić pro­gra­mi­stom imple­men­ta­cje obiek­to­wych mode­li a ana­li­ty­kom ich two­rze­nie, dać im wspól­ny (powszech­ny, [[Ubiquitous Language]]) język.

A tu pro­szę: inży­nier ze swo­im obiek­to­wym języ­kiem pro­gra­mo­wa­nia, struk­tu­ra­mi kodu i danych” zabie­ra się do tego, do cze­go nie ma żad­ne­go przy­go­to­wa­nia: mode­lo­wa­nie fir­my (świa­ta) i tego jak jest zarzą­dza­na. Rozumiem obu­rze­nie: to my jeste­śmy pro­gra­mi­sta­mi i my wie­my jak pro­gra­mo­wać. Owszem, JAK ale nie CO. Nie wystar­czy że popy­ta­cie use­ra jak pra­cu­je, trze­ba zro­zu­mieć: co i po co robi a potem stwo­rzyć tego model. Dobry model musi odzwier­cie­dlać rzeczywistość”.

Z obiek­to­wo­ści pro­gra­mi­ści rozu­mie­ją tyl­ko tyle, że to coś co łączy dane i funk­cje”. Ja nicze­go wię­cej nie ocze­ku­ję od pro­gra­mi­stów. Ilu pro­gra­mi­stów czy­ta­ło ze zro­zu­mie­niem Druckera, Portera, Kottlera?

Wielu z nich jest (będzie jak to prze­czy­ta ;)) jak obra­żo­ne dzie­ci bawią­ce się sza­cha­mi: roz­po­zna­ją koni­ka, wie­że czy kró­la, tra­fia­ją figu­ra­mi w pola sza­chow­ni­cy i nie dadzą sobie powie­dzieć, że Goniec to tyl­ko po sko­sie. Szachy to nie jakieś drew­nia­ne pio­ny i 64 pola do ich usta­wia­nia”. Można zagrać tymi pio­na­mi na tej plan­szy w war­ca­by a nawet w zbi­ja­ka, ale to nadal są sza­chy i ta gra ma nie­co inne zasa­dy mimo, że to fak­tycz­nie tyl­ko plan­sza i drew­nia­ne pio­ny i fak­tycz­nie da się z powo­dze­niem zagrać tym sprzę­tem” w war­ca­by, a nawet w chiń­czy­ka (w koń­cu to tyl­ko drew­nia­ne figurki).

Tak więc obiek­to­we pro­gra­mo­wa­nie to narzę­dzie, moż­na nim wie­le zro­bić na wie­le spo­so­bów, ale jeże­li powie­my sobie, że pro­jek­tu­je­my jakąś rze­czy­wi­stość biz­ne­so­wą meto­da­mi obiek­to­wy­mi, to z całym sza­cun­kiem: ocze­ku­ję od pro­gra­mi­sty, że uzna fakt, że figur­ki i plan­sza to jed­nak sza­chy. Od sto­la­rza nie ocze­ku­ję, że będzie mistrzem sza­cho­wym, ocze­ku­ję, że pod dyk­tan­do sza­chi­sty (wyma­ga­nia) wyko­na naj­lep­szą plan­szę i pio­ny i nie będzie się wda­wał w dys­ku­sje na temat tego, dla­cze­go koń na sza­chow­ni­cy wyci­na takie śmiesz­ne hołub­ce i for­so­wał tezy by uznać, że ma cho­dzić pro­sto” i będzie pro­ściej. Szachista tak chce i już, ma pra­wo bo to on zama­wia, to on tu jest sza­chi­stą a sto­larz stolarzem.

Proces powstawania oprogramowania

Tu powo­łam się (po raz kolej­ny) na wzo­rzec pro­jek­to­wy MVC. Obrazuje on podział opro­gra­mo­wa­nia na trzy klu­czo­we podsystemy:

Stosowanie tego wzor­ca ma pewien głę­bo­ki sens: podział odpo­wie­dzial­no­ści zgod­nie z regu­łą obiek­to­wą mówią­cą, że obiekt (tak­że kom­po­nent i jego inter­fejs) ma wszyst­kie i tyl­ko te kom­pe­ten­cje, któ­re są wyma­ga­ne do wywią­za­nia się z kon­trak­tu ([[pro­jek­to­wa­nie zorien­to­wa­ne na kon­trakt]]). Tym kon­trak­tem jest to za co odpo­wia­da obiekt i tyl­ko to”. Powyższy dia­gram (nie jest to [[dia­gram klas]], to sche­mat blo­ko­wy obra­zu­ją­cy wza­jem­ne oddzia­ły­wa­nie na sie­bie kom­po­nen­tów: blo­czek ozna­cza kom­po­nent, strzał­ka poka­zu­je kie­ru­nek oddzia­ły­wa­nia) obra­zu­je zobo­wią­za­nia tych trzech komponentów.

Nie wgłę­bia­jąc się w szcze­gó­ły tego wzor­ca (opi­sy dostęp­ne w sie­ci) istot­ne jest odręb­ne ist­nie­nie kom­po­nen­tów. Model zawie­ra w sobie (mode­lu­je w pro­jek­cie i imple­men­tu­je w kodzie) świat rze­czy­wi­sty wyra­żo­ny w obiek­to­wym para­dyg­ma­cie” (kon­trakt brzmi: wiem wszyt­ko o tym czym jest i jak dzia­ła świat w oto­cze­niu użyt­kow­ni­ka), zarów­no dane jak i logi­kę ich zacho­wań. View ma kon­trakt inny: bio­rę na sie­bie całą inte­rak­cję pro­gra­mu z użyt­kow­ni­kiem. Controller zaś mówi: bio­rę na sie­bie zapa­mię­ty­wa­nie, całą komu­ni­ka­cję, jej spraw­ność i nie­za­wod­ność, w tym tak­że pomię­dzy View i Modelem.

Mamy pro­sty podział odpo­wie­dzial­no­ści: Grafik odpo­wia­da za pro­jekt View, Analityk Biznesowy za Model (przy­po­mnę: co i jak jest prze­twa­rza­ne) a pro­gra­mi­sta za tech­no­lo­gię i ubra­nie tego wszyst­kie­go w dzia­ła­ją­cy kod czy­li za imple­men­ta­cję. Jeżeli uzna­my, że ana­li­tyk opra­cu­je Model meto­da­mi obiek­to­wy­mi to mamy wła­śnie atut pro­gra­mo­wa­nia, pro­jek­to­wa­nia oraz ana­li­zy obiek­to­wej czy­li zgod­ność takie­go podej­ścia z rzeczywistością.

No i teraz sko­ro tak, to samo się nasuwa:

  1. wyko­naj ana­li­zę i opra­cuj obiek­to­wy model rze­czy­wi­sto­ści, upew­nij się, że jest praw­dzi­wy (zgod­ny z tą rzeczywistością),
  2. opra­cuj pro­jekt tego co zoba­czy użyt­kow­nik pro­gra­mu: ekrany,
  3. zapisz ogra­ni­cze­nia sto­so­wa­nia przy­szłe­go programu,
  4. daj to pro­gra­mi­stom by stwo­rzy­li zgod­ny z tymi wyma­ga­nia­mi, dzia­ła­ją­cy program.

Czy inna kolej­ność jest moż­li­wa? Czy widać, że bez pro­jek­tów Modelu i ekra­nów nie ma się co brać za kodo­wa­nie? Co kodo­wać? Jak na tym tle wyglą­da­ją meto­dy pole­ga­ją­ce, na tym, że od razu po roz­mo­wie z nie­ro­zu­mie­ją­cym obiek­to­we­go para­dyg­ma­tu użyt­kow­ni­kiem, przy­stę­pu­je się do kodo­wa­nia? Jak będzie prze­bie­ga­ło two­rze­nie kodu, jeśli wie­my na razie tyl­ko to, że ma powstać fak­tu­ra zaś o tym, że doty­czy zamó­wień z inne­go sys­te­mu i wła­sne­go maga­zy­nu dowie­my się jutro mając już coś napi­sa­ne”? Bo ja mam wra­że­nie, że to po pro­tu sta­re funk­cyj­ne podej­ście tyle, że z uży­ciem klas obiek­tów, metod i atry­bu­tów” bo nie raz, patrząc na pra­ce nie­któ­rych pro­gra­mi­stów, nie prze­cho­dzi mi przez gar­dło para­dyg­mat obiektowy”.

Czym to gro­zi? Długim cza­sem kodo­wa­nia, kolej­ny­mi pro­to­ty­pa­mi i dzie­siąt­ka­mi mody­fi­ka­cji kodu, bra­kiem zro­zu­mie­nia, uprosz­cze­nia­mi wyma­gań czy­li jed­nym sło­wem: duży­mi pie­niędz­mi za kiep­ski pro­gram (skąd to znamy??).

Dlatego pro­szę pro­gra­mi­stów: rób­cie to co rozu­mie­cie i nie wma­wiaj­cie niko­mu, że wie­cie lepiej jak zarzą­dzać fir­mą Waszych klien­tów. Róbcie to co każ­dy dobry sto­larz: popro­ście klien­ta o rysu­nek tego co ma powstać i zrób­cie. Nie zapo­mi­naj­cie, że dobry sto­larz to nie to samo do dobry pro­jek­tant, jak klient nie potra­fi ryso­wać (a naj­czę­ściej nie, bo nie to jest jego kom­pe­ten­cją), dobry sto­larz zawsze ode­śle do pro­jek­tan­ta po rysu­nek. Między inny­mi dla­te­go, by póź­niej nie być posą­dzo­nym o stron­ni­czość czy­li ryso­wa­nie tyl­ko tego co jest łatwe w wyko­na­niu. Rzecz w tym, że nie ma być łatwe dla sto­la­rza a dobre dla klienta.

Pod tym wszyst­kim pod­pi­su­ję się ja, Jarek Rysownik

P.S.

Ten arty­kuł powi­nien mieć chy­ba tytuł: Manifest analityka-projektanta ;).

Ten straszny diagram klas

(aktu­ali­zo­wa­ny 2020) Gdybym miał oce­nić sta­ty­stycz­nie dia­gram klas opi­sy­wa­ny w książ­kach o UML , pro­jek­tach jakie widu­ję nie tyl­ko w pra­cach stu­den­tów, to powie­dział bym, że jest jakiś pro­blem z nimi. Dlaczego? Pokaże to, co moim zda­niem jest chy­ba nie tak. Szczególnie jak ktoś uwa­ża, że dia­gram klas do model danych co wprost pro­wa­dzi do antyw­zor­ca obiek­to­we­go o nazwie ane­micz­ny model dzie­dzi­ny ?*?Ten arty­kuł to kon­ty­nu­acja poprzed­nie­go arty­ku­łu o mode­lach dzie­dzi­ny sys­te­mu.

Co można i należy pokazać w wynikach analizy – taksonomia

Przede wszyst­kim ana­li­za to nie pro­jekt, powin­na poka­zać obiek­tyw­ny stan fak­tycz­ny. Druga rzecz, o tym już nie­któ­rzy zapo­mi­na­ją: wyni­kiem ana­li­zy jest doku­men­ta­cja zro­zu­mie­nia, tak więc model ana­li­tycz­ny nie może być mode­lem poka­zu­ją­cym stan po uprosz­cze­niach. To powi­nien być model rze­czy­wi­sto­ści z nanie­sio­ny­mi, zasto­so­wa­ny­mi lokal­nie, ogra­ni­cze­nia­mi i uprosz­cze­nia­mi. Innymi sło­wy: dla fabry­ki spodni budu­je­my kom­plet­ny model czło­wie­ka (mane­kin) z komen­ta­rzem, że tu w uży­ciu jest część od pasa w dół a nie wma­wia­my niko­mu, że w tej fabry­ce czło­wiek skła­da sie wyłącz­nie z bio­der i nóg. W prze­ciw­nym wypad­ku, przy­szła roz­bu­do­wa sys­te­mu będzie co naj­mniej problematyczna.

Produkt ana­li­zy prze­ka­zu­je infor­ma­cję o tym co zasta­no, opi­su­je poję­cia i regu­ły jakie nimi rzą­dzą. Tak na praw­dę, opi­sać fir­mę (orga­ni­za­cję) to zna­czy stwo­rzyć listę pojęć jaki­mi się w niej ope­ru­je (jaki­mi moż­na ją opi­sać) i regu­ły jakie ogra­ni­cza­ją swo­bo­dę uży­cia (funk­cjo­no­wa­nia) tych pojęć. Model poję­cio­wy (ich spe­cy­fi­ka­cja) to seman­ty­ka sys­te­mu, ogra­ni­cze­nia swo­bo­dy ich wza­jem­ne­go koja­rze­nia to syn­tak­ty­ka, i na koniec dzie­dzi­no­we ogra­ni­cze­nie swo­bo­dy ich uży­cia to prag­ma­ty­ka. Wkrada się tu tak­że przy­dat­ne poję­cie jakim jest entro­pia czy­li mia­ra nie­upo­rząd­ko­wa­nia. Tak więc mamy sys­tem pojęć, jego entro­pia (sto­pień nie­upo­rząd­ko­wa­nia) jest ogra­ni­czo­na syn­tak­ty­ką i prag­ma­ty­ką spe­cy­ficz­ną dla dzie­dzi­ny i miej­sca (orga­ni­za­cji). Co to ozna­cza dla ana­li­zy przedwdrożniowej?

Jednym z celów tej ana­li­zy jest odkry­cie i zapi­sa­nie wie­dzy o pod­mio­cie infor­ma­ty­zo­wa­nym”. Jak ją zapi­sać? Ano wła­śnie tak: zbu­do­wać listę pojęć i wska­zać opi­sa­ne ogra­ni­cze­nia. Doskonałym narzę­dziem do tego jest dia­gram klas (odra­dzam dia­gram ERD, moż­na go póź­niej zbu­do­wać w opar­ciu o model poję­cio­wy, jeże­li zaj­dzie taka potrze­ba, ale nie nale­ży tych dwóch mode­li sto­so­wać zamien­nie). Diagram klas opi­su­ją­cy taki sys­tem poję­cio­wy to tak zwa­na prze­strzeń poję­cio­wa (name­spa­ce) . Jak to wygląda:

Diagram klas, taksonomia

Od razu uwa­ga: powyż­szy dia­gram jest nad­mia­ro­wy, w real­nym pro­jek­cie bym tego tak nie nary­so­wał, ale po kolei.???

Podstawowe poję­cia (seman­ty­ka) ana­li­zo­wa­ne­go sys­te­mu to kla­sy ozna­czo­ne nie­bie­skim kolo­rem. Bardzo czę­sto zda­rza się, że pew­ne poję­cia moż­na lub nale­ży pokla­sy­fi­ko­wać, by prze­ka­zać infor­ma­cję o ist­nie­niu tej kla­sy­fi­ka­cji. Diagram ten moż­na wiec uzu­peł­nić na dwa spo­so­by: sto­su­jąc tak zwa­ne super­kla­sy (uogól­nie­nie, zebra­nie kil­ku wspól­nych cech) oraz tak zwa­ne ste­reo­ty­py, czy­li zna­cząc dodat­ko­wo kla­sy. Klasa uogól­nia­na nazy­wa­na jest spe­cja­li­za­cją. Na powyż­szym dia­gra­mie Zamówienie (spe­cja­li­za­cja) jest spe­cy­ficz­nym rodza­jem Dokumentu (uogól­nie­nie) a każ­dy doku­ment to coś będą­ce­go jakąś tre­ścią np. na papie­rze. Zamówienie jed­nak jest tak­że «obiek­tem biz­ne­so­wym», utrwa­lo­nym i zro­zu­mia­łym poję­ciem (bytem) w fir­mie, do cze­goś kon­kret­ne­go służy.

Jest pew­na seman­tycz­na róż­ni­ca pomię­dzy super-kla­są a ste­reo­ty­pem, gdyż uwa­żam, że tych pojęć nie moż­na sto­so­wać zamien­nie. Super-kla­sa poka­zu­je, że pew­ne byty są uogól­nia­ne (mają one jakieś wspól­ne cechy zebra­ne w tym uogól­nie­niu) i uogól­nie­nie to – jako poję­cie – jest sto­so­wa­ne w roz­mo­wie”. Stereotyp wska­zu­je na pew­ne ist­nie­ją­ce i istot­ne (chce­my to zako­mu­ni­ko­wać w doku­men­ta­cji) roz­róż­nie­nie pomię­dzy poję­cia­mi jed­nak nie jest ono sto­so­wa­ne w roz­mo­wie”. Można więc uznać, że poję­cie Dokument funk­cjo­nu­je w roz­mo­wie” na rów­ni z poję­ciem Zamówienie choć jest to poję­cie (Dokument) abs­trak­cyj­ne. Nie ist­nie­je coś takie­go jak ogól­ny doku­ment” ale poję­cie to jest powszech­nie sto­so­wa­ne w fir­mach, abs­trak­cje takie ozna­cza­my pisząc nazwę takiej kla­sy kur­sy­wą. Można tak­że powie­dzieć, że Zamówienie jest «obiek­tem biz­ne­so­wym» (coś istot­ne­go, uży­wa­ne­go) jed­nak raczej nikt nie uży­wa tego poję­cia na co dzień. Ten ste­reo­typ infor­mu­je czy­tel­ni­ka ana­li­zy, że to coś istot­ne­go (jakimś kontekście).

Wpłata jest zda­rze­niem, jed­nak zda­rze­nie to coś, co na co dzień nie jest trak­to­wa­ne jako rów­no­praw­ne sło­wo” w biz­ne­sie. Dlatego w tym przy­pad­ku w mode­lu użył­bym tyl­ko ste­reo­ty­pu «zda­rze­nie», by wska­zać, że jest to coś inne­go niż «obiekt biz­ne­so­wy» ale już nie użył bym, abs­trak­cyj­nej super­kla­sy Zdarzenie. Jeżeli jed­nak w toku pro­jek­to­wa­nia (etap po ana­li­zie) uzna­my, że chce­my prze­twa­rzać dane o tych zda­rze­niach zapro­jek­tu­je­my dla sys­te­mu kla­sę Zdarzenie.

Obiektem biz­ne­so­wym jest jed­nak Dowód Wpłaty (tak na praw­dę repre­zen­tu­je on to zda­rze­nie ale nie jest to toż­sa­me poję­cie: stwier­dze­nie wpła­ty nie jest dowo­dem wpła­ty). Te niu­an­se są bar­dziej oczy­wi­ste (mam nadzie­ję :)) na przy­kła­dzie klas Klient, Osoba, Pracownik, Sprzedawca. Widać tu tak­że ewi­dent­nie, że Klient jest wyłącz­nie Osobą.

Diagram ten zawie­ra tak­że pew­ne regu­ły biz­ne­so­we (ogra­ni­cze­nia entro­pii, czy­li swo­bo­dy). Są to liczeb­no­ści nanie­sio­ne na sko­ja­rze­nia (aso­cja­cje), linie łączą­ce kla­sy. Zaznaczono np. że Sprzedawca może mieć pod opie­ką klien­tów, tak­że żad­ne­go, jed­nak klient musi mieć i tyl­ko jed­ne­go opie­ku­na. Brak linii łączą­cej dwie kla­sy świad­czy zaś o tym, że nie ogra­ni­cza­ją się one nawza­jem w żaden spo­sób np. Wpłaty w żaden spo­sób nie wpły­wa­ją na Sprzedawcę i odwrot­nie. Istnieje jedy­nie pośred­ni zwią­zek mówią­cy, że moż­na sko­ja­rzyć Wpłatę ze Sprzedawcą, ele­men­tem koja­rzą­cym jest Faktura i jest ona tak­że kon­tek­stem tego sko­ja­rze­nia: Faktura jest pro­duk­tem pro­ce­su Sprzedaży, za któ­ry odpo­wia­da Sprzedawca. To jest powód, dla któ­re­go model pro­ce­sów powi­nien tak­że powstać jako jeden z pro­duk­tów takiej ana­li­zy bo to on zawie­ra tę wła­śnie informację.

Model dziedziny to projekt

A teraz model dzie­dzi­ny, przy­to­czę dia­gram uży­ty w poprzed­nim artykule:

Diagram klas, model dziedziny systemu

Jak widać jest pomię­dzy nimi istot­na róż­ni­ca. Jej źró­dłem jest to, że tak­so­no­mia to model poję­cio­wy zaś model dzie­dzi­ny (w rozu­mie­niu Model z wzor­ca MVC) to opis prze­twa­rza­nia. Przede wszyst­kim model dzie­dzi­ny nie zawie­ra pojęć abs­trak­cyj­nych. Dlaczego? No bo ich nie zapi­su­je­my i nie prze­twa­rza­my :)! Po dru­gie pew­ne poję­cia znik­nę­ły z mode­lu (Klient, jest akto­rem) bo Klient nie jest prze­twa­rza­ny, ale dane klien­ta będą atry­bu­ta­mi (nie zazna­czo­no) Zamówienia: jest on tu, Klient, zama­wia­ją­cym. Czytaj wię­cej o two­rze­niu i testo­wa­niu mode­lu dzie­dzi­ny.

Tak więc war­to zwró­cić uwa­gę na to, że dia­gram klas dia­gra­mo­wi nie rów­ny, to samo narzę­dzie może posłu­żyć do dwóch róż­nych celów w tej samej doku­men­ta­cji. Widać tak­że (mam nadzie­ję), że pró­ba poka­za­nia na jed­nym dia­gra­mie zarów­no sys­te­mu pojęć jak i spo­so­bu ich prze­twa­rza­nia, jako infor­ma­cji w sys­te­mach infor­ma­tycz­nych, jest raczej błęd­nym podej­ściem. Wydaje mi się, że podej­mo­wa­nie takich prób świad­czy o nie­zro­zu­mie­niu róż­ni­cy pomię­dzy sys­te­mem poję­cio­wym a mode­lem prze­twa­rza­nia infor­ma­cji. W szcze­gól­no­ści gdy doty­czy to sys­te­mów obiektowych.

Programistom pole­cam tak­że te stro­ny.


  1. ?*?
    https://​mar​tin​fow​ler​.com/​b​l​i​k​i​/​A​n​e​m​i​c​D​o​m​a​i​n​M​o​d​e​l​.​h​tml
  2. ???
    w 2015 roku zmie­ni­ła się spe­cy­fi­ka­cja UML, usu­nię­to poję­cie dzie­dzi­cze­nia i agre­ga­cji, suge­ru­ję uzu­peł­nić wie­dzę wpi­sa­mi, któ­re powsta­ły po 2015 roku. 

Źródła

Zelinski, J. (2020) Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns’, in Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities. IGI Global, pp. 78 – 89. Available at: https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699 (Accessed: 18 December 2019).
Fowler, M. (1997) Analysis pat­terns: reu­sa­ble object models. Menlo Park, Calif: Addison Wesley (The Addison-Wesley series in object-orien­ted softwa­re engineering).
Usman, M. et al. (2017) Taxonomies in softwa­re engi­ne­ering: A Systematic map­ping stu­dy and a revi­sed taxo­no­my deve­lop­ment method’, Information and Software Technology, 85, pp. 43 – 59. Available at: https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​i​n​f​s​o​f​.​2​0​1​7​.​0​1​.​006.
Stevens, P. (2007) UML Inżynieria opro­gra­mo­wa­nia. Translated by I. Jakóbik. Gliwice: Helion.
Booch, G., Rumbaugh, J. and Jacobson, I. (2002) UML prze­wod­nik użyt­kow­ni­ka. dru­gie wyda­nie. Warszawa: WNT (inży­nie­ria oprogramowania).