Modele informacyjne

Dziesięć lat temu pisa­łem o infor­ma­cji i jej struk­tu­ral­nym cha­rak­te­rze, wpis koń­czył się zdaniem:

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 informacja?.Przemyślenia zwią­za­ne z tą ostat­nią defi­ni­cją pozo­sta­wiam Państwu. Ciąg dal­szy może nastą­pi? (źr. : Potrzeby infor­ma­cyj­ne fir­my ? Zarządzanie wie­dzą | Jarosław Żeliński IT-Consulting) 

Kontynuacją cyto­wa­ne­go tek­stu będzie dzi­siaj kwe­stia infor­ma­cji i powią­za­nych z nią wyma­gań na opro­gra­mo­wa­nie. Każdy pro­jekt wytwo­rze­nia, lub nawet tyl­ko dostar­cze­nia goto­we­go, opro­gra­mo­wa­nia powi­nien mieć co naj­mniej dwie war­stwy opi­su: (1) co chce­my stwo­rzyć i (2) jak to chce­my stwo­rzyć. Pierwsza to tak zwa­na war­stwa abs­trak­cyj­na opi­su­ją­ca mecha­nizm funk­cjo­no­wa­nia sys­te­mu. Druga to logicz­na archi­tek­tu­ra sys­te­mu czy­li pomysł na reali­za­cję (model Platform Independent). Na pod­sta­wie mode­lu PIM deve­lo­per pro­jek­tu­je opro­gra­mo­wa­nie, któ­re wyko­na (Platform Specific Model). Jednak czę­sto dostaw­ca ist­nie­ją­ce­go opro­gra­mo­wa­nia chce porów­nać logi­kę opro­gra­mo­wa­nia, któ­re ofe­ru­je, z logi­ką opi­sa­ną jako wyma­ga­ną. Tu potrzeb­ny jest nie model archi­tek­tu­ry PIM a model infor­ma­cyj­ny opi­su­ją­cy logi­kę biz­ne­so­wą ale nie narzu­ca­ją­cy archi­tek­tu­ry (bo ta już istnieje).

Bardzo czę­sto głów­nym celem biz­ne­so­wym, i zara­zem wyma­ga­niem, jest zarzą­dza­nie infor­ma­cją czy­li skoń­czo­ną licz­bą typów doku­men­tów o usta­lo­nej (lub wyma­ga­ją­cej usta­le­nia) tre­ści i struk­tu­rze. Niestety czę­sto jest tak, że struk­tu­ra doku­men­tów ule­ga pew­nym zmia­nom przy zacho­wa­niu głów­ne­go celu dla jakie­go powsta­ły, co utrud­nia zada­nie ale nie jest praw­dę, że jest to powód do per­ma­nent­ne­go mody­fi­ko­wa­nia opro­gra­mo­wa­nia. Odporność (goto­wość) apli­ka­cji na zmien­ność tre­ści jest tu wyma­ga­niem i sys­tem powi­nien sobie z tym poradzić.

W takich przy­pad­kach mode­lu­jąc sys­tem war­to sku­pić się wyłącz­nie na infor­ma­cji i na tym jak jest ona zarzą­dza­na, pozo­sta­wia­jąc pew­ne deta­le archi­tek­tu­ry dostaw­cy, któ­ry z zasa­dy – jako deve­lo­per – dys­po­nu­je więk­szą wie­dzą o dostęp­nych na ryn­ku tech­no­lo­giach i narzę­dziach. W takich przy­pad­kach war­to opra­co­wać tak zwa­ny model infor­ma­cyj­ny. Nie jest on jed­nak ani bazą danych ani mode­lem dzie­dzi­ny (przy­po­mi­nam, że obiek­to­wy model dzie­dzi­ny to kom­po­nent archi­tek­to­nicz­ny wzor­ca MVC). Jest to model związ­ków logicz­nych mię­dzy doku­men­ta­mi opi­su­ją­cy mecha­ni­zmy korzy­sta­nia z nich.

O informacji

Kluczowymi poję­cia­mi w tym obsza­rze ana­liz są: nośnik, doku­ment, infor­ma­cja, treść, dane, wia­do­mość, któ­re moż­na zobra­zo­wać w posta­ci związ­ków poję­cio­wych (dia­gram fak­tów SBVR):

Dokument elek­tro­nicz­ny (obec­ny jako poję­cie od kil­ku lat w pol­skim pra­wie) jest defi­nio­wa­ny jako
sta­no­wią­cy odręb­ną całość zna­cze­nio­wą zbiór danych upo­rząd­ko­wa­nych w okre­ślo­nej struk­tu­rze wewnętrz­nej i zapi­sa­ny na infor­ma­tycz­nym nośni­ku danych (na pod­sta­wie usta­wy KPA1 i SJP PWN). Innymi sło­wy: doku­ment elek­tro­nicz­ny to (upo­rząd­ko­wa­ne) infor­ma­cje zapi­sa­ne na elek­tro­nicz­nym nośni­ku, jed­nak nośni­kiem może być nadal np. papier, więc gene­ral­nie pod poję­ciem doku­ment moż­na (nale­ży) rozu­mieć utrwa­lo­ną odręb­ną całość zna­cze­nio­wą, zbiór danych upo­rząd­ko­wa­nych w okre­ślo­nej struk­tu­rze wewnętrz­nej”. Skoro odręb­ną, to tak­że mają­cą uni­kal­ną nazwę, bez cze­go nie­moż­li­we było by odwo­ła­nie się do takie­go doku­men­tu. Kolejna waż­na rzecz: zna­cze­nie i struk­tu­ra. Strukturę doku­men­tu okre­śla jego sza­blon, treść zaś to to co zosta­nie zapi­sa­ne z uży­ciem tego sza­blo­nu. Przykład: sło­wo fak­tu­ra ozna­cza obo­wią­zu­ją­cy sza­blon doku­men­tu mogą­ce­go, po wypeł­nie­niu, zawie­rać infor­ma­cje o tym, kto, komu, co, kie­dy i za jaką kwo­tę sprzedał.

Generalnie infor­ma­cje są orga­ni­zo­wa­ne w nazwa­ne struk­tu­ry czy­li doku­men­ty. Tu waż­na uwa­ga: ludzie w pro­ce­sie komu­ni­ka­cji zawsze ope­ru­ją infor­ma­cją o okre­ślo­nej struk­tu­rze, bywa, że jest ona – struk­tu­ra – pro­sta, struk­tu­rą jest tak­że podział wymia­ny infor­ma­cji na odręb­ne komu­ni­ka­ty, gdzie jeden komu­ni­kat to jed­no pole for­mu­la­rza”. Nie zmie­nia to fak­tu, że taki komu­ni­kat to struk­tu­ra zawie­ra­ją­ca auto­ra i nadaw­cę komu­ni­ka­tu, odbior­cę komu­ni­ka­tu oraz jego treść, jest to for­mu­larz – struk­tu­ra – jaką widzi­my pisząc np. kolej­ne­go maila.

W efek­cie moż­na przy­jąć, że wszel­kie infor­ma­cje w orga­ni­za­cjach są zor­ga­ni­zo­wa­ne z uży­ciem okre­ślo­nej licz­by for­mu­la­rzy, z któ­rych każ­dy ma okre­ślo­ną struk­tu­rę. Struktury te nazy­wa­my sza­blo­na­mi doku­men­tów (for­mu­la­rzy). Nie jest nie­ste­ty praw­dą, że infor­ma­cje są zor­ga­ni­zo­wa­ne w bazach danych rozu­mia­nych jako sys­tem rela­cyj­nych tablic. Model rela­cyj­ny jest nie­na­tu­ral­ny i strat­ny. Człowiek nie jest w sta­nie korzy­stać z nie­go wprost, jest to tyl­ko jakaś tech­no­lo­gicz­na meto­da zapi­su danych.

Model informacyjny organizacji

W związ­ku z tym, mamy pra­wo uznać, że wszyst­kie infor­ma­cje w fir­mie są zor­ga­ni­zo­wa­ne w uży­ciem skoń­czo­nej licz­by struk­tur i nie są to struk­tu­ry zna­ne z rela­cyj­nych baz danych, są to odręb­ne i nie­po­łą­czo­ne (nie­współ­dzie­lą­ce danych) for­mu­la­rze, czy­li po pro­stu odręb­ne doku­men­ty. Formularze te mogą być jaw­nie logicz­nie sko­ja­rzo­ne np. na fak­tu­rach są nano­szo­ne nume­ry zamó­wień. Mogą być sko­ja­rzo­ne nie wprost, z uży­ciem okre­ślo­nych reguł np. poda­tek za dany mie­siąc nali­cza­my na pod­sta­wie fak­tur wysta­wio­nych w tym mie­sią­cu albo dany refe­rent ma dostęp do doku­men­tu, jeże­li ten zwią­za­ny jest ze spra­wą aktu­al­nie przy­dzie­lo­ną temu refe­ren­to­wi. Ostatni przy­kład to typo­we dyna­micz­ne powią­za­nie gdyż przy­dział refe­ren­ta do spra­wy, a więc tak­że doku­men­tów z nią powią­za­nych, może ule­gać zmia­nie w czasie.

Formularze te, ich zawar­tość oraz logi­ka powią­zań pomię­dzy nimi, to sys­tem infor­ma­cyj­ny orga­ni­za­cji. Każda orga­ni­za­cja cechu­je się wła­snym, indy­wi­du­al­nym sys­tem infor­ma­cyj­nym, gdyż tyl­ko część doku­men­tów ma z góry narzu­co­ną struk­tu­rę np. pra­wem lub stan­dar­dem bran­żo­wym. Reszta, struk­tu­ra wewnętrz­nych doku­men­tów, to decy­zje wewnętrz­ne organizacji.

Postrzegam jako poważ­ny błąd uzna­nie, że model infor­ma­cyj­ny to jed­no­li­ta rela­cyj­na struk­tu­ra danych (pojęć) podob­na do (budo­wa­na na wzór) onto­lo­gii2. Po pierw­sze rela­cyj­ny model danych prze­cho­wu­je nie doku­men­ty a poję­cia, uzna­jąc związ­ki mię­dzy poję­cia­mi za sta­łe rela­cje (co nie zawsze jest praw­dą). Po dru­gie usu­wa­nie redun­dan­cji w pro­ce­sie zapi­su danych z for­mu­la­rzy wyma­ga ich odtwo­rze­nia przy każ­dej pró­bie odtwo­rze­nia kon­kret­ne­go doku­men­tu. Tak więc taka rela­cyj­na baza danych nie prze­cho­wu­je żad­nych doku­men­tów a jedy­nie zbiór trwa­le powią­za­nych pojęć. Bardzo czę­sto mówi się, że infor­ma­cje i wie­dza to onto­lo­gia. Niestety tak nie jest, onto­lo­gia to sys­tem pojęć powią­za­nych związ­ka­mi seman­tycz­ny­mi, sta­no­wi opis języ­ko­wa ale nie jest to wie­dza o świe­cie a wie­dza o języku.

Generalnie uwa­żam, że nie jest infor­ma­cją poję­cie, jego defi­ni­cja i seman­tycz­ne powią­za­nie z innym poję­ciem. To tyko model syn­tak­ty­ka i seman­ty­ka pojęć. Faktura zaś to zbiór pojęć mają­cych okre­ślo­ną struk­tu­rę i treść, war­tość ma to – wie­dza – kto, co kie­dy i od kogo kupił, a nie to co zna­czy sło­wo pro­dukt czy nabyw­ca i jak jest seman­tycz­nie on powią­za­ny z poję­ciem sprze­daw­ca. To co naj­wy­żej pozwo­li nam zro­zu­mieć jaką treść zawie­ra faktura.

Kolejną wadą podej­ścia rela­cyj­ne­go jest to, że baza taka sta­no­wi nie­po­dziel­ny mono­lit, w efek­cie to co jest moż­li­we w rze­czy­wi­sto­ści (np. pra­ca z fak­tu­rą w cał­ko­wi­tym ode­rwa­niu od odpo­wia­da­ją­cych jej zamó­wień) jest nie­moż­li­we w sys­te­mie rela­cyj­nym. Usuwanie redun­dan­cji powo­du­je tak­że powsta­wa­nie duże­go narzu­tu na zarzą­dza­nie histo­rią zmian pól baz danych, co nie ma miej­sca w rze­czy­wi­stych doku­men­tach (kar­to­te­ka klien­ta zawie­ra wyłącz­nie aktu­al­ne dane adre­so­we, histo­rycz­ne są dostęp­ne w histo­rycz­nych doku­men­tach, np. aktu­al­ne dane adre­so­we klien­ta są w jego kar­to­te­ce, jego adres z ubie­głe­go roku znaj­dzie­my na doku­men­tach wysta­wio­nych temu klien­to­wi w ubie­głym roku).

Rok temu pisa­łem przy podob­nej okazji:

war­to zauwa­żyć, że zmien­ność śro­do­wi­ska biz­ne­so­we­go powo­du­je, że żad­ne decy­zje o logi­ce biz­ne­so­wej nie są osta­tecz­ne, jed­nak są ele­men­ty nie­zmien­ne takie jak np. nasze dane oso­bo­we. Tak więc to, co powszech­nie nazy­wa­ne jest ?mode­lem danych? (busi­ness data dia­gram) w rozu­mie­niu opi­sa­nym przez autor­ki arty­ku­łu, nie ma racji bytu. Ma sens zacho­wa­nie zamó­wie­nia i osob­no fak­tu­ry, ale to czy regu­łą jest jed­no zamó­wie­nie do jed­nej fak­tu­ry, pod­le­ga zmia­nom wyni­ka­ją­cym i ze zmien­no­ści pra­wa i ze zmien­no­ści mode­li biz­ne­so­wych. Nie widzę żad­ne­go powo­du dekla­ro­wa­nia już na począt­ku pro­jek­tu, tego by nie wię­cej niż 5 osób mogło korzy­stać z jed­ne­go kon­ta i sub­skryp­cji. W szcze­gól­no­ści nie widzę powo­du by taka zasa­da była zawar­ta w samym kodzie apli­ka­cji. (źr. : Biznesowy model danych ? nie chce­my | | Jarosław Żeliński IT-Consulting).

Problemy jakie wno­si do pro­jek­tu opar­cie się na jed­nym rela­cyj­nym mode­lu danych dla całej apli­ka­cji, są zna­ne od lat:

(źr. Designing Objects Systems, Steve Cook, John Daniels, 1994 rok.)

a mimo to nadal jest on sto­so­wa­ny w spo­sób sta­no­wią­cy zagro­że­nie dla całe­go projektu.

Czym więc jest model infor­ma­cyj­ny orga­ni­za­cji? Jest to sys­tem sza­blo­nów doku­men­tów czy­li usta­lo­nych struk­tur infor­ma­cyj­nych wraz z logi­ką ich wza­jem­nych powią­zań czy­li aso­cja­cji, świa­do­mie uni­kam poję­cia rela­cji. Relacja to trwa­ły zwią­zek, zaś aso­cja­cja to sko­ja­rze­nie budo­wa­ne na bazie okre­ślo­nej logi­ki czy zacho­dzą­ce­go fak­tu. Przykład: fak­tu­ra sko­ja­rzo­na jest z oso­bą, któ­ra doko­na­ła sprze­da­ży, jed­nak w momen­cie gdy upły­nie ter­min waż­no­ści i fak­tu­ra nie jest opła­co­na, jest ona auto­ma­tycz­nie koja­rzo­na z win­dy­ka­to­rem i sprze­daw­ca prze­sta­je być za nią odpo­wie­dzial­ny (być może nawet tra­ci dostęp do jej tre­ści, zgod­nie z zasa­dą bez­pie­czeń­stwa mówią­cą, że pra­cow­ni­cy mają dostęp wyłącz­nie do infor­ma­cji potrzeb­nej do reali­zo­wa­nia ich bie­żą­cych zadań i obo­wiąz­ków).

Jak podejść do opra­co­wa­nia i udo­ku­men­to­wa­nia sys­te­mu infor­ma­cyj­ne­go, czy­li jak wyko­nać jego model? Pierwszy krok to ziden­ty­fi­ko­wa­nie doku­men­tów. Podstawą będzie tu ana­li­za pro­ce­sów biz­ne­so­wych i opra­co­wa­nie ich mode­li. Elementarny (ato­mo­wy) pro­ces biz­ne­so­wy to aktyw­ność mają­ca wej­ście i wyj­ście, a kon­kret­nie dane wej­ścio­we i dane, któ­ry powsta­ją jako pro­dukt tej aktyw­no­ści. Te dane to nic inne­go jak infor­ma­cje o okre­ślo­nej struk­tu­rze. Oznacza to, że na mode­lu pro­ce­sów (tu w nota­cji BPMN) każ­da aktyw­ność musi mieć sko­ja­rzo­ny doku­ment wej­ścio­wy i wyj­ścio­wy (ele­ment o nazwie DataObect w nora­cji BPMN), w prze­ciw­nym razie taka aktyw­ność nie powin­na się poja­wić na modelu.

Powyższy dia­gram zawie­ra mode­le dwóch odręb­nych pro­ce­sów: obsłu­ga zapy­tań ofer­to­wych oraz obsłu­ga zamó­wień. Oba dia­gra­my to naj­niż­szy poziom mode­lo­wa­nia pro­ce­sów, poziom ele­men­tar­nych (ato­mo­wych) pro­ce­sów biz­ne­so­wych. Pozwala ziden­ty­fi­ko­wać wszyst­kie doku­men­ty i ich statusy.

Tu mała uwa­ga: nie ma żad­ne­go sen­su umiesz­cza­nie na takich mode­lach deta­licz­nych prac takich jak wpro­wa­dze­nie danych zama­wia­ją­ce­go” czy spraw­dze­nie sal­da” bo to są ele­men­ty (kro­ki) pro­ce­dur. Innymi sło­wy nie rysu­je­my” na dia­gra­mach tego jak i w jakiej kolej­no­ści wypeł­nić pola for­mu­la­rza. Po pierw­sze zaciem­ni to obraz, po dru­gie pro­ce­dur, reguł biz­ne­so­wych i słow­ni­ków nie mode­lu­je­my z uży­ciem BPMN. Robi się to w posta­ci odręb­nych doku­men­tów lub diagramów.

Powyższy model obra­zu­je sytu­ację, w któ­rej pew­na fir­ma odsy­ła ofer­ty na zapy­ta­nia, otrzy­mu­jąc zaś zamó­wie­nie, spraw­dza je od stro­ny for­mal­nej i reali­zu­je. Każdy taki model, dla peł­nej zro­zu­mia­ło­ści, MUSI mieć załą­czo­ne (dia­gra­my, wzo­ry wydru­ków, inne) struk­tu­ry tych doku­men­tów. Dodatkiem będzie wła­śnie model infor­ma­cyj­ny czy­li logicz­na struk­tu­ra powią­zań logicz­nych mię­dzy doku­men­ta­mi (korzy­sta­ją z niej oso­by pra­cu­ją­ce z tymi dokumentami).

Prosta wer­sja takie­go mode­lu infor­ma­cyj­ne­go może zostać wyko­na­ną tak­że w nota­cji BPMN:

Tu jed­nak moż­li­we jest poka­za­nie jedy­nie związ­ków jaki­mi są tak zwa­ne refe­ren­cje, czy­li wza­jem­ne jaw­ne odwo­ła­nia (np. for­mu­larz ofer­ty zawie­ra pole z nume­rem zapy­ta­nia). Pełny model infor­ma­cyj­ny moż­na wyko­nać z uży­ciem nota­cji UML:

Powyższy dia­gram to kla­sy repre­zen­tu­ją­ce nazwa­ne struk­tu­ry doku­men­tów (ich typy) oraz związ­ki logicz­ne mię­dzy nimi (aso­cja­cje w UML to nie są trwa­łe rela­cje zna­ne z baz danych a jedy­nie związ­ki seman­tycz­ne). Związki te moż­na zobra­zo­wać jeże­li są to trwa­łe (wbu­do­wa­ne w treść) binar­ne powią­za­nia (zwią­zek pomię­dzy dwo­ma kla­sa­mi). Jednak związ­ki dyna­micz­ne, defi­nio­wa­ne przez regu­ły biz­ne­so­we, nie dają się zobra­zo­wać dla­te­go poprze­sta­je­my na wyspe­cy­fi­ko­wa­niu takiej reguły.

Powyższy dia­gram mówi nam, że:

  • powią­za­nie pomię­dzy ory­gi­na­łem zapy­ta­nia (np. jego skan na dys­ku) a wewnętrz­nym doku­men­tem Zapytanie od klien­ta, jest zawar­te w doku­men­cie (for­mu­larz) Metadane zapy­tań (jest to kla­sa aso­cja­cyj­na UML), któ­ry (hipo­te­tycz­ny sza­blon był­by w załą­cze­niu) zawie­ra infor­ma­cje o poło­że­niu pli­ku na dys­ku i przy­dzie­lo­nym mu np. wewnętrz­nym nume­rze Zapytania,
  • powią­za­nie pomię­dzy Ofertą han­dlo­wą a Zapytaniem jest wbu­do­wa­ne w Oferty w posta­ci nume­ru zapy­ta­nia, jako jed­ne­go z atry­bu­tów doku­men­tu Oferta (Oferta w swo­jej tre­ści powo­łu­je się na numer Zapytania, zobra­zo­wa­no to aso­cja­cją kwa­li­fi­ko­wa­ną UML),
  • zwią­zek pomię­dzy doku­men­tem a oso­bą, któ­ra ma dostęp do jego tre­ści opi­su­je regu­ła biz­ne­so­wa mówią­ca, że Sprzedawca ma dostęp do doku­men­tów klien­tów, któ­rych jest opie­ku­nem”, regu­ła ta zosta­ła zaim­ple­men­to­wa­na w posta­ci doku­men­tu Opiekun (kla­sa aso­cja­cyj­na UML) , zakła­da­my że jest to for­mu­larz zawie­ra­ją­cy nazwę klien­ta i nazwę jego opie­ku­na (np. udo­ku­men­to­wa­na decy­zja dyr. dzia­łu sprze­da­ży), te doku­men­ty mogą być w dowol­nej chwi­li zmie­nia­ne, doda­wa­ne i usuwane.

Jak widać dia­gram nie zawie­ra aso­cja­cji pomię­dzy Sprzedawcą a doku­men­ta­mi (dostęp Sprzedawcy do tre­ści dane­go doku­men­tu), gdyż ich sen­sow­ne zobra­zo­wa­nie na dia­gra­mie jest prak­tycz­nie niemożliwe.

Taki dia­gram zawie­ra pre­cy­zyj­ne infor­ma­cje o tym jakie i jak powią­za­ne z sobą infor­ma­cje prze­twa­rza orga­ni­za­cja. Nie jest to abso­lut­nie coś co nale­ży odwzo­ro­wać jako model kodu, nie ma tu żad­nych licz­no­ści klas, bo te tak­że są (poten­cjal­nie zmien­ny­mi) regu­ła­mi biz­ne­so­wy­mi (np. regu­ła: jeden sprze­daw­ca nie może się opie­ko­wać wię­cej niż dzie­się­cio­ma klien­ta­mi). Nie jest to żaden model danych, struk­tu­ry for­mu­la­rzy doku­men­tu­je­my osob­no. Nie jest też powie­dzia­ne, że imple­men­ta­cja for­mu­la­rzy to tabli­ce z kolum­na­mi odpo­wia­da­ją­cy­mi polom for­mu­la­rzy (to zresz­tą bar­dzo kiep­ski pomysł).

Pełna doku­men­ta­cja powin­na zawie­rać w załą­cze­niu deta­licz­ne struk­tu­ry tych for­mu­la­rzy (dia­gra­my przed­sta­wia­ją­ce struk­tu­ry XML, lub sko­men­to­wa­ne mock-up’y doku­men­tów). Taka spe­cy­fi­ka­cja zawie­ra wszyst­kie infor­ma­cje pozwa­la­ją­ce deve­lo­pe­ro­wi stwo­rzyć opro­gra­mo­wa­nie słu­żą­ce do zbie­ra­nia i zarzą­dza­nia infor­ma­cją. Jako model wyma­gań na sys­te­my typu EOD3 jest wystarczająca.

Gdyby było praw­dą, że wyma­ga­my od opro­gra­mo­wa­nia tak­że, by zawar­tość wybra­nych pól tych for­mu­la­rzy była wyli­cza­na lub wery­fi­ko­wa­na, musi­my dodat­ko­wo udo­ku­men­to­wać zależ­no­ści mię­dzy tymi pola­mi. Model taki czę­sto war­to uzu­peł­nić wyma­ga­ną archi­tek­tu­rą opro­gra­mo­wa­nia, bo od niej zale­żą cechy jako­ścio­we apli­ka­cji, tak zwa­ne poza­funk­cjo­nal­ne. Będzie to wła­śnie model dzie­dzi­ny sys­te­mu, opi­sy­wa­ny na moim blo­gu wielokrotnie. 

Poniżej cel i pro­ces budo­wy mode­li poję­cio­wych :

M. van Sinderen and P. Johnson (Eds.): IWEI 2011, LNBIP 76, pp. 146?162, 2011. ? IFIP International Federation for Information Processing 2011
M. van Sinderen and P. Johnson (Eds.): IWEI 2011, LNBIP 76, pp. 146?162, 2011. ? IFIP International Federation for Information Processing 2011

Zapraszam tak­że do lek­tu­ry kon­ty­nu­acji tego zagad­nie­nia w arty­ku­le Bazy Dokumentowe.

Źródła

van Sinderen, M., & Johnson, P. (Eds.). (2011). Enterprise Interoperability: Third International IFIP Working Conference, IWEI 2011, Stockholm, Sweden, March 23 – 24, 2011. Proceedings (Vol. 76). Springer Berlin Heidelberg. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑642 – 19680‑5
Usman, Z., Young, R. I. M., Chungoora, N., Palmer, C., Case, K., & Harding, J. (2011). A Manufacturing Core Concepts Ontology for Product Lifecycle Interoperability. In M. van Sinderen & P. Johnson (Eds.), Enterprise Interoperability (pp. 5 – 18). Springer. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑642 – 19680-5_3

Semantic Core czyli bat na szczegóły

Bardzo czę­sto zasta­na­wiam się, nad przy­czy­na­mi pora­żek pro­jek­tów, przy­czy­na­mi tego, że jed­ne są lep­sze inne gor­sze, a gor­szy to taki, któ­ry wymy­ka się spod kon­tro­li a osta­tecz­ny efekt (pro­dukt), uzy­ska­ny po znacz­nie dłuż­szym cza­sie niż pla­no­wa­no, jest zasko­cze­niem dla wszyst­kich. Na to nakła­da się pro­blem prze­ka­zy­wa­nia wie­dzy pomię­dzy kolej­ny­mi eta­pa­mi pro­jek­tu, gdzie naj­więk­szym ryzy­kiem jest zro­zu­mie­nie pro­ble­mu i prze­ka­zy­wa­nie wie­dzy przez same­go zama­wia­ją­ce­go. Gdzie problem?

Ten arty­kuł pole­cam biz­ne­so­wi” któ­ry szu­ka przy­czyn swo­ich pro­ble­mów, i tym (nie tyl­ko ana­li­ty­kom), któ­rzy mają ambi­cje robić coś w kie­run­ku popra­wy tego sta­nu rze­czy, zamiast uzna­wać obec­ne sta­ty­sty­ki za pew­nik bo takie są fakty”.

Wpadłem jakiś czas temu na stro­nę SemanticCore​.ORG, oto krót­ki cytat z pierw­szej strony :

The seman­tic core repre­sents a vision of com­plex sys­tems that are defi­ned and pro­vi­sio­ned based on high-level models. This vision is being pur­su­ed by mul­ti­ple gro­ups in mul­ti­ple orga­ni­za­tions based on a varie­ty of para­digms such as UML, Ontologies, Business Rules, MOF, EDOC, Data Modeling, OWL, SQL, Etc.. It is the intent of the seman­tic core to inte­gra­te the­se diver­se para­digms into fami­ly of lan­gu­ages that leve­ra­ges the­ir com­mo­na­li­ty whi­le taking advan­ta­ge of the­ir uni­que capa­bi­li­ties. We will defi­ne nor­ma­li­zed Meta-Models cap­tu­ring uni­que seman­tics, inde­pen­dent of the nota­tion. […] It is our intent to cre­ate a com­bi­ned sub­mis­sion appro­pria­te for mul­ti­ple OMG ini­tia­ti­ves inc­lu­ding Ontologies, Business Rules, Business Process Modeling and a UML infra­struc­tu­re libra­ry.[…] the seman­tic core will defi­ne models for a fami­ly of onto­lo­gi­cal­ly gro­un­ded models defi­ning all aspects of sys­tems, inc­lu­ding the­ir requ­ire­ments, envi­ron­ment, spe­ci­fi­ca­tion and imple­men­ta­tion. This will ena­ble a trans­i­tion from tra­di­tio­nal and manu­al sys­tems buil­ding tech­ni­qu­es to an auto­ma­ted and human-focu­sed para­digm. (źr. Semantic Core).

Powyżej (moje wytłusz­cze­nia) głów­ne cele tej orga­ni­za­cji (pole­cam zapo­zna­nie się z całą stroną)

  • nasza wizja to zło­żo­ne sys­te­my opi­sy­wa­ne i przed­sta­wia­ne w posta­ci mode­li na wyso­kim pozio­mie abstrakcji,
  • w tym celu defi­niu­je­my znor­ma­li­zo­wa­ny meta­mo­del opi­sa­ny sys­te­mem zna­czeń (seman­ty­ka) nie­za­leż­nym od notacji,
  • two­rzy­my to w zgo­dzie z ini­cja­ty­wa­mi OMG (www​.omg​.org),
  • seman­tic core” okre­śla stan­dar­do­wy zestaw klu­czo­wych pojęć i ich zna­czeń, opi­su­ją­cych wszyst­kie aspek­ty sys­te­mów, w tym ich wyma­ga­nia, oto­cze­nie, spe­cy­fi­ka­cji i implementacje.

Wygląda jak baj­ka ale nie jest tak źle, a coś takie­go jest bar­dzo przy­dat­ne. Nie ma sen­su budo­wa­nie jed­nej mega-nota­cji do wszyst­kie­go, widać to po pra­cach OMG (i po tym, że UML jed­nak nie zastą­pił innych nota­cji, i nikt roz­sąd­ny chy­ba już tego nie pla­nu­je). Jednak uzna­jąc fakt, że uży­wa­my (dobra prak­ty­ka) nota­cji wła­ści­wych dla roz­wią­zy­wa­ne­go pro­ble­mu (zary­zy­ku­ję tezę: wła­ści­wa to moż­li­wie naj­prost­sza i wystar­cza­ją­ca) war­to jed­nak zadbać o ich kom­pa­ty­bil­ność”. Część wspól­na to nie nowa nota­cja, a utrzy­ma­nie spój­no­ści zna­czeń współ­dzie­lo­nych pojęć ist­nie­ją­cych już notacji.

SemanticCore
(źr. SemanticCore​.org)

O złożoności

Na co war­to zwró­cić uwa­gę? Otóż w pro­ce­sie każ­dej więk­szej ana­li­zy poja­wia się zło­żo­ność, nad któ­rą nale­ży zapa­no­wać. Bez tego opa­no­wa­nia poja­wia się coś co zabi­ja pro­jek­ty ana­li­tycz­ne: utra­ta pano­wa­nia nad zło­żo­no­ścią pro­ble­mu, poja­wia­ją się mega-dia­gra­my i mega for­mu­la­rze danych.

Kilka tygo­dni temu, w jed­nym z moich pro­jek­tów, mia­łem oka­zję wejść w mały spór na temat tego, kie­dy udo­ku­men­to­wać szcze­gó­ło­wo spo­sób kla­sy­fi­ka­cji (ozna­cza­nia) pozy­cji budże­to­wych w sys­te­mie zarzą­dza­nia pro­ce­sem two­rze­nia budże­tu i jego reali­za­cji. Zamawiający od razu wcho­dził (wręcz żądał) w szcze­gó­ły, czy­li naście rodza­jów każ­de­go z ogrom­nej licz­by typów wydat­ków. Jeszcze bym dobrze nie ruszył z miej­sca a już został bym zgnie­cio­ny licz­bą tych szcze­gó­łów. Do tego dorzu­ca­no mi peł­ną szcze­gó­ło­wość struk­tu­ry orga­ni­za­cyj­nej (tak­że prze­kła­da się na budżet jako miej­sca wyda­wa­nia środ­ków). Dodam, że struk­tu­ra orga­ni­za­cyj­na zmie­ni­ła się w cią­gu roku trzy razy.

Co z tym zro­bić? Wyrzucić” te szcze­gó­ły na sam koniec! One są na począt­ku zupeł­nie nie­istot­ne (nie licząc zapo­zna­nia się nimi jako obec­nie funk­cjo­nu­ją­cym sys­te­mem), każ­dy zaś kto twier­dzi, że jed­nak są istot­ne już teraz, po pro­stu jesz­cze nie zro­zu­miał ana­li­zo­wa­ne­go problemu.

Problemem są pryn­cy­pia czy­li co i po co” a nie jak”. Owo jak” to dopie­ro pro­jek­to­wa­nie. Tak więc np. budżet, pro­ces jego two­rze­nia a potem reali­za­cji, to jakiś sys­tem pozy­cji budże­to­wych” i zda­rzeń zwią­za­nych z jego reali­za­cją. Jakaś logi­ka tej cało­ści (dalej jako regu­ły biz­ne­so­we i decy­zyj­ne). To jak zosta­nie ozna­czo­na (jakim sym­bo­lem itp.) to efekt tego co chce­my osią­gnąć. Każdy kto chwy­ci się od razu za te szcze­gó­ły (jakieś one są, mamy je już więc dla­cze­go się za nie nie zabrać), zaczy­na od koń­ca i w zasa­dzie zarzu­cił ana­li­zę i odciął sobie (klien­to­wi) moż­li­wość zbu­do­wa­nia opty­mal­ne­go (nowe­go) roz­wią­za­nia (zapew­ne inne­go niż obec­ne) na rzecz obecnego.

Należy na począt­ku pra­co­wać na abs­trak­cji, uogól­nie­niu pozwa­la­ją­cym sku­pić się na kil­ku­na­stu pryn­cy­piach zamiast na tysią­cach szcze­gó­łów. To pierw­sze jest rela­tyw­nie łatwe, to dru­gie w zasa­dzie niemożliwe.

abstraction systemcore_org
(źr. SemanticCore​.org)

Modele

Jak wspo­mnia­no powy­żej, typów mode­li (nota­cji) mamy wię­cej niż jeden. Każdy model (rodzaj mode­lu) ma swój dedy­ko­wa­ny sys­tem pojęć, po ubra­niu go w iko­ny mamy nota­cję (język obraz­ko­wy), czy­li język opi­sa­ny seman­ty­ką (zna­cze­nia pojęć) i syn­tak­ty­ką (ich wza­jem­ne, dopusz­czal­ne rela­cje). Zestaw pojęć powi­nien być dobra­ny sto­so­wa­nie do roz­wią­zy­wa­ne­go pro­ble­mu (wybór wła­ści­wej do eta­pu pra­cy notacji).

Jak wska­za­no wyżej, mamy czte­ry klu­czo­we sys­te­my pojęciowe:

  1. UML czy­li obiek­to­wy para­dyg­mat opi­su i projektowania,
  2. Ontologia (biz­ne­so­wa, sys­te­mo­wa), któ­rą obec­nie repre­zen­tu­ją Model Motywacji Biznesowej (w mię­dzy cza­sie tak­że doro­bił się ikon), SBVR i sys­te­my poję­cio­we opi­sy­wa­nia archi­tek­tu­ry kor­po­ra­cyj­nej, struk­tu­ry organizacji,
  3. Procesy biz­ne­so­we,
  4. Reguły biz­ne­so­we.

Wspólny śro­dek ma już swo­je zarze­wie”. W 2010 roku wyda­no ostat­nią spe­cy­fi­ka­cję Modelu Motywacji Biznesowej (ang. BMM). Można przy­jąć, że ten sys­tem poję­cio­wy (teraz tak­że nota­cja) to ele­ment biz­ne­so­wej onto­lo­gii. Pojawił się w niej doda­tek F zaty­tu­ło­wa­ny Powiązane spe­cy­fi­ka­cje mode­lo­wa­nia w OMG. I co my tu mamy?

Ano mamy stwier­dze­nie, że ta kom­pa­ty­bil­ność jest potrzeb­na. Napisano, że BMM współ­dzie­li pew­ne poję­cia z taki­mi sys­te­ma­mi poję­cio­wy­mi jak:

  1. BPMN (w BMM poja­wia się poję­cie pro­ces biznesowy)
  2. SBVR (BMM tak­że ope­ru­je poję­ciem Reguła Biznesowa)
  3. OSM (Organization Structure Metamodel, BMM uży­wa poję­cia komór­ka organizacyjna”).

Co cie­ka­we poję­cia te mają w OMG wspól­ne defi­ni­cje (te same poję­cia lub poję­cia dają­ce się mapo­wać 1:1). Utrzyma jest zgod­ność roli w pro­ce­sie biz­ne­so­wym i roli jako ele­men­tu struk­tu­ry orga­ni­za­cyj­nej w tych sys­te­mach (OSM, BPMN, BMM).

W spe­cy­fi­ka­cji BMM v.1.1 znaj­dzie­my taki oto diagram:

BMMOvierwiev

Notacje, któ­re wpa­dły” w ręce OMG maja wła­śnie tę bar­dzo pożą­da­ną i przy­jem­ną cechę: są kom­pa­ty­bil­ne. Wspominałem swe­go cza­su o nota­cji ArchiMate (obec­nie nale­ży do The Open Group podob­nie jak i TOGAF). Niestety nie ma tu tej kom­pa­ty­bil­no­ści, mimo że TOGAF nie jest samo­wy­star­czal­nym mode­lem (wyma­ga sto­so­wa­nia innych nota­cji poza ArchiMate), w efek­cie nie widzę moż­li­wo­ści pro­ste­go” zasto­so­wa­nia ram TOGAF”a jako bazo­wej archi­tek­tu­ry kor­po­ra­cyj­nej, bo kolej­ne eta­py uszcze­gó­ła­wia­nia mode­li (a od tego nie ma uciecz­ki w pro­jek­tach) albo będą mia­ły kło­po­ty z jed­no­znacz­no­ścią albo będą wyma­ga­ły jakie­goś dedy­ko­wa­ne­go sys­te­mu tłu­ma­cze­nia pojęć TOGAF na UML, BPMN (BMM nie, bo TOGAF od ostat­niej wer­sji dublu­je – nie wiem czy w 100% i po co – poję­cia mode­lu moty­wa­cji biznesowej.

Nie wymie­ni­łem tu nota­cji UML bo ta słu­ży do obiek­to­we­go mode­lo­wa­nia (para­dyg­mat obiek­to­wy) sys­te­mów. Nie widzę sen­su wpy­cha­nia” jej w dzie­dzi­nę onto­lo­gii zarzą­dza­nia. Paradygmat obiek­to­wy to inne spoj­rze­nie, sys­te­mo­we, opi­su­ją­ce współ­dzia­ła­ją­ce obiek­ty”, jed­nak to wtór­ny model, bo te obiek­ty sys­te­mo­we repre­zen­tu­ją” komór­ki orga­ni­za­cyj­ne, stra­te­gie, regu­ły biz­ne­so­we, doku­men­ty itp. Modele obiek­to­we są dosko­na­łe jako wstęp do pro­jek­to­wa­nia opro­gra­mo­wa­nia imple­men­to­wa­ne­go z pomo­cą obiek­to­wo zorien­to­wa­nych narzę­dzi. Są kom­plet­nie nie­przy­dat­ne jako biz­ne­so­wy sys­tem poję­cio­wy. Owszem, nie raz tu wspo­mi­na­ny DDD (spo­sób mode­lo­wa­nia dzie­dzi­ny sys­te­mu) to pew­ne takie połą­cze­nie, ale to raczej most niż ekwi­wa­lent. Patrząc na ten pro­blem z per­spek­ty­wy MDA (OMG, Model Driven Architecture) model CIM (Computing Independent Model) to powyż­sze mode­le (BMM, BPMN), UML ma zasto­so­wa­nie dla czę­ści PIM (wstęp­ny model imple­men­ta­cji w posta­ci opro­gra­mo­wa­nia) i tu jest dopie­ro miej­sce na DDD.

Tak więc bat na szcze­gó­ły jest: to pro­sta zasa­da od ogó­łu do szcze­gó­łu”, na każ­dym eta­pie mamy sto­sow­ną nota­cję (pro­sty sys­tem pojęć). Należy uogól­niać i mode­lo­wać, i potem stop­nio­wo uszcze­gó­ła­wiać mode­le aż do momen­tu doj­ścia do imple­men­ta­cji dane­go systemu.

TheMetaModelArchitecture

Powyżej obraz z nanie­sio­ny­mi eta­pa­mi [[MDA]] (wię­cej o Model Driven Architecture oraz Meta Object Facility – powyż­szy rysu­nek – na stro­nach OMG). Core Semantic to szczyt (M3) powyż­sze­go. Wymienione wyżej nota­cje to war­stwa M2 (UML dodat­ko­wo obej­mu­je tak­że M1).

Konkluzja jest taka: bazy danych zawie­ra­ją­ce szcze­gó­ło­wość sys­te­mu, pro­jek­tu­je­my na koń­cu. Szczegóły ele­men­tów budże­tu (przy­ta­cza­ny przy­kład) opra­co­wu­je­my dopie­ro jako pomysł na imple­men­ta­cję, mamy to jed­nak dwa pozio­my implementacji:

  1. roz­wią­za­nie pro­ble­mu efek­tyw­ne­go zarzą­dza­nia budże­tem w nowej for­mie np. sys­tem zna­ko­wa­nia pozy­cji budżetowych,
  2. imple­men­ta­cja tego sys­te­mu jako opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go ten pro­ces w organizacji.

To wszyst­ko powin­no być jed­nak poprze­dzo­ne ana­li­zą. Analiza obec­nej sytu­acji nie pole­ga jed­nak na jej 100% odwzo­ro­wa­niu w doku­men­tach ana­li­tycz­nych, a jedy­nie na pozna­niu w celu zro­zu­mie­nia celu biz­ne­so­we­go, opra­co­wa­nie jego mode­lu, i potem dopie­ro roz­wią­zy­wa­nie pro­ble­mu: jak to osiągnąć.

Na koniec pew­na uwa­ga :). Ktoś może powie­dzieć: biz­nes tego (nota­cje, mode­le itp.) nie rozu­mie. I ma racje, bo to narzę­dzia a nie pro­duk­ty ana­liz. Produktem ana­li­zy dla biz­ne­su są zawsze reko­men­da­cje (wyma­ga­nia na opro­gra­mo­wa­nie to tak­że rodzaj reko­men­da­cji brzmią­cej: zale­cam by takie warun­ki speł­nia­ło to opro­gra­mo­wa­nie). Zamawianie przez biz­nes mode­li jako takich, to jakieś kosz­mar­ne nie­po­ro­zu­mie­nie. To tak jak by np. praw­nik, jako pro­dukt zle­ce­nia opi­nia praw­na” oddał wybra­ny stos kodek­sów z komen­ta­rza­mi. Nie, dobry praw­nik odda­je jed­na stro­nę reko­men­da­cji: opi­nie praw­ną. To, że sko­rzy­stał z tych kodek­sów to jego narzę­dzie pra­cy, moż­li­we, że załą­czy je do tej tej opi­nii (ale raczej jako mate­riał dla inne­go praw­ni­ka lub audytora).

Analiza danych i podejmowanie decyzji: pięta achillesowa współczesnych organizacji

Zaczęło się od pro­wo­ka­cyj­ne­go arty­ku­łu Chrisa Andersona ?The End of Theory: The Data Deluge Makes the Scientific Method Obsolete? . Redaktor naczel­ny mie­sięcz­ni­ka Wired udo­wad­niał w nim, że zalew dany­mi (okre­śla­ny po angiel­sku mia­nem ?data delu­ge? lub ?big data?) wywo­ła­ny, z jed­nej stro­ny sta­łym spad­kiem kosz­tów prze­cho­wy­wa­nia infor­ma­cji, a z dru­giej, upo­wszech­nie­niem ser­wi­sów Web 2.0, słu­żą­cych kre­owa­niu i współ­dzie­le­niu wie­dzy, wkrót­ce zmu­si nowo­cze­sne orga­ni­za­cje do rezy­gna­cji z wyra­fi­no­wa­nych narzę­dzi do ana­li­zy sta­ty­stycz­nej. A w dal­szej per­spek­ty­wie może ozna­czać wery­fi­ka­cję dotych­cza­so­wych metod nauko­wych i badaw­czych. (źr. Blog Jacka Murawskiego dyrek­to­ra gene­ral­ne­go pol­skie­go oddzia­łu Microsoft.)

Jest to kolej­ny głos mówią­cy o zale­wie śmie­cio­wych danych. Pisałem swe­go cza­su o pro­ble­mach z migra­cją danych pod­czas wdra­ża­nia nowych sys­te­mów. Problemem nie jest sama migra­cja (prze­nie­sie­nie danych ze sta­re­go sys­te­mu do nowe­go) a to, co prze­nieść. Niestety naj­czę­ściej z bra­ku pomy­słu” prze­no­si się wszyst­ko” co powo­du­je, że rośnie licz­ba śmie­ci zaś rela­tyw­nie spa­da odse­tek danych fak­tycz­nie przydatnych.

W efek­cie ma miej­sce para­dok­sal­ne zja­wi­sko: rosną kosz­ty zarzą­dza­nia dany­mi a ich war­tość (przy­dat­ność) male­je. Np. dane księ­go­we i podob­ne – struk­tu­ral­ne – moż­na prze­no­sić do hur­tow­ni danych. Tu pro­ces ich czysz­cze­nia roz­wią­zu­je część pro­ble­mu, bo to tyl­ko ich porząd­ko­wa­nie. Pozostaje pro­blem cze­go nie prze­no­sić”. Dochodzi pro­blem danych nie­struk­tu­ral­nych takich jak róż­ne­go rodza­ju doku­men­ty (ofer­ty, robo­cze doku­men­ta­cje pro­jek­to­we itp.).

Cały ten pro­blem ma nazwę: [[reten­cja danych]]. Pojawiają się gło­sy by w fir­mach wpro­wa­dzić pro­ces zna­ny z urzę­dów i sys­te­mu Archiwów Państwowych: nada­wa­nie kate­go­rii archi­wal­nej każ­dej dokumentacji.

Problem nie jest pro­sty, mam wra­że­nie, że czę­sto igno­ro­wa­ny bo dys­ki twar­de tanie­ją”, jed­nak nie ma pro­ble­mu z tym by coś wynieść na strych, pro­blem w tym by to po kil­ku latach odna­leźć”. Kolejny pro­blem to psy­cho­lo­gia i czy­sta ludz­ka wyobraź­nia: po latach mamy nie raz wra­że­nie, że coś co zacho­wa­li­śmy kie­dyś nadal ma war­tość taką jak w dniu zacho­wa­nia, co z regu­ły oka­zu­je się nie­praw­dą. Rzecz w tym, że war­tość danych ope­ra­cyj­nych male­je z upły­wem cza­su (dez­ak­tu­ali­zu­ją się dane o cenach, warun­kach han­dlo­wych itp.). Można zary­zy­ko­wać tezę, że po roku więk­szość z nich (szcze­gó­ły) jest nie­przy­dat­na. Co naj­wy­żej war­tość ma sam fakt, że do jakichś kon­tak­tów docho­dzi­ło, jaki był ich cel itp.

Jak sobie z tym radzić? Narzędzie poma­ga­ją­ce w tym, zawar­te jest w więk­szo­ści dobrych sys­te­mów zarzą­dza­nia prze­pły­wem pra­cy i doku­men­tów. Każdy taki sys­tem ma tak zwa­ne [[repo­zy­to­rium doku­men­tów]]. Jest to archi­wum pli­ków (doku­men­ty, zdję­cia, pli­ki źró­dło­we, itp.), dużą war­to­ścią repo­zy­to­riów jest to, że maja tak zwa­ny sys­tem meta­da­nych. [[Metadane]] to struk­tu­ral­ny opis nie­struk­tu­ral­nej zawar­to­ści prze­cho­wy­wa­nych plików.

Właściwy pro­jekt tych meta­da­nych ([[tak­so­no­mia]]) pozwa­la na stwo­rze­nie dwóch dodat­ko­wych cech przy­dat­nych w sys­te­mach [[busi­ness inteligence]]:

  1. meta­da­ne (jako dane struk­tu­ral­ne) mogą być migro­wa­ne do hur­tow­ni danych,
  2. meta­da­ne nadal zacho­wu­ją klu­czo­we infor­ma­cje po usu­nię­ciu pli­ków źró­dło­wych (z regu­ły dużych i nie­przy­dat­nych, np. po latach nadal będzie­my wie­dzie­li jak czę­sto kon­tak­to­wał się z nami klient i po co, mimo bra­ku dostę­pu do już bez­war­to­ścio­wych danych o szcze­gó­łach tych kontaktów).

Warto two­rzyć dobrze prze­my­śla­ne sys­te­my meta­da­nych dla sys­te­mów archi­wi­za­cji doku­men­tów, gdyż pozwa­la to z jed­nej stro­ny spiąć” archi­wum doku­men­tów z hur­tow­nią danych z dru­giej pozbyć się” śmie­ci. Tempo przy­ro­stu danych sta­le rośnie gdyż biz­ne­so­we opro­gra­mo­wa­nie, auto­ma­ty­zu­jąc wie­le naszych czyn­no­ści, wytwa­rza je w tem­pie w jakim czło­wiek nigdy nie był by w sta­nie. Po dru­gie nara­sta zja­wi­sko powie­la­nia, co nazy­wam to syn­dro­mem copy&paste”. Wiele doku­men­tów (o zgro­zo tak­że tych podob­no autor­skich”) powsta­je coraz czę­ściej meto­dą powie­la­nia tego co znaj­dzie się w fir­mo­wych archi­wach (wie­dza kor­po­ra­cyj­na czy­li po pro­stu jej zanik, bo wie­dza to umie­jęt­ność napi­sa­nia cze­goś a nie sko­pio­wa­nia) czy w sieci.

Moja prak­ty­ka (to co dosta­je do audy­tu u klien­tów) poka­zu­je, że doku­men­ty wytwo­rzo­ne od zera” prak­tycz­nie zawsze mają więk­szą war­tość mery­to­rycz­ną niż te wytwo­rzo­ne na bazie tak zwa­nej wie­dzy kor­po­ra­cyj­nej”. Do tego docho­dzi ryzy­ko prze­nie­sie­nia, pod­czas kopio­wa­nia, tre­ści nie­chcia­nych. Kopiując dzie­siąt­ki stron sta­rej ofer­ty” lub poprzed­nie­go opra­co­wa­nia dorad­cze­go”, two­rząc w ten spo­sób kolej­ne indy­wi­du­al­ne autor­skie opra­co­wa­nie” nara­zić się moż­na nie tyl­ko na ujaw­nie­nie tajem­ni­cy, ale tak­że na zwy­kłe ośmie­sze­nie. Dlatego nie tyl­ko sys­tem zarzą­dza­nia doku­men­ta­mi i wie­dzą nale­ży dobrze zapro­jek­to­wać, ale tak­że pro­ces two­rze­nia nowych tre­ści. W prze­ciw­nym wypad­ku nara­ża­my się na budo­wę wiel­kie­go, ośmie­sza­ją­ce­go fir­mę, śmietnika.

Terminem bli­sko sko­ja­rzo­nym z ana­li­zą dzie­dzi­ny i pro­jek­to­wa­niem tak­so­no­mii jest [[onto­lo­gia]]. Tu dla uła­twie­nia cytat z wikipedii:

Termin onto­lo­gia” w infor­ma­ty­ce i podej­ściu systemowym

Termin onto­lo­gia” cie­szy się coraz to wiek­szą popu­lar­no­ścią w infor­ma­ty­ce (np. w budo­wie sie­ci seman­tycz­nych) oraz bada­niach nad sztucz­ną inte­li­gen­cją gdzie ozna­cza to co jest” i może slu­życ jako plat­for­ma ter­mi­no­lo­gicz­na do for­mal­nej budo­wy infor­ma­cji, pre­fe­ren­cji i wie­dzy (Model IPK).

Ontologia” w kon­tek­ście infor­ma­tycz­nym poja­wi­ła się już w roku 1967 w bada­niach doty­czą­cych mode­lo­wa­nia danych, ale dopie­ro w dobie zale­wu infor­ma­cją dostęp­ną w Internecie i koniecz­no­ścią jej prze­twa­rza­nia zysku­je szer­sze zain­te­re­so­wa­nie. Według Gadomskiego, onto­lo­gia w uogól­nio­nym sen­sie sys­te­mo­wym zaj­mu­je się opi­sy­wa­niem ?tego co jest? lub ?moze być? w danej dzie­dzi­nie zain­te­re­so­wa­nia Meta-teo­ria TOGA, w pew­nym frag­men­cie rze­czy­wi­sto­ści lub w ramach jakiejs teo­rii, mniej lub bar­dziej dokład­nie okre­ślo­nym dla dane­go agen­ta inte­li­gent­ne­go lub robo­ta dla osia­gnie­cia zada­ne­go celu. Aby zapew­nić jed­no­znacz­ność prze­ka­zu wie­dzy na temat okre­ślo­nej rze­czy­wi­sto­ści, na zada­nym pozio­mie og?lnosci, wyko­rzy­stu­je się kate­go­ry­za­cję oraz hie­rar­chi­za­cję. W niniej­szym kon­tek­ście, poję­cia te moż­na zde­fi­nio­wać następująco:

  • kate­go­ry­za­cja ? zdol­ność przy­po­rząd­ko­wa­nia sym­bo­lu wystę­pu­ją­ce­go w komu­ni­ka­cie do okre­ślo­nej gru­py obiek­tów wystę­pu­ją­cych w zada­nej dzie­dzi­nie np. ?kot? ? kla­sa kotów, poję­cie kot.
  • hie­rar­chi­za­cja ? umiej­sco­wie­nie okre­ślo­nej kla­sy w hie­rar­chicz­nej struk­tu­rze. Instancja kla­sy poza oczy­wi­sty­mi cha­rak­te­ry­sty­ka­mi wyni­ka­ją­cy­mi z przy­na­leż­no­ści do kla­sy posia­da tak­że cechy dzie­dzi­czo­ne z klas nadrzędnych.

W uje­ciach sys­te­mo­wym, kogni­tyw­nym i infor­ma­tycz­nym poję­cie «onto­lo­gia» jest poję­ciem rela­tyw­nym, naj­ogol­niej, dana onto­lo­gia zale­ży od dzie­dzi­ny, agen­ta inte­li­gent­ne­go kto­ry ją uży­wa i jego celu.

Aby wyraź­niej pod­kre­ślić cechy cha­rak­te­ry­stycz­ne tzw. top-onto­lo­gii (onto­lo­gii uniwersalnej/ogolnej, onto­lo­gii świa­ta), nale­ży przed­sta­wić kil­ka obec­nie dys­ku­to­wa­nych postu­la­tów doty­czą­cych jej funk­cjo­nal­nych cech :

  1. nie sta­no­wi listy, kata­lo­gu czy tak­so­no­mii obiek­tów, stwa­rza nato­miast for­mal­ne prze­słan­ki, wedle któ­rych tako­we mogą być budowane
  2. jest ode­rwa­na od teo­rii pozna­nia (epi­ste­mo­lo­gii), powią­za­na jest z obiek­tem, a nie jego subiek­tyw­nym odbiorem
  3. musi uchwy­cić rze­czy­wi­stość na róż­nych pozio­mach ato­mi­za­cji, jak rów­nież rela­cje pomię­dzy tymi warstwami
  4. uzna­nie bra­ku moż­li­wo­ści stwo­rze­nia jed­nej ogól­nej onto­lo­gii, ist­nie­nie wie­lu ontologii
  5. w prze­ci­wień­stwie do nauki rela­cje mię­dzy obiek­ta­mi nie są uję­te funk­cyj­nie (zależ­no­ści nie są ilościowe)
  6. nauka roz­po­czy­na pro­ces od mie­rze­nia i pre­dyk­cji, onto­lo­gia zaś od budo­wa­nia taksonomii

(za Ontologia ? Wikipedia, wol­na ency­klo­pe­dia.)

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 ;).