I jak to wszyst­kim poka­zać żeby było czytelne?

Wstęp

Niedawno napi­sał do mnie czy­tel­nik pod jed­nym z artykułów:

Załóż­my, że reali­zu­je­my pro­ces biz­ne­so­wy: zarzą­dza­nie kur­sa­mi walut. W ramach pro­ce­su pra­cow­nik musi przy­go­to­wać plik csv zawie­ra­ją­cy wyłącz­nie listę słow­ni­ko­wą par walut (np. usdpln, eurpln, eurusd). Nazwa pli­ku to np bie­żą­cą data. Następnie systemX łączy się z API zewnętrz­nej plat­for­my i pobie­ra tabe­le kur­sów tych par walut (aktu­al­ne i histo­rycz­ne mie­siąc wstecz) i wysta­wia plik xls zawie­ra­ją­cy dane: nazwa pary walut, data kur­su, war­tość kur­sy) Plik ten sys­tem X wysy­ła do szy­by ESB. Szyna prze­sy­ła ten plik do systemuY. SystemY wyko­rzy­stu­je te dane do wyzna­cze­nia wewnętrz­nych kur­sów walut wg. usta­lo­ne­go mode­lu mate­ma­tycz­ne­go. Wynik obli­czeń odkła­da­ny jest w bazie danych tego sys­te­mu. Na koń­cu pro­ce­su jest pra­cow­nik, któ­ry wyko­rzy­stu­je te infor­ma­cje za pośred­nic­twem SystemuZ. Wybiera parę walut, okre­śla datę i sys­tem zwra­ca mu wewnętrz­ny kurs wyzna­czo­ny przez SystemY. Technicznie odby­wa się poprzez odpy­ta­nie sys­te­mu Y poprzez jego API. Czyli mamy SystemX, SystemY, SystemZ, pra­cow­ni­ka, szy­nę, plik csv, plix xls, 2XAPI no i prze­pływ danych (naj­pierw pli­ków, potem poszcze­gól­nych atry­bu­tów) . I jak to wszyst­kim poka­zać żeby było czy­tel­ne? (źr.: : Model poję­cio­wy, model danych, model dzie­dzi­ny sys­te­mu)

Prawdę mówiąc, mniej wię­cej w takiej for­mie dosta­je mate­ria­ły od moich klien­tów.. ;). Co może­my zro­bić? Pomyślałem, że dobry repre­zen­ta­tyw­ny przy­kład. Popatrzmy…

Czytaj dalej… I jak to wszyst­kim poka­zać żeby było czy­tel­ne?”

Korzystanie pośrednie nową obawą użytkowników systemów ERP

Niedawno bla­dy strach padł na użyt­kow­ni­ków opro­gra­mo­wa­nie SAP AG za spra­wą pew­ne­go pro­ce­su i wyroku: 

Po nie­daw­nym orze­cze­niu bry­tyj­skie­go Sądu Najwyższego, któ­ry potwier­dził pra­wo fir­my SAP do nali­cza­nia opłat za pośred­nie korzy­sta­nie z sys­te­mów SAP przy uży­ciu takich apli­ka­cji innych firm jak Salesforce, WorkDay i QlikView, korzy­sta­nie pośred­nie jest obec­nie wymie­nia­ne przez klien­tów fir­my SAP jako głów­na oba­wa w obsza­rze zarzą­dza­nia licen­cja­mi SAP i kon­tro­lo­wa­nia ich kosz­tów. […] W ostat­nich tygo­dniach ryzy­ko zwią­za­ne z korzy­sta­niem pośred­nim ? dotych­czas głów­nie teo­re­tycz­ne ? sta­ło się rze­czy­wi­sto­ścią, któ­ra może zmu­sić wie­le przed­się­biorstw do ponie­sie­nia milio­no­wych nie­za­bu­dże­to­wa­nych kosz­tów dodat­ko­wych licen­cji SAP. (Źródło: Korzystanie pośred­nie głów­ną oba­wą klien­tów SAP – ERP​-view​.pl

Cóż to jest to korzy­sta­nie pośred­nie” i w czym problem? 

In this instan­ce, the third par­ty sys­tems are acces­sing the SAP envi­ron­ment, pul­ling data and often wri­ting it back via a con­nec­tion to the SAP envi­ron­ment. Here a ?user? must be set up to gain access to the SAP sys­tem. On the sur­fa­ce then it can appe­ar like only one user (or a small num­ber of users) is per­for­ming actions on the SAP sys­tem. In reali­ty tho­ugh, the ?user? will be per­for­ming far more tasks than is possi­ble for a sin­gle per­son to under­ta­ke. (Źródło: SAP Audits ? Is it impos­si­ble to gau­ge finan­cial expo­su­re? – IT Asset Knowledgebase) 

Generalnie cho­dzi o to, że inte­gro­wa­ne ze sobą apli­ka­cje wymie­nia­ją dane i zle­ca­ją sobie” usłu­gi, i tu war­to wie­dzieć co (dane, logi­ka apli­ka­cyj­na) jest chro­nio­ne pra­wa­mi autor­ski­mi i co sta­no­wi know how. Problem tkwi w popraw­nym zde­fi­nio­wa­niu przed­mio­tu (obiek­tu) prze­twa­rza­nia, przed­mio­tu pra­wa autor­skie­go i tego co sta­no­wi know-how. 

W tek­ście Ochrona know-how orga­ni­za­cji ana­li­zo­wa­nej pisa­łem dość dokład­nie o pra­wach autor­skich i know-how. Tu kil­ka klu­czo­wych pojęć. 

USTAWA z dnia 4 lute­go 1994 r. o pra­wie autor­skim i pra­wach pokrew­nych mówi:

Art. 1. 1. Przedmiotem pra­wa autor­skie­go jest każ­dy prze­jaw dzia­łal­no­ści twór­czej o indy­wi­du­al­nym cha­rak­te­rze, usta­lo­ny w jakiej­kol­wiek posta­ci, nie­za­leż­nie od war­to­ści, prze­zna­cze­nia i spo­so­bu wyra­że­nia (utwór).

Art. 2.
1. Opracowanie cudze­go utwo­ru, w szcze­gól­no­ści tłu­ma­cze­nie, prze­rób­ka, adap­ta­cja, jest przed­mio­tem pra­wa autor­skie­go bez uszczerb­ku dla pra­wa do utwo­ru pierwotnego.
2. Rozporządzanie i korzy­sta­nie z opra­co­wa­nia zale­ży od zezwo­le­nia twór­cy utwo­ru pier­wot­ne­go (pra­wo zależ­ne), chy­ba że autor­skie pra­wa mająt­ko­we do utwo­ru pier­wot­ne­go wyga­sły. W przy­pad­ku baz danych speł­nia­ją­cych cechy utwo­ru zezwo­le­nie twór­cy jest koniecz­ne tak­że na spo­rzą­dze­nie opracowania.
2. (1) Ochroną obję­ty może być wyłącz­nie spo­sób wyra­że­nia; nie są obję­te ochro­ną odkry­cia, idee, pro­ce­du­ry, meto­dy i zasa­dy dzia­ła­nia oraz kon­cep­cje matematyczne.

USTAWA z dnia 16 kwiet­nia 1993 r. o zwal­cza­niu nie­uczci­wej kon­ku­ren­cji, mówi, że:

Art. 11.
4. Przez tajem­ni­cę przed­się­bior­stwa rozu­mie się nie­ujaw­nio­ne do wia­do­mo­ści publicz­nej infor­ma­cje tech­nicz­ne, tech­no­lo­gicz­ne, orga­ni­za­cyj­ne przed­się­bior­stwa lub inne infor­ma­cje posia­da­ją­ce war­tość gospo­dar­czą, co do któ­rych przed­się­bior­ca pod­jął nie­zbęd­ne dzia­ła­nia w celu zacho­wa­nia ich poufności.

Tak więc mamy klu­czo­we poję­cie: utwór oraz know-how. Utworem jest uni­kal­na treść zaś know-how to nie­ujaw­nio­ne i chro­nio­ne (!) infor­ma­cje (tre­ści) tech­nicz­ne, orga­ni­za­cyj­ne lub gospodarcze.

Czym jest owo pośred­nie korzy­sta­nie z sys­te­mu SAP”? Drugi tekst wyja­śnia: acces­sing the SAP envi­ron­ment, pul­ling data and often wri­ting it back via a con­nec­tion to the SAP envi­ron­ment. Here a ?user? must be set up to gain access to the SAP sys­tem”. Czyli pobie­ra­nie i zapi­sy­wa­nie danych”, użyt­kow­nik by mógł tego doko­nać” musi mieć dostęp Systemu SAP.

Jednak sam fakt ist­nie­nia dostę­pu i korzy­sta­nia z nie­go, nie ozna­cza korzy­sta­nia z cudzych war­to­ści intelektualnych!

Najpierw model takie­go przypadku:

Użytkownik bez­po­śred­ni Systemu to stan­dar­do­wy”, licen­cjo­no­wa­ny użyt­kow­nik. Aplikacja pośred­ni­czą­ca tak­że korzy­sta z licen­cjo­no­wa­ne­go dostę­pu (API). Jak, i z cze­go (i czy), korzy­sta Użytkownik pośred­ni Systemu?

Żeby wska­zać to, z cze­go korzy­sta zewnętrz­ny użyt­kow­nik (aktor) Systemu, nale­ży zaj­rzeć” do wnę­trza sys­te­mu. Architektura Systemu i inte­gra­cji ma taką postać:

Na tym dia­gra­mie mamy trzy klu­czo­we ele­men­ty (tu arte­fak­ty) repre­zen­tu­ją­ce war­to­ści inte­lek­tu­al­ne chro­nio­ne pra­wem: Logika biz­ne­so­wa, Zebrane dane i Strukturę danych. Logika biz­ne­so­wa to spo­sób (meto­dy) prze­twa­rza­nia infor­ma­cji (danych) zawar­te w pro­gra­mie kom­pu­te­ro­wym, sta­no­wią (mogą sta­no­wić) know-how fir­my, sam pro­gram kom­pu­te­ro­wy (jego treść) to usta­lo­ny utwór. Prawo autor­skie chro­ni bazy danych (zebra­ne i upo­rząd­ko­wa­ne dane) zaś struk­tu­ra danych (pro­jekt, model danych) to tak­że utwór chroniony.

Zintegrowana z Systemem apli­ka­cja korzy­sta z API Systemu. API stan­dar­do­wo pozwa­la np: na pobra­nie obiek­tu, wsta­wie­nie obiek­tu oraz wyko­na­nie ope­ra­cji z uży­ciem logi­ki biznesowej. 

Zasadnicze pyta­nie brzmi: co w Systemie sta­no­wi pro­dukt dzia­łal­no­ści twór­czej o indy­wi­du­al­nym cha­rak­te­rze”? Na pew­no jest to opro­gra­mo­wa­nie jako takie oraz struk­tu­ra (model) danych oraz baza danych, czy­li zebra­ne dane (z uwa­gi na ich uni­kal­ną struk­tu­rę, model, w bazie danych). Jednak pro­gram reali­zu­je okre­ślo­ną logi­kę biz­ne­so­wą (ope­ra­cje na danych) i prze­twa­rza okre­ślo­ne obiek­ty biz­ne­so­we, czy­li okre­ślo­ne zesta­wy danych takie jak fak­tu­ra czy doku­ment maga­zy­no­wy WZ. Ogólnie ope­ra­cje z uży­ciem Systemu (apli­ka­cji) mają np. taką postać:

Jest to przy­kład moż­li­we­go dia­lo­gu użyt­kow­ni­ka (aktor) z apli­ka­cją (System). Dialog taki, nie­za­leż­nie od stop­nia kom­pli­ka­cji, będzie się skła­dał z ope­ra­cji będą­cych logi­ką biz­ne­so­wą (czy­li spe­cy­fi­ką dzie­dzi­ny) lub tech­nicz­ną (spe­cy­fi­ką tech­no­lo­gii imple­men­ta­cji). Przedmiotem prze­twa­rza­nia będą okre­ślo­ne obiek­ty biz­ne­so­we (nazwa­ne zesta­wy danych), komu­ni­kat na ekra­nie tak­że może być takim obiek­tem (jeże­li tym komu­ni­ka­tem jest treść doku­men­tu a nie tyl­ko tekst mówią­cy, że coś zosta­ło wyko­na­ne np. bez błędu).

Tu jed­nak mamy do czy­nie­nia z opro­gra­mo­wa­niem wspie­ra­ją­cym mię­dzy inny­mi ope­ra­cje opi­sa­ne w usta­wach (księ­go­we). Niewątpliwie pra­wo chro­ni struk­tu­rę danych, dane zebra­ne w bazie danych oraz know-how, to któ­re jest nie­zna­ne innym”. Jednak pra­wo nie chro­ni idei, nie chro­ni też tego co jest powszech­nie zna­ne”. Warto tak­że wie­dzieć, że wdro­że­nie w toku któ­re­go mia­ła miej­sce tak zwa­na kasto­mi­za­cja, wno­si” know-how przy­szłe­go użyt­kow­ni­ka do kodu, i za korzy­sta­nie z tej logi­ki dostaw­ca opro­gra­mo­wa­nia nie ma pra­wa brać wyna­gro­dze­nia. Pod warun­kiem jed­nak, że kod reali­zu­ją­cy to wnie­sio­ne know-how jest jaw­nie wydzielony! 

Nie ma jed­no­znacz­nej odpo­wie­dzi na pyta­nie czy w danym przy­pad­ku ma miej­sce korzy­sta­nie pośred­nie z opro­gra­mo­wa­nia, nie­wąt­pli­wie sam fakt inte­gra­cji nie sta­no­wi korzy­sta­nia pośred­nie­go. Nie jest tez praw­dą, ze sam fakt inte­gra­cji auto­ma­tycz­nie impli­ku­je korzy­sta­nie pośred­nie wyma­ga­ją­ce opła­ty licen­cyj­nej. Kluczem do stwier­dze­nia tego jest wie­dza o archi­tek­tu­rze sys­te­mu, o archi­tek­tu­rze cało­ści inte­gra­cji i o tym jakie ope­ra­cje i gdzie są wyko­ny­wa­ne. Na szczę­ście to dostaw­ca Systemu musi uza­sad­nić swo­je rosz­cze­nia doty­czą­ce wła­sno­ści inte­lek­tu­al­nej, jed­nak korzy­sta­ją­cy z tego Systemu – jeże­li nie potra­fi podać kontr­ar­gu­men­tów – nie jest w sta­nie się obro­nić. Niestety naj­więk­szym pro­ble­mem jest wdro­że­nie pole­ga­ją­ce na kasto­mi­za­cji, gdyż docho­dzi do wple­ce­nia” nowej logi­ki biz­ne­so­wej do już ist­nie­ją­cej w dostar­cza­nym oprogramowaniu.

Skutek jest taki, że dostaw­ca opro­gra­mo­wa­nia ma pod­sta­wy praw­ne do ochro­ny kodu jaki dostar­czył, jed­nak kupu­ją­cy nie ma żad­nych pod­staw (doku­men­ty, pro­jekt itp.) by chro­nić swo­je know-how i by nie pła­cić za swo­je wła­sne know-how wło­żo­ne” w toku wdro­że­nia, do wdra­ża­ne­go oprogramowania. 

Dlatego war­to restryk­cyj­nie pro­wa­dzić pro­ces ana­li­zy i pro­jek­to­wa­nia, to jest umie­jęt­nie udo­ku­men­to­wać pro­jekt tak, by gra­ni­ca pomię­dzy war­to­ścia­mi inte­lek­tu­al­ny­mi dostaw­cy i nabyw­cy opro­gra­mo­wa­nia była jasno okre­ślo­na. I nie jest to rola praw­ni­ka a archi­tek­ta cało­ści sys­te­mu, któ­ry musi tak­że znać i rozu­mieć praw­ne aspek­ty tej architektury. 

Czy wdrożenie zawsze wymaga reorganizacji?

Bardzo czę­sto spo­ty­kam się z pro­jek­ta­mi ini­cjo­wa­ny­mi przez śred­nie kadry kie­row­ni­cze dużych firm i urzę­dów, czę­sto mają one pew­ną wspól­ną cechę: nie może­my nic zmie­niać w stra­te­gii orga­ni­za­cji ale chce­my uspraw­nić pra­cę w naszym wydzia­le”. To z regu­ły bar­dzo cen­na ini­cja­ty­wa ale tak­że dobra dro­ga do poraż­ki pro­jek­tu. W urzę­dach czę­sto na gra­ni­cy łama­nia pra­wa… a nie raz z jego łama­niem. 

Projekty w admi­ni­stra­cji publicz­nej mają dodat­ko­wą spe­cy­fi­kę: zasa­dy usta­la pra­wo­daw­ca a nie mene­dżer orga­ni­za­cji. Bardzo dobrze opi­sał to zja­wi­sko prof. Bolesław Szafrański wska­zu­jąc przy­czy­nę wie­lu pora­żek wdro­żeń w admi­ni­stra­cji. Opisał trzy-eta­po­wy refe­ren­cyj­ny (i zale­ca­ny) pro­ces wdra­ża­nia nowych roz­wią­zań, a na jego tle, w swo­im opra­co­wa­niu, wska­zał dostrze­żo­ne zanie­dba­nia administracji:

(źr. na podst.: Bolesław Szafrański, Wydział Cybernetyki, Wojskowa Akademia Techniczna, Architektura kor­po­ra­cyj­na ? pro­ble­my nie tyl­ko pojęciowe”)

Cytuję to opra­co­wa­nie, bo model ten jest bar­dzo podob­ny do ogól­nej trój­war­stwo­wej kon­cep­cji orga­ni­za­cji. Prof Szafrański zwra­ca uwa­gę na to (z czym się zga­dzam), że kolej­ność podej­mo­wa­nia decy­zji i dzia­łań, powin­na być nastę­pu­ją­ca: opra­co­wa­nie nowej lub zmie­nio­nej stra­te­gii (Dokument stra­te­gicz­ny), opra­co­wa­nie tak­ty­ki dzia­ła­nia (Model ope­ra­cyj­ny dzia­ła­nia) oraz opra­co­wa­nie pla­nu wdro­że­nia IT (Fundament dzia­łal­no­ści, w kon­tek­ście Architektury Korporacyjnej). Oczywiście nic nie stoi na prze­szko­dzie, by ini­cja­ty­wa wyszła od dołu”.

W swo­im opra­co­wa­niu prof. Szafrański wska­zu­je, że wdro­że­nie nowej stra­te­gii wyma­ga spraw­dze­nia i ewen­tu­al­ne­go opra­co­wa­nia nowych mecha­ni­zmów, pro­ce­dur, pra­wa, pozwa­la­ją­ce­go nie tyl­ko wdro­żyć nową stra­te­gię ale tak­że sku­tecz­nie ją wymu­sić”.

Jeżeli powyż­szy model uogól­nić do posta­ci obra­zu­ją­cej zwią­zek pomię­dzy: stra­te­gią ryn­ko­wą orga­ni­za­cji, wewnętrz­ną tak­ty­ką reali­za­cji misji oraz tym jak zosta­ły one zaim­ple­men­to­wa­ne, to powsta­nie taki oto dia­gram (po pra­wej zna­ne od lat opra­co­wa­nie Business Process Trends):

Jeżeli pomiąć for­mę praw­ną, każ­da orga­ni­za­cja ma stra­te­gię i każ­da jakoś ją reali­zu­je (imple­men­tu­je: ma pra­cow­ni­ków a Ci umie­jęt­no­ści i zakre­sy obo­wiąz­ków). Mało któ­ra orga­ni­za­cja ma tak zwa­ny model ope­ra­cyj­ny”, czy­li to co łączy stra­te­gię i ludzi z ich obo­wiąz­ka­mi i uzy­ski­wa­ny­mi efek­ta­mi pra­cy. Czym jest taki model? To model pro­ce­sów biz­ne­so­wych: środ­ko­wa war­stwa” powyż­sze­go dia­gra­mu po prawej.

Rozwijające się ewo­lu­cyj­nie orga­ni­za­cje zawsze doku­men­tu­ją deta­le prac (infor­ma­cje w pro­ce­du­rach zarzą­dza­nia jako­ścią i tak zwa­nych doku­men­tach kadro­wych), czę­sto doku­men­tu­ją to, jaką rolą peł­ni orga­ni­za­cja w swo­im oto­cze­niu (misja, wizja, stra­te­gie itp.) i bar­dzo rzad­ko doku­men­tu­ją wewnętrz­ny łań­cuch war­to­ści czy­li pro­ce­sy biz­ne­so­we oraz, no naj­waż­niej­sze, logi­ka tego jak to wszyst­ko dzia­ła” w środ­ku (i czy dzia­ła z sen­sem). Wadą więk­szo­ści tego typu pro­jek­tów, jakie obser­wu­ję, jest sku­pia­nie się na deta­lach i pomi­ja­nie pryn­cy­piów. W efek­cie pro­jekt pochła­nia wie­le pra­cy i nadal nie mamy zro­zu­mie­nia cało­ści (w lit. ang. big pic­tu­re”), osią­ga­ne efek­ty są losowe. 

Pokażę na dość pro­stym przy­kła­dzie o czym mowa (pole­cam ww. opra­co­wa­nie prof. Szafrańskiego, opi­sał w nim błę­dy popeł­nio­ne w przy­pad­ku infor­ma­ty­za­cji Państwa). 

Poniższy dia­gram to uprosz­czo­ny model orga­ni­za­cji z zain­sta­lo­wa­nym sys­te­mem EOD (Elektroniczny Obieg Dokumentów) oraz zacho­wa­nym, nadal wyko­rzy­sty­wa­nym po sta­re­mu” opro­gra­mo­wa­niem pocz­ty elektronicznej. 

Linie cią­głe to dro­ga jaką poko­nu­ją doku­men­ty z uży­ciem EOD. Linie prze­ry­wa­ne to pocz­ta elek­tro­nicz­na. Jeżeli zosta­nie w jakiejś orga­ni­za­cji zain­sta­lo­wa­ny EOD (celo­wo nie uży­wam sło­wa wdro­żo­ny”) i nie zosta­nie z niej usu­nię­ty ema­il jako narzę­dzie alter­na­tyw­nej wewnętrz­nej komu­ni­ka­cji, to użyt­kow­nik będzie sam decy­do­wał, o tym któ­rym kana­łem prze­ka­że daną treść. W efek­cie EOD, któ­ry miał mieć wszyst­ko” nie ma wszyst­kie­go, dane w EOD są nie­wia­ry­god­ne i nie­kom­plet­ne. Jeżeli jest to urząd, to metry­ka spra­wy w zasa­dzie nie ma sen­su, celem jej two­rze­nia była moż­li­wość odtwo­rze­nia peł­ne­go prze­bie­gu spra­wy, a tu urzęd­nik sam decy­du­je, któ­re infor­ma­cje i doku­men­ty prze­ka­zu­je kana­łem for­mal­nym (EOD), a któ­re na boku”. Czy wszyst­ko musi być w EOD? Tak. Jeżeli nie jest, EOD jest tyl­ko uzna­nio­wym archi­wum dokumentów. 

Aby sku­tecz­nie wdro­żyć EOD nale­ży naj­pierw opra­co­wać nowy model ope­ra­cyj­ny dzia­ła­nia orga­ni­za­cji, model uwzględ­nia­ją­cy nowe narzę­dzie pra­cy, model któ­ry w spo­sób sys­te­mo­wy wyeli­mi­nu­je nie­po­żą­da­ne ele­men­ty złe­go sta­re­go sys­te­mu”. Dla przy­kła­du powy­żej nale­ży wyeli­mi­no­wać kana­ły komu­ni­ka­cyj­ne ozna­czo­ne linią prze­ry­wa­ną. Domyślam się, że wie­lu czy­tel­ni­ków myśli teraz no jak to tak bez maila?!”. Po wdro­że­niu EOD, wewnętrz­ny mail jest już nie potrzeb­ny (a nawet jest szko­dli­wy), a na zewnątrz nadal jest narzę­dziem komu­ni­ka­cji fir­ma-fir­ma (tak np. dzia­ła mój sys­tem komu­ni­ka­cji z klien­ta­mi). Bardzo czę­sto spo­ty­kam urzę­dy i fir­my, w któ­rych obieg ema­il i obieg for­mal­ny” to uzna­nio­wość pra­cow­ni­ków. Te wdro­że­nia nie speł­nia­ją pod­sta­wo­wej roli sys­te­mów EOD: śle­dze­nie spraw, sta­ty­sty­ki zaję­to­ści pra­cow­ni­ków, wychwy­ty­wa­nie wąskich gar­deł, łatwe zastę­po­wa­nie się pra­cow­ni­ków, moż­li­wość skon­tro­lo­wa­nia i prze­ję­cia spra­wy w dowol­nym momen­cie, peł­na histo­ria wymia­ny informacji. 

Takie wdro­że­nia to wła­śnie bar­dzo czę­sto ini­cja­ty­wy na śred­nich szcze­blach, gdzie mogą powstać decy­zje o wyda­niu środ­ków na takie wdro­że­nie, ale nie ma żad­nych szans na decy­zje o opra­co­wa­niu i wdro­że­niu zmian ope­ra­cyj­nych w ska­li orga­ni­za­cji (np. aktu­ali­za­cja instruk­cji kan­ce­la­ryj­nej w urzę­dzie, bez cze­go wdro­że­ni EOD nie ma tu żad­ne­go sensu).

Celowo poda­łem ten przy­kład, bo typo­wym powo­dem nie­po­wo­dzeń wdro­żeń sys­te­mów EOD czy CRM (te sys­te­my mają naj­gor­szą sta­ty­sty­kę nie­po­wo­dzeń, a są bar­dzo podob­ne do sie­bie), jest brak opra­co­wa­ne­go i wdro­żo­ne­go sku­tecz­ne­go nowe­go ope­ra­cyj­ne­go mode­lu dzia­ła­nia orga­ni­za­cji po wdro­że­niu”. Takim mode­lem są mode­le pro­ce­sów biz­ne­so­wych, ale nie w posta­ci mon­stru­al­nych ilo­ści deta­licz­nych dia­gra­mów (te są tu do nicze­go nie przy­dat­ne). Nie znam przy­pad­ku, by takie obraz­ki” się do cze­go­kol­wiek przy­da­ły. Chodzi o mode­le sfor­ma­li­zo­wa­ne, o ści­śle usta­lo­nym pozio­mie gra­da­cji pro­ce­sów. Ile dia­gra­mów powin­no być”? Tylko i aż tyle, ile trze­ba do roz­wią­za­nia pro­ble­mu… co opi­sa­łem mię­dzy inny­mi tu.

Powyższe ma tak­że inny istot­ny aspekt: pla­no­wa­nie i wdra­ża­nie zmian. Typowy roz­wój orga­ni­za­cji prze­bie­ga w spo­sób ewo­lu­cyj­ny, dość powol­ny. Nie wyma­ga żad­nych dodat­ko­wych zabie­gów poza prze­my­śla­nym wpro­wa­dza­niem nowych, poje­dyn­czych zarzą­dzeń czy drob­nych zmian orga­ni­za­cyj­nych. Jednak pró­by wdro­że­nia znacz­nych zmian w krót­kim cza­sie, z regu­ły skut­ku­ją nie­ocze­ki­wa­ny­mi efek­ta­mi, nie zawsze pożą­da­ny­mi. Moda” na re-inży­nie­rię pro­ce­sów biz­ne­so­wych w latach 90-tych prze­mi­nę­ła tak szyb­ko jak się poja­wi­ła. Dzisiejszy sil­nie kon­ku­ren­cyj­ny rynek nie daje cza­su na powol­ne, ewo­lu­cyj­ne zmia­ny. Bezpieczne zaś wpro­wa­dza­nie takich zmian nie jest moż­li­we bez przy­go­to­wa­nia. Opisane powy­żej pla­ny ope­ra­cyj­ne i ich testy, to nic inne­go jak wła­śnie przy­go­to­wa­nie się do takich zmian. Mając dobrze opra­co­wa­ne mode­le pro­ce­sów i archi­tek­tu­ry IT (jako całość Architektura Biznesowa/Korporacyjna), może­my prze­wi­dzieć i prze­te­sto­wać, więk­szość skut­ków pla­no­wa­nych zmian, i powo­li ale coraz wię­cej firm to robi… 

What’s New in Visual Paradigm 13.2? Czyli co nowego…

Kolejna odsło­na w roz­wo­ju opro­gra­mo­wa­nia CASE fir­my Visual Paradigm. Agile, pierw­szych katach chur­ra opty­mi­zmu, zaczy­na trosz­kę się kry­sta­li­zo­wać co zauwa­żył już [[Scott Ambler]] 12 lat temu:

książ­ka trak­tu­ją­ca o tym, że zwin­ność nie ozna­cza bała­ga­nu i pospo­li­te­go rusze­nia. Scott Ambler to kolej­ny auto­ry­tet w inży­nie­rii opro­gra­mo­wa­nia. I mimo, że niko­go nie ma sen­su mał­po­wać, na pew­no war­to się uczyć? (Źródło: Agile Modeling. Effective Practices for Modeling and Documentation | | Jarosław Żeliński IT-Consulting)

Visual-Paradigm to tak­że zestaw narzę­dzi Agile pozwa­la­ją­cych z jed­nej stro­ny zwin­nie zarzą­dzać pro­jek­to­wa­niem i pro­jek­tem (to nie jest to samo) z dru­giej nie zanie­dby­wać ana­li­zy i mode­lo­wa­nia tam gdzie to jed­nak pomaga.

Nowe ele­men­ty v.13.2.:

  1. Kanban Board to nowe narzę­dzie pozwa­la­ją­ce zarzą­dzać zakre­sem pro­jek­tu i jego reali­za­cją. Kanban to opra­co­wa­na w latach pięć­dzie­sią­tych w Japonii meto­da ste­ro­wa­nia pro­duk­cją. Słowo kan­ban w wol­nym tłu­ma­cze­niu moż­na w poniż­szym przy­pad­ku oddać jako ?spis widocz­ny?. Tu prak­tycz­nie ozna­cza to co zna­my pod nazwą bac­klog” tyle, że wer­sji widocz­nej” jako tabli­cę postę­pu prac: bil­bo­ard dostęp­ny dla człon­ków zespołu.
  2. User Story Estimation to nowy para­metr obiek­tów user sto­ry”. Generalnie tu (w tym narzę­dziu) user sto­ry to nie pro­za użyt­kow­ni­ka” a sfor­ma­li­zo­wa­na wer­sja zna­na jako sza­blon ja jako .… chciał­bym osią­gnąć.… mając do dys­po­zy­cji …”, histo­ryj­ki te są para­me­try­zo­wa­ne mie­dzy inny­mi (teraz) esty­ma­cja cza­su ich imple­men­ta­cji co bar­dzo uła­twia zarza­dza­nie projektem.
  3. Kroki wyma­ga­ją­ce potwier­dze­nia, nowa cecha spe­cy­fi­ka­cji przy­pad­ków uży­cia, bar­dzo waż­na rzecz w spe­cy­fi­ko­wa­niu przy­pad­ków uży­cia to wska­za­nie tych kro­ków sce­na­riu­szy, któ­re wyma­ga­ją potwier­dze­nia przez system.
  4. Szybki pod­gląd (tak­że zesta­wie­nie) histo­ry­jek użyt­kow­ni­ka, w toku pro­jek­tu klu­czo­we jest śle­dze­nie pro­jek­tu, któ­ry nie raz ma set­ki deta­li w zakre­sie, od teraz dys­po­nu­je­my odpo­wied­ni­mi zesta­wie­nia­mi i pod­su­mo­wa­nia­mi, to jedy­ny spo­sób na spraw­ne zarza­dza­nie zakre­sem projektu.
  5. Makiety ekra­nów to kolej­ny bar­dzo waż­ny ele­ment komu­ni­ka­cji z zama­wia­ją­cym i defi­nio­wa­niem zakre­su pro­jek­tu, roz­bu­do­wa­na zosta­ła pale­ta ele­men­tów i ich cech.
  6. CMMN (Case Management Model and Notation) to nota­cja opu­bli­ko­wa­na for­mal­nie w 2014 roku. Notacja BPMN ma za cel mode­lo­wa­nie pro­ce­sów biz­ne­so­wych czy­li powta­rzal­nych zacho­wań orga­ni­za­cji, CMMN to narzę­dzie do mode­lo­wa­nia kon­kret­nych (ziden­ty­fi­ko­wa­nych) aktyw­no­ści, nie prze­wi­dzia­nych w mode­lach pro­ce­sów, tak­że do mode­lo­wa­nia pro­po­no­wa­nych (zaak­cep­to­wa­nych) roz­wią­zań, w przy­pad­ku gdy dana aktyw­ność stwa­rza problem.
  7. Zarządzanie pli­ka­mi w repo­zy­to­rium TeamWork (ser­wer) z pozio­mu prze­glą­dar­ki diagramów.
  8. Tymczasowe dia­gra­my ana­li­zy wpły­wu. Do tej pory były zawsze zapa­mię­ty­wa­ne co w dużych pro­jek­tach skut­ko­wa­ło dużą ich licz­bą i prze­cią­ża­niem pro­jek­tu, teraz mogą one być two­rzo­ne w locie” bez koniecz­no­ści ich zachowywania.

Źródło: What’s New in Visual Paradigm 13.2? 

Narzędzie potęż­nie­je z każ­dą kolej­ną wer­sją. Obecnie ofe­ro­wa­ne jest w dwóch wersjach:

  1. Visual-Paradigm (VP) jako narzę­dzie adre­so­wa­ne do wspie­ra­nia pro­ce­sów inży­nie­rii oprogramowania.
  2. ArchiMetric to roz­sze­rze­nie pakie­tu VP, to narzę­dzie wspie­ra­ją­ce pro­wa­dze­nie ana­liz sys­te­mo­wych orga­ni­za­cji, sze­ro­ko poję­te­go mode­lo­wa­nia archi­tek­tu­ry biz­ne­so­wej (kor­po­ra­cyj­nej).

W 2005 roku wybra­łem to narzę­dzie cał­ko­wi­cie przy­pad­ko­wo, kie­ro­wa­łem się cza­sem od momen­tu zamó­wie­nia do uzy­ska­nia licen­cji, bo dzia­ło się w toku bar­dzo waż­ne­go pro­jek­tu, w któ­rym nie mogłem sobie pozwo­lić ani na prze­rwę ani na zna­ki wod­ne eva­lu­ation ver­sion” w doku­men­tach w cza­sie ocze­ki­wa­nia na licen­cje. Po tych latach korzy­sta­nia z VP i porów­ny­wa­nia pra­cy z inny­mi narzę­dzia­mi spo­ty­ka­ny­mi w pro­jek­tach, nadal mam prze­ko­na­nie, że nie­świa­do­mie doko­na­łem wte­dy chy­ba naj­lep­sze­go moż­li­we­go wyboru.

Więcej o nowin­kach w aplikacji:

Visual Paradigm 13.2 intro­du­ces a num­ber of new featu­res, which includes:

(źr. https://​www​.visu​al​-para​digm​.com/​a​b​o​u​t​u​s​/​n​e​w​s​r​e​l​e​a​s​e​s​/​v​p​1​3​2​.​jsp)

Visual Paradigm 13.0 Opublikowany

Narzędzie, któ­re­go uży­wam od 2005 roku (rezy­gnu­jąc wte­dy z MS Visio bo topor­ny i wyrzu­ca­jąc demo EA SPARX bo topor­ny i nie­zgod­ny z UML), sta­je się coraz lep­sze. To co powo­du­je, że nadal nie pla­nu­ję zmie­niać narzę­dzia to mega ergo­no­mia pra­cy, 100% zgod­no­ści ze spe­cy­fi­ka­cja­mi OMG, a przede wszyst­kim ser­wer pra­cy gru­po­wej VPository, co razem daje mega plat­for­mę ana­li­tycz­no-komu­ni­ka­cyj­ną dla ana­li­ty­ka i klienta.

W nowej wersji:

Czytaj dalej… Visual Paradigm 13.0 Opublikowany”

Różne perspektywy wymagań

Często spo­ty­kam się z czymś takim jak Diagramy klas (UML) to mode­lo­wa­nie wyma­gań z per­spek­ty­wy danych (model danych)”. Jest to nie­ste­ty dość czę­sto spo­ty­ka­na here­zja”, tak­że w zale­ca­nej przez wie­lu lite­ra­tu­rze, o czym swe­go cza­su wspominałem:

Regularnie widu­je pyta­nia takie jak to: I have an assi­gn­ment for deve­lo­ping a hotel rese­rva­tion sys­tem! One of tasks is to deve­lop UML class dia­gram! However, in the task descrip­tion it is writ­ten ?Class dia­gram sho­uld repre­sent your data­ba­se?. I am a bit con­fu­sed abo­ut the rules, nota­tions and etc? becau­se I can?t find any offi­cial UML class dia­grams spe­ci­fi­cal­ly for data­ba­ses! Could you help me ple­ase? (UML class dia­gram for data­ba­se). I regu­lar­nie piszę: uży­wa­nie dia­gra­mu klas jako repre­zen­ta­cji [rela­cyj­nej] bazy danych to świa­dec­two kom­plet­ne­go nie­zro­zu­mie­nia ana­li­zy i pro­jek­to­wa­nia zorien­to­wa­ne­go obiek­to­wo (żeby nie powie­dzieć igno­ran­cji). Jest to tak­że świa­dec­two bra­ku zna­jo­mo­ści lite­ra­tu­ry, bo fak­tycz­nie, jak zauwa­ża autor powyż­szych słów, nie ma ofi­cjal­nych mate­ria­łów (orga­ni­za­cja stan­da­ry­zu­ją­ca) mówią­cych o mode­lo­wa­niu danych dia­gra­ma­mi klas w nota­cji UML. Do mode­lo­wa­nia danych uży­wa­my nota­cji ERD (ang. Entity Relationship, dia­gram związ­ków encji). Niestety takie wzmian­ki ? jak sto­so­wać dia­gram klas UML do mode­lo­wa­nia danych ? moż­na zna­leźć w książ­kach uzna­wa­nych za war­to­ścio­we (okład­ka jed­nej z nich po pra­wej), moż­na usły­szeć na wie­lu szko­le­niach doty­czą­cych nota­cji UML, a nawet usły­szeć o tym moż­na ? mode­lo­wa­nie danych w UML ? z ust nie­jed­ne­go wykła­dow­cy na uczel­niach wyż­szych tech­nicz­nych (co jest smut­ne, mam na pół­ce pod­ręcz­nik aka­de­mic­ki z opi­sem sto­so­wa­nia klu­czy głów­nych i obcych na dia­gra­mach klas UML w mode­lo­wa­niu danych). Źródło: Business Analysis ? dia­gram klas UML i bazy danych | Jarosław Żeliński IT-Consulting

Przypomnę po raz kolej­ny czym jest obiek­to­wy para­dyg­mat ana­li­zy i projektowania:

Paradygmat obiek­to­wy ana­li­zy i pro­jek­to­wa­nia to uzna­nie, że ana­li­zo­wa­ny lub pro­jek­to­wa­ny sys­tem to współ­pra­cu­ją­ce w okre­ślo­nym celu obiekty. 

Definicja ta jest zbież­na z defi­ni­cją poję­cia sys­tem: zło­żo­ny obiekt wyróż­nio­ny w bada­nej rze­czy­wi­sto­ści, sta­no­wią­cy całość two­rzo­ną przez zbiór obiek­tów ele­men­tar­nych (ele­men­tów) i powią­zań (związ­ków i rela­cji) mię­dzy nimi (Sienkiewicz, 1994).

Innymi sło­wy sys­tem, w rozu­mie­niu ogól­nej teo­rii sys­te­mów (UML i meto­dy obiek­to­we wspie­ra­ją wła­śnie tę teo­rię), sys­tem to zbiór współ­pra­cu­ją­cych obiek­tów. Nie ma tu żad­nej mowy o danych. Dlaczego? Bo współ­pra­cu­ją ze sobą obiek­ty a nie dane. Owszem, dys­po­nu­je­my nimi, ale … Każdy zespół współ­pra­cu­ją­cych ludzi nie­wąt­pli­wie wyko­rzy­stu­je, a nie raz prze­twa­rza, okre­ślo­ne infor­ma­cje. Jednak ta współ­pra­ca pole­ga na współ­pra­cy, infor­ma­cje są wymie­nia­ne na okre­ślo­nych nośni­kach, to obiek­ty biz­ne­so­we. Np. celem nego­cja­cji jest współ­pra­ca nego­cja­to­rów i pod­pi­sa­na umo­wa (jej treść to szcze­gó­ły przy­da­ne w spo­rze oraz cel zawar­cia umo­wy), celem sprze­da­ży jest przy­chód (a nie fak­tu­ra), celem dosta­wy jest towar w okre­śla­nym miej­scu i cza­sie (list prze­wo­zo­wy wska­zu­je miej­sce i czas, doku­ment WZ to tyl­ko spe­cy­fi­ka­cja kon­kret­ne­go przed­mio­tu tej dosta­wy) itd.

Popatrzmy na jeden z wie­lu szkie­le­tów tak zwa­nej archi­tek­tu­ry biz­ne­so­wej (archi­tek­tu­ra biz­ne­so­wa, archi­tek­tu­ra korporacyjna):

architektura biznesowa framework

(źr. https://it-consulting.pl//2014/10/07/wstep-do-architektury-biznesowej/)

Ma ona, każ­da orga­ni­za­cja, przede wszyst­kim cele. By mogła je reali­zo­wać ma: fasa­dę (tak się obja­wia na zewnątrz), wewnętrz­ne pro­ce­sy biz­ne­so­we, meto­dy komu­ni­ka­cja (z oto­cze­niem), oraz enti­ties” (nie mylić z mode­lem rela­cyj­nym danych) czy­li obiek­ty biz­ne­so­we, to co jest mię­sem” cało­ści, bo to one ze przed­mio­tem współ­pra­cy i nio­są infor­ma­cje. Każda orga­ni­za­cja to sys­tem zło­żo­ny ze współ­pra­cu­ją­cych ele­men­tów: tych nio­są­cych infor­ma­cje i tych mają­cych wie­dzę o mecha­ni­zmach (logi­ce) tej współpracy.

Kolejna waż­na rzecz to zauwa­że­nie, że opro­gra­mo­wa­nie to narzę­dzie pra­cy. Część (rzad­ko kie­dy wszyst­kie) obiek­tów biz­ne­so­wych (są nimi doku­men­ty i ich treść) będzie mia­ła swo­je wer­sję elek­tro­nicz­ną, co jed­nak nie zmie­nia fak­tu, że to jedy­na zmiana!

Tak więc kil­ka słów o wyma­ga­niach na narzę­dzie pra­cy. Oprogramowanie to narzę­dzie pra­cy, wyra­fi­no­wa­ne ale jed­nak tyl­ko narzę­dzie, któ­re jest deter­mi­ni­stycz­ne, czy­li 100% zacho­wań tego opro­gra­mo­wa­nia jest prze­wi­dy­wal­na i zosta­ła z góry okre­ślo­na. Te zacho­wa­nia to nic inne­go jak nasze wyma­ga­nia wobec tego narzę­dzia pra­cy. Skoro jest to narzę­dzie, to wyma­ga­nia są opi­sem tego narzę­dzia. I tu zaczy­na się zaba­wa”, bo jed­nak nie dzia­ła kla­sycz­ne” i ana­chro­nicz­ne już moim zda­niem, zesta­wie­nie wyma­ga­nia funk­cjo­nal­ne i poza-funk­cjo­nal­ne (to podział z lat 80-tych). Tu przy­po­mnę, że mło­tek może mieć kil­ka­na­ście cech, któ­re moż­na nazwać funk­cjo­nal­ny­mi i poza-funk­cjo­nal­ny­mi, co nie zmie­nia fak­tu, że gene­ral­nie słu­ży wyłącz­nie do ude­rza­nia w coś (świad­czy jed­ną usłu­gę), jest to przy­pa­dek uży­cia: ude­rzyć w coś. Stan począt­ko­wy: wie­my w co ude­rzyć i po co (z jaką siłą), stan koń­co­wy to efekt pożą­da­ny (np. wbi­ty gwóźdź). Panuje moda na nazy­wa­nie przy­pad­ka­mi uży­cia kon­tek­stu z per­spek­ty­wy akto­ra, było by więc: uderz w gwoźdź, uderz w ścia­nę, uderz w oso­bę, uderz w szy­bę, uderz w stół sła­bo, uderz w pły­tę chod­ni­ko­wą moc­no, i tak mozna w nie­skoń­czo­ność jak tyl­ko np. nie prze­rwie­my tak zwa­nych warsz­ta­tów zbie­ra­nia wyma­gań”. To, takie podej­ście, nie ma więk­sze­go sen­su, bo zamu­la deve­lo­pe­ra nad­mia­rem infor­ma­cji i nic nie mówi o kon­struk­cji młotka.

Bardziej wyra­fi­no­wa­na usłu­gą będzie zarzą­dza­nie dany­mi kon­tak­to­wy­mi. Mamy więc szaf­kę, szu­fla­dy, a w nich kar­to­te­ki z dany­mi kon­tak­to­wy­mi. Jest to narzę­dzie pra­cy, całość – szaf­ka i jej zawar­tość – to mar­twa natu­ra”, któ­rej użyt­kow­nik (aktor) uży­wa w sobie tyl­ko zna­nym kon­tek­ście. Może nim być zapa­mię­ty­wa­nie adre­sów dostaw­ców, odbior­ców, poten­cjal­nych klien­tów, itp. Z uwa­gi na to, że ma być postęp, opi­su­je­my tę szaf­kę razem z archi­wi­stą (opro­gra­mo­wa­nie zastą­pi część jego pra­cy), któ­ry zarzą­dza dostę­pem do niej. Czy kar­ta kata­lo­go­wa wie do cze­go jest uży­wa­na? Nie. Czy cel uży­cia cokol­wiek zmie­nia w kon­struk­cji tego mebla i jego zawar­to­ści? Nie. Więc co? Tu obiek­tem biz­ne­so­wym będzie nośnik danych kon­tak­to­wych, jed­nak to my decy­du­je­my co i po co zapi­su­je­my a nie szaf­ka, archi­wi­sta też nie wni­ka w treść. Owszem, wygod­nie będzie opra­co­wać jed­na­ko­wy sza­blon na te dane, nadal nie zmie­nia to fak­tu, że będzie­my zazna­cza­li np. w polu typ adre­su” jakimś sło­wem czy dany adres to dostaw­ca, odbior­ca, czy może zain­te­re­so­wa­ny poten­cjal­ny klient.

Co tu jest wyma­ga­niem? Zamawiając elek­tro­nicz­ną wer­sje kar­to­tek, powie­my co nie­co o łatwo­ści dostę­pu, o wyszu­ki­wa­niu, o kon­tro­li dostę­pu, i gdzieś na koń­cu przy­to­czy­my wzór kar­ty kata­lo­go­wej. Dodamy regu­ły biz­ne­so­we (zastą­pi­my archi­wi­stę), np. dane jed­nej oso­by powin­ny być tyl­ko na jed­nej kar­cie (brak duble­tów) a świa­dec­twem uni­kal­no­ści będzie zgod­ność imie­nia, nazwi­ska i kodu pocz­to­we­go (są też inne pomy­sły). Inną regu­łą może być zakaz nisz­cze­nia kart, żąda­nie nie­kon­tak­to­wa­nia się może być reali­zo­wa­ne dodat­ko­wym zapi­sem nie dzwo­nić”, nasze opro­gra­mo­wa­nie przej­mie na sie­bie pro­ce­du­ry reali­zo­wa­ne przez archiwistę.

Czy mamy tu jakąś per­spek­ty­wę danych sys­te­mu”? Gdybyś my mie­li doce­lo­wo stwo­rzyć opro­gra­mo­wa­nie w mode­lu dane + funk­cje = pro­gram” to tak, ale my mówi­my o obiek­to­wych meto­dach ana­li­zy i pro­jek­to­wa­nia, mówi­my o tym dekla­ru­jąc uży­cia nota­cji UML (jest obiek­to­wa). Każda więk­sza apli­ka­cja to wie­le takich osob­nych sza­fek na doku­men­ty, wie­le reguł biz­ne­so­wych powią­za­nych z doku­men­ta­mi, cały­mi szaf­ka­mi, oraz mecha­ni­zmy ope­ro­wa­nia tymi doku­men­ta­mi w kon­kret­nych celach. Czy ma tu jaki­kol­wiek sens wycią­ga­nie” tego, że adres kore­spon­den­cyj­ny pod­mio­tu powta­rza się w róż­nych kon­tek­stach na więk­szo­ści tych doku­men­tach? Czy ma sens wycią­ga­nie na wierzch” tego, że poło­wa doku­men­tów zawie­ra coś takie­go jak pro­dukt”. Nie ma to żad­ne­go sen­su, bo po pierw­sze te szaf­ki i kar­to­te­ki, każ­da żyje wła­snym życiem i nie zmie­ni­my tego, w każ­dej chwi­li może nam dojść nowa szaf­ka z nowy­mi papie­ra­mi, a sta­ra znik­nąć gdy sta­nie się nie­po­trzeb­na. Może nam się przy­tra­fić rezy­gna­cja z szaf­ki na rzecz korzy­sta­nia z usłu­gi biu­ra nume­rów na tele­fon. Takich sytu­acji nie tyl­ko nie jeste­śmy w sta­nie prze­wi­dzieć, może­my nie mieć moż­li­wo­ści prze­ciw­dzia­ła­nia temu (np. zmia­ny w prawie).

Obiektowe podej­ście uwa­la­nia nas od zaj­mo­wa­nia się osob­no wspól­ny­mi dany­mi”, powiem wręcz, podej­ście takie – usu­wa­nie redun­dan­cji i współ­dzie­le­nie – jest wręcz szko­dli­we, Perspektywa danych” to struk­tu­ral­ne a nie obiek­to­we podej­ście, nie ma w nim nic złe­go ale nie mie­szaj­my tego. Pisałem o tym:

Metody struk­tu­ral­ne to roz­kła­da­nie pro­ble­mu biz­ne­so­we­go na oddzie­lo­ne od sie­bie dane i pro­ce­du­ry ich prze­twa­rza­nia. Informacje o obiek­tach rze­czy­wi­stych są tra­co­ne w tych meto­dach. Model rela­cyj­ny danych to model, w któ­rym utra­co­no wie­le infor­ma­cji, np. nie da się z mode­lu rela­cyj­ne­go odtwo­rzyć np. fak­tu­ry nie wie­dząc jak ona wyglą­da. Do wydru­ku fak­tu­ry potrzeb­ne jest zapy­ta­nie, któ­re wycią­gnie z bazy danych wła­ści­we dane i pro­ce­du­ra któ­ra wła­ści­wie je sfor­ma­tu­je. Metody obiek­to­we pole­ga­ją na wier­nym mode­lo­wa­niu (odwzo­ro­wa­niu) świa­ta rze­czy­wi­ste­go (dome­ny sys­te­mu), w efek­cie nie tra­ci­my żad­nej wie­dzy mode­lu­jąc (zapi­su­jąc) ?świat? w posta­ci mode­lu dzie­dzi­ny. Źródło: Czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny sys­te­mu | Jarosław Żeliński IT-Consulting

Czy mamy więc jakieś per­spek­ty­wy w mode­lach obiek­to­wych? W zasa­dzie tyl­ko dwie:

- przy­pad­ki uży­cia (dia­gram przy­pad­ków uży­cia) i sko­ja­rzo­ne z każ­dym z nich sce­na­riu­sze, jako opi­sy tego jak sys­tem ma się zacho­wać w odpo­wie­dzi na pró­bę jego użycia,

- struk­tu­ra wewnętrz­na tego sys­te­mu (model dzie­dzi­ny sys­te­mu – dia­gram klas) , odwzo­ro­wu­ją­ca współ­pra­cu­ją­ce obiek­ty”, jest to opis mecha­ni­zmu dzia­ła­nia tego sys­te­mu (blo­ki funk­cjo­nal­ne, obiek­ty i komponenty).

Czy ma sens two­rze­nie zamó­wie­nia na szaf­ki do kar­to­tek wysy­ła­jąc tyl­ko zdję­cie stro­ny czo­ło­wej wraz z dzie­siąt­ka­mi stron opo­wie­ści o tym jak do tej pory ich uży­wa­no? Jest to bar­dzo ryzy­kow­ne podej­ście. Duże bez­piecz­niej jest zapro­jek­to­wać kon­struk­cję takiej szaf­ki, wska­zu­jąc gdzie jakie zam­ki i blo­ka­dy chce­my mieć i dać taki pro­jekt do wyko­na­nia. Owszem nie ma sen­su odbie­ra­nie chle­ba inży­nie­rom, pisa­nie z jakich mate­ria­łów to ma być zro­bio­ne i jaki­mi tech­ni­ka­mi wyko­na­ne i zabez­pie­czo­ne. Ale wewnętrz­ne, czy­sto biz­ne­so­we” szcze­gó­ły takie jak podział na szu­fla­dy, wzo­ry kar­to­tek, wymóg moż­li­wo­ści ich mody­fi­ka­cji, kon­tro­la dostęp do szu­flad, owszem: to war­to opi­sać same­mu (lub zatrud­nić projektanta).

Wiele ksią­żek zawie­ra opis tak zwa­ne­go wido­ku 4+1 Kruchtena. Co tam mamy? To jeden z wie­lu dostęp­nych w sie­ci opisów:

  • per­spek­ty­wa logi­ki biz­ne­su ? ist­nie­je w każ­dym sys­te­mie infor­ma­tycz­nym i uka­zu­je róż­ne ele­men­ty sys­te­mu infor­ma­tycz­ne­go w kon­tek­ście logi­ki biz­ne­su, takie jak kla­sy, pakie­ty itp.;

  • per­spek­ty­wa pro­ce­sów ? opi­su­je wszyst­ko co jest zwią­za­ne z współ­bież­no­ścią pra­cy SI, naj­czę­ściej opi­su­je komu­ni­ka­cję i syn­chro­ni­za­cję róż­nych kom­po­nen­tów sys­te­mu i z regu­ły doty­czy sys­te­mów roz­pro­szo­nych i/lub współbieżnych;

  • per­spek­ty­wa imple­men­ta­cji ? opi­su­je spo­sób imple­men­ta­cji ele­men­tów skła­do­wych sys­te­mu, z regu­ły jest to sta­tycz­ny opis skła­do­wych ele­men­tów sys­te­mu w jego fizycz­nym śro­do­wi­sku (dewe­lo­per­skim, a doce­lo­wo produkcyjnym);

  • per­spek­ty­wa wdro­że­nia ? opi­su­je spo­sób fizycz­ne­go kopio­wa­nia i wdra­ża­nia róż­nych ele­men­tów SI, spo­sób ich komu­ni­ko­wa­nia się w kon­tek­ście ich fizycz­ne­go roz­lo­ko­wa­nia na doce­lo­wej plat­for­mie informatycznej;

  • per­spek­ty­wa przy­pad­ków uży­cia ? opi­su­je naj­bar­dziej zna­czą­ce wyma­ga­nia SI dla użyt­kow­ni­ków koń­co­wych, czy­li te przy­pad­ki uży­cia lub ich czę­ści, któ­re wywie­ra­ją naj­więk­szy wpływ na archi­tek­tu­rę i są naj­bar­dziej kry­tycz­ne do zobra­zo­wa­nia mecha­ni­zmów dzia­ła­nia systemu.

(źr.
(źr. IIC Magazine2012/04/19/)

Wystarczy porów­nać to z moim opi­sem powy­żej, by zauwa­żyć, że powyż­sze to zbęd­ne kom­pli­ko­wa­nie cało­ści i nie­po­trzeb­ne wpla­ta­nie kon­tek­stu biz­ne­so­we­go (mło­tek nie wie w jakim celu jest używany).

Implementacja to pra­ca dla deve­lo­pe­ra a mie­sza­nie w to póź­niej­sze­go wdro­że­nia już zupeł­nie pomie­sza­nie celów spe­cy­fi­ko­wa­nia wymagań.

Przypadki uży­cia to zewnętrz­ne (widzia­ne przez jego użyt­kow­ni­ka) cechy sys­te­mu. Używanie sło­wa pro­ces” do tego co w UML nazy­wa się sekwen­cja” powo­du­je tyl­ko nie­po­ro­zu­mie­nia, tu każ­dy przy­pa­dek uży­cia jest reali­zo­wa­ny z uży­ciem wewnętrz­nych kom­po­nen­tów, jest to logi­ka biz­ne­so­wa (mecha­nizm dzia­ła­nia) czy­li i model dzie­dzi­ny. Nie przy­pad­kiem klu­czo­wą cecha obiek­to­we­go podej­ścia jest her­me­ty­za­cja czy­li ukry­wa­nie wnę­trza kom­po­nen­tów (do same­go koń­ca). Najpierw ana­li­zu­je­my i doku­men­tu­je­my do cze­go słu­ży fak­tu­ra, a na koń­cu (mają kom­plet­ny pro­jekt) upew­nia­my się (testu­je­my), że każ­dy kom­po­nent dys­po­nu­je wie­dzą potrzeb­ną mu do reali­za­cji przy­pad­ku uży­cia. Na samym koń­cu jest mowa o danych, i nie jako odręb­nej per­spek­ty­wie, a jako wewnętrz­nych cechach (atry­bu­tach) kom­po­nen­tów. Tu dopie­ro defi­niu­je­my ewen­tu­al­ne zawar­to­ści doku­men­tów repre­zen­to­wa­nych w mode­lu dzie­dzi­ny przez odręb­ne kom­po­nen­ty. I abso­lut­nie nie uwspól­nia­my (nie nor­ma­li­zu­je­my, nie pozby­wa­my się redun­dan­cji) na co zwró­ci­łem uwa­gę na początku.

Nie powin­ni­śmy zapo­mi­nać, że model Kruchtena to poło­wa lat 90-tych, szczyt roz­kwi­tu metod struk­tu­ral­nych i racz­ku­ją­ce meto­dy i narzę­dzia obiek­to­we. To sta­re sys­te­my i ich rela­cyj­ne bazy danych wymu­si­ły sto­so­wa­nie [[mapo­wa­nia ORM]] i takich narzę­dzi jak [[Hibernate]]. Dzisiaj mamy rok 2015, od tam­tej pory minę­ło 20 lat. Nie musi­my się cofać do począt­ków inży­nie­rii opro­gra­mo­wa­nia w wer­sji obiek­to­wej. Coś takie­go jak per­spek­ty­wa danych to ana­chro­nizm. Podejście to w 100% zosta­ły już daw­no zastą­pio­ne przez MDA. Ale o tym już tu pisałem 😉