Politechnika Częstochowska Wydział Inżynierii Mechanicznej i Informatyki Kierunek Informatyka Projekt aplikacji PZPN Wykonanie: Łukasz Jankowski Częstochowa 2012
Spis treści 1 Wstęp... 3 2 Opis sposobu realizacji... 3 3 Opis problemu... 4 3.1 System Ligowy... 4 4 Projekt systemu... 6 4.1 Diagram klas... 6 4.2 Projekt bazy danych... 7 4.3 Diagram przypadków użycia... 10 5 Podsumowanie... 13 6 Bibliografia... 14 7 Spis rysunków... 15 8 Spis tabel... 15
P r o j e k t a p l i k a c j i P Z P N 1 Wstęp Projekt dotyczy aplikacji PZPN, za pomocą której można zarządzać wszystkimi regulaminowymi zasadami istniejącymi w organizacji PZPN. Tymi zasadami są m.in.: transferowanie zawodników z klubu do klubu, obliczanie opłat za poszczególne operacje, pilnowanie przestrzegania zasad transferu zawodników oraz wystawiania klubów do rozgrywek. Aplikacja jest bardzo złożona od strony bazodanowej. Zawiera wiele ograniczeń, które muszą być restrykcyjnie przestrzegane przez wzgląd na utrzymanie spójności danych. Ze względu na ilość i istotę tych ograniczeń należy tak skonstruować bazę danych aby nie generować konieczności pilnowania obostrzeń przez program, lecz w całości przenieść obsługę błędów na bazę danych. Projekt ten od ogółu do szczegółu opisuje zasady działania aplikacji wyjaśniając również nierozłączne do poprawnego działania programu zasady obowiązujące w PZPN. 2 Opis sposobu realizacji Projekt będzie zamodelowany przy użyciu programu Enterprise Architect. To narzędzie umożliwia jasną i klarowną prezentację diagramów przypadków użycia, diagramów klas, modelu bazy danych itd. za pomocą języka UML. Pozostałe diagramy, rysunki i tabele zostały zamieszczone w celu lepszego zrozumienia wszystkich niuansów technicznych i funkcjonalnych aplikacji. 3
Ł u k a s z J a n k o w s k i 3 Opis problemu Niniejszy rozdział będzie opisywał System Ligowy Piłki Nożnej w Polsce. Zawarte tu informacje pozwolą lepiej zrozumieć sens funkcjonalny działania systemu. 3.1 System Ligowy Bez omówienia systemu ligowego stworzenie projektu nie będzie możliwe gdyż szczegółowość i złożoność zagadnienia jest tak spora, że nie było by możliwe zrozumienie problemu. 25 września 2006 Zarząd Polskiego Związku Piłki Nożnej przyjął projekt reformy systemu męskich ligowych rozgrywek piłkarskich w Polsce, który 7 stycznia 2007 został zatwierdzony uchwałą delegatów podczas Walnego Zgromadzenia PZPN i zaczął obowiązywać począwszy od sezonu 2008/2009. [1] Poniżej przedstawiona tabela reprezentuje poszczególne ligi rozgrywek w Polsce. Jest to tabela klas rozgrywkowych na przykładzie sezonu 2012/2013. Tabela reprezentuje hierarchię klas, po której wspinają się poszczególne kluby piłkarskie lub rozgrywają między sobą mecze w ramach danej klasy. Tabela 1 Klasy rozgrywkowe w sezonie 2012/2013 Poziom Poszczególne ligi 1 Eksraklasa 2 I Liga 3 II Liga 4 III Liga 5 IV Liga 6 Klasa okręgowa 7 Klasa A 8 Klasa B 9 Klasa C W tabeli zaprezentowano ogólny schemat wszystkich poziomów klas przyjętych uchwałą zarządu PZPN i obecnie obowiązujących. 4
P r o j e k t a p l i k a c j i P Z P N W każdej z poszczególnych klas gra określona liczba drużyn klubów piłkarskich. Aby nie zaciemniać tabeli uszczegółowienie tego podziału zaprezentowano na poniższym diagramie. Rysunek 1 System ligowy w Polsce 5
Ł u k a s z J a n k o w s k i 4 Projekt systemu W oparciu o system ligowy funkcjonujący obecnie w Polsce należy zaprojektować diagram klas w ramach którego znajdą się odpowiednie funkcje potrzebne do realizacji zadań aplikacji oraz schemat bazy danych, w której będą przechowywane wszystkie dane na których funkcje te będą operować. 4.1 Diagram klas Projekt klas i funkcje w nim zawarte stworzą silnik działania aplikacji. To w oparciu o te elementy aplikacji kontrolowana będzie spójność danych, obsługiwane będą błędy i wyjątki. Poniżej zamieszczony rysunek przedstawia proponowany diagram klas, który został stworzony w oparciu o system ligowy. 6 Rysunek 2 Diagram klas
P r o j e k t a p l i k a c j i P Z P N Rysunek prezentuje poszczególne klasy obiektowo projektowanej aplikacji, zawierające w sobie poszczególne elementy. Jak widać użyty został ścisły związek kompozycji, sugerujący iż przykładowo ekstraklasa nie istnieje poza ligą (systemem ligowym). Każda z klas zawiera szereg funkcji odwzorowujących rzeczywiste zachowania związane z kierowaniem i zarządzaniem klubami, obsługą rozgrywek oraz księgowaniem i obsługą opłat. 4.2 Projekt bazy danych Poniższy schemat prezentuje uproszczony projekt bazy danych zawierający wszystkie niezbędne na tym etapie tabele w bazie danych. Rysunek 3 Schemat bazy danych Zaprojektowana w oparciu o wzajemne powiązania kluczy obcych relacyjna baza danych dba o spójność i integralność danych w systemie. Element nadrzędny nie może zostać usunięty bez usunięcia wszystkich powiązanych elementów podrzędnych. Każda z tabel obowiązkowo posiada pole typu integer, w którym przechowywany jest klucz podstawowy będący identyfikatorem każdego wiersza. Poniżej prezentowana tabela pola obowiązkowe dla każdej z tabel wraz z ich typami. 7
Ł u k a s z J a n k o w s k i Tabela 2 Opis pól w poszczególnych tabelach bazy danych Nazwa tabeli Użytkownik Status Uprawnienia Zawodnik Klub Opłaty Pola/Typy/Właściwości id_user int NOT NULL AUTO_INCREMENT PK sur password text NOT NULL status int NOT NULL FK(id_status) id_status int NOT NULL AUTO_INCREMENT PK description text NOT NULL id_privileges int NOT NULL AUTO_INCREMENT PK league_manage int NOT NULL group_manage int NOT NULL team_manage int NOT_NULL club_manage int NOT NULL player_manage int NOT NULL arbiter_manage int NOT NULL system_manage int NOT NULL add_player int NOT NULL transfer_player int NOT NULL player_application int NOT NULL team_create int NOT NULL invoice int NOT NULL select_player_list int NOT NULL arbiter_time_access int NOT NULL match_protocol_create int NOT NULL match_protocol_print int NOT NULL match_summary int NOT NULL status int NOT NULL FK(id_status) id_player int NOT NULL AUTO_INCREMENT PK sur pesel text NOT NULL street text NOT NULL town text NOT NULL post_code varchar(6) NOT NULL phone varchar(9) club int NOT NULL FK(id_club) yellow_card int NULL red_card int NULL id_club int NOT NULL AUTO_INCREMENT PK prezes text NOT NULL nip varchar(10) NULL regon varchar(9) NULL street text NOT NULL town text NOT NULL post_code varchar(6) NOT NULL phone varchar(9) NOT NULL mail text NOT NULL id_payment int NOT NULL AUTO_INCREMENT PK payment MONEY NOT NULL deadline DATE NOT NULL interest MONEY NULL club_payment int NOT NULL FK(id_club) 8
Drużyna Grupa Województwo Liga Rozgrywki P r o j e k t a p l i k a c j i P Z P N id_team int NOT NULL AUTO_INCREMENT PK club int NOT NULL FK(id_club) group int NOT NULL FK(id_group) league int NOT NULL FK(id_league) id_group int NOT NULL AUTO_INCREMENT PK voivodeship int NOT NULL FK(id_voivodeship) id_voivodeship int NOT NULL AUTO_INCREMENT PK id_league int NOT NULL AUTO_INCREMENT PK games int NOT NULL FK(id_game) id_game int NOT NULL AUTO_INCREMENT PK team_a int NOT NULL FK(id_team) team_b int NOT NULL FK(id_team) game_date DATE NOT NULL match_result varchar(3) NOT NULL yellow_card_for_player int NULL FK(id_player) red_card_for_player int NULL FK(id_player) Powyższa tabela uszczeguławia zaprezentowany wcześniej schemat bazy danych. Tabela zawiera więcej powiązań, które najprawdopodobniej w trakcie programowania zostaną jeszcze rozwinięte, a sama baza danych zostanie rozbudowana. Powyżej opisane tabele reprezentują jedynie pierwszą iterację fazy projektowania użytego modelu iteracyjno przyrostowego. Ze względu na złożoność zagadnienia planuje się 2 iteracje z ciągłą kontrolą przyrostów dla poszczególnych zadań. 9
Ł u k a s z J a n k o w s k i 4.3 Diagram przypadków użycia Na diagramie przypadków użycia zaprezentowane zostaną poszczególne funkcje realizowane przez poszczególnych użytkowników systemu. Diagram ten pomoże wyjaśnić role i zadania poszczególnych grup osób (reprezentowanych przez użytkowników systemu), począwszy od zawodników, poprzez sędziów, kierowników klubów, prezesów klubów aż do administratora systemu. Rysunek 4 Diagram przypadków użycia Poniżej zaprezentowana tabela prezentuje merytoryczny opis poszczególnych funkcji przypadków użycia. Jest on niezbędny do opisu działania każdego przypadku. Jak widać przypadki zostały podzielone poprzez użycie ich przez poszczególnych aktorów. Definiuje to jednoznacznie podział uprawnień, o którym wcześniej wspominano w opisie bazy danych, gdzie zaprojektowane zostały tabele, w których określane będą uprawnienia poszczególnych użytkowników do wykonywania wybranych akcji. 10
P r o j e k t a p l i k a c j i P Z P N Poniższa tabela również uwzględnia podział przypadków użycia przez pryzmat uprawnień użytkowników. Tabela 3 Opis poszczególnych funkcji Użytkownik Przypadek użycia Opis Administrator Zarządzanie ligami Administrator dba o poprawny podział na poszczególne ligi wg obowiązującej uchwały PZPN Zarządzanie grupami Administrator kontroluje podział poszczególnych grup działających w obrębie województw, w razie konieczności modyfikuje dane w bazie danych. Zarządzanie drużynami Administrator zatwierdza dodanych do drużyny zawodników. Zarządzanie klubami Administrator wykonuje wszystkie czynności wynikające z konieczności zarządzania klubami, zatwierdza dane nowego klubu, modyfikuje je lub też czyni klub nieaktywnym w momencie jego rozwiązania (ze względów utrzymania historii, nie usuwamy klubów). Zarządzanie zawodnikami Każdy zawodnik grający w klubie musi być w systemie, każdy zawodnik może należeć tylko do jednego klubu. Zarządzanie rozgrywkami Administrator zatwierdza terminy rozgrywek, wpisuje je do systemu, ustawia czas dostępu do meczu dla sędziego głównego. Zarządzanie systemem Administrator czuwa nad poprawną pracą systemu i kontroluje wszystkie procesy oraz przypadki użycia związane z merytoryczną obsługą systemu. Prezes Dodawanie zawodnika Zawodnik przyjmowany do klubu musi być zgłoszony, a do systemu muszą być wprowadzone jego dane. Zgłaszanie zawodnika do rozgrywek Transferowanie zawodnika do innego klubu Stworzenie drużyny zawodników podstawowych i rezerwowych Przed każdym sezonem (upływem wyznaczonej daty) należy zgłosić zawodników do rozgrywek. Za opłaceniem odpowiednich wynagrodzeń dla klubu, zawodnik może być trasferowany (wypożyczony) na okres 1 lub 2 meczy w sezonie bądź na stałe do innego klubu. Do udziału w rozgrywkach należy stworzyć drużynę zawierającą minimum 11 zawodników podstawowych i 7 rezerwowych. 11
Ł u k a s z J a n k o w s k i Kierownik drużyny Wprowadzenie kadry meczowej Obsługa spotkań Akceptacja wpisu arbitra dot. Podsumowania spotkania Do zadań kierownika drużyny należy organizacja i zarządzanie spotkaniami, m.in. wprowadzenie kadry meczowej czyli prezesa, kierownika drużyny, trenera, zawodników itp. Kierownik drużyny organizuje drużynie wszystkie sprawy związane ze spotkaniem, wypisuje protokoły, komunikuje się z sędziami, poczyna ustalenia dot. meczu, prowadzi ewidencję zawodników, karty zdrowia, uzupełnia dane zawodników ukaranych kartkami karnymi, dba o ważność badań. Kierownik drużyny akceptujezatwierdza podsumowanie meczu wpisane przez arbitra głównego, celem weryfikacji i dbania o swoją drużynę. Sędzia Stwórz protokół meczowy Przed rozegranym meczem sędzia przygotowuje protokół meczowy składający się z podstawowych pól oraz wypełnia dane dot. rozgrywki. Wydrukuj protokół meczowy Wpisz podsumowanie meczu Przed rozegranym meczem sędzia drukuje protokół meczowy celem weryfikacji zawodników. Poprzez zatwierdzony przez administratora termin i udostępniony w czasie po zakończeniu meczu dostęp do aktualizacji danych meczu realizowany przez system System Wystaw opłaty System automatycznie wystawia opłaty danym klubom wg stałych stawek lub zatwierdzonych przez zwierzchnictwo Wyświetl listę zawodników w danym klubie Nadaj czasowy dostęp dla głównego sędziego do meczu w którym sędziuje System udostępnia listę zawodników w ramach klubu celem stworzenia drużyny. System nadaje głównemu arbitrowi dostęp do danych o meczy w którym sędziuje aby ten mógł wpisać podsumowanie meczu. Użytkownik Pokaż statystyki Każdy użytkownik systemu powinien mieć dostęp do statystyk. 12
P r o j e k t a p l i k a c j i P Z P N 5 Podsumowanie System został zaprojektowany z użyciem najnowszych technik modelowania w oparciu o paradygmat programowania obiektowego. Model tez został wybrany ze względu na dużą złożoność projektu oraz możliwość stosunkowo jednoznacznego odwzorowania poszczególnych funkcji i elementów aplikacji ze świata zewnętrznego. Klasy programistyczne oraz relacyjna baza danych zostały zaprojektowane w taki sposób aby zapewnić spójność i integralność danych. Dalszy rozwój aplikacji zależny będzie od implementacji i wybranego języka programowania. 13
Ł u k a s z J a n k o w s k i 6 Bibliografia 1. System ligowy piłki nożnej w Polsce [on-line], Wikipedia, http://pl.wikipedia.org/wiki/system_ligowy_pi%c5%82ki_no%c5%bcnej_w_polsce [dostępne: 8.12.2012 r.] 2. Forum Piłkarskie ASTAR [on-line], http://www.astar1.webd.pl/forum/, [dostępne: 12.12.2012 r.] 3. Notatki z zajęć 14
P r o j e k t a p l i k a c j i P Z P N 7 Spis rysunków Rysunek 1 System ligowy w Polsce... 5 Rysunek 2 Diagram klas... 6 Rysunek 3 Schemat bazy danych... 7 Rysunek 4 Diagram przypadków użycia... 10 8 Spis tabel Tabela 1 Klasy rozgrywkowe w sezonie 2012/2013... 4 Tabela 2 Opis pól w poszczególnych tabelach bazy danych... 8 Tabela 3 Opis poszczególnych funkcji... 11 15