Adresatem tego wpi­su są współ­pra­cu­ją­cy ze mną dostaw­cy opro­gra­mo­wa­nia ERP i dewe­lo­pe­rzy, gdyż Opis Techniczny Oprogramowania (archi­tek­tu­ra logi­ki biz­ne­so­wej sys­te­mu) to wyma­ga­nie w sto­sun­ku do pro­duk­tu zama­wia­ne­go przez moich klien­tów u dewe­lo­pe­ra (wyko­naw­cy imple­men­ta­cji). Deweloper wraz z pro­jek­tem sys­te­mu otrzy­mu­je tak­że Analizę Biznesową jako opis kon­tek­stu projektu.

Tekst ten zawie­ra krót­ki opis pra­cy ze mną oraz opis i przy­kła­dy moich pro­duk­tów. Jeżeli są Państwo, jako dewe­lo­pe­rzy, zain­te­re­so­wa­ni zle­ce­niem mi opra­co­wa­nia Analizy Biznesowej i Opisu Technicznego Oprogramowania lub jego czę­ści, zapra­szam na stro­nę Zapytanie.

Typowy podział na role w projekcie

Najczęściej jestem anga­żo­wa­ny do pro­jek­tów, w któ­rych usta­lo­no trzy role: 1. Zamawiający, jako Organizacja Analizowana zgła­sza cele biz­ne­so­we i pro­ble­my (Wymagania Biznesowe wobec pro­jek­tu). 2. Analityk Biznesowy – Architekt Systemu Informacyjnego, pro­wa­dzi ana­li­zę i opra­co­wu­je model biz­ne­so­wy orga­ni­za­cji (pro­ce­sy biz­ne­so­we i ich logi­ka), reko­men­du­je obsza­ry do popra­wy, opra­co­wu­je roz­wią­za­nie jako archi­tek­tu­rę logicz­ną wyma­ga­ne­go sys­te­mu (Opis Techniczny Oprogramowania), jest ona wyma­ga­niem dla dewe­lo­pe­ra. 3. Deweloper wyko­naw­ca roz­wią­za­nia (full stack deve­lo­per). Z per­spek­ty­wy klien­ta wyglą­da to tak:

Proces dostar­cza­nia opro­gra­mo­wa­nia, na pod­sta­wie oraz 

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 kupio­ne na ryn­ku (COTS) lub dedy­ko­wa­ne deve­lo­po­wa­ne (patrz Kastomizacja…).

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/

Z per­spek­ty­wy dewe­lo­pe­ra wyglą­da to tak:

Jako Architekt Systemu sta­le poszu­ku­ję deve­lo­pe­rów do współ­pra­cy: zare­je­struj się jako deve­lo­per na new­slet­ter.

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

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.

Dlaczego moje projekty są zorientowane na dokumenty

Ważna uwa­ga! Poniższe doty­czy 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. Poniższy 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 wte­dy wzor­ce pro­jek­to­we dla Repozytorium to Active Record i Active Table. 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”.

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. 

Dlatego od dwóch dekad doku­men­ty w sys­te­mach infor­ma­tycz­nych są coraz czę­ściej wyra­ża­ne jako struk­tu­ry XML/XSD/DTD (lub JSON) i prze­cho­wy­wa­ne w takiej posta­ci , czę­sto uzu­peł­nia­ne wer­sją do czy­ta­nia i dru­ku” w for­ma­cie pdf (real­nie są to czę­sto pli­ki pdf zawie­ra­ją­ce treść XML). 

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ś pli­ki XML jako doku­men­ty, 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 (np. struk­tu­ry doku­men­tów XML) prze­cho­wy­wa­ne w nie­za­leż­nych pła­skich (nie powią­za­nych rela­cyj­nie) tabe­lach: kolum­ny 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 .

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. 

Jak masz czas pole­cam wystą­pie­nie M. Fowlera z 2012 roku: 

Komunikacja w projekcie

Co do zasa­dy pra­cu­ję zdal­nie i pre­fe­ru­ję pisem­ną for­mę wymia­ny tre­ści i mate­ria­łów. Spotkania np. na Skype, są jak naj­bar­dziej pro­wa­dzo­ne, jed­nak ich celem są bie­żą­ce usta­le­nia, pla­no­wa­nie, pre­zen­ta­cje pro­to­ty­pów, itp. a nie np. warsz­ta­ty i zbie­ra­nie wyma­gań”. Pisemna for­ma prze­ka­zy­wa­nia wszel­kich mate­ria­łów zabez­pie­cza inte­res wszyst­kich trzech stron pro­jek­tów (spon­sor, pro­jek­tant, wyko­naw­ca). Więcej na stro­nie Komunikacja w pro­jek­cie, opis narzę­dzia jakie sto­su­ję w komu­ni­ka­cji na stro­nie: Visual Paradigm Postmania (bio­rą­cy udział w komu­ni­ka­cji spon­sor i deve­lo­per nie muszą nicze­go insta­lo­wać, ani kupo­wać jakich­kol­wiek licencji).

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ę poka­zać 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żej wybra­ne opra­co­wa­nia wyko­na­ne dla admi­ni­stra­cji publicz­nej jako Opis Przedmiotu Zamówienia i wybra­ne wer­sje demo. 

Poniższe opra­co­wa­nia do 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). 

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/.

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

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, pro­szę o kon­takt. Zainteresowany? Zarejestruj się jako deve­lo­per na new­slet­ter!.

Źródła:

Ambra Molesini, Enrico Denti, & Andrea Omicini. (2021). MDE and MDA in a Multi- Paradigm Modeling Perspective (Y. Rhazali, Ed.). IGI Global. https://​doi​.org/​1​0​.​4​0​1​8​/​978 – 1‑7998 – 3661‑2
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.
Carlson, D. (2001). Modeling XML Applications with UML. Pearson Education, Inc.
Fowler, M. (1997). Analysis pat­terns: reu­sa­ble object models. Addison Wesley.
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.
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.
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.