Rubik s Manager - SAD Sebastian Chojniak, Łukasz Krupa, Grzegorz Łuczyna 16 maja 2007 1
Spis treści 1 Wprowadzenie 4 1.1 Cel.......................................... 4 1.2 Zakres........................................ 4 1.3 Definicje....................................... 4 1.4 Załączniki...................................... 4 2 Prezentacja architektury systemu 5 3 Załozenia i zależności 5 4 Przeglad przypadków użycia 6 4.1 Skrócony opis przypadków użycia......................... 6 4.1.1 Trening początkującego speedcubera................... 6 4.1.2 Trening speedcubera - trening podstawowy................ 6 4.1.3 Trening speedcubera - poprawianie techniki................ 6 4.1.4 Organizowanie zawodów internetowych.................. 6 4.1.5 Uczestniczenie w zawodach internetowych................ 6 4.1.6 Kibicowanie w zawodach internetowych.................. 7 4.1.7 Organizowanie zawodów stacjonarnych.................. 7 4.1.8 Układanie kostki wirtualnej........................ 7 4.2 Realizacja przypadków użycia........................... 8 4.2.1 Trening początkującego speedcubera................... 8 4.2.2 Trening speedcubera - trening podstawowy................ 9 4.2.3 Trening speedcubera - poprawianie techniki................ 10 4.2.4 Organizowanie i uczestniczenie w zawodach internetowych....... 11 4.2.5 Kibicowanie w zawodach internetowych.................. 12 4.2.6 Układanie kostki wirtualnej........................ 13 5 Dekompozycja logiczna systemu 14 5.1 Najważniejsze komponenty............................. 14 6 Dekompozycja na procesy 14 7 Instalacja systemu 15 7.1 Aplikacja serwerowa................................ 16 7.1.1 Instalacja uproszczona........................... 16 7.1.2 Instalacja podstawowa........................... 16 7.2 Aplikacja kliencka................................. 16 7.3 Dostęp zdalny.................................... 16 2
8 Implementacja systemu 17 8.1 Omówienie..................................... 17 8.1.1 Interfejs................................... 17 8.1.2 Aplikacja.................................. 17 8.1.3 Dziedzina.................................. 17 8.1.4 Infrastruktura biznesowa.......................... 17 8.1.5 Usługi techniczne.............................. 18 8.2 Warstwy- lista.................................... 18 8.2.1 Interfejs................................... 18 8.2.2 Aplikacja.................................. 18 8.2.3 Dziedzina.................................. 18 8.2.4 Infrastruktura biznesowa.......................... 19 8.2.5 Usługi techniczne.............................. 19 9 Przechowywane dane 21 10 Wydajność systemu 22 10.1 Wydajność systemu w trybie treningu....................... 22 10.2 Wydajność systemu zawodów........................... 22 11 Jakość 23 11.1 Przenośność..................................... 23 11.2 Rozszerzalność................................... 23 11.3 Niezawodność.................................... 23 11.4 Bezpieczeństwo................................... 23 11.5 Łatwość obsługi................................... 23 12 Historia zmian 24 3
1 Wprowadzenie 1.1 Cel Dokument ten prezentuje zagadnienia związane z funkcjonowaniem i architekturą systemu Rubik s Manager. Równocześnie przeprowadzona jest wstępna analiza wymagań technicznych. W dokumencie omówione są także najistotniejsze elementy systemu. 1.2 Zakres Dokument ten obejmuje: przegląd przypadków użycia, założenia architektoniczne, przegląd warstw systemu, wymagania jakościowe. 1.3 Definicje RM - skrót od nazwy produktu, tj. Rubik?s Manager, kostka Rubika - łamigłówka logiczna w postaci sześcianu o ruchomych ścianach; także potoczna nazwa na pochodne tej łamigłówki, speedcubing - sport polegający na układaniu kostki Rubika na czas, World Cubing Association - organizacja ustalająca regulamin organizowania zawodów w speedcubingu. 1.4 Załaczniki Wizja systemu. Szczegółowy opis przypadków użycia. Diagram dziedziny. 4
2 Prezentacja architektury systemu System uruchamia się jako samodzielna aplikacja nie wymagająca połączenia z centalnym serwerem systemu. Niektóre z przypadków użycia wymagają nawiązania połączenia za pośrednictwem Internetu - aplikacja działa wówczas w trybie klient-serwer. Serwer odpowiedzialny jest za odbieranie danych od klientów w celu (jedno z następujących): zachowania ich w centralnej bazie danych, udostępnienia ich do odbioru innym klientom, przesłania ich wskazanemu klientowi. 3 Założenia i zależności Podstawowym założeniem jest zgodność z regulaminem publikowanym przez WCA. Po pojawieniu się nowej wersji regulaminu, powinna pojawiać się możliwie szybko aktualizacja systemu prowadząca do zgodności ze zmianami. Ponadto system powinien wspierać wykorzystywane w speedcubingu urządzenia. Dla każdego nowo pojawiającego się urządzenia wydawany będzie moduł umożliwiający komunikację z nim i transferowanie danych. 5
4 Przeglad przypadków użycia 4.1 Skrócony opis przypadków użycia 4.1.1 Trening poczatkuj acego speedcubera Użytkownik nie potrafiący układać kostki rubika zapoznaje się z podstawami teoretycznymi i używaną w speedcubingu notacją. Następnie system oferuje mu do wyboru listę technik sugerując wybór tej o przypuszczalnym najkrótszym czasie przyswajania. Użytkownik poznaje wszystkie fazy wybranej techniki równocześnie przeprowadzając pierwszą próbę ułożenia kostki rubika. W dowolnym momencie użytkownik może przejść do bazy wiedzy i poszukać odpowiedzi na nurtujące pytanie. 4.1.2 Trening speedcubera - trening podstawowy Użytkownik dokonuje pomiaru czasów kolejnych ułożeń. Za każdym razem miesza kostkę przy użyciu algorytmu wygenerowanego przez system. W dowolnym momencie przegląda uzyskane wyniki i prosi system o wygenerowanie statystyk oraz wykonanie analizy elementów, które należy poprawić. 4.1.3 Trening speedcubera - poprawianie techniki Użytkownik sugerjąc się przeprowadzoną przez system analizą lub właną opinią wybiera fazę, którą chciałby poprawić. System generuje algorytmy mieszające, które pozwalają przećwiczenie możliwie wielu przypadków danej fazy. W dowolnym momencie użytkownik prosi system o wygenerowanie nowego, lepiej dopasowanego rozwiązania dla danego przypadku. 4.1.4 Organizowanie zawodów internetowych Użytkownik ustala parametry organizowanych zawodów - termin, limit zawodników, filtr obowiązujący zawodników, liczbę i rodzaj przeprowadzanych rund, metody kwalifikacji. System rozpoczyna przyjmowanie zgłoszeń od zawodników. W czasie trwania zawodów organizator zawodów pozwala sterować całym procesem systemowi, lub sam podejmuje decyzje takie jak np. odrzucanie niektórych z odebranych czasów. 4.1.5 Uczestniczenie w zawodach internetowych Użytkownik prosi system o wyświetlenie listy aktywnych rejestracji na zawody, w których ma prawo wziąć udział. Zgłasza chęć uczestnictwa w wybranych. W czasie trwania zawodów system odbiera z serwera algorytm mieszający. Po wykonaniu ułożenia system wysyła uzyskany wynik do serwera i odbiera wyniki pozostałych zawodników. Czynność jest powtarzana, jeżeli uczestnik zakwalifikował się do kolejnej rundy. W przeciwnym razie użytkownik może zakończyć uczestniczenie w zawodach, lub kontynuować jako kibic. 6
4.1.6 Kibicowanie w zawodach internetowych Użytkownik prosi system o wyświetlenie listy odbywających się zawodów spełniających wskazane kryteria, np.: tylko zawody, w których biorą udział speedcuberzy z Kanady, tylko zawody, w których bierze udział więcej niż 20 speedcuberów, itp. Po wybraniu jednej pozycji z listy użytkownik łączy się z serwerem i system daje mu możliwość: przeglądania i analizowania wyników, odbierania transmisji od wybranego uczestnika zawodów, komentowania zawodów. W dowolnym momencie użytkownik może przerwać kibicowanie. Równocześnie może poprosić system o przesłanie do siebie wyników po zakończeniu zawodów. 4.1.7 Organizowanie zawodów stacjonarnych Użytkownik ustala parametry organizowanych zawodów. Po określeniu nowej rundy i wybraniu jej jako aktualnie odbywającej się, system generuje sekwencje mieszające, po czym oczekuje na pobranie czasów z urządzeń pomiarowych; w przypadku ich braku system prosi o ręczne wpisanie czasów. Użytkownik wydaje systemowi polecenia podsumowania rundy i rozpoczęcia nowej. Po zakończeniu zawodów system generuje i pozwala wydrukować raport z zawodów. 4.1.8 Układanie kostki wirtualnej Użytkownik wybiera rodzaj kostki spośród listy dostępnych. System wyświetla model wybranej trój- lub czterowymiarowej kostki sterowany przy użyciu myszki. Użytkownik prosi system o pomieszanie kostki, następnie decyduje, czy system ma włączyć pomiar czasu i rozpoczyna układanie. Po ułożeniu system zapamiętuje ewentualny czas. 7
4.2 Realizacja przypadków użycia 4.2.1 Trening poczatkuj acego speedcubera 8
4.2.2 Trening speedcubera - trening podstawowy 9
4.2.3 Trening speedcubera - poprawianie techniki 10
4.2.4 Organizowanie i uczestniczenie w zawodach internetowych 11
4.2.5 Kibicowanie w zawodach internetowych 12
4.2.6 Układanie kostki wirtualnej 13
5 Dekompozycja logiczna systemu Gdy system pracuje w trybie klient-serwer, pracą systemu kieruje główny serwer (zwany dalej aplikacją serwerową). Połączony jest z zewnętrznym serwerem WWW i bazą danych. Dostęp do serwera możliwy będzie poprzez: przeglądarka WWW (np. IE, Firefox...), aplikacja kliencka (część systemu RM). 5.1 Najważniejsze komponenty W skład systemu RM wchodzą następujące autonomiczne komponenty: sterowniki urządzeń pomiarowych, aplikacja kliencka, aplikacja serwerowa. Wymienione komponenty będą dostępne oddzielnie. W skład nich wchodzą mniejsze komponenty wyodrębnione podczas implementacji systemu. 6 Dekompozycja na procesy W systemie pracują następujące główne procesy. baza danych, serwer WWW, aplikacja serwerowa, aplikacja kliencka, przeglądarka WWW, stackmata. Komponenty wymienione w punkcie implementacja systemu będą także niezależnymi procesami, umożliwi to lepsze wykorzystanie wieloprocesorowych architektur komputerowych. 14
7 Instalacja systemu 15
Instalacja systemu RM nie wymaga udziału osób specjalnie przeszkolonych do tego celu. Nie mniej jednak dostępna będzie pomoc techniczna w razie problemów z instalacją. System dzieli się zasadniczo na trzy części, których instalacja znacząco się różni: 7.1 Aplikacja serwerowa Część systemu uruchomiona na serwerze z dostępem do internetu, o minimalnych parametrach: CPU 1GHz, 512MB RAM, 20GB HDD, Internet 1Mbps. W skład której wchodzą: zewnętrzna baza danych (ProgreSQL), zewnętrzny serwer WWW z PHP, aplikacja RM. System RM zawiera instalator aplikacji serwerowej. Wymaga on obecnej bazy danych i serwera WWW z PHP na serwerze. Serwer musi ponadto być zgodny z J2EE. Istnieje możliwość instalacji rozproszonej, tzn. istnieje kilka zsynchronizowanych serwerów, poprawia to bezpieczeństwo danych i dostępność serwisu podczas awarii jednego z serwerów. Instalator posiada dwa tryby instalacji: 7.1.1 Instalacja uproszczona Dostępnych jest kilka standardowych instalacji. Instalator dokona instalacji automatycznie według wybranego schematu. Opcja przeznaczona jedynie dla osób tworzących małe lokalne systemy RM. 7.1.2 Instalacja podstawowa Umożliwia dokładne skonfigurowanie systemu. Wymaga dobrej znajomości systemu. W razie wątpliwości dostępne są parametry domyślne i opis ich działania. 7.2 Aplikacja kliencka Część systemu uruchamiana na komputerze speedcubera. Posiada intuicyjny program instalujący. Instalator zawiera gotowe podstawowe konfiguracje systemu. Użytkownik wybiera tylko moduły do zainstalowania i wskazuje folder docelowy, gdzie ma zostać zainstalowany system. Następnie cały proces instalacyjny przebiega automatycznie. System jest gotowy do uruchomienia. 7.3 Dostęp zdalny Dowolny użytkownik internetu może skorzystać z systemu RM zdalnie. Wystarczy, że połaczy się z serwerem RM za pomocą dowolnej przeglądarki internetowej. W tym przypadku nie jest wymagana instalacja systemu na komputerze użytkownika. 16
8 Implementacja systemu System podzielony jest na 5 warstw. Trzy pierwsze warstwy (czyli interface,aplikacja,dziedzina) to typowy układ view, model, peresenter. Warstwa czwarta to konkretne moduły do rozwiązywania poszczególnych problemów. Warstwa najniższa to usługi transmisji danych,bezpieczeństwa i obsługi urządzeń peryferyjnych. 8.1 Omówienie 8.1.1 Interfejs Warstwa interfejsu służy do komunikacji z użytkownikiem. Wyświetla komunikaty dla użytkownika i przyjmuje od niego dane. W warstwie występuje kilka interfejsów, każdy zaprojektowany do potrzeb innego typu użytkownika programu RM. Warstwa interfejs korzysta tylko i wyłącznie z warstwy aplikacja. Interfejs widza jest wykonany w technologii Adobe Flex 2. Interfejs organizatora jest wykonany w technologii Java Server Pages. Interfejs treningowy jest aplikacja napisaną w języku C++. 8.1.2 Aplikacja Warstwa aplikacji jest podzielona na 3 komponenty, każdy dla innego zadania systemu. Jest to logika, która przetwarza dane na wysokim poziomie abstrakcji (wykorzystując komponenty z dziedziny) i za pomocą warstwy interfejsu przesyła je do użytkownika. 8.1.3 Dziedzina Warstwa dziedziny zawiera obiekty z diagramu dziedziny dla programu RM. Obiekty te opierają swoje funkcjonalności o modułu z działu infrastruktury biznesowej. Relacje między nimi są umieszczone w warstwie aplikacji. 8.1.4 Infrastruktura biznesowa Warstwa składa się z 8 modułów, z których każdy udostępnia jakąś funkcjonalność wykorzystywaną przez warstwę dziedziny (np. moduł Algorytmy mieszające jest wykorzystywany w Rundzie zawodów i nauce technik, a moduł statystyk w liście rankingowej). Moduły do transmisji danych i pomiaru czasu korzystają z warstwy Usługi techniczne. Algorytmy mieszające i rozwiązujące napisane w języku Lisp. Moduł kostek wirutalnych oparty o Open GL. 17
Moduł Statystyki korzysta z interfejsu Java DataBase Connectivity do komunikowania się z bazą danych PostgreSQL. Moduł wymiany danych jest oparty o interfejsy Java Message Service. 8.1.5 Usługi techniczne Zestaw niskopoziomowych modułów do urządzeń peryferyjnych i sieci. Interfejs Java Authentication and Authorization Service Interfejs obsługi urządzeń pomiarowych stworzony w asemblerze. Obsługa transmisji wideo z wykorzystaniem narzędzia Sopcast. 8.2 Warstwy- lista 8.2.1 Interfejs 1. Interfejs użytkownika. 2. Interfejs organizatora. 3. Interfejs kibica. 4. Interfejs treningowy. 8.2.2 Aplikacja 1. Zawody. 2. Kibicowanie. 3. Trening. 8.2.3 Dziedzina 1. Lista rankingowa. 2. Tworzenie zawodów. 3. Runda zawodów. 4. Nauka technik. 18
8.2.4 Infrastruktura biznesowa 1. Algorytmy rozwiązujące. 2. Algorytmy mieszające. 3. Selekcja zwycięzców. 4. Statystyki. 5. Przeszukiwanie wyników. 6. Wymiana danych. 7. Kostki wirtualne. 8. Pomiar czasu. 8.2.5 Usługi techniczne 1. Transmisja video 2. Obsługa stackmaty 3. Transmisja danych/wyników 19
20
9 Przechowywane dane 21
10 Wydajność systemu 10.1 Wydajność systemu w trybie treningu Generowanie sekwencji mieszające w czasie poniżej 1 sek. Rozwiązywanie tradycyjnej kostki w czasie do 4 sek. Rozwiązywanie dowolnej kostki w czasie do 30 sek. Dostęp do centralnej bazy danych poniżej 3 sek. 10.2 Wydajność systemu zawodów Dostęp do centralnej bazy danych poniżej 3 sek. Nawiązywanie połączenia między sędzią a graczami poniżej 5*log(liczba graczy+3) sek. Możliwość jednoczesnej transmisji video od/do 3000 graczy/kibiców. 22
11 Jakość 11.1 Przenośność Aplikację kliencką można zainstalować na dowolnym komputerze klasy PC z systemem operacyjnym 1. MS Windows XP 2. MS Windows Vista 3. Ubuntu 6.06 4. Debian 3.1 5. Knoppix 4.0 Aplikacja serwerowa w pełni kompatybilna z J2EE. Możliwość umieszczenia na dowolnym serwerze zgodnym z J2EE. 11.2 Rozszerzalność Funkcjonalności programu umieszczone są w modułach, tak aby ich dodawanie wymagało minimalnego modyfikowania aplikacji. 11.3 Niezawodność Dopuszczalne są krótkie przerwy w działaniu systemu, nie częściej niż 3 razy w tygodniu. Wszystkie dane mają dwie kopie bezpieczeństwa na różnych dyskach. 11.4 Bezpieczeństwo Mechanizmy autoryzacji ograniczają możliwości modyfikacji danych przez nieupoważnione osoby: Java Authentication and Authorization Service. 11.5 Łatwość obsługi Interface użytkownika jest intuicyjny, dający możliwość personalizacji. Wszystkie bardziej zaawansowane i rzadziej używane funkcje są widoczne w trybie zaawansowanym. Domyślny jest tryb podstawowy, udostępniający podstawowe funkcje. Wszędzie umieszczona jest pomoc kontekstowa. 23
12 Historia zmian Data Osoba Opis zmian 16.05.2007 Łukasz Krupa Wprowadzono punkty 8-11. 16.05.2007 Łukasz Krupa Sprawdzono ortografię. 18.05.2007 Sebastian Chojniak Wprowadzono punkty 5-7. 19.05.2007 Grzegorz Łuczyna Wprowadzono punkty 1-3. 21.05.2007 Grzegorz Łuczyna Wprowadzono punkt 4. 22.05.2007 Sebastian Chojniak Przeredagowano punktów 5-7. 23.05.2007 Łukasz Krupa Drobne zmiany w punkcie 8. 23.05.2007 Sebastian Chojniak Dodano diagramu instalacji. 23.05.2007 Sebastian Chojniak Sprawdzono ortografii. 23.05.2007 Grzegorz Łuczyna Dodano diagramy do punktu 4. 23.05.2007 Sebastian Chojniak, Skład dokumentu. Łukasz Krupa, Grzegorz Łuczyna 24