Daniłowski Cezary, s25901 16 czerwca 2024, Warszawa

Polsko-Japońska Akademia Technik Komputerowych Modelowanie i Analiza Systemów Informacyjnych

1. Kontekst i wymagania użytkownika ........................................................................................................ 3
2. Diagram przypadków użycia ................................................................................................................... 5
3. Diagram klas ............................................................................................................................................ 6
   1. Analityczny ......................................................................................................................................... 6
   2. Projektowy ......................................................................................................................................... 7
4. Scenariusz przypadku użycia „Wystawienie opinii lekarskiej” ................................................................ 8
   1. Opis tekstowy ................................................................................................................................. 8
   2. Diagram aktywności ....................................................................................................................... 9
5. Diagram stanu dla klasy „FighterInvolvement” .................................................................................... 10
6. Skutki analizy dynamicznej ................................................................................................................... 11
   1. Metody ............................................................................................................................................ 11
   2. Atrybuty ........................................................................................................................................... 11
7. Projekt graficznego interfejsu użytkownika .......................................................................................... 12
8. Decyzje projektowe............................................................................................................................... 14
   1. ADR 1 – Ekstensja i jej trwałość ........................................................................................................... 14
   2. ADR 2 – Asocjacja z atrybutem ............................................................................................................ 14
   3. ADR 3 – Dziedziczenie overlapping ..................................................................................................... 15
   4. ADR 4 – Dziedziczenie wieloaspektowe .............................................................................................. 17
   5. ADR 5 – Atrybut powtarzalny .............................................................................................................. 18
   6. ADR 6 – Mapowanie atrybutów złożonych w modelu relacyjnym ...................................................... 18
   7. ADR 7 – Mapowanie dziedziczenia w modelu relacyjnym .................................................................. 19
   8. ADR 8 – Wykorzystane technologie .................................................................................................... 19
   9. Inne pomniejsze decyzje ..................................................................................................................... 19

Pewna organizacja znana pod nazwą World Federation of Combat, w skrócie WFC, zajmuje się organizacją wydarzeń sportowych, a także szkoleń związanych z różnymi sztukami walki. Zwróciła się z prośbą o realizację systemu wspomagającego codzienną pracę i procesy w niej zachodzące.

System winien umożliwiać dla każdej osoby korzystającej z systemu zapamiętanie jej danych osobowych: imię(imiona), nazwisko, unikalny niezmienny PESEL, data urodzenia, adres, dane kontaktowe (numery telefonów i unikalny w systemie adres e-mail), wiek obliczany na podstawie daty dzisiejszej i daty urodzenia, unikalny login i zaszyfrowane hasło.

System ma umożliwiać organizację różnego rodzaju wydarzeń, przy czym wydarzenia można podzielić ze względu na rodzaj (turniej, pokaz) i dostępność (prywatne, publiczne). Każde wydarzenie ma cechy: nazwa, data i czas, lokalizacja, termin zapisów, opcjonalny powód odwołania oraz wartość pieniężna wygranej, przy czym dla pokazu do wygranej wchodzi też certyfikat uczestnictwa, a do turnieju dodatkowo do puli wygranej wchodzi pas konkretnego koloru z sztuki walki, którą uczestnik najlepiej opanował (z wyłączeniem sztuk walki, z których ma już najwyższy możliwy pas). Dla publicznego wydarzenia zapamiętywane jest też ilość dostępnych miejsc, a dla wydarzenia prywatnego cena biletu. Każda osoba odpowiedzialna za organizację wydarzenia, dalej zwana Organizatorem ma ustalony budżet narzucony przez WFC, oraz pamiętany jest jej dochód i data zatrudnienia. Organizator wyświetla wydarzenie po jego dodaniu. Poza tym organizator może wyświetlić listę dodanych przez siebie wydarzeń. Z wspomnianej listy może wybrać konkretne wydarzenie, po czym może edytować jego dane, lub też całkowicie je odwołać podając przy tym powód odwołania.

Organizator, może też organizować bootcampy szkoleniowe, które trenują uczniów w danej sztuce walki w konkretnym pasie. Tzn. uczeń po odbyciu szkolenia zdobywa dany pas z danej sztuki walki. Dla szkolenia zapamiętywana jest jego nazwa, data i czas startu, data i czas zakończenia, pas i sztuka walki. Każdy bootcamp składa się z lekcji, które posiadają informacje o lokalizacji (adres), data i godzina (musi mieć miejsce w czasie trwania bootcampu), temat lekcji, czas trwania w godzinach. Lekcje są posortowane według dat i czasu. System po dodaniu szkolenia, wyświetla je organizatorowi. Organizator może wyświetlić listę dodanych przez siebie szkoleń. Z wspomnianej listy może wybrać konkretną ofertę szkolenia, po czym może ją edytować, dodać dla niej lekcję, wyświetlić jej listę lekcji, a dla tej listy wyświetlić konkretną lekcję i ją odwołać.

W wydarzeniu może brać udział zawodnik, dla którego należy zapamiętać jego płeć, wagę, wzrost, oraz obliczaną na podstawie wagi klasyfikację wagową, która może przyjąć następujące wartości: musza, kogucia, piórkowa, lekka, półśrednia, średnia, półciężka, ciężka, superciężka. Żeby wziąć udział w wydarzeniu zawodnik musi mieć minimalny wiek, który teraz wynosi 20 lat. Zawodnicy posiadają lub też nie, pasy w różnych sztukach walki

(biały, żółty, pomarańczowy, zielony, niebieski, purpurowy, brązowy, czarny). Zawodnik zapisując się na wydarzenie musi je uprzednio wyświetlić (wyświetlić informacje o wydarzeniu). Po dokonaniu zapisu system go wyświetla. Zawodnik może wyświetlić swoją listę zapisów na wydarzenie, i z niej wybrać pogląd konkretnego zapisu. Może też wypisać się z wydarzenia do ustalonego terminu zapisów, po tym terminie wypisanie się nie będzie możliwe. Dla zapisu jest pamiętana data zapisu, punkty (już po odbyciu się wydarzenia), zdobyte miejsce (już po odbyciu wydarzenia), status („oczekujący” – przed badaniem, „zaakceptowany” – po badaniu z pozytywną opinią, „odrzucony” – po badaniu z negatywną opinią, „anulowany” – wypisanie się z wydarzenia, „zarchiwizowany” – po odbyciu się wydarzenia).

System ma umożliwiać wystawianie opinii lekarskich przez licencjonowanych lekarzy na temat zawodnika, który podchodzi do zawodów. Dla lekarzy należy zapamiętać ich numer licencji, oraz dochód płynący z pracy na rzecz WFC. Lekarz może dokonać opinii lekarskiej uprzednio wybierając z listy zapisów zapis konkretnego zawodnika, który będzie brał udział w zawodach. Dla każdej opinii pamiętany jest status, czy zawodnik został dopuszczony przez lekarza do wydarzenia, opis (stan zdrowia, przeciwskazania), data wystawienia opinii.

Do systemu może zalogować się też kibic, który może zakupić bilet na dane wydarzenie. Kibic ma ulubioną sztukę walki, i ulubionego zawodnika. W ramach zakupu biletu jest pamiętana data jego zakupu, oraz generowany jest numer unikalny w ramach wydarzenia.

Poza zapisem na wydarzenie zawodnicy mogą też wziąć udział w bootcampie szkoleniowym, Zawodnik, może być mistrzem lub uczniem na bootcampie, nie może być jednocześnie mistrzem i uczniem. Dodatkowo, będąc mistrzem musi posiadać taki sam pas w jakim szkoli bootcamp lub lepszy. Zawodnik zapisuje się na bootcamp uprzednio wybierając go z listy. Po dokonaniu zapisu system go wyświetla. Zawodnik może wyświetlić swoją listę zapisów na szkolenia, a po wyświetleniu konkretnego bootcampu z tej listy, może się z niego wypisać.

System, ma też umożliwiać comiesięczne generowanie podsumowania finansowego WFC.

W ramach procesu analizy dynamicznej nakreślono metody i atrybuty potrzebne do przeprowadzenia zaproponowanego przypadku użycia.

CreateFighterInvolvement(fighter, event)

Tworzy nowy zapis zawodnika w wydarzeniu. CreateMedicalCertificate(fighterInvolvement, isAccepted, desc, weight, height)

Tworzy wstępną nową opinię lekarską. W zależności od pola isAccepted, aktualizuje status fighterInvolvement (true => ACCEPTED, false => REJECTED). IsAccepted decyduje o dopuszczeniu zawodnika do udziału w wydarzeniu. desc – tekstowa treść opinii. Aktualizuje także wagę i wzrost jakie miał zawodnik przed uczestnictwem w wydarzeniu.

SetWeight(fighter, newValue) oraz SetHeight(fighter, newValue)

Wywoływane wewnątrz metody CreateMedicalCertificate. Aktualizują one wagę i wzrost zawodnika, jakie posiadał przy udziale na wydarzenie.

SetStatus( status)

Metoda wywoływana przez metodę CreateMedicalCertificate. Aktualizuje status konkretnego zapisu.

status – atrybut w klasie FighterInvolvement biorący udział w przypadku użycia. Reprezentuje status zapisu, gdzie może przyjąć następujące wartości: PENDING, ACCEPTED, REJECTED, ARCHIVED, CANCELED

height – atrybut w klasie Fighter, jest wykorzystywany w przypadku użycia weight – tak jak height

isAccepted – atrybut w klasie MedicalCertificate. Lekarz ustawiając go decyduje o dopuszczeniu zawodnika do konkretnego wydarzenia.

Rys. 7.1 Interfejs lekarza – lista zawodników i ich oczekujących zapisów na wydarzenia.

Rys. 7.2 Interfejs lekarza – wyświetlenie pojedynczego zapisu zawodnika.

Rys. 7.3 Interfejs lekarza – formularz wystawiania opinii lekarskiej.

Rys. 7.4 Interfejs lekarza – wyświetlenie pojedynczej opinii lekarskiej.

Rys. 7.1 Fragment z analitycznego diagramu klas – przykład asocjacji z atrybutem.

Rys. 7.2 Fragment z projektowego diagramu klas – przykład rozwiązania implementacji asocjacji z atrybutem.

Rys. 7.3 Fragment z analitycznego diagramu klas – dziedziczenie overlapping.

Rys. 7.4 Fragment z projektowego diagramu klas – implementacja dziedziczenia overlapping.

Rys. 7.5 Fragment z analitycznego diagramu klas – dziedziczenie wieloaspektowe.

Rys. 7.6 Fragment z projektowego diagramu klas – implementacja dziedziczenia wieloaspektowego.

Rys. 7.7 Fragment z analitycznego diagramu klas – przykład atrybutu powtarzalnego, tutaj „name”

Rys. 7.8 Fragment z projektowego diagramu klas – implementacja atrybutu powtarzalnego.

1. Postanowiono nie przedstawiać na diagramach metod typu set i get ze względu na to, iż zajmowało by to dużą ilość miejsca.
2. W implementacji niektóre złożone metody dotyczące logiki biznesowej zostały ulokowane w oddzielnych klasach - kontrolerach.
3. Atrybuty opcjonalne w implementacji nie zostały oznaczone adnotacjami @Required w przeciwieństwie do atrybutów wymaganych.
4. Atrybuty pochodne zostały zaimplementowane w postaci właściwości do odczytu (getter), oznaczono je adnotacją @NotMapped w celu wykluczenia jej z mapowania przez ORM.
5. Do zmapowania asocjacji wiele-do-wielu wykorzystano tabelę asocjacyjną, podobnie w rodzaju asocjacji z atrybutem.
6. W kompozycji w części oznaczono klucz obcy do całości adnotacją @Required i uniemożliwiono zmienianie jego wartość ustawiając w kontekście bazy danych przy budowniczym modelu użyto metody ValueGeneratedNever(), która informuje bazę danych o tym, że wartość klucza obcego nie powinna być zmieniania po przypisaniu. Ustawiono także adnotację [Editable(false)] co sprawia, że pole nie jest możliwe do edycji w widokach.
7. Na diagramie przedstawiono pewne ograniczenia względem atrybutów i relacji. Ograniczenie XOR dla relacji między klasą Fighter, a TrainingBootcamp, gdyż Fighter może brać udział w szkoleniu na dwa sposoby, może być mistrzem, albo uczniem. Logika tego i innych ograniczeń zostały umieszczona w specjalnych customowych adnotacjach.
8. W celu zachowania unikalności niektórych atrybutów użyto metody w FluentAPI: .HasIndex(e => e.Value).IsUnique();