Temat: pojekt portalu imprezowego

Na początek uwaga: wymieniamy się postrzeganiem diagramu i problemu, nie jest absolutnie dyskusja "co jest prawdziwe i jedynie słuszne".

Artur Kęska:
Ogólnie z tego Co Pan tu pisze wynika, że najlepszy był pierwszy diagram (pomijając chęć posiadania metod). Mi na tym pierwszym diagramie przeszkadzała jednak gęsta sieć powiązań, oraz brak wyraźnych odpowiedzialności za trwałość obiektów. Ale na to nikt nie zwrócił dotychczas uwagi więc może to nikomu nie przeszkadza.

Nic takiego nie powiedziałem, gęsta sieć powiązań raczej czyni go złym diagramem.

Jarek Żeliński:
Usunięcie użytkownika powoduje zniknięcie wszystkiego poza eventem.

Hmm, może ale jak Pan to wykoncypował, zaiste zagadka...

Usuwając użytkownika usuniemy wszystko co jest z nim w kompozycji. Pozostanie tylko Event i to z nim zagregowano.

Jest pewna niekonsekwencja zasady wedle której wiedza o czymś jest zamykana w jednym obiekcie: galeria jest elementem eventu, nie rozumiem dlaczego galeria dziedziczy (i co?) z tabeli komentarzy (dziedziczenie oznacza specjalizację),

Z diagramu poprzednika wynika, że zarówno obiekty Event Galeria jak i Photo mogą być komentowane, oraz należą do do jakiegoś użytkownika.

Nadal nie wiem dlaczego Event, Gallery i Photo jest szczególnym przypadkiem CommentTable.

Wygląda więc na to że warto te cechy pokazać jako wspólne, z czego przynajmniej relacja posiadania przez

Relacja to cecha baz relacyjnych a nie systemów obiektowych.

Jeżeli tablica komentarzy zarządza komentarzami to "jakim prawem" pozwalamy użytkownikowi "obejść" posiadacza tych danych i dajemy mu komentarze "na skróty".

Wręcz przeciwnie. Skoro użytkownik wystawia komentarze to pewnie jest też ich właścicielem.

To łamie zasadę dobrego projektowania obiektowego: jedna odpowiedzialność w jednym miejscu. Jeżeli User chce się dowiedzieć co napisał rok temu prosi o to Commenttable.

Ten diagram nadal nie jest obiektowy moim zdaniem,

Ojj, zabolało...

jak wyżej...

to jest kolejna próba wcielenia modelu danych lub jakiegoś modelu pojęciowego.

Mam szczerą nadzieję, że się pan z tych słów wycofa.

Raczej nie :), uwagi jak wyżej :).

Diagram klas jako narzędzie może opisywać zarówno model pojęciowy jak model jakiejś rzeczywistości odwzorowywanej (modelowanej) w kodzie.

Od modelu dziedziny do kodu jeszcze daleka droga.

Jak dla kogo, w najpopularniejszym wzorcu MVC model dziedziny i model kodu są od strony koncepcji wręcz tożsame.
Więcej o tym tu:
http://it-consulting.pl/autoinstalator/wordpress/index...

jest tam także odnośnik do obszernego artykułu na MSDN na ten temat.

Jeżeli mogę sobie wyobrazić jakie atrybuty w tych klasach tak nijak nie przychodząc mi do głowy metody.

Nie wierzę, że Pan nie umie. Podpuszcza mnie Pan :-)

Domysły zabijają projekty, przykłady, przykłady :)

Proponuje rozważenie kolejnej rzeczy: jeżeli mówimy o diagramie klas w kontekście oprogramowania obiektowego to jeżeli kompozycja ma głęboki sens tak agregacja traci go zupełnie bo nie ma odpowiednika rzeczywistości modelowanej.

Ma. Wynikają z niej odpowiedzialności klas.

Odpowiedzialności klas to ich interfejs czyli metody a nie atrybuty, zwracam uwagę, że wszelkie asocjacje (a są nimi także kompozycja i agregacja) to atrybuty klas a nie ich metody.

Co do zasady zgoda. Ale..
Kto powiedział, że implementacja ma być w hibernate?

Nikt i nie ma tu o tym mowy...

A nawet gdyby to akurat z tym konkretnym diagramem nie było by raczej kłopotu. Poza tym chyba mowa była o modelu dziedziny a nie diagramie klas.

każdy z tych diagramów to diagram klas: model kodu obiektowego, model dziedziny czy model taksonomii (związków pojęciowych) to diagramy klas.

Polecam gorąco karty CRC, jako narzędzie analizy (która powinna poprzedzać projektowanie) są doskonałe.

Na koniec: zanim narysujemy jakikolwiek diagram należy go opisać:
1. co modeluje
2. jaką pragmatykę stosujemy (w tym wzorce, metafory itp.)

bez tych dwóch ustaleń nawet ta dyskusje jest "lekko" bezprzedmiotowa bo bez tych ustaleń można uznać, że każdy ma rację.

Ja nie ukrywam, że w kwestii pragmatyki stosuję standardowe wzorce obiektowe (Go4), zasadę projektowania poprzez kontrakty, zamykanie konkretnej wiedzy i odpowiedzialności w jednaj klasie i pewnie kilka innych.

Tak więc uwaga dla każdego kto modeluje z pomocą diagramów (nie tylko UML): opisz co model modeluje i jaką pragmatykę zastosowano. Pragmatykę pomocniczo można opisać z pomocą metafory lub kilku metafor.Jarek Żeliński edytował(a) ten post dnia 02.02.11 o godzinie 10:25

Temat: pojekt portalu imprezowego

Jarek Żeliński:
Na początek uwaga: wymieniamy się postrzeganiem diagramu i problemu, nie jest absolutnie dyskusja "co jest prawdziwe i jedynie słuszne".

Zgoda. Staram się jedynie przedstawić nieco inny punkt widzenia i obronić swoją wizję. Z resztą może mi Pan wierzyć lub nie, czytam Pana teksty z dużym zainteresowaniem.

Przepraszam nie ustosunkuję się do wszystkich uwag, jedyne co rzuciło mi się w oczy to to że odczytał Pan Commentable jako CommentTable. Mój błąd w słowie jest literówka (na diagramie napisałem Cometable.
Mam taki zwyczaj, że jeżeli słowo nazwa klasyfikatora składa się z dwóch członów zapisuję ją z kapitalizacją. Natomiast posfix "able" używam aby pokazać że klasyfikator dostarcza jakiegoś interfejsu do zarządzania jej/lub potomka stanem (Iterable, Browsable bo ja wiem Readable).
W sumie ciekawe, że pan tak to odczytał.

Nie zgadzam się też z twierdzeniem, że relacja nie wpływa na odpowiedzialność klasy.
Jeżeli relacja jest kompozycją (wypełniony rąb) wówczas klasa odpowiada za usuwanie komponowanych obiektów.
Jeżeli relacja jest agregacją, wówczas obiekty żyją od siebie niezależnie.
Uważam też (i z tego co widzę Pan również), że każda klasa powinna być przez kogoś komponowana. Inaczej nie ma pewności czy kiedyś zostanie usunięta z systemu (CRUD).

Poza tym, jak by na to nie patrzeć obiekty żyją w pewnych relacjach między sobą. Uważam, że to że tego słowa użyto do opisu pewnej klasy baz danych nie sprawia że tylko tam istnieją relacje. Z resztą Generalizacja jest też typem relacji, a w relacyjnych bazach danych raczej nie występuje.

Artur Kęska:
Ogólnie z tego Co Pan tu pisze wynika, że najlepszy był pierwszy diagram (pomijając chęć posiadania metod). Mi na tym pierwszym diagramie przeszkadzała jednak gęsta sieć powiązań, oraz brak wyraźnych odpowiedzialności za trwałość obiektów. Ale na to nikt nie zwrócił dotychczas uwagi więc może to nikomu nie przeszkadza.

Nic takiego nie powiedziałem, gęsta sieć powiązań raczej czyni go złym diagramem.

Jarek Żeliński:
Usunięcie użytkownika powoduje zniknięcie wszystkiego poza eventem.

Hmm, może ale jak Pan to wykoncypował, zaiste zagadka...

Usuwając użytkownika usuniemy wszystko co jest z nim w kompozycji. Pozostanie tylko Event i to z nim zagregowano.

Jest pewna niekonsekwencja zasady wedle której wiedza o czymś jest zamykana w jednym obiekcie: galeria jest elementem eventu, nie rozumiem dlaczego galeria dziedziczy (i co?) z tabeli komentarzy (dziedziczenie oznacza specjalizację),

Z diagramu poprzednika wynika, że zarówno obiekty Event Galeria jak i Photo mogą być komentowane, oraz należą do do jakiegoś użytkownika.

Nadal nie wiem dlaczego Event, Gallery i Photo jest szczególnym przypadkiem CommentTable.

Wygląda więc na to że warto te cechy pokazać jako wspólne, z czego przynajmniej relacja posiadania przez

Relacja to cecha baz relacyjnych a nie systemów obiektowych.

Jeżeli tablica komentarzy zarządza komentarzami to "jakim prawem" pozwalamy użytkownikowi "obejść" posiadacza tych danych i dajemy mu komentarze "na skróty".

Wręcz przeciwnie. Skoro użytkownik wystawia komentarze to pewnie jest też ich właścicielem.

To łamie zasadę dobrego projektowania obiektowego: jedna odpowiedzialność w jednym miejscu. Jeżeli User chce się dowiedzieć co napisał rok temu prosi o to Commenttable.

Ten diagram nadal nie jest obiektowy moim zdaniem,

Ojj, zabolało...

jak wyżej...

to jest kolejna próba wcielenia modelu danych lub jakiegoś modelu pojęciowego.

Mam szczerą nadzieję, że się pan z tych słów wycofa.

Raczej nie :), uwagi jak wyżej :).

Diagram klas jako narzędzie może opisywać zarówno model pojęciowy jak model jakiejś rzeczywistości odwzorowywanej (modelowanej) w kodzie.

Od modelu dziedziny do kodu jeszcze daleka droga.

Jak dla kogo, w najpopularniejszym wzorcu MVC model dziedziny i model kodu są od strony koncepcji wręcz tożsame.
Więcej o tym tu:
http://it-consulting.pl/autoinstalator/wordpress/index...

jest tam także odnośnik do obszernego artykułu na MSDN na ten temat.

Jeżeli mogę sobie wyobrazić jakie atrybuty w tych klasach tak nijak nie przychodząc mi do głowy metody.

Nie wierzę, że Pan nie umie. Podpuszcza mnie Pan :-)

Domysły zabijają projekty, przykłady, przykłady :)

Proponuje rozważenie kolejnej rzeczy: jeżeli mówimy o diagramie klas w kontekście oprogramowania obiektowego to jeżeli kompozycja ma głęboki sens tak agregacja traci go zupełnie bo nie ma odpowiednika rzeczywistości modelowanej.

Ma. Wynikają z niej odpowiedzialności klas.

Odpowiedzialności klas to ich interfejs czyli metody a nie atrybuty, zwracam uwagę, że wszelkie asocjacje (a są nimi także kompozycja i agregacja) to atrybuty klas a nie ich metody.

Co do zasady zgoda. Ale..
Kto powiedział, że implementacja ma być w hibernate?

Nikt i nie ma tu o tym mowy...

A nawet gdyby to akurat z tym konkretnym diagramem nie było by raczej kłopotu. Poza tym chyba mowa była o modelu dziedziny a nie diagramie klas.

każdy z tych diagramów to diagram klas: model kodu obiektowego, model dziedziny czy model taksonomii (związków pojęciowych) to diagramy klas.

Polecam gorąco karty CRC, jako narzędzie analizy (która powinna poprzedzać projektowanie) są doskonałe.

Na koniec: zanim narysujemy jakikolwiek diagram należy go opisać:
1. co modeluje
2. jaką pragmatykę stosujemy (w tym wzorce, metafory itp.)

bez tych dwóch ustaleń nawet ta dyskusje jest "lekko" bezprzedmiotowa bo bez tych ustaleń można uznać, że każdy ma rację.

Zgoda. Tylko, że to lista dyskusyjna. Trudno mi powiedzieć które zasady można pominąć a które nie, jednak z braku czasu pozostawiam nieco niedomówień.

Ja nie ukrywam, że w kwestii pragmatyki stosuję standardowe wzorce obiektowe (Go4), zasadę projektowania poprzez kontrakty, zamykanie konkretnej wiedzy i odpowiedzialności w jednaj klasie i pewnie kilka innych.

Tak więc uwaga dla każdego kto modeluje z pomocą diagramów (nie tylko UML): opisz co model modeluje i jaką pragmatykę zastosowano. Pragmatykę pomocniczo można opisać z pomocą metafory lub kilku metafor.Jarek Żeliński edytował(a) ten post dnia 02.02.11 o godzinie 10:25

Temat: pojekt portalu imprezowego

Artur Kęska:

Jarek Żeliński:
Na początek uwaga: wymieniamy się postrzeganiem diagramu i problemu, nie jest absolutnie dyskusja "co jest prawdziwe i jedynie słuszne".

Zgoda. Staram się jedynie przedstawić nieco inny punkt widzenia i obronić swoją wizję.

i o to chodzi :)

Z resztą może mi Pan wierzyć lub nie, czytam Pana teksty z dużym zainteresowaniem.

miło mi i ciesze się :)

Przepraszam nie ustosunkuję się do wszystkich uwag, jedyne co rzuciło mi się w oczy to to że odczytał Pan Commentable jako CommentTable. Mój błąd w słowie jest literówka (na diagramie napisałem Cometable.

OK

Mam taki zwyczaj, że jeżeli słowo nazwa klasyfikatora składa się z dwóch członów zapisuję ją z kapitalizacją. Natomiast posfix "able" używam aby pokazać że klasyfikator dostarcza jakiegoś interfejsu do zarządzania jej/lub potomka stanem (Iterable, Browsable bo ja wiem Readable).

No cóż, jakąś przyjęta konwencją jest dodawania "I" jako pierwsze znaku nazwy interfejsu (w zasadzie interfejs jest abstrakcja implementowaną przez klasy konkretne, ale to kwestia i metody i standardów, np. IKsiązki to interfesj definiujący odpowiedzialność klasy/komponentu Książki

W sumie ciekawe, że pan tak to odczytał.

:)

Nie zgadzam się też z twierdzeniem, że relacja nie wpływa na odpowiedzialność klasy.
Jeżeli relacja jest kompozycją (wypełniony rąb) wówczas klasa odpowiada za usuwanie komponowanych obiektów.

To, że kontener zarządza swoją zawartością jest "oczywiste", pisząc odpowiedzialność mam na myśli całość, np. wyszukanie właściwego składnika (obiektu agregowanego), ciężar wszystkich czerwonych itp.

Jeżeli relacja jest agregacją, wówczas obiekty żyją od siebie niezależnie.

kwestia podejścia :) czym się semantycznie różni agregacja od kompozycji? Skoro obiekt zagregowany i żyje niezależnie to po prostu jest to zwykłą asocjacją - czym się rożni zwykła asocjacja do agregacji?

Poza tym, jak by na to nie patrzeć obiekty żyją w pewnych relacjach między sobą.

i tak i nie, albo dwie kartki są spięte spinaczem i stanowią "względna całość (agregacja) albo leżą luźno i ja wiem co je łączy wtedy nie są ze sobą w żadnej relacji - to ja wiem (klasa zarządzająca) co je łączy (np. ten sam NIP kontrahenta).

Uważam, że to że tego słowa użyto do opisu pewnej klasy baz danych nie sprawia że tylko tam istnieją relacje.

ja dla odmiany pilnuje tego by nie powodować nieporozumień do którego właśnie doszło.

Z resztą Generalizacja jest też typem relacji, a w relacyjnych bazach danych raczej nie występuje.

Generalizacja jest związkiem pomiędzy uogólnieniem a specjalizacją.

Na koniec: zanim narysujemy jakikolwiek diagram należy go opisać:
1. co modeluje
2. jaką pragmatykę stosujemy (w tym wzorce, metafory itp.)

bez tych dwóch ustaleń nawet ta dyskusje jest "lekko" bezprzedmiotowa bo bez tych ustaleń można uznać, że każdy ma rację.

Zgoda. Tylko, że to lista dyskusyjna. Trudno mi powiedzieć które zasady można pominąć a które nie, jednak z braku czasu pozostawiam nieco niedomówień.

jak widać, określenie metodyki, stylu, standardów i wzorców projektowych to podstawa sprawnej komunikacji,

Dlatego warto przed diagramem napisać co on pokazuje, ta dyskusja pokazuje jak "niepewność" używanych pojęć oraz rożne style czy metody projektowania potrafią "zmylić" czytającego...Jarek Żeliński edytował(a) ten post dnia 02.02.11 o godzinie 17:21

Temat: pojekt portalu imprezowego

Jarek Żeliński:
Dlatego warto przed diagramem napisać co on pokazuje, ta dyskusja pokazuje jak "niepewność" używanych pojęć oraz rożne style czy metody projektowania potrafią "zmylić" czytającego...Jarek Żeliński edytował(a) ten post dnia 02.02.11 o godzinie 17:21

No to są święte słowa.
Problem polega na tym, że w zasadzie nie ma jednego standardu. Już sam przykład z dodawaniem I na początku nazwy interfejsu. Jedni mówią dodawać (np M$ o ile się nie mylę) inni mówią, nie. Ja jestem z tej drugiej szkoły.
Moja niechęć do tej konwencji wynika z historii. Mianowicie kiedyś istniała (dla języka C++) konwencja mówiąca aby Klasy zaczynać od C interfejsy od I a zmienne (karamba) od ich typu (np. psz - pointer string zero terminated). Była (i jest nadal przez niektóre kręgi wyznawana) to tzw notacja węgierska (za co Węgrzy do dziś się wstydzą).
Był to niezły koszmarek, szczególnie w czasach kiedy narzędzia programistyczne nie obsługiwały w tak zaawansowany sposób refactoringu.
Mam takie poczucie, że w UML dodawanie "I" jako przedrostka nazwy interfejsu jest szczególnie nie wskazana, ponieważ już sama prezentacja graficzna różni się od klasy czy klasy abstrakcyjnej w sposób wystarczający.

kwestia podejścia :) czym się semantycznie różni agregacja od kompozycji?
Skoro obiekt zagregowany i żyje niezależnie to po prostu jest to zwykłą
asocjacją - czym się rożni zwykła asocjacja do agregacji?

I tu mnie pan ma :-)
Z tym, że akurat mam dokładnie odwrotne odczucia. Otóż o ile asocjacja ma jakiś sens na modelu, o tyle nie ma za bardzo odwzorowania w kodzie. Ja to widzę tak: agregować można poprzez np stworzenie referencji lub wskaźnika danej klasy w klasie agregującej. Podobnie sprawa ma się z Kompozycją, z tym że "Kompozytor" powinien jeszcze zadbać o stworzenie i usunięcie "Komponentów".
Natomiast jeżeli chodzi o asocjacje to mam duże opory bo tak na chłopski rozum - w jaki sposób dwa obiekty mają się do siebie odwoływać skoro ani jeden ani drugi nie jest właścicielem? W zasadzie należało by to implementować jako agregacje z rąbami na obu końcach.

Temat: pojekt portalu imprezowego

Artur Kęska:
Problem polega na tym, że w zasadzie nie ma jednego standardu.

w kwestii konwencji tworzenia nazw nie ma znaczenia jaka to konwencja, ważny by jej konsekwentnie przestrzegając w dokumentacji

ponieważ już sama prezentacja graficzna różni się od klasy czy klasy abstrakcyjnej w sposób wystarczający.

??? symbol klasy jest jeden, różnica polega jedynie w przypadku użycia stereotypu <<interfejs>>, na diagramie komponentów dopiero może to być "lizak".

Z tym, że akurat mam dokładnie odwrotne odczucia. Otóż o ile asocjacja ma jakiś sens na modelu, o tyle nie ma za bardzo odwzorowania w kodzie.

asocjacje (są nimi także agregacja i kompozycja) to atrybuty obiektów wiec mając atrybut "związek z innym obiektem" z wartością będaca ID tegoż obiektu mamy to co mamy, rzecz w czym innym: jakie znaczenie w kodzie ma takie połączenie?

Kompozycja ma znaczenie proste: obiekty zagregowane należy zniszczyć razem z niszczonym obiektem agregującym. W sumie w kodzie (projekcie) obiektowym proste asocjacje maja "małe" znaczenie moim zdaniem.

Natomiast jeżeli chodzi o asocjacje to mam duże opory bo tak na chłopski rozum - w jaki sposób dwa obiekty mają się do siebie odwoływać skoro ani jeden ani drugi nie jest właścicielem?

Nie rozumiem pojęcia "obiekt jest właścicielem"...:(

Powyższe dyskusje utleniają mnie, że należy bezwzględnie rozdzielać diagram klas jako model pojęciowy od diagramu klas modelującego implementację.

Temat: pojekt portalu imprezowego

Jarek Żeliński:
Nie rozumiem pojęcia "obiekt jest właścicielem"...:(

Skrót myślowy

Powyższe dyskusje utleniają mnie, że należy bezwzględnie rozdzielać diagram klas jako model pojęciowy od diagramu klas modelującego implementację.

Zgadzam się w na 100%