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