Wypozyczalnia DVD - Diagram klas i przypadków użycia

0

Witam!

Muszę zrobić projekt internetowej wypożyczalni DVD. Zacząłem od wymienionych w temacie diagramów.
Sam system jest mały i prosty, podstawowym zadaniem systemu jest umożliwienie dokonania rezerwacji przez internet i zapoznania się z ofertą wypożyczalni. Na stronce wyświetlają sie wiec filmy które można zarezerwować. Poniżej zamieszczam diagram EER (baza danych) oraz wymienione diagramy.

EER:
user image

Przypadki użycia:
user image

Diagram klas:
user image
Co jest źle? Co powinienem zrobić inaczej? Szczególnie mam wątpliwości co do diagramu klas...

Naczytałem się sporo o diagramach klas, nie wiem czy bardziej mi to rozjaśniło czy pogmatwało w głowie, niemniej jak się nie ma praktyki to robi się trochę na oślep. Kilka wątpliwości...

  1. Czy można tak zrobić z użytkownikami jak zrobiłem? U jednego definiujemy wszystkie pola, reszta dziedziczy? Podobnie z metodami...

  2. Czy nie lepiej aby metoda zarezerwujFilm() była w klasie Wypożyczenia? I podobnie z innymi metodami?

  3. No i jeszcze związki pomiędzy klasami.... jak je dobierać oraz liczności.

Potrzebuję zrobić jeszcze trzeci diagram, jaki możecie polecić w miarę łatwy?

Za wszystkie uwagi, sugestie będę niezmiernie wdzięczny... z góry dziękuję.

0

Co ja bym zrobił:

Ad baza danych:

  • dodałbym tabele: miasta, adresy
  • opis filmu trzymałbym jako typ TEXT, a nie VARCHAR
  • kod pocztowy raczej jako CHAR(6), a nie VARCHAR(7) (to 7 to dla mnie zagadka kompletna ;))
  • cena filmu - to raczej liczba zmiennoprzecinkowa, więc np. float

Ad reszta:

  • zrobiłbym oddzielną, abstrakcyjną klasę Użytkownik, której rozszerzeniami byłyby inne
  • metodę zarezerwujFilm() trzymałbym w klasie Klient, bo to w końcu on wykonuje tą akcję. Powinna też przyjmować jako parametr Film, który ma być zarezerwowany.

Ad czwarty diagram - może spróbuj przepływu danych?

P.S. - diagram bazy danych też robiłeś w Enterprise Architect?

0
somekind napisał(a)

P.S. - diagram bazy danych też robiłeś w Enterprise Architect?

MySQL Workbench

0

@somekind, dla mnie 6 w kodzie pocztowym jest równie zagadkowe jak 7. Stawiam na 5.
pozdrawiam

0

@bogdans - kody pocztowe (przynajmniej w Polsce) mają przecież zawsze 6 znaków.
No ale faktycznie można kreseczkę w bazie pominąć.

0

IMHO kody pocztowe w Polsce mają zawsze 5 znaków, kreskę piszemy by zwiększyć czytelność.
Zbliżone zagadnienie, jak proponujesz pamiętać w bazie NIP (z kreseczkami, czy bez)?
pozdrawiam

0

Witam.

Piszecie o liczbie znaków dla pola, a co z diagramem klas, zależnościami pomiędzy nimi itd, wiem ze to nie jest łatwe ale ja ciągle mam mętlik...

0
bogdans napisał(a)

IMHO kody pocztowe w Polsce mają zawsze 5 znaków, kreskę piszemy by zwiększyć czytelność.

Mają format dd-ddd, nieprawdaż? I ja tak zawsze na przesyłkach piszę.
Niemniej jednak w bazie można kreseczkę pominąć - i tu masz też odpowiedź na swoje pytanie o NIP.
Można też zastanowić się, czy to ma być wypożyczalnia tylko dla polskich klientów, bo jeśli nie, to należy inaczej podejść, gdyż formaty kodów pocztowych w różnych krajach są różne.

0

to ma być wypożyczalnia do szkoły na lekcje, wiec wszystko jak najbardziej uproszczone...
pomoże mi ktoś z diagramem klas...?

0
jedre napisał(a)

pomoże mi ktoś z diagramem klas...?

Słuchaj, ja już napisałem, że u mnie byłaby oddzielna abstrakcyjna klasa Użytkownik, po której dziedziczyłaby reszta klas. Co nie znaczy, że Twoje rozwiązanie jest złe, jest po prostu inne, nie po mojemu i się nie będę wypowiadał. Niech ktoś naprawdę mądry Ci pomoże.

0

Witam,
diagram przypadków użycia jest w miarę dobry, natomiast diagram klas moim zdaniem
wymaga dopracowania. Np. co to za dziwna zależność administrator->pracownik,
obserwator<-klient, co to są 'wypożyczenia'. Jeśli mówimy o programowaniu
obiektowym nazwij to 'wypożyczalnia' a faktycznie będzie zawierała listę klientów, listę tytułów, itp.
I chyba nie ma potrzeby stosowania klas abstrakcyjnych ponieważ będzie tylko jeden
określony typ 'klient', jeden określony typ 'tytuł', gdybyśmy wyróżniali tutaj jakieś podkategorie
miałoby to sens. Bo co miałby wspólnego klient z tytułem, jeśli chodzi o dziedziczenie?
A więc zrób zwyczajnie:
klasy: 'klient', 'tytuł', 'listaklientow', 'listatytulow', 'wypozyczalnia'
Jeśli faktycznie potrzebujesz mieć jakiegoś administratora (?), to możesz zrobić
klasę bazową pt. 'człowiek'.

0
piotr.wycz napisał(a)

Bo co miałby wspólnego klient z tytułem, jeśli chodzi o dziedziczenie?

Ale Obserwator, Klient, Pracownik, Administrator z Użytkownikiem już chyba coś mają?

0

Ja bym zrobił klasę bazową człowiek, jeśli tylu aktorów jest potrzebnych.
Wtedy można nawet zastosować jeden rodzaj listy, który przyjmie wskaźnik
do klasy 'czlowiek'.

1 użytkowników online, w tym zalogowanych: 0, gości: 1