Snatch, serwer brydżowy Plan architektury systemu

Transkrypt

1 Snatch, serwer brydżowy Plan architektury systemu Michał Korch Piotr Tomanek Marcin Pilipczuk Piotr Tabor 16 maja 2005 roku Wersja: 1.3 environment Historia Data Wersja Autor Zmiany Michał Korch Stworzenie wzorca całości dokumentu i dodanie wstępu Marcin Pilipczuk Rozdział drugi, widok procesów oraz komentarze - zarys co gdzie powinno być Marcin Pilipczuk Widok logiczny oraz widok infrastruktury b Piotr Tabor Tytuł, wydajność oraz najważniejsze algorytmy b Michał Korch Widok przypadków użycia b Piotr Tabor Schemat danych oraz Założenia i ograniczenia Piotr Tomanek Poprawki kontrolera jakości. Ostateczna wersja Marcin Pilipczuk Drobne poprawki Michał Korch Naniesienie poprawek Piotra T. do implementacji i poprawek Piotr Tabor kontrolera Poprawienie widoku implementacyjnego, dopisanie konfiguracji i protokołów sieciowych Spis treści 1 Wstęp Cel dokumentu Definicje i skróty Źródła Streszczenie Prezentacja architektury Widok Przypadków Użycia Widok logiczny Widok procesów Widok infrastruktury Widok implementacyjny Widok przechowywania danych Założenia i ograniczenia dotyczące architektury UTF Bridge Markup Language Protokoły sieciowe Zagrożenia sieciowe Przegląd przypadków użycia Gracz i widz Sędzia Reklamodawca Pracownik

2 5 Widok logiczny Omówienie Najważniejsze komponenty Moduły obsługi rozdania Moduły obsługi turniejów i inicjowania rozgrywek towarzyskich Moduły rankingowe Moduły czatu Moduły o osobach Moduły o reklamach Moduły pomocy i FAQ Inne moduły aplikacji klienckich Inne moduły aplikacji serwerowych Realizacja przypadków użycia Rozegranie towarzyskiej partyjki Stencel Diks kontra Mincer Engel Rozegranie turnieju o mistrzostwo wydziału, sędziuje pan Deminet Gracz Michał K. szuka odpowiedzi na nurtujące go pytanie Sędzia Piotr T. zmienia swój adres Reklamodawca Grzegorz G. sprawdza, jak jego baner funkcjonuje Pracownik pan Jakub Ciekawski dodaje swój ranking Widok procesów Serwer pojedynczego rozdania Serwer turnieju Demon nadzorujący Aplikacja kliencka: gracza, widza i sędziego Serwer www Apache z serwerem JBoss Proces czatu Baza danych Widok infrastruktury 24 8 Widok implementacyjny Języki programowania Warstwy Uwierzytelnianie użytkowników Tworzenie logów Synchronizacja procesów Najważniejsze algorytmy Widok przechowywania danych FAQ GRACZE INTERWENCJE SEDZIOWSKIE JEZYKI PRACOWNIK TO DO RANKINGI RANKINGI DANE REKLAMY ROZDANIA ROZGRYWKI PRYWATNE ROZGRYWKI TURNIEJOWE TURNIEJE TURNIEJE SEDZIOWIE UZYTKOWNICY WYSWIETKANE REKLAMY ZAPISY NA TURNIEJE ZAWODY Konfiguracja 48 2

3 11 Protokoły sieciowe Przestrzenie nazw Komunikaty przy przeprowadzaniu rozdania Komunikaty do serwera pojedynczego rozdania Komunikaty od serwera pojedynczego rozdania Wielkość i wydajność Założenia Wymagania co do pojemności urządzeń Łącze internetowe Łącze intranetowe Baza danych

4 1 Wstęp 1.1 Cel dokumentu Celem tego dokumentu jest przedstawienie architektury systemu. Dokument ma przedstawić wizję architektury systemu z różnych stron. Ten dokument stanowi podstawę do: 1. podziału pracowników na zespoły, 2. przydziału pracy implementatorom, 3. ustalenia kolejności wykonywania komponentów systemu, 4. prac nad schematem bazy danych, 5. zamówień odpowiedniego sprzętu, 6. opracowywania interfejsów między poszczególnymi modułami. 1.2 Definicje i skróty projekt To, co ten dokument opisuje - projekt rozgrywek brydżowych przez internet. gracz Klient grający w brydża przez działający projekt. widz Klient obserwujący rozgrywki. sędzia Klient mający większe uprawnienia, organizujący turnieje i nadzorujący je. udziałowiec Portal który jest udziałowcem i docelowym właścicielem binarnej wersji projektu. zespół Zespół wykonujący projekt 1.3 Ź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. 1.4 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ę. 4

5 2 Prezentacja architektury Jak wynika z Wizji, projekt składa się z następujących elementów: Bazy danych przechowującej informacje o rozgrywkach Będzie to Oracle 10i: - 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). - umożliwiający analizę danych przy pomocy zewnętrznych narzędzi dostarczonych z bazą danych - umożliwiający łatwe sporządzanie kopii bezpieczeństwa przy pomocy mechanizmów wbudowanych - umożliwiający podział obowiązków na wiele maszyn przy wzroście zapotrzebowania (obsługa systemół Gridowych) 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). Serwera pojedynczego rozdania - Zarządza przeprowadzeniem pojedynczego rozdania brydżowego. - Zostaje uruchomiony poprzez utworzenie instancji klasy javowej na skutek wywołania RPC zainicjalizowanej przez serwer pojedynczego turnieju. - Podłączają się do niego klienci(na określony adres IP i port zapisany w bazie danych (tabela ROZDA- NIA)) 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. - 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. - Kończy działanie Serwera pojedynczego turnieju - Odpowiada za przeprowadzenie całego turnieju - 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ć). - 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. - 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) - Aktualizuje wpisy w bazie danych - dotyczęce serwera i portu na którym jest uruchomiony - 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. - Po zakończeniu turnieju przygotowuje rankingi i zapisuje je do bazy danych oraz aktualizuje dane turnieju. - Kończy działanie. 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. 5

6 Aplikacji klienckiej gracza i widza (apletu) - odpowiada za uczestnictwo gracza lub możliwość oglądania przez widza pojedyńczego turnieju. - 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. - Aplet łączy się ze wskazanym serwerem i ewentualnie dokonuje autoryzacji - Aplet przeprowadza/pokazuje rozdanie udostępniając wykodny interfejs użytkownika - Aplet kończy działanie Aplikacji klienckiej sędziego - stanowi interfejs użytkownika do zarządzanie turniejem przez sędziego - Aplikacja sędziowska zostaje uruchomiona przez sędziego na komputerze klienckim - Aplikacja sędziowska pyta o dane uwierzytelniające użytkownika i go loguje - 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 - Aplikacja sędziowska odczytuje (poprzez SOAP) dane wybranego turnieju (w tym serwer i port) i ustawnawia połączenie TCP/IP z serwerem tego turnieju - Aplikacja umożliwia sterowanie turniejem - Aplikacja zostaje wyłączona Demona nadzorującego - uruchamiany przez CRON a co minutę (domyślnie) na każdej maszynie obsługującej system - Sprawdza, czy wszystkie procesy turniejów, które powinny być uruchomione na danej maszynie są uruchomione i ewentualnie je uruchamia - Sprawdza, czy odpowiednie serwery są uruchomione (serwer gier towarzystkich, serwer chata) Stron www dla graczy i widzów - prezentacja danych Zrealizowane w postaci serwletu Stron www dla sędziów - prezentacja danych Zrealizowane w postaci serwletów Stron www dla pracownika - prezentacja danych Zrealizowane w postaci serwletów Stron www dla reklamodawcy - prezentacja danych Zrealizowane w postaci serwletów W tym: 1. Do bazy danych podłączają się: strony www, serwery turniejów, rozdań oraz demon nadzorujący. 2. Do 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. 3. Do 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. 4. Aplikacja gracza i widza łączy się z wszystkimi serwerami i demonami. 5. Aplikacja sędziego łączy się z wszystkimi serwerami i demonami. 6. 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. 7. Strony www wyświetlają statycznie informacje z bazy danych. Dodatkowo niezależnym wątkiem pobocznym będzie 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: 6

7 2.1 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. 2.2 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: Moduły obsługi rozdania Moduł dostępu do bazy danych - danych rozdania. Moduł przeprowadzania rozdania. Moduł grania. Moduł wyświetlania gry. Moduł komunikacyjny aplikacja kliencka - serwer rozdania. Moduły obsługi turniejów i inicjowania rozgrywek towarzyskich Moduł dostępu do bazy danych - danych turnieju. Moduł komunikacyjny aplikacja kliencka - serwer turnieju. Moduł wyświetlania organizacji stolików, podchodzenia do stolików, zapraszania. Moduł konfiguracji turnieju i zarządzania nim. Moduł konfiguracji struktury turnieju, moduły definiujące schematy turniejów. Moduł podliczający i wyświetlający wyniki. Moduł nadzorowania turnieju przez serwer. Moduły rankingowe Moduł wyświetlający rankingi i pojedynczy ranking w aplikacji klienckiej. Moduł wyświetlający rankingi i pojedynczy ranking przez www. Moduł wyszukujący gracza i wysyłający rankingi. Moduł dostępu do bazy danych - rankingi. Moduł tworzenia rankingów przez www. Moduły czatu Moduł wyświetlający rozmowę w aplikacji klienckiej. Moduł komunikacji p2p w rozmowie. Program czatu, zestawiający te połączenia. Moduły manipulujące danymi osobowymi Moduł dostępu do bazy danych - osoby. Moduł autoryzacji od strony aplikacji klienckiej. Moduł autoryzacji od strony serwera. Moduł wyświetlania i zmieniania swoich danych w aplikacji klienckiej. Moduł obsługi żądań zmian danych. Moduł wyszukiwania osób i robienia statystyk. Moduły manipulujące danymi reklam 7

8 Moduł dostępu do bazy danych - reklamy i reklamodawcy. Moduł wyświetlania reklamy w aplikacji klienckiej. Moduł zarządzania reklamami. Moduł interfejsu www z reklamodawcą i pracownikiem w kwestii reklam. Moduły pomocy i FAQ Moduł interfejsu do FAQ przez www dla pracownika i klienta. Manual. Inne moduły aplikacji klienckich Moduł menu. Aplikacja kliencka gracza. Rozszerzenia sędziego. Inne moduły aplikacji serwerowych Procesy: demon nadzorujący, serwer turnieju, serwer rozdania. Moduł utrzymywania i wznawiania połączenia z klientem. Moduł backupu bazy danych. 2.3 Widok procesów 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: 1. Jeden proces obsługujący czat. 2. Jeden proces - demon nadzorujący. 3. Dla każdego turnieju proces serwera turnieju. 4. Dla każdego rozdania proces serwera rozdania. 5. Aplikacja kliencka. 6. Serwer www (Apache). 2.4 Widok infrastruktury Widok ten opisuje rozmieszczenie procesów i modułów na maszynach oraz konieczną infrastrukturę połączeń. 2.5 Widok implementacyjny Widok ten przedstawia podział systemu na następujące warstwy oraz rozmieszczenie modułów w warstwach: Warstwa bazy danych. Warstwa funkcji dostępowych do bazy danych. Warstwa pojedynczej rozgrywki. Warstwa turnieju. Warstwa nadzoru nad rozgrywkami i turniejami. Warstwa łączności z klientami (łączenie z aplikacjami + www). Warstwa łączenia się z serwerami aplikacji klienckich. Warstwa interfejsu aplikacji klienckich. 8

9 2.6 Widok przechowywania danych Widok ten opisuje ogólną wizję bazy danych, na którą składają się następujące części: Informacje o pojedynczych rozgrywkach. Informacje o turniejach. Informacje o rankingach. Informacje o osobach. Informacje o reklamach. 9

10 3 Założenia i ograniczenia dotyczące architektury 3.1 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. 3.2 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 serwer turnieju serwer rozdania 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) 3.3 Protokoły sieciowe Ze względu na komunikację serwer turnieju serwer rozdania aplikacja kliencka istnieje potrzeba opracowania protokołów sieciowch wykorzystujących TCP/IP. 3.4 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). 10

11 4 Przegląd przypadków użycia 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ę. 4.1 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. Zalogowanie się gracza Aplikacja kliencka przekazuje dane demonowi nadzorującego, który w celu dokonania autoryzacji łączy się z bazą danych. Rejestracja gracza Gracz rejestruje się za pomocą strony www. Jego dane zapisywane są w bazie danych. 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ł. Rozegranie meczu brydżowego Z punktu widzenia architektury nie różni się od rozegrania zwykłego turnieju. Przeglądanie dostępnych turniejów dla gracza Aplikacja kliencka wyświetla listę turniejów, którą udostępni jej demon nadzorujący. Zarejestrowanie się do turnieju Aplikacja kliencka przesyła żądanie zarejestrowania do turnieju demonowi nadzorującemu, który zapisuje odpowiednie informacje w bazie danych. 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. 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. Modyfikacja własnych ustawień gracza Gracz za pośrednictwem formularza www zmienia ustawienia. Zmiany są zapisywane w bazie danych. 11

12 Oglądanie trwającej rozgrywki Serwer turnieju podłącza aplikacje widzów do odpowiednich serwerów rozdań. 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. 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. Rozmowa gracza z innymi graczami Aplikacja kliencka komunikuje się z demonem nadzorującym, ten przekierowywuje żądania do procesu czatu. 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. 4.2 Sędzia Sędzia na początku swojej pracy uruchamia aplikację sędziego, która łączy się z demonem nadzorującym. Zalogowanie sędziego do portalu Autoryzacji dokonuje demon nadzorujący na podstawie danych zebranych przez aplikację kliencką i bazy danych. Zgłoszenie gracza, który chce zostać sędzią Aplikacja gracza przesyła odpowiednią informację do demona nadzorującego, który zapisuje ją w bazie danych. Utworzenie nowego turnieju Aplikacja sędziego przesyła dane nowego turnieju demonowi nadzorującemu, który zapisuje odpowiednie informacje w bazie danych. Przeglądanie chętnych do turnieju i usuwanie ich 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. Wystartowanie własnego turnieju 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. Usunięcie nieobecnych graczy 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. Rozpoczęcie turnieju Serwer turnieju otrzymuje od aplikacji sędziego polecenie rozpoczęcia turnieju, o czym informuje aplikacje zalogowanych graczy. 12

13 Rozmowa gracza z graczem Patrz: widok od strony gracza. Nałożenie kary punktowej na gracza bądź parę Sędzia za pośrednictwem swojej aplikacji informuje serwer turniejowy o podjętej decyzji, ten ją rejestruje i powiadamia odpowiednie aplikacje klienckie. Usunięcie gracza z turnieju 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. Obejrzenie rozgrywki z turnieju Aplikacja sędziego za pośrednictwem serwera turnieju podłącza się do serwera konkretnego rozdania. Podsumowanie wyników turnieju, ustalenie końcowego rankingu 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. 4.3 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. 4.4 Pracownik 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. 13

14 5 Widok logiczny 5.1 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ą: 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. 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. 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. Obsługa czatu. Obejmuje obsługę połączeń p2p komunikatora oraz zestawianie połączeń przez proces czatu. Obsługa danych osobowych. Obejmuje przechowywanie w bazie danych informacji o osobach, protokoły autoryzacji, aktualizacji swoich danych oraz wyszukiwania osób i statystyk. Obsługa reklam. Obejmuje wyświetlanie reklam, zarządzanie nimi oraz interfejs reklamodawcy. Obsługa FAQ i pomocy. Obejmuje zadawanie pytań przez www i aplikację kliencką, przechowywanie FAQ, interfejs pracownika oraz manuale. Inne istotne części aplikacji klienckiej. Menu, rozszerzenia sędziowskie. Inne istotne części serwerów. Moduł podtrzymywania i wznawiania połączeń, moduł backupu danych. Opisane zostały bardziej istotne części systemu wraz z ich najważniejszymi klasami. 5.2 Najważniejsze komponenty Rozrysowanie przyporządkowania modułów do procesów i warstw znajduje się w schemacie logicznym Moduły obsługi rozdania Moduły te służą obsłudze pojedynczego rozdania brydżowego. 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. 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. 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. 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. 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. 14

15 5.2.2 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. 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. 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. 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. Moduł konfiguracji turnieju i zarządzania nim. Część rozszerzeń sędziowskiej aplikacji. Definiuje interfejs zakładania nowego turnieju, zmiany jego konfiguracji, uruchamianie go. 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. Moduł podliczający i wyświetlający wyniki. Moduł po stronie aplikacji sędziowskiej, wyświetlający i zarządzający wynikami turnieju. 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ń Moduły rankingowe Moduły te służą wyświetlaniu rankingów i tworzeniu nowych systemów punktowych. Moduł wyświetlający rankingi i pojedynczy ranking w aplikacji klienckiej. Część aplikacji klienckiej wyświetlający rankingi. Moduł wyświetlający rankingi i pojedynczy ranking przez www. Wyświetla rankingi w postaci stron html. 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. 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ło- Rankingu, 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. Moduł tworzenia rankingów przez www. Moduł umożliwiający tworzenie nowych podklas LiczydłoRankingu przez www. 15

16 5.2.4 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. Moduł wyświetlający rozmowę w aplikacji klienckiej. Przypomina wyglądem okienko GG. Potrafi wyświetlać emotikony :P. Moduł komunikacji p2p w rozmowie. Moduł komunikacyjny - przesyłania informacji z rozmowy. 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 Moduły o osobach Moduły te zarządzają danymi osobowymi graczy oraz autoryzacją. Moduł dostępu do bazy danych - osoby. Definiuje klasę BazaDanychOsoba, która potrafi serializować się do bazy danych, przechowuje informację o osobie. 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. 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ę. 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. 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. 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 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. 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ń. Moduł wyświetlania reklamy w aplikacji klienckiej. Moduł pobierający z serwera reklamę i wyświetlający ją w odpowiednim miejscu aplikacji klienckiej. 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, 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 Moduły pomocy i FAQ Moduły poniższe zapewniają mechanizm działania FAQ oraz Manuali. 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ź. Manual. Manuale w postaciach texinfo i.hlp, dostępne do ściągnięcia z witryny (statyczne). 16

17 5.2.8 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. Moduł menu. Moduł definiuje klasę Menu i MenuPrzycisk, które są odpowiedzialne za funkcjonowanie menu w aplikacji klienckiej. Aplikacja kliencka gracza. Aplikacja kliencka gracza dokładniej jest opisana w Widoku Procesów. Zespala ona moduły klienckie w aplecie Javy. 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 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. 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. 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ń. Moduł backupu bazy danych. Ten moduł jest zestawem skryptów bazy danych umożliwiającym zachowanie stanu bazy danych i odtworzenie po awarii. 5.3 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 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. 17

18 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ą 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 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 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 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. 18

19 5.3.3 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ź Sędzia Piotr T. zmienia swój adres Piotrowi zlikwidowano jedno konto, które podał jako adres w serwerze 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 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 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 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 Pracownik 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. 19

20 6 Widok procesów 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. 6.1 Serwer pojedynczego rozdania Serwer pojedynczego rozdania jest procesem pomocniczym. Działa on jednoprzebiegowo robiąc: 1. Jako argument dostaje numer rozdania, które jest zapisane w bazie danych. 2. Łączy się z bazą danych. 3. Otrzymuje informacje nt. graczy rozdania, typu rozdania (towarzyskie, turniejowe) oraz kartach (ew. w bazie danych jest informacja wylosować rozdanie ). 4. Oczekuje na połączenia od graczy. W przypadku rozdania towarzyskiego obsługuje zapraszanie graczy do stolika. 5. Wysyła karty graczom. 6. Przeprowadza licytację. 7. Przeprowadza rozgrywkę. 8. Przekierowuje prośby o rozmowę do procesu czatu. 9. Zapisuje wynik do bazy danych. 10. W przypadku rezygnacji któregoś z graczy zapisuje ten fakt też do bazy danych. 11. Informuje swojego zleceniodawcę (demon nadzorujący lub serwer turnieju) o końcu rozdania. 6.2 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: 1. Jako argument dostaje numer turnieju o którym informacje są zapisane w bazie danych. 2. Pobiera te informacje z bazy danych. 3. Czeka na podłączenie sędziego turnieju (założyciela). 4. Czeka na potwierdzenie od sędziego uruchomienia turnieju. 5. Czeka na podłączenia graczy. Informuje sędziego o ewentualnych brakach i odbiera i obsługuje decyzje sędziego (wyrzucanie par, zmiana konfiguracji rozdań). 6. Czeka na potwierdzenie od sędziego o ruszeniu turnieju. 7. Rusza turniej, nadzoruje wykonanie kolejnych rozdań (uruchamia serwery rozdań), zbiera wyniki i zaprasza kolejnych graczy do kolejnych stolików. 8. 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). 9. Umożliwia widzom oglądanie dawniejszych i obecnych rozdań. 10. Umożliwia sędziemu oglądanie dawniejszych i obecnych rozdań, wraz z kartami graczy. 11. Przyjmuje kary i informuje o nich graczy. 12. Przekierowuje prośby o rozmowę do procesu czatu. 13. Wysyła do apletu sędziowskiego wyniki zakończonych rozdań. 20