Poniżej jest umieszczana automatycznie treść podstrony aurora znajdującej się w namespace projektu. Proszę ją utworzyć i traktować jako stronę startową - tam umieszczamy linki do poszczególnych podstron, które też mają się znajdować w projekcie, np. analiza_wymagan. W namespace mogą też Państwo umieszczać pliki (obrazki, diagramy, archiwa) linkowane na stronie danego projektu. Proszę usunąć ten akapit po zapoznaniu się z jego treścią.
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.
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:
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).
W projekcie bazy danych wyróżniono następujące encje:
Rozpatrywanie wszystkich tabel ze względu na kolejne postacie normalne:
Wszystkie wartości atrybutów są atomowe, więc zgodnie z definicją warunek postaci 1NF spełniony.
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.
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)
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.
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:
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.
