Use Case mały diagram, proszę o ocenę.

Witam. Jako że nieubłaganie zbliża mi się egzamin z Inżynierii Oprogramowania, chciałbym poprosić o szybką ocenę mojego małego diagramu przypadków użycia. Głównie nie chodzi mi o sens całości, ale o to czy diagram jest zgodny z UML, jakie rażące błędy popełniłem, co powinienem w nim zmienić. Diagram przedstawia system obsługi klienta PKP. Pozdrawiam.

mi się nie rzuciły w oczy żadne błędy

Nie rozumiem.
Biletowa płaci gotówką?
Baza rozkładów jazdy szuka kursu?
System rezerwacji i sprzedaży się rejestruje?

Mnie się wydaje że zapomniałeś tu o jednym: diagram use-case to diagram przypadków użycia systemu (!). Podkreślam SYSTEMU. Co to za przypadek "odbierz bilet", albo "kup bilet w kasie". To nie są przypadki użycia systemu.

@Shalom - A gdyby biletowa sobie w systemie zaznaczała że zarezerwowany bilet został odebrany? Wtedy taki przypadek użycia ma sens. Masz propozycję jak go wtedy nazwać? Podobnie z zakupem w kasie - gdyby to był np. samolot, to wtedy może zostać? Wtedy sprzedawca zaznacza w systemie że jedno miejsce ubyło. Też wtedy sugerujesz zmienić nazwę? I czy wtedy powinienem się starać to rozbić na jakieś przypadki żeby wykładowca się nie przyczepił że to nie przypadek użycia systemu?
@somekind - hmmm. Rysując to posługiwałem się książką Język UML 2.0 w modelowaniu systemów informatycznych. Na stronie 55 wyraźnie istnieje połączenie między aktorem System Poczty Elektronicznej, a przypadkiem użycia "Dokonaj rejestracji". Z tym że tam jest zastosowana nawigacja w kierunku aktora. Czy po dodaniu tej strzałki (nawigacji) byłoby ok?

@insanity_prawn_boy bierz pod uwagę to że
a) masz mieć przypadek użycia systemu
b) aktor który jest połączony z tym przypadkiem używa systemu w okreslony sposób.
Nie jest tak ze każda sytuacja która kojarzy ci się z systemem będzie przypadkiem użycia.
Jeśli tak to przypadek kiedy "Pasażer" wykonuje "Kup Bilet" polegałby mniej więcej na tym ze pasażer podchodzi do jakiegoś terminala, uruchamia nasz system i w jakiś sposób dokonuje kupna biletu (taki przypadek pasuje np. do automatu biletowego). Ale wtedy nie ma miejsca na żadną Biletową.
Poza tym gdyby chodziło o oznaczenie w systemie np. że miejsce ubyło to przypadek byłby "zmniejsz ilość dostępnych miejsc" a nie "odbierz bilet". Patrz na to co wykonuje system ;)

W takim razie wygląda na to że mam problem ze zidentyfikowaniem aktorów.
Temat z zeszłego roku: "PKP (od strony informatycznej: kasa biletowa, płatność kartą, gotówką, sms. wyszukiwanie kursów, rezerwacja miejsc, bilety, bilety grupowe itp.)"
Jakich aktorów Ty byś wyznaczył? Rozumiem że panuje tutaj pewna dowolność i polecenie jest mało szczegółowe, ale pan egzaminator stawia ilość na równi z jakością... Co byś zaproponował?

Zależy kto ma tego systemu używac. Jeśli bezpośrednio Pasażer to on będzie tutaj aktorem. Jeśli pasażer przekazuje swoje żądania przez jakiegoś Pracownika to aktorem będzie Pracownik.
Aktorem będzie każdy kto bezpośrednio używa systemu.

Przede wszystkim, zanim ten diagram można będzie analizować merytorycznie trzeba go poprawić notacyjnie ;)

1. Wszędzie gdzie użyłeś strzałki z zamkniętym grotem oznacza ona Uogólnienie (lub dziedziczenie, zależy jak patrzeć) zapewne pisząc przy niej <<uses>> nie o to Ci chodziło.
2. W ogóle odpuść sobie na tym diagramie krotności i inne stereotypy poza <<include>> i <<extend>>
3. Nazwy PU to są rozkazy dla systemu, a w Twoim przypadku chyba dla organizacji PKP (modelujesz zdaje się przypadki biznesowe nie system) więc jak się ma do tego "Kup bilet przez internet"?
   Na razie wystarczy, uporządkuj i wrzuć nową wersję. Będę dalej zadawał trudne pytania ;)