Celem projektu było stworzenie serwisu internetowego, gromadzącego i udostępniającego dane o zagrożeniach i niedogodnościach występujących w aglomeracjach miejskich.
Serwis jest narzędziem dedykowanym zarówno dla doświadczonych internautów jak i dla osób mało zaznajomionych z Siecią, które umożliwia prostą wymianę danych między użytkownikami portalu na temat zaobserwowanych przez nich zagrożeń. Serwis udostępnia intuicyjny interfejs wprowadzania i wyszukiwania danych zawartych w bazie danych. Sposób reprezentacji zawartych w bazie danych informacji został tak przemyślany, aby zminimalizować czas poszukiwania informacji (mechanizm filtrów i reprezentacja zagrożeń na mapie).
Projekt był realizowany w czteroosobowym zespole. Odpowiedni podział pracy nawet w tak niewielkim zespole jest istotny i może znacznie ułatwić pracę. Pracę nad projektem można podzielić na dwa etapy. Pierwszy związany ze wstępnym projektowaniem aplikacji i wyborem technologii oraz drugi związany z realizacją.
W etapie projektowania uczestniczyła każda osoba z zespołu. Wspólnie ustalono cele projektu i główne założenia. Następnie ustaliliśmy jakie technologie zostaną wykorzystane oraz zgodnie z preferencjami każdego z nas rozdzieliliśmy zadania do realizacji. Zakres pracy każdej z osób prezentował się następująco:
Taki podział pracy okazał się sprawnie funkcjonować. Przede wszystkim ze względu na stworzenie dwóch mniejszych zespołów zajmujących się poszczególnymi warstwami.
Niestety podczas realizacji projektu nie skorzystaliśmy z systemu kontroli wersji. Był to duży błąd, ponieważ po pewnym czasie ilość różnych wersji rozwojowych aplikacji była bardzo duża. Zorientowanie się która wersja jest aktualna, ciągłe aktualizacje plików, archiwizacja wymagały sporo czasu.
Projekt korzysta z wielu technologii. Wybór każdej z nich był przemyślany i pomimo sporego wysiłku włożonego we współdziałanie wszystkich rozwiązań, przyniósł wymierne korzyści.
Schemat aplikacji składa się z trzech warstw:
Poniżej znajduje się krótka charakterystyka każdej z warstw systemu.
Interpretowana i wyświetlana użytkownikowi przez przeglądarkę. Do implementacji wygodnego dla użytkownika interface’u wykorzystano następujące technologie: HTML, CSS, JavaScript, AJAX oraz GoogleMaps API. Warstwę można podzielić na część reprezentacji danych dla użytkownika oraz część administracyjną i reprezentacji informacji o użytkowniku.
Warstwa odbiera zapytania z warstwy prezentacji i odpowiednio na nie reaguje. W szczególności komunikuje się z warstwą bazy danych przy pomocy sterownika JDBC oraz zapytań SQL. Zaimplementowana w języku Java logika odpowiednio przetwarza dane, a następnie odpowiada z wykorzystaniem HTML’a bądź XML’a i technologii AJAX.
Warstwa realizowana jest przez system bazo-danowy PostgreSQL. Odpowiada na zapytania przesyłane z warstwy logiki aplikacji. Sama baza danych została dokładniej opisana w „Projekcie logicznym” sprawozdania. Trzon tej warstwy stanowi serwer Tomcat 5.5. Jest to jednocześnie kontener serwletów Java. Pozwala na przechowywanie serwletów oraz klas języka Java.
Schemat działania aplikacji przestawia rys. 1.
Wielokrotnie odznaczony, jeden z najpopularniejszych systemów zarządzania relacyjnymi bazami danych. Zgodny ze standardem SQL.
Jest to kontener serwletów Java i serwer WWW stworzony przez organizacje Apache Software Foundation. Praca z serwerem wymagała odpowiedniego skonfigurowania Tomcat’a, co sprowadzało się do edycji plików XML. Podczas realizacji projektu serwer pracował niezależnie od rozwijanych plików projektu, przez co konieczna była ręczna podmiana tychże plików w celu testowania aplikacji. Była to dość czasochłonna czynność. Rozwiązaniem problemu okazała się funkcjonalność oferowana przez środowisko programistyczne, tj. możliwość integracji Tomcat’a z Eclipse. Taki sposób pracy znacznie przyspieszył pracę, w szczególności testowanie projektu.
Język Java stanowi główną część aplikacji i jest szeroko wykorzystywany w projekcie. Stanowi warstwę logiczną systemu oraz jest wykorzystywany do komunikacji z bazą danych. Komunikacja z PostgreSQL polega na nawiązywaniu połączenia z serwerem bazo-danowym oraz wysyłaniu zapytań SQL do bazy danych. Ze względu na istotę zagadnienia, wykorzystaniu języka Java w projekcie został poświęcony oddzielny rozdział.
JavaScript jest podstawą funkcjonowania interface'u użytkownika w części reprezentującej dane o zagrożeniach.
XML w aplikacji używany jest do asynchronicznej wymiany informacji między przeglądarką a serwerem. Stanowi on swoisty protokół, poprzez który, serwer wysyła dane do klienta, które następnie ulegają sparsowaniu i użyciu.
Jedną z najistotniejszych części projektu była wizualizacją zbieranych i przechowywanych przez system danych. Najlepszym rozwiązaniem w tej materii okazała się wizualizacja za pomocą mapy z naniesionymi na nią punktami, o których informacje przechowywane są w bazie danych systemu.
W projekcie posłużyliśmy się mapami firmy Google - GoogleMaps. Wybór nasz umotywowany był powszechnością tego silnika map, prostotą jego użycia przez użytkowników, przejrzystym i prostym API oraz przede wszystkim faktem, iż GoogleMaps jest bezpłatny - jedne, co należy zrobić, aby praktycznie bez ograniczeń móc z niego korzystać, to zarejestrować się bezpłatnie w systemie Google, otrzymując w ten sposób indywidualny dla naszej domeny kod aktywacyjny GoogleMaps.
GoogleMaps oferuje szeroki zakres funkcjonalności dostępnej za pomocą GoogleMaps API używanego z poziomu języka JavaScript. Dokładna specyfikacja GoogleMaps API dostępna jest pod tym adresem.
GoogleMaps zawiera szereg klas pozwalających na wyświetlanie oraz nawigowanie mapą, dodawanie do mapy punktów wraz z prezentacja opisu do nich oraz wiele innych.
W naszej aplikacji korzystaliśmy głównie z wyświetlania i nawigacji mapy oraz szeregu operacji wykonywanych na markerach mapy. Ciekawostką jest zastosowanie menu kontekstowego pod prawym klawiszem myszy, co jest rzeczą rzadko spotykaną w aplikacjach webowych.
GoogleMaps - ze względu na dużą ilość informacji wymienianych w obrębie swojej funkcjonalności korzystają z asynchronicznej wymiany danych. Cały zaprojektowany w aplikacji interface współpracy z mapami Google również został oparty o asynchroniczną wymianę informacji, opartą o technologie Ajax.
Ajax jest technologią zainicjowaną przez firmę Google, służącą do asynchronicznej wymianie danych między przeglądarką a serwerem. Nie jest ona nowym językiem programowania a jedynie nowym wykorzystaniem już istniejących języków skryptowych, działających po stronie klienta (Java Script, JScript, VBScript) oraz języka znaczników XML. Cała magia Ajax'a opiera się na obiekcie typu XMLHttpRequest, udostępniany przez przeglądarkę, który umożliwia wymianę danych klienta z serwerem bez potrzeby przeładowania całej strony.
Korzystając z udogodnień, jakie niesie GoogleMaps API, zamiast tradycyjnego obiektu XMLHttpRequest, różnego w różnych przeglądarkach, posłużono się obiektem GXmlHttp, niezależnym od używanej przeglądarki. Dzięki temu poprawiono przejrzystość kodu, pozbywając się konieczności sprawdzania typu używanej przez użytkownika przeglądarki.
AJAX w naszej aplikacji obsługuje niemal całą funkcjonalność związaną z interaktywnym przeglądaniem informacji o zagrożeniach na mapie. Jest on używany do wczytywania punktów, znajdujących się w widzianym obszarze mapy, dodawania punków do bazy, usuwania ich oraz wszelkiej edycji. Dzięki technologii AJAX możliwe jest sprawdzanie informacji o wzajemnej interakcji między użytkownikiem a zdarzeniem, np. czy zalogowany użytkownik głosował już na wybrane zdarzenie, co pozwala na dynamiczne budowanie okien informacyjnych dla poszczególnych zdarzeń.
Funkcje JavaScript odpowiadające za wszelkie połączenia asynchroniczne między klientem a serwerem łączą się z obiektami typu REO (Respont Object) po stronie serwera. Funkcje te można podzielić na dwie grupy:
Działanie tych pierwszych odbywa się poprzez wysłanie odpowiedniego zapytania do obiektu typu REO na serwerze. Obiekt REO parsuje otrzymane zapytanie po czym wywoływana jest odpowiednia funkcje działająca na bazie danych z parametrami wysłanymi w zapytaniu.
Pobieranie informacji z bazy działa podobnie jak aktualizacja, z tą jednak różnicą, że po wysłaniu zapytania do obiektu REO, przeglądarka otrzymuje odpowiedź od serwera z danymi, o które pytała. Dane przesyłane są za pomocą XML, którego dane, po sparsowaniu na poziomie JavaScript, przechowywane są już po stronie klienta.
Jest to procesor szablonów stron WWW stworzony jako projekt open source przez Apache Software Foundation. Velocity przeznaczony jest przede wszystkim do tworzenia dynamicznych stron WWW. Wykorzystuje MVC (Model-View-Controller), dzięki czemu uwalnia osoby tworzące dokumenty HTML od uciążliwej edycji wspólnych plików. Taka możliwość ułatwiła pracę w naszym zespole. Jest to spora zaleta Velocity nad JSP i PHP, w przypadku których zarówno kod, jak i szablon, mogą znajdować się w tym samym pliku.
Wykorzystano HTML 4.0 do prezentacji treści w przeglądarce.
Kaskadowe arkusze stylów, wykorzystane do zdefiniowania wyglądu prezentacji danych w przeglądarce. Zgodne z W3C.
Język Java udostępnia bardzo przyjemne i proste w obsłudze narzędzia służące do połączenia z bazą danych. Za połączenie z bazą danych odpowiedzialny jest pakiet Java Database Connectivity (JDBC). Pakiet ten umożliwia programistom łączenie się z bazami danych oraz wykonywanie zapytań i aktualizację danych w języku SQL.
Po odpowiednim skonfigurowaniu środowiska możliwe jest już połączenie się z bazą danych. W projekcie utworzono metody umożliwiające szybkie połączenie. Są to funkcje:
Otwiera połączenie z bazą danych. Metoda zwraca obiekt klasy Connection wykorzystywanej podczas wykonywania operacji na bazie danych.
Zamyka połączenie z bazą danych, jako parametr przyjmuje obiekt klasy Connection. Ważnym jest, aby był to ten sam obiekt, który wcześniej został utworzony przy pomocy metody openConnection.
Metody zostają zamieszczone poniżej:
private Connection openConnection() throws ClassNotFoundException, SQLException
{
Connection connection;
connection = DriverManager.getConnection("jdbc:postgresql:INDECT", "postgres", "postgres");
Class.forName("org.postgresql.Driver");
return connection;
}
private void closeConnection(Connection connection)
{
if (connection != null)
{
try
{
connection.close();
}
catch (Exception e)
{
e.printStackTrace();
}
}
}
Domyślnie baza danych pracuje w trybie automatycznego zatwierdzania poleceń, czyli wynik każdego polecenia w języku SQL jest natychmiast zatwierdzany w bazie. Po zatwierdzeniu polecenia nie możemy już go odwołać. W przypadku wykonywania pewnej czynności w bazie danych, na przykład dodawania nowego zdarzenia, koniecznym jest dodanie informacji do dwóch tabel: Zdarzenia oraz Definicje_zdarzen. Może jednak zajść sytuacja, w której dane zostały już zapisane w pierwszej tabeli, a w drugiej jeszcze nie. Zakładając, że w tym momencie wystąpił pewien błąd, doszłoby do sytuacji, w której zgubione zostałyby informacje o kategoriach zdarzeń do których to zdarzenie należy. Podobna sytuacja ma miejsce w kilku innych sytuacjach (dodawanie i edycja kategorii, zatwierdzanie zdarzenia itp.). W celu zabezpieczenia się przed taką sytuacją podczas tworzenia projektu wykorzystany został mechanizm transakcji Podobnie jak w przypadku łączenia się z bazą, również w przypadku użycia transakcji utworzone zostały metody umożliwiające sprawne rozpoczynanie oraz kończenie transakcji. Są to:
Rozpoczyna transakcje. W języku Java rozpoczęcie transakcji jest równoznaczne z ustawieniem danego połączenia tak ,aby dane nie mogły być automatycznie zatwierdzane. Metoda ta, jak również dwie kolejne jako parametr przyjmują aktualnie otwarte połączenie.
Zatwierdza transakcje. Warte podkreślenia jest, że metoda ta jednocześnie rozpoczyna nową transakcję, ponieważ połączenie ma wyłączony tryb automatycznego zatwierdzania zmian. W przypadku tego projektu funkcjonalność ta nie jest jednak wykorzystywana w projekcie, ponieważ transakcja jest zatwierdzana zawsze przed zakończeniem połączenia.
Odrzuca transakcje. Wykonywana zawsze, gdy w metodzie wykorzystującej mechanizm transakcji pojawił się jakiś błąd.
Kod powyższych funkcji:
private void beginTransaction (Connection connection)
{
try
{
connection.setAutoCommit(false);
}
catch (SQLException e)
{
System.out.println("Nie można rozpocząć transakcji");
e.printStackTrace();
}
}
private void commitTransaction (Connection connection)
{
try
{
connection.commit();
}
catch (SQLException e)
{
System.out.println("Nie można zakończyć transakcji");
e.printStackTrace();
}
}
private void rollbackTransaction (Connection connection)
{
try
{
connection.rollback();
}
catch (SQLException e)
{
System.out.println("Nie można przerwać transakcji");
e.printStackTrace();
}
}
Pobieranie danych z bazy danych przy pomocy języka Java jest proste. Wystarczy jedynie połączyć się z bazą, utworzyć i wykonać zapytanie. Przykład funkcji pobierającej dane pokazany jest poniżej:
public ArrayList<String> getTagCategoryNameList()
{
ArrayList<String> lvResult = new ArrayList<String>();
Connection connection = null;
Statement statement = null;
ResultSet result = null;
try
{
connection = openConnection();
String QUERY = "SELECT TKZ.nazwa FROM \"Typy_kategorii_zdarzen\" TKZ";
statement = connection.createStatement();
result = statement.executeQuery(QUERY);
while (result.next())
{
lvResult.add(result.getString("nazwa"));
}
}
catch (Exception e)
{
e.printStackTrace();
}
finally
{
closeConnection(connection);
}
return lvResult;
}
Do pobierania danych służy metoda executeQuery(String). Jak można zauważyć zwraca ona obiekt klasy ResultSet. Jest to obiekt, w którym przechowywane są wszystkie rekordy zwrócone przez zapytanie. Rekordy można przeglądać przy użyciu metod next() oraz previous() powodujących przesuwanie się „kursora” przez kolejne rekordy. Dodatkowo możliwe jest ustawienie kursora przy pomocy metod typu first(), last(), beforeFirst(), afterLast(). Wszystkie z tych metod zwracają wartości logiczne:
Po wykonaniu zapytania kursor domyślnie ustawiony jest przed pierwszym rekordem. Rozwiązanie takie umożliwia szybkie sprawdzenie czy zapytanie zwróciło rekordy. Wystarczy jedynie wywołać na obiekcie ResultSet metodę next(). Jeśli metoda się wykona, oznacza to, że istnieje conajmniej jeden rekord. Jest to również wygodne, gdy potrzebujemy iterować po wszystkich rekordach. Wystarczy napisać pętle while w sposób podany w poprzednim przykładzie.
Operacje te są równie proste jak pobieranie danych z bazy. Przykładowa funkcja edytująca dane w bazie:
public int editTag(String pmTagId, String pmName)
{
Connection connection = null;
Statement statement = null;
int lvReturned = 0;
try
{
connection = openConnection();
String QUERY = "UPDATE \"Kategorie_zdarzen\" SET nazwa = '" + pmName + "' WHERE id_kategorie_zdarzen = " + pmTagId;
statement = connection.createStatement();
statement.executeUpdate(QUERY);
}
catch (Exception e)
{
e.printStackTrace();
lvReturned = -1;
}
finally
{
closeConnection(connection);
}
return lvReturned;
}
Jedyna różnica pomiędzy pobieraniem danych z bazy jest wykorzystanie metody executeUpdate(String). Metoda ta jest używana dla instrukcji nie zwracających żadnych danych, a jedynie zmieniających, dodających i usuwających dane w bazie.
Mechanizmem zasługującym na uwagę jest mechanizm poleceń przygotowywanych. Funkcja korzystająca z tego narzędzia wygląda następująco:
public int editEvent(Event pmEvent)
{
Connection connection = null;
Statement statement = null;
PreparedStatement lvStatement = null;
int lvReturned = 0;
try
{
connection = openConnection();
beginTransaction(connection);
String QUERY = "UPDATE \"Zdarzenia\" SET szerokosc_geograficzna = " + pmEvent.gPoint.getLat() + ", dlugosc_geograficzna = " + +pmEvent.gPoint.getLng() + ", opis = '" + pmEvent.description + "', adres_zdjecia = '" + pmEvent.fotoLink +
"', waznosc = " + pmEvent.gPoint.importance + ", nazwa = '" + pmEvent.name + "' WHERE id_zdarzenia = " + pmEvent.id;
statement = connection.createStatement();
statement.executeUpdate(QUERY);
QUERY = "DELETE FROM \"Definicje_zdarzen\" WHERE id_zdarzenia = " + pmEvent.id;
statement.executeUpdate(QUERY);
QUERY = "INSERT INTO \"Definicje_zdarzen\"(id_zdarzenia, id_kategorie_zdarzen) VALUES (?, ?)";
ArrayList<String> lvCategories = new ArrayList<String>();
StringTokenizer lvTokens = new StringTokenizer(pmEvent.gPoint.getTags(), ", ");
lvStatement = connection.prepareStatement(QUERY);
while (lvTokens.hasMoreTokens()
{
lvCategories.add(lvTokens.nextToken());
}
for (String lvString:lvCategories)
{
lvStatement.setInt(1, Integer.valueOf(pmEvent.id));
lvStatement.setInt(2, Integer.valueOf(lvString));
lvStatement.addBatch();
lvStatement.clearParameters();
}
lvStatement.executeBatch();
commitTransaction(connection);
}
catch (Exception e)
{
e.printStackTrace();
lvReturned = -1;
rollbackTransaction(connection);
}
finally
{
closeConnection(connection);
}
return lvReturned;
}
Potęga tego mechanizmu jest wykorzystywana podczas dodawania jednocześnie wielu rekordów do bazy danych, lub ogólniej podczas wykonywania kilku komend SQL o takiej samej strukturze, ale innych wartościach. Tworzone jest zapytanie SQL, ale w miejsce zmieniających się danych wstawiane są znaki zapytania. Są one traktowane jako swego rodzaju parametry. Następnie przy wykorzystaniu metody prepareStatement(String) zwracającej obiekt klasy PreparedStatement należy utworzyć szablon zapytania. Teraz należy ustawić wartości kolejnych parametrów. Jedyna trudność polega na tym, aby pilnować typów danych oraz kolejności argumentów. W przypadku, gdy wartość posiada wartość NULL koniecznym jest jawne ustawienie tej wartości przy użyciu metody setNull(int, int). Pierwszym argumentem tej metody jest numer argumentu, za który ma zostać ustawiona wartość NULL, a drugim typ danych odpowiadający temu argumentowi. Przy użyciu metody addBatch() stworzone zapytanie dodawane jest do grupy instrukcji ,które należy wykonać. Metoda executeBatch() natomiast wykonuje wszystkie zapisane instrukcje.
W przypadku gdy dane dodawane są jednocześnie do kilku tabel połączonych relacjami, koniecznym było pobranie wartości ostatnio wygenerowanego klucza. W standardzie JDBC istnieją metody umożliwiające automatycznie jego pobranie podczas dodawania danych, niestety nie są one dostępne dla baz PostgreSQL. Koniecznym okazało się uzyskanie danych przez pobranie z bazy aktualnej wartości sekwencji przy użyciu SQL’owej metody currval(‘Nazwa_sekwencji’).
Proces wdrażania systemu do użytkownika składa się z kilku etapów:
Wykonany projekt jest typową aplikacją sieciową, opartą na popularnych technologiach. W związku z tym również proces wdrożenia systemu (w szczególności przygotowanie infrastruktury technicznej i systemu informatycznego) należy do standardowych technik informatycznych. Poniżej znajduje się krótki opis działań, które zostały podjęte w ramach realizacji każdego etapu wdrażania systemu.
Dokumentację systemu stanowi ten dokument oraz dwa pozostałe: projekt konceptualny i projekt logiczny. Z punktu widzenia użytkownika istotny jest rozdział interface oraz wprowadzanie danych.
Etap ten był analizowany we wczesnej fazie projektu, podczas wyboru technologii. Oparcie systemu o servlet’y Java oraz kontener servlet’ów Tomcat wymagają wykorzystania serwerów dedykowanych. Tańszym rozwiązaniem jest odpowiednie skonfigurowanie serwera VPS (Virtual Private Server). Projekt przez pewien czas funkcjonował na serwerze VPS z systemem Debian 5.0, później lokalnie, na jednym komputerze uruchomiony był serwer Tomcat oraz system bazy danych Postgresql. Ze względu na ograniczenia czasowe, finansowe oraz fakt, że projekt jest systemem testowym infrastruktura techniczna nie obejmuje profesjonalnych rozwiązań takich jak load-balancer’y czy oddzielne serwery bazo-danowe.
Ten proces obejmuje zainstalowanie i konfigurację serwera Tomcat oraz sytemu bazo-danowego Postgresql. Kolejnym krokiem jest wgranie aplikacji poprzez umieszczenie plików na serwerze Tomcat oraz utworzenie bazy danych.
Testowanie systemu odbywało się na bieżąco podczas tworzenia aplikacji. W szczególności testów wymagały momenty, w których do systemu dodawane były pliki tworzone przez różne osoby. Testowana była każda z warstw aplikacji: prezentacji, logiki oraz bazy-danych.
W przypadku serwisu internetowego jest to prosty etap. Może się wiązać z wykupieniem domeny oraz ewentualną promocją serwisu. W przypadku tego projektu kroki te nie zostały podjęte.
Celem systemu jest gromadzenie i prezentacja informacji o zagrożeniach. Dane pochodzą od użytkowników i są przez nich wprowadzane do aplikacji. Z tego powodu bardzo istotnym aspektem aplikacji jest udostępnienie łatwego i intuicyjnego sposobu przekazywania danych. Zagadnienie to zostało uwzględnione na etapie projektowania. Zastosowana interaktywna mapa oparta na popularnej technologii GoogleMaps zapewnia prostotę obsługi i przejrzystość prezentacji danych. Również wykorzystywane w aplikacji formularze nie odbiegają od standardowych, powszechnie stosowanych rozwiązań. Zagadnienie zostało dokładniej opisane w rozdziale Interface.
Wprowadzane dane można podzielić na dane dotyczące zagrożeń oraz dane o użytkownikach systemu. Użytkownik samodzielnie przekazuje do systemu zarówno dane o zagrożeniach jak i dane dotyczące jego osoby.
Taki model gromadzenia informacji wymaga weryfikacji autentyczności danych. W tym celu został zaimplementowany algorytm oceny wiarygodności użytkownika. Każdemu użytkownikowi zostaje przypisany pewien zmienny współczynnik, na podstawie którego szacowana jest autentyczność wprowadzonych danych. Dokładna zasada działania systemu oceny wiarygodności danych opisana została w następnym rozdziale.
Ten parameter ma zasadnicze znaczenie przy wyliczaniu wiarygodności zdarzenia które dodał użytkownik, lub na nie zagłosował. Jest to bardzo ważna informacja, gdyż pozwala na oszacowanie prawdopodobieństwa, że dane w systemie o zagrożeniach są zgodne z rzeczywistością. Jednostka to procenty, zakres od 0 do 100. Przyjęto oznaczenie UTF (User Trust Factor) oraz następujące założenia:
Wiarygodność zwykłego użytkownika zarejestrowanego ulega zmianie za każdym razem, gdy zdarzenie które on dodał lub zagłosował na nie zostanie zatwierdzone bądź odrzucone przez administratora lub służby specjalne. Przyjęty wzór:
UTF = UTF + (100 - UTF) * 0.05 * EI * EI * UV * EA
Gdzie:
EI (Event Importance) – ważność zdarzenia (1, 2 lub 3)
EA (Event Accepted) – (1) gdy zdarzenie zostało zaakceptowane, (-1) gdy odrzucone
UV (User Vote) – (1) gdy użytkownik potwierdził zdarzenie, (-1) gdy zanegował
Taki wzór spełnia bardzo istotne warunki. Użytkownik, który zagłosował zgodnie z rzeczywistością staje się bardziej wiarygodny, a w przeciwnym przypadku bardziej podejrzany. UTF może spaść do zera (wtedy użytkownik jest usuwany z systemu), ale nie może osiągnąć 100%. Ważność zdarzenia na temat którego użytkownk wydał opinię ma bardzo duży wpływ na wynik działania tego wzoru.
Ten parametr pozwala oszacować jak bardzo prawdopodobne jest, że dane zdarzenie jest zgodne z rzeczywistością. Jest obliczany na podstawie wiarygodności użytkownika który dodał to zdarzenie, jak i tych, którzy na nie głosowali. Jednostka to procenty, zakres od 0 do 100. Przyjęto oznaczenie ETF (Event Trust Factor) oraz następujące założenia: Jeśli opinia o zdarzeniu pochodzi od administratora lub służby specjalnej, to automatycznie ETF = 100% Dla każdej opinii pochodzącej od normalnego użytkownika ETF jest modyfikowany według wzoru:
ETF = ETF + (100 - ETF) * UTF * UV / 100
Gdzie:
UV (User Vote) – (1) gdy użytkownik potwierdził zdarzenie, (-1) gdy zanegował
UTF (User Trust Factor) – wiarygodność użytkownika
Taki wzór spełnia bardzo istotne warunki. Każdy głos potwierdzający zdarzenie zwiększa jego wiarygodność – zależnie od wiarygodności użytkownika, ale zawsze zwiększa. Analogicznie dla głosów negujących. ETF może spaść do zera (wtedy zdarzenie jest usuwane z systemu), ale nie może osiągnąć 100%. Wiarygodność użytkownika ma bardzo duży wpływ na wynik działania tego wzoru.
Użytkownik korzysta z systemu poprzez przeglądarkę internetową. Po wejściu na odpowiednią stronę pojawia się główne okno aplikacji. W centralnej części znajduje się mapa regionu (domyślnie jest to Polska). Powyżej mapy znajduje się obszar logowania oraz rejestracji. Po lewej stronie umieszczony został panel umożliwiający filtrowanie wyświetlanych zdarzeń. Stronę startową przedstawia rys. 2.
Dodanie nowego punktu odbywa się poprzez znalezienie właściwego miejsca na mapie a następnie kliknięcie prawym przyciskiem myszy. Pojawia się wówczas menu kontekstowe przedstawione poniżej.
Menu mapy pozwala na zwiększenie i zmniejszenie przybliżenia oraz wyśrodkowanie mapy względem miejsca kliknięcia. Można również wyświetlić obszar szukania. Dodanie punktu odbywa się poprzez wybranie opcji ‘dodaj nowy punkt’, co jest równoważne z dodawaniem nowego zagrożenia. Wówczas na mapie pojawia się czerwona pinezka po kliknięciu (podwójnym) której pojawia się okno zawierające formularz. Formularz pozwala wpisać nazwę zdarzenia, określić kategorie z którymi jest związany, dodać opis zdarzenia oraz nadać priorytet. Dwa przyciski pod formularzem pozwalają zapisać bądź anulować zdarzenie. Opisany formularz przedstawia poniższy rysunek.
Po zapisaniu zdarzenia możliwe jest przeglądanie jego parametrów. Kliknięcie na pinezkę powoduje otworzenie się chmurki zawierającej wszystkie dostępne informacje. Użytkownikowi prezentowana jest informacja dotycząca autora, nazwy, opisu i ważności zagrożenia. Ponadto wypisane są typy kategorii określone dla zdarzenia oraz wyświetlany jest współczynnik zaufania.
W tym przypadku współczynnik zaufania wyniósł 0, ponieważ zagrożenie dodała osoba niezalogowana, czyli gość. Domyślnie, zdarzenie dodane przez niezalogowanego użytkownika jest niewidoczne, ale istnieje możliwość zmiany filtru powodująca wyświetlanie się również takich zdarzeń. Możliwość logowania istnieje jedynie dla zarejestrowanych osób. Rejestracja odbywa się poprzez kliknięcie przycisku w głównym oknie aplikacji, a następnie wypełnieniu formularza rejestracyjnego. Jest on przedstawiony na rysunku:
Po zaakceptowaniu formularza zostaje utworzone konto użytkownika. Zostaje wyświetlone okno powitalne i od tej chwili możliwe jest logowanie w systemie. Zalogowany użytkownik ma możliwość oceny zdarzeń przyciskami ‘plus’ i ‘minus’ oraz zgłaszania nadużyć.
Mechanizm dodawania nowych zagrożeń jest taki sam jak dla użytkownika niezalogowanego, jednak pojawia się możliwość edycji dodanych zdarzeń. Po kliknięciu przycisku ‘edytuj’ kolor pinezki zmienia się na zielony. Wówczas możliwe jest przeniesie punktu w inne miejsce na mapie oraz edycja danych zdarzenia.
Wyświetlanie zdarzeń można kontrolować poprzez nakładanie odpowiednich filtrów. Dostępne są trzy typy filtrów: względem współczynnika wiarygodności zdarzenia, względem współczynnika ważności zdarzenia i względem typów kategorii zdarzenia. Zastosowanie dwóch pierwszych filtrów polega na wybraniu dowolnych wartości z widocznych list rozwijanych. W przypadku trzeciego filtru, po kategoriach zdarzeń, należy najpierw wybrać kategorię zdarzenia. Spowoduje to wyświetlenie się kilku typów kategorii z możliwością zaznaczenia. W ten sposób zostaną wyświetlone zdarzenia związane jedynie z wybranymi typami kategorii.
Aplikacja oferuje również panel dla administratora, który umożliwia podgląd użytkowników oraz podgląd i edycję kategorii tagów dla zagrożeń. Panel administratora jest przedstawiony poniżej.
Administrator może również nadawać prawa do administrowania systemem innym użytkownikom. Może również nadać status służby porządkowej.
Podczas pracy nad projektem każdy z nas zapoznał się zasadą działania bazy danych PostgreSQL oraz kontenera serwletów Tomcat. Zaznajomiliśmy się ze środowiskiem programistycznym Eclipse EE oraz zdobyliśmy doświadczenie w projektowaniu serwisów internetowych i baz danych. Nie bez znaczenia jest również doświadczenie zdobyte podczas pracy zespołowej. Rozwiązywanie pojawiających się błędów często wymagało ścisłej współpracy.
Aplikacja w obecnym kształcie nie spełnia trendów „Web 2.0”, gdzie każdy większy serwis pozwala na tworzenie społeczności internetowej. W przypadku tego projektu udostępnienie użytkownikom takiej funkcjonalności byłoby bardzo korzystne. Wspólne dyskusje na forum publicznym umacniają społeczność skupioną wokół aplikacji oraz zwiększają zainteresowanie. Dlatego wartym przemyślenia do przyszłego rozwoju pomysłem byłoby stworzenie forum, systemu komentarzy czy też bardziej rozbudowanego profilu użytkownika.
Na chwilę obecną nie zaimplementowano systemu powiadamiania służb specjalnych o najistotniejszych zdarzeniach dotyczących tych służb. Mechanizm taki eliminowałby konieczność ręcznego przeglądania mapy przez odpowiednie służby.
Być może warto również zaimplementować możliwość przesyłania zdjęć dotyczących zagrożenia. Zdjęcia mogą stanowić dodatkową pomoc podczas identyfikacji zdarzenia dla odpowiednich służb. Ponadto, wraz z systemem komentarzy, mogą znacząco podnieść atrakcyjność serwisu.
