Problematyczny UML

Witam,
Prosiłbym o sprawdzenie czy "błędy" wskazane przez prowadzącego są faktycznie istotne z punktu widzenia UML, już nie bardzo wiem co tu zmienić żeby się podobało, a prowadzący jest bardzo ciężki w obyciu, (dokłada treść od prowadzącego):

1. "Klient" jest aktorem czyli znajduje się poza zakresem systemu i nie
   można mu planować metod, gdyż nie mamy wpływu i nie powinniśmy mieć na to,
   co jest poza zakresem systemu. To samo dotyczy innych aktorów.
2. Na diagramach sekwencji widać wywołania metod kierowane do
   obiektów, które tych metod nie mają wg diagramu klas.

1. Diagram pokazuje przypadki użycia systemu, a systemu ktoś musi używać i jest to właśnie Aktor. Przypadek niepowiązany z aktorem nie miałby sensu. Jeśli Klient jest użytkownikiem systemu to jak najbardziej należy na diagramie umieścić przypadki użycia systemu przez Klienta. Ale jednocześnie musisz rozumieć że chodzi TYLKO o użycie SYSTEMU! Takie rzeczy jak odbiór towaru czy wydanie towaru to też funkcje systemu? Albo wyłożenie towaru? W jaki sposób twój system to realizuje? Częścia systemu są jakieś roboty które automatycznie wykładają towar jak magazynier kliknie "wykładaj"? Bo ja mam wrażenie że nic na tym twoim diagramie nie dotyczy bezpośrednio systemu, a opisuje raczej co robią pracownicy w firmie ;] Jak system realizuje dostarczenie towaru? Wysyła drony które towar dostarczają? o_O Zrozumiałbym coś a'la księgowanie odbioru towaru albo wydanie pokwitowania odbioru. Więc generalnie twój diagram jest zupełnie źle.
2. Nie ma diagramu sekwencji więc nie mogę sie odnieść.

1. Przypadki użycia to spagetti, uporządkuj to jako aktorzy -> przypadki. Przypadki (tutaj częsci systemu) włóż do jednego worka, a aktorów na zewnątrz.
2. "Obsługa systemu" - co to? Miał być chyba tytuł.
3. Rozdziel to na przypadki użycia. Modelowanie całego systemu nie jest przypadkiem użycia, może że masz tylko powiedzmy wydawanie towaru.
4. Dziwi mnie że nie ma dodatkowo modelowania czynności, gdybyś to zrobił to byś zrozumiał co masz źle.
   Jadąc od lewej (dodatkowo coś jest nie tak z includami):
   a) Odbiór towaru - ogólnie nie wiem jak wygląda system, ale chyba to nie jest potrzebne. Co prawda możesz modelować także nieinformatyczne zadania, ale przydałoby się to zaznaczyć na dodatkowym przypadku użycia.
   b) klient -> złożenie zamówienia -> magazynier (osobny diagram)
   c) szukanie towaru(zawiera się) w Pobranie towaru? Nie wiem co chcesz uzyskać. Może zastanów się nad <<extended>>.
   d) brak towaru? ma to w ogóle sens w tym przypadku? Co masz na myśli?
   e) Dostarczenie, przyjęcie, wyłożenie towaru no coś tutaj chyba jest nie tak.

Ogólnie to jeden wielki śmietnik, niemający sensu. Doprowadziłeś do wielu wieloznaczności, które powinieneś znosić i wykluczać.
To powinno być mocniej podzielone i uporządkowane.

Jak nie masz przypadków użycia to diagram klas i obiektów nie ma sensu. Wygląda to tak jakby oba diagramy były z różnych projektów. Zacznij od przypadków użycia, potem zrób diagram czynności. Dopiero wtedy możesz określić mniej więcej wymagane klasy.

Doczytałem i zmieniłem. Takie coś jest już akceptowalne?

Trochę lepiej ale robisz przypadki które nie są powiązane z aktorem a to źle. To że masz include oznacza że jeden przypadek wymaga drugiego, ale to wcale nie znaczy ze ten includowany ma być przez nikogo nie używany. Poza tym z diagramu wynika ze to sytem wysyła przesyłkę. Tak faktycznie jest? Jest tam robot który pakuje i wysyła? Czy moze system jedynie rejestruje informacje o wysyłce?

Faktycznie, przeoczyłem to wysyłanie towaru. Teraz już chyba jest w porządku.

Nie, nie jest. Co to za strzałka od aktora do aktora? o_O Diagram ma modelować zachowanie systemu i ma na nim nie być niczego "poza systemem"! To że magazynier dostarcza klientowi towar z punktu widzenia systemu w ogóle nie istnieje i nie ma to miejsca na diagramie przypadków użycia systemu. Poza tym serio to klient rejestruje w systemie odbiór czy może jednak dostawca? Nie wiem też czemu klient przyjmuje zamówienie albo rejestruje płatność ;)

Ok, jeżeli teraz na podstawie tego use-case diagramu robię diagram klas, to czy można stworzyć metodę dla dostawcy typu "dostarcz" mimo, że na diagramie use case tego nie widać?

Nie bo taka metoda w ogóle nie miala by sensu. Co ona by niby robiła? o_O

A no i właśnie sporo się wyjaśniło.

Uporządkowane, pousuwane zbędne elementy. Nie jestem pewien co do diagramu klas, a w szczególności magazynu.