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, gdyż Opis Techniczny Oprogramowania to model PIM jako:

  • wyma­ga­nie klien­ta w sto­sun­ku do pro­duk­tu zama­wia­ne­go u dewe­lo­pe­ra lub dostaw­cy oprogramowania,
  • udo­ku­men­to­wa­na infor­ma­cja opi­su­ją­ca archi­tek­tu­rę i mecha­nizm dzia­ła­nia opro­gra­mo­wa­nia (sys­te­mu).

Opis Techniczny Oprogramowania jest czę­sto opi­sem Przedmiotu Zamówienia w rozu­mie­niu opi­su tego co ma powstać”:

  1. powstać ma doku­ment będą­cy opi­sem Przedmiotu Zamówienia (to moja rola),
  2. ma powstać rzecz i/lub ma zostać wyświad­czo­na usłu­ga, opi­sa­na w ww. doku­men­cie jako Przedmiot Zamówienia.

Standardowo w pro­jek­tach jestem anga­żo­wa­ny gdy: 

  1. opro­gra­mo­wa­nie ma powstać, a ja jestem jego pro­jek­tan­tem, lub 
  2. opro­gra­mo­wa­nie już ist­nie­je i nale­ży je udokumentować.

Czym jest opis techniczny

Bardzo popu­lar­ny mem wśród kode­rów (autor nie znany)

jest takie sta­re powie­dze­nie: ludzie dzie­lą na tych któ­rzy mają bac­kup i na tych któ­rzy będą mie­li bac­kup”, iden­tycz­nie jest z doku­men­ta­cją tech­nicz­ną 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: 

Opis pro­duk­tu powi­nien przed­sta­wiać (ujaw­niać) go na tyle jasno i wyczer­pu­ją­co, aby znaw­ca mógł go urze­czy­wist­nić. 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. 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 jest to roz­wią­za­nie, któ­re jest na tyle nowe, że sto­sow­ne opi­sy 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. Produkt powi­nien nada­wać się do odtwo­rze­nia (na pod­sta­wie doku­men­ta­cji) 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 pro­duk­tu, a tak­że koniecz­ność dodat­ko­wych uzu­peł­nia­ją­cych badań nauko­wych, nie­zbęd­nych do wytwo­rze­nia pro­duk­tu według tego opisu.

na pod­sta­wie

Powyższe ozna­cza (wytłusz­cze­nia moje), że wyko­na­nie opro­gra­mo­wa­nia (imple­men­ta­cja) na pod­sta­wie jego pro­jek­tu nie powin­no mieć (wyma­gać) cha­rak­te­ru twór­cze­go. To ozna­cza tak­że, że pro­jekt ten powi­nien na to pozwo­lić. Wykonawca (sto­larz, mecha­nik, koder/programista) wyko­nu­je okre­ślo­ny przed­miot na pod­sta­wie jego opi­su tech­nicz­ne­go, zawie­ra­ją­ce­go wszel­kie infor­ma­cje do tego wyma­ga­ne. Wybór tech­no­lo­gii i narzę­dzi oraz ich uży­cie, nie jest twór­czo­ścią, jest uży­ciem posia­da­nej wie­dzy i odpo­wied­nich środków. 

źr.: https://​her​ber​to​gra​ca​.com/​2​0​1​7​/​1​1​/​1​6​/​e​x​p​l​i​c​i​t​-​a​r​c​h​i​t​e​c​t​u​r​e​-​0​1​-​d​d​d​-​h​e​x​a​g​o​n​a​l​-​o​n​i​o​n​-​c​l​e​a​n​-​c​q​r​s​-​h​o​w​-​i​-​p​u​t​-​i​t​-​a​l​l​-​t​o​g​e​t​h​er/

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 mój 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 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ą.

Model systemu służy do określenia składników systemu.

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.

Standardowe trzy zakre­sy pro­jek­tów jakie ofe­ru­je. Każdy wią­że się z opcjo­nal­nym nad­zo­rem autorskim.

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ł ról 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.

(na pod­sta­wie: Architektura infor­ma­cji, sys­tem infor­ma­cyj­ny a infor­ma­tycz­ny w orga­ni­za­cji)

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

Role i pro­duk­ty w pro­jek­cie dostar­cze­nia opro­gra­mo­wa­nia (Model Logiczny Systemu to Platform Independent Model w MDA)

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

Czym jest Projekt czyli Model Logiczny Systemu

Oprogramowanie to część kom­pu­te­ra, ten zaś to nasz sys­tem. Mówiąc więc potocz­nie, że uży­wa­my pro­gra­mu kom­pu­te­ro­we­go” mamy na myśli apli­ka­cję na kom­pu­te­rze, a jako ludzie uży­wa­my komputera. 

Od wie­lu lat pra­cu­ję wg. zasady: 

softwa­re deve­lo­per vs softwa­re engi­ne­er
Generally, softwa­re engi­ne­ers look after the big­ger pic­tu­re, whi­le softwa­re deve­lo­pers focus on one area to exe­cu­te the­ir plans. Engineers can act as deve­lo­pers, too, or sim­ply over­see deve­lo­pers who cre­ate func­tio­nal programs.

https://​www​.rand​stad​.co​.uk/​c​a​r​e​e​r​-​a​d​v​i​c​e​/​c​a​r​e​e​r​-​g​u​i​d​a​n​c​e​/​f​u​l​l​-​s​t​a​c​k​-​d​e​v​e​l​o​p​e​r​-​v​s​-​s​o​f​t​w​a​r​e​-​e​n​g​i​n​e​er/

Zgodnie z powyż­szym: naj­pierw powsta­je pro­jekt opro­gra­mo­wa­nia a potem jest ono tworzone.

Model Logiczny Systemu w nomen­kla­tu­rze MDA (Model-dri­ven Architecture) to Platform Independent Model (PIM) czu­li model mecha­ni­zmu jego dzia­ła­nia. Związek mię­dzy pro­jek­tem a dzia­ła­ją­cym opro­gra­mo­wa­niem wyglą­da tak:

Architektura apli­ka­cji

Ważne jest to, by wie­dzieć, że: 1. kod nie jest swo­ją doku­men­ta­cją a jego ochro­na praw­na jest bar­dzo ogra­ni­czo­na, 2. pra­wo chro­ni pro­jekt opro­gra­mo­wa­nia (Platform Independent Model) jako utwór i jako know-how, kod jako odtwo­rze­nie pro­jek­tu w okre­ślo­nym języ­ku pro­gra­mo­wa­nia zawsze jest utwo­rem zależnym. 

Powyższe jest też czę­sto okre­śla­ne nazwą: archi­tek­tu­ra hek­sa­go­nal­na (Hexagonal Architecture). Podstawowym zało­że­niem jest tu wyraź­ne oddzie­le­nie stro­ny użyt­kow­ni­ka (User-Side), logi­ki biz­ne­so­wej (Business Logic) i stro­ny ser­we­ra czy­li śro­do­wi­ska wyko­ny­wa­nia apli­ka­cji (Server-Side) (patrz: Hexagonal Architecture: three prin­ci­ples and an imple­men­ta­tion exam­ple).

Powyższy dia­gram bywa przed­sta­wia­ny tak­że w innej formie: 

( źr.: Hexagonal Architecture, the­re are always two sides to eve­ry sto­ry)

Obszar nazwa­ny Domain to nasz model PIM (logi­ka biz­ne­so­wa). Jest to czę­sto w prze­tar­gach doku­ment nazy­wa­ny Opis Techniczny Oprogramowania (lub Opis Przedmiotu Zamówienia), w rozu­mie­niu opi­su mecha­ni­zmu jego dzia­ła­nia. Ta część reali­zu­je wyma­ga­nia funk­cjo­nal­ne. Pozostałe kom­po­nen­ty odpo­wia­da­ją za reali­za­cję wyma­gań pozafunkcjonalnych.

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.

Struktura pro­duk­tów ana­li­zy biz­ne­so­wej i projektowania.

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:

Monolit vs. mikro­ser­wi­sy (https://​www​.data​ro​bot​.com/​b​l​o​g​/​i​n​t​r​o​d​u​c​t​i​o​n​-​t​o​-​m​i​c​r​o​s​e​r​v​i​c​es/)

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

źr.: https://​her​ber​to​gra​ca​.com/​2​0​1​7​/​1​1​/​1​6​/​e​x​p​l​i​c​i​t​-​a​r​c​h​i​t​e​c​t​u​r​e​-​0​1​-​d​d​d​-​h​e​x​a​g​o​n​a​l​-​o​n​i​o​n​-​c​l​e​a​n​-​c​q​r​s​-​h​o​w​-​i​-​p​u​t​-​i​t​-​a​l​l​-​t​o​g​e​t​h​er/

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ść .

The One Question To Haunt Everyone: What is a DDD Aggregate? – Thomas Ploch – DDD Europe 2022

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):

Introduction to NoSQL ? Martin Fowler ? GOTO 2012

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:

Andrew Davidson, Matthew Fuchs, Mette Hedin, Mudita Jain, Jari Koistinen, Chris Lloyd, Murray Maloney, & Kelly Schwarzhof. (1999, July 30). Schema for Object-Oriented XML. Schema for Object-Oriented XML 2.0. https://​www​.w3​.org/​T​R​/​N​O​T​E​-​S​OX/
Anna Benchy, & Gibin George. (2022). Migration of Relational Database to Document Oriented Database. International Journal of Advanced Research in Science, Communication and Technology, 153 – 157. https://​doi​.org/​1​0​.​4​8​1​7​5​/​I​J​A​R​S​C​T​-​4​923
Bernauer, M., Kappel, G., & Kramler, G. (2003). Representing XML Schema in UML – An UML Profile for XML Schema. 25.
Booch, G., Christerson, M., Fuchs, M., & Koistinen, J. (1999). UML XML Mapping Schema. 8.
Börger, E. (2018). Why Programming Must Be Supported by Modeling and How. In T. Margaria & B. Steffen (Eds.), Leveraging Applications of Formal Methods, Verification and Validation. Modeling (Vol. 11244, pp. 89 – 110). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑030 – 03418-4_6
Brambilla, M., Cabot, J., & Wimmer, M. (2012). Model-dri­ven softwa­re engi­ne­ering in prac­ti­ce. Morgan & Claypool.
Buckland, M. (2018). Document Theory. KNOWLEDGE ORGANIZATION, 45(5), 425 – 436. https://​doi​.org/​1​0​.​5​7​7​1​/​0​943 – 7444-2018 – 5‑425
Buckland, M. K. (1997). What is a docu­ment”? Journal of the American Society for Information Science, 48(9), 804 – 809. https://​doi​.org/​1​0​.​1​0​0​2​/​(​S​I​C​I​)​1​097 – 4571(199709)48:9<804::AID-ASI5>3.0.CO;2‑V
Buckland, M. (1998). What is a digi­tal document”?
Carlson, D. (2001). Modeling XML Applications with UML. Pearson Education, Inc.
Chaves, D., & Malinowski, E. (2019). Document Data Modeling: A Conceptual Perspective. In T. Welzer, J. Eder, V. Podgorelec, R. Wrembel, M. Ivanović, J. Gamper, M. Morzy, T. Tzouramanis, J. Darmont, & A. Kamišalić Latifić (Eds.), New Trends in Databases and Information Systems (Vol. 1064, pp. 19 – 27). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑030 – 30278-8_3
Evans, E. (2003). Domain-Driven Design. Pearson Education (US).
Evans, E. (2014). Domain-dri­ven design: tac­kling com­ple­xi­ty in the heart of softwa­re. Addison-Wesley.
Fowler, M. (1997). Analysis pat­terns: reu­sa­ble object models. Addison Wesley.
Friedenthal, S., Moore, A., & Steiner, R. (2015). A prac­ti­cal guide to SysML: the sys­tems mode­ling lan­gu­age (Third edi­tion). Elsevier, MK, Morgan Kaufmann is an imprint of Elsevier. https://www.sciencedirect.com/book/9780128002025/a‑practical-guide-to-sysml
Murawski, R. (Ed.). (2015). Filozofia mate­ma­ty­ki i infor­ma­ty­ki. Copernicus Center Press.
Paredaens, J., Bra, P. D., Gyssens, M., & Gucht, D. van. (2012). The Structure of the Relational Database Model. Springer Science & Business Media.
Pugh, K. (2006). Interface-orien­ted design. Pragmatic Bookshelf.
Pyrża, A. (Ed.). (2006). Poradnik wyna­laz­cy: meto­dy­ka bada­nia zdol­no­ści paten­to­wej wyna­laz­ków i wzo­rów użyt­ko­wych. Urząd Patentowy Rzeczypospolitej Polskiej. https://uprp.gov.pl/sites/default/files/inline-files/Poradnik%20wynalazcy.%20Metodyka%20badania%20zdolno%C5%9Bci%20patentowej%20wynalazk%C3%B3w%20i%20wzor%C3%B3w%20u%C5%BCytkowych.%20Wydanie%20I.pdf
Robert C. Martin. (2018). Czysta archi­tek­tu­ra Struktura i design opro­gra­mo­wa­nia Przewodnik dla pro­fe­sjo­na­li­stów (Wojciech Moch, Trans.). Helion SA.
Sharma, G., Tripathi, V., & Singh, V. (2023). A sys­te­ma­tic ana­ly­sis of tren­ding NOSQL data­ba­se tools and tech­ni­qu­es: A survey. 020091. https://​doi​.org/​1​0​.​1​0​6​3​/​5​.​0​1​5​4​304
Document Content Description for XML. (1998, July 31). Document Content Description for XML. https://​www​.w3​.org/​T​R​/​N​O​T​E​-​dcd
Williams, S. P., Mosen, J., & Schubert, P. (n.d.). The Structure of Social Documents. 10.

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.