Diagram klas UML - sprawdzenie/ podpowiedzi

Witam,

Tworzę diagramy powiązane z systemem tworzenia gier komputerowych.

Najpierw mam diagram pakietów: http://vlep.pl/01k8o6.png
W którym kolejno zawarte są diagramy przypadków użycia:

1. Faza projektowania - http://vlep.pl/v4ht8y.png
2. Faza tworzenia - http://vlep.pl/vgxncy.png
   3.Implementacja - http://vlep.pl/fwl5ba.png

I do tego momentu prowadzący zajęcia powiedział że to trzyma się kupy.

Tworzę teraz diagram klas//vlep.pl/0pvlcy.png

I chciałbym zapytać czy idę w dobrym kierunku, co mam ew. zmienić /dodać ?

ps. Chciałbym dodać ze pierwszy raz tworzę diagramy UML więc prosiłbym o wyrozumiałość :)

No dobra, ale ile faktycznie z tych twoich usecase to są przypadki użycia systemu? Bo ja mam spore wątpliwości. Use Case opisuje funkcje systemu.

1. U ciebie widzę jakieś "wprowadzenie produktu na rynek". Tzn jak to system realizuje? Przewidujesz taki guzik "release!" który automatycznie wyśle aktualną wersje gry na steama albo zleci automatycznie wypalanie płytek? Jak to ma działać?
2. Widzę też na przykład "poprawianie kodu". To znaczy że programista pisze ten kod / poprawia ten kod za pomocą tego twojego systemu? Masz tam mieć wbudowany edytor kodu czy coś?
3. Widzę przypadek "wyłapywanie błędów" bez aktora który by go używał. To co to niby jest? Kto używa tej funkcji systemu? I jak ona w ogóle działa? To jest jakiś statyczny analizator kodu źródłowego?
4. "Komponowanie ścieżki dźwiękowej"? Znaczy się że system nie dość że ma edytor kodu, issue tracker i automatycznie wydaje grę to jeszcze ma wbudowany moduł do komponowania muzyki?
5. I do tego ma jeszcze wbudowany moduł tworzenia grafiki 3d?
6. A żeby tego było mało to główny projektant może to jeszcze sobie monitorować? :D

Ok, z tego wynika ze to jest bardzo bardzo skomplikowany system, ale ok, bo przecież to tylko zabawa. No ale teraz ten diagram klas to wygląda jak jakiś żart. Bo sam widzisz z moich punktów powyżej że chcesz zaprojektować gigantyczny i skomplikowany system. Sam diagram komponentów / architektury byłby tutaj sporym wyzwaniem a ty nie dość że chcesz zrobić diagram klas, to jeszcze póki co masz na nim tylko role użytkowników...

Zdaję sobie sprawę że sam system może być bardzo skomplikowany, ale nie do końca to jest moim zamiarem. Chciałem to ująć w jakieś takie bardziej ogólne ramy - taki - "diagram-ściągawka". Nie chce tego nikomu sprzedać ani tym bardziej sam używać,jedynie chce zaliczyć z podstaw UML'a przedmiot udowadniając że znam te powiązania i że ogólnie wiem o co biega.

Bardzo konkretnie mi odpowiedziałeś za bardzo dziękuję(widać trafiłem na doświadczoną osobę, obeznaną z tematem) - rozumiem że tymi pytaniami chcesz mi uświadomić że ten system nie powinien w ten sposób wyglądać jeśli chciałbym to potraktować wszystko na poważnie - wezmę sobie te rady do serca jeśli jeszcze kiedyś w życiu przyjdzie mi tworzenie czegoś związanego z UML'em . Co do diagramu klas to nie jest skończony - chciałem tylko znać zdanie czy tak mniej więcej ma wyglądać jego początek.

Mój główny cel był taki żebyś zaczął poprawnie myśleć w kategoriach czym jest a czym nie jest Use Case. Musisz myśleć o tym że każdy przypadek użycia musi być konkretną funkcją systemu i musisz rozumieć jak ta funkcja ma działać. W ogóle dziwnym pomysłem jest use case bez scenariuszy. Nawet jeśli nie jest to konieczne to polecałbym jednak scenariusze napisać. Bo to ułatwia trochę weryfikacje czy dany przypadek ma sens czy też go nie ma. Scenariusz może mieć format:

• Aktorzy: lista osób zaangażowanych
• Warunki wstępne: wszystko co musi być spełnione aby dany przypadek miał sens i można było użyć danej funkcji systemu. Na przykład dla jakiegoś sklepu internetowego użytkownik jest zalogowany, użytkownik ma w koszyku co najmniej jeden produkt
• Scenariusz właściwy: w punktach kolejne kroki które użytkownik ma wykonać w celu realizacji przypadku użycia np.

1. Użytkownik klika na przycisk "do kasy"
2. Użytkownik podaje numer karty kredytowej w odpowiednim polu
3. Użytkownik klika przycisk "zapłać"

• Warunki końcowe: opis stanu po wykonaniu przypadku, np. zakupy zostają opłacone, karta kredytowa użytkownika zostaje obciążona należnością, system wysyła zlecenie do magazynu aby przygotować paczkę z zakupionymi produktami

O czym warto pamiętać:

• Jeśli scenariusz nie zawiera odwołania do systemu, to nie opisuje przypadku użycia systemu. Np. jeśli kompozytor komponuje muzykę przy swoim pianinie to nie jest to przypadek użycia systemu, bo system nie jest używany!
• Jeśli brakuje "aktora" dla danego przypadku to znów bardzo możliwe że nie jest to przypadek użycia systemu. Bo systemu ktoś musi używać. System "sam" się nie używa.