Problem z diagramem klas

Question

Stworzyłem sobie diagram przypadków użycia dla aplikacji mobilnej. Chce stworzyć teraz do tego diagram klas, ale nie wiem czy robię to dobrze i co mogę tam dodać i co jeszcze z czym połączyć. Proszę o pomoc.

Link do gotowego diagramu przypadków użycia - https://www.lucidchart.com/invitations/accept/64398960-622c-4aa1-8d27-a7ca78b7be50

Link do niedokończonego diagramu klas - https://www.lucidchart.com/invitations/accept/4ba160e3-fdf6-4efc-a2b0-166852a76098

Comments

@DragonCoder, i jeszcze mam pytanie co do tej daty ważności. Czy jest jakiś sens wprowadzania daty ważności od kiedy? Dla systemu jest ważne jedynie czy jego termin ważności nie minął.

---

Ma sens. Masz tylko waznosc. Czym jest waznosc? Bilet jest wazny 2 dni. Czyli od kiedy on jest wazny, od momentu w ktorym kupilem, zeskanowalem itd? Jezeli powiem, ze bilet jest wazny od daty zakupu przez 2 dno, to wiem, ze kupilem bilet 21.10.2019 i jest wazny do 23.10.2019. W innym przypadku brzmi to tak, jakby bilet byl wazny zawsze, bo nie wiesz od kiedy zaczyna sie jego termin wartosci. Dla Ciebie moze to byc logiczne i wgl, ale maszyna nie mysli, ona robi co jej kazesz.

---

@DragonCoder w tym systemie bilet uprawnia do jazdy ile się chcę o ile bilet jest ważny. Termin ważności to inaczej data do kiedy ten bilet jest ważny. Jeśli zapisze, że jest ważny do 29-11-2019 to maszyna będzie wiedzieć, że po tej dacie zeskanowanie biletu nie będzie możliwe.

---

Musisz myslec do przodu, zeby pozniej nie zmieniac calego systemu. Jesli pozniej pomyslisz, jednak bilety powinny byc wazne od momentu zeskanownia ich, to wtedy ups mam prpblem. System jest w obiegu, musze to zmienic, bo teraz jest wazny x dni od danej daty. Jesli dodasz jedna zmienna, to napiszesz jedna funkcje, ktora sama obliczy do kiedy ten bilet jest wazny. Jedna zmienna, jedna funkcja oszczedza teoretycznie rozszerzenie funkcjonalności na zas

---

Pytania które tu padają, to tak naprawdę warstwa wymagań :) Można ją wyprowadzić albo na początku (duża biurokracja), albo z każdego punktu scenariusza w UC (tak naprawdę to właśnie robią metodyki Agile dla User Story gdzie można powiedzieć że UC == US). To szybsze podejście często wystarcza.

Answer 1

W tradycyjnej analizie, jedna z możliwych kolejności to Use Case -> Scenario -> Class Diagram (lub inny).

Bez scenariusza głównego (minimum) i alternatywnych, nie stworzysz diagramu klas w sposób jakkolwiek odpowiadający rzeczywistości.

Comments

Ok... w dużym uproszczeniu ale krok po kroku:

0. Wypisz jacy aktorzy biorą udział w tych UC. Zwyczajowo inicjatorzy będą po lewej, uczestnicy/benificjenci po prawej.

1. Jeśli kontekst nazwałeś "System skanowania biletów", to co tu robią UC np. "Rozpoczęcie trasy"? Może inaczej je nazwać, może nie tu? Każdy UC (Use Case) ma prowadzić do jakiegoś celu systemowego/biznesowego (zależy od poziomu UC) korelującego z głównym kontekstem.

2. Jako 2 etap, wypisz "happy patch" czyli krok po kroku w danym UC co się dzieje. Ta ścieżka nie zawiera "jeśli dane są poprawne, jeśli system stwierdzi". Zawsze w "happy patch" dane są kompletne, aktor czyta i rozumie i wszystko działa :-) Kroków powinno być ~ 5 (max 7). Jeśli będzie więcej, rób <<include>> na poziomie UC. Happy patch to inaczej scenariusz główny.

3. Dla takiego scenariusza (happy patch), zrób diagram klas.

4. Cofnij się do etapu 2 i tym razem wszystko co możliwe idzie źle. Danych nie ma, login zły, aktor nie potwierdza, system się wiesza, baza i łącze pada itp... Dodaj te scenariusze "czepiając się" każdego z punktów happy patch. Oczywiście te przypadki błędów które chcesz obsłużyć. Te scenariusze, jeśli są obszerne (i chcesz je pokazać) są zawsze <<extend>>. Czarnowidztwo maksymalne :-) To są scenariusze alternatywne.

5. Dla tych scenariuszy dodaj elementy do diagramu klas.

Przy takim podejściu, będziesz miał z całą pewnością głębszą analizę niż spekulacje co jest w klasach. Teraz nawet nie ma co do nich zaglądać....