Utworzyłem podobny temat, ale związany z diagramem encji ([tutaj])(Tworzenie diagramu encji). Postanowiłem stworzyć oddzielny temat na tworzenie diagramu klas, a dokładnie poprosić Was o sprawdzenie czy został prawidłowo wykonany zgodnie z załączonym opisem (jeśli temat powinien zostać połączony bardzo proszę o moderację tego wątku).
W załączniku znajduję się diagram klas + opis.
Czekam na opinie...
PS. Przy Kluczu i Pilocie powinno być dotyczy.
Wg mnie diagram ok, dwie drobne uwagi:
Generalizacja - powinien być pusty grot strzałki, a masz wypełniony.
Nie wiem czy jest sens wprowadzać klasy Klucz i Pilot, może da radę wprowadzić Enumerację określającą typ Zasobu.
Czy Klucz i Pilot mają jakieś istotnie różne zachowanie, bądź struktura znacznie się będzie różnić? Może chodzi tylko o ewidencję zasobów i klucz / pilot nie posiadają własnej logiki biznesowej? :)
W realnym świecie taki diagram musiałbyś pokazać potem temu, kto pisał wymagania i okazałoby się, że wymagania są niejasne, niekompletne i byś musiał pisać diagram od nowa.
Twój wykładowca zdaje się spisał się na medal, bo dając ci to zadanie również celowo chyba napisał wymagania w sposób otwarty na interpretacje (podobnie jak się pisze prawdziwe wymagania biznesowe. Zwykle też się pisze najpierw niejasno, a potem się dopiero klaryfikują wymagania).
portier może wypożyczyć danemu PRACOWNIKOWI co najwyżej trzy KLUCZE oraz co najwyżej jednego PILOTA.
to należałoby czytać (w realnym świecie) raczej w ten sposób, że nie trzy klucze i jednego pilota, tylko pewną liczbą kluczy (od 0 aż do liczby dostępnych kluczy), i pewną liczbę pilotów (tak samo), oraz pewną liczbę innych rzeczy, np. szklanek czy talerzy. I to wszystko należałoby uwzględnić w implementacji, a co za tym idzie w diagramie, bo inaczej nie przetrwałoby to nawet tygodnia w normalnym świecie zmieniających się wymagań.
Albo np.. jest napisane W ramach jednego WYPOŻYCZENIA,. Ale co to znaczy w ramach jednego wypożyczenia.
jaki jest limit wypożyczeń? Niby napisane jest, że KLUCZE oraz PILOTY będą mogły być wypożyczane wielokrotnie; również dany PRACOWNIK może dokonać dowolnej liczby WYPOŻYCZEŃ. . Ale czy to znaczy, że pracownik może np. jednego dnia zrobić 5 różnych wypożyczeń w 5 róznych salach i mieć w ręku 15 kluczy i 5 pilotów?
Na logikę tak, bo to wynika z wyżej wymienionego tekstu - ale z drugiej strony możliwe, że jest tu zawarte ukryte założenie (a to się często zdarza w realnych sytuacjach, jeśli np. klient by wysłał takie wymagania, to można być pewnym, że z połowy założeń trzeba się domyślać), że np. wypożyczenie blokuje aż do oddania. I PRACOWNIK może dokonać dowolnej liczby WYPOŻYCZEŃ. ale po kolei, a nie naraz. Bo tak mówiłby zdrowy rozsądek (który często okazuje się wazniejszy od logiki).
No i sam język tych wymagań jest dość mętny i tak samo jak w prawdziwym życiu są wymagania kompletnie z d**y Należy używać notacji UML 2.5., więc w sumie widzę, że symulacja rzeczywistości dobra ;)