Temat: pojekt portalu imprezowego

Witam,

Powoli zaczynam uczyć się UMLa oraz używania programów z nim związanych. Widzę że ta grupa służy pomocą - i czytając tematy z niej - widać to.

Wiec tak, mam do zrobienia projekt portalu imprezowego. Krotki opis:

Jest to projekt strony stworzonej dla ludzi uczęszczających na imprezy w klubach. Na stronie będą znajdowały się informacje o imprezach w najlepszych klubach.

Portal zawierac będzie:
1.Miejsca
2.Wydarzenia + galerie
3.Użytkowników

1.Miejsca: Mogą być zgłaszane przez każdego użytkownika, akceptowane przez administratora.
2.Wydarzenia: Mogą byc dodawane przez każdego użytkownika. Użytkownicy mogą dodać się do wydarzenia jako: „wezmą udział”, „może będą”, „nie wybierają sie”. Do wydarzenia każdy może dodać zdjęcia. Zdjęcia dodane przez administratorów są oddzielone od zdjęć użytkowników. Użytkownicy mogą oceniać wydarzenia.
3.Użytkownicy: mogą uzupełnić swój profil o podstawowe dane i zdjęcie. Mogą brać czynny udział w życiu portalu: komentować wydarzenia i zdjęcia, oceniać zdjęcia jak i wydarzenia, dodawać się do wydarzeń, zaznaczać się na zdjęciach. Ponadto każdy użytkownik może zgłaszać miejsca, wydarzenia oraz dodawać zdjęcia. Ponadto do profilu można dodać swoje ulubione miejsca. Użytkownicy mogą między sobą wysyłać wiadomości oraz dodawać siebie do znajomych.
Użytkownicy dzielą się na:
Administratorów – sprawuję władzę nad portalem. Może zmieniać statusy, usuwać i edytować wydarzenia, zdjęcia, miejsca.
Administrator miejsca – sprawuję władzę nad swoim miejscem. Może dodawać, usuwać i edytować swoje wydarzenia, zdjęcia, miejsca. Może wysyłać wiadomość do użytkowników którzy lubią jego miejsce.
Użytkownik normalny – może uzupełnić profil, oceniać, komentować, oglądać zdjęcia.
Gość – Może oglądać wydarzenia oraz częsciowo profile.
Administrator dziedziczy cechy użtykownika normalnego, a użytkownik normalny cechy gościa.

Najpierw zrobilem model dziedziny (zgodnie ze wskazkowkami kolejnosci wykonania pracy - http://www.uml.com.pl/modules/articles/article.php?id=15) -

Mam prosbe o opinie tego modelu? Jest on dobrze wykonany? Jesli nie co moznaby poprawic/zmienic.





Krotki objasnienie like w tym przykladzie dziala jak opinion (nie ma byc ocen tylko like poprostu ze sie podoba/cos lubi).

Z gory dziekuje za pomocGrzegorz Kożuchowski edytował(a) ten post dnia 21.12.10 o godzinie 15:35

Temat: pojekt portalu imprezowego

Na początek pytanie: czy choć przez sekundę wyobraziłeś sobie kod implementujący ten diagram?

Temat: pojekt portalu imprezowego

Jarek Żeliński:
Na początek pytanie: czy choć przez sekundę wyobraziłeś sobie kod implementujący ten diagram?

Wyobrazilem sobie.

Moze troche niewyraznie wyglada(przez opisy strzalek i trudno cos odczytac - ale to kwestia chyba rozlozenia bardziej blokow)

Jednak jesli trzeba to moge opisac krok po kroku jak sobie wyobrazam za pomoca tego diagramu kod implementujacy (aczkolwiek model dziedziny nie ma przedstawiac ogolnego odwzorowania jak ma wygladac nasz projekt? Kod implementujacy tu chyba nie gra wiekszej roli). Postaram sie dzisiaj ten diagram zrobic moze bardziej czytelny (okroje go takze) - bo rzeczywiscie tak na niego patrze z boku i dla osoby ktora go nie robila trudny jest do rozszyfrowania.

Temat: pojekt portalu imprezowego

Grzegorz Kożuchowski:
Jednak jesli trzeba to moge opisac krok po kroku jak sobie wyobrazam za pomoca tego diagramu kod implementujacy (aczkolwiek model dziedziny nie ma przedstawiac ogolnego odwzorowania jak ma wygladac nasz projekt? Kod implementujacy tu chyba nie gra wiekszej roli).

tu pojawia się kwestia wzorców ale, model dziedziny to fragment implementacji, paradoksalnie, implementacja to rozbudowa a nie upraszczanie modelu koncepcyjnego.

Jedną z "dobrych praktyk" analizy obiektowej i projektowania jest zarządzanie odpowiedzialnością klas (komponentów), nawet jeśli sam diagram klas semantycznie i syntaktycznie byłby OK (nie sprawdzałem) to jest to projekt z gatunku "spagetti modeling" dlatego budzi mój opór :)

Postaram sie dzisiaj ten diagram zrobic moze bardziej czytelny (okroje go takze) - bo rzeczywiscie tak na niego patrze z boku i dla osoby ktora go nie robila trudny jest do rozszyfrowania.

sugeruję uwzględnić powyższe uwagi :)

Temat: pojekt portalu imprezowego

Jarek Żeliński:
sugeruję uwzględnić powyższe uwagi :)

Chcialbym bardziej zrozumiec Pana uwagi. W zwiazku z tym postanowilem troche okroic projekt. Zrobilem najpierw model dziedziny dla:

"Jest uzytkownik ktory dodaje komentarze. Sa wydarzenia w ktorych ten uzytkownik moze brac udzial. Kazde wydarzenie moze miec (ale nie musi) komentarze i galerie zdjec. Galeria zdjec sklada sie ze zdjec(moze byc pusta). Zdjecia mozna komentowac"

Ponizej diagram takiej malej aplikacji:





Chcialbym poznac Pana/Wasza opinie na temat tego modelu dziedziny. Co byscie w nim zmienili? Jesli jest ok postaram sie zrobic juz caly projekt.

pozdrawiam i dzieki za pomoc

Temat: pojekt portalu imprezowego

Kilka ogólniejszych uwag:
- poprawność semantyczna i syntaktyczna diagramu
- to co i po co diagram modeluje
to dwa odrębne aspekty, pierwszy językowy, drugi to aspekt modelowania.

Zakładam, że pierwszy jest OK, jednak pozostaje reszta:
- zasadnicze pytanie: co model przedstawia

Model dziedziny czyli co? Model pojęciowy czy model opisujący koncepcję rozwiązania (potem model systemu).....

Model dziedziny jest (domyślnie) kojarzony z wzorcem MVC (tu sugeruje literaturę, nie ma tu miejsca).

Druga sprawa: powszechnie popełniany błąd projektowy to traktowanie modelu dziedziny i diagramu klas jak modelu danych co jest grubym nieporozumieniem, mimo że znam książki, że autor na diagramie klas używa pojęć z dziedziny relacyjnych baz danych np. "klucz główny" - ja to traktuje jako poważne pomylenie pojęć i błąd projektowy. Możliwe, że repozytorium systemu będzie implementowany z pomocą bazy relacyjnej ale po pierwsze nie misi po drugie to nie jest problem modelu obiektowego. (polecam Fowler i antywzorzec "anemiczny model dziedziny").

Na początek ćwiczenie: dopisz choć jedną metodę i jeden atrybut do każdej klasy i niech to nie będzie metoda set lub get :), wtedy będzie widać intencję tworzenia każdej klasy. Gdybyś miał z tym problem poczytaj gdzieś o metodzie kart CRC analizy i projektowania.

Oczywiście, można pozostać przy modelach które prezentujesz ale to nie jest modelowanie obiektowe ;)Jarek Żeliński edytował(a) ten post dnia 23.12.10 o godzinie 18:54

Temat: pojekt portalu imprezowego

Jarek Żeliński:
Na początek ćwiczenie: dopisz choć jedną metodę i jeden atrybut do każdej klasy i niech to nie będzie metoda set lub get :), wtedy będzie widać intencję tworzenia każdej klasy. Gdybyś miał z tym problem poczytaj gdzieś o metodzie kart CRC analizy i projektowania.

Ok - postarałem się coś naskrobać (mam jeszcze parę modeli innych - np. związany już z DdD):





Zaczniemy może od klasy User:
Ma ona metody login i register - to chyba nie trzeba tłumaczyć.
User bierze odział w evencie.
Klasa event zawiera metody (readComment i readGallery - pierwsza ma za zadanie czytać wszystkie komentarze a druga czytac cala galerie).

Ma także i Tutaj się zastanawiam i za bardzo nie mogłem wymyślić/znaleźć gdzie to umieścić: addComment i addUser. Wybrałem własnie to miejsca (pomimo tego ze to użytkownik dodaje się do eventu i to użytkownik dodaje komentarz - może dlatego ze w tym miejscu jest to dodawane) - prosiłbym o pokierowanie mnie tutaj - gdzie dokładnie umieszczać takie metody?

Drugie z pytanie jakie mam jest związane z podziałem klasy komentarze. Jak widać mamy klasę:
- Comment która jest uogólniona poprzez klasy commentEvent i commentPhoto. Te klasy dodają opcję typu do którego dany komentarz się odwołuje. Następnie - klasa event zawiera już nie klasę comment a commentEvent (czyli komentarze które są z nią związane).
Tak samo zostało zrobione z galerią (przewiduję rozbudowę galerii np. dla użytkowników) - więc galleryEvent uogólnia klasę gallery (czyli automatycznie klasa galleryEvent może wywołać funkcję readPhoto - z klasy gallery).

Tutaj się zastanawiałem długo czy takie rozwiązanie jest poprawne (chodzi o diagram) - na pewno daje dużo w przypadku rozbudowy. Jeśli mamy kolejne miejsce np z komentarzami to dodajemy tylko jedną klasę - nie przebudowujemy za dużo.

Prosiłbym o zweryfikowanie tego - i jeśli nie jest poprawne - pomoc/poprawienie tego lub naprowadzenie mnie do dobrego rozwiązania.

Temat: pojekt portalu imprezowego

Grzegorz Kożuchowski:

Jarek Żeliński:
Na początek ćwiczenie: dopisz choć jedną metodę i jeden atrybut do każdej klasy i niech to nie będzie metoda set lub get :), wtedy będzie widać intencję tworzenia każdej klasy. Gdybyś miał z tym problem poczytaj gdzieś o metodzie kart CRC analizy i projektowania.

Ok - postarałem się coś naskrobać (mam jeszcze parę modeli innych - np. związany już z DdD):





Zaczniemy może od klasy User:
Ma ona metody login i register - to chyba nie trzeba tłumaczyć.
User bierze odział w evencie.
Klasa event zawiera metody (readComment i readGallery - pierwsza ma za zadanie czytać wszystkie komentarze a druga czytac cala galerie).

Ma także i Tutaj się zastanawiam i za bardzo nie mogłem wymyślić/znaleźć gdzie to umieścić: addComment i addUser. Wybrałem własnie to miejsca (pomimo tego ze to użytkownik dodaje się do eventu i to użytkownik dodaje komentarz - może dlatego ze w tym miejscu jest to dodawane) - prosiłbym o pokierowanie mnie tutaj - gdzie dokładnie umieszczać takie metody?

Drugie z pytanie jakie mam jest związane z podziałem klasy komentarze. Jak widać mamy klasę:
- Comment która jest uogólniona poprzez klasy commentEvent i commentPhoto. Te klasy dodają opcję typu do którego dany komentarz się odwołuje. Następnie - klasa event zawiera już nie klasę comment a commentEvent (czyli komentarze które są z nią związane).
Tak samo zostało zrobione z galerią (przewiduję rozbudowę galerii np. dla użytkowników) - więc galleryEvent uogólnia klasę gallery (czyli automatycznie klasa galleryEvent może wywołać funkcję readPhoto - z klasy gallery).

Tutaj się zastanawiałem długo czy takie rozwiązanie jest poprawne (chodzi o diagram) - na pewno daje dużo w przypadku rozbudowy. Jeśli mamy kolejne miejsce np z komentarzami to dodajemy tylko jedną klasę - nie przebudowujemy za dużo.

Prosiłbym o zweryfikowanie tego - i jeśli nie jest poprawne - pomoc/poprawienie tego lub naprowadzenie mnie do dobrego rozwiązania.

Po pobieżnym przejrzeniu tego diagramu, najbardziej mi się rzuca w oczy obiekt "user". Moim zdaniem metody login i register nie powinny znajdować się w tej klasie. Dlaczego ? Mała metafora z wejścia na dyskotekę -> imprezowicz (User) podchodzi do człowieka na bramce a ten weryfikuje jego tożsamość i jeżeli jest wszystko w porządku to go wpuszcza. Także moim zdaniem powinna się tu znaleźć osobna klasa np. Autentykator, która będzie miała ww. metody.

Z innych rzeczy jeszcze to wydaje mi się, że obiekty typu gallery event, comment event i comment photo przynależa tylko do szczególnego przypadku implementacji gdy używamy relacyjnej bazy danych (były by zupełnie niepotrzebne np. w obiektowej bazie) i tak na prawdę nie są częścią modelu domeny.Wojciech Soczyński edytował(a) ten post dnia 27.12.10 o godzinie 08:35

Temat: pojekt portalu imprezowego

- metoda login to odpowiedzialność innego obiektu, nie Usera bo tej jest "autoryzowany" a nie "utoryzujący się", po drugie User tu to dane a nie aktor... a autoryzujemy aktora
- nie rozumiem dziedziczenia GaleryEvent po Galery,
- trudno będzie obsłużyć dziedziczenie komentarzy, lepsze było by proste uznanie, że komentarz dotyczy tego z czym jest połączony asocjacją...


plus uwagi Wojtka

Na koniec: ten diagram to tylko związki pojęciowe, nie ma tam nic o odwołaniach (use), diagram klas to nie model danych(!) jeżeli zaś był by to model dziedziny zgodny MVC to autoryzacja wypada bo jest częścią kontrolera a nie dziedziny.Jarek Żeliński edytował(a) ten post dnia 30.12.10 o godzinie 22:02

Temat: pojekt portalu imprezowego

Mam dziwne wrazenie ze poprzez diagramy klas starasz sie przedstawic modele bazy...

Temat: pojekt portalu imprezowego

Krzysztof Szelążek:
Mam dziwne wrazenie ze poprzez diagramy klas starasz sie przedstawic modele bazy...

mam dokładnie to samo odczucie... gdzieś czytałem (czy to potwierdzacie?), że model dziedziny obiektowy im mniej ma asocjacji a więcej <<use>>...

ale niestety widuje książki akademików, gdzie na diagramach klas operuje się pojęcie np. klucza głównego i to jest tragedia moim zdaniem...

pracuje w wolnych chwilach nad przykładem modelu dziedziny, takiego wkładu analityka w postaci "klocka" "Model" dla wzorca MVC, dam tu do recenzji jak skończę :)

Temat: pojekt portalu imprezowego

Jarek Żeliński:

Krzysztof Szelążek:
Mam dziwne wrazenie ze poprzez diagramy klas starasz sie przedstawic modele bazy...

mam dokładnie to samo odczucie... gdzieś czytałem (czy to potwierdzacie?), że model dziedziny obiektowy im mniej ma asocjacji a więcej <<use>>...

ale niestety widuje książki akademików, gdzie na diagramach klas operuje się pojęcie np. klucza głównego i to jest tragedia moim zdaniem...

pracuje w wolnych chwilach nad przykładem modelu dziedziny, takiego wkładu analityka w postaci "klocka" "Model" dla wzorca MVC, dam tu do recenzji jak skończę :)

Potwierdzam diagram klas, a diagram bazy ew. erd to 2 rozne sprawy...

Mysle ze odruchowe budowanie diagramow klas na modelach bazy w ORM/AC daje nam taki mix diagramow, przez co robi sie zamet i balagan...

Jarek czekamy na przyklady :D

Temat: pojekt portalu imprezowego

Głównie na czym mi zależy to przedstawić model (z wzorca MVC) - czyli mój diagram klas po prze konwertowaniu go na kod powinien zawierać
cały (albo większość modelu).

Nie wiem czy dobrze myślę ale powinno to tak działać - jeśli mam stworzony taki dobry model:

Jestem na podstronie np. /evenr/1
i tam w kontrolerze robię
$event = new event(1);
$attending = $event->readAttending();
$gallery = $event->readGallery(); // tutaj można jako parametr albo
innym sposobem przekazać ze np max 4 zdjęcia ma wyświetlać i np 4 stronę
$event->name (czy tam $event->getName())
i dzięki temu mam pobrane (nie interesuje programisty jak, skąd itp):
a) informacje o całym evencie
b) wszystkich gości
c) cala galerie

Druga sprawa: np użytkownik się loguje - tutaj zgadzam się - to nie powinien użytkownik robić.

przykład:
$user = $system->login(login,password); // loguje i zapisuje user w zmiennej user (klasę)
$event->addUser($user); // dodaje usera do attending - i zwraca rezultat(np. w postaci statusu).

Nie wiem czy dobrze myślę - ale chyba tak to powinno wyglądać. Jeśli się mylę proszę mnie poprawić. Tylko to co chciałem osiągnąć to nie do końca chyba nazywa się model dziedziny a bardziej "Projektowe diagramy klas".

Jarek Żeliński:
- metoda login to odpowiedzialność innego obiektu, nie Usera bo
tej jest "autoryzowany" a nie "utoryzujący się", po drugie User
tu to dane a nie aktor... a autoryzujemy aktora
- nie rozumiem dziedziczenia GaleryEvent po Galery,
- trudno będzie obsłużyć dziedziczenie komentarzy, lepsze
było by proste uznanie, że komentarz dotyczy tego z czym jest
połączony asocjacją...

>
>

plus uwagi Wojtka

>

Na koniec: ten diagram to tylko związki pojęciowe, nie ma tam
nic o odwołaniach (use), diagram klas to nie model danych(!)
jeżeli zaś był by to model dziedziny zgodny MVC to autoryzacja
wypada bo jest częścią kontrolera a nie dziedziny.

Spróbowałem jeszcze raz zrobić model dziedziny:





btw. na przykład czekam z niecierpliwością.Grzegorz Kożuchowski edytował(a) ten post dnia 02.01.11 o godzinie 14:46

Temat: pojekt portalu imprezowego

Grzegorz Kożuchowski:
Głównie na czym mi zależy to przedstawić model (z wzorca MVC) - czyli mój diagram klas po prze konwertowaniu go na kod powinien zawierać
cały (albo większość modelu).

użycie wzorca MVC na etapie analizy obecnie niejako z góry zakłada, że Controller i Vidoki to nie projekt tylko gotowce jakiegoś frameworka (bo to nadaje w ogóle sens temu wzorcowi).

Tak więc model dziedziny nie powinien w ogóle zawierać elementów sterowania samym programem w szczególności logowania....

jak się dorwę do "chwili wolnego czasu" spłodzę ten demo diagram ;), na razie urodziłem wstęp do niego:

http://it-consulting.pl/autoinstalator/wordpress/index...

Temat: pojekt portalu imprezowego

Tak w ogóle wracając jeszcze do "Usera", to można go rozdzielić na dwa obiekty - jeden jest użytkownikiem systemu i ma w sobie dane potrzebne dla autoryzacji etc (username,password) - można go zgeneralizować dla większości aplikacji. Natomiast drugi user, którego nazwę "Person" będzie miał w sobie pozostałe dane - imię, nazwisko, data urodzenia etc i to on pojawi się na diagramie w miejscach typu uczestnik eventu czy osoba na zdjęciu.

Temat: pojekt portalu imprezowego

Wojciech Soczyński:
drugi user, którego nazwę "Person" będzie miał w sobie pozostałe dane - imię, nazwisko, data urodzenia etc i to on pojawi się na diagramie w miejscach typu uczestnik eventu czy osoba na zdjęciu.

pod warunkiem, że chcemy przetwarzać te dane :), bo chyba nie mam pewności że aktor obsługujący program jest także uczestnikiem organizowanej imprezy...

to coś jak użytkownik systemu ERP, który ma bazę kontrahentów do faktur ale nie musi mieć poza loginem, danych fakturzysty...

P.S.
ciąg dalszy artykułu:
http://it-consulting.pl/autoinstalator/wordpress/index...Jarek Żeliński edytował(a) ten post dnia 04.01.11 o godzinie 21:06

Temat: pojekt portalu imprezowego

Jarek Żeliński:

Wojciech Soczyński:
drugi user, którego nazwę "Person" będzie miał w sobie pozostałe dane - imię, nazwisko, data urodzenia etc i to on pojawi się na diagramie w miejscach typu uczestnik eventu czy osoba na zdjęciu.

pod warunkiem, że chcemy przetwarzać te dane :), bo chyba nie mam pewności że aktor obsługujący program jest także uczestnikiem organizowanej imprezy...

to coś jak użytkownik systemu ERP, który ma bazę kontrahentów do faktur ale nie musi mieć poza loginem, danych fakturzysty...

P.S.
ciąg dalszy artykułu:
http://it-consulting.pl/autoinstalator/wordpress/index...Jarek Żeliński edytował(a) ten post dnia 04.01.11 o godzinie 21:06

Masz rację, bardzo często się zdarza, że projektuje się coś nadmiarowo i potem i tak nie wykorzystuje, lepiej chyba zrobić nawet mniej ale zrobić sobie większe pole do manewru.

Temat: pojekt portalu imprezowego

Po przejrzeniu ostatniego diagramu i treści wymagań, mam pewne wątpliwości.
Po pierwsze komentarze zawierają opis odpowiedzialności dla czegoś co wykonuje jakąś akcję (jest procesem) tym czasem diagram raczej przedstawia model danych niż procesów (to będą zupełnie inne modele).
Zauważyłem też wielokrotne użycie klas Użytkownik i Komentarz na tym samym diagramie, co dla mnie jest dość konfuzyjne.
Dla tego osobiście zaproponował bym inny model:





Robiąc powyższy diagram przyjąłem kilka założeń (niekoniecznie wynikających ze specyfikacji).
- każdy obiekt posiada swojego właściciela (użytkownika)
- usunięcie użytkownika skutkuje usunięciem wszystkich posiadanych przez niego obiektów.
- zdjęcia mogą istnieć wyłącznie w kontekście jednej galerii
- galeria może istnieć jedynie w kontekście jednego wydarzenia,
- aplikacja użytkownika (nie wiem czy do dobra nazwa) do uczestnictwa w wydarzeniu może obejmować tylko jedno wydarzenie.
- jedno wydarzenie może posiadać wiele aplikacji od różnych użytkowników.

I pewnie jeszcze parę o których napiszę innym razem jak już powyższy diagram zostanie porządnie zmieszany z błotem ;-)

Pozdrawiam

Grzegorz Kożuchowski:
Głównie na czym mi zależy to przedstawić model (z wzorca MVC) - czyli mój diagram klas po prze konwertowaniu go na kod powinien zawierać
cały (albo większość modelu).

Nie wiem czy dobrze myślę ale powinno to tak działać - jeśli mam stworzony taki dobry model:

Jestem na podstronie np. /evenr/1
i tam w kontrolerze robię
$event = new event(1);
$attending = $event->readAttending();
$gallery = $event->readGallery(); // tutaj można jako parametr albo
innym sposobem przekazać ze np max 4 zdjęcia ma wyświetlać i np 4 stronę
$event->name (czy tam $event->getName())
i dzięki temu mam pobrane (nie interesuje programisty jak, skąd itp):
a) informacje o całym evencie
b) wszystkich gości
c) cala galerie

Druga sprawa: np użytkownik się loguje - tutaj zgadzam się - to nie powinien użytkownik robić.

przykład:
$user = $system->login(login,password); // loguje i zapisuje user w zmiennej user (klasę)
$event->addUser($user); // dodaje usera do attending - i zwraca rezultat(np. w postaci statusu).

Nie wiem czy dobrze myślę - ale chyba tak to powinno wyglądać. Jeśli się mylę proszę mnie poprawić. Tylko to co chciałem osiągnąć to nie do końca chyba nazywa się model dziedziny a bardziej "Projektowe diagramy klas".

Jarek Żeliński:
- metoda login to odpowiedzialność innego obiektu, nie Usera bo
tej jest "autoryzowany" a nie "utoryzujący się", po drugie User
tu to dane a nie aktor... a autoryzujemy aktora
- nie rozumiem dziedziczenia GaleryEvent po Galery,
- trudno będzie obsłużyć dziedziczenie komentarzy, lepsze
było by proste uznanie, że komentarz dotyczy tego z czym jest
połączony asocjacją...

>
>

plus uwagi Wojtka

>

Na koniec: ten diagram to tylko związki pojęciowe, nie ma tam
nic o odwołaniach (use), diagram klas to nie model danych(!)
jeżeli zaś był by to model dziedziny zgodny MVC to autoryzacja
wypada bo jest częścią kontrolera a nie dziedziny.

Spróbowałem jeszcze raz zrobić model dziedziny:





btw. na przykład czekam z niecierpliwością.Grzegorz Kożuchowski edytował(a) ten post dnia 02.01.11 o godzinie 14:46

Temat: pojekt portalu imprezowego

Artur Kęska:




Robiąc powyższy diagram przyjąłem kilka założeń (niekoniecznie wynikających ze specyfikacji).
- każdy obiekt posiada swojego właściciela (użytkownika)
- usunięcie użytkownika skutkuje usunięciem wszystkich posiadanych przez niego obiektów.
- zdjęcia mogą istnieć wyłącznie w kontekście jednej galerii
- galeria może istnieć jedynie w kontekście jednego wydarzenia,
- aplikacja użytkownika (nie wiem czy do dobra nazwa) do uczestnictwa w wydarzeniu może obejmować tylko jedno wydarzenie.
- jedno wydarzenie może posiadać wiele aplikacji od różnych użytkowników.

Usunięcie użytkownika powoduje zniknięcie wszystkiego poza eventem.
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ę), Jeżeli tablica komentarzy zarządza komentarzami to "jakim prawem" pozwalamy użytkownikowi "obejść" posiadacza tych danych i dajemy mu komentarze "na skróty".

Ten diagram nadal nie jest obiektowy moim zdaniem, to jest kolejna próba wcielenia modelu danych lub jakiegoś modelu pojęciowego. Diagram klas jako narzędzie może opisywać zarówno model pojęciowy jak model jakiejś rzeczywistości odwzorowywanej (modelowanej) w kodzie. Jeżeli mogę sobie wyobrazić jakie atrybuty w tych klasach tak nijak nie przychodząc mi do głowy metody.

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.

Żeby nie powtarzać się zapraszam tu:
http://it-consulting.pl/autoinstalator/wordpress/index...

Diagramy jak powyższy niestety skutkują często tym, programista traktuje to jak model danych, który albo szybko uprości albo będzie walczył np. hibernate'em by go odwzorować. Potem zacznie się zastanawiać jaki program ma powstać bo na razie dostał jedynie dane jakie mają być przetwarzane.

Po raz kolejny polecam zapoznanie się antywzorce "anemiczny model dziedziny". Jarek Żeliński edytował(a) ten post dnia 31.01.11 o godzinie 08:35

Temat: pojekt portalu imprezowego

No dobra to się trochę pobronię :-)

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.

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

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

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. Wygląda więc na to że warto te cechy pokazać jako wspólne, z czego przynajmniej relacja posiadania przez Użytkownika jest cecha wymaganą. Wiem że nie lubi Pan generalizacji... więc nie generalizujmy.
Galeria natomiast może być elementem Event'u, co nie znaczy, że Event musi posiadać galerię. Galeria jest tez własnością Użytkownika bo to prawdopodobnie on ją tworzy i usuwa a nie Event.
Co widzę nie jest jasne, to fakt, że User może posiadać Eventy, Galerie i Zdjęcia. Zgadzam się, że ten zapis jest naciągany i lepiej było by jawnie pokazać relacje ale czy niesłuszny... hmm liczę na ripostę.

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. Można tez przyjąć tak jak Pan, że komentarz należy do obiektu komentowanego, ale to tylko inne rozwiązanie i wcale nie koniecznie prawdziwe (choć pozornie oczywiste).
Jak pan to nazwał "Tablica" komentarzy jest jedynie kontenerem agregacji, wiec nie zarządza Komentarzami ale udostępnia relację do nich.
Ściślej rzecz biorąc to np. Event (bo Commentable to abstrakcja a więc jako taka nie istnieje) agreguje komentarze.
Jest tu rzecz jasna pewien problem, ponieważ taka konstrukcja zakłada, że można usunąć Event a komentarze pozostaną - ale tego akurat mi Pan nie wypomniał. To z resztą też jest specyfika jakichś nie wypowiedzianych wymagań.

Ten diagram nadal nie jest obiektowy moim zdaniem,

Ojj, zabolało...

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

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

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.

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 :-)

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.

Żeby nie powtarzać się zapraszam tu:
http://it-consulting.pl/autoinstalator/wordpress/index...

n/a

Diagramy jak powyższy niestety skutkują często tym, programista traktuje to jak model danych, który albo szybko uprości albo będzie walczył np. hibernate'em by go odwzorować. Potem zacznie się zastanawiać jaki program ma powstać bo na razie dostał jedynie dane jakie mają być przetwarzane.

Co do zasady zgoda. Ale..
Kto powiedział, że implementacja ma być w hibernate? 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.

Po raz kolejny polecam zapoznanie się antywzorce "anemiczny model dziedziny". Jarek Żeliński edytował(a) ten post dnia 31.01.11 o godzinie 08:35

Oj, z ostatnim to już się kompletnie nie mogę zgodzić. To, że we wstępnych diagramach nie pokazuje się metod tylko relacje to coś zupełnie innego niż ADM. Gdybym dopisał jakąś dodatkową klasę która ustawiała by jakieś atrybuty np. Event'u to było by ADM a tak nie ma podstaw do takiej oceny.