Wprowadzenie

Adresatem tego wpi­su są moi poten­cjal­ni klien­ci oraz dostaw­cy opro­gra­mo­wa­nia ERP i dewe­lo­pe­rzy, któ­rzy są dostaw­ca­mi moich klien­tów, a cza­sa­mi bywa, że to oni zle­ca­ją mi pra­ce u swo­ich klien­tów. Typowe przy­pad­ki to:

1. opro­gra­mo­wa­nie ma powstać, a ja jestem pro­jek­tan­tem jego logi­ki (reali­za­cja wyma­gań funk­cjo­nal­nych), lub
2. opro­gra­mo­wa­nie już ist­nie­je i logi­kę tę nale­ży je udo­ku­men­to­wać (kod źró­dło­wy nie jest doku­men­ta­cją aplikacji).

Ten opis powstał w taki spo­sób, by moż­na było prze­rwać jego czy­ta­nie w dowol­nym momen­cie: od ogó­łu do szcze­gó­łu. Dlatego zachę­cam do lek­tu­ry oso­by zain­te­re­so­wa­ne moją rolą w pro­jek­tach, bez wzglę­du na to czy jeste­ście Państwo nabyw­cą opro­gra­mo­wa­nia (mój poten­cjal­ny klient) czy jego dostaw­cą (part­ne­rem moje­go klien­ta a być może klien­tem). Na koń­cu tek­stu udo­stęp­ni­łem przy­kła­do­we doku­men­ta­cje do pobra­nia bezpłatnie.

System ERP to nic inne­go jak zin­te­gro­wa­ny zestaw dobra­nych na ryn­ku stan­dar­do­wych apli­ka­cji, plus dedy­ko­wa­ne add-on’s w obsza­rach spe­cy­ficz­nych dla orga­ni­za­cji (ERP jako Integracja) .

Proces opracowania i wdrożenia systemu

Poniższy dia­gram obra­zu­je pro­ces ana­li­zy, pro­jek­to­wa­nia o wdro­że­nia rozwiązania:. 

Moje pro­jek­ty to wypra­co­wa­ne na świe­cie wzor­ce zobra­zo­wa­ne na powyż­szym diagramie:

Analiza, opra­co­wa­nie Architektury Korporacyjnej, wyma­ga­nia:
1. Powstaje model orga­ni­za­cji (pro­ce­sy biz­ne­so­we i struk­tu­ry doku­men­tów), ​‚
2. Określane są wyma­ga­nia biz­ne­so­we (potrze­by),
3. Projektowana jest nie­za­leż­na od plat­for­my logi­ka reali­za­cji wyma­gań (model sys­te­mu), .

teraz ma miej­sce wybór dewe­lo­pe­ra, któ­ry:

4. wybie­ra i sta­wia śro­do­wi­sko ​‚
5. reali­zu­je imple­men­ta­cję zapro­jek­to­wa­nej logi­ki w wybra­nym śro­do­wi­sku ​‚
6. prze­ka­zu­je użyt­kow­ni­kom sys­tem i wdra­ża go.

UWAGA!
Moje pro­jek­ty są archi­tek­tu­rą kom­po­nen­to­wą (mikro­ser­wi­sy), wdro­że­nie będzie spraw­nym , ite­ra­cyj­no-przy­ro­sto­wym pro­ce­sem (punk­ty 5. i 6. w pętli). Bywa, że śro­do­wi­sko jest już wyma­ga­niem poza funk­cjo­nal­nym (fir­ma już je posia­da, będzie to okre­ślo­na chmu­ra, itp.).

Czym jest Model Logiki Systemu

Jest tak­że nazy­wa­ny Opisem tech­nicz­nym Oprogramowania. Opis tech­nicz­ny opro­gra­mo­wa­nia (nie mylić z opi­sem powy­ko­naw­czym wdro­że­nia) to doku­men­ta­cja, pozwa­la­ją­ca oso­bie mają­cej odpo­wied­nią wie­dzę, samo­dziel­nie zro­zu­mieć jego dzia­ła­nie i wytwo­rzyć go. Poniżej opis mini­mal­ny i wystar­cza­ją­cy opis pro­duk­tu, tak­że apli­ka­cji (wyna­la­zek to pro­dukt zgła­sza­ny do patentowania):

Opis wyna­laz­ku powi­nien przed­sta­wiać (ujaw­niać) wyna­la­zek na tyle jasno i wyczer­pu­ją­co, aby znaw­ca Jest mógł ten wyna­la­zek urze­czy­wist­nić, a eks­pert mógł doko­nać rze­czo­wej ana­li­zy porów­naw­czej z dotych­cza­so­wym sta­nem tech­ni­ki. Za ​„znaw­cę z danej dzie­dzi­ny” uwa­ża się prze­cięt­ne­go prak­ty­ka dys­po­nu­ją­ce­go prze­cięt­ną, ogól­nie dostęp­ną wie­dzą z danej dzie­dzi­ny w odpo­wied­nim cza­sie, któ­ry dys­po­nu­je typo­wy­mi środ­ka­mi i moż­li­wo­ścia­mi pro­wa­dze­nia prac i doświad­czeń. Przyjmuje się, że spe­cja­li­sta taki ma dostęp do sta­nu tech­ni­ki; tzn. infor­ma­cji zawar­tych w pod­ręcz­ni­kach, mono­gra­fiach, książ­kach. Zna tak­że infor­ma­cje zawar­te w opi­sach paten­to­wych i publi­ka­cjach nauko­wych, jeże­li wyna­la­zek doty­czy roz­wią­zań, któ­re są na tyle nowe, że nie są zawar­te w książ­kach. Ponadto, potra­fi korzy­stać ze sta­nu tech­ni­ki w dzia­łal­no­ści zawo­do­wej do roz­wią­zy­wa­nia pro­ble­mów tech­nicz­nych. Przedstawiony wyna­la­zek powi­nien więc nada­wać się do odtwo­rze­nia bez dodat­ko­wej twór­czo­ści wyna­laz­czej. Pod poję­ciem tym nale­ży rozu­mieć dodat­ko­wą dzia­łal­ność umy­sło­wą, eks­pe­ry­men­tal­ną zwią­za­ną z nie­peł­ną infor­ma­cją tech­nicz­ną zawar­tą w opi­sie wyna­laz­ku, a tak­że koniecz­ność dodat­ko­wych uzu­peł­nia­ją­cych badań nauko­wych, nie­zbęd­nych do reali­za­cji roz­wią­za­nia według wyna­laz­ku w peł­nym zakre­sie żąda­nej ochro­ny. Odtworzenie wyna­laz­ku powin­no być moż­li­we na pod­sta­wie prze­cięt­nej wie­dzy spe­cja­li­sty w danej dzie­dzi­nie, bez nad­mier­ne­go wysił­ku. (art. 33 ust. 1 § 32 ust. 2 pkt. 63)

Innymi sło­wy: Opis ten powi­nien pozwa­lać urze­czy­wist­nić pro­dukt, a urze­czy­wist­nie­nie to nie powin­no wyma­gać: innej niż powszech­nie dostęp­na widza, dzia­łal­no­ści twór­czej. Przy czym pod­kre­śla się, że samo sto­so­wa­nie wie­dzy nie jest dzia­łal­no­ścią twórczą.

Sama apli­ka­cja, jej funk­cjo­nal­ność, wyma­ga opra­co­wa­nia (zapro­jek­to­wa­nia) a potem imple­men­ta­cji. Środowisko w jakim będzie funk­cjo­no­wa­ła to wyma­ga­na infrastruktura. 

Diagram po pra­wej to tak zwa­na archi­tek­tu­ra hek­sa­go­nal­na (hexa­go­nal archi­tec­tu­re) . Bardzo lubię ten model bo per­fek­cyj­nie poka­zu­je gra­ni­cę mię­dzy apli­ka­cją a jej śro­do­wi­skiem. Pokazuje zatem mój, pro­jek­tan­ta apli­ka­cji, zakres odpo­wie­dzial­no­ści w projekcie:

• ja, jako pro­jek­tant logi­ki roz­wią­za­nia, pro­jek­tu­ję to co jest wewnątrz czer­wo­nej gra­ni­cy (jest to tak zwa­ny Platform Independent Model),
• dewe­lo­per dostar­cza to co jest poza czer­wo­ną gra­ni­cą (śro­do­wi­sko wyko­naw­cze, fra­me­work, itp..),
• koder (naj­czę­ściej pra­cu­je dla dewe­lo­pe­ra) imple­men­tu­je to co zapro­jek­tu­ję ja jako projektant.

Projekt to Opis tech­nicz­ny, i jako opis mecha­ni­zmu dzia­ła­nia apli­ka­cji zawiera:

1. mode­le struk­tur doku­men­tów i komunikatów, 
2. meto­dy wyli­cza­nia lub wery­fi­ko­wa­nia war­to­ści wszyst­kich pół wyli­cza­nych w tych dokumentach,
3. model archi­tek­tu­ry kodu (kom­po­nen­ty, modu­ły, inte­gra­cje, itp.), 
4. oraz opi­su­je mecha­ni­zmy współ­dzia­ła­nia kom­po­nen­tów wyja­śnia­ją­ce inte­gra­cję, wpro­wa­dza­nie danych i powsta­wa­nie nowych treści.

Po pra­wej stro­nie u góry poka­za­no archi­tek­tu­rę kom­plet­ne­go sys­te­mu: apli­ka­cja, i zawar­ta w niej logi­ka dzie­dzi­no­we, to imple­men­ta­cja mecha­ni­zmu jej dzia­ła­nia. Cała resz­ta to infra­struk­tu­ra tech­nicz­na w jakiej ona funk­cjo­nu­je. pro­jek­to­wa­nie opro­gra­mo­wa­nia to opra­co­wa­nie mode­lu opi­su­ją­ce­go mecha­nizm dzia­ła­nia apli­ka­cji. Rolą dewe­lo­pe­ra jest dobór i uru­cho­mie­nie śro­do­wi­ska oraz imple­men­ta­cja ww. mecha­ni­zmu w wybra­nym języ­ku pro­gra­mo­wa­nia. Więcej w opi­sie Projektowanie apli­ka­cji.

Warto tu pod­kre­ślić, że sama ​„idea sys­te­mu” wyra­żo­na jako opis jego zewnętrz­nych cech i spo­so­bów uży­cia, nie sta­no­wi opi­su tech­nicz­ne­go i nie pod­le­ga żad­nej ochro­nie. Innymi sło­wy same makie­ty ekra­nów i user sto­ry nie sta­no­wią żad­nej doku­men­ta­cji moż­li­wej do ochro­ny. Mogą być chro­nio­ne jako utwo­ry w świe­tle pra­wa autor­skie­go, ale z zasa­dy nie sta­no­wią opi­su mecha­ni­zmu dzia­ła­nia, know-how ani nie sta­no­wią tajem­ni­cy przed­się­bior­stwa (pole­cam tu cały wpis: Ochrona Wartości Intelektualnych).

Bez wzglę­du na dzie­dzi­nę inży­nie­rii , powyż­sze wymo­gi są iden­tycz­ne. Komputer (opro­gra­mo­wa­nie) jest zawsze czę­ścią nad­rzęd­nej kon­struk­cji (sys­te­mu, raz jest to macie­rzy­ste urzą­dze­nie a raz orga­ni­za­cja). Powoduje to, że opro­gra­mo­wa­nie kom­pu­te­ra, któ­ry wraz z tym opro­gra­mo­wa­niem z zasa­dy reali­zu­je jakiś mecha­nizm , musi zostać udo­ku­men­to­wa­ne na rów­ni z inny­mi ele­men­ta­mi sys­te­mu, któ­re­go jest częścią.

Dokumentowanie istniejącego oprogramowania

Jeżeli celem jest opra­co­wa­nie doku­men­ta­cji opro­gra­mo­wa­nia, któ­re powsta­ło ale nie ma ono pro­fe­sjo­nal­nej doku­men­ta­cji technicznej:

1. dosta­je aktu­al­ne doku­men­ty (jakie­kol­wiek jaki­mi dys­po­nu­je zle­ce­nio­daw­ca) i na bazie ich audy­tu powsta­je doku­men­ta­cja tech­nicz­na w takiej posta­ci w jakiej jest moż­li­wa do stwo­rze­nia na bazie dostar­czo­ne­go mate­ria­łu źró­dło­we­go, na tym eta­pie jako efekt, powsta­je tak­że opis tego jakie dal­sze pra­ce są koniecz­ne by pro­jekt Techniczny uzy­skał doce­lo­wą postać (koszt: staw­ka za ana­li­zą doku­men­ta­cji),
2. kon­ty­nu­acja jako reali­za­cja prac okre­ślo­nych w poprzed­nim punk­cie (har­mo­no­gram i z góry usta­lo­na kwo­ta, roz­li­cze­nia mie­sięcz­ne ryczał­tem), 
3. prze­ka­za­nie praw mająt­ko­wych do opra­co­wa­nej doku­men­ta­cji ma miej­sce zawsze, zależ­nie od usta­le­nia: po pierw­szym lub po dru­gim etapie.

Analiza Biznesowa jako modelowanie CIM, Projektowanie jako specyfikowanie wymagań PIM (MBSE)

Systemy zarzą­dza­ją­ce infor­ma­cją zor­ga­ni­zo­wa­ne są wokół doku­men­tów i dzie­dzi­no­wych (kon­tek­sto­wych) reguł ich prze­twa­rza­nia. Dlatego naj­bar­dziej ade­kwat­na meto­dą ich pro­jek­to­wa­nia są wzor­ce opar­te na onto­lo­giach, dzie­dzi­no­wych kom­po­nen­tach, doku­men­tach i ich prze­ka­zy­wa­niu mię­dzy komponentami.

Zakres 1 to nie raz samo­dziel­ny pro­jekt biz­ne­so­wy, któ­re­go celem jest poten­cjal­na opty­ma­li­za­cja pro­ce­sów. Jeżeli jed­ną z reko­men­da­cji jest wdro­że­nie opro­gra­mo­wa­nia, reali­zo­wa­ny jest Zakres 2. Jeżeli oka­że sie, że na ryn­ku nie ma wyma­ga­ne­go opro­gra­mo­wa­nia, reali­zo­wa­ny jest Zakres 3. Realizacja wyglą­da jak poniżej:

Jeżeli moim zle­ce­nio­daw­cą jest dewe­lo­per, każ­do­ra­zo­wo usta­lam indy­wi­du­al­nie wyma­ga­nia wobec doku­men­ta­cji jaka ma powstać. 

Typowy podział na role w projekcie

Podział pra­cy w pro­jek­tach inży­nier­skich naj­czę­ściej ma cha­rak­ter wyni­ka­ją­cy nie tyle z roli co z dzie­dzi­ny wie­dzy. W pro­jek­tach IT mamy dwie dzie­dzi­ny: wie­dza o infor­ma­cji (infor­ma­tion scien­ce, infor­ma­tion sys­tems) i wie­dza o tech­no­lo­gii infor­ma­tycz­nej (infor­ma­tion tech­no­lo­gy) (patrz take cie­ka­wy opis: Information Technology vs. Information Systems). Jest to o tyle istot­ne, że wybór meto­dy imple­men­ta­cji roz­wią­za­nia i tech­no­lo­gii, powi­nien nastą­pić dopie­ro po opra­co­wa­niu same­go roz­wią­za­nia (logi­ki tego jakie dane i jak prze­twa­rza­my), robi to deweloper.

Najczęściej jestem anga­żo­wa­ny do pro­jek­tów, w któ­rych usta­lo­no role: 

1. Zamawiający: jako Organizacja Analizowana zgła­sza cele biz­ne­so­we i pro­ble­my, udo­stęp­nia wie­dzę na swój temat, jest sta­łym recen­zen­tem pro­duk­tów ana­li­zy i pro­jek­to­wa­nia (zama­wia­ją­cy to eks­pert dzie­dzi­no­wy) w toku pro­jek­tu. To kadry kie­row­ni­cze Zamawiającego, wspie­ra­ne przez Asystenta-koor­dy­na­to­ra, dostar­cza­ją mate­ria­ły źró­dło­we opi­su­ją­ce opis ich dzia­ła­nia i potrzeby. 

2. Asystent-koor­dy­na­tor: oso­ba zaan­ga­żo­wa­na bez­po­śred­nio z zbie­ra­nie mate­ria­łów źró­dło­wych (wywia­dy, kolek­cjo­no­wa­nie doku­men­tów, itp.), z regu­ły jest to oso­ba anga­żo­wa­na (zatrud­nia­na, wyzna­cza­na) przez Zamawiającego.

3. Analityk: jako archi­tekt-pro­jek­tant (inży­nier sys­te­mów, obszar Information Systems), pro­wa­dzi ana­li­zę otrzy­ma­nych mate­ria­łów, opra­co­wu­je model biz­ne­so­wy orga­ni­za­cji (pro­ce­sy biz­ne­so­we, prze­pływ i logi­ka prze­twa­rza­nia infor­ma­cji), a potem opra­co­wu­je model dzie­dzi­no­wy roz­wią­za­nia jako archi­tek­tu­rę i logi­kę dzia­ła­nia sys­te­mu (patrz jak powsta­je Opis Techniczny Oprogramowania), jest ona wyma­ga­niem dla dostawcy. 

4. Deweloper (Programmer, obszar Information Technology): jako wyko­naw­ca imple­men­ta­cji roz­wią­za­nia, wybie­ra tech­no­lo­gię, narzę­dzia i śro­do­wi­sko apli­ka­cji, pro­jek­tu­je i wyko­nu­je imple­men­ta­cję, dostar­cza i wdra­ża oprogramowanie.

(źr.: https://​buil​tin​.com/​r​e​c​r​u​i​t​i​n​g​/​s​o​f​t​w​a​r​e​-​e​n​g​i​n​e​e​r​-​v​s​-​p​r​o​g​r​a​m​mer)

Poniżej zobra­zo­wa­no to jako pro­ces wytwarzania/dostarczania opro­gra­mo­wa­nia (w moim przy­pad­ku zorien­to­wa­ne­go na mode­le: MBSE). W przy­pad­ku wdra­ża­nia sys­te­mów stan­dar­do­wych, rolę dewe­lo­pe­ra peł­ni fir­ma wdra­ża­ją­ca dostar­czo­ne goto­we opro­gra­mo­wa­nie, któ­rej kon­sul­ta­cji kon­fi­gu­ru­ją dostar­czo­ny sys­tem, jed­nak w przy­pad­ku gdy wyma­ga­ne są funk­cjo­nal­no­ści dedy­ko­wa­ne, powsta­ją one jako dedy­ko­wa­ne kom­po­nen­ty (add-ons).:

Projekt roz­wią­za­nia to począt­ko­wo model przy­pad­ków uży­cia (UML) i ich spe­cy­fi­ka­cje (makie­ty, sce­na­riu­sze i logi­ka danych) oraz archi­tek­tu­ra inte­gra­cji HLD (kom­po­nen­ty, doku­men­to­wy model danych, sekwen­cje) . Na jego pod­sta­wie Dostawcy skła­da­ją oferty. 

Po wybo­rze Dostawcy pro­jekt jest reali­zo­wa­ny ite­ra­cyj­nie: kolej­ne przy­pad­ki uży­cia (usłu­gi apli­ka­cji) są wdra­ża­ne, a jeże­li wyma­ga­ne jest dedy­ko­wa­ne opro­gra­mo­wa­nie, przy­pad­ki uży­cia są dopre­cy­zo­wy­wa­ne (archi­tek­tu­ra LLD) i imple­men­to­wa­ne. Zgodnie z zale­ce­nia­mi pro­du­cen­tów sys­te­mów stan­dar­do­wych, nie dopusz­czam kasto­mi­za­cji stan­dar­do­we­go opro­gra­mo­wa­nia, bra­ku­ją­ce funk­cjo­nal­no­ści są dostar­cza­ne jako opro­gra­mo­wa­nie dedy­ko­wa­ne (patrz Kastomizacja…).

Struktura i treść moich opracowań

Więcej na temat same­go pro­ce­su powsta­wa­nia tych pro­duk­tów w: Analiza Potrzeb i Opracowanie Wymagań na Oprogramowanie, wię­cej o sto­so­wa­nych meto­dach i stan­dar­dach: Metoda ana­li­zy i pro­jek­to­wa­nia sys­te­mów biz­ne­so­wych. Słownik sto­so­wa­nych metod i narzę­dzi jest dostęp­ny na stro­nie: Słownik meto­dycz­ny.

Model Biznesowy

Jest to pro­dukt Analizy Biznesowej, Mapa pro­ce­sów i ich mode­le to część opi­su­ją­ca mecha­ni­zmy rzą­dzą­ce pra­cą ana­li­zo­wa­nej i opi­sa­nej orga­ni­za­cji. Celem tego eta­pu pra­cy jest zro­zu­mie­nie tego jak okre­ślo­na orga­ni­za­cja dzia­ła i współ­dzia­ła z oto­cze­niem oraz prze­ka­za­nie tej wie­dzy dostaw­cy dostaw­cy roz­wią­za­nia w celu lep­sze­go zro­zu­mie­nia przez nie­go kon­tek­stu i śro­do­wi­ska w jakim roz­wią­za­nie będzie wdra­ża­ne. Model biz­ne­so­wy zawie­ra sche­ma­ty blo­ko­we wyko­na­ne z uży­ciem nota­cji BMM (Business Model Motivation) , BPMN (Procesy biz­ne­so­we), UML (struk­tu­ry danych doku­men­tów biz­ne­so­wych) oraz SBVR (słow­nik pojęć i regu­ły biz­ne­so­we). Na tym eta­pie są reali­zo­wa­ne ewen­tu­al­ne zmia­ny w pro­ce­sach to-be i okre­śla­ny zakres projektu.

Projekt Rozwiązania

Ten etap to okre­śle­nie wyma­gań na opro­gra­mo­wa­nie. Najpierw powsta­ją: Diagram przy­pad­ków uży­cia (lista usług apli­ka­cji) i model HLD (pod­sys­te­my, inte­gra­cje). Jeżeli zawie­dzie poszu­ki­wa­nie na ryn­ku zgod­ne­go z tymi wyma­ga­nia­mi goto­we­go opro­gra­mo­wa­nia (np. ERP), usłu­gi apli­ka­cji wyma­ga­ją­ce wytwo­rze­nia, spe­cy­fi­ko­wa­ne są jako pro­jekt logi­ki sys­te­mu do imple­men­ta­cji (jako odręb­ne mikroserwisy). 

Z zasa­dy ope­ru­ję przy­pad­ka­mi uży­cia, ich sce­na­riu­sza­mi oraz mode­lem dzie­dzi­ny budo­wa­nym jako archi­tek­tu­ra sepa­ro­wa­nych od sie­bie usług apli­ka­cyj­nych (imple­men­to­wa­ne jako mikro­ser­wi­sy, kom­po­nen­ty) . Struktury infor­ma­cji są spe­cy­fi­ko­wa­ne jako doku­men­ty (potem XML/JSON), co opi­sa­łem w tek­ście Projekt apli­ka­cji….

Ogólnie moje pro­jek­ty są opar­te na wzor­cach pro­jek­to­wych, szcze­gól­nie są to ICONIX, DDD, micro ser­wi­sy i doku­men­to­we struk­tu­ry danych. Architektura mikro­ser­wi­sów opar­ta jest na poniż­szym schemacie:

To co obec­nie nazy­wa­my zwin­nym two­rze­niem opro­gra­mo­wa­nia (agi­le) to ​„raczej” szyb­ka ana­li­za cało­ści pro­ble­mu (ana­li­za biz­ne­so­wa), pro­jekt logi­ki biz­ne­so­wej roz­wią­za­nia, czy­li podział całe­go sys­te­mu na kom­po­nen­ty biz­ne­so­we (archi­tek­tu­ra HLD) oraz ite­ra­cyj­ne ich uszcze­gó­ła­wia­nie (archi­tek­tu­ra LLD każ­de­go kom­po­nen­tu) i kolej­ne, ite­ra­cyj­ne ich imple­men­to­wa­nie. Praktyka poka­zu­je, koszt prac ana­li­ty­ka pro­jek­tan­ta (tu inży­nier sys­te­mo­wy), zależ­nie od stop­nia zło­żo­no­ści pro­jek­tu, to ok. 10 – 20 % całe­go budże­tu na wyko­na­nie opro­gra­mo­wa­nia (kosz­ty śro­do­wi­ska: licen­cje, sprzęt itp. do dodat­ko­we kosz­ty), czy­li deve­lo­per to jed­nak zna­ko­mi­ta więk­szość pra­co­chłon­no­ści i budżetu.

Dodatek techniczny

Dlaczego moje projekty są zorientowane na dokumenty/komunikaty

Ważna uwa­ga! Dotyczy zarów­no apli­ka­cji two­rzo­nych od zera jak i apli­ka­cji już ist­nie­ją­cych i roz­wi­ja­nych. Ten opis doty­czy obu rodza­jów apli­ka­cji, w przy­pad­ku apli­ka­cji już ist­nie­ją­cych, doku­men­ty w mode­lu logicz­nym mogą być utrwa­la­ne w bazie i mode­lu rela­cyj­nym z pomo­cą dodat­ko­wej war­stwy ORM (mapo­wa­nie obiek­to­wo-rela­cyj­ne), ma to jed­nak opi­sa­ne niżej kon­se­kwen­cje. Najczęściej sto­so­wa­ne prze­ze mnie wzor­ce pro­jek­to­we to Repozytorium/Envelope, Active Record lub Active Table oraz DDD/Aggregate . Co do zasa­dy na eta­pie ana­li­zy i pro­jek­to­wa­nia nie two­rzę i nie uży­wam mode­li danych rozu­mia­nych jako ​„jed­na rela­cyj­na baza danych dla projektu”. 

Innymi sło­wy logi­ka dzie­dzi­no­wa to doku­men­ty i komu­ni­ka­ty, te mogą być utrwa­la­ne. Jak widać po pra­wej, meto­dy utrwa­la­nia są poza zakre­sem mode­lu dzie­dzi­ny, czy­li poza mode­le opi­su­ją­cym mecha­nizm dzia­ła­nia aplikacji. 

Krótkie wyjaśnienie

Pojęcie ​„zbiór danych” więk­szo­ści nadal koja­rzy się z rela­cyj­nym mode­lem danych. Jednak my jako ludzie gro­ma­dzi­my infor­ma­cje w posta­ci redun­dant­nych doku­men­tów, ich struk­tu­ry odpo­wia­da­ją naszym potrze­bom a doku­men­ty są z zasa­dy nie­za­leż­ny­mi od sie­bie byta­mi (to nie raz zawie­ra­ją powią­za­ne logicz­nie tre­ści nicze­go tu nie zmie­nia). Dokument to przede wszyst­kim kon­tekst dla danych na nim zgro­ma­dzo­nych. Dlatego tak zwa­ne Systemy Biznesowe czę­sto nazy­wa­ne są sys­te­ma­mi for­mu­la­rzo­wy­mi: z zasa­dy ope­ru­ją na doku­men­tach (for­mu­la­rzach), inte­gra­cja sys­te­mów – wewnątrz orga­ni­za­cji jak i mię­dzy orga­ni­za­cja­mi – to wymia­na nazwa­nych zesta­wów danych: doku­men­tów .

Relacyjny model danych jest nie­ela­stycz­ny. Cechuje się pre­cy­zyj­nie zde­fi­nio­wa­ną struk­tu­rą danych, któ­ra jed­nak bar­dzo ją ogra­ni­cza. Musimy zde­fi­nio­wać sta­łą struk­tu­rę jak kolum­ny i wier­sze tabel oraz okre­ślić ich rela­cje, co jest póź­niej trud­ne do zmia­ny. Ponadto, jeśli dzie­dzi­na poję­cio­wa jest głę­bo­ko zagnież­dżo­na, uży­cie mode­lu rela­cyj­ne­go dla niej będzie wyma­ga­ło wie­lu tabel i złą­czeń. Relacyjne bazy danych mają sła­bą ska­lo­wal­ność pozio­mą. Mogą być ska­lo­wa­ne w pio­nie poprzez doda­nie więk­szej ilo­ści zaso­bów, takich jak pro­ce­sor i pamięć RAM. Ale nie mogą być ska­lo­wa­ne pozio­mo, tzn. łączyć wie­lu maszyn i two­rzyć kla­strów. Wynika to z wyma­gań doty­czą­cych spój­no­ści. Baza danych zorien­to­wa­na na doku­men­ty roz­wią­zu­je nie­któ­re z tych pro­ble­mów, z któ­ry­mi bory­ka się baza danych w mode­lu relacyjnym.

Główną wadą rela­cyj­ne­go mode­lu danych w sys­te­mach biz­ne­so­wych jest zapi­sy­wa­nie danych w posta­ci współ­dzie­lo­nych znor­ma­li­zo­wa­nych struk­tur poję­cio­wych, pozba­wio­nych redun­dan­cji, co powo­du­je, że dane są pozba­wio­ne kon­tek­stu , a w kon­se­kwen­cji model ten nie spraw­dza się w sys­te­mach zarzą­dza­ją­cych doku­men­ta­mi i ich tre­ścią. Dokumenty biz­ne­so­we (dowo­dy księ­go­we ale tak­że umo­wy, ofer­ty i wie­le innych) to zło­żo­ne agre­ga­ty danych więc zapy­ta­nia SQL do tabel rela­cyj­nych (do ich zapi­su i odczy­tu) to bar­dzo zło­żo­ne struk­tu­ry kodu, powo­du­ją­ce, że tak zor­ga­ni­zo­wa­ne bazy szyb­ko sta­ją się nie­wy­daj­ne (zaso­by takie jak pro­ce­sor i RAM są ogra­ni­czo­ne a ska­lo­wa­nie pozio­mie tu jest nie­moż­li­we). Dodatkowo doku­ment, w sen­sie fizycz­nym nie może być gene­ro­wa­ną dyna­micz­nie struk­tu­rą (zapy­ta­nia SQL do bazy rela­cyj­nej), bo jest wte­dy tyl­ko wir­tu­al­nym chwi­lo­wym bytem, nie sta­no­wi tak­że doku­men­tu w sen­sie praw­nym (Kodeks Cywilny), nie da się też zarzą­dzać jego cyklem życia. 

W dzi­siej­szej erze big data moż­na zaob­ser­wo­wać ogrom­ną ewo­lu­cję w typach baz danych i ich wyko­rzy­sta­niu. Rozwiązania takie jak np. MySQL czy Oracle, nie są w sta­nie spro­stać współ­cze­snym wyma­ga­niom zwią­za­nym z obsłu­gą dużej róż­no­rod­no­ści, szyb­ko­ści, praw­dzi­wo­ści i, co waż­ne, obszer­nych zbio­rów danych. Bazy danych NoSQL są szyb­ki­mi roz­wią­za­nia­mi i dosko­na­le radzą sobie z tymi wyma­ga­nia­mi dzię­ki dodat­ko­wym cechom, takim jak ska­lo­wa­nie pozio­me, wyso­ka wydaj­ność, zgod­ność z ela­stycz­no­ścią i wszechstronność.

Dokument jako agregat

Najpierw czym jest agre­gat: gene­ral­nie jest to drze­wia­sta struk­tu­ra, nio­są­ca kon­tek­sto­we dane, mają­ca toż­sa­mość .

Dokumenty w sys­te­mach infor­ma­tycz­nych są coraz czę­ściej wyra­ża­ne jako struk­tu­ry XML/XSD/DTD (lub JSON) w bazach doku­men­to­wych (NpSQL) i prze­cho­wy­wa­ne w posta­ci agre­ga­tów .

Dane gru­po­wa­ne w doku­men­ty i prze­twa­rza­ne jako całe struk­tu­ry infor­ma­cyj­ne, a nie jako poje­dyn­cze pola danych, są coraz czę­ściej sto­so­wa­ną meto­dą budo­wa­nia archi­tek­tu­ry opro­gra­mo­wa­nia . Podejście takie daje znacz­nie więk­szą swo­bo­dę pro­jek­to­wa­nia, zaś struk­tu­ry takie jaki XML czy JSON, moż­na prze­twa­rzać i prze­sy­łać mię­dzy apli­ka­cja­mi ze znacz­nie więk­szą swo­bo­dą .

W moich pro­jek­tach dane są mode­lo­wa­ne jako hie­rar­chicz­ne agre­ga­ty (patrz wzor­ce obiek­to­we) prze­cho­wy­wa­ne w nie­za­leż­nych pła­skich (nie powią­za­nych rela­cyj­nie) tabe­lach: kolum­ny takiej tabe­li repre­zen­tu­ją meta­da­ne, cały doku­ment jako XML/JSON jest zawar­to­ścią jed­ne­go z pól. Każdy doku­ment ma okre­ślo­ną struk­tu­rę oraz zde­fi­nio­wa­ne regu­ły okre­śla­ją­ce jego popraw­ność (słow­nik i regu­ły biz­ne­so­we , . Struktura ta może być przej­rzy­ście wyra­żo­na w posta­ci dia­gra­mu UML .

Mechanizm utrwa­la­nia stan­dar­do­wo mode­lu­ję z uży­ciem wzor­ca repo­zy­to­rium. Obiekt «enti­ty» (wiersz ww. tabe­li z doku­men­ta­mi) odpo­wie­dzial­ny jest za prze­cho­wa­nie doku­men­tu (patrz wzo­rzec «enve­lo­pe» ): ma atry­bu­ty zawie­ra­ją­ce klu­czo­we meta­da­ne do reali­zo­wa­nia logi­ki biz­ne­so­wej oraz ope­ra­cje CRUD dla tego doku­men­tu . Od pozo­sta­łej czę­ści apli­ka­cji oddzie­la go kom­po­nent reali­zu­ją­cy logi­kę dostę­pu do danych. 

Logika dzie­dzi­no­wa (tak­że wali­da­cja doku­men­tów) może być wspól­na dla wie­lu doku­men­tów w okre­ślo­nym dzie­dzi­no­wym kon­tek­ście . Dokument jest tu agre­ga­tem, któ­ry moż­na wyra­zić jako drze­wia­sta struk­tu­rę klas i mapo­wać na rela­cyj­na bazę danych:

A moż­na agre­gat uczy­nić (zaim­ple­men­to­wać) jako sta­tycz­ną struk­tu­rę np. XML i prze­cho­wy­wać go w bazie doku­men­to­wej (NoSQL):

Jednym z klu­czo­wych powo­dów powszech­ne­go sto­so­wa­nia XML jest tak­że stan­da­ry­za­cja doku­men­tów, głów­nie finan­so­wych i urzę­do­wych w ramach Unii Europejskiej oraz stan­da­ry­za­cja, tak­że w Unii, metod zarzą­dza­nia nimi (archi­wa) .

Z racji tego, że poję­cie doku­men­tu ma tak­że cha­rak­ter praw­ny, wyda­je się oczy­wi­stym, że zacho­wa­nie inte­ro­pe­ra­cyj­no­ści wyma­ga takiej stan­da­ry­za­cji. Jest to – stan­da­ry­za­cja – pro­ces postę­pu­ją­cy w ramach Unii Europejskiej i wewnątrz państw wspól­no­ty, dla­te­go z zasa­dy w moich pro­jek­tach wyma­ga­niem jest sto­so­wa­nie XML jako meto­dy zapi­su infor­ma­cji. To czy fizycz­nie będzie to motor bazy NoSQL czy pła­skie tabli­ce w moto­rach SQL nie ma więk­sze­go zna­cze­nia, bo istot­ny jest tu nie­re­la­cyj­ny model danych .

Jako ana­li­tyk biz­ne­so­wy i jed­no­cze­nie archi­tekt roz­wią­za­nia, jestem pro­jek­tan­tem. Na pod­sta­wie otrzy­ma­nych mate­ria­łów pro­jek­tu­ję roz­wią­za­nie i odsy­łam jego opis (opi­sa­ne sche­ma­ty blo­ko­we pre­zen­tu­ją­ce pro­ce­sy biz­ne­so­we, archi­tek­tu­rę inte­gra­cji, struk­tu­ry doku­men­tów i logi­kę ich popraw­no­ści, itp. (co do zasa­dy sto­su­ję stan­dar­dy: nota­cje BPMN, UML, SBVR, itp.). Jak i dla­cze­go dla­cze­go? Polecam poniż­szy refe­rat, któ­ry mam nadzie­ję wie­le wyjaśni:

Przykłady specyfikacji wymagań

Prezentowanie przy­kła­do­wych spe­cy­fi­ka­cji jest moż­li­we wyłącz­nie wte­dy, gdy nie są one obję­te tajem­ni­cą przed­się­bior­stwa, mogę więc poka­zać tyl­ko wybra­ne opra­co­wa­nia. Sa to wyłącz­nie opu­bli­ko­wa­ne wcze­śniej doku­men­ty w prze­tar­gach publicz­nych lub opi­sy ​„demo” (tu jako arty­kuł: Projekt apli­ka­cji ? przy­kład). Poniższe opra­co­wa­nia to doku­men­ta­cja dedy­ko­wa­nych sys­te­mów, jed­nak nie każ­dy sys­tem musi być dedykowany. 

Projekty dla admi­ni­stra­cji były reali­zo­wa­ne z moim wspar­ciem (nad­zór autor­ski), zosta­ły wyko­na­ne w ter­mi­nie i w budże­cie, zama­wia­ją­cy dostał autor­skie pra­wa mająt­ko­we do pro­jek­tu, apli­ka­cje te nadal są w uży­ciu i są roz­wi­ja­ne przez ich właścicieli. 

Większość pro­jek­tów nasta­wio­na jest na zakup i wdro­że­nie opro­gra­mo­wa­nia goto­we­go, dla­te­go przy­go­to­wa­nie np. do wdro­że­nia sys­te­mu ERP to zawsze Analiza Biznesowa oraz ​„archi­tek­tu­ra wyso­kie­go pozio­mu” (HLD) inte­gra­cji sys­te­mu. Jedynie tam, gdzie wyma­ga­ne są dedy­ko­wa­ne funk­cjo­nal­no­ści two­rzo­na jest archi­tek­tu­ra LLD (ww. spe­cy­fi­ka­cja techniczna). 

Komentarze do pro­jek­tu Generator Ofert na stro­nie: Generator Ofert ? Komentarze

Przykład pro­ce­su pro­wa­dze­nia ana­li­zy i wyko­na­nia opi­su doku­men­ta­cji, wraz z fil­mem jak powsta­wał, znaj­dziesz na stro­nie: https://​it​-con​sul​ting​.pl/​2​0​2​0​/​1​2​/​1​1​/​a​n​a​l​i​z​a​-​b​i​z​n​e​s​o​w​a​-​o​d​-​z​l​e​c​e​n​i​a​-​d​o​-​k​o​m​p​l​e​t​n​e​g​o​-​p​r​o​j​e​k​t​u​-​t​e​c​h​n​i​c​z​n​e​g​o​-​z​-​u​z​y​c​i​e​m​-​n​a​r​z​e​d​z​i​a​-​c​a​se/.

W razie jakich­kol­wiek pytań lub suge­stii co do tego, cze­go wg. Was deve­lo­pe­rów bra­ku­je w tych przy­kła­dach zapra­szam do komen­ta­rzy pod tym tek­stem lub pro­szę o kon­takt.

Stale poszu­ku­ję deve­lo­pe­rów dla moich klien­tów: zare­je­struj się jako deve­lo­per na new­slet­ter.

Źródła: