Model pojęciowy, model danych, model dziedziny systemu

Niemalże każ­de spo­tka­nie pro­jek­to­we, na któ­rym oma­wia­ne są mode­le UML, na każ­dym szko­le­niu na temat UML, poja­wia się pro­blem o któ­rym pisze Ron Ross (wytłusz­cze­nia moje):

Another impli­ca­tion is that con­cept models and logi­cal data models are cle­ar­ly distinct. Unfortunately, many people blur the line betwe­en them. That?s wrong. A con­cept model is abo­ut the meaning of the words you use, and the busi­ness sta­te­ments you make assu­ming tho­se meanings. It?s abo­ut com­mu­ni­ca­tion. A logi­cal data model is abo­ut how you orga­ni­ze what you think you know abo­ut the world so it can be recor­ded and logi­cal­ly mani­pu­la­ted in a sys­te­ma­tic way.I star­ted my care­er in data. It took me as much as 15 years of inten­se work on busi­ness rule sta­te­ments (1990 – 2005) to ful­ly appre­cia­te the dif­fe­ren­ce. But now I am very cle­ar that con­cept models do need to be deve­lo­ped to excru­cia­ting level of deta­il in order to disam­bi­gu­ate the inten­ded busi­ness communication.Most busi­nesses don?t do that today. They jump in at data design (con­cep­tu­al, logi­cal or even phy­si­cal). And they unk­no­win­gly pay a big pri­ce for it. (Źródło: Concept Model vs. Data Model ? Ron Ross on Business Rules)

Generalnie model poję­cio­wy, model danych to skraj­nie róż­ne mode­le. Jeżeli do tego doda­my dys­ku­sje na temat obiek­to­we­go mode­lu dzie­dzi­ny, to na spo­tka­niu mamy nie­mal­że gwa­ran­cje ostre­go sporu.

Widzę dwa głów­ne źró­dła tych pro­ble­mów. Pierwsze to fakt, że w szko­łach wyż­szych nadal kró­lu­je ana­li­za struk­tu­ral­na, a po maco­sze­mu trak­to­wa­na ana­li­za sys­te­mo­wa i obiek­to­wa (obie bazu­ją na kon­cep­cji współ­pra­cu­ją­cych obiek­tów i ope­ru­ją poję­ciem obiekt zaś ter­min” to poję­cie słow­ni­ko­we). Teoria sys­te­mów i opar­ty na niej para­dyg­mat obiek­to­wy są nie­ste­ty trud­ne, bazu­ją w 100% na her­me­ty­za­cji i abs­tra­ho­wa­niu od szcze­gó­łów, a ode­rwa­nie się od szcze­gó­łów więk­szo­ści ludziom przy­cho­dzi z ogrom­nym tru­dem albo nie uda­je się w ogó­le. Drugie to powszech­ne myle­nie kon­tek­stów słów ter­min” (poję­cie) i kon­cep­cja” (pomysł, idea) w lite­ra­tu­rze anglojęzycznej:

con­cept {rzecz.} (też: notion, idea, con­cep­tion, term) poję­cie {n.} Same con­cept, but looking at com­mu­ni­ca­tion dyna­mics in a very dif­fe­rent sphe­re. To samo poję­cie, ale patrząc na dyna­mi­kę komu­ni­ka­cji w zupeł­nie odmien­nej sferze.

con­cept {rzecz.} (też: con­cep­tion, idea) kon­cep­cja {f.} However, we ought to be awa­re that the con­cept of vic­ti­mi­sa­tion requ­ires strong pro­of. Musimy jed­nak być świa­do­mi, że kon­cep­cja repre­sjo­no­wa­nia wyma­ga moc­nych dowodów.

term {rzecz.} (też: notion, idea, con­cep­tion, con­cept) poję­cie {n.} Really cool term: neo­te­ny – the reten­tion of play and juve­ni­le tra­its in adults. Świetne poję­cie – neo­te­nia, zacho­wa­nie u doro­słych mło­dzień­czych cech i chę­ci do zabawy.

(źr. http://​pl​.bab​.la/​s​l​o​w​n​i​k​/​a​n​g​i​e​l​s​k​i​-​p​o​l​s​k​i​/​c​o​n​c​ept)

Do tego docho­dzą nota­cje i cza­sa­mi wręcz nie zro­zu­mie­nie ich seman­ty­ki i zasto­so­wa­nia. W oma­wia­nym obsza­rze od lat są sto­so­wa­ne dwie, od nie­daw­na trzy notacje:

  1. dia­gram związ­ków encji (naj­po­pu­lar­niej­sze nota­cje to Crow?s Feet” czy­li kurze stop­ki 🙂 i jej wer­sja zwa­na, nota­cją bar­ke­ra (Barker’s nota­tion, ERD, ang. Entity Relationship Diagram)
  2. dia­gram klas nota­cji UML (ang. Unified Modeling Language)
  3. dia­gram fak­tów (ang. SBVR, Semantics Of Business Vocabulary And Rules)

Pierwszy słu­ży do two­rze­nia mode­li w para­dyg­ma­cie rela­cyj­nym na trzech pozio­mach ogól­no­ści, wszyst­kie trzy są mode­la­mi danych (a nie pojęć):

  1. Conceptual data model
  2. Logical data model
  3. Physical data model

Diagram klas w nota­cji UML słu­ży do two­rze­nia modeli:

  1. poję­cio­wych (wszyst­kie dia­gra­my klas w spe­cy­fi­ka­cjach OMG to mode­le poję­cio­we opi­su­ją­ce seman­ty­ką i syn­tak­ty­kę danej notacji),
  2. mode­li obiek­to­wych (dia­gram obiek­tów) i ich meta­mo­de­li (dia­gram klas), są to tak zwa­ne mode­le dzie­dzi­ny sys­te­mu (logi­ka, mecha­nizm dzia­ła­nia apli­ka­cji, przed­się­bior­stwa, każ­de­go sys­te­mu w rozu­mie­niu teo­rii systemów),
  3. mode­li struk­tu­ry kodu apli­ka­cji (dia­gram klas).

Od nie­daw­na mamy nota­cje SBVR a w niej dia­gram Fact dia­gram”. Jest to dia­gram (nie jest to dia­gram klas UML, ale dia­gra­mu klas UML moż­na użyć by go zastą­pić) repre­zen­tu­ją­cy w for­mie gra­ficz­nej słow­nik pojęć i jest to spe­cy­ficz­ny model poję­cio­wy, opar­ty na tak zwa­nych związ­kach opar­tych na fak­tach (aso­cja­cje repre­zen­tu­ją tu fak­ty, któ­re kon­tek­sto­wo koja­rzą dane dwa poję­cia np. doku­ment opi­su­je zda­rze­nie, pod­kre­śle­nia wska­zu­ją na poję­cia ze słow­ni­ka (są w nim zde­fi­nio­wa­ne) o sło­wo pisa­ne kur­sy­wą to fakt, któ­ry je kon­tek­sto­wo koja­rzy (mode­le fak­tów to nie są ontologie).

Modele danych (np. dia­gra­my ERD) to struk­tu­ry poka­zu­ją­ce orga­ni­za­cję danych (infor­ma­cji). Mogą być na dużym pozio­mie abs­trak­cji w posta­ci wstęp­ne­go pomy­słu”, mogą być wypra­co­wa­nym mode­lem i mogą być mniej lub bar­dziej kom­pro­mi­so­wym pla­nem implementacji.

Obiektowy para­dyg­mat oraz ogól­na teo­ria sys­te­mów zakła­da­ją, że wszyst­ko to co obser­wu­je­my to pew­na więk­sza lub mniej­sza zło­żo­ność opi­sa­na jako skoń­czo­na licz­ba współ­pra­cu­ją­cych ele­men­tów (lub ich klas). Każdy ele­ment ma okre­ślo­ne cechy, każ­dy w okre­ślo­ny spo­sób reagu­je na bodź­ce z oto­cze­nia. Całkowitą zło­żo­ność wyzna­cza licz­ba tych ele­men­tów i pro­sto­ta lub jej brak, reak­cji na bodź­ce. Doskonale tłu­ma­czy to meta­fo­ra K.Poppera o zega­rach i chmurach:

Generalnie pro­blem zło­żo­no­ści ład­nie opi­sał Karl Popper, w swo­im dzie­le Wiedza Obiektywna meta­fo­rą ?o chmu­rach i zega­rach?. To co obser­wu­je­my, sys­tem, może być tak zło­żo­ne, że ilość obiek­tów i ich wza­jem­nych oddzia­ły­wań będzie zbyt duża, by moż­li­we było stwo­rze­nie mode­lu (teo­ria wyja­śnia­ją­ca zacho­wa­nie) takie­go sys­te­mu, pozwa­la­ją­ce­go na prze­wi­dy­wa­nie zacho­wa­nia takiej zło­żo­no­ści. Są jed­nak sys­te­my, któ­rych natu­ra na to pozwa­la, ich model jest moż­li­wy do stwo­rze­nia, takie sys­te­my są prze­wi­dy­wal­ne w 100%. Metaforą sys­te­mu nie­prze­wi­dy­wal­ne­go jest chmu­ra, a prze­wi­dy­wal­ne­go zegar. Oczywiście jest nie­skoń­cze­nie wie­le sys­te­mów o natu­rze gdzieś pomię­dzy chmu­ra­mi i zega­ra­mi. (Źródło: Wszystkie dro­gi pro­wa­dzą do Rzymu | | Jarosław Żeliński IT-Consulting)

Elementy sys­te­mu mają swo­je cechy (ukry­te: her­me­ty­za­cja) a uze­wnętrz­nia­ją wyłącz­nie reak­cje na bodź­ce (żąda­nia). W efek­cie sys­tem żyje” ale nie jest bazą danych”. UML i dia­gram klas, w tym wypad­ku, mode­lu­je współ­pra­cu­ją­ce obiek­ty a nie bazę danych”. To, że taka baza (każ­da for­ma utrwa­la­nia danych) fizycz­nie ist­nie­je (jest two­rzo­na) to wyłącz­nie sku­tek potrze­by jaką jest zapa­mię­ta­nie sta­nu sys­te­mu (apli­ka­cji).

Niewątpliwie jed­nak dia­gram klas UML nie jest mode­lem danych, i nie słu­ży do mode­lo­wa­nia danych… 

Model kom­po­nen­tu sys­te­mu, opi­su­ją­cy mecha­nizm jego dzia­ła­nia (logi­kę) to tak zwa­ny model dzie­dzi­ny” czy­li obiek­to­wy model sys­te­mu opi­su­ją­cy (mode­lu­ją­cy) mecha­nizm jego dzia­ła­nia. Owszem, apli­ka­cja może słu­żyć do zarzą­dza­nia duży­mi i zor­ga­ni­zo­wa­ny­mi zbio­ra­mi danych ale to to samo co zespół ludzi – sys­tem współ­pra­cu­ją­cych obiek­tów mają­cych – każ­dy – wie­le cech – zarzą­dza­ją­cy biblio­te­ką: Ci ludzie i ich cechy to nie baza danych” a ukry­te do ich wia­do­mo­ści cechy i umie­jęt­no­ści, dostęp­ne dla innych wyłącz­nie pod warun­kiem zada­nia pyta­nia i woli odpo­wie­dzi na nie, ci ludzie mogą zarzą­dzać” jakimś zbio­rem danych. 

Dlatego ubo­le­wam, gdy oso­by będą­ce nauczy­cie­la­mi aka­de­mic­ki­mi, tre­ne­ra­mi pro­wa­dzą­cy­mi szko­le­nia czy auto­ra­mi wie­lu uczo­nych” blo­gów, publi­ku­ją pomy­sły o mode­lo­wa­niu danych z uży­ciem UML… co nie ma nic wspól­ne­go z UML.

O SBVR, mode­lach poję­cio­wych i dia­gra­mie fak­tów pisa­łem w arty­ku­le SBVR czy­li regu­ły biz­ne­so­we i słow­nik. Kwestie dia­gra­mów klas opi­sa­łem mię­dzy inny­mi w arty­ku­le Cholerny dia­gram klas i w Czym jest a czym nie jest model dzie­dzi­ny. Jeśli zaś cho­dzi o to czym nie jest dia­gram ERD pisa­łem przy oka­zji Wiedza po stu­diach? Zostaliście oszukani?

Diagram obiektów czyli bottom-up

W toku nie­jed­nej ana­li­zy moż­na spo­tkać się z sytu­acją gdy stan­dar­do­we podej­ście pole­ga­ją­ce na bada­niu doku­men­tów i ana­li­zie zstę­pu­ją­cej (od ogó­łu do szcze­gó­łu, ang. top-down) może być trud­ne lub wręcz nie moż­li­we. Dotyczy to ana­li­zy sys­te­mów sła­bo udo­ku­men­to­wa­nych lub wręcz nie­udo­ku­men­to­wa­nych, gdzie jedy­ne dostęp­ne dane to obser­wa­cja lub rela­cja obser­wa­to­ra (uczest­ni­ka, itp. czy­li rela­cja z dru­giej ręki). Jest to sytu­acja podob­na to serii (pakie­tu) zebra­nych user sto­ry” (w nomen­kla­tu­rze meto­dyk zwin­nych histo­ryj­ki użyt­kow­ni­ka), nie­for­mal­nych rela­cji. Jak ugryźć taką sytuację?

Z pomo­cą przy­cho­dzi poję­cie spe­cy­fi­ka­cji instan­cji w UML, zapew­ne brzmi to strasz­nie ale nie jest tak źle. Cóż to jest ta spe­cy­fi­ka­cja instan­cji? Co mówi spe­cy­fi­ka­cja (UML v.2.5):

9.8 Instances
9.8.1 Summary
InstanceSpecifications repre­sent instan­ces of Classifiers in a mode­led sys­tem. They are often used to model exam­ple con­fi­gu­ra­tions of instan­ces. They may be par­tial or com­ple­te repre­sen­ta­tions of the instan­ces that they cor­re­spond to.

Generalnie rzecz w tym, by poka­zać to co wie­my czy­li kon­kret­ne nazwa­ne egzem­pla­rze tych rze­czy” o któ­rych ktoś mówi lub któ­re obser­wu­je­my. To egzem­pla­rze i ich spe­cy­fi­ka­cja (nazwy, cechy itp.). Innymi słowy

dia­gram obiek­tów słu­ży do poka­za­nia kon­kret­ne­go, obser­wo­wal­ne­go sta­nu rzeczy

Jeżeli więc z jakie­goś powo­du nie może­my ope­ro­wać uogól­nie­nia­mi (kla­sy) bo nie posia­da­my odpo­wied­niej wie­dzy lub jest ona zbyt ubo­ga, ana­li­zę moż­na pro­wa­dzić od dołu” czy­li mając szcze­gó­ły uogól­niać je. Poważną zale­tą tej meto­dy jest łatwość wery­fi­ka­cji mode­lu przez klien­ta”. Większość ludzi nie radzi sobie z abs­trak­cja­mi (np. meta­mo­de­le): mode­le budo­wa­ne z uży­ciem dia­gra­mów klas to uogól­nie­nia: opi­su­ją kla­sy a nie kon­kret­ną rze­czy­wi­stość. Diagramy obiek­tów (instan­cje klas) to nic inne­go jak mode­le kon­kret­nych sytu­acji” z życia.

Tak więc napi­szę tu kil­ka słów o bar­dzo mało popu­lar­nym dia­gra­mie UML: dia­gra­mie obiek­tów (spe­cy­fi­ka­cje instancji).

InstanceSpecUML25Notation
(źr. UML v.2.5, for­mal 15 – 03-01)

Powyższe przy­kła­dy to mode­le kon­kret­nych sytu­acji: mamy tu (od góry) kon­kret­ną uli­cę, kon­kret­ny adres, dwie oso­by i zwią­zek mię­dzy nimi (ojciec-syn) oraz tak zwa­ną war­tość (nazwa­ne kon­kret­ne war­to­ści to tak­że obiek­ty). Diagram obiek­tów zawie­ra więc prak­tycz­nie wyłącz­nie kon­kret­ne, nazwa­ne byty w opi­sy­wa­nej rze­czy­wi­sto­ści. Prawdę mówiąc bar­dzo wie­le, o ile nie więk­szość, sche­ma­tów blo­ko­wych wyko­ny­wa­nych w tak zwa­nych doku­men­tach biz­ne­so­wych i pre­zen­ta­cjach, to pew­ne nie­for­mal­ne dia­gra­my obiek­tów. Wszędzie tam gdzie na sche­ma­cie blo­ko­wym są kon­kret­nie nazwa­ne uni­kal­ne ele­men­ty łączo­ne róż­ny­mi for­ma­mi linii i strza­łek, moż­na mówić o przed­sta­wie­niu kon­kret­nej zma­te­ria­li­zo­wa­nej” sytuacji.

Typowym przy­kła­dem są sche­ma­ty orga­ni­za­cyj­ne. Poniżej jed­na z wie­lu dostęp­nych w sie­ci Internet struk­tur orga­ni­za­cyj­nych: są to kon­kret­ne nazwy orga­nów (np. Rada Nadzorcza), komó­rek orga­ni­za­cyj­nych i sta­no­wisk, np. jak na poniż­szym diagramie.

źr. http://www.darrwww.hb.pl/pl/1042/Kadra_i_struktura_organizacyjna/
źr. http://​www​.dar​rwww​.hb​.pl/​p​l​/​1​0​4​2​/​K​a​d​r​a​_​i​_​s​t​r​u​k​t​u​r​a​_​o​r​g​a​n​i​z​a​c​y​j​na/

Powyższy dia­gram do dość powszech­na for­ma doku­men­to­wa­nia struk­tu­ry orga­ni­za­cyj­nej. Poniżej wer­sja tej struk­tu­ry (okro­jo­na) w posta­ci dia­gra­mu obiektów:

Analiza stanu faktycznego_1

Są to dokład­nie te same blocz­ki”, na dia­gra­mie tym (UML, dia­gram obiek­tów) każ­dy ele­ment to instan­cja (kla­sy)”. Na tym eta­pie odwzo­ro­wu­je­my jedy­nie to co wie­my w for­mie jaką zna­my. Kolejny etap to szu­ka­nie zasad i klu­czo­wych dla nich pojęć, skla­sy­fi­ko­wa­nie obiek­tów odwzo­ro­wa­nych na diagramie:

Struktura organizacyjna - model pojeciowy

Powyższy dia­gram to dia­gram fak­tów (spe­cy­fi­ka­cja SBVR/OMG). Jest to model poję­cio­wy, skła­da się z pojęć słow­ni­ka (pojęć biz­ne­so­wych) i fak­tów łączą­cych te poję­cia, na ich pod­sta­wie two­rzo­ne są kla­sy i atry­bu­ty, do któ­rych przy­po­rząd­ko­wy­wa­ne są poszcze­gól­ne obiek­ty mode­lu ana­li­zo­wa­ne­go (dia­gra­mu obiektów):

Struktura organizacyjna - klasyfikacja obiektów

Powyżej obiek­to­wy model Struktury orga­ni­za­cyj­nej po uzu­peł­nie­niu o kla­sy­fi­ka­to­ry (każ­dy obiekt na dia­gra­mie został przy­po­rząd­ko­wa­ny do okre­ślo­nej kla­sy). Teraz moż­na opra­co­wać struk­tu­rę metamodelu:

Struktura organizacyjna - model dziedziny

Powyższy dia­gram to meta­mo­del tego co przed­sta­wia dia­gram obiek­tów (pier­wot­nie poka­za­na struk­tu­ra orga­ni­za­cyj­na). Teraz poja­wia się pyta­nie: co ma wyko­nać pro­gra­mi­sta (o ile takie jest zada­nie). Na tym eta­pie zro­zu­mie­li­śmy czym jest struk­tu­ra orga­ni­za­cyj­na i udo­ku­men­to­wa­li­śmy to, ale nadal nie roz­wią­za­li­śmy pro­ble­mu: jak to zaim­ple­men­to­wać (powyż­sze nie jest żad­nym wyma­ga­niem imple­men­ta­cji dla programisty).

Teraz mamy dwa wyj­ścia (pew­nie są też inne): potrak­to­wać powyż­sze jako meta­mo­del struk­tu­ry orga­ni­za­cyj­nej, użyć go, po uzu­peł­nie­niu o ogra­ni­cze­nia, jako recep­ty” dla fabry­ki struk­tu­ry orga­ni­za­cyj­nej”, uzu­peł­nić o kla­sy two­rzą­ce tę struk­tu­rę (wspo­mnia­ną fabry­kę) i dokoń­czyć model dzie­dzi­ny sys­te­mu”, albo poprze­stać na tym eta­pie, spi­sać regu­ły biz­ne­so­we” i w tej for­mie prze­ka­zać deve­lo­pe­ro­wi (wte­dy on sam musi roz­wią­zać pro­blem meto­dy imple­men­ta­cji). Jedno jest pew­ne: nie jest to abso­lut­nie żaden model danych.

Tak więc ana­li­za od szcze­gó­łu do ogó­łu” cza­sa­mi bywa bar­dzo pomoc­na. Pozwala wyjść od kon­kret­ne­go rze­czy­wi­ste­go sta­nu świa­ta” i opra­co­wać na jego pod­sta­wie model poję­cio­wy i meta­mo­del. To bar­dzo pomoc­na tech­ni­ka. Warto pamię­tać, że to co nie raz nazy­wa­ne jest mode­lem dzie­dzi­ny” jed­nak nim nie jest.

Proces a zdolność do wytworzenia

Wiele pro­jek­tów, w któ­rych powsta­ją doku­men­ty zwią­za­ne z pro­ce­sa­mi biz­ne­so­wy­mi (mode­le, mier­ni­ki, reor­ga­ni­za­cja itp.), ope­ru­je poję­cia­mi, poza oczy­wi­ście pro­ce­sem biz­ne­so­wym, taki­mi jak zdol­ność do reali­za­cji, funk­cje, zaso­by, pro­duk­ty. Często są one na tyle źle (nie­pre­cy­zyj­nie) zde­fi­nio­wa­ne (cza­sem źle tłu­ma­czo­ne z lite­ra­tu­ry ang.), że doku­men­ty te są nie­jed­no­znacz­ne a spo­tka­nia robo­cze bywa­ją bar­dzo emocjonalne.

Problem ten jest dość powszech­ny na świe­cie, co moż­na było zaob­ser­wo­wać na stro­nach por­ta­lu LinkedIn, gdzie powsta­ła dys­ku­sja na temat tego czym jest pro­ces two­rze­nia pro­duk­tu a czym posia­da­na zdol­ność do jego wytwo­rze­nia (pro­ces­ses and capa­bi­li­ties). Na stro­nach por­ta­lu BPTrends, jeden z jego głów­nych auto­rów, Paul Harmon, opi­sał to i pod­su­mo­wał (pole­cam cały artykuł):

There has been a lot of discus­sion on the rela­tion­ship betwe­en pro­ces­ses and capa­bi­li­ties. I can?t offer a defi­ni­ti­ve solu­tion to discus­sion becau­se some of the defi­ni­tions of ?capa­bi­li­ties? are incom­pa­ti­ble with one ano­ther. What fol­lows, howe­ver, is my take on what I belie­ve to be the most use­ful appro­ach to defi­ning and using capa­bi­li­ties in a pro­cess-focu­sed envi­ron­ment. (źr. BPTrends | Harmon on BPM: Processes and Capabilities).

W swo­ich pro­jek­tach czę­sto two­rzę mode­le pro­ce­sów biz­ne­so­wych i mode­le moty­wa­cji biz­ne­so­wej (two­rząc mode­le archi­tek­tu­ry biz­ne­so­wej, kor­po­ra­cyj­nej), muszę w tym zagwa­ran­to­wać ich jednoznaczność.

Nie raz pisa­łem tu o defi­ni­cji poję­cia pro­ces biz­ne­so­wy, sto­sun­ko­wo rzad­ko – poja­wia się przy oka­zji mode­li moty­wa­cji biz­ne­so­wej – o defi­ni­cji poję­cia capa­bi­li­ties czy­li zdol­ność do” lub poten­cjał”. Jest to okre­ślo­na cecha orga­ni­za­cji (są to akty­wa orga­ni­za­cji). Jest to kon­se­kwen­cja posia­da­nia okre­ślo­nych zaso­bów. Innymi sło­wy posia­da­nie na liście płac pra­cow­ni­ka potra­fią­ce­go dobrze goto­wać (zasób ludz­ki posia­da­ją­cy okre­ślo­ne umie­jęt­no­ści, peł­nią­cy funk­cje kucha­rza), orga­ni­za­cja ta ma zdol­ność (poten­cjał) do ser­wo­wa­nia zna­ko­mi­tych potraw. Jeżeli zde­cy­du­je się to robić, to będzie to pro­ces ser­wo­wa­nia tych potraw (pro­dukt pro­ce­su). Pojęcia te razem sta­no­wią pew­ną prze­strzeń nazw”. Ważne by rozu­mieć nie tyl­ko te poję­cia, ale tak­że to, by rozu­mieć, że w doku­men­ta­cji opi­sją­cej model orga­ni­za­cji sto­so­wać te poję­cia muszą być tak zde­fi­nio­wa­ne by nie powo­do­wać nie­jed­no­znacz­no­ści, muszą się więc wza­jem­nie wyklu­czać (zasa­da wyłą­czo­ne­go środ­ka w logi­ce), a jako całość muszą sta­no­wić kom­plet­ny słow­nik do opi­sa­nia okre­ślo­nej rze­czy­wi­sto­ści (prze­strzeń nazw). Poniżej model poję­cio­wy obra­zu­ją­cy te poję­cia i związ­ki mię­dzy nimi (dia­gram fak­tów nota­cji SBVR):

Ontologia proces biznesowy zdolnosc

Uznając, że poję­cia te (ich defi­ni­cje) wza­jem­nie się wyklu­cza­ją (co musi­my zagwa­ran­to­wać sto­su­jąc je razem w jed­nej doku­men­ta­cji) uzy­sku­je­my kla­row­ny sys­tem nazy­wa­nia ele­men­tów orga­ni­za­cji, zarów­no na pozio­mie mode­li BMM (model moty­wa­cji biz­ne­so­wej) jak i mode­li pro­ce­sów, gdzie pro­ces biz­ne­so­wy i akty­wa (BMM), jaki­mi są zaso­by oraz zdol­no­ści do cze­goś, a tak­że pro­duk­ty ofe­ro­wa­ne na ryn­ku, to odręb­ne pojęcia.

Dbałość o jed­no­znacz­ność i spój­ność doku­men­ta­cji to klu­czo­wa cecha ana­li­ty­ka, pisa­łem o tym mię­dzy inny­mi w arty­ku­le o tępie­niu nie­jed­no­znacz­no­ści. Uznawanie, że to nie waż­ne, dopusz­cza­nie do nie­pre­cy­zyj­nych defi­ni­cji, uzna­wa­nie tych pojęć za bli­sko­znacz­ne czy wręcz syno­ni­my, pro­wa­dzi nie tyl­ko do emo­cji w roz­mo­wach, ale tak­że do nie­przy­dat­no­ści two­rzo­nych dokumentów.

c.d. nt. Architektury Korporacyjnej

Architektura Korporacyjna (AK), bar­dzo mod­ny ostat­nio temat. Tym razem o … no wła­snie. Co do poję­cia Architektura Korporacyjna, nabie­ram prze­ko­na­nia, że to ?po pro­stu? pew­na (orga­ni­za­cyj­na, biz­ne­so­wa) spe­cja­li­za­cja poję­cia System (zespół ele­men­tów współdziałających).

Jeżeli uzna­my (zgo­dzi­my się), że celem ist­nie­nia orga­ni­za­cji są jej pro­duk­ty (war­tość jaka dostar­cza) a nie infor­ma­cje jakie prze­twa­rza (bo te są jedy­nie środ­kiem, narzę­dziem osią­ga­nia celu: są wtór­ne wobec powyż­sze­go celu), to kon­se­kwen­cją jest uzna­nie, że Archi­tek­tu­ra Korporacyjna to opis orga­ni­za­cji, a nie coś co trze­ba stwo­rzyć (stwo­rzyć nale­ży opis Architektury a nie Architekturę). Pamiętamy tak­że, że two­rze­nie mode­li ist­nie­ją­cych orga­ni­za­cji nie two­rzy tych orga­ni­za­cji a jedy­nie je opi­su­je. (parz: Teoria komu­ni­ka­cji, dżun­gla ram i szkie­le­tów).

Co i jak dokumentować

W defi­ni­cjach AK czę­sto spo­ty­ka­my czte­ry poję­cia: ludzie, pro­ce­sy, infor­ma­cje, tech­ni­ka. Zróbmy pro­sty model poję­cio­wy dla tych pojęć:

Model pojęciowy czterech elementow architektury korporacyjjnej

Kilka uwag: nie połą­czy­łem bez­po­śred­nio ludzi z tech­ni­ką, gdyż tech­ni­ka to narzę­dzie pra­cy, a więc słu­ży ono do cze­goś czło­wie­ko­wi. Tym co łączy czło­wie­ka z tech­ni­ką jest cele jej uży­cia. Druga uwa­ga: pro­ce­sy i infor­ma­cje to abs­trak­cje, mate­rial­ne są dane (i ich nośni­ki) oraz pro­duk­ty (to co orga­ni­za­cja dostar­cza swo­im klien­tom, nawet usłu­gi są mate­ria­li­zo­wa­ne ich opi­sem). Umieściłem na dia­gra­mie tak­że doku­men­ty i regu­ły biz­ne­so­we by nadać kon­tekst danym i pro­ce­som. Gdyby zaś uznać, że pro­ces biz­ne­so­wy (zgod­nie z jego defi­ni­cją) to tak­że pro­duk­ty i regu­ły biz­ne­so­we, zaś dane jed­nak zawsze repre­zen­tu­ją jakieś obiek­ty biz­ne­so­we (doku­men­ty), to wszyst­kie poję­cia na tym dia­gra­mie sta­ją ele­men­ta­mi AK.

W lite­ra­tu­rze na temat AK poja­wia się tak­że stwier­dze­nie, mówią­ce że w ramach ana­li­zy i doku­men­to­wa­nia AK nale­ży brać pod uwa­gę stra­te­gię fir­my a więc tak­że, będą­cą jej źró­dłem, moty­wa­cję biz­ne­so­wą (model biznesowy).

Po co doku­men­to­wać (mode­lo­wać) AK? Przede wszyst­kim po to by zro­zu­mieć jak dzia­ła orga­ni­za­cja, a potem by móc świa­do­mie, zna­jąc ryzy­ko, podej­mo­wać decy­zje o wpro­wa­dza­niu zmian do niej. 

Na powyż­szym dia­gra­mie ciem­nym kolo­rem zazna­czo­no dane biz­ne­so­we, ludzi i tech­ni­kę. To nama­cal­ne (mate­rial­ne) ele­men­ty każ­dej orga­ni­za­cji, mają one prak­tycz­nie zawsze swo­ją doku­men­ta­cję: ludzie w posta­ci struk­tu­ry orga­ni­za­cyj­nej, dane biz­ne­so­we w posta­ci wzo­rów doku­men­tów, tech­ni­kę w posta­ci reje­stru mająt­ku trwa­łe­go (przy­po­mi­nam, że pro­ce­sy i infor­ma­cje to byty abs­trak­cyj­ne). Wystarczy więc sko­ja­rzyć ze sobą te trzy obsza­ru (spi­sy) per ele­ment i otrzy­ma­my pierw­szy opis poka­zu­ją­cy co z czym jest powią­za­ne czy­li co i na co ma wpływ.

Problem w tym, że taki opis z jed­nej stro­ny jest zbyt szcze­gó­ło­wi do bie­żą­cej pra­cy z nim. By jaka­kol­wiek ana­li­za była w ogó­le wyko­ny­wal­na nale­ży ten opis spro­wa­dzić (uogól­nić) do roz­sąd­nie małej licz­by” obiek­tów. Aby to zro­bić nale­ży wpro­wa­dzić pew­ne abs­trak­cie, ukry­wa­ją­ce przez nami zbęd­na szcze­gó­ło­wość. Te abs­trak­cje to wła­sne infor­ma­cje i pro­ce­sy. Ludzi zaś i tech­ni­kę uogól­nia­my odpo­wied­nio do ele­men­tów struk­tu­ry orga­ni­za­cyj­nej i apli­ka­cji (któ­re, w przy­pad­ku tech­ni­ki IT ukry­wa­ją” przez nami koniecz­ny do ich ist­nie­nia sprzęt).

Przy oka­zji: czę­sto moż­na usły­szeć, że orga­ni­za­cja to ludzie. Zgadzam się z tym, pro­szę zwró­cić uwa­gę, że mój powyż­szy model poję­cio­wy jest antropocentryczny.

Z per­spek­ty­wy orga­ni­za­cji, każ­da ana­li­za wpły­wu zmia­ny, będzie wyma­ga­ła zro­zu­mie­nia tego co ma wpływ na pro­dukt – to on nie­sie war­tość ryn­ko­wą. Jak widać mamy pro­sty łań­cu­szek” poka­zu­ją­cy, że łącza się kolej­no: pro­dukt, pro­ces go two­rzą­cy, ludzie reali­zu­ją­cy pro­ces, infor­ma­cje jakich czło­wiek wyma­ga, dane nio­są­ce te infor­ma­cje i tech­ni­ka zarzą­dza­ją­ca tymi dany­mi. Przerwanie tego łań­cu­cha spo­wo­du­je prze­rwa­nie dostar­cza­nia pro­duk­tu dla­te­go war­to go dokład­nie zro­zu­mieć i zarzą­dzać nim (pano­wać nad nim).

Tak więc AK to doku­men­ta­cja, model, zawie­ra­ją­ca całą i wystar­cza­ją­cą wie­dzę o tym, co ma wpływ na dostar­cza­nie produktu.

Można do tego jesz­cze dodać ele­men­ty mode­lu biz­ne­so­we­go, któ­ry uza­sad­ni nam dostar­cza­nie takie­go a nie inne­go pro­duk­tu i mamy kom­plet. Od cze­go nale­ży zacząć? Od zbu­do­wa­nia wła­snej (lub wybo­ru ) meto­dy­ki two­rze­nia tej doku­men­ta­cji oraz zatrud­nie­niu Architekta. (c.d. Jak roz­ma­wiać z biz­ne­sem nt. Architektury Korporacyjnej).

Czy to musi być jakiś stan­dard np. TOGAF? Nie jestem prze­ko­na­ny. ArchiMate (nota­cja zale­ca­na w TOGAF) to nic inne­go jak sys­tem poję­cio­wy. Czy mamy wybór? Oczywiście, że mamy. Od daw­na OMG dostar­cza spraw­dzo­ne i otwar­te stan­dar­dy notacyjne. 

Co mamy w ?skrzyn­ce narzę­dzio­wej OMG? (www​.omg​.org)? Ludzie i pro­ce­sy to nic inne­go jak BPMN i struk­tu­ra orga­ni­za­cyj­na (ta dru­ga w BPMN lub jako sfor­ma­li­zo­wa­ny orga­ni­gram). Informacje i tech­ni­ka to nic inne­go jak UML i dia­gra­my struk­tu­ral­ne. (Architektura kor­po­ra­cyj­na z OMG​.org). W razie potrze­by udo­ku­men­to­wa­nia stra­te­gii (moty­wa­cji biz­ne­so­wej) mamy nota­cje BMM. Notacje, któ­re ?wpa­dły? w ręce OMG maja też bar­dzo pożą­da­ną i przy­jem­ną cechę: są ze sobą kom­pa­ty­bil­ne i uzu­peł­nia­ją się (czy­taj Semantic Core).

Ale o tym, AK z OMG jak widać już pisałem :).

Produkty w procesie analizy wymagań

W arty­ku­le Inżynieria wyma­gań mię­dzy inny­mi opu­bli­ko­wa­łem tak­so­no­mię wyma­gań, jej roz­wi­nię­ta postać:

taksonomia wymagań

Temat wyma­gań regu­lar­nie wypły­wa na forach dys­ku­syj­nych i na kon­fe­ren­cjach. Ostatnio w podob­nej for­mie poja­wił się na pew­nym forum ser­wi­su LinkedIn i na dzi­siej­szej kon­fe­ren­cji. Na forum padło pyta­nie: co wybrać jako doku­men­ta­cje wyma­gań: SRS czy Use Case (odpo­wied­nio [[Software Requirements Specification]] czy­li [[spe­cy­fi­ka­cja wyma­gań na opro­gra­mo­wa­nie]] i Przypadki Użycia opro­gra­mo­wa­nia). Na dzi­siej­szej kon­fe­ren­cji zaś praw­nik, pod­czas swo­je­go refe­ra­tu, zwró­cił uwa­gę na fakt, że od stro­ny umów, pro­jek­ty – od ana­li­zy przed­wdro­że­nio­wej do dostar­cze­nia zamó­wio­ne­go opro­gra­mo­wa­nia – nale­ży dzie­lić pro­jekt na fazy będą­ce, zależ­nie od celu, umo­wą efek­tu (umo­wa o dzie­ło) i umo­wą sta­ran­ne­go dzia­ła­nia (umo­wa zlecenia).

Problem w tym, że SRS – czę­sto rozu­mia­ne jako doku­ment o struk­tu­rze opi­sa­nej w [[reko­men­da­cji IEEE830]], zawie­ra w pew­nej for­mie przy­pad­ki uży­cia (ale nie ich sce­na­riu­sze) rozu­mia­ne jako opis funk­cjo­nal­no­ści. Do tego reko­men­da­cja ta nie jest stan­dar­dem zawar­to­ści doku­men­tu a rekomendacją. 

SRS_IEEE830-1998Topics

Pojęcie przy­pad­ku uży­cia ma co naj­mniej dwie zupeł­nie róż­ne defi­ni­cje: jed­ną rodem z książ­ki Alistair’a Cockbourna Jak pisać efek­tyw­ne przy­pad­ki uży­cia”, dru­ga w spe­cy­fi­ka­cji nota­cji UML. Osobiście pre­fe­ru­ję te dru­gą i tyl­ko o nie będzie tu mowa (Cockbourn zresz­tą jaw­nie wyra­ża nie­chęć do UML w swo­jej książce).

Dla upo­rząd­ko­wa­nia dal­szej tre­ści przyj­mu­ję, że poję­cie przy­pa­dek uży­cia opro­gra­mo­wa­nia i funk­cjo­nal­ność opro­gra­mo­wa­nia są toż­sa­me (a kon­kret­nie przy­pa­dek uży­cia opi­su­je spo­sób reali­za­cji funk­cjo­nal­no­ści): obie okre­śla­ją to jaki efekt chce osią­gnąć (do cze­go użyć), w kon­kret­nym przy­pad­ku, użyt­kow­nik opro­gra­mo­wa­nia (kon­kret­na funk­cja jaką peł­ni opro­gra­mo­wa­nie, to jego moż­li­wy przy­pa­dek użycia).

Popatrzmy na eta­py pro­jek­tu, któ­re wyróż­nio­no na bazie tego, jakiej wie­dzy potrze­bu­je­my na każ­dym z tych eta­pów, by zapla­no­wać kolejny.

Etapy projektu

Jako pierw­sze powsta­ją wyma­ga­nia biz­ne­so­we opra­co­wa­ne na bazie oce­ny sytu­acji biz­ne­so­wej. Są one albo wła­snym pro­duk­tem Zamawiającego albo pro­duk­tem zatrud­nio­ne­go do tego celu eks­per­ta. Na bazie wyma­gań biz­ne­so­wych (celów biz­ne­so­wych) wyko­nu­je się ana­li­zę wyko­ny­wal­no­ści tych celów, powsta­je pomysł roz­wią­za­nia pro­ble­mu (osią­gnię­cia celu) w posta­ci wyma­gań wobec reko­men­do­wa­ne­go roz­wią­za­nia. Jeżeli ist­nie­je (zna­le­zio­no) na ryn­ku roz­wią­za­nie (pro­dukt lub stan­dar­do­wą usłu­gę) zosta­je ono zaku­pio­ne i wdro­żo­ne. Jeżeli nie (doty­czy nie tyl­ko cało­ści ale i czę­ści wyma­gań) nale­ży roz­wią­za­nie naj­pierw zapro­jek­to­wać a potem dopie­ro zle­cić wyko­na­nie i wdro­że­nie (a wcze­śniej na bazie pro­jek­tu wycenić).

Każdy z tych pro­duk­tów to przed­miot osob­nej umo­wy (lub jej eta­pu). Zależnie od stop­nia nie­wie­dzy” po stro­nie Zamawiającego, może to być umo­wa o dzie­ło lub zle­ce­nia. Jednak zale­ca się (praw­ni­cy zale­ca­ją) by, zawsze tam gdzie anga­żo­wa­ny jest eks­pert (usłu­go­daw­ca) zewnętrz­ny, sto­so­wać umo­wy o dzie­ło (umo­wa efek­tu), gdyż pozwa­la to pano­wać i nad cza­sem i nad budże­tem pro­jek­tu oraz w przy­pad­ku spo­ru sądo­we­go, moż­li­we było okre­śle­nie przed­mio­tu spo­ru (opis tego co mia­ło zostać wytwo­rzo­ne – dzieło).

Do zawar­cia umo­wy o dzie­ło koniecz­ny jest opis tego co ma powstać (opis dzie­ła). Patrząc od koń­ca: zawie­ra­jąc umo­wę z dostaw­cą opro­gra­mo­wa­nia mamy wyma­ga­nia wobec pro­duk­tu goto­we­go (w momen­cie zaku­pu speł­nia je lub nie) lub wyko­na­ny pro­jekt tego co ma powstać. Aby powstał pro­jekt musi­my mieć okre­ślo­ne wyma­ga­nia wobec roz­wią­za­nia i wyma­ga­nia (cele) biz­ne­so­we. Najtrudniej jest wyce­nić etap ana­li­zy sytu­acji biz­ne­so­wej bo tu w zasa­dzie nie wie­my jaka ta sytu­acja jest. Wymagania biz­ne­so­we, by powsta­ły, wyma­ga­ją pozy­ska­nia wie­dzy o tym jak funk­cjo­nu­je orga­ni­za­cja Zamawiającego i jakie zmia­ny pla­nu­je. To etap ana­li­zy biz­ne­so­wej (model moty­wa­cji biz­ne­so­wej i mode­le pro­ce­sów biz­ne­so­wych). W tym wypad­ku będzie to raczej umo­wa sta­ran­ne­go dzia­ła­nia z eks­per­tem, któ­ry tę ana­li­zę (i mode­le) wykona.

Pewnym roz­wią­za­niem pro­ble­mu ryzy­ka umo­wy czas i mate­riał” (nie wie­my kie­dy i jakim kosz­tem powsta­nie ocze­ki­wa­ny pro­dukt), jest okre­śle­nie tego jaki kon­kret­nie pro­dukt ma powstać (opis tego, jak stwier­dzi­my, że pra­ce wyko­na­no popraw­nie) i okre­śle­nia cza­su jaki sobie na to daje­my. Wymaga to pew­nej inwe­sty­cji, poświę­ce­nia cza­su na to, ale opła­ci się bo moc­no obni­ża­my ryzy­ko projektu.

Konkluzja praw­ni­ka, by zawie­rać umo­wy o dzie­ło jeże­li tyl­ko jest to moż­li­we, jest moim zda­niem słusz­na. Tam gdzie nie mamy wystar­cza­ją­cej wie­dzy by zawie­rać takie umo­wy, war­to zain­we­sto­wać czas by okre­ślić jed­nak przed­miot umo­wy, gdyż umo­wa zle­ce­nia z eks­per­tem (dostaw­cą opro­gra­mo­wa­nia) powo­du­je, że Zamawiający kom­plet­nie nie panu­je nad umo­wą: nie wie jakie­go pro­duk­tu ocze­ki­wać, satys­fak­cja z wyko­na­nej pra­cy może nadejść w trud­nym do prze­wi­dze­nia czasie.

Druga uwa­ga: jeże­li cały pro­ces, od pierw­szej ana­li­zy do dostar­cze­nia pro­duk­tu, reali­zu­je jed­na fir­ma, mamy do czy­nie­nia z sytu­acją, w któ­rej dostaw­ca sam kon­tro­lu­je sta­wia­ne mu wyma­ga­nia bo sam sobie defi­niu­je to co ma następ­nie wytwo­rzyć. Taki brak kon­tro­li rodzi poważ­ne ryzy­ko nierzetelności.

Pojęcia, reguły i fakty czyli o czym oni mówią…

Niedawno napi­sa­łem:

opro­gra­mo­wa­nie repre­zen­tu­je narzę­dzie pra­cy, więc pro­jekt tego opro­gra­mo­wa­nia raczej powi­nien zawie­rać poję­cie (kla­sę) Kartoteka Pracowników a nie Pracownicy. (Dlaczego nie podo­ba mi się kla­sa Pracownik?).

To sta­ły temat wie­lu dys­ku­sji z pro­gra­mi­sta­mi. Ostatnio, po pew­nym szko­le­niu, w ramach wspar­cia po szko­le­niu jakie zawsze świad­czę, zno­wu padło pytanie:

Czy zda­rza Ci się robić analizy/projekty, gdzie byty wystę­pu­ją pod nazwa­mi inny­mi niż uży­wa­ny­mi potocz­nie przez Biznes.

Z tym – uży­wa­ne poję­cia – jest regu­lar­nie duży pro­blem, dla­te­go od pew­ne­go cza­su orto­dok­syj­nie sto­su­ję budo­wa­nie prze­strze­ni poję­cio­wej” dla pro­jek­tu ([[Semantics of Business Vocabulary and Business Rules]]). Buduję słow­nik pojęć, listę reguł biz­ne­so­wych (to nie to samo co regu­ły decy­zyj­ne) oraz tak zwa­ny dia­gram fak­tów, któ­ry słu­ży do testo­wa­nia (i doku­men­to­wa­nia słow­ni­ka) – upew­nie­nia się, że poję­cia nie koli­du­ją ze sobą a ich defi­ni­cje nie nakła­da­ją się na sie­bie oraz, że lista jest dzie­dzi­no­wo kom­plet­na. Po co to? Właśnie po to,

by żad­ne zde­fi­nio­wa­ne sło­wo nie mia­ło w pro­jek­cie (w wyma­ga­niach, w kodzie) wię­cej niż jed­ne­go zna­cze­nia i by zna­cze­nie każ­de­go zefi­nio­wa­ne­go poję­cia nie budzi­ło żad­nych wątpliwości

(co nie­co o słow­ni­kach ter­mi­nów: Reguły biz­ne­so­we jako motor ste­ru­ją­cy orga­ni­za­cji: fak­ty + defi­ni­cje pojęć).

Jedna uwa­ga na począ­tek: jeże­li byty” (kla­sy) w kodzie (pro­jek­cie) opro­gra­mo­wa­nia wystę­pu­ją pod inny­mi nazwa­mi niż w rze­czy­wi­sto­ści, to jest to abso­lut­na poraż­ka, bo pro­gra­mi­sta zupeł­nie tra­ci kon­takt z klien­tem i (lub) doku­men­ta­cją opi­su­ją­ca wyma­ga­nia. Jeżeli już koniecz­nie pro­gra­mi­sta musi ulżyć sobie w ambi­cji uży­wa­nia wyłącz­nie j.angielskiego w kodzie, powi­nien ten kod być boga­to komen­to­wa­ny, by nie było wąt­pli­wo­ści jakie znacz­nie nie­sie np. nazwa kla­sy czy atry­bu­tu (tym bar­dziej, że np. sło­wo name to nie tyl­ko nazwisko.….)

http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471
źr. http://​www​.moder​na​na​lyst​.com/​R​e​s​o​u​r​c​e​s​/​B​u​s​i​n​e​s​s​A​n​a​l​y​s​t​H​u​m​o​r​/​t​a​b​i​d​/​2​1​8​/​D​e​f​a​u​l​t​.​a​s​p​x​?​A​r​t​i​c​l​e​T​y​p​e​=​A​r​t​i​c​l​e​V​i​e​w​&​A​r​t​i​c​l​e​I​D​=​2​471

Słownik pojęć (czę­sto wystę­pu­je w doku­men­tach jako czy­sto pol­skie sło­wo glos­sa­riusz ;)) bywa czę­sto przed­mio­tem burz­li­wych nego­cja­cji, bo nie raz (a w zasa­dzie zawsze ;)) biz­nes sto­su­je slang, w któ­rym to samo sło­wo ma róż­ne zna­cze­nie, zależ­nie od kon­tek­stu uży­cia. Może to mieć sens w języ­ku mówio­nym gdy peł­na treść wypo­wie­dzi daje ten kon­tekst, ale na pozio­mie ana­li­zy i pro­jek­tu każ­de poję­cie musi mieć jed­no uni­kal­ne znacz­nie mimo bra­ku kon­tek­stu (tym bar­dziej, że np. nazwy klas nie są ele­men­ta­mi peł­nych zdań ani opowieści :)).

Pamiętam pro­jekt, w któ­rym wice­pre­zes pew­nej fir­my na każ­de dzia­ła­nie takie jak nowa umo­wa, nowy pro­jekt, nowy klient, uży­wał sło­wa temat”, nikt nie miał odwa­gi powie­dzieć mu, że nie raz nie rozu­mie o czym on mówi … Ja – obcy – się odwa­ży­łem 🙂 i upo­rząd­ko­wa­li­śmy to, był opór ;). Pamiętam, że dyplo­ma­tycz­nie popro­si­łem go by zbu­do­wał hie­rar­chię tema­tów” nazy­wa­jąc każ­dy ele­ment tej hie­rar­chii jed­nym lub dwo­ma sło­wa­mi sło­wa­mi i pomo­gło :), Słownik pojęć to negocjacje 🙂

Evans (DDD ) zapo­cząt­ko­wał bar­dzo cie­ka­we podej­ście, ono się roz­wi­ja. Co cie­ka­we Evans nie wymy­ślił idei a sys­tem wzor­ców DDD. Wspólny język to dwa ele­men­ty: uży­wa­nie biz­ne­so­wych nazw (bez skró­tów) na ele­men­ty rze­czy­wi­ste i kla­sy w sys­te­mie, ale tak­że uży­wa­nie np. poję­cia fabry­ka” przez biz­nes i przez deve­lo­pe­ra jako kon­te­ner” na pewien rodzaj kom­pe­ten­cji (wie­dza o tym jak powsta­ją pew­ne obiek­ty biznesowe).

Elementy wzor­ca DDD to nie tyl­ko blo­ki kodu, to tak­że ele­men­ty (kla­sy­fi­ka­to­ry) wie­dzy o biz­ne­sie. Faktura VAT to agre­gat – struk­tu­ra infor­ma­cji, to tyl­ko wie­dza o tym co ten doku­ment zawie­ra, ale FabrykaFaktur to odręb­na wie­dza o tym jak ten doku­ment jest two­rzo­ny. Należy świa­do­mie udo­ku­men­to­wać oba byty: doku­ment i recep­ta jego two­rze­nia. Dlaczego osob­no? Bo po pierw­sze wysta­wio­ne fak­tu­ry żyją wła­snym, życiem i obcią­ża­nie każ­dej z nich (np. tysiąc fak­tur mie­sięcz­nie) całą wie­dza jak powsta­ła nie ma więk­sze­go sen­su. Po dru­gie zmia­na prze­pi­sów nie powin­na się odbić na doku­men­tach już wysta­wio­nych ani docią­żyć nowo powstających.

Biznes tak­że musi zro­zu­mieć, że ma dwa róż­ne ele­men­ty opi­su swo­ich dzia­łań: pra­ca z doku­men­ta­mi i two­rze­nie doku­men­tów. Jednak uzna­nie tego fak­tu to jed­no, nie wie­rzę w to, że biz­nes się tego nauczy, bo nie nauczył się for­mal­ne­go opi­su lub mode­lo­wa­nia pro­ce­sów pod­czas wdro­żeń ISO, jed­nak uwa­żam, że biz­nes nie ma takiej potrze­by. Moim zda­niem od dobre­go ana­li­ty­ka nie ma uciecz­ki, to inna kom­pe­ten­cja. Nie ma uciecz­ki od pro­jek­tan­tów mody mimo ist­nie­nia kobiet chcą­cych mieć ład­ne sukien­ki i bar­dzo dobrych kraw­ców. Nikt tu niko­go nie zastąpi.

Czy Model dziedziny ma stan?

(to część bar­dziej techniczna)

W kwe­stii cze­goś takie­go jak Stan Modelu w MVC (czy model biz­ne­so­wy ma stan?) jestem ostroż­ny z uży­wa­niem poję­cia stan”, popa­trz­my na gry kom­pu­te­ro­we… Czym jest stan? Stan na pewien moment w cza­sie (snap­shot) czy stan biz­ne­so­wy” trwa­ją­cy minu­ty, godzi­ny a nie raz dłu­żej? Model to sys­tem: zespół ele­men­tów współ­dzia­ła­ją­cych. Z per­spek­ty­wy biz­ne­su, reagu­je on na akcje (sta­bil­ny ekran ocze­ki­wa­nia na OK, to per­ma­nent­ny maszy­no­wy prze­bieg spraw­dza­nia sta­nu przy­ci­sków). Osobiście trak­tu­ję kla­sy Modelu jako samo­dziel­ne żyją­ce byty, kon­struk­cja metod musi zagwa­ran­to­wać brak błę­dów i radzić sobie z tym co sta­łe” dla użyt­kow­ni­ka i zmien­ne” dla sys­te­mu (zegar bez sekund­ni­ka jest z per­spek­ty­wy minut mar­twym przed­mio­tem a mimo to cho­dzi”).

Podejście do MVC, któ­re prak­ty­ku­ję: Model powi­nien reali­zo­wać 100% funk­cjo­nal­no­ści i dać się testo­wać bez war­stwy V i C. Konkretnym sta­nem raczej cha­rak­te­ry­zu­je się kon­kret­ny obiekt a nie cały sys­tem. Cały sys­tem moż­na zapew­ne opi­sać maszy­ną sta­no­wą ale po co, sko­ro są ich nie­zli­czo­ne ilo­ści? Model żyje jak mro­wi­sko, wystar­czy zro­zu­mieć mrów­ki, mro­wi­sko to sku­tek na któ­ry za bar­dzo nie mamy wpływu.

Model DDD ana­li­tycz­ny” to meta­mo­del imple­men­ta­cji, Evans trak­tu­je go jako blo­ki kodu” zro­zu­mia­łe przez biz­nes, idąc dalej: ana­li­tyk trak­tu­je DDD jako wie­dzę o biz­ne­sie w posta­ci zro­zu­mia­łej przez deve­lo­pe­ra. Obie stro­ny uzna­ją, że ta struk­tu­ra jest wza­jem­ną umo­wą”. Jestem zwo­len­ni­kiem takie­go podej­ścia do DDD :), Evans się z tym w moich oczach nie kło­ci, on w zasa­dzie nie pisał o ana­li­zie biz­ne­so­wej :). Wielu pro­gra­mi­stów, auto­rów dosko­na­łych ksią­żek, zakła­da, że ana­li­zę wyma­gań ma popraw­nie wyko­na­ną”, co by to nie mia­ło zna­czyć :), ale to ogrom­ne uprosz­cze­nie bo tu – błę­dy – tkwi więk­szość ryzyk projektu.

Więcej o słow­ni­kach i regu­łach biznesowych:

(OMG, Glossary, Business Rules, http://​en​.wiki​pe​dia​.org/​w​i​k​i​/​S​e​m​a​n​t​i​c​s​_​o​f​_​B​u​s​i​n​e​s​s​_​V​o​c​a​b​u​l​a​r​y​_​a​n​d​_​B​u​s​i​n​e​s​s​_​R​u​les oraz http://​en​.wiki​pe​dia​.org/​w​i​k​i​/​B​u​s​i​n​e​s​s​_​r​ule, http://​www​.visu​al​-para​digm​.com/​s​u​p​p​o​r​t​/​d​o​c​u​m​e​n​t​s​/​b​p​v​a​u​s​e​r​g​u​i​d​e​/​2​0​1​7​/​2​1​8​1​/​5​7​0​4​3​_​c​r​e​a​t​i​n​g​f​a​c​t​.​h​tml).