Wprowadzenie

Coraz czę­ściej czy­ta­my o śro­do­wi­skach chmu­ro­wych” (nadal nie mogę się prze­ko­nać do pisa­nia tego bez cudzy­sło­wu). Nawet tak zaawan­so­wa­ne jak Amazon WS czy AZURE, są nadal bar­dzo czę­sto wyko­rzy­sty­wa­ne tyl­ko jako hosting apli­ka­cji. Oba te ser­wi­sy moż­na wyko­rzy­sty­wać jako sie­cio­wy dysk, śro­do­wi­sko sys­te­mo­we (Windows, Linux), bazę danych SQL, ale tak­że jako bazy NoSQL. 

Jednym z naj­istot­niej­szych ele­men­tów sys­te­mów infor­ma­cyj­nych (patrz: infor­ma­tion scien­ce) jest utrwa­la­nie danych (pamię­taj­my, że dane to zapi­sy, a infor­ma­cja to to, co rozu­mie czło­wiek, któ­ry je czy­ta). Niedawno nawią­zy­wa­łem do pro­ble­mu utrwa­la­nia danych.

Poprawna obiek­to­wa archi­tek­tu­ra i kom­plet­ny pro­jekt tech­nicz­ny apli­ka­cji (model PIM) opi­su­je pre­cy­zyj­nie jak wyko­nać imple­men­ta­cje i nie zawie­ra pro­jek­tu żad­nej bazy danych, ani tym bar­dziej zapy­tań SQL. Implementacja utrwa­la­nia nie może mieć wpły­wu na logi­kę biz­ne­so­wą sys­te­mu ani nawet zawie­rać jej! (źr.: Dokument a kumu­la­cja fak­tów: OOAD i model dzie­dzi­ny sys­te­mu) Prosty dia­gram po lewej stro­nie poka­zu­je pro­blem opi­sa­ny przez Smith’a jako Computers, Models, and the Embedding World, The Limits of Correctness.” 

Komputer (rozu­mia­ny jako pro­ce­sor, pamięć i pro­gram) sta­no­wi dla czło­wie­ka narzę­dzie pracy. 

Cechą kom­pu­te­ra jest w ogrom­nej więk­szo­ści przy­pad­ków odwzo­ro­wy­wa­nie tego co zastę­pu­je­my kom­pu­te­rem, a tak zwa­ne sys­te­my biz­ne­so­we, zastę­pu­ją papie­ro­we for­my prze­twa­rza­nia i prze­cho­wy­wa­nia infor­ma­cji. Systemy ERP, CRM, Workflow, Sklepy inter­ne­to­we, Archiwa, i wie­le innych to tak na praw­dę doku­men­ty i ich treść. 

Istota pro­ble­mu pole­ga na tym, że okre­ślo­ne, dostęp­ne tech­no­lo­gie same z sie­bie czę­sto stwa­rza­ją ogra­ni­cze­nia tego co mogą (potra­fią) odwzo­ro­wać, i mimo upły­wu cza­su i postę­pu tech­no­lo­gii, ana­li­za i pro­jek­to­wa­nie zarzą­dza­nia infor­ma­cją nadal jest jed­nym z naj­więk­szych pro­ble­mów wdro­żeń systemów. 

SQL vs. NoSQL

SQL

Skrót NoSQL jest inte­pre­to­wa­ny jako nie SQL” lub nie tyl­ko SQL” (Not only SQL). SQL (Structured Query Language) to język zapy­tań do baz danych o rela­cyj­nym mode­lu danych (ang. RDBMS: Relational Data Base Management System). Cechą tego mode­lu danych jest usu­wa­nie redun­dan­cji i podział danych na tabe­le i słow­ni­ki pól tych tabel, oraz związ­ki mię­dzy nimi (rela­cje). W efek­cie otrzy­mu­je­my sche­ma­ty tabel i rela­cji mię­dzy nimi np. takie:

A nawet takie:

(model danych pew­ne­go sys­te­mu ERP)

Odtworzenie doku­men­tu (for­mu­la­rza) będą­ce­go np. fak­tu­rą lub dekla­ra­cją podat­ko­wą, wyma­ga wyko­na­nia sze­re­gu bar­dzo skom­pli­ko­wa­nych ope­ra­cji łącze­nia danych z tych tabel i odwzo­ro­wa­nia ich pier­wot­nej posta­ci np. fak­tu­ry. W tego typu bazach danych fizycz­nie nie ma żad­nych dokumentów. 

Drugim pro­ble­mem jaki stwa­rza model rela­cyj­ny, jest koniecz­ność jego prze­bu­do­wy prak­tycz­nie zawsze, gdy zmie­ni się struk­tu­ra prze­cho­wy­wa­nych w nim doku­men­tów (opra­co­wa­nie nowe­go mode­lu, migra­cja danych do nowe­go mode­lu – bywa że nie­moż­li­wa w 100%, aktu­ali­za­cja zapy­tań SQL do nowej struk­tu­ry bazy danych). 

Biorąc pod uwa­gę fakt, że real­ny świat to cią­głe zmia­ny, model rela­cyj­ny jest w tym przy­pad­ku po pro­stu nieadekwatny. 

Koszty utrzy­ma­nia i roz­wo­ju sys­te­mów zarza­dza­nia dany­mi (i apli­ka­cja­mi, któ­re je wyko­rzy­stu­ją) w mode­lu rela­cyj­nym, są wie­lo­krot­nie wyż­sze niż pier­wot­ne ich wdro­że­nie .

Po co więc wymy­ślo­no te rela­cyj­ne bazy? To były cza­sy gdy pamięć była naj­kosz­tow­niej­szym zaso­bem kom­pu­te­ra zaś dane mię­dzy sys­te­ma­mi w zasa­dzie nie były wymie­nia­ne! Było kil­ka zalet, np. brak błę­dów nazew­nic­twa itp. wię­cej o nich w sie­ci moż­na poczy­tać, jed­nak moim zda­niem baza danych będą­ca imple­men­ta­cją tak zwa­nych związ­ków poję­cio­wych (tym są rela­cyj­ne mode­le danych) nie spraw­dza się bo nie mode­lu­je obiek­tów świa­ta rze­czy­wi­ste­go a jedy­nie ich nazwy i powią­za­nia mię­dzy nimi a to ogrom­na róż­ni­ca. (źr.: SQL albo NoSQL, oto jest pyta­nie – 2011 r.)

NoSQL

Jednym z typo­wych przy­kła­dów bazy danych typu NoSQL są bazy typu key-value i ich odmia­ny . Z uwa­gi na ich cechy i powszech­ność sku­pię się na tego typu bazach. 

Wśród tego typu baz są tak zwa­ne bazy doku­men­to­we. Idea tego typu baz danych reali­zu­je jed­no pod­sta­wo­wych zało­żeń obiek­to­we­go para­dyg­ma­tu (role obiek­tów): repo­zy­to­rium nie słu­ży do prze­twa­rza­nia tre­ści a jedy­nie do jej utrwa­la­nia i szyb­kie­go przy­wo­ły­wa­nia (dostę­pu). Przetwarzaniem danych (tre­ści) zaj­mu­ją kom­po­nen­ty odpo­wie­dzial­ne wyłącz­nie za reali­za­cję logi­ki apli­ka­cji. Skoro repo­zy­to­rium nie prze­twa­rza tre­ści, jest ono – prze­cho­wy­wa­na treść i jej struk­tu­ra – neu­tral­nym ele­men­tem. Dlatego ope­ru­je­my tu czę­sto poję­ciem plik, któ­rym zależ­nie od typu bazy, może być np. ciąg zna­ków XML lub JSON albo po pro­stu ciąg binar­ny (czy­li cokol­wiek”). Taka baza to hipo­te­tycz­ne dwie kolum­ny: pierw­sza zawie­ra iden­ty­fi­ka­to­ry wier­szy a dru­ga prze­cho­wy­wa­ną treść. I teraz zależ­nie od typu bazy i logi­ki apli­ka­cji, któ­ra ją wyko­rzy­stu­je, tą tre­ścią może by ciąg zna­ków (np. XML, JSON) lub dowol­ny ciąg zna­ków binar­ny (czy­li XML tak­że, ale tak­że np. zdję­cie lub plik edy­to­ra tekstów). 

Przykładem bazy doku­men­to­wej jest Amazon DynamoDB. Poniższy dia­gram poka­zu­je w uprosz­cze­niu idee tej bazy i porów­na­nie z typo­wą mode­lem rela­cyj­nym: odtwo­rze­nie doku­men­tu z bazy rela­cyj­nej (po lewej) wyma­ga skom­pli­ko­wa­nych ope­ra­cji łącze­nia tabel, po pra­wej stro­nie mamy zaś zestaw cią­gów zna­ków, każ­dy sta­no­wi sobą kom­plet­ny już doku­ment, mogą one mieć róż­ną struk­tu­rę. Pobranie doku­men­tu z bazy po pra­wej odby­wa się zawsze pro­stym zapy­ta­niem, takim samym„ bez wzglę­du na struk­tu­rę tych danych. 

Dzięki temu osią­ga­my dwie klu­czo­we korzy­ści: zmie­nia­ją­ca się w cza­sie struk­tu­ra doku­men­tów nie wpły­wa na bazę danych, czas pobra­nia doku­men­tu jest bar­dzo krót­ki i nie zale­ży od struk­tu­ry doku­men­tu . Różnicę efek­tyw­no­ści poka­za­no poniżej:



Dokument jako struktura danych

Opisane bazy NoSQL mają sze­reg zalet w sto­sun­ku do baz danych w mode­lu rela­cyj­nym. Jednak pro­blem two­rze­nia mode­li rela­cyj­nych jest zastę­po­wa­ny pro­ble­mem mode­lo­wa­nia struk­tur doku­men­tów . Nie jest to jed­nak pro­blem budo­wa­nia znor­ma­li­zo­wa­nych rela­cyj­nych struk­tur danych. Jest to pro­blem natu­ry czy­sto seman­tycz­nej: rzecz w tym czym jest doku­ment i czym są pola, z któ­rych on się skła­da. Jest wie­le podejść do tego zagad­nie­nia, uwa­żam, że klu­czo­we jest odkry­cie i zro­zu­mie­nie co opi­su­je dany doku­ment. Po dru­gie istot­ne jest umie­jęt­ne zapro­jek­to­wa­nie logi­ki apli­ka­cji. Dlatego repo­zy­to­ria NoSQL z zasa­dy nie bio­rą udzia­łu w logi­ce biz­ne­so­wej ale struk­tu­ra doku­men­tów deter­mi­nu­je logi­kę ich prze­twa­rza­nia. Rolą repo­zy­to­rium jest wyłącz­nie utrwa­la­nie i udo­stęp­nia­nie. Poniżej przy­kład dość typo­wy: fak­tu­ry i opi­sy pro­duk­tów (opis pro­duk­tu jako Karta Produktu): mimo tego, że oba te typy doku­men­tów mają inną struk­tu­rę, mogą być prze­cho­wy­wa­ne w jed­nej i tej samej bazie danych NoSQL. 

Rejestry sepa­ru­ją­ce doku­men­to­wą bazę danych od logi­ki apli­ka­cyj­nej, dia­gram pocho­dzi z wyda­nej wła­śnie publi­ka­cji, w któ­rej dokład­nie opi­sa­no zasa­dy pro­jek­to­wa­nia sys­te­mów infor­ma­cyj­nych i tego typu repo­zy­to­riów: .

Baza doku­men­to­wa słu­ży wyłącz­nie do prze­cho­wy­wa­nia danych. Kontekstowy i seman­tycz­ny dostęp do danych zapew­nia­ją dzie­dzi­no­we reje­stry: dodat­ko­we pro­ste tabe­le umiesz­czo­ne przez repo­zy­to­rium, w czę­ści apli­ka­cyj­nej. Z uwa­gi na to, że bazy doku­men­to­we nie nada­ją się do reali­za­cji wyra­fi­no­wa­nych zbio­ro­wych obli­czeń na tre­ści doku­men­tów, wyko­rzy­stu­je się do tego typo­we hur­tow­nie danych. 

[uzu­peł­nie­nie mie­siąc póź­niej] Z tego wzglę­du bar­dzo przy­dat­ny jest tu dobrze zna­ny wzo­rzec pro­jek­to­wy Repozytorium (Repository). Istotą tego wzor­ca jest sepa­ra­cja kolek­cji obiek­tów (np. nośni­ków doku­men­tów) od logi­ki apli­ka­cji za pomo­cą kla­sy reali­zu­ją­cej inter­fejs do tej kolek­cji. Poniżej wer­sja adre­so­wa­na do chmury:

Realizacja utrwa­la­nia (zapis danych) to obiek­ty prze­cho­wu­ją­ce («Storage» Repozytorium danych) oraz dane («docu­ment» Zestaw danych) prze­cho­wy­wa­ne jako doku­men­ty (XML, JSON) lub pli­ki (baza key value). Dostęp do tej kolek­cji zapew­nia kla­sa «Management» Kontrola dostę­pu do danych, sta­no­wią­ca zara­zem inter­fejs do tej kolek­cji. Interfejsów do jed­ne­go repo­zy­to­rium może być wię­cej, reali­zu­ją one wte­dy kon­tek­sto­we udo­stęp­nia­nie danych z tej samej kolek­cji. Tak więc Realizacja usłu­gi to dzie­dzi­no­wy kod apli­ka­cji, zaś Realizacja utrwa­la­nia to chmu­ro­wa usłu­ga taka jak bazy NoSQL dostęp­ne w chmurze. 

Chmury Amazon i AZURE

Ciekawym przy­kła­dem bazy doku­men­to­wej jest DynamoDB. Jest to par­ty­cjo­no­wa­na baza NoSQL mają­ca dwie kolum­ny z klu­czem: jeden to stan­dar­do­wy dla tego typu bazy iden­ty­fi­ka­tor, dru­gi to klucz wska­zu­ją­cy na struk­tu­rę defi­niu­ją­cą for­mat danych w trze­ciej kolum­nie prze­cho­wu­ją­cej dane (doku­men­ty). Jest to baza prze­cho­wu­ją­ca dane w for­ma­cie JSON, więc ich inter­pre­ta­cja wyma­ga defi­ni­cji kon­kret­nej struk­tu­ry danych. dodat­ko­wa kolum­na (SortKey) peł­ni rolę defi­ni­cji typu (iden­ty­fi­ka­tor struk­tu­ry). Jest to wygod­ne bo w sys­te­mach obiek­to­wych łatwo defi­niu­je się typy zło­żo­ne, nada­jąc każ­de­mu rekor­do­wi dodat­ko­wy iden­ty­fi­ka­tor, moż­na inte­pre­to­wać pobra­ne dane. 

(https://​aws​.ama​zon​.com/​b​l​o​g​s​/​d​a​t​a​b​a​s​e​/​c​h​o​o​s​i​n​g​-​t​h​e​-​r​i​g​h​t​-​d​y​n​a​m​o​d​b​-​p​a​r​t​i​t​i​o​n​-​k​ey/)

Więcej infor­ma­cji o repo­zy­to­riach Amazon, tak­że Amazon S3 (bar­dzo szyb­ka baza pli­ków) znaj­dzie­cie w książ­ce wydaw­nic­twa Helion: Amazon Web Services . Analogiczne roz­wią­za­nie ofe­ru­je AZURE.

Na zakończenie

Osobiście pole­cam roz­wa­że­nie opi­sa­nych tu roz­wią­zań w swo­ich pro­jek­tach. W obsza­rze doku­men­tów i zarzą­dza­nia ich tre­ścią są wręcz dosko­na­łe. Model rela­cyj­ny, dosko­na­ły do obli­czeń, nie­ste­ty prze­gry­wa z kre­te­sem w apli­ka­cjach biz­ne­so­wych, gdzie zaczy­na się liczyć przede wszyst­kim szyb­kość dostę­pu do ogrom­nej ilo­ści danych oraz odpor­ność na szyb­ko zmie­nia­ją­ce się wyma­ga­nia co do struk­tu­ry danych.

Problem pro­jek­to­wa­nia struk­tur doku­men­tów, tak­że w bazach doku­men­to­wych, to osob­ne i trud­ne zagad­nie­nie. Opisałem go w naj­now­szym arty­ku­le, któ­ry uka­że się za nie­dłu­go w wydaw­nic­twie IGI Global: Emerging Challenges, Solutions, and Best Practices for Digital Enterprise Transformation.

C.d. czy­taj Bazy NoSQL jako imple­men­ta­cje wzor­ców struk­tur infor­ma­cji.

Źródła

Harley Vera, Wagner Boaventura, Maristela Holanda, Valeria Guimaraes, & Fernanda Hondo. (2015). Data Modeling for NoSQL Document-Oriented Databases. CEUR Workshop Proceedings, 1478, 129 – 135.
Garba, M. (2020). A Comparison of NoSQL and Relational Database Management Systems (RDBMS). 1(2), 9.
Gyorödi, C., Gyorödi, R., & Sotoc, R. (2015). A Comparative Study of Relational and Non-Relational Database Models in a Web- Based Application. International Journal of Advanced Computer Science and Applications, 6(11). https://​doi​.org/​1​0​.​1​4​5​6​9​/​I​J​A​C​S​A​.​2​0​1​5​.​0​6​1​111
Wilkins, M. (2020). Amazon Web Services: pod­sta­wy korzy­sta­nia z chmu­ry AWS (J. Zatorska, Trans.). Helion SA.
Guimaraes, V., Hondo, F., Almeida, R., Vera, H., Holanda, M., Araujo, A., Walter, M. E., & Lifschitz, S. (2015). A stu­dy of geno­mic data pro­ve­nan­ce in NoSQL docu­ment-orien­ted data­ba­se sys­tems. 2015 IEEE International Conference on Bioinformatics and Biomedicine (BIBM), 1525 – 1531. https://​doi​.org/​1​0​.​1​1​0​9​/​B​I​B​M​.​2​0​1​5​.​7​3​5​9​902
Smith, B. C. (1985). The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18 – 26. https://​doi​.org/​1​0​.​1​1​4​5​/​3​7​9​4​8​6​.​3​7​9​512

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.

Ten post ma 8 komentarzy

  1. Paweł Dąbrowski

    Ciekawy arty­kuł. Nie mam pytań co do zasad­ni­czej czę­ści arty­ku­łu, nato­miast do rys. 8.
    Relacje zależ­no­ści wska­zu­ją rela­cję CLIENT/SUPPLIER, któ­ra suge­ru­je, że jeże­li zmie­ni się SUPPLIER to MOŻE (ale nie musi) zmie­nić się CLIENT.
    1. Jaka jest inten­cja zasto­so­wa­nia tej rela­cji pomię­dzy Domain User” a <> Faktury i <> Karty Produktów? Czy nie wystar­czy­ła­by rela­cja asocjacji?
    2. Czy rela­cja uży­cia pomię­dzy Faktury, Karty Produktów nie suge­ru­je, że te kla­sy­fi­ka­to­ry zale­żą od Archiwum doku­men­tów i poten­cjal­nie, jeże­li zmie­ni się archi­wum to MOGĄ się też one zmie­nić (a chy­ba powin­ny być nie­za­leż­ne od archiwum).
    3. W przy­pad­ku Archivist” rela­cja zależ­no­ści wyda­je się mieć sens, w tym duchu, że jeże­li zmie­nia­my archi­wum doku­men­tów z AMAZON na AZURE to sam archwii­sta musi się zmie­nić”, tzn. nauczyć nowe­go narzę­dzia, stro­ny, API itp.
    Z góry dzię­ku­ję za odpowiedzi.

  2. Najpierw klu­czo­wa zasa­da: nie rela­cja a zwią­zek ;). W UML i obiek­to­wym para­dyg­ma­cie co do zasa­dy mówi­my o współ­pra­cy (inte­rak­cja), a to ozna­cza że CLIENT/SUPPLIER to USŁUGOBIORCA/USŁUGODAWCA. Innymi sło­wy obiekt CLIENT wywo­łu­je ope­ra­cje obiek­tu SUPPLIER. Nie ma tu mowy o jakim­kol­wiek zmie­nia­niu cze­go­kol­wiek: nie jest praw­dą, że zwią­zek zależ­no­ści ozna­cza prze­no­sze­nie zmian z obiek­tu na obiekt. Tak więc zda­nie Relacje zależ­no­ści wska­zu­ją rela­cję CLIENT/SUPPLIER, któ­ra suge­ru­je, że jeże­li zmie­ni się SUPPLIER to MOŻE (ale nie musi) zmie­nić się CLIENT.” nie­ste­ty nie jest praw­dą, zwią­zek zależ­no­ści nicze­go takie­go nie sugeruje. 

    W UML związ­ki uży­cia (zależ­ność ozna­czo­na «use») ozna­cza­ją wyłącz­nie wywo­ły­wa­nie ope­ra­cji obiek­tu, na któ­ry wska­zu­je grot strzał­ki, a nie że jak się coś zmie­ni u dostaw­cy to tak­że u klien­ta”. Niestety ogrom­na licz­ba auto­rów lite­ra­tu­ry dot. UML inter­pre­tu­je poję­cie kla­sy i atry­bu­tów jako związ­ki zna­ne z rela­cyj­nych sys­te­mów baz danych, co jest kom­plet­nym nie­po­ro­zu­mie­niem i nie jest praw­dą (każ­da książ­ka zawie­ra­ją­ca choć­by suge­stię, że dia­gra­my klas słu­żą lub mogą słu­żyć, do mode­lo­wa­nia danych nada­je się wyłącz­ne na śmiet­nik). Związek zależ­no­ści ze ste­reo­ty­pem «use» na mode­lu archi­tek­tu­ry (dia­gra­mie klas lub kom­po­nen­tów), repre­zen­tu­je wyłącz­nie wywo­ła­nia ope­ra­cji inter­fej­su na dia­gra­mach sekwen­cji i dia­gra­mach komu­ni­ka­cji. Związek zależ­no­ści bez ste­reo­ty­pu «use» ozna­cza ogól­nie korzy­sta­nie z..” bez wni­ka­nia w cel i meto­dy użycia.

    I teraz:
    1. Aktor Domain user ma do dys­po­zy­cji (korzy­sta z) doku­men­tów typu Faktury i Karty produktów.
    2. nigdzie nie ma na tym dia­gra­mie rela­cji uży­cia pomię­dzy Faktury, Karty Produktów”
    3. aktor Archivist korzy­sta bez­po­śred­nio (ma taka moż­li­wość) z Archiwum doku­men­tów (nie ma to nic wspól­ne­go z AZURE czy AMAZON).

    Co więc mamy na dia­gra­mie 8?
    1. doku­men­to­we repo­zy­to­rium zawie­ra­ją­ce obiek­ty kla­sy Dokument, są to pary ID-string (czy­li [klucz]-[treść doku­men­tu], tu nie ma zna­cze­nia czy jest to baza key-value czy dokumentowa)
    2. repo­zy­to­rium doku­men­to­we z zasa­dy nie prze­twa­rza ich tre­ści (pomi­jam sam fakt wyszu­ki­wa­nia w bazach doku­men­to­wych), słu­ży wyłącz­nie to utrwa­la­nia tre­ści i jej pobierania
    3. Dziedzinowe reje­stry, Faktury i Karty Produktów, zawie­ra­ją klu­czo­we atry­bu­ty (meta­da­ne) doku­men­tów każ­de­go z tych typów oraz kucz (ID) pozwa­la­ją­cy pobrać tak zna­le­zio­ny doku­ment z bazy doku­men­to­wej, gdyż tu Dziedzinowe reje­stry nie zawie­ra­ją doku­men­tów, a jedy­nie odno­śni­ki do nich w Archiwum doku­men­tów (bo tu są fizycz­nie składowane).

    Rysunek 8. pocho­dzi z mojej publi­ka­cji w IGI Global gdzie jest wię­cej na ten temat.

  3. Paweł Dąbrowski

    Faktycznie rela­cja to złe okre­śle­nie. To jest rela­tion­ship”, czy­li zwią­zek. Teraz już zapamiętam :).

    Nie jestem prze­ko­na­ny co do cał­ko­wi­tej nie­praw­dzi­wo­ści tego co napi­sa­łem, bo w spe­cy­fi­ka­cji UML mamy:
    roz­dział 7.7.1 – A Dependency signi­fies a supplier/client rela­tion­ship betwe­en model ele­ments whe­re the modi­fi­ca­tion of a sup­plier may impact the client model elements.”.
    rodział 7.7.3.1. – A Dependency implies that the seman­tics of the clients are not com­ple­te witho­ut the suppliers.”.
    Nie napi­sa­łem, że na pew­no się zmie­ni, tyl­ko, że może – zgod­nie ze spe­cy­fi­ka­cją jak się wyda­je. MAY impact” the client model ele­ments. Jeżeli ma wpływ to zna­czy, że coś się może zmie­nić pod tym wpływem.

    Co wię­cej powyż­sze ozna­cza moim zda­niem, że zwią­zek rela­cji powi­nien być sto­so­wa­ny do impact analysis”.

    I zno­wu jak wyżej co do związ­ku uży­cia – jeże­li ope­ra­cja zmie­nia np. swo­je argu­men­ty to rów­nież musi się zmie­nić client, któ­ry tą ope­ra­cję wywo­łu­je. Jeżeli doda­je­my nową ope­ra­cję, to klient rów­nież może ją wyko­rzy­stać, chodź nie musi. Oczywiście w samym UML jest: 7.8.23.1 A Usage is a Dependency in which the client Element requ­ires the sup­plier Element (or set of Elements) for its full imple­men­ta­tion or ope­ra­tion”, co nie potwier­dza bez­po­śred­nio tej tezy, ale wyda­je się naturalne.

    Związek zależ­no­ści bez ste­reo­ty­pu ?use? ozna­cza ogól­nie ?korzy­sta­nie z..? bez wni­ka­nia w cel i meto­dy uży­cia.”. To się zga­dza, ale czy to wyklu­cza powyż­sze i ana­li­zę wpływu?

    Ad 2. Przepraszam, cho­dzi­ło mi o zwią­zek uży­cia pomię­dzy Faktury a Archiwum doku­men­tów i Karty pro­duk­tów a Archiwum doku­men­tów. Wracając do AZURE czy AMAZON – osta­tecz­nie jeden lub dru­gi może być archi­wum takich doku­men­tów? Tzn. gdzieś w naszym mode­lu osta­tecz­nie zosta­nie wybra­ne kon­kret­ne archi­wum doku­men­tów. A pobra­nie doku­men­tu z jed­ne­go czy dru­gie­go może wyglą­dać ina­czej, chodź nie znam tych technologii :).

    1. Zdanie modi­fi­ca­tion of a sup­plier may impact the client” ozna­cza, że jeże­li efekt (wynik) pra­cy kom­po­nen­tu CLIENT zale­ży od efek­tu (wyni­ku) pra­cy kom­po­nen­tu SUPPLIER, to zmo­dy­fi­ko­wa­nie tego dru­gie­go może sie odbić na pierw­szym, ale to dla­te­go para­dyg­mat obiek­to­wy ope­ru­je poję­ciem poli­mor­fi­zmu: zmia­na meto­dy nie może wpły­nąć na jej pro­dukt. Analiza wpły­wu pole­ga wyłącz­nie na spraw­dze­niu czy zmia­na kom­po­nen­tu sys­te­mu wpły­nie na zacho­wa­nie całe­go sys­te­mu, jeże­li tak, to jest to dra­mat pro­jek­tan­ta 😉 a nie zależ­ność ozna­cza­ją­ca taki wpływ” 😉 

      UML to nota­cje uni­wer­sal­na, dla­te­go CO DO ZASADY każ­dy dia­gram MUSI mieć wska­za­nie na kon­tekst, bez tego nie mamy pra­wa inter­pre­to­wa­nia go. W UML gene­ral­nie two­rzo­ne są albo mode­le archi­tek­tu­ry okre­ślo­ne­go sys­te­mu (lub typu sys­te­mu) albo mode­le poję­cio­we. Dlatego sama nazwa dia­gram klas” nic nie zna­czy. Albo jest to archi­tek­tu­ra sys­te­mu (jego kom­po­nen­ty) albo model poję­cio­wy (name­spa­ce).

      Przypominam, że rela­tion­ship” i rela­tion” w j. angiel­skim ma nie­co inne (szer­sze) znacz­nie niż rela­cja” w języ­ku pol­skim, Relation” jest to zwią­zek mate­ma­tycz­ny (iden­tycz­nie inte­pre­to­wa­ny w rela­cyj­nych” mode­lach danych). UML bazu­je na poję­ciu aso­cja­cja (zwią­zek). Relationship” jest rozu­mia­ne jako współ­ist­nie­nie”.

      Pisze Pan:

      Oczywiście w samym UML jest: 7.8.23.1 ?A Usage is a Dependency in which the client Element requ­ires the sup­plier Element (or set of Elements) for its full imple­men­ta­tion or ope­ra­tion?, co nie potwier­dza bez­po­śred­nio tej tezy, ale wyda­je się naturalne. 

      Niestety nie jest natu­ral­ne. Związek uży­cia ma bar­dzo pre­cy­zyj­na defi­ni­cję; jest to tyl­ko i wyłącz­nie wywo­ły­wa­nie ope­ra­cji inne­go kom­po­nen­tu. Pojęcie ana­li­zy wpły­wu nie jest poję­ciem UML. W UML poję­cie zależ­no­ści nie jest tym czym sło­wo zależ­ność” w języ­ku pol­skim. W języ­ku pol­skim jest praw­dą, że pod­wład­ny zale­ży od prze­ło­żo­ne­go, w UML byśmy napi­sa­li prze­ło­żo­ny jest zależ­ny od pod­wład­ne­go” dla­te­go, że efek­ty pra­cy dzia­łu księ­go­wo­ści (czy­li jego sze­fa tak­że) są zależ­ne od efek­tów pra­cy pra­cow­ni­ków tego dzia­łu. I to jest klu­czo­wa róż­ni­ca, na któ­rą łapie” sią wie­lu ludzi. Bo to JA (CLIENT) uży­wam (zwią­zek «use») odku­rza­cza (SUPPLIER), żeby posprzą­tać miesz­ka­nie, i ja zale­żę” od tego odku­rza­cza (a nie odku­rzacz ode mnie), bo jak odku­rzacz sła­bo cią­gnie, to JA źle odku­rzy­łem miesz­ka­nie, i to MNIE oce­ni rodzi­na za nie­do­kład­nie odku­rze­nie miesz­ka­nie. Jakakolwiek zmia­na kon­struk­cji odku­rza­cza NIE MA PRAWA wpły­nąć na moje zacho­wa­nie, bo kupu­jąc odku­rzacz zawie­ram kon­trakt (inter­fejs) że on odku­rza ;), kon­struk­cja odku­rza­cza nie ma pra­wa wpły­wać na to, że on ODKURZA (poli­mor­fizm).

      Pomiędzy UML a rela­cja­mi w SQL jest prze­paść, i nie ma tu abso­lut­nie żad­nej ana­lo­gii. Niestety wie­lu ludzi, tro­pem sta­rych ksią­żek na temat EJB (Enterprise Java Beans), brnie w ane­micz­ne mode­le dzie­dzi­ny i dia­gra­my klas jako mode­le danych. 

      AZURE i AMAZON to repo­zy­to­ria, nazy­wa­ne są cza­sa­mi obiek­to­wy­mi bo obie te plat­for­my udo­stęp­nia­ją API, czy­li dla użyt­kow­ni­ka są czar­ną skrzyn­ką”. To API na ope­ra­cję ZAPISZ i OCZYTAJ, para­me­trem jest iden­ty­fi­ka­tor zapi­sy­wa­ne­go obiek­tu, a tym obiek­tem może być plik zdję­cie, plik XML/JSON, cokol­wiek. Repozytoria z zasa­dy nie reali­zu­ją­ca żad­nej logi­ki biz­ne­so­wej (pole­cam: Evans, E. (2003). Domain-Driven Design. Pearson Education (US).).

      Miłą cechą UML/obiektowości jest to, że na eta­pie pro­jek­to­wa­nia nie ma żad­ne­go zna­cze­nia czym będzie to repo­zy­to­rium. Ale nie­wąt­pli­wie pomię­dzy apli­ka­cją a repo­zy­to­rium jest zwią­zek zależ­no­ści «use» wska­zu­ją­cy strzał­ką na repo­zy­to­rium (czy­li na jego inter­fejs). Dlatego pobra­nie doku­men­tu z obu tych repo­zy­to­riów MUSI wyglą­dać identycznie ;).

  4. Paweł Dąbrowski

    * Co wię­cej powyż­sze ozna­cza moim zda­niem, że zwią­zek ZALEŻNOŚCI powi­nien być sto­so­wa­ny do ?impact analysis?.

    1. Związek zależ­no­ści” nie ma pra­wa być uży­wa­ny do ana­li­zy zależ­no­ści (wpły­wu) bo ozna­cza zależ­ność” a nie wpły­wa­nie na coś” 😉 co nie jest tym samym. UML powstał na bazie obiek­to­we­go para­dyg­ma­tu, a ten defi­niu­je­my jako współ­dzia­ła­nie”: są to więc luź­no powią­za­ne kom­po­nen­ty wywo­łu­ją­ce swo­je usłu­gi. Ale to pro­jek­tant sys­te­mu decy­du­je jako to obmy­śli”.

      I gene­ral­nie: UML ma spe­cy­fi­ka­cje, nie wol­no mu dora­biać dodat­ko­wych natu­ral­nych” inter­pre­ta­cji ;). I nie przy­pad­kiem w UML ta zależ­ność nazy­wa się depen­den­cy” a nie o impact”. 😉

  5. Paweł Dąbrowski

    Dziękuję za wyjaśnienia. 

    Zakupiłem publi­ka­cję w IGI Global. Jaka jest naj­lep­sza for­ma komu­ni­ka­cji w przy­pad­ku pytań do samej publikacji?

    1. Generalnie, w kwe­stii publi­ka­cji nauko­wych, jest taka zasa­da, że wszę­dzie tam gdzie autor podał ema­il jest to zapro­sze­nie (otwar­tość) na dys­ku­sje. Jeżeli podał tyl­ko imię nazwi­sko i miej­sce afi­lia­cji (macie­rzy­sty insty­tut, uczel­nia, itp.) pisze­my do nie­go na adres tej jednostki.

Dodaj komentarz

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