Politechnika Gdańska WYDZIAŁ ELEKTRONIKI TELEKOMUNIKACJI I INFORMATYKI Katedra: Algorytmów i Modelowania Systemów Imię i nazwisko dyplomanta: Michał Piątek Nr albumu: 102145 Forma i poziom studiów: Dzienne, magisterskie Kierunek studiów: Informatyka Praca dyplomowa magisterska Temat pracy: System kontroli jakości treści w platformach do wspólnej edycji zasobów Kierujący pracą: dr inż. Adrian Kosowski Zakres pracy: Gdańsk, 2009
Spis treści 1. Wprowadzenie 7 1.1. Cel pracy................................... 7 1.2. Definicje pojęć związanych z systemem................... 7 1.2.1. Serwis społecznościowy........................ 7 1.2.2. Wejście................................ 7 1.2.3. Wyjście................................ 7 1.3. Przegląd istniejących rozwiązań: serwisy typu online judge........ 7 1.3.1. Sphere Online Judge (SPOJ)..................... 7 1.3.2. UVa Online-Judge.......................... 8 1.3.3. Timus Online Judge......................... 8 1.3.4. Saratov State University Online Contester............. 8 1.3.5. Fujian Normal University Online Judge (Fjnu Online Judge)... 8 1.3.6. Tianjin University (Peiyang University) Online Judge (TJU Online Judge).............................. 8 1.3.7. Hangzhou Dianzi University Online Judge System (HDU Online Judge System)............................ 9 1.3.8. Zheijang University Online Judge (ZOJ).............. 9 1.3.9. JudgeOnline.............................. 9 1.4. Społecznościowy portal do budowania kolekcji danych testowych dla zagadnień algorytmicznych........................... 9 2. 10 2.1. Definicje pojęć w systemie.......................... 10 2.2. Opis ogólny funkcjonalności systemu.................... 11 2.3. Przypadki użycia............................... 11 2.4. Opis przypadków użycia........................... 14 2.4.1. Rejestracja użytkownika....................... 14 2.4.2. Logowanie............................... 14 2.4.3. Wylogowanie............................. 17 2.4.4. Przeglądanie zadań.......................... 19 2.4.5. Dodanie oceny............................ 19 2.4.6. Przeglądanie ocen........................... 21 2.4.7. Przeglądanie wejść.......................... 24 2
Spis treści Spis treści 2.4.8. Dodanie wejścia............................ 24 2.4.9. Testowanie rozwiązania w systemie................. 26 2.4.10. Edycja zadań............................. 29 2.4.11. Dodanie zadań............................ 31 2.4.12. Edycja użytkowników......................... 33 2.5. Organizacja bazy danych........................... 33 2.5.1. Schemat relacyjnej bazy danych................... 33 2.5.2. Opis tabel............................... 36 2.6. Struktura klas w systemie.......................... 38 2.6.1. Package: Beans............................ 38 2.6.2. Package: Entity Beans........................ 38 2.6.3. Package: Utils............................. 38 2.6.4. Package: Servlets........................... 39 3. Realizacja aplikacji w modelu MVC 44 3.1. Definicja modelu MVC............................ 44 3.2. Model..................................... 46 3.3. View...................................... 46 3.4. Controller................................... 46 3.5. Maszyna wirtualna Javy oraz Class Loadery................ 46 3.6. Custom Class Loader maszyny wirtualnej Java............... 46 3.7. Implementacja Custom Class Loadera w systemie............. 46 4. Budowa systemu 47 4.1. System jako aplikacja JEE.......................... 47 4.2. Struktura systemu.............................. 47 5. Przykładowe zastosowania systemu przy rozwiązywaniu problemów algorytmicznych 48 5.1. Kolorowanie wierzchołkowe.......................... 48 5.2. Znajdowanie najkrótszej ścieżki....................... 48 6. Podsumowanie i wnioski 49 A. Podręcznik użytkownika 50 B. Opis wdrożenia 51 B.1. Apache Tomcat................................ 51 B.2. MySQL.................................... 51 3
Spis treści Spis treści C. Wykorzystane technologie oraz frameworki 52 C.1. JSP...................................... 52 C.2. JSTL...................................... 52 C.3. CSS...................................... 52 C.4. JavaScript................................... 52 C.5. Servlety.................................... 52 C.6. MySQL.................................... 55 C.7. JDBC..................................... 55 C.8. POJO Entity Bean.............................. 55 C.9. JPA...................................... 57 C.10.Hibernate................................... 57 C.11.Java refrections................................ 57 C.12.Ajax...................................... 57 C.13.JsMath..................................... 60 4
Spis rysunków 2.1. Interfejs IInputValidator........................... 11 2.2. Interfejs IJudge................................ 12 2.3. Diagram przypadków użycia użytkownika niezalogowanego........ 12 2.4. Diagram przypadków użycia użytkownika zalogowanego.......... 13 2.5. Diagram aktywności rejestracji........................ 15 2.6. Diagram maszyny stanów rejestracji..................... 16 2.7. Diagram aktywności logowania........................ 17 2.8. Diagram maszyny stanów logowania..................... 18 2.9. Diagram aktywności logowania........................ 18 2.10. Diagram maszyny stanów logowania..................... 18 2.11. Diagram aktywności przeglądania zadań.................. 19 2.12. Diagram maszyny stanów przeglądania zadań............... 20 2.13. Diagram aktywności dodania oceny..................... 21 2.14. Diagram maszyny stanów dodania oceny.................. 22 2.15. Diagram aktywności przeglądania ocen................... 23 2.16. Diagram maszyny stanów przeglądania ocen................ 23 2.17. Diagram aktywności przeglądania wejść................... 25 2.18. Diagram maszyny stanów przeglądania wejść................ 25 2.19. Diagram aktywności dodania wejsćia.................... 26 2.20. Diagram maszyny stanów dodawania wejścia................ 27 2.21. Diagram aktywności testowania rozwiązań................. 28 2.22. Diagram maszyny stanów testowania rozwiązań.............. 28 2.23. Diagram aktywności edycji zadań...................... 30 2.24. Diagram maszyny stanów edycji zadań................... 30 2.25. Diagram aktywności dodawania zadań................... 32 2.26. Diagram maszyny stanów dodawania zadań................ 32 2.27. Diagram aktywności edycji użytkowników.................. 34 2.28. Diagram maszyny stanów edycji użytkowników............... 34 2.29. Schemat relacyjnej bazy danych, część 1.................. 35 2.30. Schemat relacyjnej bazy danych, część 2.................. 35 2.31. Opis pól tabeli Uzytkownik......................... 36 2.32. Opis pól tabeli RolaUzytkownika...................... 36 2.33. Opis pól tabeli Przywilej........................... 36 5
Spis rysunków Spis rysunków 2.34. Opis pól tabeli PrzywilejPoleWMenu.................... 37 2.35. Opis pól tabeli PoleWMenu......................... 37 2.36. Opis pól tabeli Zadanie............................ 37 2.37. Opis pól tabeli InputDoZadania....................... 37 2.38. Opis pól tabeli Ocena............................. 38 2.39. Opis pól tabeli RozwiazanieUzytkownika.................. 38 2.40. Zależności pomiędy pakietami klas w systemie............... 39 2.41. Pakiet zawierający klasę SessionBean.................... 40 2.42. Pakiet zawierający klasy mapujące na encje bazy danych......... 41 2.43. Pakiet zawierający klasy narzędziowe.................... 42 2.44. Pakiet zawierający servlety.......................... 43 3.1. Schemat zależności w modelu MVC..................... 45 C.1. Plik styles.css................................. 53 C.2. Plik js.js.................................... 54 C.3. Plik web.xml................................. 56 C.4. Plik persistence.xml.............................. 58 C.5. Klasa Polewmenu............................... 59 C.6. Interfejs XMLHttpRequest.......................... 61 6
Rozdział 1 Wprowadzenie 1.1. Cel pracy 1.2. Definicje pojęć związanych z systemem 1.2.1. Serwis społecznościowy Serwis społecznościowy - (inaczej: portal społecznościowy) - rodzaj interaktywnych stron WWW, które są współtworzone przez sieci społeczne osób podzielających wspólne zainteresowania lub chcących poznać zainteresowania innych.[18]. 1.2.2. Wejście Wejście - zdefiniowany w systemie plik tekstowy zawierający dane testowe dla konkretnego zadania. 1.2.3. Wyjście Wyjscie - plik tekstowy zawierający rozwiązanie zadania dla konkretnego wejścia. Plik ten jest wysyłany przez użytkownika systemu za pośrednictwem formularza WWW. 1.3. Przegląd istniejących rozwiązań: serwisy typu online judge 1.3.1. Sphere Online Judge (SPOJ) Serwis SPOJ jest dostępny pod adresem url: http://www.spoj.pl/. Ten portal przyjmuje rozwiązania w trzydziestu pięciu językach programowania (C++, C, Pascal (fpc 2.0.4), Text, Java, Python, C99 strict, Ruby, Perl, Brainf**k, Pascal (gpc v20030830), Haskell, C#, Ocaml, PHP, ADA 95, Common Lisp (clisp 2.33.2), Common Lisp (sbcl 1.0.4.0), D, Bash, Scheme (guile 1.6), Assemble, Lua, JAR, Fortran, Icon, Whitespace, Prolog, Pike, Nice, Intercal, Nemerle, Clips, Smalltalk, Scheme (qobi 0.9+0.10a)). Zawiera zawody typu open oraz zawody typu closed. 7
1.3.Przegląd istniejących rozwiązań: serwisy typu online judge Wprowadzenie 1.3.2. UVa Online-Judge Serwis UVa Online-Judge jest dostępny pod adresem url: http://uva.onlinejudge. org/. Ten portal przyjmuje rozwiązania w czterech językach programowania (C, C++, Delphi, Java). Zawiera zawody typu open z setami zadań zawierającymi maksymalnie 100 zadań (w sumie 2523 zadania) oraz zawody zawierające po kilka zadań organizowane co jakiś czas. 1.3.3. Timus Online Judge Serwis http://acm.timus.ru/ jest dostępny pod adresem url: http://acm.timus.ru/. Ten portal przyjmuje rozwiązania w pięciu językach programowania (C, C++, Delphi, Java, C#). Zawiera zawody typu open z setami zadań zawierającymi maksymalnie 100 zadań (w sumie 711 zadań) oraz zawody zawierające po kilka zadań organizowane co jakiś czas. 1.3.4. Saratov State University Online Contester Serwis Saratov State University Online Contester jest dostępny pod adresem url: http: //acm.sgu.ru/. Ten portal przyjmuje rozwiązania w czterech językach programowania (C, C++, Delphi, Java). Zawiera zawody typu open z setami zadań zawierającymi maksymalnie 100 zadań (w sumie 343 zadania) oraz zawody zawierające po kilka zadań organizowane co jakiś czas. Oprócz brania udziału w zawodach istnieje możliwość tworzenia własnych zawodów, 1.3.5. Fujian Normal University Online Judge (Fjnu Online Judge) Serwis Fjnu Online Judge jest dostępny pod adresem url: http://acm.fjnu.edu.cn/. Ten portal przyjmuje rozwiązania w czterech językach programowania (C, C++, Pascal, Java). Zawiera zawody typu open z setami zadań zawierającymi maksymalnie 100 zadań (w sumie 1060 zadań) oraz zawody zawierające po kilka zadań organizowane co jakiś czas. 1.3.6. Tianjin University (Peiyang University) Online Judge (TJU Online Judge) Serwis TJU Online Judgejest dostępny pod adresem url: http://acm.tju.edu.cn/toj/. Ten portal przyjmuje rozwiązania w czterech językach programowania (C, C++, Pascal, Java). Zawiera zawody typu open z setami zadań zawierającymi maksymalnie 100 zadań (w sumie 2292 zadania) oraz zawody zawierające po kilka zadań organizowane co jakiś czas. Oprócz brania udziału w zawodach istnieje możliwość tworzenia własnych zawodów, posiadających od 3 do 14 zadań, nazwę, hasło, tytuł, opis oraz określony czas trwania. 8
1.4.Społecznościowy portal do budowania kolekcji danych testowych dla zagadnień algorytmicznych Wprowadzenie 1.3.7. Hangzhou Dianzi University Online Judge System (HDU Online Judge System) Serwis HDU Online Judge System jest dostępny pod adresem url: http://acm.hdu.edu. cn/. en portal przyjmuje rozwiązania w czterech językach programowania (C, C++, Pascal, Java). Zawiera zawody typu open z setami zadań zawierającymi maksymalnie 100 zadań (w sumie 1786 zadań) oraz zawody zawierające po kilka zadań organizowane co jakiś czas. Zawody mogą mieć cztery modyfikatory dostępu (Public, Private, Registered Site, Rigister Network). Oprócz brania udziału w zawodach istnieje możliwość tworzenia własnych zawodów, w których możemy dodawać notatki, zadania (z listy predefiniowanych zadań lub, jeśli jesteśmy użytkownekiem z uprawnieniem Diy super user, dodać własne zadanie) oraz definiować czas trwania. 1.3.8. Zheijang University Online Judge (ZOJ) Serwis ZOJ jest dostępny pod adresem url: http://acm.zju.edu.cn/onlinejudge/. Ten portal przyjmuje rozwiązania w czterech językach programowania (C, C++, Pascal, Java). Zawiera zawody typu open z setami zadań zawierającymi maksymalnie 100 zadań (w sumie 3212 zadań) oraz zawody zawierające po kilka zadań organizowane co jakiś czas. 1.3.9. JudgeOnline Serwis JudgeOnline jest dostępny pod adresem url: http://judge.ybdevelop.cn/judgeonline/. Ten portal przyjmuje rozwiązania w trzech językach programowania (C, C++, Pascal). Zawiera zawody typu open z setami zadań zawierającymi maksymalnie 100 zadań (w sumie 124 zadania) oraz zawody zawierające po kilka zadań organizowane co jakiś czas. 1.4. Społecznościowy portal do budowania kolekcji danych testowych dla zagadnień algorytmicznych 9
Rozdział 2 2.1. Definicje pojęć w systemie W tej sekcji zostanie przedstawionych kilka istotnych, z punktu widzenia użytkownika systemu, definicji. Użytkownik - zarejestrowana w systemie, identyfikowana przez login i hasło osoba, posiadająca uprawnienia do przeglądania i wyboru konkretnego zadania, przeglądania, oceniania i wyboru konkretnego wejścia do zadania oraz nadsyłania rozwiązań. Problem Setter - użytkownik, który oprócz uprawnień standardowych posiada możliwość dodawania zadań oraz ich modyfikacji (zmiana nazwy zadania, treści, sędziego wejść oraz sędziego wyjść). Administrator - użytkownik posiadający uprawnienia problem settera oraz mogący nadawać uprawnienia użytkownikom (ustalenie, czy dany użytkownik ma uprawnienia problem settera czy też nie). Zadanie - zagadnienie algorytmiczne, które można rozwiązać poprzez napisanie stosownego programu, który na wejście przyjmie określone dane ze standardowego wejścia (STDIN) i wypisze stosowne dane na standardowe wyjście (STDOUT). Wejście - tekstowa reprezentacja danych wsadowych dla zadań. Rozwiązanie - tekstowa reprezentacja rozwiązania zadania dla konkretnego wejścia. Sędzia wejść - klasa napisana w Javie, odpowiadająca za walidację poprawności wejścia (automatyczny proces weryfikacji poprawności danych wejściowych, zgodnych z wzorcem podanym w opisie zadania), implementująca interfejs IInputValidator: 2.1 Sędzia rozwiązań - klasa napisana w Javie, odpowiadająca za sprawdzanie poprawności i/lub jakości rozwiązań do zadań związanych z konkretnym wejściem, implementująca interfejs IJudge 2.2. Odpowiedzi tej klasy powinny być zawarte w określonym poniżej standardzie: OK - rozwiązanie poprawne NOT OK -rozwiązanie niepoprawne 10
2.2.Opis ogólny funkcjonalności systemu package u t i l s ; / @author Michał Piątek / public interface I I n p u t V a l i d a t o r { / Sprawdza poprawność inputu @param input i n p u t v a l i d a t o r input data @return c o r r e c t n e s s / boolean v a l i d a t e ( S t r i n g [ ] input ) ; } Rysunek 2.1. Interfejs IInputValidator WynikUżytkownika < Maksimum - rozwiązanie użytkownika w relacji maksimum. Jeśli użytkownik zmieścił się w określonym przedziale rozwiązanie jest poprawne, w przeciwnym razie niepoprawne. WynikUżytkownika > Minimum - rozwiązanie użytkownika w relacji minimum. Jeśli użytkownik zmieścił się w określonym przedziale rozwiązanie jest poprawne, w przeciwnym razie niepoprawne. 2.2. Opis ogólny funkcjonalności systemu System jest społecznościowym serwisem internetowym 1.2.1 pozwalającym zalogowanym w nim użytkownikom dodawanie wejść do problemów algorytmicznych oraz ich ocenę, sprawdzanie własnych rozwiązań poprzez zastosowanie par wejście 1.2.2 - wyjście 1.2.3 przy pomocy sędziego, który ocenia poprawność rozwiązania i/lub jego jakość. Użytkownik mający uprawnienia problem settera może dodatkowo dodawać i modyfikować zadania. Administrator posiada dodatkowo możliwość edycji uprawnień. 2.3. Przypadki użycia Przypadki użycia dostępne w systemie zostały przedstawione na dwóch rysunkach 2.3 oraz 2.4 11
2.3.Przypadki użycia package u t i l s ; / @author Michał Piątek / public interface IJudge { / Sprawdza output do danego inputu @param input judge input data @param output judge output data @return score / S t r i n g judge ( S t r i n g [ ] input, S t r i n g [ ] output ) ; } Rysunek 2.2. Interfejs IJudge Rysunek 2.3. Diagram przypadków użycia użytkownika niezalogowanego 12
2.3.Przypadki użycia Rysunek 2.4. Diagram przypadków użycia użytkownika zalogowanego 13
2.4.Opis przypadków użycia 2.4. Opis przypadków użycia 2.4.1. Rejestracja użytkownika Diagram aktywności został przedstawiony na rysunku 2.5, natomiast maszyna stanów na rysunku 2.6. Opis: Niezalogowany i nie zarejestrowany wcześniej użytkownik wprowadza swoje dane i zostaje zarejestrowany w systemie. Aktorzy: Niezalogowany użytkownik Warunki początkowe: Użytkownik musi być niezalogowany. Scenariusz przypadku użycia: 1 Użytkownik wprowadza swoje dane (login i hasło) oraz wpisuje kod weryfikujący. 2 Użytkownik naciska przycisk rejestruj. 3 Servlet zapisuje informacje o użytkowniku w bazie. 4 Użytkownik zostaje przekierowany do strony rejestracji ze stosownym komunikatem. Alternatywne scenariusze: Wynik: Użytkownik podał login występujący w systemie, zostaje poinformowany o zaistniałym fakcie. Użytkownik wprowadził błędne dane, zostaje poproszony o ich poprawienie. Użytkownik zostaje zarejestrowany w systemie. 2.4.2. Logowanie Diagram aktywności został przedstawiony na rysunku 2.7, natomiast maszyna stanów na rysunku 2.8. Opis: Niezalogowany użytkownik po podaniu poprawnego loginu i hasła zostaje zalogowany w systemie. 14
2.4.Opis przypadków użycia Rysunek 2.5. Diagram aktywności rejestracji Aktorzy: Niezalogowany użytkownik Warunki początkowe: Użytkownik musi być niezalogowany. Scenariusz przypadku użycia: 1 Niezalogowany użytkownik klika w link zaloguj. 2 Użytkownik wprowadza login i hasło. 3 Użytkownik klika przycisk zaloguj. 4 Servlet zapisuje dane o użytkowniku w sesji. 5 Użytkownik zostaje przekierowany an stronę główną, komunikat powitalny zostaje wyświetlony. Alternatywne scenariusze: Wynik: 1 Użytkownik nie podał wszystkich pól, zostaje poproszone o uzupełnienie danych. 2 Użytkownik podał dane niepoprawne, zostaje poproszony o poprawienie danych. 15
2.4.Opis przypadków użycia Rysunek 2.6. Diagram maszyny stanów rejestracji 16
2.4.Opis przypadków użycia Rysunek 2.7. Diagram aktywności logowania Użytkownik zostaje zalogowany i może kontynuować użytkowanie serwisu. 2.4.3. Wylogowanie Diagram aktywności został przedstawiony na rysunku 2.9, natomiast maszyna stanów na rysunku 2.10. Opis: Zalogowany użytkownik naciska przycisk wyloguj i zostaje wylogowany z systemu. Aktorzy: Zalogowany użytkownik Warunki początkowe: Użytkownik musi być zalogowany. Scenariusz przypadku użycia: Wynik: 1 Użytkownik naciska przycisk wyloguj. 2 Servlet usuwa informacje o użytkowniku z sesji. 3 Użytkownik zostaje przekierowany do strony głównej portalu, komunikat o wylogowaniu z systemu zostaje wyświetlony. Użytkownik zostaje wylogowany z systemu. 17
2.4.Opis przypadków użycia Rysunek 2.8. Diagram maszyny stanów logowania Rysunek 2.9. Diagram aktywności logowania Rysunek 2.10. Diagram maszyny stanów logowania 18
2.4.Opis przypadków użycia Rysunek 2.11. Diagram aktywności przeglądania zadań 2.4.4. Przeglądanie zadań Diagram aktywności został przedstawiony na rysunku 2.11, natomiast maszyna stanów na rysunku 2.12. Opis: Zalogowany użytkownik przegląda zadania zawarte w systemie. Aktorzy: Zalogowany użytkownik Warunki początkowe: Użytkownik musi być zalogowany. Scenariusz przypadku użycia: Wynik: 1 Użytkownik naciska przycisk zadania i zostaje przekierowany na stronę zadań. 2 W przypadku istnienia więcej niż dziesięciu zadań w systemie użytkownik ma możliwość przeglądać kolejne strony zadań. 3 Użytkownik może wybrać konkretne, interesujące go zadanie. Po kliknięciu w link zadania jego treść oraz panel związany z wejściami (dodawanie wejść oraz przeglądanie wejść) zostają asynchronicznie dograne na stronę serwisu. Strona z listą zadań, ewentualnie dodatkowo nazwa oraz opis konkretnego, wybranego przez użytkownika zadania. 2.4.5. Dodanie oceny Diagram aktywności został przedstawiony na rysunku 2.13, natomiast maszyna stanów na rysunku 2.14. 19
2.4.Opis przypadków użycia Rysunek 2.12. Diagram maszyny stanów przeglądania zadań Opis: Zalogowany użytkownik oddaje ocenę na dane wejście. Zależności: 1 Przeglądanie zadań 2.4.4 2 Przeglądanie wejść 2.4.7 Aktorzy: Zalogowany użytkownik systemu Warunki początkowe: Użytkownik musi być zalogowany. Użytkownik musi przeglądać konkretne zadanie. Użytkownik nie oddał jeszcze głosu na to wejście. Scenariusz przypadku użycia: 1 Użytkownik wybiera w panelu wejść zakładkę dodaj rozwiązanie. 2 Użytkownik zaznacza ocenę dla danego wejścia. 3 Servlet zapisuje dane w bazie danych. 4 Użytkownikowi zostaje pokazana ocena średnia dla danego wejścia. 20
2.4.Opis przypadków użycia Rysunek 2.13. Diagram aktywności dodania oceny Wynik: Ocena użytkownika została zapisana w systemie. 2.4.6. Przeglądanie ocen Diagram aktywności został przedstawiony na rysunku 2.15, natomiast maszyna stanów na rysunku 2.16. Opis: Zalogowany użytkownik przegląda średnie z ocen dla wejść do zadań. Zależności: 1 Przeglądanie zadań 2.4.4 2 Przeglądanie wejść 2.4.7 Aktorzy: Zalogowany użytkownik systemu Warunki początkowe: Użytkownik musi być zalogowany. Użytkownik musi przeglądać konkretne zadanie. 21
2.4.Opis przypadków użycia Rysunek 2.14. Diagram maszyny stanów dodania oceny 22
2.4.Opis przypadków użycia Rysunek 2.15. Diagram aktywności przeglądania ocen Rysunek 2.16. Diagram maszyny stanów przeglądania ocen Użytkownik oddał głos na dane wejście, w przeciwnym razie informacje nie zostają wyświetlone. Scenariusz przypadku użycia: Wynik: 1 Użytkownik wybiera w panelu wejść zakładkę dodaj rozwiązanie. 2 Użytkownik przegląda oceny. Użytkownik zapoznał się ze średnimi ocenami wejść. 23
2.4.Opis przypadków użycia 2.4.7. Przeglądanie wejść Diagram aktywności został przedstawiony na rysunku 2.17, natomiast maszyna stanów na rysunku 2.18. Opis: Zalogowany użytkownik przegląda wejścia do wybranego przez siebie zadania. Zależności: Aktorzy: 1 Przeglądanie zadań 2.4.4 Zalogowany użytkownik Warunki początkowe: Użytkownik musi być zalogowany. Zadania muszą się znajdować w systemie. Użytkownik musi przeglądać wybrane przez siebie zadanie. Scenariusz przypadku użycia: Wynik: 1 Użytkownik wybiera z panelu wejść opcję dodaj rozwiązanie. 2 Użytkownik przegląda listę wejść dla danego zadania. 3 Użytkownik wybiera konkretne, interesujące go wejście. 4 Panel z zawartością wejścia oraz formularzem zgłoszeniowym rozwiązania zostaje dograny asynchronicznie na stronę serwisu. Lista wejść, ewentualnie dodatkowo konkretne wybrane przez użytkownika wejście. 2.4.8. Dodanie wejścia Diagram aktywności został przedstawiony na rysunku 2.19, natomiast maszyna stanów na rysunku 2.20. Opis: Zalogowany użytkownik dodaje wejście do wybranego przez siebie zadania. Zależności: 24
2.4.Opis przypadków użycia Rysunek 2.17. Diagram aktywności przeglądania wejść Rysunek 2.18. Diagram maszyny stanów przeglądania wejść Aktorzy: Przeglądanie zadań 2.4.4 Zalogowany użytkownik systemu. Warunki początkowe: Użytkownik musi być zalogowany. W systemie muszą istnieć zadania. Scenariusz przypadku użycia: 1 Użytkownik wybiera interesujące go zadanie. 2 Użytkownik wybiera zakładkę dodaj input w panelu zadania. 3 Użytkownik wprowadza treść wejścia i naciska przycisk wyślij, dane zostają wysłane asynchronicznie. 4 Servlet uruchamia walidatora wejść i sprawdza dane użytkownika. 5 Dane zostają zapisane w bazie danych. 6 Użytkownik zostaje powiadomiony o poprawnym dodaniu wejścia. Alternatywne scenariusze: 25
2.4.Opis przypadków użycia Rysunek 2.19. Diagram aktywności dodania wejsćia Wynik: Wejście jest niepoprawne, użytkownik zostaje powiadomiony o tym fakcie stosownym komunikatem. Poprawnie zwalidowane wejście zostaje dodane do bazy danych, użytkownik zostaje powiadomiony stosownym komunikatem. 2.4.9. Testowanie rozwiązania w systemie Diagram aktywności został przedstawiony na rysunku 2.21, natomiast maszyna stanów na rysunku 2.22. Opis: Zalogowany użytkownik sprawdza swoje rozwiązanie zadania dla konkretnego, wybranego przez siebie wejścia. Zależności: Przeglądanie zadań 2.4.4 Przeglądanie wejść 2.4.7 Aktorzy: Zalogowany użytkownik systemu. 26
2.4.Opis przypadków użycia Rysunek 2.20. Diagram maszyny stanów dodawania wejścia Warunki początkowe: Użytkownik musi być zalogowany. W systemie muszą istnieć zadania oraz wejścia do nich. Scenariusz przypadku użycia: Wynik: 1 Użytkownik wybiera interesujące go wejście. 2 Użytkownik wprowadza wyjście w pole formularza. 3 Użytkownik naciska przycisk sprawdź. 4 Servlet tworzy klasę sędziego wykorzystując do tego celu Custom Class Loadera. Przy pomocy sędziego następuje sprawdzenie rozwiązania, wynik zostaje zapisany w bazie danych. 5 Wynik zostaje zaprezentowany użytkownikowi poprzez asynchronicznie dogranie na stronę. Wynik oceny sędziego zostaje zapisany w bazie danych i wyświetlony użytkownikowi. 27
2.4.Opis przypadków użycia Rysunek 2.21. Diagram aktywności testowania rozwiązań Rysunek 2.22. Diagram maszyny stanów testowania rozwiązań 28
2.4.Opis przypadków użycia 2.4.10. Edycja zadań Diagram aktywności został przedstawiony na rysunku 2.23, natomiast maszyna stanów na rysunku 2.24. Opis: Zalogowany użytkownik z uprawnieniami problem settera aktualizuje dane zadania. Zależności: Aktorzy: Przeglądanie zadań 2.4.4 Zalogowany użytkownik z uprawnieniami problem settera. Warunki początkowe: Użytkownik musi być zalogowany. Użytkownik musi posiadać uprawnienia problem settera. Scenariusz przypadku użycia: 1 Użytkownik wybiera interesujące go zadanie do edycji. 2 Użytkownik zmienia nazwę, opis, sędziego lub walidatora wejść. 3 Servlet dokonuje zmian w bazie danych. 4 Użytkownik zostaje przekierowany do strony edycji zadań z komunikatem o powodzeniu zmiany zadania. Alternatywne scenariusze: Wynik: Użytkownik podał niepoprawnie którąś z wartości, zostaje powiadomiony stosownym komunikatem. Zmienione zadanie zostaje zachowane w bazie danych, użytkownik zostaje powiadomiony stosownym komunikatem. 29
2.4.Opis przypadków użycia Rysunek 2.23. Diagram aktywności edycji zadań Rysunek 2.24. Diagram maszyny stanów edycji zadań 30
2.4.Opis przypadków użycia 2.4.11. Dodanie zadań Diagram aktywności został przedstawiony na rysunku 2.25, natomiast maszyna stanów na rysunku 2.26. Opis: Aktorzy: Zalogowany użytkownik mający uprawnienia problem settera lub administratora dodaje nowe zadanie do systemu. Zalogowany użytkownik z uprawnieniami problem settera lub administratora. Warunki początkowe: Użytkownik musi być zalogowany. Użytkownik musi mieć uprawnienia problem settera lub administratora. Scenariusz przypadku użycia: 1 Użytkownik naciska przycisk dodaj zadanie. 2 Użytkownik wprowadza nazwę zadania oraz jego treść. 3 Użytkownik może pobrać paczkę z interfejsami IJudge 2.2 oraz IInputValidator 2.1. 4 Użytkownik załącza skompilowane klasy Java sędziego oraz walidatora wejść. 5 Użytkownik naciska przycisk dodaj zadanie. 6 Servlet dodaje zadanie do bazy danych. 7 Użytkownik zostaje przekierowany do strony dodawania zadań ze stosownym komunikatem powodzenia operacji dodania nowego zadania do systemu. Alternatywne scenariusze: Wynik: Użytkownik nie podał wszystkich pół, zostaje poproszony o podanie wszystkich wartości. Użytkownik próbuje dodać zadanie o nazwie istniejącej w systemie, zostaje poinformowany o zaistniałej sytuacji i poproszony o zmianę nazwy. Użytkownilk załączył pliki nie implementujące odpowiednio interfejsu IJudge 2.2 dla sędziego zadań oraz IInputValidator 2.1, zostaje poproszony o załączenie poprawnych plików *.class. 31
2.4.Opis przypadków użycia Rysunek 2.25. Diagram aktywności dodawania zadań Rysunek 2.26. Diagram maszyny stanów dodawania zadań 32
2.5.Organizacja bazy danych 2.4.12. Edycja użytkowników Diagram aktywności został przedstawiony na rysunku 2.27, natomiast maszyna stanów na rysunku 2.28. Opis: Zalogowany administrator ustawia uprawnienia zwykłego użytkownika / problem settera wybranym przez siebie użytkownikom. Aktorzy: Zalogowany administrator systemu Warunki początkowe: Użytkownik musi być zalogowany. Użytkownik musi posiadać uprawnienia administratora. Scenariusz przypadku użycia: 1 Użytkownik naciska przycisk Edytuj użytkowników. 2 Użytkownik wybiera interesującą go stronę z użytkownikami. 3 Użytkownik dokonuje stosownych zmian. 4 Użytkownik naciska przycisk zapisz zmiany. 5 Servlet zapisuje informacje o użytkownikach w bazie danych. 6 Użytkownik zostaje przekierowany do strony edycji użytkowników z komunikatem powodzenia zapisy zmian uprawnień użytkowników. Alternatywne scenariusze: Wynik: Użytkownik nie wprowadził żadnych zmian, zostaje powiadomiony stosownym komunikatem. Zmiana uprawnień zapisana w bazie danych. Użytkownik zostaje powiadomiony o zmianie stosownym komunikatem. 2.5. Organizacja bazy danych 2.5.1. Schemat relacyjnej bazy danych Schemat relacyjnej bazy danych został przedstawiony na rysunkach 2.29 oraz 2.30. Opis poszczególnych tabel znajduje się w podrozdziale 2.5.2. 33
2.5.Organizacja bazy danych Rysunek 2.27. Diagram aktywności edycji użytkowników Rysunek 2.28. Diagram maszyny stanów edycji użytkowników 34
2.5.Organizacja bazy danych Rysunek 2.29. Schemat relacyjnej bazy danych, część 1 Rysunek 2.30. Schemat relacyjnej bazy danych, część 2 35
2.5.Organizacja bazy danych Nazwa pola Typ pola Opis pola id int(10) unsigned NOT NULL Id użytkownika - klucz główny RolaUzytkownika Id int(10) unsigned NOT NULL Id roli użytkownika - klucz obcy login varchar(50) NULL Login uzytkownika haslo varchar(32) NULL Hasło użytkownika - skrót md5 Rysunek 2.31. Opis pól tabeli Uzytkownik Nazwa pola Typ pola Opis pola Id int(10) unsigned NOT NULL Id roli użytkownika - klucz główny Nazwa varchar(50) default NULL Nazwa roli użytkownika Rysunek 2.32. Opis pól tabeli RolaUzytkownika 2.5.2. Opis tabel Użytkownik tabela zawierająca informacje o użytkowniku. Opis pól przedstawiono w tabeli 2.31. RolaUzytkownika tabela zawierająca informacje o roli użytkownika. Opis pól przedstawiono w tabeli 2.32. Przywilej tabela zawierająca informacje o przywileju użytkownika. Opis pól przedstawiono w tabeli 2.33. PrzywilejPoleWMenu tabela kontener zawierająca informacje o tym jakie pola w menu sa przypisane do jakiego przywileju. Opis pól przedstawiono w tabeli 2.34. PoleWMenu tabela zawierające informacje o polach w menu. Opis pól przedstawiono w tabeli 2.35. Zadanie tabela zawierające informacje o zadaniach znajdujących się w systemie. Opis pól przedstawiono w tabeli 2.36. InputDoZadania tabela zawierające informacje o wejściach do zadań znajdujących się w systemie. Opis pól przedstawiono w tabeli 2.37. Nazwa pola Typ pola Opis pola Id int(10) unsigned NOT NULL Id przywileju - klucz główny RolaUzytkownika Id int(10) unsigned NOT NULL Id roli użytkownika - klucz obcy Nazwa varchar(50) default NULL Nazwa roli użytkownika Rysunek 2.33. Opis pól tabeli Przywilej v 36
2.5.Organizacja bazy danych Nazwa pola Typ pola Opis pola Przywilej Id int(10) unsigned NOT NULL Id przywileju - klucz obcy PoleWMenu Id int(10) unsigned NOT NULL Id pola w menu - klucz obcy Id int(11) NOT NULL Id kontenera - klucz główny Rysunek 2.34. Opis pól tabeli PrzywilejPoleWMenu Nazwa pola Typ pola Opis pola Id int(10) unsigned NOT NULL Id pola w menu - klucz główny Pole varchar(50) NULL Nazwa pola w menu Rysunek 2.35. Opis pól tabeli PoleWMenu Nazwa pola Typ pola Opis pola idzadanie int(10) unsigned NOT NULL Id zadania - klucz główny Uzytkownik id int(10) unsigned NOT NULL Id dodającego - klucz obcy Nazwa varchar(100) NULL Nazwa zadania Tresc text Treść zadania Judge mediumblob Binarna reprezentacja klasy sędziego InputValidator mediumblob Binarna reprezentacja klasy walidatora wejść Rysunek 2.36. Opis pól tabeli Zadanie Nazwa pola Typ pola Opis pola Id int(10) unsigned NOT NULL Id wejścia do zadania - klucz główny Uzytkownik id int(10) unsigned NOT NULL Id uzytkownika - klucz obcy Zadanie idzadanie int(10) unsigned NOT NULL Id zadania - klucz obcy Input text Zawartość wejścia Rysunek 2.37. Opis pól tabeli InputDoZadania 37
2.6.Struktura klas w systemie Nazwa pola Typ pola Opis pola id int(11) NOT NULL Id oceny - klucz główny uzytkownikid int(11) NOT NULL Id użytkownika - klucz obcy inputid int(11) NOT NULL Id wejścia - klucz obcy ocena int(11) NOT NULL Ocena wejścia w skali 1-100 Rysunek 2.38. Opis pól tabeli Ocena Nazwa pola Typ pola Opis pola id int(10) unsigned NOT NULL Id rozwiązania - klucz główny InputDoZadania Id int(10) unsigned NOT NULL Id wejścia - klucz obcy Zadanie idzadanie int(10) unsigned NOT NULL Id zadania - klucz obcy Rozwiazanie longblob Rozwiązanie jako plik Poprawne tinyint(1) default NULL Określa, czy rozwiązanie było poprawne UzytkownikId int(10) unsigned default NULL Id użytkownika - klucz obcy Rysunek 2.39. Opis pól tabeli RozwiazanieUzytkownika Ocena tabela zawierające informacje o ocenach wejść do zadań znajdujących się w systemie. Opis pól przedstawiono w tabeli 2.38. RozwiazanieUzytkownika tabela zawierające informacje o rozwiązaniach zadań znajdujących się w systemie. Opis pól przedstawiono w tabeli 2.39. 2.6. Struktura klas w systemie Kod systemu został podzielony na odrębne pakiety klas, zależności między nimi zostały przedstawione na rysunku 2.40. Podział taki został wprowadzony, aby polepszyć strukturyzację kodu oraz ułatwić zarządzanie kodem. Poszczególne pakiety zostaną dokładniej opisane w kolejnych podrozdziałach. 2.6.1. Package: Beans Diagram klas tego pakietu został przedstawiony na rysunku 2.41. 2.6.2. Package: Entity Beans Diagram klas tego pakietu został przedstawiony na rysunku 2.42. 2.6.3. Package: Utils Diagram klas tego pakietu został przedstawiony na rysunku 2.43. 38
2.6.Struktura klas w systemie Rysunek 2.40. Zależności pomiędy pakietami klas w systemie 2.6.4. Package: Servlets Diagram klas tego pakietu został przedstawiony na rysunku 2.44. 39
2.6.Struktura klas w systemie Rysunek 2.41. Pakiet zawierający klasę SessionBean 40
2.6.Struktura klas w systemie Rysunek 2.42. Pakiet zawierający klasy mapujące na encje bazy danych 41
2.6.Struktura klas w systemie Rysunek 2.43. Pakiet zawierający klasy narzędziowe 42
2.6.Struktura klas w systemie Rysunek 2.44. Pakiet zawierający servlety 43
Rozdział 3 Realizacja aplikacji w modelu MVC 3.1. Definicja modelu MVC MVC (ang. Model-View-Controller) - Model-Widok-Kontroler to architektoniczny wzorzec projektowy, którego głównym założeniem jest wyodrębnienie trzech podstawowych komponentów aplikacji: modelu danych interfejsu użytkownika logiki sterowania w taki sposób, aby modyfikacje jednego komponentu minimalnie wpływały na pozostałe [19]. Schemat zależności między modelem, widokiem, kontrolerem, dispatcherem i przeglądarką użytkownika został przedstawiony na rysunku 3.1. Ogólny schemat życia żądania w tym modelu przedstawia się następująco: Użytkownik wysyła żądanie do kontrolera. Kontroler może zapisać odpowiednie dane w bazie danych oraz pobrać dane potrzebne do zaprezentowania w interfejsie przygotowywanym dla użytkownika. Kontroler przygotowuj dane dla widoku. Widok generuje odpowiedni interfejs. Kontroler przy użyciu dispatchera pokazuje użytkownikowi wygenerowany interfejs. Cykl wraca do miejsca wyjścia- interfejs oczekuje na interakcje użytkownika. 44
3.1.Definicja modelu MVC Realizacja aplikacji w modelu MVC Rysunek 3.1. Schemat zależności w modelu MVC 45
3.2.Model Realizacja aplikacji w modelu MVC 3.2. Model 3.3. View 3.4. Controller 3.5. Maszyna wirtualna Javy oraz Class Loadery 3.6. Custom Class Loader maszyny wirtualnej Java 3.7. Implementacja Custom Class Loadera w systemie 46
Rozdział 4 Budowa systemu 4.1. System jako aplikacja JEE 4.2. Struktura systemu 47
Rozdział 5 Przykładowe zastosowania systemu przy rozwiązywaniu problemów algorytmicznych 5.1. Kolorowanie wierzchołkowe 5.2. Znajdowanie najkrótszej ścieżki 48
Rozdział 6 Podsumowanie i wnioski 49
Dodatek A Podręcznik użytkownika 50
Dodatek B Opis wdrożenia B.1. Apache Tomcat B.2. MySQL 51
Dodatek C Wykorzystane technologie oraz frameworki C.1. JSP JSP - JavaServer Pages. C.2. JSTL JSTL - JavaServer Pages Standard Tag Library. C.3. CSS CSS - Kaskadowe arkusze stylów (ang. Cascading Style Sheets, CSS). CSS to język umożliwiający manipulację formy prezentacji znaczników HTML na stronach WWW. Arkusz stylów to lista dyrektyw ustalająca w jaki sposób elemnenty strony WWW mają zostać wyświetlone. (Plik z arkuszem stylu styles.css został zaprezentowany na rysunku C.1). C.4. JavaScript JavaScript - skryptowy język obiektowy umożliwiający tworzenie dynamicznych stron po stronie użytkownika, jak i zarządzanie DOM (ang. Document Object Model). Java- Script został wykorzystany w systemie do obsługi AJAX-a po stronie klienckiej. Częściowy listing pliku js.js został przedstawiony na rysunku C.2. C.5. Servlety Servlet - klasa języka Java, rozszerzająca możliwości serwerów hostujących aplikacje w oparciu o model żądanie - odpowiedź. Pomimo, że serwlety mogą odpowiadać na każdy rodzaj żądania są najczęściej wykorzystywane do rozszerzania funkcjonalności aplikacji webowych. Klasa HttpServle zawarta w pakiecie javax.servlet.http dostarcza metod potrzebnych przy przetwarzaniu HTTP. Najważniejsze z nich to doget() i dopost() służący do obsługi żądań typu GET oraz POST. Cykl życia serwletu przedstawia się następująco: Żądanie HTTP zostaje zgłoszone serwerowi aplikacji JEE. 52
C.5.Servlety Wykorzystane technologie oraz frameworki #menu{ padding bottom : 1 5 px ; background : u r l (.. / images /menubackground. png ) repeat y ; } #menu>div { d i s p l a y : i n l i n e block ; }. menuitem{ d i s p l a y : i n l i n e block ; padding : 1 0 px ; margin : 0 px ; margin l e f t : 2 px ; margin r i g h t : 2 px ; background c o l o r : t r a n sparent ; border : none ; }. menuitemover{ d i s p l a y : i n l i n e block ; padding : 1 0 px ; margin : 0 px ; margin l e f t : 2 px ; margin r i g h t : 2 px ; background c o l o r : rgb ( 0, 1 2 8, 2 5 5 ) ; border : rgb (180,255,255) s o l i d 1px ; }. zadanie l i g h t mouseout{ background : rgb ( 6 7, 1 8 7, 2 0 0 ) ; c u r s o r : d e f a u l t ; }. zadanie l i g h t mouseover{ background : rgb ( 4 7, 1 5 7, 2 1 0 ) ; c u r s o r : p o i n t e r ; } / /... Rysunek C.1. Plik styles.css 53
C.5.Servlety Wykorzystane technologie oraz frameworki f u n c t i o n gethttpobject ( ){ var xhr = f a l s e ; i f ( window. XMLHttpRequest ) { xhr = new XMLHttpRequest ( ) ; } e l s e i f ( window. ActiveXObject ) { try { xhr = new ActiveXObject ( Msxml2.XMLHTTP ) ; } catch ( e ){ try { xhr = new ActiveXObject ( M icrosoft.xmlhttp ) ; } catch ( e ){ xhr = f a l s e ; } } } return xhr ; } f u n c t i o n processhttprequest ( callbackfunction, params, page ){ var r e q u e s t = gethttpobject ( ) ; i f ( r e q u e s t ){ r e q u e s t. onreadystatechange = f u n c t i o n (){ callbackfunction ( r e q u e s t ) ; } r e q u e s t. open ( POST, page, true ) ; r e q u e s t. setrequestheader ( Content Type, a p p l i c a t i o n /x www form urlencoded ) ; r e q u e s t. send ( params ) ; } } f u n c t i o n loadvote ( r e q u e s t ){ i f ( r e q u e s t. readystate == 4){ i f ( r e q u e s t. s t a t u s == 200 r e q u e s t. s t a t u s == 304){ var XML = r e q u e s t. responsexml ; var id = trim (XML. getelementsbytagname ( id ) [ 0 ]. f i r s t C h i l d. nodevalue ) ; / /... } } } Rysunek C.2. Plik js.js 54
C.6.MySQL Wykorzystane technologie oraz frameworki Serwer aplikacji przy pomocy class loadera ładuje do pamięci klasę odpowiedniego serwletu(mapowanie ścieżek uri znajduje się w pliku web.xml C.3) oraz tworzy jej instancję. Serwer wykonuje metodę init() serwletu. Wykonana zostaje metoda doget()/dopost(). Obsługa żądania kończy się. Po zakończeniu obsługi żądania obiekt serwletu pozostaje w pamięci - w przypadku kolejnego żądania zostanie wywołana tylko metoda doget()/dopost(). C.6. MySQL MySQL - system zarządzania relacyjną bazą danych (RDBMS- ang. Relational Database Management System). Silnik bazodanowy użyty w systemie w celu przechowywania danych o użytkownikach, zadaniach, wejściach oraz rozwiązaniach do nich. Wybrano ten RDBMS, ze względu na: Szybkość funkcjonowania Licencję GPL Wielosystemową architekturę C.7. JDBC JDBC - nazwa handlowa (Java TM Database Connectivity) api zawierające klasy i interfejsy umożliwiające łączenie się z bazą danych, dokonywanie operacji na bazie danych oraz przetwarzania zwracanych rezultatów. Wykorzystany sterownik MySqlJDBCConnector to sterownik typu 4. Sterownik typu 4 jest napisany całkowicie w Javie i wykorzystuje natywny protokół bazy danych. Sterowniki tego typu są niezależne od platformy uruchomieniowej, nie potrzebują warstwy translacyjnej, czy middlewarowej, komunikują się bezpośrednio z serwerem bazy danych, więc ich wydajność jest lepsza niż pozostałych sterowników (typu 1, 2 i 3) [17]. C.8. POJO Entity Bean POJO Entity Bean - Plain Old Java Object. Obiekty tego typu muszą posiadać bezargumentowy konstruktor, niekoniecznie publiczny, dobrze też, gdy implementują metody equals() oraz hashcode(). Są one wykorzystane jako obiekty mapujące tabele z relacyjnej bazy danych [14]. 55
C.8.POJO Entity Bean Wykorzystane technologie oraz frameworki <?xml v e r s i o n = 1.0 encoding= UTF 8?> <web app v e r s i o n = 2.5 xmlns= http : / / java. sun. com/xml/ ns / javaee xmlns : x s i= http : / /www. w3. org /2001/XMLSchema i n s t a n c e x s i : schemalocation= http : / / java. sun. com/xml/ ns / javaee http : / / java. sun. com/xml/ ns / javaee /web app 2 5. xsd > <s e r v l e t > <s e r v l e t name>menu</s e r v l e t name> <s e r v l e t c l a s s >S e r v l e t s. Menu</s e r v l e t c l a s s > </ s e r v l e t > //... <s e r v l e t mapping> <s e r v l e t name>menu</s e r v l e t name> <url pattern >/Menu</url pattern > </ s e r v l e t mapping> //... </ s e r v l e t mapping> <s e s s i o n config > <s e s s i o n timeout> 30 </s e s s i o n timeout> </s e s s i o n config > <error page> <error code >404</ error code> <l o c a t i o n >/e r r o r. jsp </l o c a t i o n > </e rror page> <p e r s i s t e n c e context r e f > <p e r s i s t e n c e context r e f name> p e r s i s t e n c e / pracamagisterska </p e r s i s t e n c e context r e f name> <p e r s i s t e n c e unit name> PracaMagisterskaPU </p e r s i s t e n c e unit name> </p e r s i s t e n c e context r e f > <welcome f i l e l i s t > <welcome f i l e >index. jsp </welcome f i l e > </welcome f i l e l i s t > </web app> Rysunek C.3. Plik web.xml 56
C.9.JPA Wykorzystane technologie oraz frameworki C.9. JPA JPA (ang. Java Persistence API) - oficjalny standard mapowania obiektowo-relacyjnego (ORM) firmy Sun Microsystems dla języka Java [15] [16]. JPA składa się z trzech części: API, zdefiniowanego w paczce javax.persistence Java Persistence Query Language (JPQL) metadanych związanych z obiektami/relacjami (adnotacje XML-owe) C.10. Hibernate Hibernate - framework realizujący dostęp do warstwy danych. Odpowiada za translację pomiędzy relacyjną bazą danych, a obiektami (mapowanie O/R). Ułatwia pisanie aplikacji poprzez zastąpienie bezpośredniego dostępu do danych w bazie danych przez wysokopoziomowy mechanizm obiektowy. Obiekty są mapowane na tabele w odpowiednim pliku XML oraz przy wykorzystaniu specjalnych adnotacji. Trwałość (persistence) obiektów jest zapewniania dzięki obiektom typu POJO. Jako język zapytań został wykorzystany język JPQL (Java Persistence Query Language) [14]. Plik persistence.xml został przedstawiony na rysunku C.4, a przykładowy obiekt mapujący na tabelę polewmenu na rysunku C.5. C.11. Java refrections Java Reflection API - api, dzięki któremu aplikacja Java może być modyfikowana w trakcie wykonywania. Refleksje pozwalają w łatwy sposób rozbudowywać istniejącą aplikację o nowe moduły, czy funkcjonalności. W systemie API to zostało wykorzystane do dynamicznego ładowania klas walidatora wejść oraz sędziego zadań. C.12. Ajax AJAX (ang. Asynchronous JavaScript and XML, Asynchroniczny JavaScript i XML) technologia wytwarzania serwisów internetowych, w której wymiana informacji pomiędzy użytkownikiem serwisu, a samym serwisem odbywa się w sposób asynchroniczny, nie wymagający przeładowywania zawartości całego dokumentu, lecz tylko wybranej jego części. Jest to alternatywa dla standardowego wytwarzania synchronicznego, w którym po synchronicznym wysłaniu żądania do serwera otrzymujemy informację zwrotna w postaci dokumentu HTML[13]. Na technologię tą składają się trzy elementy: XMLHttpRequest - obiekt umożliwiający budowanie asynchronicznych (jak i synchronicznych) żądań, przechowujący informację o funkcji zwrotnej (callback), stanie i 57
C.12.Ajax Wykorzystane technologie oraz frameworki <?xml v e r s i o n = 1.0 encoding= UTF 8?> <p e r s i s t e n c e v e r s i o n = 1.0 xmlns= http : / / java. sun. com/xml/ ns / p e r s i s t e n c e xmlns : x s i= http : / /www. w3. org /2001/XMLSchema i n s t a n c e x s i : schemalocation= http : / / java. sun. com/xml/ ns / p e r s i s t e n c e http : / / java. sun. com/xml/ ns / p e r s i s t e n c e / p e r s i s t e n c e 1 0. xsd > <p e r s i s t e n c e unit name= PracaMagisterskaPU > <provider >org. h i b e r n a t e. ejb. H i b e r n a t e P e r s i s t e n c e </provider > <jta data source/> <c l a s s >EJBBeans. Inputdozadania </c l a s s > <c l a s s >EJBBeans. InputdozadaniaPK</c l a s s > <c l a s s >EJBBeans. Ocena</c l a s s > <c l a s s >EJBBeans. Polewmenu</c l a s s > <c l a s s >EJBBeans. Przywilej </c l a s s > <c l a s s >EJBBeans. Przywilejpolewmenu </c l a s s > <c l a s s >EJBBeans. Rolauzytkownika </c l a s s > <c l a s s >EJBBeans. Rozwiazanieuzytkownika </c l a s s > <c l a s s >EJBBeans. RozwiazanieuzytkownikaPK </c l a s s > <c l a s s >EJBBeans. Uzytkownik</c l a s s > <c l a s s >EJBBeans. Zadanie </c l a s s > <p r o p e r t i e s > <property name= h i b e r n a t e. show sql value= f a l s e /> <property name= h i b e r n a t e. connection. username value= s p o j /> <property name= h i b e r n a t e. connection. d r i v e r c l a s s value= com. mysql. jdbc. Driver /> <property name= h i b e r n a t e. connection. password value= pass /> <property name= h i b e r n a t e. l o g g i n g. l e v e l value= SEVERE /> <property name= h i b e r n a t e. connection. u r l value= jdbc : mysql : / / l o c a l h o s t :3306/ s p o j s o l u t i o n c o m p a r e r? useunicode=true& ; characterencoding=utf 8 & ; c o n n e c t i o n C o l l a t i o n=u t f 8 g e n e r a l c i /> </p r o p e r t i e s > </p e r s i s t e n c e unit> </p e r s i s t e n c e > Rysunek C.4. Plik persistence.xml 58
C.12.Ajax Wykorzystane technologie oraz frameworki / Encja polewmenu @author Michał Piątek / @Entity @Table (name = polewmenu, c a t a l o g = s p o j s o l u t i o n c o m p a r e r, schema = ) @NamedQueries ({ @NamedQuery(name = Polewmenu. f i n d A l l, query = SELECT p FROM Polewmenu p ), @NamedQuery(name = Polewmenu. findbyid, query = SELECT p FROM Polewmenu p WHERE p. id = : id ), @NamedQuery(name = Polewmenu. findbypole, query = SELECT p FROM Polewmenu p WHERE p. pole = : pole ), @NamedQuery(name = Polewmenu. findzrola, query = SELECT p FROM Polewmenu p, Przywilejpolewmenu pr WHERE pr. p r z y w i l e j I d = : r o l a I d and p. id = pr. polewmenuid ), @NamedQuery(name = Polewmenu. findbezroli, query = SELECT p FROM Polewmenu p WHERE (SELECT COUNT( pr. i d ) from Przywilejpolewmenu pr where pr. polewmenuid = p. id ) = 0 )}) p u b l i c c l a s s Polewmenu implements S e r i a l i z a b l e { p r i v a t e s t a t i c f i n a l long serialversionuid = 1L ; @Id @GeneratedValue ( s t r a t e g y = GenerationType.IDENTITY) @Basic ( o p t i o n a l = f a l s e ) @Column(name = Id ) p r i v a t e I n t e g e r id ; @Column(name = Pole ) p r i v a t e S t r i n g pole ; / /... implementacja metod i konstruktorów } Rysunek C.5. Klasa Polewmenu 59
C.13.JsMath Wykorzystane technologie oraz frameworki statusie żądania oraz informację zwrotną. W chwili utworzenia obiektu XMLHttpRequest musi być on w stanie UNSENT, ten stan jest reprezentowany przez stałą o tej samej nazwie i wartości 0. Status OPENED jest ustawiany po pomyślnym wywołaniu metody open(). Podczas, gdy obiekt jest w tym stanie można ustawiać nagłówki poprzez wywołanie metody setrequestheader() oraz można wykonać żądanie poprzez wywołanie metody send(). Status HEADERS RECEIVED jest ustawiany, gdy wszystkie nagłówki odpowiedzi zostały przesłane. Status LOADED jest ustawiany, gdy ciało odpowiedzi jest przesyłane do klienta. Status DONE jest ustawiany, gdy transmisja dobiegła końca, są znane nagłówki, ciało wiadomości oraz flaga błędu. Interfejs XMLHttpRequest został przedstawiony na rysunku C.6. JavaScript - język skryptowy wykonywany po stronie użytkownika, który obsługuje obiektowy model dokumentu (Document Object Model, DOM). Nie musi to być koniecznie JavaScript, może to być inny język skryptowy, taki jak VBScript, czy JScript. XML - język znacznikowy, w którym zapisywana jest informacja zwrotna. Nie musi być to koniecznie format XML (Extensible Markup Language), może to też być czysty HTML/XHTML, JSON (JavaScript Object Notation), czy inny format wybrany przez użytkownika. C.13. JsMath JsMath - pakiet umożliwiający wstawianie notacji matematycznych na strony HTML, który to działa na szerokim zbiorze przeglądarek internetowych oraz systemów operacyjnych z rodziny Windows, Macintosh OS X oraz *NIX. jako, że jest to pakiet JavaScriptowy nie ma potrzeby instalowania dodatkowych modułów na serwerze. Do prezentowania zawartości TEX-owych wstawek można wykorzystać czcionki TEX-owe, skalowalne czcionki obrazkowe, jak i czcionki Unicodowe. Zawartość stron nie musi być w żaden sposób preprocesowana, całość jest zapisana w TEX-u, potem renderowana przez silnik JavaScriptowy, co ułatwia zarządzanie zawartością. 60