 Strona główna forum UML
Poprawne modelowanie prostej (na pozor) relacji | Zarejestruj się by pisać |
| Wcięte | Najpierw najnowsze | Poprzedni temat | Następny temat | Koniec |
| Postujący | Wątek |
|---|---|
| piotrgal | wysłane dnia: 2007/9/11 9:01 |
Nowicjusz  Dołączył: 2007/9/10 z: Posty: 2 |
Poprawne modelowanie prostej (na pozor) relacji Witam !
Mam pytanie / problem dotyczacy zamodelowania prostej zaleznosci/relacji dwoch klas (nie w UML ale juz w jakims obiektowym jezyku). Zagadnienie jest dosyc ogolne. Rzecz wydawala mi sie banalna i oczywista dopoki nie zdalem sobie sprawy, ze sa dwa mozliwe rozwiazania - oba wydaja sie poprawne i nie mam pojecia ktore nalezy wybrac (z punktu widzenia dobrego modelowania). Otoz zalozmy ze mamy dwie jakies klasy obiektow, gdzie jedna jest w zaleznosci klienckiej do drugiej, czyli jedna z nich moze byc powiazana z wieloma egzemplarzami drugiej. Moze to byc cokolwiek np. obiekt "regal" ktory jest powiazany z obiektami "ksiazka" ktore na nim leza. Banal... Pytanie brzmi: czy obiekt "regal" powinien zawierac liste/kolekcje obiektow "ksiazka", czy tez kazdy obiekt "ksiazka" powinien zawierac odniesienie do obiektu "regal" ??? Co jest poprawne zakladajac absolutnie teoretyczny, modelowy poziom rozwazan? Prosze pominac kwestie uzycia wylacznego/dzielonego (akurat niefortunnie ksiazki moga lezec jednoczesnie tylko na jednym regale )) Zreszta i tak gdyby ktos zaproponowal pierwsze rozwiazanie to jak wtedy majac jakas ksiazke dowiem sie, na ktorym regale ona lezy? (poza tym ksiazka moze tez nie lezec na zadnym legale) A w przypadku drugiego - jakie ksiazki leza na danym regale - dylemat oczywisty... (aha no i bez zadnych relacji bazodanowych - mamy tylko obiekty w pamieci i ich referencje oraz "rozne" kolekcje do dyspozycji) Dublowac informacje w obie strony??? Az sie boje pomyslec... (nadmiarowosc informacji, koniecznosc utrzymywania obu zaleznosci w synchronizacji, itp.) Pozdrawiam, Piotr |
| Jacek | wysłane dnia: 2007/9/11 19:57 |
Nie może przestać Dołączył: 2005/12/27 z: Gliwice Posty: 102 |
Re: Poprawne modelowanie prostej (na pozor) relacji Witaj,
Rozwiązania w języku programowania niestety nie jestem w stanie Ci podać. Ale postaram naprowadzić na rozwiązanie, które mnie wydaje się logiczne. Odwołam się tutaj do teorii baz danych. W koncepcji baz danych (może to podsunie Ci odpowiedź) miałbyć trzy relacje: tblRegał, tblKsiążka i tblKsiążkiNaRegale. Pomimo, że jest to związek relacji 1 do n, to przydatna jest tutaj relacja pośrednicząca -przechowująca identyfikatory regału oraz książek. Coś takiego w UML, którego rozwiązania nie chcesz można rozwiązać za pomocą klasy asocjacyjnej (pośredniczącej).
|
| piotrgal | wysłane dnia: 2007/9/12 9:49 |
Nowicjusz Dołączył: 2007/9/10 z: Posty: 2 |
Re: Poprawne modelowanie prostej (na pozor) relacji Witam ponownie,
Dzieki za pierwsza odpowiedz! Wlasnie chcialem uniknac uzywania relacyjnej bazy danych do rozwiazania, bo tam sytuacja jest troche inna - wystarczy jedna relacja w jedna strone, bo w druga informacje mozna uzyskac za pomoca selecta (czyli po prostu wyszukiwanie po pasujacych kluczach). W przypadku obiektow w pamieci nie ma takiej mozliwosci (nie mozna przeciez szukac po wartosciach referencji...), wiec ta brakujaca informacja musi byc gdzies zapamietana. A ze nie chce UML to nie powiedzialem nic Chodzilo mi tylko o unikniecie RBD. Z tego co sprawdzilem to asocjacja jest OK, tylko ze to teoria - jak ta asocjacje zaprogramowac - i tu wlasnie dochodzimy do dylematu opisanego przeze mnie. Ktorekolwiek z tych dwoch rozwiazan wpadnie nam pierwsze do glowy to zaraz mozna wykazac ze brakuje nam informacji o powiazaniu przeciwnym... Zasugerowales uzycie tabeli posredniczacej, tzn. mam rozumiec ze powinieniem zdefiniowac dodatkowa klase ktorej rola bedzie tylko wiazanie tych dwoch ze soba? Hmmm, musze nad tym pomyslec chwile Czekam na dalsze glosy od innych! Piotr |
| w3x | wysłane dnia: 2007/10/2 22:15 |
Nowicjusz Dołączył: 2007/10/2 z: Posty: 2 |
Re: Poprawne modelowanie prostej (na pozor) relacji Witaj,
rozumiem Twój problem ponieważ sam od jakiegoś czasu zacząłem robić modele w UML-u i dogłębniej niż kiedyś analizować strukturę programów, które piszę. Miałem podobne przemyślenia do Twoich w odniesieniu do kursów i kursantów (przy założeniu, że jeden kursant może odbywać wiele kursów ale tylko jeden kursant może odbywać konkretny kurs). Wybrałem Kursanta oraz listę kursów jakie odbywał. Kursy były obiektami na liście kursów. Pozwoliło mi to np. uniknąć wczytywania za każdym razem całej listy kursów z bazy danych i pozwoliło na bardziej selektywny wybór a przez co zaoszczędzenie zasobów systemowych. Rozważałem inną drogę, żeby kursy przechowywały odniesienia do kursantów ale ostatecznie się wycofałem z tego, mimo iż pokusa była duża ponieważ w pewnych przypadkach tak byłoby wygodniej. Co do niemożności zaprogramowania "dwukierunkowego" połączenia i przeszukiwania obiektów się nie zgadzam. Np. w C++ mając zwykły wskaźnik na jakiś obiekt można wywołać przecież jakąś funkcję, która poda ten klucz, na podstawia którego decydujemy. Listę można natomiast iterować i również porównywać poszczególne obiekty. Nie jestem ekspertem i być może moje wywody są błędne od strony sztuki projektowania obiektowego ale udało mi się rozwiązać problem dosyć elegancko. Natomiast uważam, że wybór konkretnego rozwiązania jest zależny od danego przypadku i to nie tylko od jego podmiotów ale również sposobu ich wykorzystania w programie. Pozdrawiam, Mateusz |
| Wcięte | Najpierw najnowsze | Poprzedni temat | Następny temat | Top |
| Zarejestruj się by pisać | |