Ten arty­kuł jest adre­so­wa­ny do wszyst­kich. Biznes (praw­ni­cy tak­że) może prze­ko­nać się, że opro­gra­mo­wa­nie moż­na nary­so­wać i zro­zu­mieć. Analitycy i pro­gra­mi­ści, że to moż­li­we, a dewe­lo­pe­rzy, że nikt im nie odbie­ra pra­cy a raczej pomaga. 

Wprowadzenie

W dzi­siej­szym świe­cie inży­nie­rii naj­więk­szą war­tość mają czas i zaso­by. Czas to jak naj­szyb­sze odda­nie roz­wią­za­nia (pro­duk­tu) do użyt­ku (szyb­ka komer­cja­li­za­cja), zaso­by to koszt jakim się to odbę­dzie. Kluczem są kosz­ty: time to mar­ket”, tu kosz­tem jest opóź­nie­nie komer­cja­li­za­cji (nie­zre­ali­zo­wa­ne przy­cho­dy), kosz­tem jest tak­że samo powsta­wa­nia opro­gra­mo­wa­nia. Praktycznie od począt­ku inży­nie­rii opro­gra­mo­wa­nia zależ­ność kosz­tów od dys­cy­pli­ny i eta­pu pra­cy się nie zmie­nia, wyglą­da to jak poniżej:

Źr. Effective softwa­re deli­ve­ry. White paper. May 2009

Od same­go począt­ku prac nad opro­gra­mo­wa­niem tak napraw­dę roz­wią­zu­je­my pro­ble­my: począw­szy od pro­ble­mów z odkry­ciem co tak napraw­dę jest roz­wią­za­niem pro­ble­mu (a pro­blem trze­ba naj­pierw ziden­ty­fi­ko­wać), przez pro­ble­my zwią­za­ne z wła­ści­wym zapro­jek­to­wa­niem roz­wią­za­nia (algo­ryt­my, archi­tek­tu­ra kodu), do pro­ble­mów wybo­ru tech­no­lo­gii i imple­men­ta­cji. Patrząc od koń­ca: pomył­ki są bar­dzo kosz­tow­ne dla orga­ni­za­cji (spon­sor pro­jek­tu). Development (kodo­wa­nie i testy) to pra­ca zespo­łów ludzi, są bar­dzo kosz­tow­ne. Najtańsza jest tu pra­ca (etap) ana­li­ty­ka-pro­jek­tan­ta, to jed­nak tak­że czas (pamię­ta­my time to market”). 

Tak więc water­fall” nie wcho­dzi w grę. Praktyka jed­nak poka­zu­je, że roz­po­czę­cie od razu od kodo­wa­nia nie roz­wią­zu­je żad­ne­go pro­ble­mu bo złe pomy­sły są i będą, kory­go­wa­ne dopie­ro na eta­pie kodo­wa­nia gene­ru­ją bar­dzo duże kosz­ty. Lekarstwem jest odej­ście o mono­li­tycz­nej archi­tek­tu­ry na rzecz samo­dziel­nych kom­po­nen­tów, czy wręcz mikro­ser­wi­sów (jed­nost­ki imple­men­ta­cji to poje­dyn­cze przy­pad­ki uży­cia UML, tu rozu­mia­ne jako nie­za­leż­ne mikro-apli­ka­cje ). Dlatego opty­mal­ne wyda­je sie podej­ście: 1. ana­li­za, 2. pro­jek­to­wa­nie HLD: kom­po­nen­ty, 3. ite­ra­cyj­ne pro­jek­to­wa­nie LLD kom­po­nen­tów i ich deve­lop­ment. Osiągamy waż­ną rzecz: naj­droż­sze zaso­by: deve­lop­ment, dosta­ją do imple­men­ta­cji prze­my­śla­ne roz­wią­za­nie, nie tra­ci­my cza­su i środ­ków na kolej­ne pro­to­ty­py w kodzie. 

MDA czyli cykl życia aplikacji

Ponad 10 lat temu orga­ni­za­cja Object Management Group opu­bli­ko­wa­nia spe­cy­fi­ka­cje MDA (Model Driven Architecture, archi­tek­tu­ra zorien­to­wa­na na mode­le ). Opisuje ona pro­ces od ana­li­zy, przez mode­le roz­wią­za­nia, aż do jego imple­men­ta­cji. Proces ten wyglą­da tak:

MDA proces poziomy CIP PIM PSM

Czy to jest water­fall (tech­ni­ka wodo­spa­do­wa)? To zale­ży od zapro­jek­to­wa­nej archi­tek­tu­ry opro­gra­mo­wa­nia. Jeżeli będzie to funk­cyj­ny mono­lit budo­wa­ny na cen­tral­nej rela­cyj­nej, bazie danych (RDBMS) to będzie to water­fall. Jeżeli jed­nak będzie to kom­po­nen­to­wa archi­tek­tu­ra zorien­to­wa­na na micro apli­ka­cje (micro ser­wi­sy), będzie to zwin­na, ite­ra­cyj­no-przy­ro­sto­wa, imple­men­ta­cja i roz­wój, gdyż na pod­sta­wie mode­lu PIM (tak­że poli­ty­ka podzia­łu na kom­po­nen­ty i usłu­gi) wyko­ny­wa­ne są przy­ro­sto­wo i nie­za­leż­nie od sie­bie, kolej­ne imple­men­ta­cje usług apli­ka­cji (PSM->Code). Tak więc wszyst­ko roz­strzy­ga się na pozio­mie mode­li PIM. PIM (Platform Independent Model) to pro­jekt opro­gra­mo­wa­nia nie­za­leż­ny od tech­no­lo­gii (czy­li tak­że od uży­te­go języ­ka programowania). 

Mikro-serwisy

O mikro-apli­ka­cjach pisa­łem nie raz, tu tyl­ko przypomnienie:

Tak więc wszyst­ko zale­ży od archi­tek­tu­ry, zwin­ność tak­że. Po pra­wej stro­nie (dia­gram powy­żej) poka­za­no ideę podzia­łu apli­ka­cji na nie­za­leż­ne kom­po­nen­ty, każ­dy z wła­snym repo­zy­to­rium (bazą danych). Komponenty te moż­na deve­lo­po­wać i odda­wać do użyt­ku w dowol­nej kolej­no­ści .

Program to abstrakcja rozwiązania, określony kod to jedna z wielu możliwych implementacji

Złożoność sys­te­mów rośnie z każ­dym rokiem. Oprogramowanie (kom­pu­te­ry) jest czę­ścią coraz więk­szej ich licz­by. Development jest naj­kosz­tow­niej­szą fazą wytwa­rza­nia opro­gra­mow­nia, dla­te­go coraz zno­wu czę­ściej poprze­dza się go pro­jek­to­wa­niem czy­li two­rze­niem pro­gra­mu jako logi­ki” . Nie da się z mar­szu” napi­sać tysię­cy linii kodu, nie popeł­nia­jąc błę­dów w kodzie czy na pozio­mie samej archi­tek­tu­ry i logi­ki działania.

Tworzenie sys­te­mów zawie­ra­ją­cych opro­gra­mo­wa­nie obej­mu­je wie­le pozio­mów abs­trak­cji, pro­wa­dzą­cych od wyma­gań do kodu. Posiadanie abs­trak­cyj­nych kon­cep­cji poma­ga zde­fi­nio­wać kod i upew­nić się, że kom­po­nen­ty opro­gra­mo­wa­nia zacho­wu­ją się w ocze­ki­wa­ny spo­sób. Istnieje luka, któ­ra nie może być wypeł­nio­na przez zwy­kłe meto­dy pro­gra­mo­wa­nia, ale któ­ra może być wypeł­nio­na, jeśli pro­gra­mo­wa­nie jest wspie­ra­ne przez odpo­wied­nie ramy modelowania.

Program kom­pu­te­ro­wy może zostać wyra­żo­ny z pomo­cą kodu, ale tak­że, w spo­sób rów­no­praw­ny, z pomo­cą sche­ma­tów blo­ko­wych, algo­ryt­mów i wzo­rów mate­ma­tycz­nych” (http://​www​.ipblog​.pl/​2​0​1​7​/​0​3​/​p​r​o​g​r​a​m​y​-​k​o​m​p​u​t​e​r​o​w​e​-​c​o​-​p​o​d​l​e​g​a​-​o​c​h​r​o​n​ie/). Zgodnie z powyż­szym i z MDA mamy:

Jeden pro­jekt (PIM) i wie­le moż­li­wych jego reali­za­cji (PSM)

Przykład czyli programujemy obrazkowo

Zakres projektu

Opracujemy pro­gram wspie­ra­ją­cy pro­ces obsłu­gi klien­tów przy­chod­ni wete­ry­na­ryj­nej. Wygląda on tak:

Obsługa klien­ta Przychodni weterynaryjnej

Jak widać nie jest spe­cjal­nie wyra­fi­no­wa­ny: Jeżeli potrzeb­na jest wizy­ta ze swo­im pupi­lem u wete­ry­na­rza, uma­wia­my ter­min, przy­cho­dzi­my na wizy­tę, opusz­cza­my przy­chod­nie z recep­tą i zale­ce­nia­mi. Faza ana­li­zy i opra­co­wa­nia archi­tek­tu­ry zosta­ła opi­sa­na w arty­ku­le Projekt apli­ka­cji. Tu sku­pi­my się na pro­gra­mo­wa­niu”.

Od kil­ku już dekad w pod­ręcz­ni­kach inży­nie­rii opro­gra­mo­wa­nia nadal moż­na spo­tkać sentencję: 

algo­ryt­my + struk­tu­ry danych = programy 

Poza tech­no­lo­gią i para­dyg­ma­ta­mi, nic sie nie zmie­ni­ło. To zna­czy, że bez wzglę­du na archi­tek­tu­rę, para­dyg­mat i język pro­gra­mo­wa­nia, «pro­gra­my» to «algo­ryt­my + struk­tu­ry danych». Innymi sło­wy: pro­gra­mo­wa­nie to pro­jek­to­wa­nie algo­ryt­mów i struk­tur danych, dalej jest już tyl­ko imple­men­ta­cja (kodo­wa­nie) tych programów. 

Każdy pro­gram” to dekla­ra­cja zmien­nych + dzia­ła­nia na nich. Może to być poprze­dzo­ne pobra­niem tych danych i zakoń­czo­ne zwró­ce­niem danych (para­me­trów). Można to (frag­ment pro­gra­mu pre­zen­to­wa­na jako czyn­ność” w UML) wyra­zić pseudokodem:

Lub w for­mie bar­dziej przy­stęp­nej dla laika, obraz­ko­wej”:

Od począt­ków czło­wie­czej biu­ro­kra­cji” stan­dar­do­wą for­mą prze­cho­wy­wa­nia danych są for­mu­la­rze, czy sze­rzej rzecz ujmu­jąc, doku­men­ty. W roku 1972 Codd opu­bli­ko­wał swo­ja pra­cę, w któ­rej opi­sał rela­cyj­ny model danych, jed­nak celem było zarzą­dza­nie zbio­ra­mi danych a nie infor­ma­cją” . Powstało wie­le imple­men­ta­cji tego mode­lu i nie­ste­ty model ten zdo­mi­no­wał bran­że. W cza­sie gdy powsta­wał liczy­ła się opty­ma­li­za­cja tych zbio­rów od stro­ny obję­to­ści (to był głów­ny czyn­nik kosz­to­wy). Jednak po latach oka­za­ło się, że:

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

To powo­du­je, że od 20 lat mamy moż­li­wość korzy­sta­nia z baz zorien­to­wa­nych na doku­men­ty (bazy NoSQL). Struktury danych bar­dzo łatwo i efek­tyw­nie moż­na pro­jek­to­wać od razu jako szkie­le­ty doku­men­tów: agre­ga­ty :

Diagram struk­tur zło­żo­nych, UML

Powyższy dia­gram to kla­sycz­ny agre­gat, któ­ry z innej per­spek­ty­wy wyglą­da tak:

Diagram klas UML

Powyższe łatwo zapi­sać jako jed­na struk­tu­rę XML (lub JSON) i zacho­wać jako war­tość jed­ne­go atry­bu­tu obiek­tu . Każdy ele­ment tego agre­ga­tu (atry­but) ma adre­so­wal­ną uni­kal­ną postać, np. data pla­no­wa­nej wizyty: 

Karta Wizyty.data := 22-10-02
Karta Wizyty.Rezerwacja.data := 22-10-16

Gdzie nazwa doku­men­tu jest począt­kiem ścież­ki (nazwy doku­men­tów-agre­ga­tów muszą być uni­kal­ne). Dzięki temu atry­bu­ty, jako typy danych, defi­nio­wa­ne są raz (np. tu data), zaś kon­tekst nada­je im poło­że­nie w struk­tu­rze doku­men­tu. Powyższy przy­kład to dwie róż­ne daty: data doko­na­nia rezer­wa­cji (data zało­że­nia Karty wizy­ty) i data samej wizy­ty. Tu 2 paź­dzier­ni­ka umó­wio­no sie na wizy­tę w dniu 16 paź­dzier­ni­ka. Ale typ «data» defi­niu­je­my raz, nie musi­my defi­nio­wać tylu dat ile jest ich rodza­jów (data_rezerwacji, data_wizyty, itp…)

Tą meto­dą jed­nym pro­stym kro­kiem pobie­ra­my dane z takie­go agre­ga­tu , następ­nie opi­su­je­my jakie ope­ra­cje mają zostać na nich wyko­na­ne, wynik zwra­ca­my jako ten sam agre­gat (wyli­czo­no war­to­ści pustych atry­bu­tów, zwra­ca­my wypeł­nio­ne) lub inny agre­gat (wynik wyli­czeń to nowy formularz/agregat) i może­my go np. prze­ka­zać inne­mu kom­po­nen­to­wy do utrwa­le­nia, lub zwró­cić jako wynik do poka­za­nie na ekra­nie (patrz tak­że star­szą for­mę wzor­ca enve­lo­pe: DTO).

Przykładowy opis two­rze­nia nowej kar­ty wizyty:

Diagram aktyw­no­ści UML

Tak więc zapro­jek­to­wa­nie apli­ka­cji, prze­te­sto­wa­nie spój­no­ści i kom­plet­no­ści logi­ki jej dzia­ła­nia, przed kodo­wa­niem jest nie tyl­ko moż­li­we ale i pożą­da­ne, pomi­jam, że odby­wa sie znacz­nie mniej­szym kosz­tem i szyb­ciej (prak­ty­ka poka­zu­je, że powyż­sze na dia­gra­mach jest o ponad rząd wiel­ko­ści szyb­sze i tań­sze niż pra­ca od razu na kodzie).

Podsumowanie

Od począt­ku inży­nie­rii opro­gra­mo­wa­nia wia­do­mo, że pro­gra­mo­wa­nie to nie koniecz­nie kodo­wa­nie. Już na stu­diach naj­pierw ryso­wa­łem” opro­gra­mo­wa­nie a potem dopie­ro kodo­wa­łem to np. w Fortranie. Powód zawsze był ten sam: pra­ce kon­cep­cyj­ne są wie­lo­krot­nie tań­sze na sche­ma­tach blo­ko­wych niż na żywej maszy­nie. Ten sam pro­gram moż­na było zawsze uru­cho­mić na róż­nych kom­pu­te­rach, koniecz­ny był jedy­nie wybór wła­ści­we­go języ­ka dla danej maszy­ny. Owszem, moż­na od razu w kodzie”, jest to jed­nak naj­bar­dziej nie­efek­tyw­na meto­da two­rze­nia opro­gra­mo­wa­nia. Wbrew potocz­ne­mu postrze­ga­niu mani­fe­stu agi­le, opi­sa­ne tu sche­ma­ty blo­ko­we to nie jest nad­mia­ro­wa doku­men­ta­cja” a isto­ta dzia­ła­nia sys­te­mu”. Po dru­gie ani urząd paten­to­wy w USA, ani euro­pej­ski sąd w spra­wie ochro­ny know-how, nie będzie ana­li­zo­wał kodu źró­dło­we­go tyl­ko jego sfor­ma­li­zo­wa­ny opis. 

Źródła

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
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
Codd, E. F. (1970). A Relational Model of Data for Large Shared Data Banks. IBM Research Laboratory. https://web.archive.org/web/20110912055121/http://www.cs.berkeley.edu/~christos/classics/Codd72a.pdf
Evans, E. (2003). Domain-Driven Design. Pearson Education (US).
Newman, S. (2015). Building micro­se­rvi­ces: desi­gning fine-gra­ined sys­tems (First Edition). O’Reilly Media.
Object Management Group. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
Object Management Group. (2010). The MDA Foundation Model. Object Management Group. https://​www​.omg​.org/​c​g​i​-​b​i​n​/​d​o​c​?​o​r​m​s​c​/10 – 09-06.pdf
Object Management Group. (2014). Model Driven Architecture (MDA) MDA Guide rev. 2.0. Object Management Group. https://​www​.omg​.org/​c​g​i​-​b​i​n​/​d​o​c​?​o​r​m​s​c​/14 – 06-01.pdf
Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software, 37(2), 3 – 5. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​1​9​.​2​9​5​9​049
Paredaens, J., Bra, P. D., Gyssens, M., & Gucht, D. van. (2012). The Structure of the Relational Database Model. Springer Science & Business Media.
Šilingas, D., & Butleris, R. (2009). Towards imple­men­ting a fra­me­work for mode­ling softwa­re requ­ire­ments in MagicDraw UML. Information Technology and Control, 38(2).
Wirth, N. (2004). Algorithms and Data Structures (Oberon ver­sion). https://web.archive.org/web/20110813043427/http://www.ethoberon.ethz.ch/WirthPubl/AD.pdf

Jarosław Żeliński

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Masz pytania to treści artykułu? Kliknij tu i umów się na krótkie konsultacje.

Ten post ma 3 komentarzy

  1. Sławek Sobótka

    Problem z tym, że cza­sem ta pomoc” pro­gra­mi­stom koń­czy się jak niedź­wie­dzia przy­słu­ga. Źle zakre­ślo­ne gra­ni­ce mikro­ser­wi­sów, modu­łów czy obiek­tów. Źle bo naiw­nie i zbyt dosłow­nie zebra­ne wyma­ga­nia”, bez ana­li­zy – tyl­ko czym jest ta ana­li­za? Weźmy na tapet przy­kład z kar­tą wizy­ty. Przedstawiony model, to bar­dzo dobry model pre­zen­ta­cyj­ny (view model, read model, pro­jek­cja). Ale zro­bie­nie z tego agre­ga­tu DDD to suma wszyst­kich antyw­zor­ców jak nie robić DDD czy nawet object orien­ted. Budując na tej pod­sta­wie sys­tem, któ­ra da się roz­bu­do­wać czy ska­lo­wać skoń­czy­my z kata­stro­fą. Dlatego wypo­wiem się w obro­nie pro­gra­mi­stów, nie cho­dzi o strach o odbie­ra­nie pra­cy”, bo tej jest po kokard­kę ale o jej dokła­da­nie przez błęd­ne mode­le, któ­re i tak trze­ba robić od nowa same­mu albo póź­niej wszyst­ko przerabiać.

    1. Jarosław Żeliński

      Problem z tym, że cza­sem ta pomoc” pro­gra­mi­stom koń­czy się jak niedź­wie­dzia przy­słu­ga.” to zawsze dzia­ła w obie strony. 

      Pojęcie agre­ga­tu to pro­blem wie­lu spo­rów: agre­ga­cja” rozu­mia­na jako obiek­ty połą­czo­ne związ­kiem kom­po­zy­cji, czy hie­rar­chicz­na struk­tu­ra danych” wyra­żo­na jako JEDEN DOKUMENT (XML, JSON, itp.). Obserwując imple­men­ta­cje i ich skut­ki, kata­stro­fą jest pierw­sze rozu­mie­nie. Dlatego od 20 lat bazy doku­men­to­we (agre­gat danych jako jeden doku­ment) dają znacz­nie lep­sze wyni­ki. Jeżeli mam do czy­nie­nia z popra­wia­niem po błęd­nych mode­lach, to w 100% są to doku­men­ty zacho­wy­wa­ne jako rela­cyj­ne mode­le danych wydłu­by­wa­ne zapy­ta­nia­mi SQL po set­ki zna­ków na każ­de takie zapy­ta­nie. DDD zaś abso­lut­nie nicze­go tu nie narzu­ca: enti­ty to pła­ska struk­tu­ra a agre­gat to drze­wia­sta. Jak ktoś imple­men­tu­je drze­wia­stą struk­tu­rę danych jako kaska­dę dekla­ra­cji zagnież­dżo­nych klas, a potem na to nakła­da jesz­cze ORM by zapi­sać to w rela­cyj­nym (pła­skim, pozba­wio­nym redun­dan­cji) mode­lu to to jest mega katastrofa ;). 

      Jakość opro­gra­mo­wa­nia ma jeden mier­nik: kosz­ty całe­go cyklu życia.

    2. Jarosław Żeliński

      Budując na tej pod­sta­wie sys­tem, któ­ra da się roz­bu­do­wać czy ska­lo­wać skoń­czy­my z katastrofą.”

      Tak (takie agre­ga­ty) powsta­ła apli­ka­cja obsłu­gu­ją­ca wnio­ski o dofi­nan­so­wa­nie pro­jek­tów polo­nij­nych z całe­go świa­ta. Zmienność tre­ści wnio­sków (wnio­sek to ww. opi­sa­ny agre­gat) to doku­men­ty od kil­ku­na­stu stron do kil­ku­set, i co roku inna defi­ni­cja struk­tu­ry wnio­sku. Projekt wg. powyż­sze­go opi­su i meto­dy powstał w mie­siąc, a imple­men­ta­cja w 5 mie­się­cy, łącz­nym kosz­tem ok. 0,5 mln zł. Konkurencyjne ofer­ty: Java Spring + SQL/RDBMS opie­wa­ły na ponad 10 mln, jako co naj­mniej rocz­ny pro­jekt. Mój pro­jekt był udo­ku­men­to­wa­ny tak, że w cią­gu pię­ciu lat kod był przej­mo­wa­ny dwu­krot­nie przez kolej­ne fir­my a bene­fi­cjant do dzi­siaj ma pra­wa mająt­ko­we do cało­ści. Analogicznie powsta­ła z mojej ręki apli­ka­cja zarzą­dza­ją­ca pra­ca­mi wydzia­ły śled­cze­go Żandarmerii Wojskowej w całej Polsce. efek­ty podob­ne do powyż­szych. Obie się dosko­na­le ska­lu­ją, pierw­sza bez­bo­le­śnie zosta­ła prze­nie­sio­na do chmu­ry AZURE. Żadna, w toku roz­wo­ju, nie wyma­ga­ła migra­cji danych. 

      Paradygmat obiek­to­wy to nie dzie­dzi­cze­nie i łącze­nie danych i funk­cji w obiek­ty” a współ­pra­cu­ją­ce obiek­ty cechu­ją­ce sią luź­ny­mi powią­za­nia­mi, her­me­ty­za­cją i polimorfizmem”.

Dodaj komentarz

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