Raport końcowy
Transkrypt
Raport końcowy
INDECT. Projekt i implementacja prototypu systemu GIS dla akwizycji, wizualizacji i przetwarzania wiedzy o zagrożeniach. Bazy danych i systemy zarządzania bazami Kamil Papp: [email protected] Marcin Polak: [email protected] Mariusz Reichert: [email protected] Automatyka i Robotyka, 4 rok Wydział Elektroniki, Automatyki, Informatyki i Elektroniki Akademia Górniczo-Hutnicza w Krakowie 23 marca 2010 1 Projekt konceptualny 1.1 Sformułowanie zadania projektowego Celem projektu jest stworzenie serwisu internetowego służącego do akwizycji, wizualizacji i przetwarzania wiedzy o zagrożeniach na terenie Krakowa. Głównym zadaniem jest stworzenie prostej w obsłudze, a jednocześnie oferująca bogata funkcjonalność aplikacji. System zapewni odpowiednio skategoryzowane i opisanie informacji o zagrożeniach oraz mechanizmy służące do ich łatwego przeglądu i analizy. 1.2 Analiza stanu wyjściowego Nie istnieje w internecie polski odpowiednik systemu, który umożliwiałby przewidywana przez nas funkcjonalność. Istnieją natomiast anglojęzyczne serwisy charakteryzujące się możliwościami podobnymi do tych zawartych w naszej koncepcji serwisu. Najważniejsze z nich to: • http://www.crimemapping.com/ – serwis wspomagający agencje rządowe z USA w dostarczaniu społeczeństwu cennych informacji na temat bieżących zagrożeń w ich najbliższej okolicy. Celem serwisu jest asystowanie departamentom policji w redukowaniu przestępstw dzięki lepiej poinformowanym obywatelom. Serwis użytkownikom niezalogowanym umożliwia przeglądanie mapy z zagrożeniami, natomiast zalogowanym oferuje dodatkowo możliwość informowania o interesujących ich zagrożeniach za pomocą maili. Użytkownicy nie mogą zgłaszać zagrożeń, gdyż są one wprowadzane przez agencje rządowe, 1 • http://www.crimemapper.co.uk/ – prosta aplikacja webowa, która umożliwia obywatelom dostęp do informacji na temat poziomu przestępstwa w ich sąsiedztwie. Zwykli użytkownicy nie maja możliwości logowania się do serwisu. Informacje o poziomie przestępstw są zapewniane przez 43 odziały policji z Anglii i Walii, • http://www.crimereports.com/ – jest największym internetowym źródłem dokładnych i aktualnych informacji o przestępstwach. Crime Reports współpracuje z ponad sześciuset agencjami wspierania prawa (np. policja) z USA oraz Kanady. Oferuje im niedrogie, łatwe w użytkowaniu oprogramowanie. Umożliwia ono zrozumienie tendencji przestępczych oraz dzielenie się z społeczeństwem aktualnymi danymi na temat przestępczości. Użytkownicy mogą oglądać mapę zagrożeń, a po zalogowaniu się, otrzymują za darmo mailem wybrane przez siebie informacje na temat przestępstw. Nie mogą zgłaszać własnych zagrożeń. Jak widać z przeprowadzonej analizy istniejących serwisów, nie umożliwiają one zalogowanym użytkownikom zgłaszanie informacji o zagrożeniach. W naszym systemie głównym problemem będzie stworzenie mechanizmu odpowiadającego za weryfikacje prawdziwości zgłaszanych informacji. Mechanizm ten będzie oparty o system rankingowy wiarygodności użytkowników oraz weryfikacje informacji przez osoby związane z rożnego rodzaju centrami kryzysowymi. 1.3 Analiza wymagań użytkownika W naszym projekcie reprezentowane będą następujące cztery typy użytkowników: • niezalogowani – przeglądanie zagrożeń na mapie, proste wyszukiwanie zagrożeń, czytanie komentarzy na temat zagrożeń, • zalogowani – te same możliwości co użytkownik niezalogowany oraz dodatkowo: edycja swojego konta, dodawanie zagrożeń, ocenianie wiarygodności zagrożeń, dodawanie komentarzy, zgłaszanie nadużyć, głosowanie, dodawanie zdjęcia, zaawansowane wyszukiwanie zagrożeń (kryteria wyszukiwanie takie jak: ograniczone do obszaru, w danym horyzoncie czasowym, stopnia zagrożenia itd.), przeglądanie statystyk, zdefiniowanie obszaru monitorowania, zaznaczenie zagrożenia do monitorowania, • moderator – te same możliwości co użytkownik zalogowany oraz dodatkowo: edycja zagrożeń czyli zmiana czynnika określającego prawdziwość zagrożenia, zgłaszanie zagrożeń do usunięcia, czytanie raportów, edycja komentarzy, • administrator – te same możliwości co użytkownik zalogowany oraz dodatkowo: usuwanie zagrożeń, zarządzenie kontami użytkowników, usuwanie nieprawidłowości, tworzenie raportów. 1.4 Scenariusze użycia • Użytkownik niezalogowany: rejestracja, zalogowanie, przeglądanie mapy zagrożeń, przeglądanie informacji o zagrożeniach, wyszukanie zagrożenia według kryterium: stopień niebezpieczeństwa, rodzaj zagrożenia, czytanie komentarzy. • Użytkownik zalogowany: przeglądanie mapy zagrożeń, przeglądanie informacji o zagrożeniach, czytanie i edycja komentarzy, wyszukanie zagrożenia według kryterium: stopień niebezpieczeństwa, rodzaj zagrożenia, w podanym obszarze, w podanym horyzoncie czasowym, zgłoszenie nadużycia, 2 edycja swojego konta, opiniowanie zagrożeń, dodanie zagrożenia, dodawanie/usuwanie/edycja obszarów monitorowania zagrożeń, dodawanie/usuwanie/edycja zagrożeń do monitorowania, przeglądanie statystyk, głosowanie, dodawanie zdjęć. • Moderator: zmiana czynnika określającego prawdziwość zagrożenia, zgłoszenie zagrożenia do osunięcia, edycja komentarzy. • Administrator: usuniecie zagrożenia, usuniecie konta, sprawdzenie i usuniecie nieprawidłowości, definiowanie/usuwanie raportów. 1.5 Identyfikacja funkcji • Rejestracja oraz potwierdzenie rejestracji, • Logowanie, wylogowanie z serwisu, • Przeglądanie mapy, • Przeglądanie informacji o zagrożeniach, wyszukiwanie zagrożeń, usuwanie zagrożenia, • Zgłoszenie nadużycia, • Edytowanie komentarzy, • Edytowanie, usuwanie konta, • Dodawanie zdjęć, • Dodawanie zagrożenia, • Opiniowanie zagrożenia, • Przeglądanie statystyk, • Dodawanie, usuwanie, edytowanie obszaru monitorowania zagrożeń, • Dodawanie, usuwanie, edytowanie zagrożenia do monitorowania, • Zgłaszanie zagrożenia do usunięcia, • Określanie stopnia prawdziwości zagrożenia, • Definiuj/usuń raport, • Obsługa nieprawidlowości. 3 1.6 FHD — diagramy hierarchii funkcji Rysunek 1: Hierarchia funkcji projektowanej aplikacji 4 1.7 DFD — diagramy przepływu danych Rysunek 2: Diagram kontekstowy Rysunek 3: Diagram systemowy 5 Rysunek 4: Diagram szczegółowy 1.8 Encje i atrybuty • groups – groups id, group name, • languages – languages id, languages name, • area alerts – area alerts id, users id, description, sms, im, email, area, created at, updated at, • users – users id, groups id, languages id, phone, im, email, nickname, rank, gender, hashed password, salt, avatar, • threat alerts – threat alerts id, users id, threats id, description, sms, im, email, created at, updated at, • notifications – notifications id, users id, threats id, notified at, description, • comments – comments id, threats id, users id, description, created at, updated at, • threats – threats id, threat types id, description, rank, plus, minus, extra plus, extra minus, place, created at, updated at, • pictures – pictures id, users id, threats id, name, description, file, created at, • threat types – threat types id, threat name. 6 1.9 ERD — diagramy związków encji Rysunek 5: Diagram związków encji 7 1.10 STD — diagramy przejść pomiędzy stanami Rysunek 6: Diagram przejść pomiędzy stanami 8 2 Projekt logiczny 2.1 Projekt tabel, kluczy, powiązań miedzy tabelami w języku SQL Poniższy kod tworzy tabele występujące w naszym projekcie, jednakże dzięki zaimplementowaniu serwisu w frameworku Ruby on Rails nie istnieje potrzeba tworzenia schematu tabel w języku SQL, gdyż piszemy go w języku Ruby. Najpierw jednak przedstawimy kod w języku SQL, potem w języku Ruby. Dzięki konwencją stosowanym w frameworku Ruby on Rails kod jest znaczenie krótszy, np. jedną z konwencji jest automatycznie generowany klucz główny, a co ważniejsze kod aplikacji jest niezależny od bazy danych: • Tabela groups. SQL CREATE TABLE "groups"( "groups_id" Serial NOT NULL, "group_name" Character varying(100) NOT NULL, PRIMARY KEY ("groups_id") ); Ruby create_table :groups do |t| t.string :group_name, :null => false, :default => "", :limit => 100 end • Tabela users. SQL CREATE TABLE "users"( "users_id" Serial NOT NULL, "groups_id" Integer NOT NULL, "languages_id" Integer NOT NULL, "phone" Character varying(100) NOT NULL, "im" Character varying(100) NOT NULL, "nickname" Character varying(100) NOT NULL, "email" Character varying(100) NOT NULL, "rank" Integer DEFAULT 0 NOT NULL, "gender" Character varying(256) DEFAULT Men NOT NULL, "hashed_password" Character varying(256) NOT NULL, "salt" Character varying(256) NOT NULL, "avatar" Bytea, "timestamps" Timestamp, PRIMARY KEY ("users_id") ); ALTER TABLE "users" ADD CONSTRAINT "Relationship1" FOREIGN KEY ("groups_id") REFERENCES "groups" ("groups_id") ON DELETE NO ACTION ON UPDATE NO ACTION; 9 ALTER TABLE "users" ADD CONSTRAINT "Relationship2" FOREIGN KEY ("languages_id") REFERENCES "languages" ("languages_id") ON DELETE NO ACTION ON UPDATE NO ACTION; Ruby create_table :users do |t| t.string :phone, :im, :nickname, :email, :null => false, :default => "", :limit => 100 t.integer :rank, :null => false, :default => 0 t.references :language, :null => false, :default => 1 t.references :group, :null => false, :default => 3 t.binary :avatar, :null => true t.string :gender, :default => "Men" t.string :hashed_password, :salt , :null => false t.timestamps end • Tabela languages. SQL CREATE TABLE "languages"( "languages_id" Serial NOT NULL, "languages_name" Character varying(100) NOT NULL, PRIMARY KEY ("languages_id") ); Ruby create_table :languages do |t| t.string :language_name, :null => false, :default => "", :limit => 100 end • Tabela threats. SQL CREATE TABLE "threats"( "threats_id" Serial NOT NULL, "threat_types_id" Integer NOT NULL, "description" Text NOT NULL, "rank" Integer DEFAULT 0 NOT NULL, "plus" Integer DEFAULT 0 NOT NULL, "minus" Integer DEFAULT 0 NOT NULL, "extra_plus" Integer DEFAULT 0 NOT NULL, "extra_minus" Integer DEFAULT 0 NOT NULL, "place" Point NOT NULL, "created_at" Timestamp NOT NULL, "updated_at" Timestamp NOT NULL, 10 PRIMARY KEY ("threats_id") ); ALTER TABLE "threats" ADD CONSTRAINT "Relationship3" FOREIGN KEY ("threat_types_id") REFERENCES "threat_types" ("threat_types_id") ON DELETE NO ACTION ON UPDATE NO ACTION; Ruby create_table :threats do |t| t.text :description, :null => false, :default => "" t.integer :rank, :plus, :minus, :extra_plus, :extra_minus, :null => false, :default => 0 t.references :threat_type, :null => false t.point :place, :null => false t.timestamps end • Tabela threat types. SQL CREATE TABLE "threat_types"( "threat_types_id" Serial NOT NULL, "threat_name" Character varying(100) NOT NULL, PRIMARY KEY ("threat_types_id") ); Ruby create_table :threat_types do |t| t.string :threat_name, :null => false, :default => "", :limit => 100 end • Tabela comments. SQL CREATE TABLE "comments"( "comments_id" Serial NOT NULL, "threats_id" Integer NOT NULL, "users_id" Integer NOT NULL, "desciption" Text NOT NULL, "created_at" Timestamp NOT NULL, "updated_at" Timestamp NOT NULL, PRIMARY KEY ("comments_id") ); ALTER TABLE "comments" ADD CONSTRAINT "Relationship4" FOREIGN KEY ("threats_id") 11 REFERENCES "threats" ("threats_id") ON DELETE NO ACTION ON UPDATE NO ACTION; ALTER TABLE "comments" ADD CONSTRAINT "Relationship5" FOREIGN KEY ("users_id") REFERENCES "users" ("users_id") ON DELETE NO ACTION ON UPDATE NO ACTION; Ruby create_table :comments do |t| t.text :description, :null => false, :default => "" t.references :user, :threat, :null => false t.timestamps end • Tabela notifications. SQL CREATE TABLE "notifications"( "notifications_id" Serial NOT NULL, "users_id" Integer NOT NULL, "threats_id" Integer NOT NULL, "notified_at" Timestamp NOT NULL, "description" Text NOT NULL, PRIMARY KEY ("notifications_id") ); ALTER TABLE "notifications" ADD CONSTRAINT "Relationship9" FOREIGN KEY ("users_id") REFERENCES "users" ("users_id") ON DELETE NO ACTION ON UPDATE NO ACTION; ALTER TABLE "notifications" ADD CONSTRAINT "Relationship10" FOREIGN KEY ("threats_id") REFERENCES "threats" ("threats_id") ON DELETE NO ACTION ON UPDATE NO ACTION; Ruby create_table :notifications do |t| t.references :user, :threat, :null => false t.datetime :notified_at, :accepted_at, :null => false t.text :description, :null => false, :default => "" end 12 • Tabela pictures. SQL CREATE TABLE "pictures"( "pictures_id" Serial NOT NULL, "users_id" Integer NOT NULL, "threats_id" Integer NOT NULL, "name" Character varying(100) NOT NULL, "description" Text NOT NULL, "file" Bytea NOT NULL, "created_at" Timestamp NOT NULL, PRIMARY KEY ("pictures_id") ); ALTER TABLE "pictures" ADD CONSTRAINT "Relationship6" FOREIGN KEY ("users_id") REFERENCES "users" ("users_id") ON DELETE NO ACTION ON UPDATE NO ACTION; ALTER TABLE "pictures" ADD CONSTRAINT "Relationship7" FOREIGN KEY ("threats_id") REFERENCES "threats" ("threats_id") ON DELETE NO ACTION ON UPDATE NO ACTION; Ruby create_table :pictures do |t| t.string :name, :null => false, :default => "", :limit => 100 t.text :description, :null => false, :default => "" t.references :user, :threat, :null => false t.binary :file, :null => false t.datetime :created_at, :null => false end • Tabela area alerts. SQL CREATE TABLE "area_alerts"( "area_alerts_id" Serial NOT NULL, "users_id" Integer NOT NULL, "description" Text NOT NULL, "sms" Boolean DEFAULT true NOT NULL, "im" Boolean DEFAULT true NOT NULL, "email" Boolean DEFAULT true NOT NULL, "area" Polygon NOT NULL, "created_at" Timestamp NOT NULL, "updated_at" Timestamp NOT NULL, PRIMARY KEY ("area_alerts_id") ); 13 ALTER TABLE "area_alerts" ADD CONSTRAINT "Relationship11" FOREIGN KEY ("users_id") REFERENCES "users" ("users_id") ON DELETE NO ACTION ON UPDATE NO ACTION; Ruby create_table :area_alerts do |t| t.references :user, :null => false t.text :description, :null => false, :default => "" t.boolean :sms, :im, :email, :null => false, :default => true t.polygon :area, :null => false t.timestamps end • Tabela threat alerts. SQL CREATE TABLE "threat_alerts"( "threat_alerts_id" Serial NOT NULL, "users_id" Integer NOT NULL, "threats_id" Integer NOT NULL, "description" Text NOT NULL, "sms" Boolean DEFAULT true NOT NULL, "im" Boolean DEFAULT true NOT NULL, "email" Boolean DEFAULT true NOT NULL, "created_at" Timestamp NOT NULL, "updated_at" Timestamp NOT NULL, PRIMARY KEY ("threat_alerts_id") ); ALTER TABLE "threat_alerts" ADD CONSTRAINT "Relationship15" FOREIGN KEY ("threats_id") REFERENCES "threats" ("threats_id") ON DELETE NO ACTION ON UPDATE NO ACTION; ALTER TABLE "threat_alerts" ADD CONSTRAINT "Relationship16" FOREIGN KEY ("users_id") REFERENCES "users" ("users_id") ON DELETE NO ACTION ON UPDATE NO ACTION; Ruby create_table :threat_alerts do |t| t.references :user, :threat, :null => false t.text :description, :null => false, :default => "" t.boolean :sms, :im, :email, :null => false, :default => true t.timestamps end 14 2.2 Słownik Danych W projekcie wykorzystano trzy tablice słownikowe: • groups – tabela zawierająca dostępne grupy, • languages – tabela zawierająca dostępne języki, • threat types – tabela zawierająca dostępne typy zagrożeń. 2.3 Analiza zależności funkcyjnych i normalizacja tabel Po dokonaniu analizy schematu tabel zauważyliśmy, że nasza baza danych spełnia trzecią postać normalną, gdyż wszystkie atrybuty kluczowe są zależne bezpośrednio od wszystkich kluczy. 2.4 Denormalizacja struktury tabeli W naszym projekcie nie przewidujemy denormalizacji. 2.5 Projektowanie operacji na danych - zdefiniowanie kwerend Podobnie jak w przypadku projektowania schematów tabel, zapytania w naszej aplikacji będą wykonywane z poziomu języka Ruby, dlatego przytoczymy jedynie przykład zapytania w języku SQL oraz w języku Ruby (przykład zapytania zwracającego komentarze danego użytkownika): SQL SELECT komentarz.tresc FROM komentarz WHERE komentarz.id_uzytkownik=id_szukanego; Ruby query=Komentarz.find :all, :select=>"tresc", :conditions=>["id_uzytkownik=?", id_szukanego] 15 3 Raport końcowy 3.1 Zdefiniowanie interfejsów do prezentacji, edycji i obsługi danych • Użytkownik niezalogowany. Interfejs użytkownika niezalogowanego pozwala na przeglądanie zagrożeń naniesionych na mapę oraz proste wyszukiwanie zagrożeń według rodzaju lub stopnia zagrożenia. Dostęp do większej funkcjonalności uzyskać może poprzez dokonanie procesu rejestracji. Proces rejestracji pozwala na natychmiastowe utworzenie konta. • Użytkownik zalogowany. Użytkownik po zalogowaniu otrzymuje dostęp do wszystkich funkcjonalności użytkownika niezalogowanego. Uzyskuje możliwość administracji swoim kontem, poprzez możliwość obejrzenia swoich danych wprowadzonych podczas rejestracji. Rozbudowana została możliwość wyszukiwania o przeszukiwanie zagrożeń względem horyzontu czasowego. Użytkownik dysponuje możliwością ręcznego dodania zagrożenia. • Moderator. Prototyp interfejsu moderatora zawiera wszystkie funkcjonalności użytkownika zalogowanego. • Administrator. Administrator otrzymuje, oprócz wszystkich wymienionych wcześniej funkcjonalności, możliwości zarządzania kontami użytkowników. Dysponuje narzędziem do przeglądania wszystkich założonych kont, oraz możliwością ich manualnego założenia oraz usunięcia. Administrator może dokonać usunięcia zagrożenia. Rysunek 7: Panel administratora 3.2 Zdefiniowanie panelu sterowania aplikacji Panel sterowania aplikacją jest w zasadzie zgodny z interfejsami wszystkich użytkowników (zalogowanego, moderatora oraz administratora). Patrząc pod kątem aplikacji potrzebne funkcje wyszczególnione w diagramie STD zostały ujętne w panelach użytkownika zalogowanego, moderatora oraz administratora. 16 Rysunek 8: Dane użytkownika 3.3 Uruchamianie i testowanie aplikacji Aplikacja uruchamiana i testowana jest na serwerze lokalnym. Podczas procesu testowaniu uwzględniliśmy: • rejestrację użytkowników, • logowanie / wylogowanie użykowników, • dodawanie i usuwanie zagrożeń, • przeglądanie zagrożeń, • wyszukiwanie zagrożeń, • obsługę kont użykowników. 3.4 Wprowadzanie danych Dane w postaci mapy Krakowa wprowadzane sa on-line przy pomocy API do google - maps. Znajdują się one na zewnętrznych serwerach należących do Google. Ręcznie wprowadzane są dane opisujące zagrożenia. Proces rejestracji użytkownika odbywa się w dwojaki sposób. Administrator dysponuje możliwością recznego założenia konta. Dodatkowo każdy niezalogowany użytkownik ma możliwość automatycznej rejestracji. 3.5 Wdrażanie systemu do użytkowania W obecnej chwili projektu jest na etapie ”development”, wymaga wdrożenia po pełnym ukończeniu. Projekt tworzony jest etapami: 17 Rysunek 9: Spis użytkowników Rysunek 10: Spis zagrożeń 18 • Utworzenie i konfiguracja bazy danych PostgreSQL i PostGIS, konfiguracja połączenia z Ruby, • Tworzenie szkieletu aplikacji w Ruby on Rails, • Tworzenie migracji bazodanowej w Ruby on Rails, • Implementacja aplikacji w architekturze MVC (Model-View-Controller), – Model – opisuje dane i logikę programu, – Widok – wyświetla dane przechowywane w modelu, – Kontroler – przekształca żądania użytkownika na żądania zrozumiałe dla modelu. Rysunek 11: Schemat Model-Widok-Kontroler 3.6 Przeprowadzenie szkolenia użytkowników W celu użytkowania serwisu konieczne jest zapoznanie się z metodami: • Rejestracji – rejestracja dokonywana jest za pomocą wybrania opcji ”sign in”dostępnej w menu aplikacji. Po wypełnieniu i zatwierdzeniu formularza utworzone zostaje konto użytkownika, • Przeglądania punktów – przeglądanie punktów dostępne jest na ekranie głównym aplikacji. Użytkownik po naciśnięciu na znajdujacy się na mapie punkt uzyskuje informacje dotyczące zagrożenia, • Obsługi wyszukiwania – wyszukiwanie dostępne jest z menu ”search”. Następnie użytkownik może wybrać cechy interesujących go zagrożeń, które zostaną wyświetlone na mapie, • Dodawawania punktów – dodawnie punktu odbywa się poprzez menu ”threat”i opcję ”create threat”. Użytkownik po podaniu danych opisujących zagrożenie dokonuje potwierdzenia. Plik dodawany jest automatycznie do bazy danych. 19 Rysunek 12: Rejestracja użytkownika Rysunek 13: Podgląd zagrożenia 20 Rysunek 14: Wyszukiwanie zagrożeń Rysunek 15: Dodawanie zagrożenia 21 3.7 Zapewnienie dokumentacji technicznej i użytkowej Rolę dokumentacji technicznej pełni czytany właśnie raport końcowy. Składa się on z trzech części, będący rówocześnie poszczególnymi etapami realizacji projektu: • Projekt konceptualny, • Projekt logiczny, • Raport końcowy, Dodatkowo informacje zawarte w raporcie zostały zamieszczone w systemie wiki. 3.8 Rozwijanie i modyfikowanie aplikacji W projekcie zaimplementowano szkielet kompletnego portalu społecznościowego opartego o diagram hierarchi funkcji. W celu uzyskania pełnej zakładanej funkcjonalności należy dokonać utworzenia ciała funkcji realizujących: • obsługa komentarzy, czyli dodawanie, przeglądanie oraz moderowanie komentarzy, • statystyki, czyli tworzenie oraz zarządzanie raportami, • mechanizm głosowania, oparty o wiarygodność użytkowników system potwierdzający prawdziwość zagrożeń, • obsługę zdjęć, • możliwość edycji danych użytkownika, • wyszukiwanie zagrożeń po obszarze. Po dokonaniu tego procesu należy dokonać wdrożenia systemu opisane w wcześniejszych rozdziałach. Panel sterowania aplikacji wymaga uzupełnienia działów: • about – informacje o projekcie, • contact – dane kontaktowe, • faq – instrukcja obsługi serwisu, • privacy – warunki użytkowania aplikacji. Również istotną rzeczą jest dodanie obsługi wielojęzykowości. W obecnej chwili aplikacja stworzona jest jedynie z myślą o użytkownikach dysponujących podstawową znajomością języka angielskiego. W kwestii technicznej istnieje możliwość ukierunkowania serwisu w stronę technologii Ajax, która mogłaby być jeszcze mocniej wykorzystywana w celu ułatwienia obsługi systemu przez użytkownika. Dodatkowo proces rejestracji należy wyposażyć w system potwierdzenia dokonania rejestracji przez konkretnego użytkownika. Można zrealizować to poprzez wysyłanie wiadomości e-mail weryfikującej prawdziwość podanej poczty elektronicznej. 22 3.9 Opracowanie doświadczeń wynikających z realizacji projektu Całkowity czas realizacji prototypu wyniósł 5 miesięcy. W początkowej fazie projektu związany był on z potrzebą zapoznania się z wiedzą teoretyczną dotyczącą realizowanego zagadnienia. Po dokonaniu wyboru technologii kolejny okres czasu został przeznaczony na dogłębne zapoznanie się z wybranymi narzędziami. Najdłuższy okres czasu został poświęcony na realizację właściwej aplikacji. Koszty projektu były zerowe. Wynika to z dużej dostępności materiałów pomocnicznych na darmowych serwisach. Niestety, brak opłat za korzystanie z materiałów często odbijał się na jakości prezentowanych rozwiązań. Podczas realizacji aplikacji bardzo często zmuszeni byliśmy do przywracania starszych wersji projektów. Spowodowane to było faktem, że część rozwiązań działała w sposób odmienny niż prezentowano to w materiałach dydaktycznych. W przypadku wdrożenia systemu do czasu realizacji projektu należałoby dodać czas potrzebny na przeprowadzenie dogłębnych testów aplikacji na serwerze globalnym, przy znacznym obciążeniu ze strony użytkowników. W przypadku zrealizowanego prototypu dokonano jedynie testów na serwerach lokalnych. 3.10 Użyte technologie Projekt został oparty o następujące technologie: • PostgreSQL - system zarządzania relacyjnymi bazami danych. Zastosowany do utworzenia bazy danych i przetrzymywania informacji koniecznych do funkcjonowania systemu, • Ruby on Rails - framework służący do tworzenia aplikacji webowych. Wykorzystywany w celu obsługi bazy danych oraz tworzeniu strony internetowej, • Google Maps Api -biblioteki firmy Google służące do prezentacji zagrożeń na mapie Krakowa, • JavaScript - biblioteki wykorzystywane w celu zapewnienia interakcji z użytkownikiem oraz obsługę zdarzeń, • Scriptacoulos -biblioteka programistyczna JavaScript oparta na Prototype JavaScript Framework. Zastosowany w celu uzyskania animacji interfejsu oraz wykorzystania elementów opartych na obiektowym modelu dokumentu. 3.11 Wykaz literatury • http://www.indect-project.eu/ - Projektu INDECT • http://postgis.refractions.net/ - PostGIS • http://code.google.com/apis/maps/ - Google Maps API • http://www.postgresql.org/ - PostgreSQL • http://rubyonrails.org/ - Ruby on Rails 23