ˇ ENI´ TECHNICKE´ V BRNEˇ VYSOKE´ UC BRNO UNIVERSITY OF TECHNOLOGY
ˇ NI´CH TECHNOLOGII´ FAKULTA INFORMAC ˚ ´ STAV INTELIGENTNI´CH SYSTE´MU U FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INTELLIGENT SYSTEMS
´ VA VOZIDEL ZA POMOCI MOBILNI´HO SPRA TELEFONU S GPS
ˇ SKA´ PRA´CE ´R BAKALA BACHELOR’S THESIS
AUTOR PRA´CE AUTHOR
BRNO 2012
PATRIK POMPE
ˇ ENI´ TECHNICKE´ V BRNEˇ VYSOKE´ UC BRNO UNIVERSITY OF TECHNOLOGY
ˇ NI´CH TECHNOLOGII´ FAKULTA INFORMAC ˚ ´ STAV INTELIGENTNI´CH SYSTE´MU U FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INTELLIGENT SYSTEMS
´ VA VOZIDEL ZA POMOCI MOBILNI´HO SPRA TELEFONU S GPS THESIS TITLE
ˇ SKA´ PRA´CE ´R BAKALA BACHELOR’S THESIS
AUTOR PRA´CE
PATRIK POMPE
AUTHOR
VEDOUCI´ PRA´CE SUPERVISOR
BRNO 2012
ˇ EK ´C Ing. JAN HORA
Abstrakt Tato práce se zabývá získáváním informací z chytrého mobilního telefonu pro využití v aplikaci typu kniha jízd. Nejprve specifikuje a analyzuje požadavky na takovou aplikaci, poté se zabývá možnostmi její realizace. Popisuje implementaci zvoleného řešení, které se skládá ze tří částí – aplikace pro telefon na platformě Android, která sbírá potřebné informace o trasách vozidel, webového portálu, který poskytuje rozhraní pro zobrazení a správu získaných dat a webových služeb pro zajištění komunikace předchozích dvou částí. Vzniklou aplikaci následně srovnává s existujícími podobnými projekty.
Abstract This thesis deals with the possibilities of using information obtained from smart-phones for applications such as driver’s logbook. Firstly, the specification and analysis of requirements for such applications and then explore the possibility for its realization. Further, it describes the implementation of the solution, which consist of three parts – Applications for the Android phone platform, which collects the necessary information about the routes taken by the vehicle, web portal that provides an interface for viewing and managing the obtained data and a web service for communication between the previous two parts. The final application is then compared with existing projects, which are similar to this one.
Klíčová slova kniha jízd, Android, webové služby, Kohana, PHP, mapy, klient, server, REST, chytrý telefon
Keywords driver’s logbook, Android, web services, Kohana, PHP, maps, framework, client, server, REST, smart-phone
Citace Patrik Pompe: Správa vozidel za pomoci mobilního telefonu s GPS, bakalářská práce, Brno, FIT VUT v Brně, 2012
Správa vozidel za pomoci mobilního telefonu s GPS Prohlášení Prohlašuji, že jsem tuto bakalářskou práci vypracoval samostatně pod vedením pana Ing. Jana Horáčka. Uvedl jsem všechny literární prameny a publikace, ze kterých jsem čerpal. ....................... Patrik Pompe 16. května 2012
c Patrik Pompe, 2012.
Tato práce vznikla jako školní dílo na Vysokém učení technickém v Brně, Fakultě informačních technologií. Práce je chráněna autorským zákonem a její užití bez udělení oprávnění autorem je nezákonné, s výjimkou zákonem definovaných případů.
Obsah 1 Specifikace a analýza požadavků 1.1 Požadavky na aplikaci typu klient . . . . . . . . . . . . . . . . . . . . . . . 1.2 Požadavky na aplikaci typu server . . . . . . . . . . . . . . . . . . . . . . . 1.3 Bezpečnostní požadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 4 4 5
2 Analýza možností realizace 2.1 Klient . . . . . . . . . . . . . . . . . . 2.1.1 Android . . . . . . . . . . . . . 2.1.2 Vývojové prostředky . . . . . . 2.1.3 Komponenty Android aplikace 2.2 Server . . . . . . . . . . . . . . . . . . 2.2.1 Framework Kohana . . . . . . 2.3 Webové služby . . . . . . . . . . . . . 2.3.1 XML-RPC . . . . . . . . . . . 2.3.2 SOAP . . . . . . . . . . . . . . 2.3.3 REST . . . . . . . . . . . . . . 2.4 Mapové podklady . . . . . . . . . . . . 2.4.1 Regionální poskytovatelé . . . 2.4.2 Google Maps a OpenStreetMap
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
6 6 6 7 8 8 9 12 13 13 13 14 15 15
3 Návrh systému 3.1 Serverová část . . . . . . . . . . . . 3.1.1 Databázový model . . . . . 3.1.2 Administrační rozhraní . . 3.1.3 Grafické uživatelké rozhraní 3.1.4 Případy použití . . . . . . . 3.2 Klient . . . . . . . . . . . . . . . . 3.2.1 Zpracování GPS informací . 3.2.2 Webové služby . . . . . . . 3.2.3 Případy použití . . . . . . . 3.3 Webové služby . . . . . . . . . . . 3.3.1 Zjištění dostupnosti vozidel 3.3.2 Správa jízd . . . . . . . . . 3.3.3 Čerpání pohonných hmot . 3.4 Výpočet geografických vzdáleností
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
17 17 17 19 20 21 23 23 24 24 25 25 25 26 26
. . . . . . . . . . . . . .
1
. . . . . . . . . . . . . .
4 Implementace 4.1 Monitorování přestupků řidičů . . . . . . . . . 4.1.1 Překročení maximální povolené rychlosti 4.1.2 Vymezení oblasti pohybu vozidel . . . . 4.1.3 Povinné přestávky . . . . . . . . . . . . 4.1.4 Kontrola prostojů . . . . . . . . . . . . 4.1.5 Čerpání pohonných hmot . . . . . . . . 4.2 Multilingválnost aplikace . . . . . . . . . . . . 4.3 Bezpečnost . . . . . . . . . . . . . . . . . . . . 4.3.1 Server . . . . . . . . . . . . . . . . . . . 4.3.2 Klient a webové služby . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
5 Testování a shodnocení vzniklé aplikace 5.1 Aplikační prostředí . . . . . . . . . . . . . . . . . . 5.2 Testování . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Klient . . . . . . . . . . . . . . . . . . . . . 5.2.2 Server . . . . . . . . . . . . . . . . . . . . . 5.3 Porovnání s existujícími řešení . . . . . . . . . . . 5.3.1 Aplikace LogBookie a Kniha-jízd-zdarma.cz
2
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
27 27 27 28 30 31 31 31 32 32 33
. . . . . .
35 35 35 35 36 36 36
Úvod V dnešní době se chytré telefony staly běžným technickým zařízením. Možnosti jejich využití jsou daleko větší než u klasických mobilních telefonů. Díky obsahu různých hardwarových modulů dokáže takový telefon nahradit více jednotlivých specializovaných zařízení. Cena nejlevnějších chytrých telefonů je téměř srovnatelná s klasickými mobilními telefony, a koupě chytrého telefonu tak je výhodnější, než koupě několika specializovaných zařízení. Typickým příkladem jsou zařízení s GPS 1 moduly. Takové zařízení si kupovali většinou jen řidiči a turisté, kteří ho využívali čistě za účelem zjištění polohy a navigování do cíle plánované trasy. Díky chytrým telefonům se GPS modul dostal k většímu počtu uživatelů. Díky snadné rozšiřitelnosti softwarové výbavy telefonu začali vývojáři vytvářet zajímavé aplikace, které nejen plní původní navigační a lokalizační účel, ale díky větším možnostem telefonu přinášejí spoustu funkcionality navíc. Oblastí, kde nám mohou chytré telefony zpříjemnit a usnadnit život je mnoho. Zvlášť užitečné by to však mohlo být v oblastech, které většina lidí dělá z povinnosti, např. zákonné. Jednou z nich může být vedení knihy jízd a získávání přehledu o pohybu vozidel ve firmě. V současnosti existuje velké množství softwarových aplikací, které nahrazují tradiční ručně psanou evidenci. Bývají velmi propracované zejména po stránce plnění admistrativních požadavků, ale zásadní nevýhoda u nich přetrvává. Tou je nutnost manuálního vkládání informací o provedených jízdách. Tyto informace se snadno získávají právě díky GPS zařízení. Proto některé aplikace umožňují import takto získaných dat. Práce nutná pro zanesení informací o jízdě se tak minimalizuje na připojení GPS zařízení k PC a importu dat do aplikace. Produkty některých firem jsou schopny vynechat i tento krok. Moduly GPS jsou v automobilech instalována spolu se zařízeními, která je v reálném čase odesílají ke zpracování do monitorovacího centra. Taková řešení jsou určena spíše pro sledování pohybu vozidel, možnosti vypátrání při odcizení apd. Vedení knihy jízd je tak v podstatě jen doplněkem k takto propracovanému systému. Tato řešení však vyžadují nemalé počáteční investice do instalace potřebných zařízení a zejména pronájem takové služby je nákladný. Jako cíl své práce jsem se rozhodl najít a implementovat řešení, které by co nejvíce usnadnilo administrativní úkony a poskytlo co největší přehled o vozovém parku. Tohoto cíle však chci dosáhnout bez vysokých nákládů, které by znamenaly zpoplatnění takové služby. Zároveň bych chtěl nabídnout potenciálnímu uživateli vzniklé aplikace funkcionalitu, která je v této oblasti nestandardní až ojedinělá. Tato práce se tak zabývá možnostmi, jak splnit požadavky na takovou aplikaci. Dále popisuje návrh zvoleného řešení a některé problémy, které bylo nutno při jeho implementaci řešit. Na závěr vyhodnocuje vzniklou aplikaci na základě testování a porovnání s existujícími řešení.
1
Global Positioning System
3
Kapitola 1
Specifikace a analýza požadavků Existují podnikatelé, kteří ve své firmě vlastní vozový park, a potřebují, ať už z administrativních [20], nebo jen z informativních důvodů přehled o pohybu vozidel a nákladech na jejich provoz. Tyto infromace je v dnešním světě moderních technologií možné získavat co nejvíce automaticky a zároveň toto řešení nemusí nutně znamenat velké investice. Technické řešení těchto požadavků musí zajišťovat dvě základní operace: • automatický sběr dat o pohybu vozidel • kompletní správu dat Z nich vyplývá logické rozdělení řešení na dvě části – aplikaci server a aplikaci klient.
1.1
Požadavky na aplikaci typu klient
Sbírané informace o poloze musí být co nejpřesnější. Tento požadavek ke dnešnímu dni splňuje GPS. Klient tedy musí využívat GPS příjmače. Aby mohl klient data zasílat serveru v reálném čase, je třeba, aby byl připojen ke komunikační síti s co největším pokrytím. Uvažovat tak lze pouze síť GMS a její datové služby použitelné pro přístup k internetu – GPRS a navazující. Protože pokrytí GMS není stoprocentním a signál GPS může být v některých terénech také nedostupný, musí být aplikace odolná vůči výpadkům obou signálů – údaje o poloze musí při výpadku ukládat do vnitřní paměti a při výpadku GPS musí umožnit pozdější korekci trasy. Klient musí užvateli umožnit jednoduché zahájení trasování včetně základní konfigurace.
1.2
Požadavky na aplikaci typu server
Serverová aplikace musí být v podstatě informační systém, který bude informace od klientů sbírat, ukládat a vizualizovat uživateli do podoby, kterou potřebuje. Pro správce vozového parku to jsou typicky následující pohledy na data a potřebná funkcionalita: • aktuální poloha vozidel • zobrazení tras vozidel na mapovém podkladu
4
• správa vozidel a řidičů ve firmě, případně ve více firmách spravovaných jedním uživatelem • správa omezení a pravidel pro řidiče a vozidla (vymezení oblasti pohybu, dodržování povinných zastávek apd.) • upozorňovat uživatele na případná porušení těchto omezení • evidovat informace o rychlosti jízdy a o překračování povolené rychlosti • správa informací o spotřebě pohoných hmot u vozidel a firmy celkově • rozlišovat jízdy na firemní a soukromé • reflexe firemní hierarchie v podobě uživatelských rolí • jeden uživatel může být zastoupen ve více firmách, vždy z různou uživatelskou rolí • možnost veškeré záznamy organizovat pod administrativní časovou jednotku – např. jeden rok, kvartál apd. • tyto informace by měly být zobrazitelné odkudkoliv, tzn. systém by měl být dostupný přes webové rozhraní
1.3
Bezpečnostní požadavky
Mimo standardní problémy řešené u většiny informačních systémů s webovým rozhraním, nastává u této aplikace problém se zabezpečením informace o poloze na cestě mezi klientem a serverem. Informace o poloze vozidla respektivě osoby lze klasifikovat jako velmi citlivé. Aplikace tak musí zajistit bezpečnost těchto informací během celého životního cyklu – od jejich vzniku, přes transport až po uložení na serveru. Tématu bezpečnosti je třeba věnovat velkou pozornost.
5
Kapitola 2
Analýza možností realizace 2.1
Klient
Z podkapitoly 1.1 o požadavcích na klienta vyplývá, že to musí být samostatná fyzická jednotka umístěná ve vozidle. Tato jednotka musí obsahovat GPS a GMS moduly. Pro potřeby této práce jsem se rozhodl použít jako hardwarové jednotky klienta dnes rozšířený a dostupný chytrý telefon 1 . Alternativní možnost by představovala specializovaná hardwarová jednotka pevně zabudovaná do vozidla, napájená z jeho elektrického rozvodu, aktivovaná při nastartování. Výhodou chytrého telefonu je, že obsahuje potřebné hardwarové moduly. Operační systém, kterým je telefon vybaven, zprostředkovává rozhraní pro jednoduché využití funckionality těchto modulů. Rozšířit funkcionalitu telefonu lze jednoduše – instalací konkrétní speciální aplikace. Realizace klienta v této práci tak spočívá ve vytvoření takové aplikace. Velká nevýhoda použití telefonu jako klienta je zřejmá – pokud řidič nespustí před jízdou aplikaci, trasa jízdy a potřebné informace zůstanou nezaznamenány. Tento problém však není technického charakteru a ve své práci jsem ho ignoroval. Rozhodnul jsem se tedy jako klienta použít mobilní telefon, konkrétně s operačním systém Android.
2.1.1
Android
Platforma Android je složená z několika úrovní – viz obr. 2.1. Nad linuxovým jádrem, které představují především ovladače hardwarových komponent telefonu, stojí množství knihoven napsaných v jazyce C/C++. Jejich funkcionalita je programátorovi dostupná skrz aplikační framework. Programátor tak může využít stejné funkcionality jako samotné jádro operačního systému. Při spuštění každé aplikace v tomto systému, je vytvořena na novém procesu instance virtuálního stoje Dalvik. Ten je optimalizován pro co největší výkonnost při současném běhu mnoha jeho instancí. Jeho nízkoúrovňová funkcionalita (např. správa paměti, správa vláken) se opírá o zmíněné linuxové jádro. Politika vlastního virtuálního stroje pro každou aplikaci je zavedena především z bezpečnostních důvodů. Komunikace mezi aplikacemi je tak umožněna jen po explicitní definici. Zároveň každá aplikace běží ve výchozím nastavení pod unikátním uživatelem a všechny soubory využívané aplikací mají přístupová práva nastavena pouze pro ID tohoto uživatele. 1
Telefon poskytující nadstandardní funkcnionalitu, snadno rozšiřitelnou instalací nových aplikací.
6
Obrázek 2.1: Schéma architektury Android [1].
2.1.2
Vývojové prostředky
Vývoj aplikace pro Android probíhá v jazyce Java. Programátorovi je tak k dispozici nejen samotný framework Android, ale v podstatě i jakákoliv jiná knihovna jazyka Java. Může se tak zdát, že oproti vývoji klasické Java SE aplikace se vývoj pro Android nijak výrazně neliší. Staronovým problémem, se kterým se zde programátor potýká je hardwarová výkonnost. Problémem netradičním, je energetická náročnost – telefon je bez dokovací stanice odkázán na vlastní bateriový zdroj. Proto je vhodné během vývoje dodržovat některá doporučení [3], která většinou kopírují standardní postupy. Zde nabývají většího významu v podobě až násobného zrychlení vykonání kódu. Např: • preferovat statické metody třídy nad metodami objektu, kdykoliv danná metoda nepracuje s atributy objektu • pro přístup k privátním atributům uvnitř třídy využívat vlastní atributy místo metod set a get určené pro veřejné rozhraní Právě zmíněná slabší hardwarová výkonnost nutí programátora k hledání co nejvýkonnějšího způsobu implementace, což v dnešní době výkonných PC bývá často opomíjeno. Výkon telefonního hardwaru je v porovnání s osobními počítači znatelně horší, a tak může přijít vhod některý způsob optimalizace. Např. kritické místa aplikace lze naprogramovat v nativních jazycích C/C++. Je to sice z programátorského hlediska méně pohodlné, ale lze tak uplanit již napsaný kód v těchto jazycích nebo dosáhnout většího výkonu aplikace. 7
Pro vývoj aplikace v jazyce Java slouží vývojový balík SDK, pro nativní jazyk NDK. Tyto balíky obsahují komponenty nutné pro vývoj – vlastní platforma Android, debugger ADB a dále např. emulátor telefonu, což je samostatná aplikace umožňující vývoj bez vlastního fyzického telefonu.
2.1.3
Komponenty Android aplikace
Každá aplikace se skládá z komponent. Tyto komponenty lze brát jako zcela samostatné celky, a proto je lze snadno sdílet s dalšími aplikacemi (samozřejmě jen pokud je tak definováno), což ušetří opakování stejné funkcionality v různých aplikacích a tím šetří i paměťové prostředky telefonu. Tyto komponenty mohou být potomky těchto základních typů: • Activity – je reprezentována jedním aplikačním oknem, má svůj životní cyklus o základních třech stavech – aktivita je zcela viditelná, částečně viditelná, nebo je na pozadí. Jako jediná komponenta je aktivita v interakci s uživatelem. Obsah aktivity tvoří tzv. Views. View může být například formulářový prvek. Rozložení Views v komponentě určuje Layout. Aktivitu nelze chápat pouze jako vizuální prvek, v kontextu frameworku Android je totiž i nositelkou aplikační logiky. Příkladem Activity může být např. okno pro psaní SMS zprávy. • Service – běží na pozadí a uživateli není nidky viditelná. Vykonává dlouhodobé operace, jako je např. přehrávání hudby. • Content provider – spravuje a sdílí aplikační data, umožňuje k nim přístup i z jiných aplikacím. • Broadcast reciever – slouží k zachycování broadcastových událostí. Ty může vyvolávat vlastní aplikace, nebo mohou být sýtémového typu – např. informace o nízkém stavu baterie. Tyto komponenty také definují reakci na událost a stejně jako komponenty typu Service nejsou uživateli viditelné.
2.2
Server
Pro realizaci serverové aplikace lze použít velké množství technologií. Podstatným argument pro rozhodnutí se může stát schopnost jednoduché a efektivní komunikace klient → server. Pokud je klient implementován v jazyce Java, hodí se Java EE i jako prosředí pro implementaci serveru. Jelikož by ovšem způsob této komunikace měl být co nejvíce univerzální a nezávislý na konkrétní platformě, přímo se nabízí implementovat komunikační rozhraní pomocí webové služby 2.3. Ta vytvoří most mezi serverem a klientem, kteří se stanou na sobě nezávislými a při dodržení komunikačního protokolu služby se mouhu libovolně modifikovat. Porovnávat obecně mezi sebou technologie jako PHP, Jave EE, ASP.NET by mohlo být předmět samostatné práce, jejímž závěrem by pravděpodobně stejně bylo, že volba technologie závísí na konkrétním projektu. U této aplikace se nepožadují extrémní požadavky na výkonnost. Žádné výpočetně náročné operace nejsou předpokládány, spíše se požadují rychlé krátké odpovědi na často periodicky se opakující požadavky klientů. Jistá odlehčenost zvolené technologie tak může být ku prospěchu výkonnosti.
8
Dnes nejdostupnější možností řešení webové aplikace je jazyk PHP. Poskytuje jej nejvíce provozovatelů webhostingu, je to z hlediska zatížení stroje serveru méně náročná technologie, jeden server je schopen obsluhovat více aplikací než u náročnějších technologií a to se příznivě projevuje i na její cenové dostupnosti. Je třeba si však uvědomit, že oproti PHP nabízí tyto technologie robustnější prostředí pro vývoj aplikace. V PHP lze tuto absenci řešit nasazením jednoho z mnoha frameworků. Framework umožní programátorovi soustředit se více na řešení specifickým problémů aplikace typicky několika způsoby [4]: • pro často řešené problémy obsahuje řadu připravených řešení (např. v podobě knihoven funkcí) • vede programátora k dodržování struktury umístění zdrojových souborů a vlastního kódu, čímž pomáhá udržet pořádek v celém projektu • zapouzdřuje, sjednocuje a zabezpečuje potenciálně rizikové operace (např. uživatelský vstup) Pro usnadnění výběru frameworku pro PHP je dostupné množství testů a srovnání [14]. Tak jako v případě výběru samotné technologie, i zde je lepší řídit se potřebami konkrétní aplikace. Ze zmiňovaných testů vyniká v rychlosti a odlehčenosti zdrojového kódu framework Kohana.
2.2.1
Framework Kohana
Jazyk PHP od své 5. verze kompletně přepracovaný způsob práce s objekty, který se tak více blíží přístupu použitému v jazycicích Java a C++. Spousta starších frameworků na tuto změnu nezareagovala dostatečně razantně (např. framework CodeIgnitor), proto jejich zdrojový kód nese prvky jazyka starší verze. Ne tak framework Kohana, který vychází ze zmíněného frameworku CodeIgnitor, ale byl od samého počátku vyvíjen pro PHP 5.2. Proto je jeho podpora OOP 2 na lepší úrovni. Návrhový vzor, na kterém je jádro frameworku Kohana založeno je HMVC 3 . Jedná se o rozšíření návrhového vzoru MVC, který je velmi rozšířený pro vývoj nejen webových aplikací [18]. Vzor MVC člení zdrojový kód do tří samostatných logických celků tak, aby každý vykonával operace, které mu náleží. Tyto celky spolu spolupracují, jak je naznačeno v obrázku 2.2, který zároveň zobrazuje rozdíl mezi HMVC a MVC. Model Popisuje a spravuje nové datové informace ze vstupu systému, nebo stávající z uložiště dat (např. databáze). Různé implementace Modelu se pak liší přítomností většího nebo menšího množství tzv. bussiness logiky. Ta např. zprostředkovává rozhraní pro operace vytvoření, změnu, odstranění datového záznanu a další, specifické pro konkrétní případ. Model tak uchovává vlastně i stav aplikace a různě velkou míru aplikační logiky. 2 3
Objekově orientované programování Hierarchical-Model-View-Controller
9
Obrázek 2.2: Rozdíl mezi MVC a HMVC [18].
Kontroler Jak jeho název napovídá, Kontroler je hlavní řídící jednotkou celého vzoru. Reaguje na požadavek uživatele a s pomocí ostatních komponent mu nabídne adekvátní odpověď. Jeho základními funkčními bloky jsou tzv. Akce. Typický cyklus zpracování uživatelova požadavku, např. zobrazení článku má tuto podobu: 1. Kontroler přijme a identifikuje uživatelův požadavek 2. Kontroler požádá Model o data reprezentující požadovaný článek 3. Model nad svým datovým úložištěm získá požadovaná data a vrátí je Kontroleru 4. Kontroler předá připravená data Pohledu, kerý je zobrazí uživateli Pohled View neboli Pohled je komponenta, se kterou je uživatel v přímém kontaktu. Přes jeho události jsou předávany požadavky klienta na Kontroler a následně mu je zobrazena odpověď. V závislosti na technologii a způsobu implementace může komunikace probíhat i mezi Modelem a Pohledem. Model může např informovat Pohled o změně svého stavu a naopak Pohled si může informaci o stavu Modelu vyžádat. Důležitou vlastností je u tohoto vzoru zapouzdřenost. Kontroler se např. nestará o to, jak Model data ukládá. To zajistí potřebnou nezávislost – kdyby došlo ke změně datového uložiště z databáze na souborový systém, způsobilo by to jen úpravu zdrojového kódu Modelu. Kontroler by zůstal stejný a dál by volal Model stejným způsobem. 10
Zpracování požadavku uživatele Pro pochopení, jak frameworku funguje, je stěžejní znalost toku zpracování uživatelského požadavku [7]. 1. všechny požadavky na server jsou pomocí nastavení .htaccess souboru přesměrovány na soubor index.php (a) nastaví se základní prostředí php, jako je úroveň reportování chyb apd. (b) vloží se jádro frameworku (c) vloží se soubor bootstrap.php 2. vykonává se obsah souboru boostrap.php (a) inicializuje se framework – nastavení logování, cachování a zpracování vyjímek (b) inicializují se tzv. Routes (cesty), které jsou definované regulárním výrazem a zajištují překlad URI4 požadavku na Kontroler a jeho Akci (c) vytvoří se instance třídy Request (hlavní požadavek) a spustí se jeho zpracování i. Prochází se seznam Routes dokud se nenajde ta, jejíž regulární výraz vyhovuje URI požadavku ii. vytvoří se instance Kontroleru určeného z URI pomocí Route iii. vykoná se jeho Akce before iv. vykoná se Akce určená z URI pomocí Route, ktrerá generuje Response – odpověď na požadavek v. vykoná se jeho Akce after (d) tento hlavní požadavek může během svého zpracování vytvářet požadavky nové (viz obr. 2.2 popisující schéma HMVC) a předchozí blok kroků se může vykonávat opakovaně 3. tok programu se předá zpět do index.php a ten zobrazí odpověď hlavního požadavku Co nabízí HMVC5 oproti MVC navíc je hierarchické rozložení požadavku – viz obr. 2.2. V praxi to znamená, že jeden Kontroler může během zpracování požadavku vytvářet požadavky nové a delegovat jimi jiné Kontrolery (i sebe sama). To umožňuje efektivní využitelnost napsaného kódu a zabrání jeho opakování, což se pozitivně projevuje na jeho přehlednosti a kompaktnosti. V praxi takový cyklus může vypadat např. takto: • Kontroler spravující články dostane požadavek na zobrazení článku, který je přístupný jen autentizovaným čtenářům • Kontroler tedy musí zobrazit autentizační formulář. Nesestavuje jej sám, ale jednoduchým zasláním požadavku tím pověří Kontroler spravující autentizaci uživatele • ten do svého Pohledu potřebuje začlenit obrázek s CAPTCHA6 proto vytvoří požadavek na kontoler spravující CAPTCHA, který zároveň připraví prostředí serveru pro ověření úspěšnosti CAPTCHA testu. 4
Uniform Resource Identifier Poprvé představen v roce 2000 [24]. 6 Completely Automated Public Turing test to tell Computers and Humans Apart 5
11
• odpovědi na dílčí požadavky (nemusí se jednat vždy o Pohledy) se při vynořování z rekurze hierarchicky skládají až po nejvyšší úroveň, kde je celá odpověď předána uživateli Framework Kohana programátora přesně k takovému způsobu psaní zdrojového kódu vede, avšak nenásilnou cestou, tzn. že navrhováné členění aplikace je pouze doporučené. Oproti některým PHP frameworkům, jako jsou např Symphony a Yii, Kohana nepoužívá žádné generátory kódu. Ty vývoj aplikace mohou zpočátku značně urychlit. U specifické aplikace, která neslouží jen pro CRUD7 operace nad daty, je stejně potřeba takto vygenerovaný kód výrazně upravit. Absence generátoru nepředstavuje výrazný problém při využití základní vlastnosti OOP – dědičnosti. Stejné operace nad více třídami se umístí do společného předka a třída potomka je o tento kód odlehčena. V jádře frameworku jsou pro základní třídy MVC připraveny abstraktní předci, od kterých dědí třídy samotné aplikace.
2.3
Webové služby
Zbývajícím prvkem v architektuře této aplikace je zajištění komunikace mezi klientem a serverem. Ze současných požadavků vyplývá podoba komunikace, kdy klient zasílá požadavky na server a očekává odpověď v podobě dotazovaných dat, nebo jen potvrzení o úspěšnosti doručení požadavku. Možností, jak toho docílit, by byla implementace vlastního komunikačního protokolu. Tento specializovaný protokol by pravděpodoně vykazoval vysokou efektivitu v podobě co nejmenšího možného datového toku mezi klientem a serverem, ale přinesl by i spoustu komplikací. Především návrh kvalitního protokolu a samotná jeho implementace není triviální záležitost. Řešit např. zabezpečení takového protokolu by mohlo svou náročností zcela překonat ostatní problematiku této práce. Navíc neznámé protokoly v internetu nebudí velkou důvěru, teoreticky se tak může stát, že komunikace bude např. odfiltrována firewallem. Proto je výhodnější se porozhlédnout po možnostech, které nabízejí zavedené protokoly. Při rozdělení aplikace do více samostatných celků se přímo nabízí využít techniky SOA8 . Tato architektura definuje aplikaci jako několik nezávislých komponent – služeb. Služba má přesně definovanou funkncionalitu svým komunikačním rozhraním (pro jeho formální popis je standardně používán jazyk WSDL9 ). Architekturu SOA, která je založena na interakci tří uživatelských rolí, popisuje obr. 2.3. Služby nemusí být určeny pouze pro proprietární využítí. Pokud je služba kvalitní a byl by o ni zájem, lze ji nabízet veřejně. Její poskytovatel pak službu zaregistruje do veřejného registru služeb. Zde si ji vyhledá zájemce, získá na ní kontakt a může ji začít využívat – stane se z něj konzument služby. Aplikace tvořená službami je flexibilní – úprava jedné služby při zachování rozhraní némá vliv na ostatní služby. Funkcionalita aplikace je jasně definovavá samotnými službami, které jsou bezstavové. Jednotlivé služby mohou být implementovány na různých platformách v různých programovacích jazycích, dokonce nemusí být implementovány na jednom fyzickém stroji. Z těchto důvodů jsou služby výborně znovupoužitelné – kdykoliv je potřeba stejné funkcionality, téměř bez ohledu na technické podmínky se dá služba opětovně využít. 7
Create-Update-Delete Service Oriented Architecture 9 Web Services Description Language 8
12
Obrázek 2.3: Základní schéma SOA [21].
Služby jsou tak ve své podstatě pokračováním snahy o efetktivnější vývoj software, tak jako starší techniky modulárního a objektově orientovaného programování. Webové služby, jsou prostředkem jak realizovat SOA v síti internet. Jsou volány nejčasťěji nad protokoly HTTP a HTTPS, ale klidně i SMTP. Mezi technologiemi pro realizaci webové služby, které lze v dnešní době využít, převažují SOAP 10 , jeho předchůdce XML-RPC 11 a stále populárnější REST 12 .
2.3.1
XML-RPC
Vzdálené volání procedur (RPC) využívá XML jednak pro definici požadavku konzumenta (názvu volané procedury, jejich parametrů, datových typů), ale i pro popis odpovědi samotné služby. Pro implementaci na straně klienta i serveru lze využít téměř pro každý programovací jazyk připravené knihovny a rozšíření.
2.3.2
SOAP
Je protokol vycházející z XML-RPC a snaží se o větší komplexnost. Kromě RPC tedy umožňuje datovou komunikaci na úrovni instancí objektů. Přenesený objekt má shodné vlastnosti a chování s objekty vzniklými na druhé straně komunikace. Těchto pozoruhodných schopností je dosaženo za cenu větší složitosti oproti XML-RPC. Každá SOAP zprává např. musí obsahovat definci typu XML dokumentu. Opět jsou pro implementaci k dispozici knihovny pro většinu programovacích jazyků.
2.3.3
REST
Nepředstavuje ani tak novou technologii, jako spíše nový přístup, který naplno využívá vlastností HTTP protokolu. Pojem REST se poprvé objevil v roce 2000 v disertační práci Roye Fieldinga13 , který patří mezi autory protokolu HTTP. 10
Simple Object Access Protocol XML Remote Procedure Call 12 Representational State Transfer 13 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm 11
13
Oproti zmíněným procedulárním technikám je REST více orientován na zdroje dat a určuje, jak se k nim chovat. Každý zdroj má svou vlastní URI. Způsob chování k datům zdroje je určen metodou HTTP požadavku. Tyto metody jsou základní čtyři – GET, POST, UPDATE, DELETE. Všechny zdroje tak mohou nabízet nejvýše tyto metody, což je ve většině případů překvapivě dostačující. Odpovědí jsou data v libovolném formátu – XML, JSON nebo jen prostý text. To může oproti standardizovaným SOAP zprávám působit chaoticky. Tuto volnost lze využít např. pro ušetření přenosu zbytečných režijních dat. Navíc tento přístup zjednodušuje komunikaci ze strany klienta na server takovým způsobem, že se při jeho implementaci lze vyhnout použití externích knihoven nebo rozšíření. Architektura REST je odlehčená a s jednoduchým principem, což je předpoklad pro snadnou rozšiřitelnost a znovupoužitelnost. Problémem při její implementaci může být absence podpory méně běžných metod protokolu HTTP – UPDATE a DELETE u některých zařízení. Lze to vyřešit částečným porušením REST přístupu, kdy se např. místo metody DELETE použije POST a mezi parametry volání se přidá původní metoda operace. Lehkost a jednoduchost této technologie způsobila, že většina velkých poskytovatelů veřejných služeb na webu využívá právě ji. Jmenovitě např. Twitter, Facebook, Yahoo, Flicker. Paralelně využívá REST a SOAP Google, Amazon, Ebay. V otázce bezpečnosti se SOAP a REST staví odlišně. REST ji v podstatě neřeší s argumentací, že to je záležitost transportní vrstvy. Zajistit bezpečnou komunikaci tak lze např. použitím TSL14 nebo SSL15 a základních autentizačních prostředků HTTP. SOAP si bezpečnostní a autentizační mechanismy často implementuje sám, k dispozici je spoustu rozšíření různé úrovně. V porovnání SOAP a REST tak lze učinit závěr, že pro webové technologie s jednoduchým otevřeným rozhraním se hodí více REST, kdežto pro firemní enterprise systémy bude pravděpodobně vhodnější SOAP. Vzhledem k povaze této práce a k faktu, že klient (platforma Android) neobsahuje integrovanou podporu SOAP ani XML-RPC (ta by se musela zajistit improtem externí knihovny), jsem zvolil REST princip webových služeb.
2.4
Mapové podklady
Ze specifikace požadavků 1 plyne potřeba využití mapových podkladů a nalezení způsobu, jak na nich potřebné informace zobrazit. Za vznikem mapových podkladů stojí většinou kartografické a geodetické firmy nebo státní instituce. Jejich produktů využívají mapové portály a staví na nich vlastné služby v prostředí WWW. Mapových portálů existuje velké množství [19]. Jen některé nabízí své podklady k využití skrze API 16 . Právě to je pro vývojáře nejsnadnější způsob, jak využít mapové podklady ve své aplikaci. Musí však dodržet licenční podmínky, ke kterým se použitím API zavazuje. Pro bezplatné využití mapových podkaldů platí téměř u všech poskytovatelů základní podmínka – účel jejich použití je nekomerční. Problémové bývá často propojení komerčních a nekomerčních částí aplikace (např. v podobě rozšířené funkcionality). V těchto případech licenční podmínky často nejsou zcela jasné a je potřeba jejich obsach pečlivě nastudovat, případně se obrátit přímo na podporu konkrétního poskytovatele. Aplikace vznikající v této práci je zcela nekomerční, ale ani to nemusí být dostatečující, viz podmínky některých regionálnách poskytovatelů 2.4.1. 14
Transport Layer Security Secure Sockets Layer 16 Application Programming Interface 15
14
2.4.1
Regionální poskytovatelé
Při výběru mapového podkladu aplikace je podstatné geografické zacílení. U této aplikace je to primárně Česká republika. Nelze však vyloučit její budoucí rozšíření. Především je však důležitý fakt, že uživatelé aplikace mohou chtít trasovat své cesty i v zahraničí. Regionální provozovatel by měl díky soustředěnosti na menší území být schopen rychleji reagovat na změny v terénu a častěji aktualizovat své podklady. Regionálními lídry jsou dlouhodobě Mapy.cz společnosti Seznam.cz a AMapy.cz společnosti Centrum Holdings. Mapy.cz V současnosti nabízí moderní API verze 4.7. Mapové podklady pokrývají podrobně celou Evropu. Množství dotazů na API za časovou jednotku není nijak limotované a tak na první pohled nic nebrání jejich podrobnějšímu studiu a případnému využití. Problémové jsou však licenční podmínky17 , které neumožní využívat API v privátní sekci aplikace (za přihlášením), byť je registrace zdarma. Navíc API neumožňuje využít podrobnou mapu Evropy mimo území ČR (pravděpodobně kvůli licenční smlouvě mezi Seznam.cz a dodavatelem těchto podkladů), a tak je nutné Mapy.cz pro použití v aplikaci zavrhnout. AMapy.cz Portál po dlouhodobé neaktivitě při údržbě a vývoji svého API[19] v roce 2011 představil kompletně novo mapovou službu. Vystavěl ji nad technologií společnosti Google. Navíc nabízí několik funkcí, které ocení především běžní uživatelé. Pro vývojáře aplikací by mohla být zajímavá detailní vrstva map, která v současnosti pokrývá několik větších měst v ČR a pyšní se přívlastkem nejdetailnější“. ” Pro aplikace týkající se dopravy se nabízí funckionalita Dopravní informace. Ta do podkladů přínáší údaje o uzavírkách a dokonce i dopravních nehodách. Zásadní problém, který brání využití služeb AMapy.cz je absence funkčního API. Dle vyjádření oddělení podpory zákazníků se aktuálně teprve vyjednávají podmínky pro použití API společnosti Google. Podrobné infromace, jestli výsledkem bude pouze obdoba API Google, nebo jestli jej AMapy.cz rozšíří o vlastní funkcionalitu, nejsou zveřejněny. Z této situace lze usoudit, že nové AMapy.cz se v současnosti soutředí na běžné uživatele a vývojářům nabízí pouze možnost vložit si mapu do své aplikace bez schopnosti větší interakce. Za takové situace nezbývá nic jiného, než zvolit z nadnárodních poskytovatelů.
2.4.2
Google Maps a OpenStreetMap
Přestože regionální mapové podklady nabízejí větší množství kartogreafických informací, jejich vyloučení není pro plánovanou aplikaci až tak velkou ztrátou. Pro potřeby trasování v této aplikaci jsou podstatné jen komunikace kategoriií dálnice, silnice a místní komunikace. Tyto kategorie jsou i u nadnárodních poskytovatelů jako jsou Google Maps, pokryty velmi kvalitně. Google Maps a OpenStreetMap se nejvíce liší v původu geografických podkladů a v licenčních podmínkách použití. Podklady Google Maps jsou vlastněny společností Google, nebo jinými kartografickými společnostmi (např. data pro Českou Republiku pocházejí od společnosti Geodis Brno). Že je Google umožní využívat např. i v opensource projektech neznamená, že vlastní mapová data jsou volně šiřitelná. Ta jsou stále chráněna autorskými 17
http://api4.mapy.cz/view?page=faq
15
právy. Volně tak lze použít jen vlastní službu Google Maps za podmínky, že služba nad ní vystavěná bude volně dostupná koncovým uživatelům18 . Extrémní omezení jako u Mapy.cz z těchto podmínek nevyplývají. OpenStreetMap oproti tomu nabízí svobodná samotná kartografická data. Ta jsou sbírána tisícovkami dobrovolníků po celém světě, nebo jsou uvolněny organizacemi pod licencí kompatibilní s licencí OpenStreetMap19 . Vlastní API nad těmito podklady je dostupné pod licencí GPL. Pro naši aplikaci jsou tak z pohledu licenčních podmínek obě možnosti vyhovující. Pro srovnání kvality jednotlivých podkladů pro slouží online nástroje, např. http://sautter. com/map/. Z hrubého testování obou podkladů je evidentní, že podklady OpenStreetMap díky zmíněným tisícům tvůrců dokáží rychleji reagovat na změny v terénu. Některé nové silniční stavby zaznamenané v OpenStreetMap nejsou v Google Maps vůbec vyznačeny. Na rozdíl od Mapy.cz a Google limituje provoz své služby. Limit 25 000 načtených map denně20 je pro úvodní provoz dostačující. V případě nárůstu provozu nad uvedenou hranici umožňuje Google za poplatek limit navýšit, nebo rovnou přejít na prémiovou verzi, která poskytuje pokročilejší služby. Limity použití OpenStreetMap se týkají pouze při využívání služeb editujících mapové podklady, pouhé čtení těchto informací není nijak omezeno. Podstatné jsou i schopnosti jednotlivých API, kde Google Maps nabízí více potřebnou funkcionalitu a to při větší intuitivnosti a jednoduchosti používání. Oproti tomu API OpenStreetMap je přizpůsobeno pro samotnou úpravu mapových podkladů je mnohem komplexnější a složitější. Budoucí podpora u obou porovnávaných možností je zaručena, na jedné straně stojí softwarový gigant a na straně druhé rychle rostoucí komunita s počtem aktivních editorů přesahujícím 10 0000 [9]. Celkově do OpenStreetMap přispělo již více než 500 000 000 uživatelů a jejich služeb využívá čím dál více velkých projektů, pro které jsou limitující podmínky Google Maps[22]. Dalším argumentem pro Google Maps je, že je to nativní mapové prostředí pro aplikace frameworku Android, a případné využití mapového podkaldu i na straně klienta by bylo bezproblémové. Možností, jak odstínit problémy způsobené případnou změnou poskytovatele mapového podkladu by bylo implementovat zvláštní vrstvu nad mapovými API. Případná změna by se tak týkala pouze této vrstvy. Takové řešení by se však vyplatilo až pro systémy, které využívají mapových podkladů ve větší míře, než tato aplikace.
18
http://code.google.com/intl/cs-CZ/apis/maps/terms.html http://wiki.openstreetmap.org/wiki/OpenStreetMapLicense 20 http://code.google.com/intl/cs-CZ/apis/maps/faq.html#usagelimits 19
16
Kapitola 3
Návrh systému Výsledkem analýzy je podoba základní architektury aplikace zobrazená na obr. 3.1
Obrázek 3.1: Schéma návrhu základní architektury.
3.1
Serverová část
Po analýze požadavků by měla být jasná struktura perzistentních dat. Ta jsou ukládána v relační databázi a jejich struktruru vyjadřuje ERD 1 . Pro větší přehlednost je v následujícím textu rozdělený do více částí a zobrazuje pouze relace. Kompletní ERD je zobrazen v příloze B.
3.1.1
Databázový model
Schéma 3.2 popisuje uživatelské role v systému, jejich vztah k firmám a uživatelům. Tato struktrura vychází z požadavku, aby jeden uživatel mohl vystupovat ve více firmách pod 1
Entity Relationship Diagram
17
různými rolemi. Zároveň popisuje strukturu ACL2 , které určuje, jaká uživatelská role má právo pro konkrétní Akci nad konkrétním Kontolerem. Takto navržené ACL je poměrně snadné implementovat a zároveň umožňuje při růstu aplikace snadné přidávání nových uživatelských rolí a definici jejich práv. Aby tabulky související s ACL nenabývaly zbytečně velkých rozměrů, použil jsem zde princip tzv. Wildcards. Jedná se o záznamy, jejichž ID má speciální hodnotu (konkrétně nulovou). Pokud na takový záznam odkazuje pomocí cizího kliče záznam jiné tabulky, aplikační logika zajistí, aby se navázaly všechny řádky vázané tabulky. Např. záznam ve vazební tabulce role_action s nulovou hodnoutou ve sloupci controler odpovídá všem Kontrolerům v systému. Administrátorské právo na veškeré Akce všech Kontrolerů lze definovat jediným řádkem který obsahuje wildcards ve sloupci controler a action. Pokud by bylo potřeba takové roli zakázat jednu konkrétní akci, nemusí se to řešit smazáním řádků s wildcards a přidáním všech ostatních akcí kromě zakázané. Pro tuto možnost je připraven sloupec alowed nesoucí boolovskou hodnotu TRUE nebo FALSE. Bezpečnostní politika je taková, že hodnota FALSE má přednost před TRUE. Když se v tabulce vyskytne pro akci záznam s hodnotou FALSE, dalším záznamem s TRUE hodnotou se jej zastínit nepodaří. Naopak to aplikovat lze – jediný další záznam s hodnotou FALSE odstraní akci z výčtu povolených. Takto navržené ACL ušetří spoustu záznamů v tabulce práv, která by se jinak stala nepřehlednou pro pozdější úpravy. Samotná tato logika není implementována v databázi, ale zajišťuje ji jeden z aplikačních pomocníků, viz podkapitola 3.1.2 o návrhu administračního rozhraní.
Obrázek 3.2: Uživatelé a uživatelké role v systému.
Vztahy firem ke svým vozům a administrativním časovým obdobím popisuje obr. 3.3. Je v něm zachycen vztah mezi uživately a vozidly vyjadřující, která vozidla může konkrétní uživatel používat. Dále zachycuje vymezení oblastí, kde se vozidla a řidiči mohou pohybovat. Ta jsou typicky reprezentována polygony složenými z bodů. Takové omezení může být přiřazeno jak ke konkrétnímu uživateli, tak vozidlu. V poslední části ERD na obr. 3.4 je zachycena samotná struktura jedné jízdy vozidla s případnou informací o doplnění pohonných hmot. Speciální význam má tabulka ride_open. Ta obsahuje jízdy, které jsou momentálně v systému otevřené – právě do nich přichází data z klientských aplikací. Význam této tabulky je především bezpečnostní. Uchovává unikátní řetězec, který umožní jízdu identifikovat a modifikofat její trasu přidáním bodů z klientské aplikace. Oproti identifikaci na základě 2
Access Control List
18
Obrázek 3.3: Firmy a související entitní množiny.
číselného ID se tento řetězec hůře odhaduje – je v systému pouze dočasně a komplikuje útočníkovi cílený útok na narušení dat konkrétní jízdy. Při vytváření nového záznamu je tento řetězec náhodně generován a musí být unikátní, což si hlídá aplikační i databázová vrstva. Po ukončení jízdy je její záznam z této tabulky odstraněn.
Obrázek 3.4: Jízdy a související entitní množiny.
3.1.2
Administrační rozhraní
Téměř každá databázová tabulka je pomocí ORM3 namapována na svůj Model. Strukturu vztahů Modelů a Kontrolerů zobrazuje diagram tříd na obr. 3.5. Zelenou barvou jsou zvýrazněny třídy frameworku Kohana, oranžovou barvou pak jejich abstraktní potomci, kteří nesou společné metody a atributy. Třídy nejnižší úrovně jsou v diagramu bez barevného zvýraznění a nejsou v něm pro přehlednost uvedeny všechny, pouze příklady. U Modelů byl zaveden předek ModelBase proto, že některé vlastnosti třídy ORM nebyly zcela vyhovoující a není vhodné přepisovat třídu frameworku, pro případ jeho budoucí aktualizace. Názvy tříd se mohou zdát zbytečně dlouhé, musí ale respektovat konvence frameworku, dle kterých název třídy vždy reprezentuje úmístění jejího souboru v adresářové struktuře. Kontrolery jsou členěny mezi tři abstraktní předky. Potomci ControllerBase jsou těmi, jejichž akce volá uživatel přes webové rozhraní aplikace. V tomto předku je přetížená metoda before() (viz podkapitola 2.2.1 o zpracování uživatelovat požadavku) tak, aby kontrolovala, jestli je uživatel autentizován. Případně jej přesměruje na přihlašovací Kontroler. 3
Object relational mapping
19
Jestli má uživatel právo požadovanou akci vykonat – kontrola z práv ACL, se určuje mimo Kontroler. Je to další bezpečnostní prvek, který zamezí situaci, kdy se při přetěžování metod u potomků tohoto Kontroleru zapomělo autorizační metodu zavolat. Proto je tato logika posunuta do třídy Request, u které je přetížena metoda execute() tak, že se nejprve zavolá pomocník HelperACL. Ten určí, jestli přihlášený uživatel má právo vykonat akci a pokud je výsledek autorizace negativní, akce se nevykoná a uživatel je o této skutečnosti informován varováním. Webové služby jsou na serveru realizovány jako potomci třídy ControllerServiceBase. Ta je implementována v principu REST, řeší autentizaci volání webových služeb (viz kapitola 4.3 o bezpečnosti), její výstupy jsou často XML formátu a tak využívá externího modulu pro serializaci polí a objeků do XML. Poslendí je skupina interních Kontrolerů – potomci ControllerInternalBase. U nich je podstatná vlastnost, že jejich akce nelze zavolat prostřednictvým URI požadavku, ale pouze interním vyvoláním jiného Kontroleru, viz obr. 2.2 popisující HMVC. Do diagramu tříd nejsou zahrnuty třídy aplikačních pomocníků“. Jsou to nejčastěji ” jedoduché statické třídy se statickými metodami, které zaštiťují opakovaně volanou funckionalitu, bez evidentního vztahu s jinými třídami. Pokud je jejich funkcionalita složitější (tak jako zmíňěný HelperACL, který používá data z databáze), implementují návrhový vzor singleton [17]. Jeho princip spočívá ve vytvoření jediné instance dané třídy dostupné přes statickou metodu, která je udržována v paměti po celou dobu zpracování požadavku, kdy je volána z různých míst aplikace. Konkrétně u pomocníka HelperACL to způsobí, že se dotaz na databázi nemusí provádět vícekrát – data jsou cachována“. ”
3.1.3
Grafické uživatelké rozhraní
Grafické uživatelské rozhraní této aplikace je zprostředkováno skrze Pohledy. Ty jsou produkovány třídou View, která implementuje návrhový vzor factory [15]. Vyjadřovacími prostředky Pohledu při sestavnení výstupu pro uživatele (webové stránky) jsou značkovací jazyk HTML pro definici struktury obsahu a CSS pro definici vzhledu. Interaktivitu aplikace na straně prohlížeče uživatele zajišťuje použití skriptovacího jazyka JavaScript (dále jen JS). Ten najde své využití především při ovládání map a také pro vyvolání a zpravování AJAX požadavků. Ty jsou v aplikaci použity pro získávání objektů tras k vykreslení na mapách, složitější validaci formulářů apd. Vývoj v jazyce JS má své specifické problémy, především v různé podpoře webových prohlížečů. To je jedním z hlavních důvodů, proč použít některou z komplexních knihoven, jakými jsou např. JQuery a MooTools. Tyto knihovny usnadňují psaní kódu připravenými funkcemi pro snadnější práci s DOM 4 , konkrétně s výběrem DOM prvků, traverzováním nad nimi a úpravou jejich vlastností. Kromě těchto základních prostředků také často zapouzdřují volání AJAX požadavků, podporují animace a celkově nabízí programátorovi pohodlnější prostředí než samotný JS. Tato funkcionalita je v nich vytvořena způsobem kompatibilním se všemi běžnými moderními webovými prohlížeči, což ušetří spoustu ladění a testování, protože ne všechny prohlížeče interpretují JS stejně. Kterou knihovnu zvolit, řeší spousta článků [23]. Jajich stručný závěr je, že JQuery je pro jednoduché skriptování vhodné a má rychlou křivku učení. MooTools je naopak vhodné 4
Document Object Model
20
Obrázek 3.5: Diagram tříd serverové aplikace.
pro rozsáhlé JS aplikace a zkušenější JS programátory. Proto jsem jako JS knihovnu použil JQuery.
3.1.4
Případy použití
Možnosti použití aplikace server vyjadřuje diagram případů užití na obr. 3.6. Pro přehlednost jsou v něm nejčastější operace jako vytvoření, úprava a smazání záznamu souhrně označovány akcí správa“. Uživatelské role jsou v současnosti v aplikaci rozděleny na: ” • Návštěvník – neautentizovaný uživatel • Adminstrátor – vedení firmy, tuto roli zíká automaticky každý, kdo se registruje přes webové rozhraní a tím si vytvoří firmu • Manažer – oproti adminstrátorovi má omezená práva zejména v oblasti správy firemních jednotek. Je tak určena především k zobrazení přehledů a statistik z nasbíraných dat. • Řidič – uživatelům této role není umožněn přístup do informačního systému serverové části aplikace, mohou používat pouze klienta a skrze něj webové služby serveru
21
Obrázek 3.6: Diagram případů užití aplikace Server.
22
3.2
Klient
Architektura klientské Android aplikace zobrazené na obr. 3.7 do jisté míry musí respektovat strukturu frameworku Android popsanou v podkapitole 2.1.3. Aplikační komponenty typu Activity mají společné vlastnosti extrahovány do svého předka – třídy ProjectActivity. V diagramu tříd 3.7 nejsou pro přehlednost opět uvedeny všechny koncové (barevně nezvýrazněné) třídy, ale jen ty podstatné. Konkrétní koncové třídy Activity v podstatě odpovídají jednotlivým případům užití viz diagram případů užití na obr. 3.8. Jediná komponenta typu Service – třída TrackerService slouží k trasování jízdy na pozadí spuštěné aplikace. Využívá služeb třídy Tracker pro získávání informací o poloze v pravidelných intervalech. Tyto intervaly jsou časové – za každé 3 vteřiny, případně pokud vozidlo během této doby urazí větší vzdálenost než 30m, je akce informace zaslána dřív. Tyto hodnoty byly získány na základě testování a jsou optimálním poměrem mezi podrobností záznamu a množtvím odeslaných informací.
Obrázek 3.7: Diagram tříd aplikace Klient.
3.2.1
Zpracování GPS informací
Takto získané informace je potřeba ukládat. Způsob ukládání je řešen poměrně složitě, a proto byl rozložen do několika samostatných tříd. Jejich implementace staví na návrhových vzorech Observer [15] a Chain Of Responsibility [17]. Informace o aktuálním čase, poloze a rychlosti vozidla reprezentuje třída TrackPoint. Její instance vznikají ve třídě Tracker. Ta prostřednictvím rozhraní LocationListener komunikuje s GPS modulem a objekty třídy TrackPoint předává do zmiňované TrackerService. Ta je v podstatě jen přepošle dál do instance třídy DataTransmitter. Tato třída implementuje návrhový vzor singleton, protože v aplikaci funguje jako jednotná datová sběrnice a implementovat celou její funkcionalitu staticky by nebylo vhodné. DataTransmitter obsahuje dva potomky abstraktní třídy DataStorage, která definuje abstraktní metody pro 23
práci s daty aplikace tak, aby její potomci měli shodné rozhraní. Potomek ServerStorage slouží k bezprostřední datové výměně se serverovou aplikací pomocí webových služeb. Potomek LocalStorage pužívá jako datové úložiště lokální databázi SQLite. Zmiňovaný DataTransmitter jako Observer reaguje na změnu dostupnosti internetového připojení, která se šíří napříč operačním systémem Android v podobě Broadcast události. Podle toho, zda se jedná o odpojení nebo připojení k internetu, volí jako cíl uložení dat LocalStorage nebo ServerStorage. Pokud se změní stav z nepřipojeno na připojeno, pokusí se DataTransmitter v novém procesu o synchronizaci dat mezi lokální databází a serverem. To se děje voláním stejné služby třídy ServerStorage. Vzhledem k tomu, že veškeré instance TrackPoint mají své časové známky a hodnoty pořadí již od svého vzniku v třídě Tracker, nezáleží na pořadí, ve kterém jednotlivé instance TrackPoint na server dorazí. Proces synchronizace je tak pouze jednoduché fronty z databáze a odeslání jejich prvků na server.
3.2.2
Webové služby
S vlastními webovými službami přichází do styku ServerStorage. Jelikož požadavky na REST orientované služby jsou obyčejné HTTP požadavky, využívá třídu frameworku DefaultHttpKlient. Bezpečností problematika komunikace skrze webovou službu je popsána samostatně v podkapitole 4.3. Odpovědi webové služby jsou zpravidla strukturované XML dokumenty. Z důvodu optimalizace jsem se rozhodl odpovědi jednoduchých, často volaných služeb formátovat bez XML. I když je XML dokument zpracován SAX parserem, který umožní rychlejší sekvenční zpracování než DOM parser, jedná se stále o poměrně náročnou operaci. Proto jsem některé služby implementoval tak, aby vracely prostou textovou odpověď – viz popis webových služeb v podkapitole 3.3.
3.2.3
Případy použití
Možnosti použití klientské aplikace znázorňuje diagram případu užití na obr. 3.8. V podstatě je celý klient postaven jako uživatelské rozhraní pro práci s webovými službami serveru a tomu odpovídá jeho funkcionalita. Vzhledem k tomu, že jsou tyto služby často voláný během uživatelovi interakce s grafickým rozhraním a jejich odpověď není okamžitá, musí být uživatel informován o tom, že je požadavek zpravováván a nenechat uživatelské rozhraní neaktivní. Toho je docíleno spouštěním obsluhy požadavku v novém vlákně, zobrazením informačního dialogu a po zpracování odpovědi služby jeho skrytím.
Obrázek 3.8: Diagram případů užití aplikace Klient.
24
3.3
Webové služby
Vlastní implementace webových služeb se týká serverové aplikace, ale jejich podoba je přizpůsobena především technickým možnostem a potřebám klienta. Zpracování odpovědi musí být u klienta často velmi rychlé, proto se liší formáty odpovědí. Pro odpovědi obsahující velké množství strukturovaných dat je použit formát XML. Pro služby, jejichž odpovědmi jsou jednotlivé informaci, je použit prostý text. Princip REST takové použití umožňuje. Dokonce, pokud je odpovědí pouze návratový kód, lze pro jeho přenos použít stavový kód v hlavičce HTTP odpovědi. Pokud je použit pricip REST, tak návratové kódy služeb stavovým kódům v podstatě odpovídají. V aplikaci jsou proto použity následující: • 200 – odpověď je v pořádku • 400 – webová služba je volána s chybnými parametry • 401 – nepodařilo se autentizovat uživatele • 404 – chybná URI, nelze určit, která webová služba je volána • 500 – došlo k interní chybě na straně serveru, způsobenou např. chybou ve zdrojovém kódu, přesný důvod by se uživatel neměl z bezpečnostních důvodů dozvědět Všechny služby jsou přístupné pouze po autentizaci, kterou popisuje podkapitola 4.3. Proto v každém volání služby musí klient odeslat autentizační údaje. Ty se tak přidávají k povinným parametrům volání služby.
3.3.1
Zjištění dostupnosti vozidel
Podle identity uživatele služba vrací seznam vozidel, které jsou v daný okamžik k dispozici. Bere v úvahu: • aktuálně probíhající jízdy ostatních firemních uživatelů – jestli vozidlo nepoužívá někdo jiný • oprávnění uživatele používat konkrétní vozidlo • jestli je k aktuálnímu datu vozidlo vedeno jako aktivní Formátem odpovědi je XML.
3.3.2
Správa jízd
Je realizována jako jedna služba, její chování se dle principu REST větví podle typu HTTP požadavku. • Zahájení nové jízdy – požadavek typu POST, povinný parametrem ID vozidla, volitelně s příznakem, jestli má být zahajovaná jízda v systému vedena jako soukromá. Jako identifikátor uživatele se použijí informace získané z autentizačních údajů. Odpovědí je v případě úspěchu náhodně vygenerovaný řetězec identifikující jízdu v sytému.
25
• Uložení bodů trasy – požadavek typu PUT, parametrem je struktura obsahující povinně GPS souřadnice, identifikátor jízdy pod kterou bod patří, časová známka a pořadové číslo bodu. Nepovinně aktuální rychlost. Služba přijímá během jednoho volání i více těchto struktur v pdobě pole – z optimalizačních důvodu zmíněných v podkapitole 4.3.2. Odpovědí je pouze stavový kód HTTP. • Ukončení jízdy – požadavek typu DELETE, povinný parametr ID jízdy, odstraní z databáze záznam v tabulce ride_open, tím jízdu ukončí a uvolní vozidlo pro další použití.
3.3.3
Čerpání pohonných hmot
Pokud probíhá jízda, je tato informace přiřazena k ní, jinak je vedena jako samostatný záznam k vozidlu. Povinnými parametry jsou množství načerpaných pohonných hmot a celková cena nákupu. Služba Dostupná vozidla Zahájení jízdy Ukončení jízdy Přidání bodu trasy Čerpání pohonných hmot
HTTP metoda GET POST DELETE PUT POST
Formát odpovědi XML plaintext plaintext stavový kód HTTP stavový kód HTTP
URI /car /ride /ride /ride /refuel
Tabulka 3.1: Přehled webových služeb
3.4
Výpočet geografických vzdáleností
Informace o délce trasy by se daly získávat již během trasování v aplikaci Klient. Přikládaly by se jako vzdálenosti od posleního bodu trasy k bodu aktuálně zpracovávanému. Vzhledem k tomu, že existuje potřeba využití této funkcionality i na straně Serveru, není nutné tyto informace přidávat do zprávy o poloze vozidla a zbytečně tak navyšovat datový tok. Další možností by bylo použití externí webové služby. Celková vzdálenost trasy se aktualizuje při každém přijatém bodě, proto je potřeba tento výpočet provést rychle, tzn. čekat na výsledek webové služby není vhodné. Protože celá aplikace staví na podrobném trasování, kde vzdálenosti mezi jednotlivými body trasy jsou v řádech metrů, lze pro vlastní implementaci vzdálenosti použít ortodromy 5 . Vlastní vzdálenost d dvou bodů o souřadnicích [ϕ1 ; λ1 ][ϕ2 ; λ2 ]: d=σ∗r
σ = arrcos(sinϕ1 sinϕ2 + cosϕ1 cosϕ2 cos(λ2 − λ1 ))
Kde r je průměrný poloměr koule v km, pro planetu Zemi r = 6372.795 Použití ortodromy není tak přesné jako použití pokročilejších metod, např. Vincentyho rovnice, která k výpočtu používá vhodnější model povrchu země než je koule – zploštělý elipsoid [26]. Jak již bylo bylo řečeno, při výpočtech malých vzdáleností je toto zkreslení zanedbatelné, proto je ortodroma dostačující. 5
nejkratší spojnice dvou bodů na kulové ploše (např. povrchu Země) [10]
26
Kapitola 4
Implementace 4.1
Monitorování přestupků řidičů
Pojmem přestupek v aplikaci nepředstavuje nutně přestupek vůči dopravnímu zákonu, ale porušení některého z omezení, která aplikace kontroluje. • dodržování maximální povolené rychlosti • pohyb vozidla, řidiče uvnitř vymezené oblasti • dodržování povinných přestávek po stanovené době jízdy • kontrola neoprávněných přestávek • čerpání neúměrného množství pohonných hmot Pokud aplikace zjistí porušení jednoho z omezení, je pomocí systémové zprávy informován samotný řidič tak jeho nadřízení (vyšší uživatelské role). V aplikaci lze ručně“ vytvářet záznamy o jízdách, které nebyly zanamenány klientskou ” aplikací. K takto vytvořeným trasám již nelze zpětně uvést veškeré informace, jako jsou čas a rychlost v konkrétním bodě trasy. Takto nelze kontrolovat povinné přestávky ani dodržování nejvyšší povolené rychlosti. K tomuto způsobu vytváření záznámů o jízdách mají oprávnění pouze uživatelské vyšších rolí a u nich není předpoklad, že by při zadávání jízdy měli být hlídáni interními omezeními, která sami vytváří. Z těchto důvodů jsou omezení kontrolována jen na výstupu webových služeb do serverové části, samotné služby řeší pouze přenos. Všechna porušení řidiče v průběhu jízdy se v aplikaci Server zobrazují v detailu konkretní jízdy.
4.1.1
Překročení maximální povolené rychlosti
Z GPS modulu lze snadno získat informace o aktuální rychlosti vozidla. Nabízí se tak možnost kontrolovat, zda řidič nepřekračuje zákonem stanovenou maximální rychlost. Získání informace o maximální povolené rychlosti v konkrétním bodu je však složitější. Některé mapové podklady tyto informace obsahují. Např. navigace společnosti TomTom a její mapové podklady poskytují tyto informace poměrně spolehlivě. Pro volné použití v cizích aplikacích však nejsou dostupné. Naštěstí OpenStreetMap podporují vkládání těchto informací do svých mapových podkladů. Některé silniční sítě jsou pokryty dostatečně, ale většina včetně té české, je pokryta 27
nedostatečně. Na obr. 4.1, který porovnává pokrytí silniční sítě Brna a Londýna, lze pozorovat zřetelně lepší pokrytí v Londýně. Informaci o maximální povolené rychlosti lze z podkladů OSM1 získat dotazem, který vybere všechny mapové elementy v určité obdelníkové oblasti. Pro každý bod trasy tak při jeho kontrole volám webovou službu OSM nad obdelníkovou oblastí určenou čtyřmi body – nejsevernějším, nejjižnějším, nejvýchodnějíším a nejzápadnějším. V praxi se dotazuji na oblast cca 25 x 25 metrů, kde testovaný bod je středem této oblasti. Odpověď je formátu XML a obsahuje popis všech geografických elementů ležících v ploše dotazovaného obdelníku. Mezi nimi se pokouším dohledat elementy popisující silnice. Pokud je silnic ve výběru nalezeno více, je upřednostněna ta se stejným ID, která byla použita u předchozího bodu trasy. Pokud je u této silnice uvedena maximální povolená rychlost, považuji tento údaj za výsledek. Většinou informace o maximální povolené rychlosti chybí, proto pokračuji v parsování odpovědi dál. Údajem, na jehož výskyt v podkladech se lze spolehnout, je údaj o typu silnice. Z něj je možné určit, jestli se jedná o dálnici, pro kterou většinou platí jiné rychlostní omezení než pro běžnou silnici. Zjištěný typ silnice si pro další zpracování uložím. Další podstatný údaj je, zda se testovaný bod nachází v obci. V OSM jsou pro tento účel použitelné atributy is_in a place. Na jejich jejich přítomnosti v odpovědi určím, že testovaný bod leží v obci. Poslední potřebný údaj je kód státu, ve kterém testovaný bod trasy leží. Pro získání této informaci se mi více osvědčila webová služba GoogleMaps než OSM. Tyto tři informace (typ pozemní komunikace, příznak obce a kód státu) jsou dostatečné informace pro získání maximální povolené rychlosti ve většině evropských zemí. V současnosti neexistuje žádná webová služba, která by informace o rychlostních limitech poskytovala na základě těchto tří informací (ani žádná jiná podobná). Proto musí být tyto data uložena přímo v aplikaci. V aplikaci jsou implementovány rychlostní limity České republiky a jejích sousedních zemí [2]. Tento způsob získávání informací jistě není ideální, nezohledňuje např. snížení maximální povolené rychlosti při deštivém počasí (Francie) a podobné další vyjímky. Protože se často stává, že bod byl chybně vyhodnocen na pozici mimo obec, aplikuje se během ukládání získaných limitů vyhlazovací filtr. Ten vybere izolované body s jinou maximální povolenou rychlostí, než mají jeho sousední body, a upraví ji na hodnotu jeho sousedů. Celý tento proces je výpočetně náročný. Kdyby byl implementován přímo do webové služby přijímající data o pozicích z klienta, příliš by brzdil odpověď klientovi. Proto je celý proces získání povolené rychlosti přesunut do nezávislého procesu, který je spouštěn v pravidelných intervalech pomocí plánovače úloh CRON. Nevýhoda tohoho řešení je zřejmá – překročení povolené rychlosti není reportováno okamžitě, ale až s jistou prodlevou, která je úměrná počtu uživatelů současně využívající systém.
4.1.2
Vymezení oblasti pohybu vozidel
Pomocí této funkcionality může administrátor vymezit oblast, ve které se mají určená vozidla nebo řidiči pohybovat. Při pohybu mimo vyznačenou oblast je toto porušení reportováno. Plochu, kde se může vozidlo svobodně pohybovat je nutné nejdříve definovat, nejsnaději vyznačením požadované plochy přímo do mapy. Nabízí se možnost definovat tuto oblast 1
OpenStreetMap – http://www.openstreetmap.com
28
Obrázek 4.1: Pokrytí rychlostních limitů v podkaldech OSM pro Londýn a Brno, barevně zvýrazněné komunikace mají definovanou maximální povolenou rychlost, odstín barvy určuje její hodnotu. Zdroj: http://www.itoworld.com/map/5.
jako kružnici se zvoleným středem a poloměrem. Taková implementace by byla jednoduchá a stejně tak jednoduchá by byla i kontrola polohy vozidla. Stačilo by porovnat vzdálenost středu kružnice a polohy vozidla s poloměrem kružnice. Mnohem podrobnější určení oblasti než kružnice umožňuje obecný polygon. Pomocí něj je možné definovat rozsah volného pohybu vozidla i na úroveň silnice v podobě úzkého polygonu, který by kopíroval její trasu. Implementace polygonu je však náročnější, stejně tak i kontrola přítomnosti body v polygonu. Pro vykreslení polygonu v mapě existují v API GoogleMaps potřebné metody. Ne však pro jeho ruční vytvoření. Pro usnadění implementace jsem proto použil vlastní modifikaci volně dostupné knihovny[5] pro tvorbu polygonů v GoogleMaps. Pro test přítomnosti bodu v polygonu existuje několik algoritmů, viz [16]. Vzhledem k faktu, že při všech operacích nad mapou se pracuje s obrovským rozlišením, bylo třeba použít takový algoritmus, který nebude iterovat nad jednotlivými body přímek tvořících polygon. Ideálně se proto jeví použití Ray-casting algoritmu 1. Input: Seznam hran polygonu polygon, testovaný bod P Output: Logická hodnota určující přítomnost testovaného bodu v polygonu count = 0 for side in polygon do if rayIntersectSide(P oint, side) then count = count + 1 endif endfor if isOdd(count) then return T RU E endif else return F ALSE endif
29
Funkce rayIntersectSide používá jako druhý parametr dílčí hrany polygonu, které je potřeba definovat. Polygon je v mapě reprezentován uspořádaným seznamem bodů a právě pořadí bodů v seznamu určuje výsledný tvar polygonu. Každou hranu definují vždy dva sousední body. Je tedy nutné perzistentně ukládat pořadí dílčích bodů. Záznam bodu v databázi proto obsahuje referenci na bod sousední, viz kompletní ER diagram v příloze B. To zaručí správné pořadí bodů i při transformacích typu vložení bodu nového nebo odstranění stávajícího. Samotná funkce rayIntersectSide testuje, jestli paprsek vyslaný po ose x s y souřadnicí testovaného bodu protne aktuálně testovanou hranu. Rozhodnutí, zda bod leží v polygonu, závísí na počtu průsečíků. Pokud je lichý, bod leží v polygonu, viz obr. 4.2. Výhoda tohoto algoritmu je, že k testu průniku hrany stačí znát souřadnice jejích hraničních bodů a nemusí se nikdy iterovat po dílčích bodech hrany.
Obrázek 4.2: Princip algoritmu Ray-casting [12].
Nejjednodušší polygon pro testování přítomnosti bodu uvnitř jeho plochy je obecný obdélník. Ten je definován dvěma intervaly hodnot (x, y). Bod je definován souřadnicemi X a Y. Leží-li obě souřadnice v příslušných intervalech obdélníku, bod se nachází uvnitř plochy obdélníku. Nabízí se tedy jednoduchá optimalizace původního algoritmu 1, pro kterou je nutné si plochu obecného polygonu rozšířit na plochu obecného obdelníku. V praxi to znamená, že se při vytváření obecného polygonu ze všech jeho vrcholů uloží extrémy v osách x a y. Ty definují potřebný obdélník. Samotná optimalizace tak spočívá v zabránění vykonání složitějšího algoritmu raycasting, pokud nepřítomnost bodu odhalí již algoritmus na přítomnost bodu v obdélníku obsahujícím polygon.
4.1.3
Povinné přestávky
Administrátor může v aplikaci nastavit, zda se u firemních řidičů má kontrolovat dodržovaní povinných přestávek podle aktuálních legislativních předpisů. V aplikaci jsem prozatím implementoval pravidla platná pro EU[8]. Nebyla implementována pravidla týkající se dvojic střídajících se řidičů, z důvodu, že systém byl od počátku koncipován pro jednono řidiče ve vozidle a změna tohoto principu by nutně vyvolala potřebu dalších rozsáhlých změn. Mimo tato legislativní omezení, která jsou zaměřena spíše na dodržování týdenní pracovní doby, lze definovat vlastní firemní pravidla pro povinné přestávky. Děje se tak určením maximální možné časové délky jízdy bez přestávky a minimální délkou přestávky, která po tomto úseku jízdy musí následovat.
30
Výpočetní náročnost kontroly dodržování povinných přestávek je oproti kontrole překračování povolené rychlosti výrazně menší, a proto mohla být zakomponována přímo do webové služby.
4.1.4
Kontrola prostojů
Aplikace umožňuje administrátorovi definovat časový úsek, během kterého vozidlo musí urazit minimální vzdálenost 30m. Tato hodnota je zavedena kvůli toleranci odchylek, kdy GPS hlásí změnu polohy aniž by k ní skutečně došlo. Většina odchylek je výrazně menší než zmíněných 30m, takže je tato hodnota spolehlivě filtruje. Kromě přestávek, kteté řidič pomocí klientské aplikace nahlásí, tak aplikace při volání webové služby pro vkládání bodu jízdy označí prostoje, které nenahlásil.
4.1.5
Čerpání pohonných hmot
Tato jednoduchá kontrola hlídá, jestli řidič nečerpal více pohonných hmot, než je vůbec možné vzhledem k objemu nádrže vozidla. Nezohledňuj však nijak aktuální množství paliva v nádrži. V současnosti tak tato kontrola neodhalí krádeže spočívající v častém načerpání po limit plné nádrže. Podezření k něčemu takovému však může administrátor získat ze statistik spotřeby, kde se zobrazují k jednotlivým vozidlům odchylky od výrobcem udávané kombinované spotřeby.
4.2
Multilingválnost aplikace
Přestože je aplikace primárně určena pro použití v jednom jazyce, pro případné budoucí rozšíření je vhodné myslet již při jejím vývoji na možnost lokalizace do jiných jazyků. Jak na straně Klienta, tak na straně Serveru jsem proto implementoval podporu českého a anglického jazyka. U Serveru to znamenalo zapouzdřit veškeré zobrazované řetězce v uživatelském rozhraní překládací funkcí frameworku Kohana. Který jazyk se pro překlad použije, závisí na uživatelem aktuálně nastaveném jazyce prostředí. Lokalizace na straně klienta je zajištěna podobně. Veškeré řetězce jsou zde definovány ve XML soborech – zdrojích. Záleží tedy na nastavení uživatelského prostředí, která mutace zdrojů se použije. Lokalizací na úrovni multilingválnosti samotných dat není nutné se v této aplikaci zabývat. Prakticky veškerá ukládaná data mají číselnou podobu. Pokud jsou přece jen některé informace ukládány v podobě textů – řetězců, budou prezentovány jen uživatelům jedné firmy. U nich lze předpokládat společnou řeč. Pro číselná data je potřeba zajistit převod do uživatelem požadovaných jednotek. Uživatelům používajícím anglické prostředí se tak budou vzdálenosti zobrazovat v mílích apd. V databázi jsou data ukládána v hodnotách jednotek SI2 . Uživatelský vstup je pomocí funkcí do těchto SI jednotek při ukládání převeden. Na výstupu jsou data převedená inverzní funkcí do uživatelem očekávané podoby. Převod z jedné jednotky do jiné je realizován většinou pouze násobením převodní konstanty, viz schéma uložení jednotek v databázi na obr. 4.3. Nesjednoceně se naopak ukládají finanční částky. Je to z důvodu složitějšího zjišťování aktuálního kurzu a nabízí se to tak jako možné budoucí rozšíření. Které jednotky jsou v systému zavedeny, popisuje tbl. 4.1 2
Le Syst`eme International d’Unités [13]
31
Obrázek 4.3: Schéma nastavení uživatelkého prostředí – jednotek a jazyka. Veličina délka (vzdálenost) délka (vzdálenost) objem objem spotřeba spotřeba
Prosředí cs en cs en cs en
Jednotka kilometr britská míle litr britský galon l/100km MPG3
Převodní konstanta 1,0 0,621371 1,0 0,219974 1,0 2,35
Tabulka 4.1: Současné převodní jednotky v systému.
4.3
Bezpečnost
Protože všechny části systému přichází do styku s citlivými daty, bylo třeba otázku bezpečnosti řešit u každé z nich.
4.3.1
Server
Data, se kterými informační systém serverové aplikace pracuje, jsou důvěrná a závislá na identitě uživatele. Základním bezpečnostním prvkem je ověření identity uživatele – autentizace. Ta je prováděna na základě e-mailové adresy a hesla uživatele. Heslo uživatel získá při registraci. Celý proces autentizace by bylo možné přenést na některou autentizační webovou službu, např. OpenID [27]. Tyto služby mají za cíl uživatelům odlehčit od nutnosti pamatovat si velké množství přihlašovacích údajů k různým webovým aplikacím. Časté vyplňování registračních údajů totiž může být důvodem, proč uživatel ztratí ostražitost a začne porušovat základní bezpečnostní principy – např. používáním jednotného hesla pro všechny využívané služby. To vede ke zvýšení pravděpodobnosti, že z některé služby heslo unikne a tím bude útočníkovi otevřena cesta ke všem účtům se stejným heslem. Vzhledem k tomu, že účty u zmiňovaných autentizačních služeb jsou spojeny více s osobní než firemní identitou uživatele a že implementace autentizace přes třetí stranu by u klientské Android aplikace byla komplikovaná, rozhodnul jsem se implementovat vlastní autentizační funckionalitu. Politika hesel, pro kterou jsem se rozhodl, spočívá v tom, že uživatel není schopen ovlivnit podobu hesla. To je vygenerováno náhodně při vytvoření účtu a změnit jej živatel může maximálně opět na nově náhodně vygenerované (např. když jej zapomene). V klientské aplikaci je stejně jako u webových prohlížečů pro přístup k serverové aplikaci možnost heslo si uložit. Uživatel si jej tak ani nemusí pamatovat. Heslo je generováno nejen ze znaků abecedy a má jistou minimální délku. To by mělo způsobit větší odolnosti proti slovníkovým útokům a útokům hrubou silou [25]. Hesla jsou v databázi uložena v hashované podobě. Jako hashovací algoritmus jsem použil SHA-256. Dalším použitým ochraným prvkem je metoda tzv. solení hesel [25]. 32
Tato opatření by byla prakticky bezcenná, pokud by uživatelem vyplněné heslo v registračním formuláři bylo přenášeno po síti v prosté textové podobě. K zabepečení nejen přihlašování, ale veškeré komunikace v privátní zóně serverové aplikace jsem použil protokol HTTPS, nadstavbu nad běžným HTTP. Ten využívá protokolů SSL respektivě TSL k asymetrickému šifrování datového toku. Během inicializace takto šifrovaného spojení se server musí identifikovat vůči klientovi. To se děje prostřednictvým digitálního certifikátu. Nastavení certifikátu je závislé již na konkrétní instalaci serverové aplikace, u demo aplikace je použit certifikát zdarma přidělený poskytovatelem hostingu. Jeho vydavatelem tedy není žádná oficiální certifikační autorita, proto ho webové prohlížeče považují za nedůvěryhodný. Pro potřeby demo aplikace je tento stav dostačující. Po úspěšné autorizaci se uloží identita uživatele do SESSION, kde zůstane až do odhlášení nebo vypršení časového limitu bez uživatelovi aktivity. Přes HTTP zůstává dostupná pouze veřejná část serverové aplikace. Pokud se autentizovaný a autorizovaný uživatel pokusí vyvolat akci privátní sekce přes HTTP, je jeho požadavek automaticky přesměrován na podobu přes HTTPS. To eliminuje přenos nešifrovaných dat, pokud uživatel např. ručně modifikuje URL a změní protokol. Částečně z bezpečnostních důvodů jsem nepoužil pro uložení tras jízd formátu pro ukládání geografických dat KML4 . Takový soubor by bylo možné jednoduše předat API GoogleMaps a to už by se postaralo o jeho vykreslení. Podmínkou ale je, aby takový soubor byl veřejně dostupný pro načtení webovou službou. Tím by se stal ale dostupným pro kohokoliv a to je nepřípustné. Proto jsou trasy vykreslovány složitějším způsobem – voláním dílčích metod API nad geografickými primitivy (body, úsečky, polygony). Řešení další části bezpečnostní problematiky – autorizace, která využívá právě identity uložené v SESSION, je vysvětleno v popisu administračního rozhraní – podkapitola 3.1.2.
4.3.2
Klient a webové služby
Základní principy operačního sytému Android zajišťují bezpečnost dat aplikace na vysoké úrovni (viz podkapitola 2.1.3 o platformě Android). Nejsou tak ohrožena případným výskytem mallware 5 v telefonu. Veškeré volané webové služby serveru vyžadují autentizaci uživatele. Použití autentizační funckionality z informačního systému by bylo možné, ale technicky zbytečně komplikované. Využil jsem toho, že protokol HTTP obsahuje vlastní prostředky pro autentizaci [6]. Pokusil jsem se implementovat metodu Digest, která přenáší autentizační údaje v šifrované podobě, ale narazil jsem na nedostatečnou podporu ze strany frameworku Android. Řešením by bylo využít některou externí Java knihovnu, ale zvětšovat tak velikost aplikace je zbytečné. Protože je třeba šifrovat veškerou komunikaci s webovou službou, jsou volány veškré služby opět nad HTTPS. Proto je dostačující využít metodu Basic, která přihlašovací údaje odesílá v prosté podobě a jejíž podpora je ve frameworku Android dobrá. Použití certifikátů Jako netriviální se nakonec ukázalo donutit operační systém Android, aby důvěřoval použitému certifikátu. Protože není podepsán certifikační autoritou, odmítal jej automaticky přijmout, což je bezesporu správné chování. 4 5
Formát pro ukládání geografických dat, založený na XML Program se zákeřným chováním – viry, trojské koně apd.
33
Aby jej považoval za důvěryhodný, nejprve jsem pomocí kryptografické knihovny Bouncy Castle vytvořil nové úložiště klíčů (soubor .bks) a do něj umístil zmíněný veřejný klíč. Toto úložiště klíčů jsem přiložil do aplikace. V aplikaci bylo poté potřeba přetížit třídu frameworku DefaultHttpClient (viz diagram tříd Klienta 3.7) tak, aby při ověřování certifikátů brala v potaz nejen systémové úložiště klíčů, ale i přidané úložiště aplikační. Nakonec, protože je použitý certifikát vystaven pro doménu poskytovatele hostingu, bylo třeba vytvořit třídu AppSSLVerifier, kterou bude používat HttpClient pro vlastní ověřování. Tento potomek zajistí, aby použitý certifikát byl důvěrný i pro doménu s demo aplikací. Optimalizace Od počátku koncipované webové služby jako rychlé a jednoduché se díky šifrování podstatně zesložitili. Během testování funkcionality systému v provozu se projevila jako slabina nutnost vytváření šifrovaného spojení při odesílání každého bodu, kdy režie s navázáním bezpečného spojení byla v obrovském nepoměru k velikosti vlastních dat s informacemi. Během jízdy tak docházelo k vytváření více požadavků, než byl telefon schopen zpracovat. Telefon začal mít problémy s odezvou ovládání a docházelo ke ztrátám některých informací, pravděpodobně z důvodu, že se operační systém Android snažil vzniklou kritickou situaci řešit zahazovaním dat. Jednoduchým řešením bylo informace o poloze bufferovat a během jednoho spojení jich odeslat více. Bohatě dostačující se úkazala velikost bufferu pro 10 záznámů.
34
Kapitola 5
Testování a shodnocení vzniklé aplikace 5.1
Aplikační prostředí
Aplikace Klient byla vyvýjena pro platformu Android verze 2.2. Testování v provozu probíhalo na telefonu HTC Wildfire. Tento telefon patří do kategorie levných chytrých telefonů. Na trh byl uveden již v roce 2010 a s modely aktuálně uváděnými na trh se výkonnostně nemůže srovnávat. Díky úspěšnému testovaní na méně výkonném zařízení však lze předpokládat bezproblémový provoz na všech kompatibilních zařízeních, zejména těch výkonnějších, kterých je většina. Díky vývojovému prostředí platformy Android 2.1.1 bylo možno v emulátoru otestovat funkčnost i pro verze 2.1 a 2.3.3. Podpora těchto tří verzí znamená v součtu pokrytí více než 90% všech Android zařízení[11].
5.2 5.2.1
Testování Klient
Testování v terénu probíhalo uvniř osobního vozidla během jízd různých délek a terénů. Bezproblémové se ukázalo bufferování dat v případě zhoršení nebo úplného výpadku pokrytí mobilní sítě a s tím souvisejícího připojení k internetu. V některých typech terénu jako jsou hluboká zalesněná údolí dochází k výpadkům GPS signálu. Tyto výpadky bývají pouze krátké a většinou nezpůsobí výrazné zkreslení odesílaných dat. Úseky trasy s výpadkem GPS se v aplikaci projevují jako napřímené linie, často nekopírující křivku komunikace. V současnosti není v aplikaci implementován způsob, jak chybějící data ručně doplnit. Klientská aplikace bývá spuštěna dlouhodobě, často na pozadí a s telefonem lze během jejího spuštění nadále bezproblémově pracovat. Dlouhodobé využívání GPS modulu a připojení k internetu má však vliv na výdrž baterie. Během testování jsem ale nepozoroval výrazný rozdíl vůči aplikacím, které využívají stejné funkcionality (GPS, GPRS), jako je např. navigační aplikace společnosti Google.
35
5.2.2
Server
Implementace webových služeb se projevila jako spolehlivá a v komunikační části nebyl zaznamenán žádný problém. Demo serverové aplikace s veškerou funkcionalitou včetně možnosti stažení aplikace Klient je zveřejněno na http://hojodoro.papope.cz a je volně k vyzkoušení. Této instalace bylo využíváno i pro testování. Produkčním prostředím je webový server Apache, PHP verze 5.3.12, databáze MySQL 5.1.53. Z důvodu využívání webových služeb je nutné mít PHP zkompilováno s knihovnou cURL. Z knihoven na aplikační úrovni je nutná přítomnost frameworku Kohana verze 3.1 a jQuery minimální verze 1.8.17. Aplikaci Server jsem vyvýjel pro použití ve webovém prohlížeči Chrome verze 18, úspěšně testovány byly také prohlížeče Firefox 12 a Opera 11.62. U serverové aplikace se během testování neosvědčil způsob získávání nejvyšší povolené rychlosti v konkrétním bodě. Čas potřebný pro dotazovaní dvojice webových služeb, následné čekání na odpověď, její zpracování a vyhodnocení způsobuje prodlevu v jednotkách sekund. Cronová úloha, i když je spuštěna s nejkratším možným intervalem 5 minut, tak zvládá odbavovat minimum zároveň probíhajících jízd. Ke kompletnímu zpracování dat tak dochází se spožděním. Větší problém však představuje kvalita takto získaných informací o nejvyšší povolené rychlosti. Pozice v obci bývají často vyhodnoceny jako mimo obec. Jednoduchý vyhlazovací filtr tyto nepřesnosti odstraňuje jen částečně, výjmečně naopak zanáší i chyby nové.
5.3 5.3.1
Porovnání s existujícími řešení Aplikace LogBookie a Kniha-jízd-zdarma.cz
Až během vývoje aplikace popisované v této práci, byl uveden do provozu v červenci 2011 produkt společnosti DHO1 , který vychází z placeného produktu LogBookie2 stejné společnosti. Vzhledem k tomu, že jde o webovou aplikaci a její používání je zdarma, jedná se tak o přímeho konkuretna vyvíjené aplikace. Společnost DHO má dlouholeté zkušenosti v oblasti satelitního sledování. Nabízí rozsáhlou řadu produktů – od sledování osob, osobních i nákladních vozidel až po monitoring lodí. Pro zajištění těchto služeb využívá především integrovaných GPS modulů ve vozidlech. Díky tomu nelze systém zaměstnanci jednoduše ošidit. Velkou pomocí se takový modul může stát při krádeži vozidla. V nabídce lze najít dokonce produkt, který umožnňuje ke sledování využít telefonu bez GPS modulu. Informace o poloze tak pravděpodobně získává pouze z telefonní sítě. O přesnosti takové služby se v jejím popisu společnost nezmiňuje, ale kvalita služeb založených na GPS dosahovat nemůže. Její výhodou je ale to, že díky nízké energitcké náročnosti toho řešení vydrží být telefon monitorován podstatně delší dobu. Co se týče konkrétní funkcionality, základní pilíře má podobné jako mnou vytvářená aplikace. Statistiky o jízdách, sledování dodržování rychlostí jsou u tohoto produktu samozřejmostí. Stejně jako aplikace této práce, nabízí i vymezení oblasti pohybu vozidel a to dokonce tak, že kromě oblastí vymezených pro pohyb uvnitř, umožní definovat i zakázané oblasti do kterých se vozidlo nesmí dostat. 1 2
http://www.kniha-jizd-zdarma.cz/ http://www.logbookie.eu/
36
Oblastí, ve které mou aplikaci výrazně převyšuje je správa údržby vozidla. V aplikaci je např. možné evidovat termíny technických kontrol, náklady na údržbu vozidla a zajímavá je zejména funkcionalita, která umožní zaznamenat historii ujetých kilometrů pro každou pneumatiku vozidla zvlášť. V případě jejich různého stáří sýstém přesně upozorní, která z nich se již blíží ke konci své životnosti. Aplikace Kniha-jízd-zdarma.cz, která je volně k dispozici a pro srovnání s mou aplikací se tak hodí více, je v podstatě jen o velké množství funkcí ochuzená LogBookie. Má také propracovaný systém reportů, vizualizací dat do grafů. Chybí jí ale jakákoliv interakce s mapovými podklady. Přehleně působí kalendářové přehledy oproti tabulkovým v mé aplikaci. Oproti LogBookie implementuje systém rezervací vozidla ve firmě, což v praxi znamená, že v kalendáři lze vidět, kdo na kdy má rezervované vozidlo. Pokročilé funkce využívajících dat GPS jako v LogBookie a v mé aplikaci Kniha-jízd-zdarma.cz neobsahuje. Neumožňuje ani jejich import, který naopak zvládá většina ostatních aplikací tohoho zaměření. Důvod je zřejmý – Kniha-jízd-zdarma.cz má uživatele motivovat k využítí její propracovanější verze LogBookie, která je ale placená. Ve srovnání s mou aplikací je LogBookie skutečně profesionálním řešením, u kterého ovšem nasazení a následný provoz vyžaduje nemalé finanční prostředky. Co této aplikaci oproti mé chybí, je tak snad jen možnost kontroly povinných přestávek. Vestavěné GPS moduly jako klienti přece jen přes své výhody nenabízí tolik možností interakce jako chytrý mobilní telefon a v tohmto ohledu je potenciál mého řešení větší.
37
Závěr Cílem práce bylo najít vhodný způsob, jak získat z chytrého mobilního telefonu data pro co nejjednodušší vedení elektronické knihy jízd. Protože podobných řešení existuje na trhu mnoho, bylo mým úmyslem také nabídnout uživatelům nové funkce, které konkurenční produkty nemají. K dosažení tohoto cíle používá aplikace nenákladných technologíí a kombinace několika zdarma dostupných webových služeb. Vzniklý informační systém serverové části lze chápat také jako ukázku, jakými způsoby lze navrhnutou architekturu využít. Aplikace je unikátní v použití chytrého telefonu jako trasovací jednotky a především ve způsobu její přímé komunikace se serverovou části. V oblasti monitorování pohybu je plně srovnatelná s profesionálními produkty. Lokalizační funkcionalitu navíc kombinuje s evidenčními schopnostmi knihy jízd, může tak být pro nenáročného zákazníka dostatečná i v oblasti vedení účetní agendy vozového parku. V této oblasti však za specializovanými produkty co do rozsahu nabízených funkcí zaostává. Oblibu by tak mohla najít u zákazníků, kteří nepožadují pokročilé účetní funkce, ale naopak využijí zdarma dostupných možností lokalizace a trasování. Zmiňované nedostatky aplikace jsou zároveň možnosti budoucího rozšíření. Především se ale nabízí využít univerzální webové služby, které umožní snadnou implementaci klientské aplikace pro jiné platformy, např. iPhone. Z nasbíraných dat je možné rekonstruovat graf převýšení trasy, zaznamenávat prudké změny rychlosti a díky tomu přesněji analyzovat spotřebu pohonných hmot. Architektura serveru se sítí flexibilních klientů umožňuje vznik nové služby určené pro vzájemné informování o dopravní situaci na cestách. Uživatel by odeslal na server popis situaci v místech, kterými právě projíždí. Server by tyto informace mohl šířit mezi ostatní klienty, kteří se k danému místu právě přibližují. Možností se v této oblasti nabízí mnoho.
38
Literatura [1] Android - The Developer’s Guide [online]. 2011-04-30 [cit. 2011-04-30]. Dostupné na:
. [2] Default speed limits by country [online]. 2012-04-12 [cit. 2012-05-08]. Dostupné na: . [3] Designing for Performance [online]. [cit. 2012-04-30]. Dostupné na: . [4] Framework [online]. 2011-02-01 [cit. 2011-04-29]. Dostupné na: . [5] Google Map API v3 polygon shape creator [online]. 2010-06-24 [cit. 2011-04-30]. Dostupné na: . [6] HTTP authentication with PHP [online]. 2011-05-06 [cit. 2011-05-06]. Dostupné na: . [7] Kohana user guide [online]. [cit. 2011-05-09]. Dostupné na: . [8] Nařízení evropského parlamentu a rady (ES) č. 561/2006. Dostupné na: . [9] Openstreetmap [online]. 2011-04-20 [cit. 2011-04-30]. Dostupné na: . [10] Ortodroma [online]. 2010-09-08 [cit. 2011-04-05]. Dostupné na: . [11] Platform Versions. Dostupné na: . [12] Point in polygon [online]. 2011-03-26 [cit. 2012-05-5]. Dostupné na: . [13] Soustava SI [online]. 2010-02 [cit. 2012-05-12]. Dostupné na: . [14] DANĚK, P. Velký test PHP frameworků [online]. 2008-08-28 [cit. 2011-04-30]. Dostupné na: .
39
[15] DVOŘÁK, M. Návrhové vzory. Praha: FIS VŠE, 2003. Diplomová práce. Dostupné na: . [16] ERIC, H. Graphic Gems IV. 1. vyd. San Diego: Academic Press, 1994. Point in Polygon Strategies. Dostupné na: . ISBN ISBN 978-0-596-007 12-6. [17] FREEMAN, E. Head First Design Patterns. 1. vyd. Sebastopol, California: O’REILLY, 2004. ISBN ISBN 978-0-596-007 12-6. [18] FREYSSINET, S. de. Scaling Web Applications with HMVC [online]. 2010-02-22 [cit. 2011-04-30]. Dostupné na: . [19] JAVOREK, J. Evidence geografických tras uživatele. Brno: FIT VUT, 2009. Bakalářská práce. [20] LUKÁŠOVÁ, J. Kniha jízd nebyla zrušena, jde jen o nafouknutou bublinu [online]. 2010-01-11 [cit. 2011-04-28]. Dostupné na: . [21] MAHMOUD, Q. H. Service-Oriented Architecture (SOA) and Web Services [online]. 2005-04 [cit. 2011-04-30]. Dostupné na: . [22] MIKUDÍK, R. OpenStreetMap mají zatopit Google mapám. Pomůže jim Microsoft. Dostupné na: . [23] NEWTON, A. JQuery vs MooTools [online]. 2009-05 [cit. 2011-04-30]. Dostupné na: . [24] PAL;, J. C. R. K. G. HMVC: The layered pattern for developing strong client tiers [online]. 2000-07-21 [cit. 2011-04-30]. Dostupné na: . [25] TICHÝ, J. Solení hesel aneb sůl nad zlato [online]. 2007-10-30 [cit. 2011-05-05]. Dostupné na: . [26] VINCENTY, T. Survey review. 23. vyd. London: DMAAC Geodetic Survey, 1975. Direct and Inverse Solution on the Ellipsoid with application of nested equations. [27] ČERNÝ, M. OpenID míří na české weby [online]. 2008-08-18 [cit. 2011-05-05]. Dostupné na: .
40
Seznam příloh A Obsah CD
42
B Kompletní ER diagram
43
41
Příloha A
Obsah CD • Adresář klient – soubory se zdrojovým kódem aplikace Klient • Adresář server – sobory se zdrojovým kódem aplikace Server • Soubor poster.pdf – plakát prezentující vytvořenou aplikaci • Soubor readme.txt – návod na sprovoznění aplikace
42
Příloha B
Kompletní ER diagram Z důvodu přehlednosti je rozdělen do dvou částí, přičemž některé tabulky se mohou opakovat v obou částech. Část na obr. B.1. znázororňuje především uložení jízd a jejich vazby na kontrolovaná omezení. Část na obr. B.2. zobrazuje ostatní entitní množiny v systému.
43
Obrázek B.1: Kompletní ER diagram aplikace Server (1. část).
44
Obrázek B.2: Kompletní ER diagram aplikace Server (2. část).
45
