Diagram klas - weryfikacja

0

Siemka. Chciałbym Was poprosić o weryfikację poprawności tego konkretnego diagramu klas. Czy relacje bądź logika jest poprawna? Będę wdzięczny za pomoc. :)

0
  1. Jaki jest cel tego diagramu? Co i komu chcesz przekazać i czego oczekujesz od tego kogoś?

  2. W oparciu o co mamy stwierdzić, że "logika jest poprawna" ?

  3. Po co tyle dziedziczenia przy użytkownikach?
    Nie wystarczyłoby Ci: Użytkownik <> ---> Rola ?

  4. "Struktura Systemu Zarządzania Obiegiem Informacji" - spodziewałbym się diagramu komponentów. Patrz punkt 1)

  5. Na pewno chodzi o to, że "Informatyk" implementuje interfejsy:

  • Interfejs Systemu Pracownika
  • Interfejs Systemu SZOI IT
  • Interfejs Systemu SZOI GZ ?

Czy nie jest to bez sensu, że Pracownik i Informatyk implementują "Interfejs systemu pracownika" ?

Może klasy Pracownik i Informatyk powinny korzystać (a nie implementować) z interfejsu, który byłby zaimplementowany przez jedną klasę?
Dlaczego chcesz mieć osobne implementacje na Pracowniku i Informatyku?

Zarówno Informatyk i Pracownik są "Pracownikami systemu", więc może sensowniej byłoby, żeby Pracownik miał dostęp do tych interfejsów, ale mógłbyś narzucić "constrainta": wymagana jest rola X.
OCL (Object Constraint Langugage) jest częścią UMLa...

0
yarel napisał(a):
  1. Jaki jest cel tego diagramu? Co i komu chcesz przekazać i czego oczekujesz od tego kogoś?

Ten diagram właściwie miał wyglądać tak: To miał być meta-system, taki ogólny, w którym Petent może się zarejestrować, a po rejestracji uzyskać możliwość dostępu do świadczeń, po czym Pracownik ma wgląd do dodanych świadczeń. Wysyła je do Głównego Zarządcy, który ma je wykonać. Po drodze jest ponowna weryfikacja poprawności danych. Informatyk ma wgląd właściwie do dwóch interfejsów i korzysta z dwóch innych. Co do generalizacji, niestety musi to wyglądać tak jak jest, zastrzegł to ostatnio wykładowca :P Jak oceniasz obecny diagram? Pewnie jeszcze jest dużo do działania, ale... zawsze kroczek bliżej. :)

1
Mikołaj Kabała napisał(a):
yarel napisał(a):
  1. Jaki jest cel tego diagramu? Co i komu chcesz przekazać i czego oczekujesz od tego kogoś?

Ten diagram właściwie miał wyglądać tak:

Chodzi o to, co chcesz przekazać i komu. Na tej podstawie dobierasz odpowiednie narzędzie (diagram), a nie wrzucasz radośnie wszystko w jedno miejsce i powstaje wielka, nieczytelna kupa... symboli.

To miał być meta-system, taki ogólny, w którym Petent może się zarejestrować, a po rejestracji uzyskać możliwość dostępu do świadczeń, po czym Pracownik ma wgląd do dodanych świadczeń.

To o czym piszesz, można zilustrować za pomocą diagramu przypadków użycia. Aktorzy: Petent, Pracownik, Główny zarządca

Wysyła je do Głównego Zarządcy, który ma je wykonać.

Tu jakiś fragment opisu procesu biznesowego. Główny Zarządca wygląda na rolę biznesową, a nie komponent, więc nie wybierałbym diagramu sekwencji, tylko diagram aktywności (osobiście procesy modelowałbym wykorzystując notację BPMN).

Po drodze jest ponowna weryfikacja poprawności danych.

Jaka ponowna weryfikacja danych? Kto weryfikuje, system czy człowiek?

Informatyk ma wgląd właściwie do dwóch interfejsów i korzysta z dwóch innych.

Co to znaczy, że Informatyk ma wgląd do dwóch interfejsów? Jaki cel biznesowy realizuje przez "wgląd w interfejsy" i korzystanie z dwóch innych? -> diagram przypadków użycia.
Jak to się wpisuje w proces obsługi świadczenia?

Co do generalizacji, niestety musi to wyglądać tak jak jest, zastrzegł to ostatnio wykładowca :P

Jak oceniasz obecny diagram?

Słabo. Wymieszane wiele różnych aspektów, przez co diagram jest zbyt chaotyczny.

0

Rozumiem, właściwie na każdej znalezionej stronie... są tego typu diagramy, niektóre robię podobnie jak wykładowcy. A wiadomo, człowiek uczy się tak, jak coś widzi. Ten przedmiot jest strasznie niejasny, stąd nie bardzo wiem nawet na czym się można wzorować, a to już dziesiąta wersja tego diagramu, przy czym wykładowca zaznaczył, że ten konkretny (rozbudowana wersja druga), jest najbliżej tego, co jest dobrze.
Z Twojej wypowiedzi wnioskuję, że diagram jest chaotyczny - być może to prawda. Jednak... słowo "Słabo" już trochę motywuje, to oznacza, że najgorzej nie jest. Dlatego też... jeśli mogę Cię poprosić, co mogę jeszcze tutaj zmienić, żeby całej koncepcji nie zaburzyć i nie rysować kolejnego diagramu? Czy relacje pomiędzy klasami w dalszym ciągu są błędne? Ewentualnie krotności? Byłbym wdzięczny za Twoje dalsze wskazówki, które z powodzeniem mógłbym wykorzystać w tym diagramie. :)

EDIT. Zmieniłem enumeracje na silne zależności pomiędzy poszczególnymi rolami użytkowników oraz interfejsów. W "Katalogu", została zmieniona agregacja ze strzałkami odwrotnie.

Dodatkowo, przesyłam również do wglądu wcześniejszy diagram przypadków użycia, o którym wspomniałeś, jednak on posiadał trochę błędów. Subsydiarnie, powoli powstaje diagram sekwencji, na podstawie właśnie diagramu przypadków użycia / diagramu klas. Więc jeśli mogę Cię poprosić o dwie opinie (diagramu klas i sekwencji), to byłbym bardzo zobowiązany ;)

0
  1. Diagram przypadków użycia
  • słyszałeś o pakietach dla diagramów przypadku użycia? Nie musisz wszystkiego umieszczać na jednym diagramie... Możesz mieć diagramy przypadków użycia per aktor.
  • "Kolejki oczekujących"? - czy jest używane przez jakiegokolwiek aktora?
  • "Inne działania" WTF?

Przypadki użycia -> czynności. "Zamów produkt, Aktywuj pakiet, Wyślij paczkę, Realizuj zabieg, Aktualizuj słownik, .... "

  1. Diagram sekwencji

a) Co ten diagram, który przestawiłeś ma ilustrować? Spodziewałbym się, że np. sekwencję interakcji użytkownika z systemem w celu realizacji określonego przypadku użycia.
b) Interakcje z systemem typu "podajImie", "podajNazwisko", to jakieś nieporozumienie. Aktywność pt. "Wyślij formularz rejestracyjny"

  1. Podstawowym problem wydaje mi się, to że nie rozumiesz do czego służą poszczególne diagramy i nie jesteś w stanie ich poprawnie użyć/nie wiesz co chciałbyś przekazać. Bez odpowiedniej podstawy będziesz się kręcił wokół tych samych błędów. Nie chodzi tu o samą notację, ale umiejętność projektowania z jej wykorzystaniem.

Najlepiej weź książkę i doczytaj -> "UML i wzorce projektowe. Analiza i projektowanie obiektowe oraz iteracyjny model wytwarzania aplikacji.", Craig Larman. Z tego materiału powinieneś zrozumieć jakie są etapy projektowania i od czego zacząć.

0
yarel napisał(a):
  1. Diagram sekwencji

Przesyłam nowy diagram sekwencji, zupełnie inny, mniejszy. Czy teraz wygląda on lepiej?

EDIT. Pojawił się drugi, zupełnie inny diagram.

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