Aurora Borealis - Recreation Center

Przedmiotem projektu jest stworzenie strony internetowej centrum sportowego, które umożliwiałoby klientom wynajem boisk piłkarskich oraz ewentualny udział w prowadzonej przez centrum lidze lub też dodatkowe atrakcje w zależności od potrzeb klienta. Wybór tematu opiera się na fakcie dużego zainteresowania współczesnego społeczeństwa aktywnościami fizycznymi, chęci dbania o własne ciało, miłego spędzenia czasu z kolegami, zwykłego poruszania się. Podobnie firmy w trosce o pracowników starają się im zapewnić rekreację czyniąc ją jeszcze bardziej kuszącą z powodu jej darmowości, załatwionej orgranizacji i gwarancji chętnych do udziału osób. Z tego powodu niejedno centrum sportowe musi umieć się zareklamować, wyjaśnić dlaczego stanowi idealne miejsce na takie rozgrywki i czym sie wyróżnia.

Najprostszym, najcelniejszym środkiem może okazać sie właśnie strona internetowa wprowadzająca potencjalnych graczy w ofertę, której właśnie szukali. Ciekawym dodatkiem jest możliwość prowadzenia rozgrywek w centrum, czyli pozwolenie graczom zmierzyć sie z innymi drużynami, zmotywować ich do bardziej zaciekłej walki i ogólnie do samej gry. Różne poziomy rozgrywek zapewniają ogólnie dobre, wyrównane mecze, aby czerpana przyjemność była dla wszystkich jak największa. Dla użytkowników oraz administratora będą udostępnione wygodne narzędzia użyteczne w przęgladaniu różnorodnych treści dotyczących ligi, zarządzania drużynami, wynikami, terminami rozgrywek oraz temu podobnymi.

System w całości będzie realizowany od podstaw, wszelkie dane będą uzupełniane ręcznie w miarę realistycznymi informacjami. Z tego powodu nie istnieją żadne dokumenty, raporty umożliwiające analizę realizowanego projektu, lecz będą tworzone wraz z postępem prac. W pierwszej fazie system ma pełnić rolę demonstracyjną stąd wykorzystywana baza danych nie wymaga żadnych dodatkowych uprawnień, pozwoleń i jest w pełni legalna, choć wymusza włożenie większego wysiłku w stworzenie danych testowych.

• Przeglądanie
  • dostępności boisk
  • listy drużyn
  • wyników spotkań
  • listy strzelców
  • terminarza meczy
  • tabeli z punktami
  • szczegółów nadchodzącego spotkania
• Zarządzanie
  • użytkownikami
  • boiskami i rezerwacjami
  • własną drużyną
  • danymi rozgrywek
  • galerią

System będzie dostępny w formie aplikacji sieciowej przez co po uruchomieniu na dowolnym serwerze(w wersji demonstracyjnej jetty) można z niego korzystać przy użyciu przeglądarki internetowej. Pozwala to na dużą niezależność platformową i minimalne wymagania sprzętowe.

Dostęp do systemu odbywa się przez wybrany adres url oraz przeglądarkę internetową, dostarczaną przez każdy system operacyjny. Natomiast samo działanie aplikacji uzależnione jest w dużym stopniu od serwera aplikacji.

Bezpieczeństwo zapewnione jest przez wymuszoną autoryzację konieczną do otrzymania odpowiednich uprawnień użytkownika lub administratora pozwalających na korzystanie z bardziej zaawansowanych funkcjonalności. Niezawodność systemu oparta jest na niezawodności wybranego serwera.

Podstawowe scenariusze użycia:

• Rezerwacja boiska:
  1. . Użytkownik wybiera z menu stronę 'Rezerwacje'.
  2. . System wyświetla stronę wraz z kalendarzem ustawionym na dzień dzisiejszy.
  3. . Użytkownik wybiera miesiąc, w którym interesuje go złożenie rezerwacji.
  4. . Użytkownik naciska na dzień w kalendarzu.
  5. . System wyświetla panel popup z tabela zawierającą możliwe godziny rezerwacji.
  6. . Użytkownik naciska przycisk 'Zarezerwuj' w wierszu z wybraną godziną.
  7. . System wyświetla potwierdzenia złożenia rezerwacji.

• Edycja konta:
  1. . Użytkownik wybiera z menu stronę 'Edycja profilu'.
  2. . System wyświetla szczegółowe dane użytkownika.
  3. . Użytkownik zmienia wybrane pola.
  4. . Użytkownik potwierdza zmiany wciskając przycisk 'Zapisz'.
  5. . System sprawdza poprawność wprowadzonych zmian.
  6. . System zapisuje zmiany w bazie.

• Edycja danych drużyny:
  1. . Użytkownik wybiera z menu stronę 'Moja drużyna'.
  2. . System wyświetla stronę na podstawie zalogowanego użytkownika.
  3. . Użytkownik zmienia dowolne dane osób z drużyny.
  4. . Użytkownik potwierdza zmiany przyciskiem zapisz.
  5. . System zapisuje po walidacji zapisuje zmiany.

• Dodawanie zgłoszenia na następny mecz:
  1. . Użytkownik wybiera z menu stronę 'Moja drużyna'.
  2. . System wyświetla stronę na podstawie zalogowanego użytkownika.
  3. . Użytkownik naciska przycisk 'Zgłoś udział' lub 'Zgłoś nieobecność'.
  4. . System dodaje do bazy notyfikacje o udziale użytkownika.
  5. . System ukazuje potwierdzenie poprawnego zapisu.

• Edycja rezerwacji:
  1. . Administrator wybiera z menu stronę 'Rezerwacje'.
  2. . System wyświetla stronę z kalendarzem ustawionym na dzień dzisiejszy.
  3. . Administrator wybiera miesiąc wprowadzania zmian.
  4. . Administrator naciska na dzień do edycji.
  5. . System wyświetla panel popup z tabelą złożoną z możliwych godzin wynajmu, rezerwacji i opisu.
  6. . Administrator edytuje zmiany, usuwa wybrane wiersze.
  7. . Administrator zapisuje zmiany.

• Edycja uprawnień oraz użytkowników:
  1. . Administrator wybiera z menu stronę 'Użytkownicy'.
  2. . System wyświetla stronę z listą użytkowników z edytowalnymi polami.
  3. . Administrator zmienia uprawnienia przy wybranym użytkowniku poprzez listę rozwijaną.
  4. . Administrator ewentualnie zmienia wybrane pola.
  5. . Administrator potwierdza wprowadzone zmiany przyciskiem zapisz.
  6. . System zapisuje wprowadzone zmiany.

• Planowanie rozgrywek:
  1. . Administrator wybiera z menu stronę 'Rozgrywki'.
  2. . System wyświetla stronę z rozgrywek dla dzisiejszego dnia.
  3. . Administrator wybiera z kalendarza rozpatrywany dzień rozgrywek.
  4. . Administrator z panelu drużyn przeciąga odpowiednie drużyny do tabeli meczy.
  5. . Administrator uzupełnia godziny rozgrywek.
  6. . Administrator potwierdza zmiany.
  7. . System zapisuje wprowadzone dane.

• Dodawanie strzelonych bramek:
  1. . Administrator wybiera z menu stronę 'Rozgrywki'.
  2. . System wyświetla stronę z rozgrywek dla dzisiejszego dnia.
  3. . Administrator wybiera z kalendarza rozpatrywany dzień rozgrywek.
  4. . Administrator naciska przycisk 'Dodaj' dla wybranego meczu, w którym padły bramki.
  5. . System wyświetla panel popup z listą zawodników obu drużyn.
  6. . Administrator wybiera zawodnika, uzupełnia czas strzelonej bramki.
  7. . Administrator zamyka panel.
  8. . System odświeża stronę wyliczając wynik na podstawie wprowadzonych goli.

• Dodawanie kar:
  1. . Administrator wybiera z menu stronę 'Kary'
  2. . System wyświetla stronę z listą kar.
  3. . Administrator poprzez przycisk dodaj wyświetla panel dodawania kary.
  4. . System wyświetla panel.
  5. . Administrator uzupełnia dane kary oraz potwierdza przyciskiem zapisz.
  6. . System zapisuje dane oraz zamyka panel.

System opiera się na bazie PostgreSQL, gdzie będzie przechowywał wszystkie informacje. W tym celu potrzebne są proste operacje tworzenia, edycji tabel oraz formułowania odpowiednich zapytań. Składają się na to instrukcje CREATE TABLE, INSERT INTO, SELECT, do których dostęp umożliwi framework Hibernate poprzez stworzone encje, obiekty DAO, menedżery, zarzadzające dostępem do tych tabel (mapowanie ORM do obiektów Java).

Diagram FHD

Diagramy DFD

W projekcie bazy danych wyróżniono następujące encje:

• Użytkownicy (id, nazwa, telefon, adres, nr dowodu, uprawnienie, id zawodnika)
• Uprawnienia (id, nazwa, opis)
• Grupy (id, nazwa, opis)
• Zawodnicy (id, imię, nazwisko, pesel, email, id drużyny)
• Drużyny (id, id grupy, nazwa, opis, kolor)
• Mecze (id, data, id pierwszej drużyny, id drugiej drużyny)
• Bramki (id, id zawodnika, id meczu, czas)
• Kary (id, id zawodnika, id meczu, opis, czas trwania)
• Zgłoszenia (id, id zawodnika, id meczu, status)
• Rezerwacje (id rezerwacji, data, id użytkownika, opis)
• Dni wolne (id, nazwa, data)

Diagram ERD

Diagram STD

Skrypt SQL tworzenia bazy

• client_roles
  • client_role_id - wymagane, liczba całkowita
  • client_role_description - łańcuch znaków
  • client_role_name - łańcuch znaków
• clients
  • client_id - wymagane, liczba całkowita
  • client_address - łańcuch znaków
  • client_document - łańcuch znaków
  • client_phone - łańcuch znaków
  • client_username - wymagane, łańcuch znaków
  • client_player_id - wymagane, liczba całkowita
  • client_role_id - wymagane, liczba całkowita
• daysoff
  • dayoff_id - wymagane, liczba całkowita
  • dayoff_date - data
  • dayoff_name - łańcuch znaków
• goals
  • goal_id - wymagane, liczba całkowita
  • goal_minute - liczba całkowita
  • goal_match_id - wymagane, liczba całkowita
  • goal_player_id - wymagane, liczba całkowita
• matches
  • match_id - wymagane, liczba całkowita
  • match_date - data z czasem
  • match_first_team - wymagane, liczba całkowita
  • match_second_team - wymagane, liczba całkowita
• notifications
  • notification_id - wymagane, liczba całkowita
  • notification_readiness - wartość logiczna
  • notification_match_id - wymagane, liczba całkowita
  • notification_player_id - wymagane, liczba całkowita
• penalties
  • penalty_id - wymagane, liczba całkowita
  • penalty_description - łańcuch znaków
  • penalty_expiration_date - data,
  • penalty_match_id - wymagane, liczba całkowita
  • penalty_player_id - wymagane, liczba całkowita
• players
  • player_id - wymagane, liczba całkowita
  • player_email - łańcuch znaków
  • player_first_name - łańcuch znaków
  • player_last_name - łańcuch znaków
  • player_nationalid - łańcuch znaków
  • player_team_id - wymagane, liczba całkowita
• reservations
  • reservation_id - wymagane, liczba całkowita
  • reservation_date - data z czasem
  • reservation_description - łańcuch znaków
  • reservation_client_id - wymagane, liczba całkowita
• team_groups
  • team_group_id - wymagane, liczba całkowita
  • team_group_description - łańcuch znaków
  • team_group_name - łańcuch znaków
• teams
  • team_id - wymagane, liczba całkowita
  • team_colour - łańcuch znaków
  • team_description - łańcuch znaków
  • team_name - łańcuch znaków
  • team_group_id - wymagane, liczba całkowita

Rozpatrywanie wszystkich tabel ze względu na kolejne postacie normalne:

• 1NF

Wszystkie wartości atrybutów są atomowe, więc zgodnie z definicją warunek postaci 1NF spełniony.

• 2NF

Każdy atrybut niekluczowy jest w pełni funkcyjnie zależny od klucza głównego (oraz baza w postaci 1NF), więc warunek postaci 2NF jest spełniony.

• 3NF

W bazie nie występują żadne zależności funkcyjne pomiędzy dowolną kolumną i inną kolumną nie będącą kluczem głównym tej tabeli - warunek postaci 3NF spełniony. (2NF także)

• 4NF i 5NF

Warunek czwartej postaci normalnej nie został spełniony, gdyż w bazie istnieją wielokrotne, wielowartościowe zależności funkcjonalne. Na cele aplikacji nie potrzeba dalszej normalizacji bazy danych, natomiast w obecnym stanie bardzo dobrze odzwierciedla model ukazywany w wartstwie prezentacji.

Z powodu braku 4NF, wykluczona została także postać 5NF.

select * from clients where client_player_id=?
select * from clients where userName=?
select * from daysoff where month(date)=? and year(date)=?
select * from goals where goal_player_id=?
select * from goals where match=? and player_team_id=?
select * from Match where match_first_team_id=? or match_second_team_id=?
select * from Match where day(date)=? and month(date)=? and year(date)=?
select * from Notification where notification_player_id=?
select * from Penalty where penalty_player_id=?
select * from Player where player_team_id=?
select * from Reservation where month(date)=? and year(date)=?
select * from Reservation where day(date)=? and month(date)=? and year(date)=?
select * from Team where team_group_id=?

Bazę danych można stworzyć za pomocą podanego wcześniej skryptu zgodnego z językiem bazy PostgreSQL: Skrypt SQL

W przypadku środowiska developerskiego zakładającego budowanie projektu w oparciu o narzędzie Apache Maven, ręczna implementacja bazy jest niepotrzebna. Podczas budowania modułu core aplikacji na podstawie zdefiniowanych encji zostają automatycznie stworzone odpowiednie struktury w bazie danych. Obowiązkowo należy zwrócić uwagę na plik mapowania encji oraz właściwości projektu dotyczące wybranej bazy danych (np. driver, lokalizacja bazy).

Formularze można podzielić ze względu na ich docelowego odbiorcę: użytkownika, administratora lub wspólne. W większości przypadków użytkownik może tylko przeglądać dane, dodawać ewentualne wpisy, podczas gdy administrator kontroluje całość zapisów.

• Ekran logowania

• Ekran edycji profilu

• Ekran rezerwacji
  • Dla użytkownika:

• Dla administratora

• Ekran terminarza meczy
  • Dla użytkownika

• Dla administratora

• Ekran rankingu strzelców

• Ekran drużyn

• Ekran kar

• Ekran użytkowników

• Ekran drużyny

Sterowanie aplikacją będzie odbywało się poprzez menu tworzone na podstawie ról nadanych użytkownikowi z uwagi na różny rodzaj uprawnień - np. użytkownik może edytować swój profil, a administrator widzi listę użytkowników. Widok panelu:

Przykładowe dane zostały wprowadzone do aplikacji i są dodawane do bazy przy budowaniu projektu. W rzeczywistości dane jednak będzie można wprowadzać na dwa sposoby:

• udostępnione formularze - logika zawarta w formularzach pozwala na dodawanie danych ograniczonych przez założenia formularza, jednak z powodu ograniczenia czasowego formularze nie obsługują wszystkich możliwych danych które użytkownik może zechcieć wprowadzić. Wprowadzane dane powinny wystarczyć dla potencjalnego użytkownika.
• insert do bazy - tworzenie odpowiednich zapytań, skryptów jest w pełni kompatybilne z działającą aplikacją i pozwala dodać dane nie obsłużone przez formularze (np. nowy użytkownik) lub w przypadku problemów innego rodzaju edycję.

Aplikacja została utworzona w technologii Java EE przy użyciu dość popularnego narzędzia Apache Maven oraz framework'u Appfuse (w nim zawarte: Hibernate, Spring, JSF i inne), przez co dalszy rozwój aplikacji jest uzależniony od tych narzędzi. Modyfikacja aplikacji wymaga przynajmniej podstawowej znajomości technologii obecnej w zmienianym module - dla bazy danych jest to np. Hibernate.

Obecny stan aplikacji pozwala na łatwy dalszy rozwój dzięki możliwości wzorowania się na zastosowanych rozwiązaniach, powielania ich do osiągnięcia satysfakcjonującego rezultatu.

Budowanie projektu skutkuje stworzeniem paczki war możliwej do uruchomienie na dowolnym serwerze aplikacji (np. Apache Tomacat będący kontenerem serwletów). Jeśli aplikacja nie jest budowana na danym środowisku przy użyciu Apache Maven to należy całą bazą danych stworzyć ręcznie przy użyciu skryptu. Możliwe jest także dzięki zastosowaniu profilów wykorzystanie innej bazy danych.

Realizacja projektu odbyła się w oparciu o znane technologie co pozwoliło na jego w miarę szybki, bezproblemowy rozwój. Wyeliminowało to trudności związane z poznawaniem technologii, szukaniem optymalnego rozwiązania danego problemu, optymalizacji kodu i tym podobnych. Podobnie dokładne oszacowanie kosztu prac, ograniczeń systemu i funkcjonalności ograniczyło dodatkowe nakłady pracy czy różnego rodzaje zastoje spowodowane brakiem idei na dalszą rozbudowę.

Nowym wymaganym aspektem projektu okazała się jego dokładna dokumentacja definiująca cały przebieg. Dodatkowy czas poświęcony na jej sporządzenie, dopracowanie umożliwia swobodniejsze tworzenie samej aplikacji w oparciu o gotowe schematy, diagramy. Zazwyczaj tworzone projekty były tworzone na bieżąco przez co kształt aplikacji mógł się bardzo zmieniać, w zależności od nowo powstałych potrzeb, czasem bardzo uciążliwych do zrealizowania. Dzięki wcześniejszemu przemyśleniu co należy stworzyć, w jaki sposób ma to działać i co dostarczać wszystkie funkcjonalne problemy były rozwiązane na samym początku. W przypadku poważnego problemu dotyczącego aplikacji dużo prościej jest przebudować sam koncept, kilka diagramów niż przepisywać część aplikacji, usilnie zmuszać moduły do współpracy.

• Hibernate
• Spring
• JSF Tutorial
• Appfuse
• Hibernate
• PostgreSQL