<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">%&amp; --translate-file latin2pl
\documentclass[a4paper,10pt]{article}

\usepackage{polski}
\usepackage[latin2]{inputenc}
\usepackage{longtable}
\usepackage{lscape}



% Marginesy
\textwidth17cm \textheight24.5cm \topmargin-40pt
\oddsidemargin-0.04cm

%%%%%%%%%%%%%%%
% To zmieniać %
%%%%%%%%%%%%%%%
% Nazwa, wersja
\newcommand{\nazwaprojektu}{Snatch, serwer brydżowy}
\newcommand{\nazwadokumentu}{Plan architektury systemu}
\newcommand{\wersjadokumentu}{1.3}

\title{\nazwaprojektu \ --- \nazwadokumentu}
\author{Michał Korch \and Piotr Tomanek \and Marcin Pilipczuk \and Piotr Tabor}

\begin{document}

% Definicja naglowka posrodku strony
\newcommand{\nagl}[1]{\par\begin{center}{\bf{#1}}\end{center}\par}
% Definicja tego na poczatku
\newcommand{\pocz}{\par {\bf{\nazwaprojektu}}\par {\bf{\nazwadokumentu}}\par {\bf{Wersja: \wersjadokumentu}}\par}
\maketitle
\par
{\bf{Wersja: \wersjadokumentu}}
\par

%% Historia
% environment
\newenvironment{historia}{\nagl{Historia}\begin{tabular*}{17cm}{c|c|c|l} {\bf{Data}} &amp; {\bf{Wersja}} &amp; {\bf{Autor}} &amp; {\bf{Zmiany}} \\}{\end{tabular*}}
% item
\newcommand{\hist}[4]{#1 &amp; #2 &amp; #3 &amp; \parbox[t]{9cm}{#4} \\ }

%% Spis tresci
\newcommand{\spistresci}{\tableofcontents}
\newcommand{\wfp}{www.bardzofajnyportal.pl}







%% Polecenie komunkacyjne
 environment
\newenvironment{SOAPmsgs}{ %
	\begin{longtable}{|p{3.5cm}|p{3cm}|p{6cm}|p{3cm}|} %
%		\caption {aaa} {bbb} %
%		\label {ccc}\\%
		\hline \multicolumn{1}{|c|}{\bf{Komunikat}} &amp; %
		\multicolumn{1}{c|}{\bf{Parametry}} &amp;%
		\multicolumn{1}{c|}{\bf{Opis}} &amp; %
		\multicolumn{1}{c|}{\bf{Odpowiedzi}} \\ \hline %
	\endfirsthead
	}	
	{\end{longtable}} 

 \newcommand{\SOAPmsg}[4]{#1 &amp; \parbox[t]{2cm}{#2} &amp; #3 &amp; #4 \\ \hline}


\begin{historia}
\hist{2005-04-08}{0.1}{Michał Korch}{Stworzenie wzorca całości dokumentu i dodanie wstępu.}
\hist{2005-04-09}{0.2}{Marcin Pilipczuk}{Rozdział drugi, widok procesów oraz komentarze - zarys co gdzie powinno być.}
\hist{2005-04-10}{0.3}{Marcin Pilipczuk}{Widok logiczny oraz widok infrastruktury.}
\hist{2005-04-11}{0.4b}{Piotr Tabor}{Tytuł, wydajność oraz najważniejsze algorytmy.}
\hist{2005-04-16}{0.5b}{Michał Korch}{Widok przypadków użycia.}
\hist{2005-04-16}{0.6b}{Piotr Tabor}{Schemat danych oraz Założenia i ograniczenia.}
\hist{2005-04-18}{1.0}{Piotr Tomanek}{Poprawki kontrolera jakości. Ostateczna wersja.}
\hist{2005-04-25}{1.1}{Marcin Pilipczuk}{Drobne poprawki.}
\hist{2005-04-26}{1.2}{Michał Korch}{Naniesienie poprawek Piotra T. do implementacji i poprawek kontrolera}
\hist{2005-05-14}{1.3}{Piotr Tabor}{Poprawienie widoku implementacyjnego, dopisanie konfiguracji i protokołów sieciowych}
\end{historia}

\spistresci
\newpage

% Dla taboreta :)
\newcommand{\strzalka}{$\leftrightarrow$}
\section{Wstęp}

\subsection{Cel dokumentu}
Celem tego dokumentu jest przedstawienie architektury systemu. Dokument ma przedstawić wizję architektury systemu z różnych stron.

Ten dokument stanowi podstawę do:
\begin{enumerate}
\item podziału pracowników na zespoły,
\item przydziału pracy implementatorom,
\item ustalenia kolejności wykonywania komponentów systemu,
\item prac nad schematem bazy danych,
\item zamówień odpowiedniego sprzętu,
\item opracowywania interfejsów między poszczególnymi modułami.
\end{enumerate}

\subsection{Definicje i skróty}
\begin{description}

\item[projekt] To, co ten dokument opisuje - projekt rozgrywek brydżowych przez internet.
\item[gracz] Klient grający w brydża przez działający projekt.
\item[widz] Klient obserwujący rozgrywki.
\item[sędzia] Klient mający większe uprawnienia, organizujący turnieje i nadzorujący je.
\item[udziałowiec] Portal www.bardzofajnyportal.pl, który jest udziałowcem i docelowym właścicielem binarnej wersji projektu.
\item[zespół] Zespół wykonujący projekt

\end{description}

\subsection{Źródła}

Ten dokument w kwestii ,,Widoku Przypadków Użycia'' oraz ,,Widoku Logicznego'' odwołuje się do Biznesowych Przypadków Użycia.
W kwestii podstawowego podziału na moduły oraz hierarchii prac, rozszerza od ,,Plan rozwoju projektu''.
Ogólna wizja projektu pochodzi z dokumentu ,,Wizja''.

\subsection{Streszczenie}
W dokumencie tym opisano architekturę systemu z różnych punktów widzenia: przypadków użycia, logicznego, procesów, danych, 
  implementatorów oraz sprzętu. Wyszczególniono decyzje projektowe, mające wpływ na architekturę.

\newpage
\section{Prezentacja architektury}

%PPP początek dużych zmian

Jak wynika z ,,Wizji'', projekt składa się z następujących elementów:
\begin{description}
\item[Bazy danych przechowującej informacje o rozgrywkach]
	Będzie to Oracle 10i: 
	\begin{itemize}
	\item[-]
	służący do przechowywania wszelkiej informacji trwałej (z wyłączeniem konfiguracji
	przechowywanej w plikach konfiguracyjnych). Umożliwia powrót systemu do stanu sprzed 
	wymyszonego resetu i kontunacje prowadzonych działań (z dokładnością opisaną w Wizji). 
	\item[-]
	umożliwiający analizę danych przy pomocy zewnętrznych narzędzi dostarczonych z bazą danych 
	\item[-]
	umożliwiający łatwe sporządzanie kopii bezpieczeństwa przy pomocy mechanizmów wbudowanych
	\item[-]
	umożliwiający podział obowiązków na wiele maszyn przy wzroście zapotrzebowania (obsługa systemół Gridowych)
	\end{itemize}

\item[Serwera chata]
	Zrealizowanego w postaci WebServisu (komunikacja przez SOAP Messaging Documents). Odbiera
	komunikaty i przesyła je do odpowiednich apletów chata. Pomaga zestawić stoliki na potrzeby 
	rozgrywek. Umożliwia zestawienie połączeń pomiędzy chatami ,,peer to peer'' (p2p) - wykorzystując
	zwykłe połączenie TCP/IP do transportu komunikatów w tym samym formacie (SOAP).

\item[Serwera pojedynczego rozdania] - Zarządza przeprowadzeniem pojedynczego rozdania brydżowego. 
	\begin{itemize}
	\item[-] Zostaje uruchomiony poprzez utworzenie instancji klasy javowej na skutek
	wywołania RPC zainicjalizowanej przez serwer pojedynczego turnieju. 	\\
	\item[-]Podłączają się do niego klienci(na określony adres IP i port zapisany w bazie danych (tabela ROZDANIA)) oraz 	    podłącza się do niego serwer turnieju (bądź serwer rozgrywek towarzyskich) i przekazuje rozdania. 
	Cała komunikacja odbywa się przy pomocy TCP/IP i asynchronicznego protokołu opartego o ,,SOAP Messaging Documents'' opisanego 	    w tym dokumencie w rodziale ,,Protokoły komunikacyjne - BML/SOAP''.
	\item[-]Po przepowadzeniu rozdania łączy się z serwerem turnieju i przedstawia mu wyniki rozdania. 
	Jeśli nie może połączyć się z serwerem turnieju to wyniki dopisuje na koniec specjalnego pliku na lokalnym 
	dysku (określone w dokumentacji) - na potrzeby późniejszego przetworzenia. 
	\item[-] Kończy działanie
	\end{itemize}

\item[Serwera pojedynczego turnieju] - Odpowiada za przeprowadzenie całego turnieju
	\begin{itemize}
	\item[-] Zostaje powołany do życia poprzez wołanie RPC w postaci klasy Javy na serwerze JBoss (wołanie
	jest ze strony demona nadzorującego - okresowo wykonywanego przez CRON'a).\\
	Dostaje jako parametr uruchomieniowy numer turnieju w bazie danych (tabela TURNIEJE) - który
	ma przeprowadzić (lub kontynuować). \\
	\item[-] Sprawdza istnienie na komputerach odpowiedzialnych za pojedyncze rozdania plików z danymi zwrotnymi (przez NFS - Network File System) i jeśli je znajdzie to je przetwarza.
	\item[-] Otwiera pierwszy dostępny port TCP/IP na potrzeby komunikacji (z aplikacjami sędziowskimi i procesami rozdań) (lub uprzednio przypisany - jeśli jest to wznowienie turnieju)
	\item[-] Aktualizuje wpisy w bazie danych - dotyczęce serwera i portu na którym jest uruchomiony
	\item[-] Przeprowadza turniej - poprzez dobór rozdań, odpowiednie uruchamianie serwerów pojedyńczych rozdań i odbieranie od nich wyników. Obsługuje też żądania ze strony sędziego turnieju. 
	\item[-] Po zakończeniu turnieju przygotowuje rankingi i zapisuje je do bazy danych oraz aktualizuje dane turnieju. 
	\item[-] Kończy działanie. 
	\end{itemize}
	
	
\item[Serwera rozgrywek pozaturniejowych] - nadzoruje wszystkie toczące się w systemie rozgrywki pozaturniejowe (towarzyskie). Stałe uruchomienie serwera pilnowane jest przez okresowo uruchamiany (CRON) demon nadzorujący. 
Uruchamia serwery poszczególnych rozdań oraz utrzymuje łączną punktacje poszczególnych stolików. Dane te nie są zapisywane do bazy danych, więc po ewentualnym resecie serwera punktacja taka zostanie utracone. 

\item[Aplikacji klienckiej gracza i widza (apletu)] - odpowiada za uczestnictwo gracza lub możliwość oglądania przez
widza pojedyńczego turnieju. 
\begin{itemize}
	\item[-] Aplet zostaje uruchomiony na skutek bądź wczytania odpowedniej stron www (utworzonej przez servlet), bądź poprzez rządanie od aplikacji sędziowskiej. Zostaje mu w parametrach przekazane do jakiego serwera i na jaki port ma się przyłączyć oraz ewentualnie hasło autoryzujące (w postaci jawnej). Alternatywnie mógł mu zostać
	przekazany kod BML (Bridge Markup Language) opisujący rozgrywkę którą ma przedstawić - co stanowi prostrzy przypadek niż ten opisany poniżej. 
	\item[-] Aplet łączy się ze wskazanym serwerem i ewentualnie dokonuje autoryzacji
	\item[-] Aplet przeprowadza/pokazuje rozdanie udostępniając wykodny interfejs użytkownika
	\item[-] Aplet kończy działanie
\end{itemize}
	
\item[Aplikacji klienckiej sędziego] - stanowi interfejs użytkownika do zarządzanie turniejem przez sędziego
	\item[-] Aplikacja sędziowska zostaje uruchomiona przez sędziego na komputerze klienckim
	\item[-] Aplikacja sędziowska pyta o dane uwierzytelniające użytkownika i go loguje
	\item[-] Aplikacja sędziowska wyświetla listę turniejów którymi zalogowany sędzia może zarządać i umożliwia wybór jednego (dostęp do danych poprzez SOAP http://www.bardzofajnyportal.pl/wsdl)
	\item[-] Aplikacja sędziowska odczytuje (poprzez SOAP) dane wybranego turnieju (w tym serwer i port) i ustawnawia połączenie TCP/IP z serwerem tego turnieju
	\item[-] Aplikacja umożliwia sterowanie turniejem
	\item[-] Aplikacja zostaje wyłączona

\item[Demona nadzorującego] - uruchamiany przez CRON'a co minutę (domyślnie) na każdej maszynie obsługującej system
	\begin{itemize}
		\item[-] Sprawdza, czy wszystkie procesy turniejów, które powinny być uruchomione na danej maszynie są uruchomione i ewentualnie je uruchamia
		\item[-] Sprawdza, czy odpowiednie serwery są uruchomione (serwer gier towarzystkich, serwer chata)
	\end{itemize}

\item[Stron www dla graczy i widzów] - prezentacja danych\\ Zrealizowane w postaci serwletu
\item[Stron www dla sędziów] - prezentacja danych \\Zrealizowane w postaci serwletów
\item[Stron www dla pracownika] - prezentacja danych \\ Zrealizowane w postaci serwletów
\item[Stron www dla reklamodawcy] - prezentacja danych\\ Zrealizowane w postaci serwletów

\end{description}

%AAA Zrobione - Napisac w kilku zdaniach do czego kazda z tych powyzszych rzeczy sluzy.
%PPP Koniec dużych zmian

W tym:

\begin{enumerate}
\item Do {\bf{bazy danych}} podłączają się: strony www, serwery turniejów, rozdań oraz demon nadzorujący.
\item Do {\bf{serwera pojedynczego rozdania}} podłączają się aplikacje graczy, widzów oraz sędziów. Jest on wywoływany przez serwer turnieju
bądź demona nadzorującego, łączy się on z bazą danych.
\item Do {\bf{serwera turnieju}} podłączają się aplikacje graczy, widzów oraz sędziów. Jest on wywoływany przez demon nadzorujący. Łączy się z bazą danych.
\item Aplikacja gracza i widza łączy się z wszystkimi serwerami i demonami.
\item Aplikacja sędziego łączy się z wszystkimi serwerami i demonami.
\item Demon łączy się z aplikacjami klienckimi oraz z bazą danych. Uruchamia serwer turnieju dla rozpoczynających się turniejów oraz serwery rozgrywek dla rozgrywek towarzyskich.
\item Strony www wyświetlają statycznie informacje z bazy danych.
\end{enumerate}

Dodatkowo niezależnym wątkiem pobocznym będzie {\bf{proces czatu}} obsługujący czat między użytkownikami.

W celu przedstawienia, jak system ma działać, przedstawione są poniżej następujące widoki:

\subsection{Widok Przypadków Użycia}

Ten widok przedstawia nietrywialne przypadki użycia spośród Biznesowych Przypadków Użycia wraz ze sposobem realizacji za pomocą wyżej opisanych 
części systemu. Pominięte zostały trywialne Przypadki Użycia, m.in. te polegające na wyświetleniu odpowiednio sformatowanej zawartości 
tabeli z bazy danych.

\subsection{Widok logiczny}

Ten widok przedstawia podział systemu na mniejsze moduły i programy zgodnie z logicznym przeznaczeniem tychże. W szczególności przedstawia on 
biblioteki wspólne dla kilku programów opisanych powyżej. Moduły opisane w tej sekcji to:

\begin{itemize}

\item {Moduły obsługi rozdania}

\begin{itemize}
\item Moduł dostępu do bazy danych - danych rozdania. 
\item Moduł przeprowadzania rozdania. 
\item Moduł grania. 
\item Moduł wyświetlania gry. 
\item Moduł komunikacyjny aplikacja kliencka - serwer rozdania. 
\end{itemize}

\item {Moduły obsługi turniejów i inicjowania rozgrywek towarzyskich}

\begin{itemize}
\item Moduł dostępu do bazy danych - danych turnieju. 
\item Moduł komunikacyjny aplikacja kliencka - serwer turnieju. 
\item Moduł wyświetlania organizacji stolików, podchodzenia do stolików, zapraszania. 
\item Moduł konfiguracji turnieju i zarządzania nim.
\item Moduł konfiguracji struktury turnieju, moduły definiujące schematy turniejów. 
\item Moduł podliczający i wyświetlający wyniki. 
\item Moduł nadzorowania turnieju przez serwer. 
\end{itemize}

\item {Moduły rankingowe}

\begin{itemize}
\item Moduł wyświetlający rankingi i pojedynczy ranking w aplikacji klienckiej. 
\item Moduł wyświetlający rankingi i pojedynczy ranking przez www. 
\item Moduł wyszukujący gracza i wysyłający rankingi. 
\item Moduł dostępu do bazy danych - rankingi. 
\item Moduł tworzenia rankingów przez www. 
\end{itemize}

\item {Moduły czatu}

\begin{itemize}
\item Moduł wyświetlający rozmowę w aplikacji klienckiej. 
\item Moduł komunikacji p2p w rozmowie. 
\item Program czatu, zestawiający te połączenia. 
\end{itemize}

\item {Moduły manipulujące danymi osobowymi}

\begin{itemize}
\item Moduł dostępu do bazy danych - osoby. 
\item Moduł autoryzacji od strony aplikacji klienckiej. 
\item Moduł autoryzacji od strony serwera. 
\item Moduł wyświetlania i zmieniania swoich danych w aplikacji klienckiej. 
\item Moduł obsługi żądań zmian danych. 
\item Moduł wyszukiwania osób i robienia statystyk. 
\end{itemize}

\item {Moduły manipulujące danymi reklam}

\begin{itemize}
\item Moduł dostępu do bazy danych - reklamy i reklamodawcy. 
\item Moduł wyświetlania reklamy w aplikacji klienckiej. 
\item Moduł zarządzania reklamami. 
\item Moduł interfejsu www z reklamodawcą i pracownikiem w kwestii reklam. 
\end{itemize}

\item {Moduły pomocy i FAQ}

\begin{itemize}
\item Moduł interfejsu do FAQ przez www dla pracownika i klienta. 
\item Manual. 
\end{itemize}

\item {Inne moduły aplikacji klienckich}

\begin{itemize}
\item Moduł menu. 
\item Aplikacja kliencka gracza. 
\item Rozszerzenia sędziego. 
\end{itemize}

\item {Inne moduły aplikacji serwerowych}

\begin{itemize}
\item Procesy: demon nadzorujący, serwer turnieju, serwer rozdania. 
\item Moduł utrzymywania i wznawiania połączenia z klientem. 
\item Moduł backupu bazy danych. 
\end{itemize}

\end{itemize}

\subsection{Widok procesów}
%AAA Zrobione - W diagramie komunikacji dolozyc krotnosci.
%AAA Zrobione - Strzaleczki przerobic na kurze nozki.

Widok ten opisuje dokładne role procesów oraz komunikację między nimi, kiedy łączność zostaje zawiązana a kiedy zerwana. Procesy w systemie to:
\begin{enumerate}
\item Jeden proces obsługujący czat.
\item Jeden proces - demon nadzorujący.
\item Dla każdego turnieju proces serwera turnieju.
\item Dla każdego rozdania proces serwera rozdania.
\item Aplikacja kliencka.
\item Serwer www (Apache).
\end{enumerate}

\subsection{Widok infrastruktury}

Widok ten opisuje rozmieszczenie procesów i modułów na maszynach oraz konieczną infrastrukturę połączeń.

\subsection{Widok implementacyjny}
%AAA Zrobione - Tradycja mowi, ze do gory nogami diagram implementacyjny.
%AAA Zrobione Brakuje wielu polaczen na diagramie implementacyjnym.
%AAA Zrobione - Np. serwery warstwie logicznej
%AAA Zrobione - Wartstwa 3 wyglada jak warstwa pomocnicza. Cos z tym zrobic.
%AAA Nie dogadaliście się - Aplikacje serdziowska i kliencka rozbic.

%!!! Serwer turnieju ---&gt; serwer generowania rozdan., a te konfiguracje---&gt; modul dostepu do danych konfiguracyjnbych.

%AAA Wyswietlanie czata --&gt; aplet czata.
%AAA Modul komunikacji aplikacja sedziowska -&gt; aplikacja kliencka jesli chodzi o rozgrywke.
%AAA Serwlet od rankingow podlaczyc do czegos.
%AAA Strona www -&gt; przegladarka www.
%AAA Duza strzalka rozbic.
%AAA Warstwy stad a warstwy diagramu komunikacji ? ? ?

% Patrz notatki w rozdziale
Widok ten przedstawia podział systemu na następujące warstwy oraz rozmieszczenie modułów w warstwach:
\begin{itemize}
\item Warstwa bazy danych.
\item Warstwa funkcji dostępowych do bazy danych.
\item Warstwa pojedynczej rozgrywki.
\item Warstwa turnieju.
\item Warstwa nadzoru nad rozgrywkami i turniejami.
\item Warstwa łączności z klientami (łączenie z aplikacjami + www).
\item Warstwa łączenia się z serwerami aplikacji klienckich.
\item Warstwa interfejsu aplikacji klienckich.
\end{itemize}

\subsection{Widok przechowywania danych}

Widok ten opisuje ogólną wizję bazy danych, na którą składają się następujące części:
\begin{itemize}
\item Informacje o pojedynczych rozgrywkach.
\item Informacje o turniejach.
\item Informacje o rankingach.
\item Informacje o osobach.
\item Informacje o reklamach.
\end{itemize}

\newpage
\section{Założenia i ograniczenia dotyczące architektury}

\subsection{UTF-8}
    Zarówno strony portalu, jak i wewnętrzna baza danych, będą stosowały kodowanie UTF-8, dlatego
    też aplikacje klienckie (przeglądarki internetowe) muszą interpretować ten standard kodowania. 
    
\subsection{Bridge Markup Language}
    System będzie wykorzystywał Bridge Markup Language (BML/BridgeML) (wersja 0.4) - zarówno do przechowywania
    całych rozgrywek w bazie danych, jak i do komunikacji
    między warstwami na poziomie wykorzystywanych protokołów sieciowych (baza danych \strzalka  serwer turnieju \strzalka  serwer rozdania \strzalka  aplikacja kliencka). 
    Istnieją już gotowe szablony XSLT prezentujące układy kart. System będzie z nich korzystał.  
    Standard BML będzie musiał zostać rozszerzony o znaczniki czasu (na potrzeby kontroli dynamiki rozdania przez sędziego)

\subsection{Protokoły sieciowe}
    Ze względu na komunikację serwer turnieju\strzalka serwer rozdania\strzalka aplikacja kliencka istnieje potrzeba opracowania protokołów sieciowch
    wykorzystujących TCP/IP. 
    
\subsection{Zagrożenia sieciowe}
    Ze względu na dużą ilość otwartych jednocześnie portów na serwerach dla ruchu internetowego istnieją zagrożenia
    ataków (w szczególności poprzez ,,zbombardowanie'' komunikatami). Kontrole tego w jak największym stopniu przekazujemy FireWallowi, 
    jednak trzeba uważać na to zagrożenie (krótkie timeout'y).

% Moje pomysly na ta sekcje:
% - konieczność opracowania protokolow sieciowych
% - aplikacje kliencie maja dzialac na wielu systemach
% - opracowanie protokołu jak ktoś się na chwilę rozłącza
% - liczby: kilka turniejów dziennie, kilkadziesiąt rozgrywek towarzyskich na raz, 100-200 na raz graczy zalogowanych

\newpage
\section{Przegląd przypadków użycia}

% Moim niestety zdaniem wlasciwie wszystkie subsubsection*e sa tutaj do omowienia, poza moze FAQ, manualem. 
% Wazny jest przeplyw informacji i kto z ktorym procesem co zalatwia.
% To jest wielka kobyla, ale na jeden subsubsection* wystarczy kilka zdan schematu jak to sie dzieje w architekturze.

Poniżej przedstawiono realizację biznesowych przypadków użycia z punktu widzenia architektury systemu.
Celem tego rozdziału nie jest bardzo dokładne opisanie działań systemu, co będzie opisane w 
osobnym dokumencie (Technicznych przypadkach użycia), a jedynie zapoznania czytelnika z zagadnieniem i 
przedstawienie podstawowych podjętych decyzji.

Niektóre przypadki użycia pominięto ze względu na ich prostotę, bądź pewnego rodzaju 
redundancję lub nieistotność wpływu na architekturę.
 
\subsection{Gracz i widz}
Gracz (lub widz) rozpoczynając pracę uruchamia za pomocą serwisu www aplikację kliencką, która 
podłącza się do demona nadzorującego.

\subsubsection*{Zalogowanie się gracza}
Aplikacja kliencka przekazuje dane demonowi nadzorującego, który w celu dokonania autoryzacji łączy się z 
bazą danych.
  
\subsubsection*{Rejestracja gracza}
Gracz rejestruje się za pomocą strony www. Jego dane zapisywane są w bazie danych.


\subsubsection*{Rozegranie pojedynczego rozdania}
Pojedyncze rozdanie nadzoruje serwer pojedynczego rozdania, który jest uruchamiany przez serwer turnieju
(w tym specjalny serwer nadzorujący partie towarzyskie). Serwer ten czerpie z bazy danych informacje o tym,
jakie rozdanie ma przeprowadzić. Aplikacje klienckie graczy i widzów podłączają się 
właśnie do tego serwera. Używając danych udostępnianych przez serwer turnieju i demona
nadzorującego, serwer ten powoduje rozegranie rozdania. Wyniki przekazuje serwerowi turnieju, który go 
uruchomił.

\subsubsection*{Rozegranie meczu brydżowego}
Z punktu widzenia architektury nie różni się od rozegrania zwykłego turnieju.

\subsubsection*{Przeglądanie dostępnych turniejów dla gracza}
Aplikacja kliencka wyświetla listę turniejów, którą udostępni jej demon nadzorujący.

\subsubsection*{Zarejestrowanie się do turnieju}
Aplikacja kliencka przesyła żądanie zarejestrowania do turnieju demonowi nadzorującemu, który zapisuje
odpowiednie informacje w bazie danych.

\subsubsection*{Wzięcie udziału w turnieju}
Aplikacja kliencka zalogowanego gracza dostaje informację od demona nadzorującego o tym, że wystartował turniej,
na który dany gracz jest zarejestrowany. Aplikacja jest łączona z serwerem tego turnieju. Serwer turnieju uruchamia
serwery poszczególnych rozdań i zapisuje wyniki w bazie danych.

\subsubsection*{Komunikacja gracza z sędzią w czasie trwania turnieju}
Aplikacja kliencka przesyła tekst wpisany przez gracza do serwera turnieju, który to przesyła komunikat do aplikacji sędziowskiej
i vice versa.

\subsubsection*{Modyfikacja własnych ustawień gracza}
Gracz za pośrednictwem formularza www zmienia ustawienia. Zmiany są zapisywane w bazie danych.

\subsubsection*{Oglądanie trwającej rozgrywki}
Serwer turnieju podłącza aplikacje widzów do odpowiednich serwerów rozdań.

\subsubsection*{Oglądanie byłych rozgrywek turniejowych (rozdań - jako gier)}
Demon nadzorujący na żądanie widza uruchamia serwer rozdania, który na podstawie danych zapisanych w bazie danych odtwarza rozdanie widzowi
za pośrednictwem jego aplikacji.

\subsubsection*{Oglądanie wyników wybranego turnieju i rankingu graczy}
Wszelkie informacje o zakończonych turniejach i rankingach udostępnia demon nadzorujący, uruchamiając ewentualnie pewne procesy pomocnicze.

\subsubsection*{Rozmowa gracza z innymi graczami}
Aplikacja kliencka komunikuje się z demonem nadzorującym, ten przekierowywuje żądania do procesu czatu.

\subsubsection*{Wyświetlanie reklam}
Za wyświetlanie reklam odpowiedzialne są aplikacje klienckie (które będą w tym celu komunikowały się z bazą danych lub dodatkowym
procesem pomocniczym) i witryn www.

\subsection{Sędzia}
Sędzia na początku swojej pracy uruchamia aplikację sędziego, która łączy się z demonem nadzorującym.

\subsubsection*{Zalogowanie sędziego do portalu}% Tytul
Autoryzacji dokonuje demon nadzorujący na podstawie danych zebranych przez aplikację kliencką i bazy danych.

\subsubsection*{Zgłoszenie gracza, który chce zostać sędzią}% Tytul
Aplikacja gracza przesyła odpowiednią informację do demona nadzorującego, który zapisuje ją w bazie danych.

\subsubsection*{Utworzenie nowego turnieju}% Tytul
Aplikacja sędziego przesyła dane nowego turnieju demonowi nadzorującemu, który zapisuje odpowiednie informacje w bazie danych.

\subsubsection*{Przeglądanie chętnych do turnieju i usuwanie ich}% Tytul
Demon nadzorujący udostępnia aplikacji sędziowskiej listę graczy zarejestrowanych na dany turniej. Aplikacja kliencka informuje 
proces demona nadzorującego o poczynionych zmianach. Ten nanosi je do bazy danych.

\subsubsection*{Wystartowanie własnego turnieju}% Tytul
Demon nadzorujący uruchamia serwer turnieju, łączy aplikację sędziego z tym turniejem. Serwer turnieju czeka na informację od
tej aplikacji o rozpoczęciu logowania graczy.

\subsubsection*{Usunięcie nieobecnych graczy}% Tytul
Serwer turnieju udostępnia aplikacji sędziowskiej listę graczy, w tym listę tych, którzy się jeszcze nie zalogowali. Sędzia za
pośrednictwem swej aplikacji ma możliwość nakazania serwerowi turniejowemu skreślenie ich z listy graczy.

\subsubsection*{Rozpoczęcie turnieju}% Bogdan mówi bankowy, Pochrybniak mówi dupa.
Serwer turnieju otrzymuje od aplikacji sędziego polecenie rozpoczęcia turnieju, o czym informuje aplikacje zalogowanych graczy.

\subsubsection*{Rozmowa gracza z graczem}% Tytul
Patrz: widok od strony gracza.

\subsubsection*{Nałożenie kary punktowej na gracza bądź parę}% Tytul
Sędzia za pośrednictwem swojej aplikacji informuje serwer turniejowy o podjętej decyzji, ten ją rejestruje i powiadamia odpowiednie 
aplikacje klienckie.

\subsubsection*{Usunięcie gracza z turnieju}% Tytul
Serwer turnieju udostępnia aplikacji sędziowskiej listę graczy. Sędzia za
pośrednictwem swej aplikacji ma możliwość nakazania serwerowi turniejowemu skreślenie gracza z listy graczy. Jeżeli gracz jest nadal
zalogowany do serwera turniejowego, jego aplikacja jest o tym informowana, a potem następuje zerwanie połączenia.


\subsubsection*{Obejrzenie rozgrywki z turnieju}% Tytul
Aplikacja sędziego za pośrednictwem serwera turnieju podłącza się do serwera konkretnego rozdania.

\subsubsection*{Podsumowanie wyników turnieju, ustalenie końcowego rankingu}% Tytul
Po zakończeniu każdej kolejki, serwer turnieju wysyła aplikacji sędziowskiej wyniki. Na koniec sędzia przy pomocy aplikacji opracowywuje 
(lub tylko akceptuje) ranking i wyniki. Po akceptacji wyniki są przesyłane serwerowi turnieju, który zapisuje wszystkie informacje o przebiegu w bazie
danych.


\subsection{Reklamodawca}

Wszelkie działania reklamodawcy polegają na poruszaniu się w ramach serwisu www. Wszelkie jego działania polegają na zapisaniu (rejestracja,
zgłoszenie reklamy) lub odczytaniu czegoś (autoryzacja, przegląd statystyk) z bazy danych.


\subsection{Pracownik www.bardzofajnyportal.pl}

Działania pracowników także są mało interesujące z punktu widzenia architektury, bowiem polegają na dokonywaniu zmian w bazie danych za
pomocą stworzonego dla nich serwisu www.

\newpage
\section{Widok logiczny}

\subsection{Omówienie}

Poniżej przedstawiony jest podział na moduły systemu rozgrywek brydżowych. Moduły dzielą się na kilka grup, zgodnie z ich funkcją:
\begin{description}
\item[Obsługa rozdania.] Obejmuje przechowywanie w bazie danych rozdań przed i po rozegraniu, przeprowadzanie rozdania przez serwer,
  wyświetlanie rozdania w aplikacji klienckiej, ustawianie rozdania, granie, oglądanie rozdania.
\item[Obsługa turniejów.] Obejmuje przechowywanie w bazie danych informacji o turniejach, konfigurację i rejestrowanie tychże, 
  przeglądanie listy turniejów, branie udziału w turnieju i zarządzanie nim, podliczanie wyników i komunikację gracze - serwer i sędzia - serwer.
\item[Obsługa rankingów.] Obejmuje przechowywanie w bazie danych informacji o rankingach i snapshotach tychże, wyświetlanie ich na stronie www oraz
w aplikacjach klienckich, wyszukiwania graczy oraz tworzenia nowych systemów punktacji.
\item[Obsługa czatu.] Obejmuje obsługę połączeń p2p komunikatora oraz zestawianie połączeń przez proces czatu.
\item[Obsługa danych osobowych.] Obejmuje przechowywanie w bazie danych informacji o osobach, protokoły autoryzacji, aktualizacji swoich danych oraz 
wyszukiwania osób i statystyk.
\item[Obsługa reklam.] Obejmuje wyświetlanie reklam, zarządzanie nimi oraz interfejs reklamodawcy.
\item[Obsługa FAQ i pomocy.] Obejmuje zadawanie pytań przez www i aplikację kliencką, przechowywanie FAQ, interfejs pracownika oraz manuale.
\item[Inne istotne części aplikacji klienckiej.] Menu, rozszerzenia sędziowskie.
\item[Inne istotne części serwerów.] Moduł podtrzymywania i wznawiania połączeń, moduł backupu danych.
\end{description}

Opisane zostały bardziej istotne części systemu wraz z ich najważniejszymi klasami.

\subsection{Najważniejsze komponenty}

Rozrysowanie przyporządkowania 
modułów do procesów i warstw znajduje się w schemacie logicznym.

\subsubsection{Moduły obsługi rozdania}

Moduły te służą obsłudze pojedynczego rozdania brydżowego. 

\begin{description}
\item[Moduł dostępu do bazy danych - danych rozdania.] Informacje o planowanym czy odbytym rozdaniu przechowywane są w bazie danych. Ten moduł to 
zbiór funkcji dostępowych do bazy danych, służących zapisowi i odczytowi informacji. Definiuje on klasę BazaDanychRozdanie, 
  z możliwością serializacji do bazy danych, losowej generacji rozdania i podania wyniku, jeśli rozdanie jest przeprowadzone.
\item[Moduł przeprowadzania rozdania.] Moduł przeprowadzania rozdania. Jest to podklasa klasy BazaDanychRozdanie do klasy Rozdanie, które potrafi ponadto
,,przeprowadzić się'', tj. zbierać od kolejnych klientów informacje o ruchach, weryfikować poprawność i zapamiętywać. W celu komunikacji korzysta z modułu
komunikacyjnego opisanego poniżej.
\item[Moduł grania.] Moduł będący częścią składową aplikacji klienckiej. Definiuje on klasę KlientRozdanie, które spamiętuje aktualny stan rozdania,
  przyjmuje polecenia położenia karty i zalicytowania, sprawdza poprawność, zapamiętuje to, co było już w lewach.
\item[Moduł wyświetlania gry.] Moduł wyświetlania klasy KlientRozdanie. Umożliwia wyświetlanie stanu aktualnego i przeszłego rozdania, licytacji, zaglądania
do dawnych lew, oraz podglądania kart graczy przez sędziego.
\item[Moduł komunikacyjny aplikacja kliencka - serwer rozdania.] Moduł obsługujący protokół komunikacyjny aplikacja - serwer. Składa się z dwóch części, 
  serwera i klienta. Potrafią nawiązać połączenie, przesłać informacje odnośnie kart i rozdania, odebrać decyzje gracza.
\end{description}

\subsubsection{Moduły obsługi turniejów i inicjowania rozgrywek towarzyskich}

Moduły te służą przeprowadzaniu turniejów i rozgrywek towarzyskich. Rozgrywki towarzyskie z punktu widzenia logicznego przypominają ,,nieustający turniej'' i tak są traktowane przez system.

\begin{description}
\item[Moduł dostępu do bazy danych - danych turnieju.] Definiuje klasę BazaDanychTurniej. Informacje o wszystkich turniejach są przechowywane w bazie 
danych. Klasa ta potrafi serializować się do bazy danych. 
\item[Moduł komunikacyjny aplikacja kliencka - serwer turnieju.] Są to dwie części - kliencka i serwera. Potrafią one: przesłać informacje konfiguracyjne
od sędziego do serwera, przekazać sędziemu dotychczasowe wyniki turnieju, przekazać klientowi informację o stolikach, odebrać informację o podejściu do 
stolika, odebrać od klienta decyzję o opuszczeniu / przyłączeniu się do turnieju, odebrać i wysłać wyniki.

\item[Moduł wyświetlania organizacji stolików, podchodzenia do stolików, zapraszania.] Moduł jest częścią składową aplikacji klienckiej. Potrafi wyświetlić
aktualny stan stolików, umożliwia zapraszanie do stolików w przypadku rozgrywek towarzyskich oraz automatyczne podchodzenie w przypadku turnieju. Przeprowadza
rozgrywkę od strony logicznej.
Wyświetla schemat turnieju. Definiuje klasę KlientTurniej oraz jej podklasę SędziaTurniej.
\item[Moduł konfiguracji turnieju i zarządzania nim.] Część rozszerzeń sędziowskiej aplikacji. Definiuje interfejs zakładania nowego turnieju, zmiany jego
konfiguracji, uruchamianie go.
\item[Moduł konfiguracji struktury turnieju, moduły definiujące schematy turniejów.] Część rozszerzeń sędziowskiej aplikacji. Definiuje klasę 
SchematTurnieju, będący częścią składową KlientTurniej. Ona to ma funkcje mówiące, kto gdzie ma teraz pójść w turnieju. Jest to klasa abstrakcyjna,
  jej podklasy to poszczególne schematy turniejów.
\item[Moduł podliczający i wyświetlający wyniki.] Moduł po stronie aplikacji sędziowskiej, wyświetlający i zarządzający wynikami turnieju.
\item[Moduł nadzorowania turnieju przez serwer.] Definiuje klasę Turniej, podklasę BazaDanychTurniej. Turniej ma metodę ,,przeprowadźSię'', która powoduje
ruszenie turnieju. Turniej korzysta z modułu komunikacyjnego po to, ażeby zbierać decyzje od sędziego i wysyłać graczom odnośnie tego, dokąd mają się udać. Korzysta z klasy SchematTurnieju, a raczej podklasy odpowiadającej temu turniejowi. Uruchamia procesy rozdań.
\end{description}

\subsubsection{Moduły rankingowe}

Moduły te służą wyświetlaniu rankingów i tworzeniu nowych systemów punktowych.

\begin{description}
\item[Moduł wyświetlający rankingi i pojedynczy ranking w aplikacji klienckiej.] Część aplikacji klienckiej wyświetlający rankingi.
\item[Moduł wyświetlający rankingi i pojedynczy ranking przez www.] Wyświetla rankingi w postaci stron html.
\item[Moduł wyszukujący gracza i wysyłający rankingi.] Część demona nadzorującego oraz bibliotek do stron www. Korzystając z klasy Ranking zdefiniowanej
przez moduł bazy danych, wyszukuje graczy w bazie i potrafi wysłać ranking do klienta.
\item[Moduł dostępu do bazy danych - rankingi.] Moduł definiuje klasę Ranking, która potrafi się przeczytać z bazy danych, zapisać do niej, stworzyć 
snapshota, przeczytać go. Definiuje abstrakcyjną klasę LiczydłoRankingu, która jest częścią Rankingu, która potrafi mają zbiór graczy posortować 
ich zgodnie z punktacją. Wszelkie podklasy LiczydłoRankingu definiują nowy ranking.
\item[Moduł tworzenia rankingów przez www.] Moduł umożliwiający tworzenie nowych podklas LiczydłoRankingu przez www.
\end{description}

\subsubsection{Moduły czatu}

Moduły te zapewniają możliwość swobodnej rozmowy między graczami i między graczem a sędzią. Klient prosi o rozmowę z innym użytkownikiem, wówczas
serwer zestawia połączenie między nimi i rozmowa odbywa się bez pośrednictwa serwera.

\begin{description}
\item[Moduł wyświetlający rozmowę w aplikacji klienckiej.] Przypomina wyglądem okienko GG. Potrafi wyświetlać emotikony :P.
\item[Moduł komunikacji p2p w rozmowie.] Moduł komunikacyjny - przesyłania informacji z rozmowy.
\item[Program czatu, zestawiający te połączenia.] Proces działający na serwerze. Dostaje jako argument połączenie z klientem, który chce rozmawiać z innym.
Łączy się z adresatem, zestawia połączenie.
\end{description}

\subsubsection{Moduły o osobach}

Moduły te zarządzają danymi osobowymi graczy oraz autoryzacją. 

\begin{description}
\item[Moduł dostępu do bazy danych - osoby.] Definiuje klasę BazaDanychOsoba, która potrafi serializować się do bazy danych, przechowuje informację
o osobie. 
\item[Moduł autoryzacji od strony aplikacji klienckiej.] Definiuję klasę Ja, która jest tworzona na początku działania aplikacji klienckiej. Użytkownik
podaje jej login i hasło, ta łączy się z serwerem, loguje się. Potrafi dalej zautoryzować użytkownika przy połączeniach z serwerami rozdań i turniejów.
\item[Moduł autoryzacji od strony serwera.] Tworzy podklasę klasy Osoba -- klasę Zalogowany. Na podstawie przesłanych informacji od klienta, potrafi stwierdzić,
  kto się podłączył i ustawić ,,siebie'' na tę osobę.
\item[Moduł wyświetlania i zmieniania swoich danych w aplikacji klienckiej.] Tworzy klasę Ja, podklasę klasy MojeDane, potrafi wyświetlać i wysłać do serwera 
informację o zmianie swoich danych.
\item[Moduł obsługi żądań zmian danych.] Tworzy podklasę klasy BazaDanychOsoba -- klasę Osoba. Osoba potrafi się komunikować z klientem wysyłając dane i 
pobierając zmiany. 
\item[Moduł wyszukiwania osób i robienia statystyk.] Potrafi wyszukiwać osoby w bazie danych. Jest tu również zbiór funkcji w bazie danych do robienia
statystyk dla pracowników \wfp.
\end{description}

\subsubsection{Moduły o reklamach}

Moduły poniższe umożliwiają zarządzenie reklamami przez pracowników i reklamodawców oraz wyświetlanie ich na stronach i w aplikacjach klienckich.

\begin{description}
\item[Moduł dostępu do bazy danych - reklamy i reklamodawcy.] Definiuje klasy BazaDanychReklama i BazaDanychReklamodawca, potrafiące się serializować do bazy danych. Klasa BazaDanychReklamodawca posiada od razu policzone w bazie danych statystyki - liczba wyświetlonych jego reklam, jego
stan finansowy. Klasa BazaDanychReklama posiada od razu policzone w bazie danych statystyki - liczbę wyświetleń.
\item[Moduł wyświetlania reklamy w aplikacji klienckiej.] Moduł pobierający z serwera reklamę i wyświetlający ją w odpowiednim miejscu aplikacji klienckiej.
\item[Moduł zarządzania reklamami.] Moduł, będący częścią demona nadzorującego i stron www, decyduje, którą reklamę wyświetlić, komunikuje się z klientem,
  aktualizuje statystyki reklamy w bazie danych,
\item[Moduł interfejsu www z reklamodawcą i pracownikiem w kwestii reklam.] Zbiór dynamicznych stron www, dających reklamodawcy i pracownikowi możliwości
opisane w Przypadkach Użycia.
\end{description}

\subsubsection{Moduły pomocy i FAQ}

Moduły poniższe zapewniają mechanizm działania FAQ oraz Manuali.

\begin{description}
\item[Moduł interfejsu do FAQ przez www dla pracownika i klienta.] Aplikacja kliencka ma odnośnik do strony www z FAQ. Na tej stronie dostępna jest możliwość
przeglądania FAQ z bazy danych i zadania nowego pytania. Pracownik może odpowiadać na zadane pytania. Ten moduł to zbiór dynamicznych stron www obsługujących
tę funkcjonalność wraz z dostępem do bazy danych, gdzie są przechowywane pary pytanie - odpowiedź.
\item[Manual.] Manuale w postaciach texinfo i .hlp, dostępne do ściągnięcia z witryny (statyczne).
\end{description}

\subsubsection{Inne moduły aplikacji klienckich}

Poniżej opisane są idee oraz moduły, które nie zmieściły się w powyższych grupach, a dotyczą aplikacji klienckiej.

\begin{description}
\item[Moduł menu.] Moduł definiuje klasę Menu i MenuPrzycisk, które są odpowiedzialne za funkcjonowanie menu w aplikacji klienckiej. 
\item[Aplikacja kliencka gracza.] Aplikacja kliencka gracza dokładniej jest opisana w Widoku Procesów. Zespala ona moduły klienckie w aplecie Javy.
\item[Rozszerzenia sędziego.] Aplikacja kliencka może być rozszerzona o możliwości sędziego. Aplikacja sędziego to aplikacja gracza z dodatkową 
funkcjonalnością. Rozwiązanie takie daje to, że nie każdy gracz musi ściągać kod potrzebny tylko sędziemu.
\end{description}

\subsubsection{Inne moduły aplikacji serwerowych}

Poniżej opisane są idee oraz moduły, które nie zmieściły się w powyższych grupach, a dotyczą aplikacji serwerowych.

\begin{description}
\item[Procesy: demon nadzorujący, serwer turnieju, serwer rozdania.] Działanie systemu zapewniają te trzy procesy oraz serwer www i baza danych. Dokładniej
opisane są one w Widoku Procesów.
\item[Moduł utrzymywania i wznawiania połączenia z klientem.] Jest to niskopoziomowy moduł, obejmujący wysyłanie pojedynczych danych do klienta, obsługę
puli klientów, nawiązywanie zerwanych połączeń.
\item[Moduł backupu bazy danych.] Ten moduł jest zestawem skryptów bazy danych umożliwiającym zachowanie stanu bazy danych i odtworzenie po awarii.
\end{description}

\subsection{Realizacja przypadków użycia}

Poniżej przedstawione jest kilka przykładów, jak za pomocą powyższych modułów realizowane jest kilka zadań serwisu.

\subsubsection{Rozegranie towarzyskiej partyjki Stencel -- Diks kontra Mincer -- Engel}

Wszyscy czterej gracze są zalogowani, mają uruchomione swoje aplikacje klienckie graczy. Pan Stencel postanawia zagrać partyjkę, klika dwukrotnie
na listę zalogowanych użytkowników na pana Diksa. Lista jest stale aktualizowana, aplikacja kliencka porozumiewa się z demonem nadzorującym 
w tej kwestii, a ten trzyma pulę zalogowanych użytkowników.

Pan Stencel, klikając na pana Diksa, wysyła do demona żądanie rozmowy. Serwer powiadamia o tym fakcie proces czatu, ten zestawia połączenie p2p
między Stenclem i Diksem. U pana Diksa pojawia się okienko rozmowy. Panowie ustalają, że wspaniale by było zagrać partyjkę z parą Mincer -- Engel.

Pan Stencel klika na opcję ,,nowy stolik'', do serwera zostaje wysłane stosowne żądanie. Serwer umieszcza w bazie danych informację o nowym rozdaniu
  towarzyskim, z losowanymi kartami, nadzorowanym przez p. Stencla, a następnie uruchamia serwer pojedynczej rozgrywki do tego rozdania i informuje o tym
  aplikację Stencla. Aplikacja ta podłącza się do serwera rozdania i na komputerze pana Stencla pojawia się okienko rozdania. W tym czasie do wszystkich
  jest wysyłana informacja aktualizacji wyglądu stolików - został dodany nowy stolik.

Pan Diks, widząc nowy stolik, klika czym prędzej na niego. Jego aplikacja nawiązuje połączenie z serwerem rozdania. Zasiada on naprzeciwko pana Stencla,
  klikając na to miejsce. 

W tym czasie do stolika podchodzi też pan Onak. Jego aplet nawiązuje połączenie z serwerem rozdania. Chciałby zagrać, więc klika na jednym z wolnych miejsc.
Zasiada, gdyż nic mu na to nie zabrania. Po chwili jednak pan Stencel, założyciel stolika, widząc co się święci, klika na gracza Onaka i wyrzuca go z tego
miejsca. Wysyła on do serwera rozdania żądanie usunięcia gracza, serwer rozdania wysyła do aplikacji pana Onaka, że niestety musi on opuścić miejsce, 
  choć wciąż może obserwować rozgrywkę z pozycji widza.

Pan Stencel w międzyczasie klika na panią Mincer i pana Engela a następnie klika ,,zaproś do stolika''. Jego aplikacja wysyła odpowiedni komunikat do demona
nadzorującego. Ten komunikuje się z zainteresowanymi, u nich wyświetla się okienko informujące o zaproszeniu. Potwierdzają oni chęć i nawiązują połączenie
z serwerem rozdania. W momencie, gdy wszyscy są podłączeni, pan Stencel może kliknąć ,,gramy'' i wysyła do serwera rozdania żądanie rozpoczęcia.

Serwer rozdania wysyła do wszystkich ich karty. Rozpoczyna się licytacja. Serwer rozdania od każdego po kolei zbiera kolejne odzywki i wysyła do wszystkich
innych obecnych przy stoliku zagrania (również do widza Onaka). Po tym, gdy stwierdzi koniec licytacji, wysyła do wszystkich komunikat, że następuje początek
rozdania. Czeka na wist od wistującego, po czym ?wysyła? karty dziadka do wszystkich obecnych przy stoliku; ich aplikacje wyświetlają informację.
Następuje rozgrywka, serwer zbiera od kolejnych ludzi ich decyzje co do kart i wysyła je do innych obecnych przy stoliku. Moduł wyświetlania pokazuje
wszystkim co się dzieje.

Po skończonej rozgrywce wszyscy opuszczają stolik, serwer zapisuje wyniki do bazy danych po czym rozłącza połączenia i ginie. Aplikacje klienckie
zamykają okno z rozgrywką.

\subsubsection{Rozegranie turnieju o mistrzostwo wydziału, sędziuje pan Deminet}

Pan Deminet chciał przeprowadzić turniej o mistrzostwo wydziału w brydża, jest sędzią portalu brydżowego \wfp. W tym celu po zalogowaniu się i nawiązaniu
połączenia z serwerem (zadziałał moduł autoryzacji z obu stron połączenia), kliknął na opcję ,,nowy turniej''. Otworzyło mu się okienko konfiguracji
turnieju (moduł konfiguracji turnieju). W tym oknie zaznaczył datę turnieju - za dwa tygodnie oraz to, że ludzie powinni rejestrować się jak najszybciej
jak to możliwe, do dnia przed turniejem, oraz podał hasło, które musi podać każdy uczestnik turnieju by móc grać. Kliknął OK, jego aplikacja
wysłała do demona nadzorującego żądanie zarejestrowania turnieju, które ten spełnił. W tym czasie panu Deminetowi ukazało się okienko wyboru
schematu rozgrywek i liczby graczy. Przewiduje on około 40-50 graczy, a schemat standardowy - w kółku, na tych samych losowych rozdaniach, parami.
Zatwierdził, po czym jego aplikacja wysłała żądanie do demona, który zaktualizował odpowiedni rekord w bazie danych.

W tym czasie pan D. wysłał za pośrednictwem U-Maila informację do wszystkich o turnieju wraz z hasłem, które trzeba podać. W ten sposób będzie to turniej
Przeznaczony tylko dla ludzi z wydziału.

Pan Ciekawski, który akurat miał wówczas dyżur w \wfp, odświeżył stronę www z listą turniejów i zobaczył nową propozycję turnieju pana D. Pan C.
kliknął na turniej, ukazały mu się szczegóły turnieju. Jako, że chodził z panem D. do jednej podstawówki, nie wahał się długo i zatwierdził
turniej. Serwer www odhaczył odpowiednią flagę w rekordzie bazy danych. Od tego czasu wszyscy mogą się rejestrować do turnieju podawszy poprawne hasło.

Przez kolejne dni 19 par zgłosiło się do uczestnictwa w turnieju. Odbyło się to następująco: jedna osoba z pary, po zalogowaniu się, przegląda listę
turniejów (jego aplikacja ściąga ją od demona), wybiera turniej pana D., klika ,,zarejestruj się z...'' i wpisuje login partnera. Zostaje wysłane żądanie
do demona, który zapisuje fakt rejestracji w bazie danych. Następnie partner loguje się do systemu, wchodzi do odpowiedniego turnieju podobnie jak jego
partner i patrzy, że ktoś go poprosił o udział w turnieju (te informacje jego aplikacja uzyskała od demona). Klika OK. po czym demon aktualizuje rekord w bazie danych - para jest już zarejestrowana.

Na pół godziny przez turniejem pan D. loguje się do demona, klika ,,aktualne turnieje'' i następnie ,,turniej MIMUW''. Demon zestawia jego połączenie
z już uruchomionym serwerem turnieju. Pan D. klika, że turniej może ruszyć. Od tej chwili gracze mogą się logować do serwera turnieju. Gracz taki klika
na listę ?aktualne turnieje?, następnie ,,turniej MIMUW'' i wpisuje hasło. Jeśli wszystko jest OK, demon zestawia mu połączenie z serwerem turnieju.

Pan D., w momencie gdy turniej ma się rozpocząć, odświeża listę zalogowanych graczy. Okazuje się, że jedna osoba się nie stawiła. Decyduje się na nią nie
czekać i usuwa jego partnera z gry. Serwer rozłącza z nim połączenie. Jako, że pan D. odznaczył turniej jako ,,prywatny'' i ,,zamknięty'', nikt nie ma prawa
być na nim widzem.

Pan D., jako że schemat standardowy turnieju pasuje do każdej liczby par, nie musi nic zmieniać i klika ,,start''. Do wszystkich aplikacji
serwer turnieju wysyła informację, że turniej się rozpoczął i przyporządkowuje ich do stolików, wysyła też schemat ?chodzenia? między stolikami.
W aplikacji klienckiej moduł wyświetlania stolików wyświetla tenże schemat.

Serwer turnieju zaczyna pierwszą rundę rozdań, uruchamia dla każdego rozdania serwer rozdania, który działa podobnie jak opisano w poprzednim punkcie.
Serwer turnieju zestawia połączenia odpowiednich graczy z odpowiednimi serwerami rozdań. Po zakończeniu kolejki rozpoczyna kolejną.

W międzyczasie jedna para zrezygnowała, serwer wysłał pytanie o akceptację do pana D., który potwierdził. Od tego czasu ich miejsce jest puste,
  liczyć będzie, jakby grali ,,średnią sali''.

Po każdej kolejce serwer turnieju wysyła do pana D. wyniku turnieju. Pan D. klika na poszczególne stoliki i jego moduł wyświetlający wyświetla mu rozdania.

Na koniec panu D. wyświetla się ranking końcowy proponowany przez aplikację na podstawie wybranego przez niego schematu rozgrywek. Pan D. akceptuje i jego
aplikacja wysyła wyniki do serwera, który ten zapisuje w bazie danych i wysyła do każdego innego gracza. Następnie zamyka połączenia i ginie.

\subsubsection{Gracz Michał K. szuka odpowiedzi na nurtujące go pytanie}

Gracz Michał ma pytanie, ale sądzi, że mógł ktoś je zadać. W tym celu klika w aplecie na ,,FAQ'' i otwiera się okienko przeglądarki z FAQ i 
wyszukiwaniem w FAQ. Wpisuje w wyszukiwarkę słowo kluczowe pytania i okazuje się, że niestety nie ma zbliżonego pytania w bazie danych. W związku
z tym na stronie klika na ,,nowe pytanie'', czyta dużo ostrzeżeń, aby najpierw się upewnił, czy jego pytania już nie ma w FAQ, po czym wpisuje 
treść pytania i kilka ,,OK''. Jego przeglądarka wysyła pytanie do serwera www, który umieszcza je w bazie danych.

Pan Ciekawski mając dyżur spostrzega na stronie administratora pytanie Michała. Odpowiada na nie i klika OK, serwer www zapisuje odpowiedź w bazie danych.
Jak Michał następnym razem się zaloguje, dostanie informację, że na jego pytanie uzyskał odpowiedź.

\subsubsection{Sędzia Piotr T. zmienia swój adres e-mail}

Piotrowi zlikwidowano jedno konto, które podał jako adres w serwerze \wfp. Aby to zmienić, loguje się za pomocą apletu i klika ,,moje dane''. Powstaje
instancja klasy MojeDane, która ściąga od demona dane, który wyciąga je z bazy danych tworząc instancję klasy Osoba. Piotr modyfikuje adres email i klika
OK, dane zostają wysłane do demona, który na ich podstawie tworzy klasę Osoba i każe jej zapisać się w bazie danych.

\subsubsection{Reklamodawca Grzegorz G. sprawdza, jak jego baner funkcjonuje}

Reklamodawca Grzegorz chciałby zobaczyć, ile wyświetleń ma jego baner. W tym celu wchodzi na stronę reklamodawców serwera brydżowego \wfp \ i loguje się.
Klika ,,moje banery'', wyświetla się lista jego banerów (tylko jeden) i klika na niego. Na tej dynamicznie wygenerowanej stronie www pojawia się
informacja z bazy danych, że jego baner już został 541 razy wyświetlony. Usatysfakcjonowany Grzegorz klika wyloguj i identyfikator sesji www zostaje
usunięty.

\subsubsection{Pracownik \wfp\ pan Jakub Ciekawski dodaje swój ranking}

Pan Jakub Ciekawski postanowił dodać ranking liczący punkty następująco: każda wygrana o więcej niż jedną lewę niż kontrakt liczy się za punkt,
  ale tylko w weekendy. W tym celu loguje się na strony www administratora, i klika ,,nowy ranking''. Tam ustawia pola -- kiedy rozdania się liczą
  i wpisuje warunek na liczenie punktów (moduł dodawania rankingów interpretuje wyrażenia ze zmiennymi np. ile lew, jaki kontrakt itd.). Klika
  "ok" i moduł nowych rankingów tworzy nowy algorytm liczenia rankingów i dodaje go do bazy danych.

% Ja dałem takie przykłady, jak komuś przyjdzie do głowy jakaś dziedzina, której nie opisałem, niech dodaje.

\newpage
\section{Widok procesów} % To jest w sumie chyba cale zrobione juz.

Jak wynika z ogólnej architektury - punktu 2 - działać będą następujące procesy: serwer rozdania, serwer turnieju, demon nadzorujący, 
  aplikacja kliencka gracza, aplikacja kliencka sędziego, serwer www, proces czatu, baza danych.

\subsection{Serwer pojedynczego rozdania}

Serwer pojedynczego rozdania jest procesem pomocniczym. Działa on jednoprzebiegowo robiąc:
\begin{enumerate}
\item Jako argument dostaje numer rozdania, które jest zapisane w bazie danych.
\item Łączy się z bazą danych.
\item Otrzymuje informacje nt. graczy rozdania, typu rozdania (towarzyskie, turniejowe) 
  oraz kartach (ew. w bazie danych jest informacja ,,wylosować rozdanie'').
\item Oczekuje na połączenia od graczy. W przypadku rozdania towarzyskiego obsługuje zapraszanie graczy do stolika.
\item Wysyła karty graczom.
\item Przeprowadza licytację.
\item Przeprowadza rozgrywkę.
\item Przekierowuje prośby o rozmowę do procesu czatu.
\item Zapisuje wynik do bazy danych.
\item W przypadku rezygnacji któregoś z graczy zapisuje ten fakt też do bazy danych.
\item Informuje swojego zleceniodawcę (demon nadzorujący lub serwer turnieju) o końcu rozdania.
\end{enumerate}

\subsection{Serwer turnieju}

Serwer turnieju przeprowadza jeden, wcześniej zdefiniowany turniej. Zostaje uruchomiony przez demon nadzorujący na krótko przed czasem startu turnieju (rzędu
    pół godziny). Działa on następująco:
\begin{enumerate}
\item Jako argument dostaje numer turnieju o którym informacje są zapisane w bazie danych.
\item Pobiera te informacje z bazy danych.
\item Czeka na podłączenie sędziego turnieju (założyciela).
\item Czeka na potwierdzenie od sędziego uruchomienia turnieju.
\item Czeka na podłączenia graczy. Informuje sędziego o ewentualnych brakach i odbiera i obsługuje decyzje sędziego 
(wyrzucanie par, zmiana konfiguracji rozdań).
\item Czeka na potwierdzenie od sędziego o ruszeniu turnieju.
\item Rusza turniej, nadzoruje wykonanie kolejnych rozdań (uruchamia serwery rozdań), zbiera wyniki i zaprasza kolejnych graczy do kolejnych stolików.
\item Obsługuje chwilowe przerwania w połączeniach od graczy, sygnalizuje sędziemu, jeśli jakiś gracz za długo jest niepołączony (kilkanaście sekund).
\item Umożliwia widzom oglądanie dawniejszych i obecnych rozdań.
\item Umożliwia sędziemu oglądanie dawniejszych i obecnych rozdań, wraz z kartami graczy.
\item Przyjmuje kary i informuje o nich graczy.
\item Przekierowuje prośby o rozmowę do procesu czatu.
\item Wysyła do apletu sędziowskiego wyniki zakończonych rozdań.
\item Na koniec przyjmuje od apletu sędziowskiego wyniki turnieju i punktację.
\item Zapisuje wyniki rozdań oraz turnieju do bazy danych.
\item Powiadamia demon o zakończeniu turnieju bądź też jego zerwaniu.
\end{enumerate}

\subsection{Demon nadzorujący}

Demon nadzorujący pracuje stale, spełnia on następujące funkcje:
\begin{itemize}
\item Do niego podłączają się jako pierwsze aplikacje klienckie.
\item Przeprowadza autoryzację (logowanie) klientów (graczy i sędziów).
\item Uruchamia procesy turniejów. 
\item Przekierowuje prośby o rozmowę do procesu czata.
\item Udostępnia listę aktualnie zalogowanych graczy oraz odbywających się towarzyskich rozgrywek.
\item Przyjmuje prośby o towarzyską rozgrywkę, uruchamia proces pojedynczej rozgrywki, wrzucając wcześniej graczy do stolika do bazy danych.
\item Przyjmuje prośby o towarzyski mecz, uruchamia proces turnieju, wrzucając wcześniej konfigurację do bazy danych.
\item Zatwierdza w bazie danych wyniki rozgrywek po zakończeniu towaszyskich rozdań i meczy.
\item Przyjmuje prośby o rejestracje na turniej.
\item Przyjmuje od sędziego prośby o nowy turniej i przyjmuje od niego konfigurację.
\item Przyjmuje od sędziego decyzje o wyrzuceniu chętnego z turnieju.
\item Udostępnia listę rankingów oraz rankingi aplikacjom klienckim.
\end{itemize}

Jest możliwe, że demon ten będzie tworzył podprocesy do małych zadań (np. definiowania turnieju), pozostaje to w kwestii decyzji późniejszej, nie ma wpływu
na ogólną architekturę projektu.

\subsection{Aplikacja kliencka: gracza, widza i sędziego}

Aplikacja kliencka działa na komputerze klienta, z poziomu przeglądarki, jest rozbudowanym apletem Javy. Po uruchomieniu łączy się z demonem nadzorującym,
  przeprowadza autoryzację, a następnie wyświetla menu oraz listę aktualnych towarzyskich rozdań oraz zalogowanych graczy. Jeśli jest to aplet sędziowski
  (jest on osobnym rozbudowanym apletem gracza, aby nie każdy użytkownik musiał ściągać moduły sędziego) i zalogowany jest sędzią, w menu pojawiają się 
  dodatkowe opcje.

Możliwe opcje dostępne graczowi i widzowi:
\begin{itemize}
\item {\bf{Podejdź do stolika.}} Kliknięcie na stolik na liście stolika powoduje otwarcie okienka ze stolikiem. Następuje zestawienie połączenia
z serwerem turnieju. W przypadku trwającej rozgrywki można 
kliknąć na jakąś starą lewę widoczną obok, pokazuje się wówczas lewa. Jeśli jeszcze rozgrywka nie zaczęła się, można zasiąść przy stoliku na jednym
z wolnych miejsc, klikając na nie. Stolikiem też jest aktualnie trwający mecz towarzyski.
\item {\bf{Porozmawiaj z kimś.}} Kliknięcie na gracza powoduje prośbę do demona o otwarcie połączenia z czatem i otwarcie okienka z czatem z innym graczem.
\item {\bf{Lista rankingów.}} Kliknięcie na tę opcję powoduje wyświetlenie listy rankingów ściągniętej od demona. Kliknięcie na ranking powoduje ściągnięcie
od demona rankingu i wyświetlenie go. Jest też pole wyszukania gracza, po wpisaniu loginu następuje zapytanie do demona o ten login. W wyniku wyświetla się
pozycja i liczba punktów gracza w aktualnym rankingu.
\item {\bf{Lista turniejów.}} Kliknięcie na tę opcję powoduje wyświetlenie listy turniejów, na które gracz mógłby się zarejestrować lub jest zarejestrowany.
Kliknięcie na turniej powoduje wyświetlenie danych o turnieju oraz opcję zarejestruj się / wyrejestruj się. Wszystkie dane są ściągane od demona.
\item {\bf{Aktualne turnieje.}} Kliknięcie na tę opcje powoduje wyświetlenie aktualnie trwających i zaczynających się turniejów. Jeśli turniej już
się rozpoczął, graczowi pozostaje rola widza. Wyskakuje drugie okienko z schematem stolików i rozdań, gracz może oglądać aktualne i starsze rozdania
klikając w stoliki, tak samo jak w towarzyskich rozdaniach. (obsługuje to ten sam moduł biblioteczny). Jeśli turniej się nie rozpoczął, gracz może
zalogować się do niego jako gracz, jeśli się do niego wcześniej zarejestrował. W obu sytuacjach aplikacja kliencka prosi demon o połączenie z serwerem
turnieju, dalsze pytania odbywają się z serwerem turnieju. W przypadku dołączenia się do turnieju otwiera się nowe okno i aplikacja łączy się z serwerem
turnieju. Wyświetlony jest rozkład stolików oraz plan rozgrywek, jest to realizowane przez ten sam moduł co rozgrywki towarzyskie. W tej sytuacji:
\begin{enumerate}
\item Przechodzenie od stolika do stolika odbywa się automatycznie.
\item Jest też specjalna możliwość czatu z sędzią.
\item Jest opcja ,,rezygnuj'', która powoduje wysłanie do sędziego prośby o rezygnację.
\end{enumerate}
\item {\bf{Dawniejsze turnieje.}} Kliknięcie na tę opcję powoduje wyświetlanie listy ostatnich turniejów. Kliknięcie na turniej powoduje wyświetlenie
informacji szczegółowych o turnieju, odnośnika ,,przebieg'' oraz ,,wyniki''. Kliknięcie na ,,przebieg'' powoduje otwarcie drugiego okna, obsługiwanego przez
moduł ,,stolików'', który łącząc się z demonem ściąga informacje o przebiegu turnieju. Kliknięcie na ,,wyniki'' powoduje ściągnięcie od demona wyników 
turnieju. Cała komunikacja odbywa się z demonem.
\item {\bf{Wyloguj.}} Powoduje rozłączenie z demonem.
\end{itemize}

Dodatkowo aplikacja sędziowska z zalogowanym sędzią dostarcza opcje:

\begin{itemize}
\item {\bf{Stwórz nowy turniej.}} Wyświetla się menu ustawiania opcji turnieju, w momencie ustawienia wszystkich dane te są wysyłane do demona. Dane
są opisane dokładniej w Przypadkach Użycia.
\item {\bf{Moje turnieje.}} Wyświetla się ściągnięta lista turniejów tego sędziego, każdy turniej ma jedną z trzech flag:
\begin{enumerate}
\item Niezaakceptowany. Turniej jeszcze nie został zaakceptowany przez pracownika \wfp, kliknięcie na niego powoduje otworzenie okna dialogu i możliwość
zmiany danych ustawionych przy zakładaniu turnieju.
\item Zaakakceptowany. Turniej został zaakceptowany. Są przy nim dwa linki: jeden prowadzi do okna dialogu na temat ustawień dokładnych turnieju,
  jak przy rejestracji, drugi do listy zarejestrowanych graczy. Każdego gracza można wyrzucić. Zmiany realizowane są przez demon.
\item Do odbycia się. Turniej lada moment się odbędzie. Kliknięcie na niego powoduje zestawienie połączenia z serwerem turnieju i otworzenie nowego 
okna turnieju. W tym oknie dostępne są (komunikacja odbywa się już z serwerem turnieju) poza możliwościami gracza:
\begin{itemize}
\item Możliwość wyświetlenia listy graczy, z informacją czy są dostępni i możliwością wyrzucenia oraz nałożenia kary.
\item Przy podejściu do stolika można zajrzeć do kart graczy na ręce.
\item Możliwość przerwania turnieju i usunięcia gracza.
\item Na koniec otwiera się okno zatwierdzania wyników i nakładania kar na koniec.
\end{itemize}
\end{enumerate}
\end{itemize}

\subsection{Serwer www Apache z serwerem JBoss}

Na maszynie do www działa serwer www Apache wraz z dynamicznie tworzonymi stronami projektu. Obok serwera Apache działa serwer JBoss, na którym działają 
skrypty generujące strony www. Strony służą do rejestracji nowych graczy, oglądania rankingów, jest to również pole działania pracowników \wfp\ i 
reklamodawców. Dokładny spis stron znajduje się w wizji logicznej. Architektura serwera Apache wraz z serwerem JBoss i maszyną Javy nie jest
przedmiotem tego dokumentu.

\subsection{Proces czatu}

Proces czatu obsługuje rozmowy one-to-one graczy i sędziów. Dostaje on polecenie ,,gracz taki chce przemówić do gracza takiego'', prosi on demon
nadzorujący o zestawienie połączenia z drugim graczem po czym zestawia bezpośrednie połączenie między nimi do rozmowy. Rozmową zajmują się aplety.

\subsection{Baza danych}

Baza danych jest bazą zgodną z Oracle 10i, działającą przez TCP. Architektura działania bazy danych nie jest przedmiotem tego dokumentu.
Zarys schematu bazy danych znajduje się w widoku przechowywania danych. Programy i serwer www łączą się przez bazy danych poprzez moduły biblioteczne
dostępu do bazy danych.

\newpage

\section{Widok infrastruktury} %Male ale chyba ok. Jak ktos cos uwaza niech dopisuje. Ja sie bardzo dobrze nie znam.

Do poprawnego działania systemu potrzebne są następujące elementy fizyczne:

\begin{description}
\item[Serwer z bazą danych.] Jeden z modeli komputerów polecanych przez Oracle pod ich bazę danych. Będzie obsługiwał całą bazę danych.
\item[Serwer główny.] Czteroprocesorowy klaster, na którym będą działać: demon nadzorujący oraz serwery rozgrywek i turniejów. System ma być przygotowany
do możliwości podłączenia pomocniczych komputerów i zlecania im np. przeprowadzania pojedynczych turniejów. Zakup tychże komputerów pozostaje w gestii
\wfp. Działa pod systemem Linux.
\item[Serwer www.] Jednoprocesorowy, nowy komputer działający pod systemem Linux z zainstalowanym: serwerem Apache oraz silnikiem JBoss. Obsługuje strony
www projektu, w tym: FAQ, Manuale, interfejs pracownika \wfp oraz reklamodawców, strony do rejestracji użytkowników, rankingi (dokładne wyszczególnienie
   co znajduje się na stronach, znajduje się w Widoku Logicznym). 
\item[Router, gateway na świat.] Średniej klasy router pośredniczący między powyższymi komputerami a ,,światem zewnętrznym''. Pełni funkcję firewalla i 
bramki. 
\item[Sieć, HUB.] Stumegabitowa sieć LAN z SWITCHem pomiędzy powyższymi komputerami.
\item[Łącze do Internetu.] Dziesięciomegabitowe łącze z routera do Internetu (a ściślej do centrali \wfp).
\item[System podtrzymywania napięcia.] Do wszystkich powyższych urządzeń.
\item[Pomieszczenie z klimatyzacją.] Na powyższą infrastrukturę potrzebne jest kilka metrów kwadratowych, w założeniu będzie to część serwerowni \wfp.
\end{description}

\newpage
\section{Widok implementacyjny}

\subsection{Języki programowania}
System w przeważającej części będzie napisany w języku Java (JDK 1.5). Pozwoli to 
współdzielić fragmenty kodu, które będą musiały działać na różnych architekturach. Ponadto
gotowe, a także bezpłatne oraz wciąż rozwijane są technologie z których system będzie korzystał
(Xerces XML Parser,  JDBC). 

Poniżej znajduje się zestawienie języków i fragmentów w których będą one wykorzystane:
\begin{description}
\item[bash] - Na potrzeby wykonania skryptów administracyjncych serwerem, takich jak obsługa backupu danych, czy okresowego porządkowania danych (CRON)
\item[XHTML] - Jako język przesyłania treści do przeglądarki internetowej (która jest podstawowym 
elementem interfejsu użytkownika
\item[XML Schema] - do walidowania wymienianych danych (np. w komunikacji sieciowej). Bridge Markup Language jest wyrażony m.in. w postaci odpowiednich schematów. 
\item[Java] 
	Można rozbić kod w Javie na następujące grupy komponentów:
	\begin{description} 
		\item [biblioteki] można podzielić na:
			\begin{itemize} 
				\item[-] wyrażające logikę biznesową
				\item[-] zapewniające wspólne struktury danych w komunikacji sieciowej
				\item[-] zapewniające jednorodne standardy w obrębie całego systemu (np. sposób zapisu dat). 
			\end{itemize}
		\item [serwlety] można podzielić na:
			\begin{itemize}
				\item[-] serwlet odpowiadający za przeprowadzenie pojedynczego turnieju
				\item[-] serwlet zarządzający rozgrywkami pozaturniejowymi	
				\item[-] serwlet odpowiadający za przeprowadzenie pojedynczego rozdania
				\item[-] serwlet odpowiadający za komunikację z użytkownikiem poprzez przeglądarkę internetową (przygotowywanie dokumunktów XHTML i zbieranie danych z formularzy)
				\item[-] serwlet będący serwerem chat'a
			\end{itemize}
		\item [aplety] można podzielić na:
			\begin{itemize} 
				\item[-] aplet zapewniający uczestnictwo gracza w pojedynczym rozdaniu (lub pokazywanie odbywającego się rozdania lub pokazywanie zapisanego w pliku rozdania)
				\item[-] aplet zapewniający uczestnictwo w chacie
				\item[-] aplikacja sędziowska - do zarządzania turniejem
			\end{itemize}
	\end{description}


\end{description}


% Przyznaje ze jakies to bardzo podobne do logiznego, troche nie rozumiem.
% Moze wcale nie chodzi o to, co napisalem w rozdziale 2, a np. warstwa niskiej komunikacji - nawiazywania polaczen, wyzej warstawa wysylania obiektow
% itd. Zostawiam stwierdzenie o co tu chodzi taboretowi :)
%To ja napiszę jakiś Syf.

\subsection{Warstwy}

% Takie tam layersy - warstwy od bazy danych do klienta, kazda sie komuniktuje tylko z sasiednimi - ogolnie

%AAA Brakuje w tym takiej skrotowej, jak to bedzie zaimplementowane.
%AAA Np. implementacja demonow, watkowosc, wiele rzadan, jak dziala logowanie, jaki mechanizm do synchronizacji watkow,
%AAA i ogolnie dodac szczegolow implementacyjnych. Jakie informacje cashowane. 

Implementacja systemu będzie utrzymana w architektórze trójwarstwowej:
\begin{description}
 \item[Warstwa danych] - realizowana poprzez następujące ,,podwarstwy'' (jako faktyczne warstwy implementacji):
	\begin{description}
		\item [Serwer relacyjnej bazy danych] - w postaci Oracle 10i (warstwa już zaimplementowana - pozostaje przygotować schemat danych oraz wdrożyć). 
		\item [JDBC i XML-parser] - Jako warstwa łączenia klas Javy (ukrywających bazy-danowy charakter obiektów) z bazą danych.  Warstwa jest dostępna w postaci bibliotek Javy. Obejmuje zarówno technologię JDBC na potrzeby dostępu do Oracla, jak i parser XML'a: ,,Xerces Java Parser 1.5.*'', który będzie wykorzystywany do serializacji i deserializachi tych obiektów oraz do walidowania Bridge Markup Language. 
		\item [Klasy Javy reprezentujące obiekty bazy danych] - Jest to zestwa klas, które służą
	przeniesieniu abstrakcji danych z języka SQL i schematu bazy danych na klasy, które reprezentują obiekty rzeczywistego brydża. Klasa ta obejmyje klasy definicje następujące obiekty:
	\begin{itemize}
		\item{} pojedynczy turniej
		\item{} pojedyncze rozdanie 
		\item{} pojedyńczą rozgrywkę
		\item{} historię pojedynczej rozgrywki
		\item{} pojedynczy gracza
		\item{} pojedyncze pytanie (możliwe, że z odpowiedzią) z FAQ
		\item{} pojedyncze zlecenie dla pracownika
		\item{} pojedynczy schemat rankingu
		\item{} pojedynczy ranking wypełniny danymi
		\item{} pojedynczy zawód
		\item{} pojedynczy zapis pary na turnieu
		\item{} pojedynczą reklamę
		\item{} statystykę wyświetleń pojedyńczej reklamy 
		\item{} pojedynczego użytkownika systemu (podklasy: pracownika i reklamodowcy)
		\item{} lista sędziów zapisanych na pojedynczy turniej
		\item{} klasa operacji administracyjnych (np. zrzut bazy danych do pliku)
		\item{} klasy mechanizmu autoryzacji użytkowników
	\end{itemize}		
	\end{description}
	\item[warstwa logiki systemowej] - skupia klasy umożliwiające przeprowadzenie większości funkcjonalności systemu oraz klasy odpowiedzialne za komunikację sieciową. Zrealizowana jest oczywiście w postaci klas Javy skupione w następujących modułach: 
		\begin{itemize} 
			\item{Moduł obsługi rozdania}
			\item{Moduł obsługi turnieju}
			\item{Moduł obsługi turniejów}
			\item{Moduł obsługi rankingu}
			\item{Moduł obsługi rankingów} 
			\item{Moduł komunikacji chata}
			\item{Moduł komunikacji sieciowej (obudowa TCP/IP do RPC z wykorzystaniem BML)}
			\item{Moduł obsługi reklam}
			\item{Moduł obsługi FAQ}
			\item{Moduł obsługi zadań pracownika}
			\item{Moduł wspólnych elementów intefejsu}
			\item{Moduł obsługi poczty elektronicznej}
		\end{itemize}
        \item[warstwa pomocnicza i współdzielonych interfejsów sieciowych]
		\begin{itemize}
			\item [Moduł komunikacji serwer rozdania &lt;-&gt; serwer turnieju]
			\item [Moduł komunikacji chata]
			\item [Moduł komunikacji serwer turnieju &lt;-&gt; aplikacja sędziowska]
			\item [Moduł komunikacji serwer turnieju &lt;-&gt; aplikacja sędziowska]
			\item [Moduł odczytu konfiguracji]
		\end{itemize}
	\item[warstwa użytkownika] - (interfejsu użytkownika):
		\begin{itemize}
			\item{ serwlet nadzorzujący - uruchamiany okresowy przez CRON w celu powołania pozostałch procesów (np. wznowienie turnieju)}
			\item{ serwlet odpowiadający za przeprowadzenie pojedynczego turnieju}
			\item{ serwlet zarządzający rozgrywkami pozaturniejowymi}
			\item{ serwlet odpowiadający za przeprowadzenie pojedynczego rozdania}
			\item{ serwlet odpowiadający za komunikację z użytkownikiem poprzez przeglądarkę internetową (przygotowywanie dokumunktów XHTML i zbieranie danych z formularzy)}
			\item{ serwlet będący serwerem chat'a}
			\item{ aplet zapewniający uczestnictwo gracza w pojedynczym rozdaniu (lub pokazywanie odbywającego się rozdania lub pokazywanie zapisanego w pliku rozdania)}
			\item{ aplet zapewniający uczestnictwo w chacie}
			\item{ aplikacja sędziowska - do zarządzania turniejem}
		\end{itemize}
	\end{description}

\subsubsection{Uwierzytelnianie użytkowników}	
	Uwierzytelnianie użytkowników będzie przeprowadzane przez następujące procesu:
	\begin{description}
		\item[wszystkie serwlety obsługujące graczy i sędziów] - na potrzeby otworzenia profilowanych stron www gracza i sędziego
		\item[aplikacja sędziowska] - na potrzeby udostępniania graczowi informacji o turniejach, którymi może administrować
		\item[serwer pojedynczego rozdania] - na potrzeby umożliwienia właściwemy graczowi uczestnictwa w rozdaniu
		\item[serwer pojedynczego turnieju] - na potrzeby umożliwienia sędziowi zarządzania tym turniejem
	\end{description}

Wszystkie te metody uwierzytelniania polegają na przesłaniu nieszyfrowanym połączeniem hasła w postaci 
jawnej do odpowiedniego serwera. Serwer porównuje je z danymi hasła zapisanymi w bazie danych (TABELA GRACZE - hasło nie kodowane) i zwraca odpowiedniej aplikacji informacje o uwierzytelnieniu gracza/bądź nie. 
		
Należy wyróżnić autoryzację przeprowadzaną przez wszystkie serwlety obsługujące pracowników www.bardzofajnyportal.pl i reklamodawców (na potrzeby otworzenia profilowanych stron www gracza i sędziego) jako tą korzystającą
z tabeli bazydanych (UZYTKOWNICY)

\subsubsection{Tworzenie logów}
Logi są prowadzone przez wszystkie aplikacje działające po stronie serwera, przy pomocy systemowej usługi syslog.
Logi w zależności od konfiguracji są prowadzone z dokładnością do (każdy kolejny poziom zawiera wszystki komunikaty poprzedniego):
\begin{description}
	\item[DL\_NONE] - Nie prowadzimy logowania działań systemu
	\item[DL\_ERRORS] - Logujemy informacje o błędach napotkanych w działaniu systemu
	\item[DL\_WARNINGS] - Logujemy informacje o wszystkich ostrzeżeniach  
	\item[DL\_INFO] - Logujemy kluczowe informacje o działaniu systemu
	\item[DL\_NOTICES] - Logujemy też mniej kluczowe informacje o dzałaniu systemu
	\item[DL\_DEBUG] - Logujemy też treści wysysłanych żadań SQL'a i ilości zwróconych rekordów
	\item[DL\_TIMES - Logujemy czasy wykonania co bardziej istotnych rządań]
\end{description}


\subsection{Synchronizacja procesów}
Procesy nie wykorzystują w sposób jawny dostępu do pamięci współdzielonej (jedynie wbudowane procesy takie jak serwer Apache, baza danych - Oracle10i, serwer jboss wykorzystują wewnętrznie segmenty pamiędzi współdzielonej). Zatem wszelka synchronizacja opiera się o wymiane komynikatów pomiędzy procesami - przy pomocy protokołu SOAP. Komunikaty przesyłane do poszczególnych procesów są kolejkowane i utrzymywane w oddzielnych buforach dla poszczególnych 
procesów komunikujących się z nami. Każdy z procesów komunikujących wysyła conajwyżej jeden komunikat na raz - co przy zastosowaniu transmisji TCP/IP gwarantuje. że kilka komunikatów nie wymiesza się. 

Procesy czytają komunikaty z początku kolejek. 

Za synchronizację dostępu do wspólnych danych odpowiada serwer bazy danych - Oracle 10i. 


% Przyznaje ze jakies to bardzo podobne do logiznego, troche nie rozumiem.
% Moze wcale nie chodzi o to, co napisalem w rozdziale 2, a np. warstwa niskiej komunikacji - nawiazywania polaczen, wyzej warstawa wysylania obiektow

%\end{description}

%\subsection{Warstwy}

% Uszczegolowienie kazdej warstwy, tak naprawde wymienienie modulow ktore tam siedza i funkcjonalnosci.

\subsection{Najważniejsze algorytmy}

W systemie nie występują złożone problemy w których potrzebne są zaawansowane algorytmy. Większość operacji ogranicza się do zarządzania 52 kartami, a ich średnia złożoność nie przekracza nlog(n). 
Z trudniejszych zadań algorytmicznych realizowanych przez system wyróżnić należy:

\begin{description}
	\item[Rozlosowywanie rozdań turniejowych] - Aplikacja sędziowska musi potrafić wygenerować zadaną liczbę rozdań brydżowych o podanych prawdopodobieństwach wystąpienia danego rozkładu kart (kolorami). 
	\item[Zliczanie wyników turnieju] - Jest to realizowane przez serwer turnieju w momencie
zakończenia turnieju oraz (jeśli system punktacyjny to przewiduje) na żądanie sędziego w dowolnym momencie turnieju. 
	\item[Sztuczna Inteligencja w grze] - Jest to funkcjonalność nie implementowana w obecnej wersji systemu. Nie wykluczamy, że udziałowiec zakupi już istniejący silnik SI i pozostanie nam jedynie jego integracja z systemem. 
\end{description}

%%% Tak naprawdę wszystko wrzucamy w baze danych i tam siedza najwazniejsze algorytmy. Ja nie widze nic wyszukanego tu. [Skad to sie wogle wzielo? ;) ]

%Możemy tu rozwinąć realizacje każdego z powyższych algorytmy. Ja za słabo znam metody liczenia punktów w turniejach by opisać dwójkę. 

%\subsubsection{Rozlosowywanie rozdań turniejowych}
%\end{itemize}

\newpage

\begin{landscape}
\section{Widok przechowywania danych}
Tabela przechowuje pytania od użytkownika dla pracownika www.bardzofajnyportal.pl i odpowiedzi na nie. 
Pytanie i odpowiedź może zostać opublikowane (anonimowo) i z takich odpowiedzi składa się z FAQ. 

\subsection{FAQ}
 Tabela ,,FAQ'' służy do przechowywania podstawowych informacji o zarejestrowanych w systemie graczach
 \begin{longtable}{|l|p{3cm}|c|c|p{4cm}|p{4cm}|} 
 \caption{Struktura tabeli FAQ} \label{tab:FAQ-structure} \\
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline
\endfirsthead
 \caption{Struktura tabeli FAQ (kontynuacja)} \\ 
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline \endhead \endfoot 
ID &amp; int(11) &amp; Nie &amp; 0 &amp;  &amp; Unikatowy identyfikator \\ \hline 
FK\_GRACZE\_ID &amp; int(11) &amp; Nie &amp; 0 &amp; GRACZE (ID) &amp; Identyfikator gracza zadającego pytanie \\ \hline 
KIEDY &amp; timestamp &amp; Tak &amp; CURRENT\_TIMESTAMP &amp;  &amp; Kiedy zadano pytanie \\ \hline 
PYTANIE &amp; longtext &amp; Nie &amp;  &amp;  &amp; Treść pytania \\ \hline 
ODPOWIEDZ &amp; longtext &amp; Nie &amp;  &amp;  &amp; Treść odpowiedzi \\ \hline 
CZY\_PUBLICZNY &amp; (1) &amp; Nie &amp;  &amp;  &amp; Czy pytanie wraz z odpowiedzią ma być publikowane w FAQ na stronie \\ \hline 
KATEGORIA &amp; varchar(100) &amp; Nie &amp;  &amp;  &amp; Do jakiej kategorii należy pytanie  \\ \hline 
 \end{longtable}

\newpage
%
% Struktura: GRACZE
%
\subsection{GRACZE}
 Tabela ,,GRACZE'' służy do przechowywania podstawowych informacji o zarejestrowanych w systemie graczach\\
 
 \begin{longtable}{|l|p{3cm}|c|c|p{4cm}|p{4cm}|} 

 \caption{Struktura tabeli GRACZE} \label{tab:GRACZE-structure} \\
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline
\endfirsthead
 \caption{Struktura tabeli GRACZE (kontynuacja)} \\ 
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline \endhead \endfoot \textbf{\textit{ID}} &amp; int(11) &amp; Nie &amp;  &amp;  &amp; Unikatowy identyfikator \\ \hline 
IMIE &amp; varchar(30) &amp; Nie &amp;  &amp;  &amp; Imię gracza \\ \hline 
IMIE2 &amp; varchar(30) &amp; Tak &amp;  &amp;  &amp; Drugie imię gracza\\ \hline 
NAZWISKO &amp; varchar(50) &amp; Nie &amp;  &amp;  &amp; Nazwisko gracza  \\ \hline 
PLEC &amp; enum('M', 'K') &amp; Nie &amp; M &amp;  &amp; Płeć gracza \\ \hline 
LOGIN &amp; varchar(30) &amp; Nie &amp;  &amp;  &amp;  Identyfikator używany przy logowaniu\\ \hline 
EMAIL &amp; varchar(100) &amp; Nie &amp;  &amp;  &amp;  Adres e-mail gracza\\ \hline 
ZAMIESZKALY &amp; varchar(50) &amp; Nie &amp;  &amp;  &amp;  Miejscowość zamieszkania gracza\\ \hline 
KOD\_POCZTOWY &amp; varchar(6) &amp; Nie &amp;  &amp;  &amp;  Kod pocztowy gracza\\ \hline 
DATA\_URODZENIA &amp; date &amp; Nie &amp; 0000-00-00 &amp;  &amp; Data urodzenia gracza\\ \hline 
ULICA &amp; varchar(20) &amp; Tak &amp;  &amp;  &amp;  Ulica, przy której mieszka gracz \\ \hline 
NR\_DOMU &amp; varchar(10) &amp; Tak &amp;  &amp;  &amp;  \\ \hline 
NR\_LOKALU &amp; varchar(10) &amp; Tak &amp;  &amp;  &amp;  \\ \hline 
PESEL &amp; varchar(40) &amp; Nie &amp;  &amp;  &amp; \\ \hline 
NR\_LEG\_PZBS &amp; bigint(10) &amp; Nie &amp; 0 &amp;  &amp; Numer legitymacji Polskiego Związku Brydża Sportowego \\ \hline 
STOPIEN\_ZNAJOMOSCI &amp; int(30) &amp; Nie &amp; 0 &amp;  &amp; Stopień znajomości brydża: 0 - nie znam, 1 - początkujący, 2 - średnio zaawansowany, 3 - zaawansowany, 4 - mistrz \\ \hline 
OPIS\_SYSTEMU\_LICYTACJI &amp; longtext &amp; Nie &amp;  &amp;  &amp; Opis systemu licytacji stosowanego przez gracza \\ \hline 
WYKSZTALCENIE &amp; enum('brak', 'podstawowe', 'zawodowe', 'średnie niepełne', 'średnie', 'policealne', 'wyższe', 'doktorat') &amp; Nie &amp; brak &amp;  &amp; Wykształcenie gracza \\ \hline 
ZAWOD &amp; varchar(50) &amp; Nie &amp;  &amp;  &amp; Zawód gracza \\ \hline 
HASLO &amp; varchar(50) &amp; Nie &amp;  &amp;  &amp; Hasło gracza \\ \hline 
CZY\_CHCE\_POWIADOMIENIA &amp; (1) &amp; Nie &amp;  &amp;  &amp; Czy gracz chce dostawać powiadomienia mailem o turniejach, w których może wziąć udział \\ \hline 
OPIS\_WLASNY\_GRACZA &amp; longtext &amp; Tak &amp; NULL &amp;  &amp; Gracz może napisać kilka słów o sobie \\ \hline 
FK\_JEZYKI\_DOMYSLNY &amp; int(11) &amp; Nie &amp; 0 &amp; JEZYKI (ID) &amp; W jakim języku ma się domyślnie wyświetlać interfejs użytkownika  \\ \hline 
STATUS &amp; enum('gracz', 'sędzia', 'super sędzia') &amp; Nie &amp; gracz &amp;  &amp; Status gracza \\ \hline 
 \end{longtable}

%
% Struktura: INTERWENCJE_SEDZIOWSKIE
%
\newpage
\subsection{INTERWENCJE\_SEDZIOWSKIE}

Tabela ta służy do przechowywania informacji o modyfikacja punktacji (karach) przyznanych przez sędziego.
(kara może być ujemna i wtedy należy rozumieć ją jako nagrodę. 
  \begin{longtable}{|l|p{3cm}|c|c|p{4cm}|p{4cm}|} 
 \caption{Struktura tabeli INTERWENCJE\_SEDZIOWSKIE} \label{tab:INTERWENCJE_SEDZIOWSKIE-structure} \\
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline
\endfirsthead
 \caption{Struktura tabeli INTERWENCJE\_SEDZIOWSKIE (kontynuacja)} \\ 
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline \endhead \endfoot \textbf{\textit{ID}} &amp; int(11) &amp; Nie &amp;  &amp;  &amp; Unikatowy identyfikator \\ \hline 
FK\_GRACZE\_ID\_SEDZIA &amp; longblob &amp; Nie &amp;  &amp; GRACZE (ID) &amp; Identyfikator sędziego, który interweniował \\ \hline 
KIEDY &amp; timestamp &amp; Tak &amp; CURRENT\_TIMESTAMP &amp;  &amp; Kiedy wprowadzono zmianę  \\ \hline 
FK\_TURNIEJE\_ID &amp; int(11) &amp; Nie &amp; 0 &amp; TURNIEJE (ID) &amp; Identyfikator turnieju, do którego odnosi się kara \\ \hline 
FK\_ZAPISY\_NA\_TURNIEJE\_PARA\_ID &amp; int(11) &amp; Nie &amp; 0 &amp; ZAPISY\_NA\_TURNIEJE (ID) &amp; Identyfikator ukaranej pary \\ \hline 
FK\_ROZDANIA\_ZA\_ROZDANIE &amp; int(11) &amp; Tak &amp; NULL &amp; ROZDANIA (ID) &amp; Identyfikator rozdania (jeśli NULL - to kara dotyczy turnieju) \\ \hline 
OPIS &amp; longtext &amp; Tak &amp; NULL &amp;  &amp; Opis turnieju \\ \hline 
KOD\_1 &amp; varchar(50) &amp; Tak &amp; NULL &amp;  &amp; dane dla systemu liczącego punkty (wykorzystanie zależy od systemu) \\ \hline 
KOD\_2 &amp; varchar(50) &amp; Tak &amp; NULL &amp;  &amp; j.w.\\ \hline 
KOD\_3 &amp; varchar(50) &amp; Tak &amp; NULL &amp;  &amp; j.w. \\ \hline 
KOD\_4 &amp; varchar(50) &amp; Tak &amp; NULL &amp;  &amp; j.w. \\ \hline 
KOD\_5 &amp; varchar(50) &amp; Tak &amp; NULL &amp;  &amp; j.w. \\ \hline 
KOD\_6 &amp; varchar(50) &amp; Tak &amp; NULL &amp;  &amp; j.w. \\ \hline 
KOD\_7 &amp; varchar(50) &amp; Tak &amp; NULL &amp;  &amp; j.w. \\ \hline 
 \end{longtable}

%
%
% Struktura: JEZYKI
%
\newpage

\subsection{JEZYKI}
 W tabeli znajdują się identyfikatory (i nazwy) języków obsługiwanych przez system. 
 \begin{longtable}{|l|p{3cm}|c|c|p{4cm}|p{4cm}|} 
 \caption{Struktura tabeli JEZYKI} \label{tab:JEZYKI-structure} \\
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline
\endfirsthead
 \caption{Struktura tabeli JEZYKI (kontynuacja)} \\ 
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline \endhead \endfoot \textbf{\textit{ID}} &amp; int(11) &amp; Nie &amp; 0 &amp; Unikatowy identyfikator \\ \hline 
\textbf{NAZWA\_JEZYKA} &amp; varchar(50) &amp; Nie &amp;  &amp; Nazwa języka \\ \hline 
 \end{longtable}

%
% Struktura: PRACOWNIK_TO_DO
\newpage
\subsection{PRACOWNIK\_TO\_DO}
Tabelka służy do przechowywania ,,zadań'' przeznaczonych dla pracownika. 
W początkowym etapie jedynym używanym typem zadania jest rozpatrzenie prośby gracza o nadanie mu
statusu sędziego. 
\begin{longtable}{|l|p{3cm}|c|c|p{4cm}|p{4cm}|} 
 \caption{Struktura tabeli PRACOWNIK\_TO\_DO} \label{tab:PRACOWNIK_TO_DO-structure} \\
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline
\endfirsthead
 \caption{Struktura tabeli PRACOWNIK\_TO\_DO (kontynuacja)} \\ 
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline \endhead \endfoot \textbf{\textit{ID}} &amp; int(11) &amp; Nie &amp;  &amp;  &amp; Unikatowy identyfikator \\ \hline 
TYP &amp; int(11) &amp; Nie &amp; 0 &amp;  &amp;  \\ \hline 
FK\_GRACZE\_ID &amp; int(11) &amp; Nie &amp; 0 &amp; GRACZE (ID) &amp;  \\ \hline 
OPIS1 &amp; text &amp; Nie &amp;  &amp;  &amp;  \\ \hline 
OPIS2 &amp; text &amp; Nie &amp;  &amp;  &amp;  \\ \hline 
OPIS3 &amp; text &amp; Nie &amp;  &amp;  &amp;  \\ \hline 
ZROBIONE &amp; (1) &amp; Nie &amp;  &amp;  &amp;  \\ \hline 
 \end{longtable}

%
% Struktura: RANKINGI

\newpage
\subsection{RANKINGI}

 Tabela przechowuje informacje o różnego rodzaju rankingach prowadzonych przez system.
 Poszczególne rankingi są przechowywane w bazie danych jako perspektywy oparte głównie o tabele
,,RANKINGI DANE''. 

 Uwaga: Należy zachować szczególną ostrożność, gdyż bezpośrednie wprowadzanie zdań SQL'owych
 do tabeli przez pracownika www.bardzofajnyportal.pl może nieść za sobą ryzyko uszkodzenia danych
  (np. poprzez wpisanie perspektywy o treści: ,,TRUNCATE TABLE TURNIEJE'').

 \begin{longtable}{|l|p{3cm}|c|c|p{4cm}|p{4cm}|} 
 \caption{Struktura tabeli RANKINGI} \label{tab:RANKINGI-structure} \\
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline
\endfirsthead
 \caption{Struktura tabeli RANKINGI (kontynuacja)} \\ 
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline \endhead \endfoot \textbf{
\textit{ID}} &amp; int(11) &amp; Nie &amp;  &amp; Unikatowy identyfikator \\ \hline 
NAZWA &amp; varchar(100) &amp; Nie &amp;   &amp;Nazwa rankingu  \\ \hline 
OPIS &amp; text &amp; Nie &amp;  &amp;  Opis rankingu\\ \hline 
VIEW\_NAME &amp; varchar(100) &amp; Nie &amp;  &amp; Nazwa perspektywy SQL generującej ranking \\ \hline 
VIEW\_SQL\_STATEMENT &amp; text &amp; Nie &amp;  &amp; Treść zapytania SQL na bazie którego zbudowana jest perspektywa wyświetlająca ranking \\ \hline 
 \end{longtable}


%
% Struktura: RANKINGI_DANE
%
\newpage
\subsection{RANKINGI\_DANE}
 Tabela przechowuje już zaagregowane informacje na temat miejsc i wyników poszczególnych graczy w poszczególnych turniejach.
 Stanowi bazę do generowania poszczególnych rankingów. 
 \begin{longtable}{|l|p{3cm}|c|c|p{4cm}|p{4cm}|} 
 \caption{Struktura tabeli RANKINGI\_DANE} \label{tab:RANKINGI_DANE-structure} \\
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline
\endfirsthead
 \caption{Struktura tabeli RANKINGI\_DANE (kontynuacja)} \\ 
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline \endhead \endfoot \textbf{\textit{ID}} &amp; int(11) &amp; Nie &amp;  &amp;  &amp; Unikatowy identyfikator \\ \hline 
FK\_TURNIEJE\_ID &amp; int(11) &amp; Nie &amp; 0 &amp; TURNIEJE (ID) &amp; Identyfikator turnieju \\ \hline 
FK\_ZAPISY\_NA\_TURNIEJE\_ID &amp; int(11) &amp; Nie &amp; 0 &amp; ZAPISY\_NA\_TURNIEJE (ID) &amp; Identyfikator pary biorącej udział w turnieju \\ \hline 
MIEJSCE &amp; int(11) &amp; Nie &amp; 0 &amp;  &amp; Zajęte przez parę miejsce \\ \hline 
PUNKTACJA1 &amp; double &amp; Nie &amp; 0 &amp;  &amp; Punktacje według poszczególnych metod liczenia punktów \\ \hline 
PUNKTACJA2 &amp; double &amp; Nie &amp; 0 &amp;  &amp; Punktacje według poszczególnych metod liczenia punktów \\ \hline 
PUNKTACJA3 &amp; double &amp; Nie &amp; 0 &amp;  &amp; Punktacje według poszczególnych metod liczenia punktów \\ \hline 
PUNKTACJA4 &amp; double &amp; Nie &amp; 0 &amp;  &amp; Punktacje według poszczególnych metod liczenia punktów \\ \hline 
 \end{longtable}


%
% Struktura: REKLAMY
%
\newpage
\subsection{REKLAMY}
 Zbiór wszystkich reklam przekazanych do www.bardzofajnyportal.pl przez reklamodawców
 \begin{longtable}{|l|p{3cm}|c|c|p{4cm}|p{4cm}|} 
 \caption{Struktura tabeli REKLAMY} \label{tab:REKLAMY-structure} \\
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline
\endfirsthead
 \caption{Struktura tabeli REKLAMY (kontynuacja)} \\ 
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline \endhead \endfoot \textbf{\textit{ID}} &amp; int(11) &amp; Nie &amp;  &amp;  &amp; Unikatowy identyfikator \\ \hline 
SZEROKOSC &amp; int(11) &amp; Nie &amp; 0 &amp;  &amp; Szerokość (w pixelach) reklamy  \\ \hline 
WYSOKOSC &amp; int(11) &amp; Nie &amp; 0 &amp;  &amp;  Wysokość (w pixelach) reklamy\\ \hline 
LINK &amp; text &amp; Nie &amp;  &amp;  &amp; Odnośnik znajdujący się pod obrazkiem \\ \hline 
OBRAZEK &amp; varchar(200) &amp; Nie &amp;  &amp;  &amp; Nazwa pliku zawierającego obrazek (specjalnie nie jest to BLOB) \\ \hline 
FK\_UZYTKOWNICY\_REKLAMODAWCA\_ID &amp; int(11) &amp; Nie &amp; 0 &amp; UZYTKOWNICY (ID) &amp; Identyfikator reklamodawcy \\ \hline 
 \end{longtable}


%
% Struktura: ROZDANIA
%
\newpage
\subsection{ROZDANIA}
W tabeli tej przechowujemy informacje zarówno o rozdaniach na potrzeby turniejów, 
jak i informacje o rozdaniach, które gracze chcieli zachować (patrz: tabela ROZGRYWKI\_PRYWATNE)
 \begin{longtable}{|l|p{3cm}|c|c|p{4cm}|p{4cm}|} 
 \caption{Struktura tabeli ROZDANIA} \label{tab:ROZDANIA-structure} \\
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline
\endfirsthead
 \caption{Struktura tabeli ROZDANIA (kontynuacja)} \\ 
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline \endhead \endfoot \textbf{\textit{ID}} &amp; int(11) &amp; Nie &amp; 0 &amp;  &amp; Unikatowy identyfikator \\ \hline 
FK\_TURNIEJE\_ID &amp; int(11) &amp; Tak &amp; NULL &amp; TURNIEJE (ID) &amp; Identyfikator turnieju do którego należy rozdanie bądź NULL\\ \hline 
KARTY\_N &amp; XML &amp; Nie &amp;  &amp;  &amp; xml: tag BML'owy opisujący karty gracza N\\ \hline 
KARTY\_E &amp; XML &amp; Nie &amp;  &amp;  &amp; xml: tag BML'owy opisujący karty gracza E \\ \hline 
KARTY\_S &amp; XML &amp; Nie &amp;  &amp;  &amp; xml: tag BML'owy opisujący karty gracza S \\ \hline 
KARTY\_W &amp; XML &amp; Nie &amp;  &amp;  &amp; xml: tag BML'owy opisujący karty gracza W \\ \hline 
 \end{longtable}


%
% Struktura: ROZGRYWKI_PRYWATNE
%

\newpage 
\subsection{ROZGRYWKI\_PRYWATNE}
 Tabela przechowuje informacje o rozdaniach i rozgrywkach, które gracz uznał za 
 warte zachowania w swoim profilu. 
 \begin{longtable}{|l|p{3cm}|c|c|p{4cm}|p{4cm}|} 
 \caption{Struktura tabeli ROZGRYWKI\_PRYWATNE} \label{tab:ROZGRYWKI_PRYWATNE-structure} \\
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline
\endfirsthead
 \caption{Struktura tabeli ROZGRYWKI\_PRYWATNE (kontynuacja)} \\ 
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline \endhead \endfoot \textbf{\textit{ID}} &amp; int(11) &amp; Nie &amp;  &amp;  &amp; Unikatowy identyfikator \\ \hline 
FK\_GRACZE\_ID\_CZYJE &amp; int(11) &amp; Nie &amp; 0 &amp; GRACZE (ID) &amp; Który gracz chce zachować rozgrywkę \\ \hline 
FK\_GRACZE\_ID\_N &amp; int(11) &amp; Tak &amp; 0 &amp; GRACZE (ID) &amp; Identyfikator gracza na pozycji N \\ \hline 
FK\_GRACZE\_ID\_E &amp; int(11) &amp; Tak &amp; 0 &amp; GRACZE (ID) &amp; Identyfikator gracza na pozycji E \\ \hline 
FK\_GRACZE\_ID\_S &amp; int(11) &amp; Tak &amp; 0 &amp; GRACZE (ID) &amp; Identyfikator gracza na pozycji S \\ \hline 
FK\_GRACZE\_ID\_W &amp; int(11) &amp; Tak &amp; 0 &amp; GRACZE (ID) &amp; Identyfikator gracza na pozycji W \\ \hline 
FK\_ROZDANIE\_ID &amp; int(11) &amp; Nie &amp; 0 &amp; ROZDANIA (ID) &amp; Identikator rozdania \\ \hline 
ROZGRYWKA &amp; xml &amp; Nie &amp;  &amp;  &amp; Tag BML opisujący przebieg rozgrywki\\ \hline 
Opis &amp; longtext &amp; Nie &amp;  &amp;  &amp; Opis tekstowy gracza \\ \hline 
 \end{longtable}

%
% Struktura: ROZGRYWKI_TURNIEJOWE
%
\newpage
\subsection{ROZGRYWKI\_TURNIEJOWE}
W tabeli są zapamiętywane informacje o tym, które pary mają rozegrać dane rozdania oraz
informacje o przebiegu tych rozgrywek - jeśli już zostało zakończone. 

 \begin{longtable}{|l|p{3cm}|c|c|p{4cm}|p{4cm}|} 
 \caption{Struktura tabeli ROZGRYWKI\_TURNIEJOWE} \label{tab:ROZGRYWKI_TURNIEJOWE-structure} \\
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline
\endfirsthead
 \caption{Struktura tabeli ROZGRYWKI\_TURNIEJOWE (kontynuacja)} \\ 
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline \endhead \endfoot \textbf{\textit{ID}} &amp; int(11) &amp; Nie &amp;  &amp;  &amp; Unikatowy identyfikator \\ \hline 
FK\_ZAPISY\_NA\_TURNIEJE\_ID\_PARA\_NS &amp; int(11) &amp; Nie &amp; 0 &amp; ZAPISY\_NA\_TURNIEJE (ID) &amp; Para grająca na pozycji NS \\ \hline 
FK\_ZAPIS\_NA\_TURNIEJE\_ID\_PARA\_EW &amp; int(11) &amp; Nie &amp; 0 &amp; ZAPISY\_NA\_TURNIEJE (ID) &amp;  Para grająca na pozycji EW\\ \hline 
FK\_ROZDANIA\_ID &amp; int(11) &amp; Nie &amp; 0 &amp;  &amp; Identyfikator rozgrywanego rozdania \\ \hline 
PRZEBIEG &amp; xml &amp; Tak &amp; NULL &amp;  &amp; BML opisujący przebieg rozgrywki \\ \hline 
STATUS &amp; enum('do zagrania', 'właśnie grane', 'zagrane') &amp; Nie &amp; do zagrania &amp;  &amp; Status rozgrywki  \\ \hline 
FK\_TURNIEJE\_ID &amp; int(11) &amp; Nie &amp; 0 &amp; TURNIEJE (ID) &amp; Identyfikator turnieju, do którego należy ta rozgrywka  \\ \hline 
FK\_GRACZE\_ID\_ROZGRYWAL &amp; int(11) &amp; Tak &amp; NULL &amp; GRACZE (ID) &amp;  Identyfikator gracza rozgrywającego to rozdanie\\ \hline 
KONTRAKT\_WYSOKOSC &amp; smallint(6) &amp; Tak &amp; NULL &amp;  &amp; Wysokość zagranego (lub do zagrania) kontraktu\\ \hline 
KONTRAKT\_KOLOR &amp; enum('bez atu', 'pik', 'kier', 'karo', 'trefl') &amp; Tak &amp; NULL &amp;  &amp; Kolor zagranego (lub do zagrania) kontraktu \\ \hline 
KONTRAKT\_STATUS &amp; enum('double', 'redouble') &amp; Tak &amp; NULL &amp;  &amp; Stopień skontrowania kontraktu \\ \hline 
WZIELI\_LEW &amp; smallint(6) &amp; Tak &amp; NULL &amp;  &amp; Ile lew wziala para rozgrywająca \\ \hline 
SERVER\_IP &amp; varchar(50) &amp; Tak &amp;  &amp;  &amp; Numer IP serwera obsługującego rozdanie (jeśli właśnie trwa) \\ \hline 
SERVER\_PORT &amp; int(11) &amp; Tak &amp; 0 &amp;  &amp; Numer portu na serwerze ,,SERVER\_IP'' na którym toczy się rozgrywka \\ \hline 

 \end{longtable}


%
% Struktura: TURNIEJE
%
\newpage
\subsection{TURNIEJE}
 Tabela zawiera informacje o zaplanowanym (lub właśnie odbywającym się) turnieju. 
 
 \begin{longtable}{|l|p{3cm}|c|c|p{3cm}|p{4cm}|} 
 \caption{Struktura tabeli TURNIEJE} \label{tab:TURNIEJE-structure} \\
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline
\endfirsthead
 \caption{Struktura tabeli TURNIEJE (kontynuacja)} \\ 
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline \endhead \endfoot \textbf{\textit{ID}} &amp; int(11) &amp; Nie &amp; 0 &amp;  &amp; Unikatowy identyfikator \\ \hline 
NAZWA &amp; varchar(50) &amp; Nie &amp;  &amp;  &amp; Nazwa turnieju  \\ \hline 
ZAPISY\_OD &amp; timestamp &amp; Tak &amp; CURRENT\_TIMESTAMP &amp;  &amp; Od kiedy można zapisywać się na turniej \\ \hline 
ZAPISY\_DO &amp; timestamp &amp; Tak &amp; 0000-00-00 00:00:00 &amp;  &amp; Do kiedy można zapisywać się na turniej \\ \hline 
START &amp; timestamp &amp; Tak &amp; 0000-00-00 00:00:00 &amp;  &amp; Kiedy się rozpoczyna  \\ \hline 
KONIEC &amp; timestamp &amp; Tak &amp; 0000-00-00 00:00:00 &amp;  &amp; Kiedy się kończy  \\ \hline 
SYSTEM\_PUNKTACYJNY &amp; varchar(20) &amp; Nie &amp;  &amp;  &amp; System punktacji turnieju \\ \hline 
TRYB\_ROZGRYWEK &amp; varchar(20) &amp; Nie &amp;  &amp;  &amp; Tryb przeprowadzania turnieju \\ \hline 
OPIS &amp; longtext &amp; Nie &amp;  &amp;  &amp;  Opis turnieju\\ \hline 
DOPUSZCZAJ\_WIDZOW &amp; (1) &amp; Nie &amp;  &amp;  &amp; Czy widzowie mają mieć dostęp do rozgrywek \\ \hline 
FK\_GRACZE\_SEDZIA\_GLOWNY\_ID &amp; int(11) &amp; Nie &amp; 0 &amp; GRACZE (ID) &amp; Identyfikator sędziego głównego (założyciela) turnieju \\ \hline 
STATUS &amp; enum('zgłoszony', 'zaakceptowany', 'rejestracja', 'przed', 'w trakcie', 'zakonczony', 'przerwany', 'anulowany') &amp; Nie &amp; zgłoszony &amp;  &amp; Status turnieju\\ \hline 
FK\_UZYTKOWNICY\_SPONSOR\_ID &amp; int(11) &amp; Nie &amp; 0 &amp; UZYTKOWNICY (ID) &amp; Sponsor turnieju (tylko jego reklamy są wyświetlane) \\ \hline 
SERVER\_IP &amp; varchar(50) &amp; Tak &amp;  &amp;  &amp; Numer IP serwera obsługującego turniej (jeśli właśnie trwa) \\ \hline 
SERVER\_PORT &amp; int(11) &amp; Tak &amp; 0 &amp;  &amp; Numer portu na serwerze ,,SERVER\_IP'' na którym toczy się turniej \\ \hline 
KRYTERIA\_HASLO &amp; varchar(50) &amp; Tak &amp;  &amp;  &amp; Hasło dostępu do turnieju  \\ \hline 
KRYTERIA\_POZYCJA\_W\_RANKINGU\_GLOWNYM &amp; int(11) &amp; Tak &amp; NULL &amp;  &amp; Maksymalna pozycja w rankingu głównym aby zostać dopuszczonym do turnieju \\ \hline 
KRYTERIA\_MIASTO &amp; text &amp; Tak &amp; NULL &amp;  &amp; Miasto zamieszkania wymagane by zagrać w turnieju \\ \hline 
KRYTERIA\_KLUB &amp; text &amp; Tak &amp; NULL &amp;  &amp; Klub, do którego trzeba należeć, aby zagrać w turnieju \\ \hline 
KRYTERIA\_STAZ\_PRZED &amp; timestamp &amp; Tak &amp; 0000-00-00 00:00:00 &amp;  &amp; Przed jaką datą trzeba było być użytkownikiem portalu, aby zagrać w turnieju \\ \hline 
KRYTERIA\_FK\_INNY\_TURNIEJ\_ID &amp; int(11) &amp; Tak &amp; 0 &amp;  &amp; Identyfikator innego turnieju \\ \hline 
KRYTERIA\_FK\_INNY\_TURNIEJ\_POZ &amp; int(11) &amp; Tak &amp; 0 &amp;  &amp; Identyfikator maksymalnego miejsca w w/w turnieju, aby zagrać w bieżącym turnieju \\ \hline 
 \end{longtable}

%
% Struktura: TURNIEJE_SEDZIOWIE
%
\newpage
Tabela zawiera informacje o sędziach obsługujących turniej.
\subsection{TURNIEJE\_SEDZIOWIE}
 \begin{longtable}{|l|p{3cm}|c|c|p{4cm}|p{4cm}|} 
 \caption{Struktura tabeli TURNIEJE\_SEDZIOWIE} \label{tab:TURNIEJE_SEDZIOWIE-structure} \\
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline
\endfirsthead
 \caption{Struktura tabeli TURNIEJE\_SEDZIOWIE (kontynuacja)} \\ 
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline \endhead \endfoot \textbf{\textit{FK\_TURNIJE\_ID}} &amp; int(11) &amp; Nie &amp; 0 &amp; TURNIEJE (ID) &amp; Unikatowy identyfikator \\ \hline 
\textbf{\textit{FK\_GRACZE\_ID}} &amp; int(11) &amp; Nie &amp; 0 &amp; GRACZE (ID) &amp; Identyfikator sędziego \\ \hline 
 \end{longtable}


%
% Struktura: UZYTKOWNICY
%
\newpage
\subsection{UZYTKOWNICY}
Tabela zawiera informacje o reklamodawcach i pracownikach www.bardzofajnyportal.pl
 \begin{longtable}{|l|p{3cm}|c|c|p{4cm}|p{4cm}|} 
 \caption{Struktura tabeli UZYTKOWNICY} \label{tab:UZYTKOWNICY-structure} \\
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline
\endfirsthead
 \caption{Struktura tabeli UZYTKOWNICY (kontynuacja)} \\ 
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline \endhead \endfoot \textbf{\textit{ID}} &amp; int(11) &amp; Nie &amp;  &amp; Unikatowy identyfikator \\ \hline 
NAZWA &amp; text &amp; Nie &amp;  &amp; Nazwa \\ \hline 
LOGIN &amp; varchar(50) &amp; Nie &amp;  &amp;  \\ \hline 
MIEJSCOWOSC &amp; varchar(50) &amp; Tak &amp;  &amp; Miejscowość, z której reklamodawca działa \\ \hline 
PELNY\_ADRES &amp; text &amp; Nie &amp;  &amp; Pełny adres \\ \hline 
NIP &amp; varchar(200) &amp; Tak &amp; NULL &amp; Numer NIP \\ \hline 
HASLO &amp; varchar(30) &amp; Nie &amp;  &amp; Hasło użytkownika \\ \hline 
STATUS &amp; enum('administrator', 'pracownik', 'reklamodawca') &amp; Nie &amp; administrator &amp; Kim jest ten użytkownik \\ \hline 
EMAIL &amp; varchar(50) &amp; Nie &amp;  &amp; Adres e-mail osoby kontaktowej \\ \hline 
 \end{longtable}

%
% Struktura: WYSWIETLANE_REKLAMY
%

\newpage
\subsection{WYSWIETKANE\_REKLAMY}
Tabela zawiera informacje o reklamach do wyświetlenia, statystykach wyświetleń i kosztach
 \begin{longtable}{|l|p{3cm}|c|c|p{4cm}|p{4cm}|} 
 \caption{Struktura tabeli WYSWIETLANE\_REKLAMY} \label{tab:WYSWIETLANE_REKLAMY-structure} \\
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline
\endfirsthead
 \caption{Struktura tabeli WYSWIETLANE\_REKLAMY (kontynuacja)} \\ 
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline \endhead \endfoot \textbf{\textit{ID}} &amp; int(11) &amp; Nie &amp;  &amp;  &amp; Unikatowy identyfikator \\ \hline 
FK\_REKLAMY\_ID &amp; int(11) &amp; Nie &amp; 0 &amp; REKLAMY (ID) &amp; Identyfikator reklamy \\ \hline 
WYSWIETLEN &amp; bigint(20) &amp; Nie &amp; 0 &amp;  &amp; Liczba wyświetleń reklamy\\ \hline 
HITOW &amp; bigint(20) &amp; Nie &amp; 0 &amp;  &amp; Liczba wykorzystań odnośnika \\ \hline 
PREZENTOWANA\_OD &amp; timestamp &amp; Tak &amp; CURRENT\_TIMESTAMP &amp;   &amp; Początek okresu prezentacji reklamy \\ \hline 
PREZENTOWANA\_DO &amp; timestamp &amp; Tak &amp; 0000-00-00 00:00:00 &amp;  &amp; Koniec okresu prezentacji reklamy  \\ \hline 
STATUS &amp; enum('oczekujące', 'zaakceptowana', 'odrzucona', 'opłacona') &amp; Nie &amp; oczekujące &amp;  &amp; Status reklamy \\ \hline 
CZY\_MA\_SIE\_WYSWIETLAC &amp; (1) &amp; Nie &amp;  &amp;  &amp; Czy reklama ma zostać wyświetlona (np. nie zapłacona, ale ufamy klientowi, że zapłaci) \\ \hline 
PRIORYTET &amp; int(11) &amp; Nie &amp; 0 &amp;  &amp; Prawdopodobieństwo wyświetlenia reklamy ,,A'' to (priorytet A / suma priorytetów reklam mogących być wyświetlonymi ) \\ \hline 
OPLATA &amp; double &amp; Tak &amp; NULL &amp;  &amp; Koszt usługi  \\ \hline 
 \end{longtable}
%
% Struktura: ZAPISY_NA_TURNIEJE
%

\newpage
Tabela zawiera infomacje o parach biorących udział w turnieju. 
\subsection{ZAPISY\_NA\_TURNIEJE}
 \begin{longtable}{|l|p{3cm}|c|c|p{4cm}|p{4cm}|}  
 \caption{Struktura tabeli ZAPISY\_NA\_TURNIEJE} \label{tab:ZAPISY_NA_TURNIEJE-structure} \\
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline
\endfirsthead
 \caption{Struktura tabeli ZAPISY\_NA\_TURNIEJE (kontynuacja)} \\ 
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline \endhead \endfoot \textbf{\textit{ID}} &amp; int(11) &amp; Nie &amp;  &amp;  &amp; Unikatowy identyfikator \\ \hline 
FK\_TURNIJE\_ID &amp; int(11) &amp; Nie &amp; 0 &amp; TURNIEJE (ID) &amp; Turniej, w którym chcą zagrać \\ \hline 
FK\_GRACZE\_ID\_PROPONUJACY &amp; int(11) &amp; Nie &amp; 0 &amp; GRACZE (ID) &amp; Gracz, który wychodzi z inicjatywą zagrania \\ \hline 
FK\_GRACZE\_ID\_ZAPROPONOWANY &amp; int(11) &amp; Nie &amp; 0 &amp; GRACZE (ID) &amp; Gracz, który się do niej ustosunkowuje \\ \hline 
STATUS &amp; enum('propozycja', 'zgłoszeni', 'zdyskwalifikowani') &amp; Nie &amp; propozycja &amp;  &amp; Status pary \\ \hline 
 \end{longtable}

%
% Struktura: ZAWODY
%
\newpage
\subsection{ZAWODY}
 \begin{longtable}{|l|p{3cm}|c|c|p{4cm}|p{4cm}|} 
 \caption{Struktura tabeli ZAWODY} \label{tab:ZAWODY-structure} \\
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline
\endfirsthead
 \caption{Struktura tabeli ZAWODY (kontynuacja)} \\ 
 \hline \multicolumn{1}{|c|}{\textbf{Pole}} &amp; \multicolumn{1}{|c|}{\textbf{Typ}} &amp; \multicolumn{1}{|c|}{\textbf{Null}} &amp; \multicolumn{1}{|c|}{\textbf{Domyślnie}} &amp; \multicolumn{1}{|c|}{\textbf{Łącze}} &amp; \multicolumn{1}{|c|}{\textbf{Komentarze}} \\ \hline \hline \endhead \endfoot 
 FK\_JEZYKI\_ID &amp; int(11) &amp; Nie &amp; 0 &amp; JEZYKI (ID) &amp; Unikatowy identyfikator \\ \hline 
\textbf{\textit{NAZWA}} &amp; varchar(50) &amp; Nie &amp;  &amp;  &amp; Predefiniowana nazwa zawodu w w/w języku\\ \hline 
 \end{longtable}

\end{landscape}

% Ech... nie chce nam sie jakos to szczegolowo robic i bym to unikal. Widze tu:
% - podzial na fragmenty bazy danych, wymienione w sekcji 2, kazdy fragment jakos belkotliwie szczegolowiej omowiony.
% - jakies puste slowa o wydajnosci
\newpage
\section{Konfiguracja}
Wszystkie procesy zakładają istnienie plików konfiguracyjnych w lokalizacji "/etc/bs". Zakładamy, że
będą to dowiązania symboliczne do jednego - współnego pliku konfiguracji w obrębie wszyskich maszyn 
obsługujących nasz system (NFS). 

Konfiguracja będzie zapisana w pliku xml (ze względu na proste parsowanie w Javie i potrzebę hierarchicznej struktury tego pliku konfiguracyjnego) i będzie obejmowała:
\begin{itemize}
  \item[-]Parametry współdzielone
%  	\begin{description}
%	\end{description}
  \item[-]Parametry demona nadzorującego
%  	\begin{description}
%		\item[IP serwera] Numer IP serwera na którym ma być uruchomiony serw
%		\item[port serwea] Numer portu na którym serwer chata prowadzi nasłych
%	\end{description}
  \item[-]Parametry serwera pojedyńczego turnieju
  	\begin{description}
		\item[IP serwerów] Numery IP serwerów na którym mają być uruchomione serwery pojedyńczego turnieju
		\begin{description}
			\item[Zakresy portów] Zakres portów na których serwery turniejów mogą prowadzić nasłuch dla danego numeru IP (liczba przyznanych portów ogranicza maksymalną liczbę toczących sie turniejów)
		\end{description}
	\end{description}
  \item[-]Parametry serwera gier towarzyskich
  	\begin{description}
		\item[IP serwera] Numer IP serwera na którym ma być uruchomiony serwer gier towarzyskich
		\item[port serwera] Numer portu na którym serwer prowadzi nasłuch
	\end{description}
  \item[-]Parametry serwera pojedyńczego rozdania
  	\begin{description}
		\item[IP serwera] Numery IP serwerów na którym ma być uruchomiony serwer pojedyńczego rozdania
		\begin{description}
				\item[zakres portów serwera] Numery portów na których serwery rozdań na danej maszynie będzą prowadzić nasłuch (ogranicza to maksymalna liczbę rozdań w systemie) 				
		\end{description}
	\end{description}
  \item[-]Parametry serwera chata
  	\begin{description}
		\item[IP serwera] Numer IP serwera na którym ma być uruchomiony serwer chata
		\item[port serwea] Numer portu na którym serwer chata prowadzi nasłuch
	\end{description}
\end{itemize}

\newpage

\section{Protokoły sieciowe}
Cała komunikacja sieciowa w systemie została oparta o protokół ,,SOAP - Messaging Documents''. Jako 
warstwa transportująca wykorzystywane jest przeważnie zwykłe połączenie TCP-IP - jedynie tylko w kilku
przypadkach wykorzystywane jest SOAP poprzez HTTP (pobieranie listy dostępnych turniejów przez aplikacje sędziowską).

\subsection{Przestrzenie nazw}
	W komunikatach będziemy wykorzystywali następujące przestrzenia nazw: 
	\begin{description}
		\item[soap] - (Simple Object Access Protocool) - przestrzeń nazw standardowych elementów protokołu SOAP. 
		\item[bml]  - (Bridge Markup Language) - przestrzeń nazw obejmujące standardowy język Bridge Markup Language - zawierający opisy kart, rozdań itp. 
		\item[bs]   - (Bridge System) - przestrzeń nazw utworzona specjalnie na potrzeby tego systemu brydżowego.
	\end{description}

\subsection{Komunikaty przy przeprowadzaniu rozdania}
	\subsubsection{Komunikaty do serwera pojedynczego rozdania}
 	\begin{SOAPmsgs}
	    \SOAPmsg{bs::get\_about}	{}{Prosi o informacje o rozdaniu}{bs::about\_game}
	    \SOAPmsg{bs::get\_players}	{}{Prosi o informacje o zalogowanych graczach}{bs::players\_info}
	    \SOAPmsg{bs::quit}		{}{Informuje serwer o zakończeniu połączenia}{}
	    \SOAPmsg{bs::get\_deal}	{}{Prosi o informacje o ,,rozdanych'' kartach}{bs::deal}
	    \SOAPmsg{bs::get\_heand}	{}{Prosi o informacje o kartach na ręce}{bs:hands}
	    \SOAPmsg{bs::who}		{}{Pyta serwer, kto teraz powinien ,,wykonać ruch'' (licytować/dorzucić karę)}{bs::turn}
	    \SOAPmsg{bs::get\_history}  {}{Prosi serwer o podanie historii dotychczasowej rozgrywki}{bs::history}
	    \SOAPmsg{bs::get\_contract}  {}{Prosi serwer o podanie rozgrywanego kontraktu}{bs::contract}
	    \SOAPmsg{bs::get\_table}  {}{Prosi serwer o podanie kart znajdujących się na stoliku}{bs::table}
	    \SOAPmsg{bs::login\_player}  {bs::player\_login\\bs::player\_password}{Umożliwia zalogowanie się gracza do rozdania}{}
	    \SOAPmsg{bs::login\_server}  {}{Logowanie się serwera turnieju - uwierzytelnienie po IP}{}
	    \SOAPmsg{bs::login\_director}  {bs::player\_login\\bs::player\_passowrd}{Umożliwia zalogowanie się sędziego do serwera rozdania}{}
	    \SOAPmsg{bs::set\_players}  {bs::table}{Wywoływana przez serwer turnieju (lub gier towarzyskich): Ustala pozycje poszczególnych graczy}{}
	    \SOAPmsg{bs::set\_deal}	{bs::deal}{Wywoływana przez serwer turnieju (lub gier towarzystkich). Ustala rozdanie}{}
	    \SOAPmsg{bs::set\_deal\_random} {bs::deal}{j.w; Losuje rozdanie}{}
	    \SOAPmsg{bs::send\_message} {bs::message\_text \\bs::to}{Wysyła wiadomość do wybranego (lub wszystkich) graczy i widzów (od sędziego lub serwera nadrzędnego)}{} 
	    \SOAPmsg{bs::kick} {bs::player\_login} {Powoduje wydalenie gracza z rozgrywki}{}
	    \SOAPmsg{bs::set\_dealer} {bs::player\_login} {Powoduje ustalenie gracza, który rozdawał - czyli gracza, który będzie rozpoczynał licytację}{}
	    \SOAPmsg{bs::start\_game} {}{Powoduje rozpoczęcie rozgrywki - o ile wszyscy niezbędni gracze są zalogowani} {bs::game\_started}
	    \SOAPmsg{bs::cancel}{} {Anuluje grę - rozłącza wszystkich graczy i zamyka serwer rozdania}{}
	    \SOAPmsg{bs::give\_bid}{bml::bid}{Odzywka gracza w licytacji}{bs::bid}
	    \SOAPmsg{bs::play\_card}{bml::card}{Karta dorzucona przez gracza}{bs::card}
	\end{SOAPmsgs}
	\subsubsection{Komunikaty od serwera pojedynczego rozdania}
 	\begin{SOAPmsgs}
	    \SOAPmsg{bs::player\_logged}{bs::ip\\bs::player\_login}{Zwraca login i ewentualnie numer IP jednego zalogowanego gracza}{}
	    \SOAPmsg{bs::director\_logged}	{bs::player\_name}{Zwraca nazwę(login) zalogowanego sędziego}{}
	    \SOAPmsg{bs::about\_game}		{bs::about\_game\_info}{Zwraca informacje ogólne o turnieju}{}
	    \SOAPmsg{bs::deal}			{bml::deal}{Zwraca informacje o karta które widzi gracz zadający pytanie}{}
	    \SOAPmsg{bs::hands}			{bml::deal}{Zwraca informacje o kartach, które znajdują się na rękach graczy - i są widziane przez gracza proszącego o dane}{}
	    \SOAPmsg{bs::turn}		{bs::direction}{Zwraca informacje którego gracza jest teraz ruch: N E S W}{}
	    \SOAPmsg{bs::players\_info}		{bs::table}{Zwraca informacje o rozmieszczeniu zalogowanychgraczy przy stoliku }{}
	    \SOAPmsg{bs::history}		{bml::game}{Zwraca historię dotychczasowej rozgryki }{}
	    \SOAPmsg{bs::contract}		{bs::table}{Zwraca informacje o rozmieszczeniu zalogowanychgraczy przy stoliku }{}
	    \SOAPmsg{bs::table}			{bml::cards}{Zwraca informacje o kartach znajdujących sie aktualnie na stoliku}{}	
	    \SOAPmsg{bs::message}		{bs::message\_text}{Przekazuje wiadomość od sędziego lub serwera}{}	
	    \SOAPmsg{bs::game\_started}		{}{Informuje o rozpoczęciu rozgrywki}{}
	    \SOAPmsg{bs::bid}			{bs::player\_login bml::bid}{Informuje, że gracz odezwał się w licytacji}{}
	    \SOAPmsg{bs::card}			{bs::player\_login bml::card} {Informuje, że gracz dorzucił kartę}{}
	    \SOAPmsg{bs::licytation\_finished}	{}{Informuje, że licytacja zakończyła się}{}
	    \SOAPmsg{bs::four\_pas}		{}{Informuje o 4 kolejnych pasach (natychmiastowe wygaśniećie licytacji))}{}
	    \SOAPmsg{bs::player\_gets\_cards}	{bs::player\_login}{Informuje o tym, który gracz wziął lewę}{}
	\end{SOAPmsgs}
	
%	\subsubsection{Komunikaty do serwera turnieju}
 %	\begin{SOAPmsgs}
%	    \SOAPmsg{}{b}{c}{d}
%	    \SOAPmsg{a1}{b1}{c1}{d1:}
%	\end{SOAPmsgs}
%	\subsubsection{Komunikaty od serwera turnieju}
 %	\begin{SOAPmsgs}
%	    \SOAPmsg{}{b}{c}{d}
%	    \SOAPmsg{a1}{b1}{c1}{d1:}
%	\end{SOAPmsgs}

%\subsection{Komunikaty chata}
 %	\begin{SOAPmsgs}
%	    \SOAPmsg{}{b}{c}{d}
%	    \SOAPmsg{a1}{b1}{c1}{d1:}
%	\end{SOAPmsgs}


\newpage
\section{Wielkość i wydajność}

\subsection{Założenia}
W ,,Wizji biznesowej'' zostały podjęte następujące założenia dotyczące wykorzystania systemu:
\begin{itemize}
\item Od jednego do kilku turniejów dziennie.
\item Kilkanaście dużych turniejów w ciągu roku.
\item Kilkadziesiąt turniejów i konkursów obecnie organizowanych w świecie rzeczywistym, przeniosłoby się do projektu.
\item Około tysiąca zarejestrowanych sędziów.
\item Około stu tysięcy zarejestrowanych graczy.
\item Jednoczesne podłączenie kilkuset graczy.
\item Średni rozmiar turnieju - kilkaset osób.
\item Kilka tysięcy wizyt dziennie.
\item Koszt wyświetlania banera przez jeden dzień w granicach 500 zł.
\end{itemize}

Szacując je z góry, otrzymamy następujące założenia, które będą stanowiły bazę wyjścia do oszacowania
wydajności i wymaganych zasobów przez system:

Równocześnie może się odbywać (patrząc logicznie):
\begin{itemize}
\item 10 turniejów po 200 graczy dziennie (10000 rozdań w takim turnieju)
\item 2 turnieje po 500 graczy (100000 rozdań w takim turnieju)
\item 100000 zarejestrowanych użytkowników portalu
\item 1000 graczy oglądających strony www (wysyłających żądania dostępu, średnio co 20 sekund)
\item 500 reklamodawców współpracujących z www.bardzofajnyportal.pl
\end{itemize}

Fizycznie zakładamy, że reprezentacja następujących obiektów logicznych wymaga następujących zasobów systemowych:
\begin{description}
\item [Dane prywatne jednego gracza (zawarte w profilu)] 10kb
\item [Dane opisujące historię jednego rozdania] 5kb
\item [Dane opisujące jeden mały turniej (bez historii rozdań, ale ze zgłoszeniami)] 100kb
\item [Dane opisujące jeden duży turniej (bez historii rozdań, ale ze zgłoszeniami)] 500kb
\item [Łączny rozmiar reklam zgłoszonych przez jednego reklamodawcę] 10000kb
\end{description}

\subsection{Wymagania co do pojemności urządzeń}
Zatem dzienny przyrost wielkości bazy danych można przeszacować przez $(10*10000rozdań+2*100000 rozdań)*5kB + 10*100kB +2*500kB = 300000 rozdań * 5kB + 2MB = 1,5GB $
Zatem udziałowiec na potrzeby przechowywania pełnej historii rozdań z jednego roku powinien wyposażyć się w macierz dyskową o logicznej pojemności 500 gigabajtów. 
Strony stałe www.bardzofajnyportal.pl nie przekroczą 1GB. 

Ponadto udziałowiec powinien przygotować urządzenia do przyrostowego backupu na poziomie 1,5GB dziennie.

\subsection{Łącze internetowe}
Można założyć, że łączny transfer wchodzący w związku z organizacją turniejów nie przekroczy 5 krotności danych zapisywanych w bazie danych w związku z turniejem, co daje 10 GB dziennie.
Ponadto transfer związany z rozgrywanymi przez użytkowników portalu rozdaniami towarzyskimi wyniesie 5*(1000 graczy * 40 rozdań)*5kb = 1 GB.
Reasumując - 11 GB dziennie. Załóżmy, że 80\% przypada na 6h w ciągu dnia, z czego wynika 
potrzeba transferu obsługi wchodzącego związanego z obsługą rozgrywek na poziomie 5 megabitów na sekundę. 

Przyjmujemy, że transfer wychodzący związany z obsługą rozdań jest analogiczny. Dochodzi do tego ponadto
500 kilobajtów na użytkownika związanych z wysyłaniem do niego reklam oraz 10 magabajtów na użytkownika związanych
z przeglądanymi przez niego stronami portalu www.bardzofajnyportal.pl. 
Co daje $11 GB (rozdania)+ 0,5 GB (reklamy) + 10GB (oglądanie stron i czat) = 22 GB $
Analogicznie licząc jak w przypadku transferu wychodzącego otrzymujemy 10 megabitów na sekundę. 

Reasumując - zalecamy łącze o przepustowości 5 megabitów/s dla transferu wchodzącego i 10 megabitów
dla transferu wychodzącego. 

\subsection{Łącze intranetowe}

Transfer wewnętrzny nie będzie istotnie większy od komunikacji ze światem zewnętrznym. 100 megabitowa sieć
LAN będzie wystarczająca. 

\subsection{Baza danych} 
Ze względu na dużą objętość i liczbę odwołań do bazy danych, system będzie wdrożony na serwerze Oracle 10i Database Enterprise Edition. 
Powinien on, na serwerze wyposażonym w dyski o przepustowości 100 megabajtów na sekundę i 2GB RAMu, odpowiadać natychmiastowo na wszelkie zapytania (przewidujemy, że 98\% zapytań będzie prostymi wyszukiwaniami na indeksowanych kolumnach). Oczekujemy, że czas wykonania zapytania
na potrzeby sporządzenia rankingu graczy nie przekroczy 0,01 sekundy (przy nie cashowanych wynikach). 

Zapytania specjalne (na potrzeby pracownika www.bardzofajnyportal.pl) generujące specjalne zestawienia w oparciu o pełnotekstowe przeszukiwanie kolumn XMLowych
(z wykorzystanie XPath) przy bazie o objętości 1 terabajta mogą potrwać nawet 10 minut. 

% No ze baza danych wydajna. Liczby powrotrzone z rozdzialu 3, ile czegos, plus ile rozdan dziennie, szacowana wielkosc bazy danych,
% ze graczy to bedzie wiele a reszty malo, itd.

\newpage

%\section{Jakość}
% No highest jakosc! ;)
% Powtorzyc o portability aplikacji klienckich.
% Ze ma byc mozliwosc wsadu nowych modulow: nowy typ rankingu. Nowy sposob rozmieszczania przy stolikach w turnieju. Nowa opcja w menu w aplikacjach.
% Fajny dobry protokol BTP ;)
% Szyfrowanie hasel w bazie danych.
% Polaczenie po sslu jesli ktos chce.
% no more pomyslas...

\end{document}

</pre></body></html>