Dokumentacja architektury oprogramowania Lokalizator

Dokumentacja architektury oprogramowania
Lokalizator
Filip Borowiec, Wojciech Staszkiewicz, Jakub Sygnowski, Miłosz Świzdor
5 czerwca 2013
1
1.1
Wprowadzenie
Cele
Celem tego dokumentu jest przedstawienie architektury Lokalizatora GPS.
1.2
Zakres
Niniejszy dokument zawiera szczegółowy opis przyjętych rozwiązań architektonicznych, zarówno w mobi
webowej części Lokalizatora – oraz tych dotyczących komunikacji między obiema aplikacjami.
2
Prezentacja architektury
Aby dogłębnie zrozumieć architekturę Lokalizatora GPS, dokonano opisu z trzech różnych perspektyw:
końcowego, życia programu a także na poziomie interfejsu aplikacji.
3
Wygląd aplikacji
Użytkownicy będą mieli do dyspozycji dwa interfejsy. Pierwszy z nich pozwala sterować aplikacją na urząd
nym, a drugi umożliwia właścicielom kont zarządzanie z poziomu przeglądarki internetowej.
3.1
Interfejs urządzenia mobilnego
Po otworzeniu aplikacji, użytkownikowi ukaże się podstawowy widok (Rys. 1a). Składać się on będzie z na
zator’, pod którym będą przyciski i kontrolki. Pierwszy od góry znajdzie się przełacznik (on/off), który pozw
oraz wyłaczyć przesyłanie informacji o położeniu urządzenia. Obok przełącznika, znajdzie się przycisk ’N
1
Jego wciśnięcie spowoduje wysłanie informacji o zakończeniu trasy, jeśli byliśmy w trakcie rejestrowania i
nowej trasy, lub po prostu rozpoczęcie nowej trasy. Poniżej przełącznika i przycisku będzie znajdować s
informująca o stanie aplikacji. Kolor czerwony oznaczać będzie brak rejestrowania trasy. Kolor żółty będzie
o braku połączenia z internetem, przy założeniu rejestrowania trasy. Kolor zielony oznaczać będzie przesyłan
do serwera na bieżąco. Poniżej opisanej kontrolki, znajdować się będzie przycisk ’Ustawienia’. Jego wciś
powodować przejście do drugiego dostępnego widoku, właśnie widoku ustawień (Rys. 1b). Widok ten jest r
rzysty jak poprzedni. Na górze znajdować się będzie lista wyboru wartości, które opisują częstotliwość za
Poniżej znajdziemy podobny widget odpowiedzialny za częstość wysyłania danych do serwera. Na dole widok
przyciski ’Zapisz’ i ’Anuluj’, których działania opisywać nie trzeba. Pod przyciskiem ’Ustawienia’ znajdują
„Zrób zdjęcie” oraz „Wyślij zdjęcia”. Przycisk „Zrób zdjęcie” służy robienie zdjęć i zapisywaniu ich. Naciśnię
„Wyślij zdjęcia” powoduje próbę wysłania wszystkich zdjęć na serwer.
3.2
Interfejs webowy
Po udaniu się na stronę aplikacji użytkownik będzie musiał się zalogować. Logowanie będzie odbywało sie w
sposób, przez podanie loginu i hasła (Rys. 2a). Po udanej próbie logowania, użytkownik zostanie prz
widoku głównego (Rys. 2b). Schemat wyglądu strony głównej został już przedstawiony w poprzednim
W skrócie: główna strona składa się z paska nawigacyjnego po lewej stronie, w którym jest rozwijalna lis
od-do filtrowania trasy po czasie oraz przycisk ’zastosuj’ wykonujący zapytanie HTML (odświeżenie stro
wyświetlenie odpowiedniej trasy w danym przedziale czasu. Pod nim znajdują się informacje o trasie: łą
trasy, średnia prędkość, łączny czas trasy, liczba postojów. Po kliknięciu w pole od (lub do) wyskaku
umożliwiający wybranie daty. Korzysta on z jQueryUI.
Po prawej stronie u góry znajduje się krótki pasek wyświetlający login aktualnie zalogowanego użytkownika o
’wyloguj’ i ’ustawienia’. Poniżej znajduje się mapa (dostaraczana przez Google Maps) z zaznaczoną trasą.
punkty są zaznaczone markerami, a te, którym odpowiada zdjęcie są zaznaczone aparatem, po kliknięciu na
się pojawia. Po kliknięciu w przycisk ustawienia zostaniemy przeniesieni do widoku ustawień (Rys. 2c). P
jest możliwość wyboru koloru reprezentacji trasy na mapie oraz rodzaju mapy. Dostępne rodzaje mapy to
oraz Satelite. Poniżej znajdziemy przyciski ’Zapisz’ oraz ’Anuluj’.
4
4.1
Cykl życia aplikacji
Serwer WWW
Serwer WWW jest ustawiony na serwerze students, korzysta z Django (w wersji, jaka jest dostępna na student
1.4.0).
4.2
Aplikacja mobilna
Aplikacja po uruchomieniu przez użytkownika odbiera od niego dane do logowania do serwisu. Następnie, p
przycisku ’ON’ rozpoczyna zbieranie danych z GPSa. Dane zbierane są nie częściej niż co określoną w ustaw
czasu. Analogicznie, co ustalony okres czasu sprawdzany jest stan sieci GPRS i jeśli sieć jest dostępna, z
2
wysyłane są do serwera. Aktualny stan aplikacji jest sygnalizowany diodą (zgodnie z opisem w poprzednim d
wymagań funkcjonalnych). Po zamknięciu aplikacji kontynuuje ona swoje działanie (odpytywanie GPSa, ma
danych i wysyłanie ich do serwisu WWW) w tle. Aplikacja umożliwia robienie zdjęć i zbiorowe wysy
pośrednictwem internetu, na serwer.
5
5.1
Komunikacja
Aplikacja mobilna z GPSem, GPRSem/WiFi
Aplikacja mobilna będzie wykonywać zapytania do systemu GPS oraz GPRS zgodne z API dostarczanym pr
http://developer.android.com/reference/android/location/LocationListener.html
5.2
Aplikacja mobilna z serwerem
W celu komunikacji aplikacji mobilnej z serwerem WWW wykorzystywany jest protokół HTTP. Konkretnie
(na adres: students.mimuw.edu.pl:44445/submit/) wykonywane jest zapytanie POST zawierające dane w for
Format danych opisuje schemat:
{\textquotedbl{}positions\textquotedbl{}:{[}{\textquotedbl{}longtitude\textquotedbl{}:20.
\textquotedbl{}passwd\textquotedbl{}:\textquotedbl{}?\textquotedbl{},\textquotedbl{}login\
\textquotedbl{}photo\textquotedbl{}:imgData, \textquotedbl{}time\textquotedbl{}:123123,
\textquotedbl{}route\textquotedbl{}:\textquotedbl{}nazwa\textquotedbl{}}
Pole photo i time są nieobowiązkowe; jeśli przesłany komunikat je zawiera, to aplikacja dołącza zdjęcie do
w czasie punktu na trasie. Serwer po odebraniu i sparsowaniu danych odsyła do urządzenia krótki komunik
6
6.1
Inne
Dostępność
Serwer dostępny wtedy, gdy działa students. Jak nie działa - to nie zbiera danych i dane giną.
6.2
Niezawodność, dokładność
Dokładność zaznaczonej trasy jest zależna od dostępności i dokładności sygnału GPS.
6.3
Obsługa błędów
W przypadku błędu w aplikacji mobilnej uruchomi się ona ponownie.
3
6.4
Bezpieczeństwo
Dane pomiędzy aplikacją mobilną a serwerem będą przesyłane nieszyfrowane. Wśród nich będzie znajdował
pobrane przez urządzenie oraz login i hasło użytkownika (szczegóły - sekcja komunikacja). Hasło będzie p
zakodowaniu za pomocą hasza md5.
4