Diagram klas UML - poprawność

0

Siemka.
Chciałbym Was poprosić o weryfikację poprawności tego diagramu UML. Mam pewne wątpliwości, zwłaszcza, przy Petencie zarejestrowanym i zleceniu. Ale... może uda Wam się wypatrzyć coś jeszcze (załącznik). Byłbym wdzięczny za pomoc. ;)

1

Wg mnie to dużo do poprawy, ja nie rozumiem tego diagramu. Za dużo zbędnych generalizacji to się nie uda przy implementacji. Dziwne nazewnictwo klas. Źle użyta kompozycja, która przedstawia związek część-całość gdy cykl życia obu obiektów jest powiązany. Zatem w Twoim diagramie w systemie lokalizacja czy pojazd medyczny nie może istnieć jeżeli usunę świadczenie medyczne. Raczej odpowiedzialność za obsługę faktur powinien mieć obiekt ku temu przeznaczony, a nie pracownik. Pracownik może być co najwyżej zależnością.

1

Do bani... Jeśli to na zaliczenie/studia/do szkoły to "pała" murowana.
Spojrzałem tylko na jedną klasę (pracownik) i są w niej różne metody jednak nie widzę klas za nie odpowiedzialnych t.j.: Faktury, raporty, zleceniodawcy, zlecenia.

W użytkowniki są metody zaloguj i wyloguj a nie ma nigdzie danych autoryzacyjnych. Może pokaż diagram ERD, który być może coś wyjaśni i jest jakimś uzupełnieniem powyższego. Jednak jeśli go nie ma to to co pokazałeś jest bez sensu i niekompletne. Nie wiadomo co te prostokąty rzeczywiście odzwierciedlają ..

Taki diagram w komplecie z bazą ( w tym przypadku wg mnie niezbędny ) ma pokazać jak działa system i co ma zaprogramować a z tego wynika jedynie jakiś chaos.

p.s. nie ma czegoś takiego jak "diagram UML" lub jest to bardzo nieprecyzyjne. W ramach UML mamy różne diagramy o różnych zastosowaniach i nazwach.
Twój diagram to diagram klas.

1
Mikołaj Kabała napisał(a):

Siemka.
Chciałbym Was poprosić o weryfikację poprawności tego diagramu UML. Mam pewne wątpliwości, zwłaszcza, przy Petencie zarejestrowanym i zleceniu. Ale... może uda Wam się wypatrzyć coś jeszcze (załącznik). Byłbym wdzięczny za pomoc. ;)

To jest źle. Dużo by pisać co jest nie tak.Kilka przykładów.

  1. Pakiet świadczenie medyczne i jego agregacje.
  2. Jak na diagramie jest "koło" to prawie na pewno jest źle. (masz takie "koło")
  3. Paten zarejestrowany, Pracownik systemu.
  4. "Patent Oglądający oferty Systemu" :D
  5. ...

Najlepiej usuń to i narysuj od nowa, bo poprawa tego zajmie Ci więcej czasu.

0

Jak napisał @malencki lepiej narysuj to od nowa.
Dla ułatwienia wypisz tutaj na forum jakie element,i zdarzenia mają być obsługiwane w systemie - językiem potocznym.

1

a też przez obecną sytuację nie mamy skąd się dowiedzieć, jak takie diagramy tworzyć, stąd ta porażka i do niej się przyznaje :P

Błagam Cię...
Obejrzyj i wypisz jakie "elementy" masz w systemie.

0
katakrowa napisał(a):

a też przez obecną sytuację nie mamy skąd się dowiedzieć, jak takie diagramy tworzyć, stąd ta porażka i do niej się przyznaje :P

Błagam Cię...
Obejrzyj i wypisz jakie "elementy" masz w systemie.

Po obejrzeniu, zrozumiałem jedynie, że elementy są klasami. Więc odpowiedź pozostaje bez zmian. Nie ma tak naprawdę różnicy, jakie elementy, czy też relacje będą między nimi. Ogólnie chodziło mi o to, żeby w takim diagramie umieścić użytkownika, który będzie interfejsem/abstrakcją, posiadające wszelkie dane chronione (imię, nazwisko, adres zamieszkania szczegółowy, PESEL, telefon). Od klasy Użytkownika, chciałem żeby wychodził Pacjent, który jest zarejestrowany i on może korzystać i zlecać pewne rzeczy do wykonania w systemie. Fakultatywnie, pacjent niezarejestrowany, który może mieć możliwość rejestracji, po czym skorzystania z usług systemu, czyli również może wykonywać czynności dodawania/usuwania/modyfikowania zleceń. Jeśli chodzi o klasę Pracownik, zamysł jest taki, żeby od niego wychodziły 3 inne podklasy (jeśli to tak można nazwać). Pracownik Systemu/Księgowy, Informatyk/Administrator, Główny Zarządca. Informatyk może właściwie najwięcej z nich wszystkich, bo może dodawać/usuwać/modyfikować pracowników, w tym Głównego Zarządcę. Może korygować na przykład... płynność systemu. Sprawdzać, czy wszystko przebiega poprawnie. Nie może on jednak wykonywać czynności przeznaczonych jedynie dla głównego zarządcy. Dlatego też dyrektor czy też główny zarządca może przyjmować zlecenia od pacjentów, którzy są zapisani. Może mieć kilka możliwości (świadczonych usług medycznych). Pracownik właściwie może zapisywać wnioski osób ubiegających się o pacjenta, czyli po prostu przekazywać deklarację wyboru przychodni, może też je modyfikować, zmieniać. Wysyła je bezpośrednio do głównego zarządcy. Dodatkowo, miałby możliwość przekazywania chęci pacjenta skorzystania z jakichś usług, również do głównego zarządcy. Mam nadzieję, że wyczerpująco odpowiedziałem na Twoje pytanie :P Akcesoryjnie, spróbuję zrobić jeszcze drugi diagram i dosłać go jeszcze dzisiaj do weryfikacji.

0

Diagram przypadków użycia jest taki :P (załącznik). Co prawda do tego jest osobny temat i nie wiem, czy dobrze rozumiem zaznaczone błędy. Spróbowałem zinterpretować błędy następująco:
Błąd nr 2 przedstawia generalizację, jednakże, strzałki powinny iść w drugą stronę (ponieważ przypadki pochodne muszą pochodzić od przypadków bazowych). Zaznaczony błąd nr 3 pokazuje relację rozszerzania pomiędzy przypadkami użyć. W tym wypadku, kolejki oczekujących mogą być rozszerzone (ale nie muszą) o trzy przypadki. Samo połączenie jest bezbłędne, natomiast problem polega na tym, że przypadek kolejek oczekujących nie ma połączenia z niczym innym w tym systemie.
Błąd nr 4 wskazuje na asocjację petenta zarejestrowanego z jego weryfikacją na liście. Wydaje nam się, że tutaj zachodzi potrzeba asocjacji skierowanej, ze względu na to, że aktor inicjuje przypadek użycia. Stąd jest zastosowana zwykła asocjacja (podobnie jak w przypadku aktora poniżej, gdzie jest petent niezarejestrowany, który bierze udział w rejestracji - powinna być asocjacja skierowana).
Błąd nr 5 pokazuje relację rozszerzania. Powinien on być zamieniony z extend na include, bo przypadek wymaga oceny jakości zdrowia Petenta.
Błąd nr 6 przedstawia relację zawierania. W tym wypadku, przypadek użycia "Wysłanie zgłoszenia" wymaga wypełnienia formularza zgłoszeniowego, więc w tym wypadku przedstawiona relacja powinna być poprawna.
Błąd nr 7 wskazuje na przypadek "Zapisanie zgłoszenia", przy którym obecnie znajduje się jedynie zwykła asocjacja, a powinna być skierowana, ponieważ jest ona inicjowana przez aktora.
Błąd nr 8 pokazuje relację rozszerzania. Prawidłowo została zastosowana relacja extend, ale nieprawidłowo kierunek grotu strzałki - powinno być odwrotnie. Przypadek "Rejestracji" może być rozszerzony o "Przeglądanie korzyści Systemu".
Błąd nr 9 wskazuje na błędną relację. Zamiast relacji include, powinna być extend, bo wszystkie przypadki wsparcia mogą, ale nie muszą być rozszerzane. Nie są one natomiast wymagane.
Finalnie, błąd nr 10 pokazuje, że przypadek "Administrator" wymaga kilku innych przypadków. Otóż, powinna być zastosowana inna relacja. Mianowicie, relacja rozszerzania. Kilka przypadków wychodzących od Administratora powinny mieć groty strzałek skierowane ku niemu i być zamienione z "include" na "extend".

Podsumowując, walka na dwa fronty. Z jednej strony poprawność zaznaczonych błędów, z drugiej strony diagram klas :P (oczywiście kombinuję dalej go rozwijać). Z tego, co zauważyłem, w tym konkretnym przypadku, zbytnia nadgorliwość nie popłacała, więc diagram klas nie musi być taki obszerny jak diagram przypadków użycia.

0

Na Twoim miejscu najpierw wydzieliłbym co jest obiektem, a co działaniem.
Przykładowo obiekty z Twojego diagramu to:

Zabiegi

Świadczenia

Zgłoszenie

Upoważnienie, wniosek, alert

Użytkownik

Komunikat

Umowa

Patent

itd ...

Wiele różnych obiektów świadczeń/zabiegów(dziedziczenie), lub jeden obiekt świadczenie/zabiegi konfigurowany - tak możesz to ułożyć na diagramie klas.
Następnie operacje:

generuj zestawienie zbiorcze

podanie leku (jakiś log kto podał i ile)

wyloguj

itd ...

To są operacje w klasach czyli metody lub jeszcze inne obiekty, które wykonują operację na danych obiektach.

Na Twoim miejscu najpierw wydzieliłbym jedną część systemu, powiedzmy użytkowników i na niej się skupił. Tylko logowanie i jakieś role użytkownika (czyli kto kim jest i co może).
Następnie dodawał kolejno małe niezależne części systemu. Rozbudowując i poprawiając pozostałe.

// Brakuje mi tutaj jeszcze diagramów czynności. Gdyby były zrobione, to przejście do diagramów klas byłoby znacznie prostsze.
Diagramy czynności to taki diagram przepływu systemu, czyli co konkretnie się dzieje.

Staraj się dzielić diagramy:
Jedna część jeden diagram. Na mniejsze łatwiej się patrzy i ogarnia :)

0
malencki napisał(a):

Staraj się dzielić diagramy:
Jedna część jeden diagram. Na mniejsze łatwiej się patrzy i ogarnia :)

To znaczy... spróbowałem zrobić coś takiego, nie mam pojęcia, czy to jest dobrze, ale... spróbuję się dostosować dalej do Twoich wskazówek :) (załącznik)

EDIT: Ten załącznik będzie nieco wyraźniejszy :P

EDIT #2: Spróbowałem dostosować się do Twoich wskazówek i udało mi się stworzyć taki diagram klas (załącznik). Czy relacje i sam diagram teraz jest nieco poprawniejszy? Byłbym wdzięczny za pomoc i ewentualne dalsze wskazówki :P

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