Witam serdecznie , jestem w trakcie projektowania diagramu klas dla przychodni - jest to mój pierwszy projekt tak więc nie wiem czy jestem na dobrym tropie:
http://img297.imageshack.us/my.php?image=dkho2.jpg
Diagram przypadków użycia: http://img160.imageshack.us/my.php?image=puve7.jpg
Jeśli mógłby mnie ktoś nakierować w dobrym kierunku lub pokazać błędy byłbym naprawdę wdzięczny.
Duzo bledow. Chociazby to, ze exclude jest rozszerzeniem i strzalka idzie w druga strone. Nie mozesz w przypadkach uzycia dawac "pacjenta". ktory ma odrazy nadanal linie include. Include jest rozszerzeniem, ktore musi byc spelnione ale nie bez posrednio od typa.
Uwagi do diagramu przypadków użycia:
Ten diagram powinien opisywać CO system robi. Tutaj jest sporo informacji odnośnie tego JAK to robi - na przykład przypadek użycia "zakończ sesję". Jeśli chcesz zobrazować takie rzeczy to proponuję użyć diagramu aktywności w perspektywie projektowej.
Aktorzy typu "baza terminów" na pewno nie są aktorami zewnętrznymi (chyba że jest to inny system komputerowy na rzecz którego twoja aplikacja będzie świadczyć jakieś usługi). Jeśli chcesz pokazać aktorów wewnętrznych to masz dwa wyjścia:
tutaj dwie uwagi:
przypadek użycia (na poziomie celu użytkownika) to taka czynność, że aktor może podejść do systemu, wykonać tylko ją a następnie odejść usatysfakcjonowany. Dlatego przypadek użycia "wyloguj" to błąd.
aktor rozpoczyna interakcję z systemem, inicjatywa należy do niego i to on rozpoczyna wszystkie zdarzenia. Dlatego aktor "baza terminów" to prawdopodobnie błąd (nie koniecznie bo aktorem może być inna aplikacja, czas lub coś równie egzotycznego)
robisz wiele popularnych błędów, aby je poprawić proponuję zajrzeć do treści konkursu:
http://www.uml.com.pl/modules/newbb/viewtopic.php?topic_id=76&forum=3
końcowa uwaga: nie jestem pewien co ten system może robić. Generalnie widzę że jest to zarządzanie pacjentami ale nie wiem czy w ramach jednego szpitala, czy też bardziej ogólnie. Widzę że są rejestrowane badania, recepty i wyniki obserwacji ale nie jest jasna ich rola funkcjonalna. Skup się na tych rzeczach, na szczegóły logowania przyjdzie czas później.
Uwagi do diagramu klas:
Nie potrzebnie rozdzielasz dane pacjenta od operacji na nim. Jeśli nie ma żadnego technologicznego powodu to na prawdę polecam przenieść te operacje z klasy ZarządzajPacjentem do bytu Pacjent
Nadużywasz dziedziczenia, dam ci receptę: zapoznaj się z książką http://helion.pl/ksiazki/probw2.htm szczególnie z miejscem gdzie Alan pisze o wyborze pomiędzy dziedziczeniem a asocjacją (brzmi to absurdalnie bo to przecież inne relacje ale faktem projektowym jest, że można tutaj zastępować jedno drugim).
... w szczególności dziedziczenie Wizyta-Data
i SearchPacjent-Zarządzaj pacjentem
Logger ma dziedziczenie wielokrotne, nie jestem pewien czy zdajesz sobie z tego sprawę. Nie jestem też pewien czy w związku z tym Logger faktycznie JEST rodzajem DBConnection, chyba nie.
Brakuje liczności np. osoba-logger
fajny numer z relacją osoba-logger, co prawda podciągnięcie recepcji jako specjalnego rodzaju osoby jest semantycznie nie ładne ale potem wykorzystujesz to, że asocjacje są dziedziczone. Ładne to i elastyczne (dodawanie nowych typów osób będzie łatwe).
Nie wiem czy istnieje potrzeba na byt "kartoteka pacjenta", ja bym po prostu go usunął i połączył z pacjentem (te wszystkie asoscjacje).
polecam konkurs z diagramu klas:
http://4programmers.net/Forum/viewtopic.php?id=95683
pozdrawiam
Udało Ci się może zrobić ten diagram dla przychodni?
Mam podobny do zrobienia.
Pozdrawiam
Szymon
[email protected]
