Ten post ma 8 komentarzy

1. 

   Paweł Dąbrowski 2 kwietnia 2021 Odpowiedz

   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. 

   Jarosław Żeliński 2 kwietnia 2021 Odpowiedz

   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 8 kwietnia 2021 Odpowiedz

   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. 

      Jarosław Żeliński 8 kwietnia 2021

      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 8 kwietnia 2021 Odpowiedz

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

      Jarosław Żeliński 8 kwietnia 2021

      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 8 kwietnia 2021 Odpowiedz

   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. 

      Jarosław Żeliński 8 kwietnia 2021

      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.

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