Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky. Mobilní aplikace pro rezervace objektů

Za´padoˇceska´ univerzita v Plzni Fakulta aplikovanyćh vˇed Katedra informatiky a vy´poˇcetn´ı techniky

Diplomov´ a pr´ ace Mobiln´ı aplikace pro rezervace objekt˚ u

Plzeˇ n, 2013

Lukáˇs Gemela

Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem diplomovou práci vypracoval samostatnˇe a v´ yhradnˇe s pouˇzit´ım citovan´ ych pramen˚ u. V Plzni dne 13. kvˇetna 2013 Lukáˇs Gemela

Abstract Currently there is no information system that enables effective lending and reservation management of movable and immovable properties in a general way. This thesis is dedicated to solving this problem by using the unique possibilities of mobile devices. First, the problem is generalized and the usability of mobile device technologies is analyzed. Afterwards, a specific implementation of the information system is introduced. The system is based on the client-server architecture in which the client is represented by a mobile device using the Android operating system.

Obsah ´ 1 Uvod 2 Problematika spr´ avy v´ yp˚ ujˇ cek 2.1 Motivace . . . . . . . . . . . . . . 2.2 Existuj´ıc´ı pˇr´ıbuzné systémy . . . 2.3 Generalizace problému v´ yp˚ ujˇcek 2.4 Shrnut´ı . . . . . . . . . . . . . .

1

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

2 2 4 5 15

3 Mobiln´ı zaˇ r´ızen´ı 3.1 Mobiln´ı zaˇr´ızen´ı jako pracovn´ı nástroj . 3.2 Technické prostˇredky mobiln´ıch zaˇr´ızen´ı 3.3 Mobiln´ı aplikaˇcn´ı platformy . . . . . . . 3.4 V´ yvoj mobiln´ıch aplikac´ı . . . . . . . . . 3.5 Shrnut´ı . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

16 16 17 23 27 31

4 Poˇ zadavky na syst´ em spr´ avy rezervac´ı 4.1 Vyuˇzitelnost mobiln´ıch zaˇr´ızen´ı . . . . . 4.2 Obecn´ y popis systému . . . . . . . . . . 4.3 Funkce webového rozhran´ı . . . . . . . . 4.4 Funkce klientské aplikace . . . . . . . . 4.5 Mimofunkˇcn´ı poˇzadavky . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

32 32 36 38 50 54

5 Moˇ znosti n´ avrhu webov´ ych aplikac´ı 5.1 V´ıcevrstv´ a architektura . . . . . . . 5.2 Aplikaˇcn´ı vrstva . . . . . . . . . . . 5.3 Vrstva persistence dat . . . . . . . . 5.4 Prezentaˇcn´ı vrstva . . . . . . . . . . 5.5 Architektura orientovaná na sluˇzby . 5.6 Technologické n´ astroje pro v´ yvoj . . 5.7 Shrnut´ı . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

55 55 58 60 65 75 78 80

. . . . . . .

. . . . . . .

6 RAT - Reserve A Thing! 6.1 Informaˇcn´ı systém RAT . . . 6.2 RAT server . . . . . . . . . . 6.3 RatDroid . . . . . . . . . . . 6.4 RatSharp . . . . . . . . . . . 6.5 Testov´ an´ı a nasazen´ı systému

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

81 . 81 . 82 . 99 . 104 . 105

7 Z´ avˇ er

106

A Rozvrˇ zen´ı mobiln´ı aplikace

107

B Popis webov´ ych REST sluˇ zeb

113

C Uˇ zivatelsk´ a pˇ r´ıruˇ cka 118 C.1 Webové rozhran´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 C.2 Aplikace RatDroid . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 D Administr´ atorsk´ a dokumentace 132 D.1 Nasazen´ı webové aplikace . . . . . . . . . . . . . . . . . . . . . . . 132 D.2 Nasazen´ı mobiln´ı aplikace RatDroid . . . . . . . . . . . . . . . . . 135 E Obsah pˇ riloˇ zen´ eho m´ edia

137

´ 1 Uvod Témˇeˇr v kaˇzdé rozs´ ahlejˇs´ı organizaci obvykle existuje mnoˇzina inventárn´ıho majetku, kter´ y je dostupn´ y ˇclen˚ um této organizace k zap˚ ujˇcen´ı nebo doˇcasnému vyuˇz´ıván´ı. Mluv´ıme-li o tomto majetku, máme na mysli jak vˇeci movité, jako je napˇr´ıklad v´ ypoˇcetn´ı technika nebo kanceláˇrské pom˚ ucky, tak vˇeci nemovité, jako jsou m´ıstnosti, budovy atp. Za modelovou organizaci si m˚ uˇzeme pˇredstavit napˇr´ıklad neziskové organizace, malé a stˇredn´ı podniky nebo vzdˇelávac´ı instituce. Term´ınem v´ yp˚ ujˇcka“ pˇredmˇetu poté nemysl´ıme pˇredán´ı do déletrvaj´ıc´ıho uˇz´ıván´ı v ˇrádech ” t´ ydn˚ u nebo mˇes´ıc˚ u, ale kr´ atkodobé zap˚ ujˇcen´ı pˇredmˇetu jeho ˇzadateli s t´ım pˇredpokladem, ˇze se oˇcek´ av´ a jeho opˇetovné navrácen´ı v pˇredem domluveném term´ınu tak, aby si pˇredmˇet mohl p˚ ujˇcit jin´ y ˇzadatel. Tato diplomov´ a pr´ ace se zab´ yvá problémem správy v´ yp˚ ujˇcek movit´ ych i nemovit´ ych objekt˚ u a implementac´ı jeho ˇreˇsen´ı za pomoci unikátn´ıch moˇznost´ı mobiln´ıch zaˇr´ızen´ı. Nejprve bude tento problém zobecnˇen a následnˇe budou nast´ınˇeny základn´ı poˇzadavky kladené na vznikaj´ıc´ı systém tak, aby bylo moˇzné správu v´ yp˚ ujˇcek efektivnˇe ˇreˇsit (Kap. 2). V Kap. 3 bude ˇctenáˇr seznámen s nejrozˇs´ıˇrenˇejˇs´ımi mobiln´ımi technologiemi a platformami. Následnˇe se v Kap. 4 ˇctenáˇr seznám´ı s u ´plnou specifikac´ı poˇzadavk˚ u, které bude systém implementovat za vyuˇzit´ı technologi´ı mobiln´ıch zaˇr´ızen´ı. V realizaˇcn´ı ˇcásti (Kap. 5) budou rozebrána obecná architektonick´ a ˇreˇsen´ı informaˇcn´ıch systém˚ u s ohledem na platformu Java, aby byla poté ukázána konkrétn´ı implementace informaˇcn´ıho systému pro p˚ ujˇcován´ı a rezervaci objekt˚ u (Kap. 6).

1

2 Problematika správy výp˚ ujˇ cek V této kapitole rozebereme st´ avaj´ıc´ı problém, zobecn´ıme jej do podoby logického modelu a n´ aslednˇe nast´ın´ıme z´ akladn´ı poˇzadavky na systém tak, aby bylo moˇzné správu v´ yp˚ ujˇcek efektivnˇe ˇreˇsit.

2.1

Motivace

Motivac´ı pro vytvoˇren´ı této pr´ ace byla jistá nepraktiˇcnost pouˇz´ıván´ı stávaj´ıc´ıho systému spr´ avy v´ yp˚ ujˇcek movit´ ych vˇec´ı na Katedˇre informatiky a v´ ypoˇcetn´ı techniky pˇri Z´ apadoˇceské Univerzitˇe v Plzni. Naskytla se otázka, zdali by nebylo moˇzné uˇcinit spr´ avu v´ yp˚ ujˇcek efektivnˇejˇs´ı, jednoduˇsˇs´ı a pr˚ uchodnˇejˇs´ı jak pro uˇzivatele, tak pro spr´ avce tohoto systému. Problematika správy v´ yp˚ ujˇcek a rezervac´ı vˇsak m˚ uˇze b´ yt vztaˇzena na libovolnou organizaci, kde k tˇemto aktivitám pravidelnˇe docház´ı, a lze tedy ˇr´ıci, ˇze se jedná o obecn´ y problém.

2.1.1

Pˇ r´ıpadov´ a studie

Na katedˇre existuje mnoˇzina movit´ ych objekt˚ u (notebook˚ u a dataprojektor˚ u), které si mohou zamˇestnanci a spolupracovn´ıci katedry na omezenou dobu zap˚ ujˇcit. Toto technické vybaven´ı je dostupné v sekretariátu katedry a je moˇzné je od sebe rozliˇsit podle pap´ırového ˇst´ıtku s identifikaˇcn´ım ˇc´ıslem, kter´ y je fyzicky pˇripevnˇen na vybaven´ı. Na katedˇre je zaveden v´ yp˚ ujˇcn´ı list“, kde kaˇzd´ y zamˇestananec pˇreb´ıraj´ıc´ı pˇred” mˇet potvrzuje pˇrevzet´ı pˇredmˇetu a zavazuje se, ˇze jej do dohodnutého term´ınu opˇet vrát´ı. Je tˇreba definovat datum a ˇcas v´ yp˚ ujˇcky a vrácen´ı objektu. V´ yp˚ ujˇcn´ı list je veden v podobˇe pap´ırového formuláˇre. Typick´ y scénáˇr v´ yp˚ ujˇcky je tedy takov´ y, ˇze vyuˇcuj´ıc´ı poˇzaduj´ıc´ı notebook pro svou pˇrednáˇsku mus´ı nejprve nalézt identifikaˇcn´ı ˇc´ıslo vyˇzadovaného notebooku a poté jej mus´ı spolu se sv´ ym jménem a datem v´ yp˚ ujˇcky a datem vr´ acen´ı zanést do jednoho ˇrádku pap´ırového formuláˇre. Pˇri fyzickém vr´ acen´ı notebooku poté vyuˇcuj´ıc´ı obvykle stvrd´ı tento akt vlastn´ım podpisem ˇr´ adky s u ´daji o vyp˚ ujˇcen´ı objektu. Je také moˇzné z´ apisem do jiného formuláˇre vytváˇret rezervace vybaven´ı. Pˇri vytváˇren´ı rezervac´ı se mus´ı zamˇestnanec manuáln´ım procházen´ım jiˇz vytvoˇren´ ych záznam˚ u ujistit, ˇze jeho rezervace se nekryje s jinou jiˇz dˇr´ıve vytvoˇrenou rezervac´ı. Je tˇreba specifikovat rezervované zaˇr´ızen´ı, datum a ˇcasové rozmez´ı rezervace. Slov-

2

Problematika správy výp˚ ujˇcek

Motivace

n´ım popisem je také moˇzné rezervace opakovat v ˇcase – zamˇestnanci si rezervuj´ı vybaven´ı podle rozvrhov´ ych akc´ı a ty se v rámci semestru opakuj´ı. Tyto pravidelné rezervace jsou poté zamˇestnanci sekretariátu katedry znázorˇ novány v t´ ydenn´ım pap´ırovém kalend´ aˇri, kde je graficky podchycena délka trván´ı rezervace a jména vˇsech u ´ˇcastn´ık˚ u. Spr´ ava nemovit´ ych objekt˚ u (tj. m´ıstnost´ı) je ˇreˇsena pomoc´ı celouniverzitn´ıho informaˇcn´ıho systému IS/STAG, kter´ y umoˇzn ˇuje mapovat rozvrhové akce (jako jsou napˇr. pˇredn´ aˇsky, semin´ aˇre, zkouˇsky) na m´ıstnosti a následnˇe vytváˇret kalendáˇre m´ıstnost´ı v r´ amci semestru. Tento informaˇcn´ı systém nicménˇe neumoˇzn ˇuje jakkoliv ˇreˇsit rezervace tˇech m´ıstnost´ı, které nejsou t´ımto systémem evidovány (napˇr. zasedac´ı m´ıstnost na katedˇre) nebo jejichˇz rezervace jdou nad rámec standardn´ıch rozvrhov´ ych akc´ı.

2.1.2

Nev´ yhody st´ avaj´ıc´ıho ˇ reˇ sen´ı

Stávaj´ıc´ı systém je zaveden pouze nad omezenou mnoˇzinou vybaven´ı. Pokud by vˇsak mˇel b´ yt poˇcet notebook˚ u a dataprojektor˚ u zv´ yˇsen, pˇr´ıpadnˇe by mˇelo b´ yt umoˇznˇeno realizovat v´ yp˚ ujˇcky i nad jin´ ymi pˇredmˇety, ˇreˇsen´ı v podobˇe pap´ırov´ ych formul´ aˇr˚ u zaˇcne nar´ aˇzet na své hranice pouˇzitelnosti. Dále se s n´ım poj´ı celá ˇrada nedostatk˚ u: - movité objekty nelze na z´ akladˇe pap´ırového formuláˇre efektivnˇe rezervovat do budoucnosti. - z´ aznamy o zap˚ ujˇcen´ı jsou dostupné pouze na jednom m´ıstˇe v pap´ırové podobˇe. - nelze efektivnˇe sledovat vyuˇzitelnost pˇredmˇet˚ u. - samotn´ y akt v´ yp˚ ujˇcky a rezervace je s ohledem na nutné vyplˇ nován´ı pap´ırov´ ych formul´ aˇr˚ u pomˇernˇe zdlouhav´ y a obtˇeˇzuj´ıc´ı. - chyb´ı aktu´ aln´ı pˇrehled jaké objekty jsou p˚ ujˇceny, rezervovány, nevráceny atp. - uˇzivatelé maj´ı obecnˇe pˇri vyplˇ nován´ı pap´ırov´ ych formuláˇr˚ u sklony k chybám a nepˇresnostem. - je nutné udrˇzovat t´ ydenn´ı kalendáˇr rezervac´ı a manuálnˇe provádˇet kontrolu, jestli se rezervace nepˇrekr´ yvaj´ı. - neexistuje jednotn´ y ˇcasov´ y formát pro definován´ı opakovan´ ych rezervac´ı.

3


Existuj´ıc´ı pˇr´ıbuzné systémy

Realizace rezervac´ı nemovit´ ych objekt˚ u pak zcela chyb´ı. Bylo by vhodné zobecnit problém v´ yp˚ ujˇcky movit´ ych a nemovit´ ych objekt˚ u, zavést jednotnou terminologii tak, aby byly navrˇzené postupy obecnˇe pouˇzitelné, a navrhnout ˇreˇsen´ı v podobˇe nˇejakého druhu informaˇcn´ıho systému.

2.2

Existuj´ıc´ı pˇ r´ıbuzn´ e syst´ emy

Teoretick´ a ˇreˇsen´ı prop˚ ujˇcov´ an´ı zdroj˚ u ve velmi obecné rovinˇe existuj´ı a jsou popsána v r´ amci tzv. Inventory managementu. Tento pojem pocház´ı z logistiky a oznaˇcuje sadu postup˚ u zab´ yvaj´ıc´ıch se otázkami dohledu nad skladov´ ymi zásobami, jejich objedn´ av´ an´ı a udrˇzován´ı jejich poˇctu v udrˇziteln´ ych mez´ıch. Systémy, které se nejv´ıce bl´ıˇz´ı potˇreb´ am této práce, se poté zpravidla oznaˇcuj´ı jako inventárn´ı systémy (Inventory Systems nebo Stock Systems). Ty lze charakterizovat jako sadu hardwarov´ ych a softwarov´ ych nástroj˚ u, které automatizuj´ı proces sledov´ an´ı inventárn´ıch objekt˚ u. Druh sledovan´ ych objekt˚ u m˚ uˇze b´ yt vpravdˇe jak´ ykoliv poˇcitateln´ y pˇredmˇet (napˇr´ıklad obleˇcen´ı, knihy, technické vybaven´ı). Modern´ı inventárn´ı systémy jsou témˇeˇr v´ yhradnˇe zaloˇzeny na technologii skenovateln´ ych ˇc´ arov´ ych kód˚ u, QR kód˚ u nebo RFID ˇst´ıtk˚ u (viz dále). Takov´ ych systém˚ u je cel´ a ˇrada, obvykle je inventárn´ı systém souˇcást´ı celého bal´ıku rozs´ ahl´ ych podnikov´ ych systém˚ u jako je napˇr´ıklad Microsoft Dynamics nebo Oracle SCM. Vˇsechny ale maj´ı jedno spoleˇcné – jsou zamˇeˇreny na v´ yrobu a logistiku invent´ aˇre, kter´ y je urˇcen k prodeji, nikoliv k u ´ˇcel˚ um zap˚ ujˇcován´ı zamˇestnanc˚ um (nebo ˇclen˚ um organizace). Spr´ avou takového druhu objekt˚ u, které se obvykle oznaˇcuje slovem assets, se zab´ yv´ a jin´ a discipl´ına – tzn. Asset Management [1]. V podnikové terminologii se slovo asset pˇrekl´ ad´ a jako tzv. provozn´ı aktivum, neboli objekt, kter´ y generuje pˇridanou hodnotu. Mezi aktiva m˚ uˇzeme zaˇradit pozemky, budovy, ale i stroje, softwarové licence a dalˇs´ı zaˇr´ızen´ı. Asset management se poté zab´ yvá správou tˇechto aktiv bˇehem jejich ˇzivotn´ıho cyklu tak, aby jejich provozován´ı generovalo maxim´ aln´ı pˇridanou hodnotu. Asset Management systém˚ u je celá ˇrada – z tˇech nejvˇetˇs´ıch zde jmenujme napˇr. Maximo Asset Management od IBM, Software Asset Management od spoleˇcnosti Microsoft a z tˇech ryze ˇcesk´ ych napˇr´ıklad ALVAO Asset Management. Tyto systémy zpravidla umoˇzn ˇuj´ı pˇridˇelovat jednotlivá aktiva mezi zamˇestnance v rámci evidence majektu (aby bylo vˇzdy jasné, kdo má danou SW licenci, poˇc´ıtaˇc atd. aktuálnˇe v drˇzen´ı) – ˇz´ adn´ y z nich ovˇsem neposkytuje moˇznost plánován´ı, rezervac´ı ani okamˇzitého vyzvednut´ı z podnˇetu zamˇestnanc˚ u. Nav´ıc naˇs´ım c´ılem nen´ı majetek evidovat (i kdyˇz nˇejak´ a forma evidence bude pravdˇepodobnˇe nutná), ani ˇr´ıdit

4


Generalizace problému výp˚ ujˇcek

jeho ˇzivotn´ı cyklus, ale pouze ˇr´ıdit jeho ˇcasov´ y“ obˇeh mezi uˇzivateli. ” Jak je vidˇet, analogie ˇreˇsen´ı naˇseho problému se v podnikové informaˇcn´ı sféˇre nehled´ a snadno. Spr´ avˇe movit´ ych objekt˚ u se pravdˇepodobnˇe nejv´ıce bl´ıˇz´ı r˚ uzné knihovn´ı systémy, jejichˇz souˇc´ ast´ı je i v´ yp˚ ujˇcn´ı protokol, pˇr´ıpadnˇe dalˇs´ı specializovan´ y software pro r˚ uzné p˚ ujˇcovny movit´ ych objekt˚ u. Jako pˇr´ıklad aplikace umoˇzn ˇuj´ıc´ı rezervace nemovit´ ych objekt˚ u bychom mohli jmenovat MS Outlook. Ten umoˇzn ˇuje rezervovat m´ıstnosti a dalˇs´ı pˇredem definované zdroje pro naplánované sch˚ uzky a jiné ˇcasové ud´ alosti. Autorovi této práce se vˇsak nepodaˇrilo naj´ıt ˇzádn´ y stávaj´ıc´ı software, kter´ y by celistvˇe ˇreˇsil nast´ınˇen´ y problém vyp˚ ujˇcován´ı majetku v obecné rovinˇe.

2.3

Generalizace probl´ emu v´ yp˚ ujˇ cek

´ Ukolem této kapitoly je zobecnit problém v´ yp˚ ujˇcek a definovat term´ıny, se kter´ ymi by bylo moˇzné d´ ale pracovat.

2.3.1

Objekt, Uˇ zivatel, Rezervace

Protoˇze ˇreˇs´ıme v´ yp˚ ujˇcky jak nemovit´ ych, tak movit´ ych pˇredmˇet˚ u, nebudeme tyto pojmy jiˇz nad´ ale pouˇz´ıvat a shrneme jej do jednoho term´ınu objekt, a to následovnˇe: Definice 1. Objekt“ je movitý nebo nemovitý majetek organizace, který lze do” ˇcasnˇe p˚ ujˇcit uˇzivatel˚ um. Aktem zap˚ ujˇcen´ı objektu“ budeme tedy nadále rozumˇet nejen fyzické zap˚ ujˇcen´ı ” napˇr. notebooku, ale i zap˚ ujˇcen´ı m´ıstnosti pro prezentaci, konferenˇcn´ıho sálu pro pˇredn´ aˇsku, celé budovy pro r˚ uzné akce atp. Nyn´ı definujme term´ın pro uˇzivatele systému: Definice 2. Uˇzivatel“ je ˇclen organizace nebo jin´ a osoba, kter´ a je opr´ avnˇena ” k vyp˚ ujˇcov´ an´ı objekt˚ u. Zcela z´ amˇernˇe neomezujeme uˇzivatele pouze na hranice organizace. T´ım nám moˇzn´ y poˇcet uˇzit´ı dramaticky nar˚ ustá napˇr´ıklad o parkovac´ı m´ısta pro návˇstˇevn´ıky nebo online m´ıstenku k sezen´ı v autobuse. Jediné, co je nutné pro koncov´ y systém ˇreˇsit, je pr´ avˇe opr´ avnˇenost k v´ yp˚ ujˇcce.

5



Nyn´ı je tˇreba zavést logiku rezervac´ı objekt˚ u. Aktem rezervace objektu uˇzivatel ˇr´ıká, ˇze je to on, kdo bude ˇz´ adan´ y objekt v budouc´ım ˇcasovém u ´seku vyuˇz´ıvat a ˇzádn´ y jin´ y uˇzivatel nen´ı opr´ avnˇen do tohoto ˇcasového u ´seku jakkoliv zasahovat nebo v tomto u ´seku objekt s´ am vyuˇz´ıvat. Definice 3. Rezervace“ je ˇcasový u ´sek poˇc´ınaj´ıc´ı v pˇr´ıtomnosti nebo budoucnosti, ” ve kterém daný objekt m˚ uˇze m´ıt vyp˚ ujˇcený pouze daný uˇzivatel. Rezervac´ı m˚ uˇze m´ıt jeden uˇzivatel libovolné mnoˇzstv´ı a libovoln´ y poˇcet rezervac´ı m˚ uˇze b´ yt v´ az´ an k jednomu objektu – jedinou podmiˇ nuj´ıc´ı prerekvizitou pro vytvoˇren´ı rezervace je neexistence jiné rezervace ve stejném ˇcasovém u ´seku. V´ ysledkem je vlastnˇe kalend´ aˇr ˇcasov´ ych událost´ı – rezervac´ı, a to jak pro uˇzivatele, tak pro objekt.

2.3.2

ˇ Zivotn´ ı cyklus rezervace

Nyn´ı je nutné si poloˇzit ot´ azku, jak zobecnit vlastn´ı vyzvedáván´ı a vracen´ı objekt˚ u. Je tˇreba si uvˇedomit, ˇze tato ˇcinnost se jiˇz vlastnˇe nevztahuje na konkrétn´ı objekty, ale na jejich rezervace. Samozˇrejmˇe, objekt zde hraje roli pˇredmˇetu rezervace, bez nˇej by vlastnˇe rezervace samotná postrádala smysl – nicménˇe je to právˇe rezervace, kter´ a bude uˇzivateli vytv´ aˇrena, upravována a nakonec fyzicky vyzvednuta“ ” pˇrevzet´ım objektu. Jiˇz bylo ˇreˇceno, ˇze k samotnému vytvoˇren´ı v´ yp˚ ujˇcky nebo rezervace docház´ı v okamˇziku vyplnˇen´ı kolonky v pap´ırovém formuláˇri. T´ım uˇzivatel vlastnˇe potvrdil“ ” svou v´ yp˚ ujˇcku a je nyn´ı opravdu oprávnˇen k tomu, aby mohl ˇzádan´ y objekt pˇrevz´ıt. Co ale u napˇr. v´ yˇse zm´ınˇeného pˇr´ıkladu parkovac´ıho stán´ı? Tam k pˇrevzet´ı dˇr´ıve rezervovaného objektu doch´ az´ı uˇz samotn´ ym aktem pˇr´ıjezdu auta, u rezervace m´ıstnosti fyzick´ ym obsazen´ım m´ıstnosti atp. Je pˇrinejmenˇs´ım poˇsetilé v tˇechto pˇr´ıpadech vyˇzadovat po uˇzivatel´ıch jakoukoliv dalˇs´ı akci. Jednak je to zbyteˇcn´ y proces nav´ıc a jednak je miziv´ a ˇsance, ˇze by uˇzivatelé v tˇechto situac´ıch modelem ˇ sen´ım je tedy rozdˇelen´ı objekt˚ pˇredepsanou akci skuteˇcnˇe prov´ adˇeli. Reˇ u do dvou kategori´ı: Definice 4. Povinnˇe potvrzované objekty pˇri vyzvednut´ı jsou objekty, jejichˇz rezervace budou pro vyzvednut´ı vyˇzadovat po majitel´ıch tˇechto rezervac´ı danou akci. Nepotvrzované objekty pˇri vyzvednut´ı ˇz´ adnou akci vyˇzadovat nebudou a k jejich vyzvednut´ı dojde posunem poˇc´ atku ˇcasového u ´seku rezervace do souˇcasnosti. ˇ aˇr by nemˇel nab´ Cten´ yt dojmu, ˇze povinnˇe potvrzované pˇredmˇety jsou vˇzdy ty movité a nepotvrzované ty nemovité. D´ıky tomu, ˇze vynucen´ım potvrzen´ı o vyzvednut´ı vznik´ a vlastnˇe nov´ y z´ aznam o aktivitˇe uˇzivatele, je moˇzné si pˇredstavit scénáˇre, kdy se i u nemovit´ ych objekt˚ u uplatn´ı potvrzován´ı a naopak:

6



- chceme sledovat re´ alnou uˇz´ıvanost objekt˚ u. - v souˇcasnosti bˇeˇz´ıc´ı rezervace, které jejich majitel nepotvrd´ı (a objekt si tak vlastnˇe nevyzvedne), mohou propadnout“ a objekt si m˚ uˇze v pˇrekr´ yvaj´ıc´ım ” ˇcasovém r´ amci rezervovat jin´ y uˇzivatel. - movité objekty se pohybuj´ı v omezeném prostoru, nen´ı potˇreba jejich obˇeh potvrzov´ an´ım komplikovat. Z podobn´ ych d˚ uvod˚ u je d´ ale zavedeno i potvrzován´ı pˇri vracen´ı objektu: Definice 5. Povinnˇe potvrzované objekty pˇri vracen´ı jsou objekty, jejichˇz rezervace budou pro vr´ acen´ı objektu vyˇzadovat po majitel´ıch tˇechto rezervac´ı danou akci. Nepotvrzované objekty pˇri vr´ acen´ı ˇza ´dnou akci vyˇzadovat nebudou a k jejich vr´ acen´ı dojde posunem konce ˇcasového u ´seku rezervace do souˇcasnosti. V´ yhody jsou zˇrejmé – rezervaci je moˇzné uˇzivatelem pˇredˇcasnˇe ukonˇcit a ostatn´ı uˇzivatelé tak budou m´ıt v re´ alném ˇcase informaci o tom, zdali je jimi sledovan´ y objekt aktu´ alnˇe k dispozici. Zaveden´ım povinnˇe potvrzovan´ ych a nepotvrzovan´ ych objekt˚ u, at’ uˇz pˇri vyzvednut´ı ˇci pˇri vracen´ı, n´ am umoˇzn´ı jistou formu genericity a flexibility celého modelu – záleˇz´ı jen na konkrétn´ı situaci a pouˇzit´ı, reálném druhu objekt˚ u a pˇrán´ı uˇzivatel˚ u.

2.3.3

Periodick´ e rezervace

Nejr˚ uznˇejˇs´ı lidské aktivity se v ˇcase ˇcasto opakuj´ı – nejinak je to i s naˇsimi rezervacemi. Pˇr´ıkladem m˚ uˇze b´ yt napˇr. kaˇzdot´ ydenn´ı setkán´ı t´ ymu s potˇrebou rezervace m´ıstnosti, pˇredn´ aˇska s rezervac´ı projektoru apod. Abychom tento jev nˇejak podchytili, zavedeme pojem periodické rezervace: Definice 6. Periodick´ a rezervace je takov´ a rezervace, kter´ a se opakuje v ˇcase s pevnˇe danou periodou a pevnˇe daným poˇctem opakov´ an´ı. Periodick´ a rezervace m˚ uˇze b´ yt samozˇrejmˇe vedena k libovolnému typu objektu – pokud bude objekt povinnˇe potvrzovan´ y pˇri vyzvednut´ı, mus´ı uˇzivatel vyzvednut´ı rezervace potvrzovat. Opakov´ an´ı rezervace vˇsak zp˚ usob´ı, ˇze tak mus´ı uˇcinit na poˇcátku kaˇzdého ˇcasového u ´seku rezervace. Obdobná situace bude platit i pro vracen´ı objekt˚ u. Zde vˇsak nast´ av´ a urˇcit´ y nesoulad. Rezervace sama o sobˇe sice k sobˇe váˇze objekt a uˇzivatele, dosud definovan´ y model vˇsak v pˇr´ıpadˇe cyklické rezervace pokulháv´ a – jak definovat periodiˇcnost? Od jakého data? Po jak dlouhou dobu? Jak´ y

7



ˇcasov´ yu ´sek maj´ı zabrat jednotlivé periody? Co kdyˇz uˇzivatel bude cht´ıt nˇekter´ y ˇcasov´ yu ´sek pˇreskoˇcit nepˇr´ıklad z d˚ uvodu v´ yluky v rozvrhu? Z tohoto d˚ uvodu upˇresn´ıme pˇredcházej´ıc´ı definici následovnˇe: Definice 7. Kaˇzd´ a rezervace se skl´ ad´ a z jedné nebo v´ıce ˇcasových period, kde kaˇzd´ a perioda obsahuje ˇcasový u ´sek rezervace v dané periodˇe. a pˇrid´ ame definici dalˇs´ı, kter´ a n´ am umoˇzn´ı jednotlivé periody vyp´ınat“: ” Definice 8. Neplatn´ a perioda je takov´ a perioda, ve které se ˇcasový u ´sek rezervace interpretuje tak, jako by ˇz´ adn´ a rezervace v této periodˇe nevznikla. Vysvˇetlen´ı tˇecho definic je n´ azornˇe ukázáno na Obr. 2.1. Kaˇzdá rezervace se skládá z jedné a v´ıce ˇcasov´ ych period, pˇriˇcemˇz periody maj´ı konstantn´ı délku. V tˇechto period´ ach jsou poté zahrnuty jednotlivé ˇcasové u ´seky samotné rezervace objektu (znázornˇeno ˇcervenou barvou). Uˇzivatel m˚ uˇze v tˇechto u ´sec´ıch pouˇz´ıvat pˇredmˇet, kter´ y si zarezervoval. Pokud je nˇekterá z period neplatná (na obrázku znázornˇeno ˇsedou barvou), je i ˇcasov´ yu ´sek rezervace v této periodˇe obsaˇzen´ y neplatn´ y a bude se interpretovat tak, jako by ˇz´ adná rezervace v dané periodˇe nikdy nevznikla.

Obrázek 2.1: Struktura periodické rezervace.

2.3.4

Potvrzen´ı vyzvednut´ı objektu

Samotn´ y akt vyzvednut´ı rezervace se zdá jako pomˇernˇe triviáln´ı událost. Nicménˇe narozd´ıl od vytvoˇren´ı rezervace je tato událost svázána s aktuáln´ım ˇcasem a ˇcasem poˇcátku vyzved´ avané rezervace. Jistˇe by nemˇelo b´ yt moˇzné vyzvedávat objekty, jejichˇz rezervace jeˇstˇe nezaˇcala. Protoˇze vˇsak uˇzivatelé sotva budou vyzvedávat objekty v pˇresnˇe dan´ y ˇcas poˇc´ atku rezervace, je tˇreba umoˇznit pˇredˇcasné vyzvednut´ı, pˇr´ıpadnˇe vyzvednut´ı po term´ınu zaˇcátku rezervace. Dále je tˇreba se ptát, co se stane s rezervacemi, které nebudou vyzvednuty. Aby tyto problémy mohly b´ yt uspokojivˇe vyˇreˇseny, je nejprve nutné definovat základn´ı ˇcasové konstanty rezervac´ı:

8



Definice 9. Minim´ aln´ı délka rezervace“ je minim´ aln´ı délka ˇcasového u ´seku re” zervace v kaˇzdé své periodˇe. Definice 10. Maxim´ aln´ı délka rezervace“ je maxim´ aln´ı délka ˇcasového u ´seku ” rezervace v kaˇzdé své periodˇe. Definice 11. Maxim´ aln´ı délka rezervace je menˇs´ı nebo rovna ˇcasové délce periody rezervace. Rezervac´ım jsou t´ımto definov´ any meze pro jejich ˇcasové u ´seky ve vˇsech periodách rezervace.

Pˇ redˇ casn´ e vyzvednut´ı Na Obr. 2.2 je zn´ azornˇena ˇcasová osa, aktuáln´ı ˇcas a situace pˇredˇcasného vyzvednut´ı rezervace. Je tˇreba se nejprve ptát, jak velk´ y ˇcasov´ y rozd´ıl uˇzivatele dˇel´ı od ˇcasu vyzvednut´ı a ˇcasu zaˇc´ atku rezervace objektu, která uˇzivateli patˇr´ı a zda takov´ a rezervace v˚ ubec existuje.

Obrázek 2.2: Pˇredˇcasné vyzvednut´ı rezervace. Pokud je tento rozd´ıl menˇs´ı neˇz minimáln´ı délka rezervace, znamená to, ˇze mezi aktuáln´ı ˇcas a ˇcas poˇc´ atku rezervace se jiˇz ˇzádná nová rezervace nevejde. Nyn´ı je tˇreba jeˇstˇe zv´ aˇzit dalˇs´ı rezervace, které mohou do ˇcasového rozd´ılu zasahovat. Na Obr. 2.3 je zn´ azornˇena situace, kdy se uˇzivatel1 pokouˇs´ı pˇredˇcasnˇe vyzvednout objekt na svou v minulosti vytvoˇrenou rezervaci. To vˇsak nen´ı moˇzné, protoˇze mezi aktuáln´ım ˇcasem a ˇcasem poˇcátku rezervace stále prob´ıh´ a rezervace uˇzivatele2. Uˇzivateli1 tedy nezb´ yvá nic jiného, neˇz vyˇckat aˇz blokuj´ıc´ı rezervace skonˇc´ı a uˇzivatel2 vyzvednut´ y objekt nevrát´ı.

9



Obrázek 2.3: Kolize rezervac´ı pˇri vyzvedáván´ı. Pokud vˇsak ˇz´ adn´ a takov´ a blokuj´ıc´ı rezervace neexistuje, je moˇzné objekt vyzvednout i pˇredˇcasnˇe. Poˇc´ atek rezervace se posune na aktuáln´ı datum a rezervace se oznaˇc´ı jako vyzvednut´ a. Tuto situaci ilustruje Obr. 2.4.

´ esné vyzvednut´ı rezervace. Obrázek 2.4: Uspˇ Pokud je rozd´ıl od ˇcasu vyzvednut´ı a ˇcasu zaˇcátku rezervace objektu vˇetˇs´ı neˇz minim´ aln´ı délka rezervace, uˇzivatel vyzvedává objekt pˇr´ıliˇs brzy a nen´ı moˇzné objekt vyzvednout. Nen´ı vˇsak d˚ uvod proˇc by uˇzivateli nemohla b´ yt vytvoˇrena rezervace nov´ a s poˇc´ atkem v aktuáln´ım ˇcase. Term´ın ukonˇcen´ı rezervace bude moci uˇzivatel s´ am definovat. Novˇe vytvoˇrená rezervace by mˇela b´ yt také automaticky vyzvednuta, jak ukazuje Obr. 2.5.

Obrázek 2.5: Vytvoˇren´ı nové rezervace. Vytvoˇren´ı rezervace vˇsak mus´ı splˇ novat podm´ınku o neexistenci jiné rezervace na stejn´ y objekt ve stejném ˇcasovém u ´seku. Na Obr. 2.6 je znázornˇena situace, kdy se uˇzivatel1 pokouˇs´ı pˇredˇcasnˇe vyzvednout objekt na základˇe budouc´ı rezervace.

10



Obrázek 2.6: Kolize rezervac´ı pˇri vytváˇren´ı. Toto vyzvednut´ı je z d˚ uvodu pˇr´ıliˇsné vzdálenosti rezervace odm´ıtnuto a uˇzivateli1 je umoˇznˇeno vytvoˇren´ı rezervace nové, s libovolnou délkou trván´ı. Ten tedy zadá pˇredpokl´ adanou dobu trv´ an´ı nové rezervace a pokus´ı se rezervaci vytvoˇrit. Nyn´ı je nutné zkontrolovat, zda v ˇcasovém u ´seku nové rezervace neexistuje jiná rezervace na stejn´ y objekt. Jak je vidˇet, tato rezervace skuteˇcnˇe existuje a patˇr´ı uˇzivateli2 a proto vytvoˇren´ı nové rezervace pro uˇzivatele1 skonˇc´ı ne´ uspˇesnˇe.

Vyzvednut´ı po term´ınu Uˇzivatelé z libovolného d˚ uvodu nemus´ı term´ın vyzvednut´ı objektu vˇcas stihnout. Rezervace jiˇz zaˇcala a objekt nen´ı stále vyzvednut – stává se tedy nevyzvednutou. Tuto situaci ilustruje Obr. 2.7.

Obrázek 2.7: Nevyzvednutá rezervace. Otázkou je, jak se takov´ ym rezervac´ıch zachovat. Jistˇe nen´ı ˇzádouc´ı blokovat ostatn´ı uˇzivatele rezervac´ı, kter´ a ztratila své p˚ uvodn´ı poslán´ı – zaruˇcit jej´ımu majiteli v´ yp˚ ujˇcku objektu. Ten si vˇsak ˇzádn´ y objekt fyzicky nep˚ ujˇcil, neprovedl potvrzen´ı o vyzvednut´ı a t´ım p´ adem se celá rezervace stává neplatnou. Na druhou stranu, jistˇe chceme umoˇznit i vyzvednut´ı objektu po term´ınu rezervace.

11



Rozumn´ ym kompromisem bude zaveden´ı dalˇs´ı ˇcasové konstanty do naˇseho modelu: Definice 12. Expirace rezervace“ je ˇcasový u ´sek od zaˇc´ atku nevyzvednuté rezer” vace, po který je rezervace ch´ ap´ ana jako st´ ale platn´ a. Pokud je poˇc´ atek rezervace roven aktuáln´ımu ˇcasu a rezervace stále nen´ı vyzvednuta, je vyˇclenˇen ˇcasov´ y u ´sek, tzv. expirace rezervace, po kter´ y bude rezervace stále ch´ ap´ ana jako platn´ a. V tomto ˇcasovém u ´seku ostatn´ı uˇzivatelé nebudou moci vytváˇret své rezervace na stejn´ y objekt a rezervace m˚ uˇze b´ yt stále vyzvednuta jej´ım majitelem. Tato situace je znázornˇena na Obr. 2.8.

Obrázek 2.8: Expirace rezervace. Jak ilustruje Obr. 2.9, aˇz se ˇcas dostane za dobu expirace rezervace a tato stále nen´ı vyzvednuta, bude umoˇznˇeno ostatn´ım uˇzivatel˚ um vytvoˇrit vlastn´ı rezervaci v ˇcasovém u ´seku této nevyzvednuté rezervace. Pokud se tak stane, je p˚ uvodn´ı ˇcasov´ y interval rezervace automaticky zneplatnˇen a majitel rezervace jiˇz nem˚ uˇze objekt vyzvednout (tato zmˇena se neprom´ıtne do ostatn´ıch period v pˇr´ıpadˇe cyklické rezervace).

Obrázek 2.9: Zneplatnˇen´ı rezervace. Tento pˇr´ıstup m´ a jeˇstˇe jednu v´ yhodu – i po vyprˇsen´ı doby expirace je stále moˇzné rezervaci vyzvednout. Lze tak ale uˇcinit pouze v pˇr´ıpadˇe, kdy jin´ı uˇzivatelé nevytvoˇrili nové rezervace do ˇcasového u ´seku rezervace p˚ uvodn´ı.

2.3.5

Potvrzen´ı vr´ acen´ı objekt˚ u

Jak jiˇz bylo zm´ınˇeno, administrátor systému bude moci vynutit potvrzen´ı vrácen´ı objektu. T´ım se opˇet dost´ aváme do situace, kdy je nutné definovat chován´ı

12



akce vr´ acen´ı objektu v r˚ uzn´ ych ˇcasov´ ych intervalech. Oˇcividnˇe nebude moˇzné potvrzovat vracen´ı tˇech objekt˚ u, které jsou vedeny jako povinnˇe potvrzované pˇri vyzvednut´ı a jejichˇz rezervace nebyla vyzvednuta.

Pˇ redˇ casn´ e vr´ acen´ı objektu V tomto pˇr´ıpadˇe dojde ke zkr´ acen´ı doby rezervace na ˇcas vrácen´ı objektu a celá v´ yp˚ ujˇcka t´ım bude dokonˇcena. Je tak mimo jiné umoˇznˇeno, aby i ostatn´ı uˇzivatelé vyuˇzili ˇcas po této rezervaci pro své v´ yp˚ ujˇcky. Pˇr´ıpad pˇredˇcasného vrácen´ı je zobrazen na Obr. 2.10.

Obrázek 2.10: Pˇredˇcasné vrácen´ı objektu.

Vr´ acen´ı objektu po term´ınu Pokud je objekt vr´ acen po term´ınu konce rezervace, nedojde k ˇzádné zmˇenˇe tohoto term´ınu – mohli bychom se dostat do kolize s jinou rezervac´ı. Rezervace vráceného objektu bude pouze vedena jako ukonˇcena.

Nevr´ acen´ı objektu V pˇr´ıpadˇe déletrvaj´ıc´ıho nevr´ acen´ı objektu uˇzivatel mohl pouze zapomenout objekt vr´ atit nebo toto vr´ acen´ı potvrdit, mohlo vˇsak také doj´ıt ke zcizen´ı majektu organizace. Je tedy ˇz´ adouc´ı v pˇr´ıpadˇe nevrácen´ı objektu o tom nˇejak´ ym zp˚ usobem informovat zopodvˇedné osoby, aby mohly na tuto událost vˇcas reagovat.

13



Jedn´ım z moˇzn´ ych pˇr´ıstup˚ u je definován´ı ˇcasového u ´seku, bˇehem kterého bude nevrácen´ı objektu tolerov´ ano. N´ aslednˇe je moˇzné vyuˇz´ıt nˇekterého z komumikaˇcn´ıch kanál˚ u (e-mail, sms atp.) pro odeslán´ı zprávy zodpovˇedn´ ym osobám nebo majiteli této nevr´ acené rezervace. D´ ale je napˇr´ıklad moˇzné zablokovat dalˇs´ı vyp˚ ujˇcován´ı objektu do doby, neˇz je tento navr´ acen posledn´ım p˚ ujˇcuj´ıc´ım uˇzivatelem. Kaˇzdopádnˇe bude nutné umoˇznit rychlé dohled´ an´ı uˇzivatele, kter´ y mˇel objekt naposledy p˚ ujˇcen a nevrátil jej.

2.3.6

Lokalizace objekt˚ u

Je ˇzádouc´ı nˇejak´ ym zp˚ usobem poskytnout uˇzivatel˚ um dalˇs´ı doplˇ nková data o objektech – kde se objekt fyzicky nacház´ı, jak vypadá a jak se z nˇemu dostat. Tyto informace budou jistˇe velmi cenné zejména pro ty uˇzivatele, kteˇr´ı rezervace tˇechto objekt˚ u prov´ adˇej´ı nepravidelnˇe, nejsou stálou souˇcást´ı organizace nebo jsou v n´ı nováˇcky. Zejména poloha budov, m´ıstnost´ı nebo objekt˚ u, které se ˇcasto pohybuj´ı ´ mezi v´ıce uˇzivateli, se jev´ı jako velmi uˇziteˇcná. Udaje by mˇely b´ yt co nejrychleji dohledatelné a nemˇelo by jich b´ yt zbyteˇcnˇe moc, aby se v nich uˇzivatelé neztráceli.

14


2.4

Shrnut´ı

Shrnut´ı

Nyn´ı m´ ame vytvoˇren´ y potˇrebn´ y obecn´ y model pro to, abychom mohli zaˇc´ıt s bliˇzˇs´ı specifikac´ı poˇzadavk˚ u na nov´ y systém. Tento model je vˇcetnˇe jiˇz definovan´ ych atribut˚ u entit a vz´ ajemn´ ych vazeb zobrazen na Diagramu 2.1.

Diagram 2.1: Obecn´ y model rezervac´ı a v´ yp˚ ujˇcek objekt˚ u. K dosaˇzen´ı u ´plné komplexnosti nám vˇsak stále nˇeco chyb´ı – je tˇreba bl´ıˇze urˇcit, jaké technické ˇreˇsen´ı bude pouˇzito pro následuj´ıc´ı c´ıle: - autentizace uˇzivatel˚ u. - identifikace objekt˚ u. - vyzvednut´ı a vr´ acen´ı objektu. - lokalizace objekt˚ u. V následuj´ıc´ıch kapitol´ ach si uk´ aˇzeme, jak lze tˇechto c´ıl˚ u dosáhnout pomoc´ı unikátn´ıch technick´ ych vlastnost´ı mobiln´ıch zaˇr´ızen´ı a pokus´ıme se definovat základn´ı sadu mobiln´ıch technologi´ı, kter´ a bude pouˇzita pro nov´ y informaˇcn´ı systém.

15

3 Mobiln´ı zaˇr´ızen´ı V dneˇsn´ı dobˇe drtiv´ a vˇetˇsina populace vlastn´ı mobiln´ı telefon. V této mnoˇzinˇe existuje nemal´ a podmnoˇzina majitel˚ u tzv. chytr´ ych telefon˚ u. Tyto telefony jsou unikátn´ı t´ım, ˇze vyuˇz´ıvaj´ı pokroˇcilého operaˇcn´ıho systému a obvykle maj´ı vlastn´ı aplikaˇcn´ı rozhran´ı, které umoˇzn´ı instalaci program˚ u tˇret´ıch stran. Jejich konektivita se také neomezuje na pouhé GSM hovory – zcela bˇeˇznˇe podporuj´ı technologie jako je napˇr´ıklad WiFi nebo 3G pro rychl´ y pˇr´ıstup do Internetu. V posledn´ıch letech lze také pozorovat nástup tzv. tablet˚ u. Tablet je zaˇr´ızen´ı, které sice obvykle neumoˇzn ˇuje komunikaci po klasické GSM s´ıti, disponuje vˇsak mnohem vˇetˇs´ım displejem neˇz chytr´ y telefon. V posledn´ı dobˇe se ukazuje, ˇze chytré telefony a tablety d´ıky své mobilitˇe, jednoduchosti, delˇs´ı v´ ydrˇzi na baterii a ergonomickému uˇzivatelskému rozhran´ı skuteˇcnˇe zaˇc´ınaj´ı naplˇ novat v´ yznam term´ınu osobn´ı poˇc´ıtaˇc“. Chytré telefony a tablety se stávaj´ı mnohem populárnˇejˇs´ı neˇz ” klasické stoln´ı poˇc´ıtaˇce a notebooky a to dokonce do té m´ıry, ˇze nˇekteˇr´ı lidé jiˇz ani nec´ıt´ı potˇrebu pro svou bˇeˇznou agendu klasické poˇc´ıtaˇce vyuˇz´ıvat. V této kapitole se ˇcten´ aˇr seznám´ı s uˇzivatelsk´ ymi a technologick´ ymi v´ yhodami, které mobiln´ı zaˇr´ızen´ı pˇrináˇsej´ı. Budou rozebrány moˇznosti v´ yvoje aplikac´ı pro r˚ uzné mobiln´ı platformy a jejich uplatnˇen´ı v rámci rozsáhl´ ych informaˇcn´ıch systém˚ u.

3.1

Mobiln´ı zaˇ r´ızen´ı jako pracovn´ı n´ astroj

Souˇcasn´ a mobiln´ı zaˇr´ızen´ı jiˇz d´ avno pˇrevzala u ´lohu r˚ uzn´ ych specializovan´ ych pˇr´ıstroj˚ u jako jsou databanky, Pocket PC nebo palmtopy. D´ıky tomu, ˇze zpravidla obsahuj´ı snadno dostupné aplikace pro plánován´ı a organizaci ˇcasu a souˇcasnˇe kombinuj´ı klasickou telefonii s rychl´ ym pˇr´ıstupem na Internet, staly se obl´ıbenou pom˚ uckou manaˇzer˚ u a dalˇs´ıch zamˇestnanc˚ u, u nichˇz je vyˇzadována okamˇzitá dostupnost a operativnost. Nicménˇe vyuˇzit´ı mobiln´ıch zaˇr´ızen´ı je mnohem ˇsirˇs´ı. Lze si je pˇredstavit jako jakési mobiln´ı termin´ aly, pˇres které zamˇestnanci interaktivnˇe komunikuj´ı s centráln´ım systémem. Ten m˚ uˇze slouˇzit pro napˇr. správu skladov´ ych zásob, jako databáze zákazn´ık˚ u nebo k objedn´ av´ an´ı obˇed˚ u ve ˇskoln´ı j´ıdelnˇe – moˇznosti jsou skuteˇcnˇe ˇsiroké. Dotykové ovl´ ad´ an´ı je zpravidla intuitivnˇejˇs´ı neˇz klasické pˇr´ıstupy, nav´ıc menˇs´ı dipleje nut´ı v´ yvoj´ aˇre aplikac´ı k co nejvˇetˇs´ı jednoduchosti a kompaktnosti rozhran´ı – d´ıky tomu m˚ uˇze mobiln´ı zaˇr´ızen´ı po rychlém zaˇskolen´ı pouˇz´ıvat skuteˇcnˇe kaˇzd´ y.

16

Mobiln´ı zaˇr´ızen´ı

Technické prostˇredky mobiln´ıch zaˇr´ızen´ı

Je také moˇzné vyuˇz´ıt r˚ uzné technologie tˇechto zaˇr´ızen´ı, které klasické poˇc´ıtaˇce zpravidla neumoˇzn ˇuj´ı, nebo je jejich pouˇzit´ı znaˇcnˇe neergonomické ˇci pro bˇeˇzné uˇzivatele sloˇzité. Nezanedbatelnou v´ yhodou je také to, ˇze zamˇestnanci obvykle maj´ı tato zaˇr´ızen´ı prakticky poˇr´ ad u sebe a ve vˇetˇsinˇe pˇr´ıpad˚ u i pˇripojená k Internetu, coˇz oproti staticky um´ıstˇen´ ym terminál˚ um nebo webovému rozhran´ı ˇrádovˇe zvyˇsuje komfort uˇz´ıv´ an´ı systému a zvyˇsuje jeho flexibilitu. Mezi dalˇs´ı moˇznosti mobiln´ıch zaˇr´ızen´ı v organizaci patˇr´ı uplatnˇen´ı tzv. BYOD (Bring Your Own Device) politiky. Tento pˇr´ıstup umoˇzn ˇuje v organizac´ıch pouˇz´ıvat stejné zaˇr´ızen´ı pro osobn´ı i pracovn´ı u ´ˇcely [4]. IT oddˇelen´ı nezakazuje pouˇz´ıván´ı vlastn´ıch zaˇr´ızen´ı v organizaci, naopak jej aktivnˇe podporuje a snaˇz´ı se poskytovat maxim´ aln´ı podporu pro hladkou integraci zaˇr´ızen´ı s infrastrukturou. Tento pˇr´ıstup má samozˇrejmˇe sv´ a rizika a z´ aleˇz´ı na kaˇzdé organizaci zdali pouˇz´ıván´ı takov´ ych zaˇr´ızen´ı ve své infrastruktuˇre umoˇzn´ı, pˇr´ıpadnˇe zdali nezvol´ı postup z druhé strany“ ” – tedy zdali radˇeji neposkytne zamˇestnanc˚ um taková zaˇr´ızen´ı, která by mohli pouˇz´ıvat i k soukrom´ ym u ´ˇcel˚ um.

3.2

Technick´ e prostˇ redky mobiln´ıch zaˇ r´ızen´ı

Mobiln´ı zaˇr´ızen´ı v sobˇe ukr´ yvaj´ı celou ˇradu zaj´ımav´ ych technologi´ı, se kter´ ymi se na klasick´ ych poˇc´ıtaˇc´ıch obvykle nesetkáme. Tato kapitola má za u ´kol seznámit ˇctenáˇre s tˇemito technologiemi a rozebrat jejich klady a zápory.

3.2.1

Lokalizace zaˇ r´ızen´ı

Mobiln´ı zaˇr´ızen´ı obvykle umoˇzn ˇuj´ı lokalizovat svou polohu, a to za pouˇzit´ı nˇekolika technologi´ı.

GSM lokalizace Pokud mobiln´ı zaˇr´ızen´ı podporuje s´ıtˇe GSM (Global System for Mobile Communications), je moˇzné pouˇz´ıt tzv. GSM lokalizaci. U této lokalizaˇcn´ı metody docház´ı k pˇrenosu ˇz´ adosti o lokalizaci z mobiln´ıho zaˇr´ızen´ı do s´ıtˇe, kde se s vyuˇzit´ım dat zjiˇstˇen´ ych z tohoto zaˇr´ızen´ı a s´ıtˇe stanov´ı jeho poloha. Mobiln´ı zaˇr´ızen´ı pak zpˇetnˇe pˇrijme informaci o poloze [3]. GSM s´ıt’ m´ a buˇ nkovou strukturu, kdy kaˇzdé buˇ nce je pˇridˇeleno (v rámci tzv. Location Area unik´ atn´ı) Cell ID ˇc´ıslo. To slouˇz´ı pro urˇcen´ı pˇr´ıstupového bodu pro mobiln´ı zaˇr´ızen´ı. Poloha vˇsech základnov´ ych stanic (tzv. BTS – Base transceiver

17



station) vytv´ aˇrej´ıc´ı buˇ nkovou strukturu je operátorovi známa. Poloha uˇzivatele v s´ıti m˚ uˇze b´ yt stanovena s vyuˇzit´ım metody Cell ID s pˇresnost´ı odpov´ıdaj´ıc´ı velikosti buˇ nky, ve které se zrovna mobiln´ı zaˇr´ızen´ı nacház´ı. Ta se pohybuje od 100m do 500m v mˇestsk´ ych oblastech a v jednotkách i des´ıtkách kilometr˚ u mimo mˇesta. Nicménˇe pˇresnost lokalizace m˚ uˇze b´ yt v´ yznamnˇe zv´ yˇsena vyuˇzit´ım tzv. Timing Advance (zkratkou TA). Tento parametr pˇredstavuje ˇcas ˇs´ıˇren´ı signálu mezi mobiln´ım zaˇr´ızen´ım a jednotliv´ ymi BTS. Pˇri znalosti rychlosti ˇs´ıˇren´ı signálu m˚ uˇze b´ yt urˇcena jejich pˇribliˇzn´ a vzd´ alenost. Mobiln´ı zaˇr´ızen´ı vˇsak v praxi pˇrij´ımá signál od v´ıce BTS, coˇz umoˇzn ˇuje v´ ypoˇcet pr˚ uniku bunˇek, které tyto stanice vytváˇrej´ı. Pro pˇresné urˇcen´ı polohy je tˇreba tˇr´ı (a v´ıce) stanic. Dosáhne se tak zv´ yˇsen´ı pˇresnosti urˇcov´ an´ı polohy na hodnoty, která m˚ uˇze dosáhnout zhruba 50m. Tento postup uˇzivatelského urˇcen´ı polohy nen´ı d´ıky své malé pˇresnosti pˇr´ıliˇs efektivn´ı a v praxi jej nahradily jiné metody lokalizace. Pouˇz´ıvá se vˇsak stále u kombinovan´ ych metod lokalizace k dalˇs´ımu zpˇresˇ nován´ı polohy zaˇr´ızen´ı (a je nutn´ y pro vlastn´ı funkˇcnost GSM s´ıtˇe).

GPS lokalizace GPS (anglicky Global Position System) patˇr´ı mezi tzv. globáln´ı navigaˇcn´ı druˇzicové systémy (anglicky Global Navigation Satellite System, zkratkou GNSS). P˚ uvodnˇe byl vyvinut pro vojenské u ´ˇcely a v souˇcasné dobˇe je pod kontrolou Ministerstva obrany Spojen´ ych st´ at˚ u americk´ ych [2]. GPS umoˇzn ˇuje za pomoci pˇrij´ımaˇce GPS sign´ alu z´ısk´ an´ı tˇr´ıdimenzionáln´ıch souˇradnic pˇrij´ımaˇce, jeho aktuáln´ı rychlost vzhledem k povrchu Zemˇe a také ˇcas. Pˇrij´ımaˇc m˚ uˇze b´ yt pouˇzit k´ ymkoliv a kdekoliv na planetˇe, ve dne i v noci, na souˇsi, na moˇri i ve vzduchu. Existuj´ı samozˇrejmˇe i dalˇs´ı GNSS systémy: jmenujme napˇr´ıklad rusk´ y GLONASS, ˇc´ınsk´ y Compass nebo novˇe vznikaj´ıc´ı systém Evropské unie - Galileo. V souˇcasné dobˇe je vˇsak GPS zdaleka nejpouˇz´ıvanˇejs´ı GNSS systém se zdaleka nejˇsirˇs´ı podporou v´ yrobc˚ u lokalizaˇcn´ıch zaˇr´ızen´ı. GPS funguje d´ıky flotile vys´ılac´ıch druˇzic. Kaˇzdá druˇzice je vynesena na pˇresnˇe stanovenou obˇeˇznou dr´ ahu tak, aby bylo bylo zajiˇstˇeno, ˇze lokalizaˇcn´ı zaˇr´ızen´ı bude moci z jakéhokoliv m´ısta na Zemi v jakoukoliv denn´ı dobu pˇrij´ımat signály ˇ z nejménˇe tˇr´ı druˇzic. Ctvrt´ y sign´ al druˇzice je pak nezbytn´ y pro synchronizaci hodin pˇrij´ımaˇce s hodinami druˇzic. Je nezbytné zm´ınit, ˇze lokalizaˇcn´ı zaˇr´ızen´ı hraj´ı roli pouze pasivn´ıch pˇrij´ımaˇc˚ u druˇzicového signálu. V souˇcasné dobˇe jsou GPS pˇrij´ımaˇce integrovány do celé ˇrady zaˇr´ızen´ı a ty jsou velmi ˇsiroce vyuˇz´ıv´ any – jmenujme alespoˇ n autonavigace, pˇr´ıstroje pro zabezpeˇcen´ı majektu, sledov´ an´ı osob, geodetické pˇr´ıstroje nebo napˇr´ıklad systémy urˇcené

18



k optimalizaci zdroj˚ u, jako je napˇr´ıklad monitorován´ı dopravy. Vˇetˇsina dnes prodávan´ ych chytr´ ych telefon˚ u a tablet˚ u GPS pˇrij´ımaˇc obsahuje, a d´ıky moˇznosti tento pˇrij´ımaˇc aktivnˇe vyuˇz´ıvat aplikacemi tˇret´ıch stran poskytuj´ı pro uˇzivatele ˇsiroké moˇznosti pouˇzit´ı, poˇc´ınaje navigac´ı, pˇres nejr˚ uznˇejˇs´ı inteligentn´ı vyhledávaˇce zaloˇzené na aktu´ aln´ı poloze zaˇr´ızen´ı a konˇce u r˚ uzn´ ych podob sociáln´ıch ˇci geolokaˇcn´ıch her, jako je napˇr´ıklad Foursquare nebo Geocaching.

Nev´ yhody GPS Asi nejvˇetˇs´ı nev´ yhodou GPS je jeho primárn´ı vyuˇzit´ı pro armádu. Pro civiln´ı vyuˇzit´ı je dostupn´ a pouze ˇc´ ast sluˇzeb tohoto systému s omezenou pˇresnost´ı lokalizace a jeho provozovatel m˚ uˇze kdykoliv i funkˇcnost této ˇcásti omezit nebo ji jednoduˇse vypnout. GPS sign´ al m´ a vysokofrekvenˇcn´ı charakter (origináln´ı návrh pˇredpokládá dvˇe nosné frekvence na 1575.42 MHz a 1227.60 MHz, coˇz je jiˇz v pásmu UHF). D´ıky tomu vˇsak obt´ıˇznˇe proch´ az´ı nˇekter´ ymi pevn´ ymi materiály, a proto je uvnitˇr budov pro pˇrij´ımaˇc d´ıky celé plej´ adˇe fyzick´ ych bariér sloˇzité aˇz nemoˇzné zachytit signál alespoˇ n ze ˇctyˇr druˇzic souˇcasnˇe a následnˇe stanovit polohu. Nav´ıc se zde mohou nacházet zdroje ruˇsen´ı sign´ alu GPS. Situace se ponˇekud lepˇs´ı, pokud se pˇrij´ımaˇc pohybuje pobl´ıˇz okna. GPS signál pomˇernˇe dobˇre procház´ı sklem a tak je moˇzné, ˇze pˇri dobrém v´ yhledu napˇr. v pˇr´ıpadˇe v´ yˇskové budovy s velk´ ymi okny bude GPS lokalizace pravdˇepodobnˇe fungovat. Tento pˇr´ıpad je vˇsak sp´ıˇse v´ yjimkou a na GPS zaˇr´ızen´ı uvnitˇr budov se obecnˇe nelze spolehnout. Konkurenˇcn´ı GNSS systémy se ˇ sen´ım d´ıky své technologické pˇr´ıbuznosti s GPS pot´ ykaj´ı se stejn´ ymi obt´ıˇzemi. Reˇ by vˇsak mohla b´ yt tzv. IPS navigace (viz dále).

Lokalizace IPS IPS (Indoor Positioning System) je navigaˇcn´ı systém navrˇzen´ y tak, aby fungoval uvnitˇr budov. Narozd´ıl od GPS nevyuˇz´ıvá pozicového signálu druˇzic, ale rovnou nˇekolika rozliˇcn´ ych technologi´ı, které spolu mohou fungovat i souˇcasnˇe. Pod pojmem IPS se neskr´ yv´ a ˇz´ adn´ a konkrétn´ı technologie, ˇzádn´ y uchopiteln´ y standard – v souˇcasné dobˇe prob´ıh´ a boj o to, kdo prvn´ı pˇrijde s prvn´ım, ˇsiroce pouˇz´ıvan´ ym ˇreˇsen´ım IPS lokalizace. Jedna z moˇzn´ ych technick´ ych implementac´ı je vyuˇz´ıt s´ıtˇe Wi-Fi, která je dnes ˇsiroce rozˇs´ıˇren´ a a naprost´ a vˇetˇsina mobiln´ıch zaˇr´ızen´ı se k n´ı dokáˇze pˇripojit. Dosud uskuteˇcnˇené realizace byly obvykle zaloˇzeny na principu indikátor˚ u s´ıly pˇrijatého signálu (RSSI - Received Signal Strength Indicator ) a seznamu pˇr´ıstupov´ ych bod˚ u, ke kter´ ym je mobiln´ı zaˇr´ızen´ı pˇripojeno [5] [6]. Bohuˇzel tento pˇr´ıstup se ukázal jako

19



neefektivn´ı – s´ıla sign´ alu se totiˇz mˇen´ı v ˇcase velmi nerovnomˇernˇe a pro rychle se pohybuj´ıc´ı objekty skokovˇe. Problémem také je, ˇze r˚ uzná zaˇr´ızen´ı indikuj´ı s´ılu signálu r˚ uznˇe, a je tedy velmi tˇeˇzké z tohoto u ´daje cokoliv predikovat. Proto se objevily pokusy, jak detekci polohy zaˇr´ızen´ı v´ıce zpˇresnit pouˇzit´ım dalˇs´ı technologie ˇsiroce pouˇz´ıvané v mobin´ıch zaˇr´ızen´ıch. Tou technologi´ı je Bluetooth. Napˇr´ıklad systém uveden´ y v [7] s´ıtˇe Wi-Fi pouˇz´ıvá pouze jako páteˇrn´ı komunikaˇcn´ı linky mezi centr´ aln´ım serverem a jednotliv´ ymi Bluetooth uzly. Ty maj´ı rádiov´ y dosah pˇribliˇznˇe deset metr˚ u a jejich rozm´ıstˇen´ı po budovˇe mus´ı b´ yt pˇredem známo. Pˇri vstupu do budovy se uˇzivatel mus´ı pˇripojit k nejbliˇzs´ımu Bluetooth uzlu – a t´ım mu pˇred´ a unik´ atn´ı 48bit Bluetooth ID svého zaˇr´ızen´ı. To je uloˇzeno na centráln´ı server. Pˇri poˇzadavku lokalizace tohoto registrovaného zaˇr´ızen´ı se vˇsechny Bluetooth uzly pokus´ı pˇripojit k zaˇr´ızen´ı s jiˇz uloˇzen´ ym Bluetooth ID – uzel, kterému se to podaˇr´ı, odes´ıl´ a zpˇet své unikátn´ı ID na server, kter´ y poté vyhodnot´ı polohu hledaného zaˇr´ızen´ı a odes´ılá tuto informaci zpˇet ˇzadateli. Pˇresnost tohoto systému je pˇribliˇznˇe deset metr˚ u (coˇz odpov´ıdá rozsahu jednotliv´ ych Bluetooth uzl˚ u) a s vˇetˇs´ım poˇctem uzl˚ u a jejich menˇs´ım dosahem by se pˇresnost jistˇe dala jeˇstˇe zv´ yˇsit. Velkou nev´ yhodou tohoto pˇr´ıstupu je ovˇsem velká nároˇcnost na infrastrukturu s´ıtˇe. V posledn´ı dobˇe se objevuj´ı studie, jak provést lokalizaci uvnitˇr budov na základˇe magnetického pole Zemˇe [8] [9]. K tomu je pouˇzita dalˇs´ı, dnes jiˇz bˇeˇznˇe se vyskytuj´ıc´ı technologie v mobiln´ıch zaˇr´ızen´ıch – magnetometr neboli kompas. Zjednoduˇsenˇe ˇreˇceno, kaˇzd´ y ˇctvereˇcn´ı centimetr Zemˇe vyzaˇruje magnetické pole – a toto pole je modulov´ ano betonov´ ymi a ocelov´ ymi konstrukcemi modern´ıch budov. Vestavˇené kompasy v mobiln´ıch zaˇr´ızen´ıch jsou obvykle natolik citlivé, aby zaznamenaly zmˇeny v magnetickém poli. Pokud je vytvoˇrena mapa tˇechto magnetick´ ych pol´ı, pˇresn´ a navigace pomoc´ı zabudovaného kompasu je poté velmi jednoduch´ a. K vytvoˇren´ı této mapy je opˇet moˇzné pouˇz´ıt vestavˇeného kompasu. Pˇresnost tˇechto systém˚ u je zhruba 1,5m a nikterak v´ yraznˇe ji neovlivˇ nuj´ı ani menˇs´ı kovové pˇredmˇety [11]. Tato technologie je také jiˇz komerˇcnˇe vyuˇz´ıvána [10]. Ot´ azkou z˚ ust´ av´ a, jak bude magnetické mapován´ı ovlivˇ nováno vˇetˇs´ımi umˇel´ ymi objekty (napˇr. auty, doˇcasn´ ymi kovov´ ymi konstrukcemi apod.) a nakolik bude trvalé. Magnetické pole Zemˇe se totiˇz kaˇzd´ ych nˇekolik let mˇen´ı. Celá oblast IPS navigace tedy z˚ ust´ av´ a po technické stránce ne zcela uspokojivˇe vyˇreˇsena.

3.2.2

Digit´ aln´ı fotoapar´ at

Kaˇzdé mobiln´ı zaˇr´ızen´ı dnes integruje alespoˇ n jeden digitáln´ı fotoaparát (kter´ y souˇcasnˇe slouˇz´ı jako videokamera). Pouˇzit´ı tˇechto zaˇr´ızen´ı je ˇsiroké, od vyuˇzit´ı

20



jako klasického fotoapar´ atu, pˇres videohovory aˇz po napˇr´ıklad bezpeˇcnostn´ı kameru v automobilu. My vˇsak zde toto zaˇr´ızen´ı uvád´ıme kv˚ uli nˇeˇcemu jinému – vestavˇen´ y fotoapar´ at lze lehce pouˇz´ıt jako integrovanou ˇcteˇcku optick´ ych kód˚ u.

Optick´ e k´ ody Optick´ y k´ od k´ oduje data popisuj´ıc´ı objekt, ke kterému je optick´ y kód pˇriloˇzen. Lze rozdˇelit do dvou skupin – jednorozmˇerné (ˇcárové) a dvojrozmˇerné QR kódy (Quick Response Codes). Liˇs´ı se zejména svoj´ı odolnost´ı proti chybám, poˇctem znak˚ u, kter´ y je moˇzno k´ odovat, a délkou textu, kter´ y m˚ uˇze kód nést [12]. Tyto kódy byly p˚ uvodnˇe ˇcitelné pouze specializovan´ ymi ˇcteˇckami a skenery, dnes je vˇsak moˇzné pomoc´ı pokroˇcilé anal´ yze obrazu vyuˇz´ıt i bˇeˇznˇe dostupné stoln´ı skenery a fotoapar´ aty – tedy i ty integrované v mobiln´ıch zaˇr´ızen´ıch. Sejmut´ı optického kódu vyˇzaduje pˇr´ımou viditelnost mezi ˇctec´ım zaˇr´ızen´ım a kódem samotn´ ym. Optické k´ ody jsou d´ıky své jednoduchosti a finanˇcn´ı nenároˇcnosti vyuˇz´ıvány v mnoha oblastech lidské ˇcinnosti – v logistice a obchodu, v evidenˇcn´ıch systémech nebo napˇr. slouˇz´ı k veˇrejné prezentaci a marketingu. Hlavn´ım vyuˇzit´ım je unikátn´ı identifikace objektu, ke kterému je kód pˇriloˇzen – takov´ y kód budeme dále naz´ yvat jako tag.

3.2.3

R´ adiov´ e technologie

Mobiln´ı zaˇr´ızen´ı mohou integrovat technologie, které umoˇzn ˇuj´ı komunikaci na krátké vzd´ alenosti pomoc´ı r´ adiov´ ych vln. V této kapitole budou tyto technologie uvedeny v ˇsirˇs´ım kontextu a poté bude rozebráno jejich konkrétn´ı vyuˇzit´ı v mobiln´ıch zaˇr´ızen´ıch.

Technologie RFID (Radio Frequency Identification) Dle [13] je RFID technologie umoˇzn ˇuj´ıc´ı (obdobnˇe jako optické kódy) identifikaci objekt˚ u, nicménˇe nevyˇzaduje k tomu pˇr´ımou viditelnost. Pˇrenos dat zde neprob´ıhá opticky, ale za pomoci r´ adiov´ ych vln. RFID systémy mohou automaticky identifikovat nˇekolik objekt˚ u um´ıstˇen´ ych ve stejném prostoru na základˇe pˇreˇcten´ı jejich tag˚ u, a to bez lidské asistence. RFID zaˇr´ızen´ı lze rozdˇelit do dvou skupin: aktivn´ı a pasivn´ı. Aktivn´ı zaˇr´ızen´ı vyˇzaduj´ı zdroj napájen´ı, bud’ z elektrické s´ıtˇe nebo pomoci baterie. v obvyklém pˇr´ıpadˇe je ˇzivotnost tagu omezena ˇzivotnost´ı baterie (a ˇzivotnost tagu je mˇeˇrena v poˇctu operac´ı ˇcten´ı, které tag mus´ı spolehnivˇe dokonˇcit).

21



Pˇr´ıkladem aktivn´ıho tagu m˚ uˇze b´ yt vys´ılaˇc v letadle, kter´ y identifikuje zemi jeho p˚ uvodu. Protoˇze jsou vˇsak baterie drahé, relativnˇe rozmˇerné a s omezenou ˇzivotnost´ı, ˇcin´ı aktivn´ı tagy ponˇekud nepraktick´ ymi. Proto existuj´ı tagy pasivn´ı. Tyto tagy nevyˇzaduj´ı ˇz´ adn´ y zdroj nap´ ajen´ı. Skládaj´ı se ze tˇr´ı ˇcást´ı: antény, mikroˇcipu pˇripojeného k anténˇe a ochranného obalu. Strana, která chce tag pˇreˇc´ıst, je odpovˇedná za jeho nap´ ajen´ı. Anténa tagu slouˇz´ı k zachytáván´ı energie a odeslán´ı poˇzadovaného identifik´ atoru objektu. Poskytnut´ı tohoto identifikátoru zajist´ı mikroˇcip. Existuj´ı dva pˇr´ıstupy, jak zajiˇst’ovat napájen´ı pasivn´ıho tagu – pomoc´ı principu magnetické indukce a elektromagnetick´ ych vln. Oba dva poskytuj´ı dostatek energie pro nap´ ajen´ı mikroˇcipu v pasivn´ım tagu (typicky od 10µW do 1mW ), liˇs´ı se vˇsak ve vzdálenosti, po kterou mohou tuto energii poskytnout. D´ıky tomu dále rozliˇsujeme pasivn´ı zaˇr´ızen´ı podle dosahu na tzv. far-field a near-field.

NFC (Near-field communication) NFC je sada standard˚ u, které si kladou za c´ıl definovat mechanismy, pomoc´ı kter´ ych mohou mobiln´ı zaˇr´ızen´ı z bezprostˇredn´ı bl´ızkosti (do 20cm) komunikovat s dalˇs´ımi pˇr´ıstoji, a souˇcasnˇe umoˇznily ˇc´ıst data ze stávaj´ıch pasivn´ıch RFID zdroj˚ u. Naprosto z´ amˇernˇe nen´ı vyuˇzito technologi´ı jako je Wi-Fi nebo Bluetooth – jejich rádiov´ y dosah je pˇr´ıliˇs velik´ y a vyˇzaduj´ı párován´ı. Je upˇrednostnˇena jednoduˇsˇs´ı konfigurace, byt’ za cenu niˇzˇs´ıch rychlost´ı. NFC technologie (narozd´ıl od RFID) podporuje ˇsifrov´ an´ı. Mimo klasick´ ych RFID tag˚ u NFC podporuje i ˇcten´ı nˇekter´ ych standard˚ u tzv. chytr´ ych karet. NFC umoˇzn ˇuje nˇekolik reˇzim˚ u pˇrenosu ve tˇrech reˇzimech: Reader/Writer ˇcten´ı nebo z´ apis do pasivn´ıho zaˇr´ızen´ı, Peer-to-peer neboli obousmˇerná komunikace dvou aktivn´ıch zaˇr´ızen´ı, a reˇzim Card emulation, ve kterém je emulováno NFC pasivn´ı zaˇr´ızen´ı. NFC také nad rámec RFID definuje vlastn´ı sadu tag˚ u. Ty se od sebe liˇs´ı velikost´ı pamˇeti, pouˇzit´ ym ˇcipem, pˇrenosovou rychlost´ı a moˇznost´ı pˇrepisov´ an´ı. Technologie uˇz z principu nen´ı kompatibiln´ı s far–field RFID tagy. D´ıky vˇsem tˇemto vlastnostem je moˇzné tuto technologii uplatnit napˇr. k bezkontaktn´ım platb´ am, identifikaci, sd´ılen´ı nebo napˇr. pro rychlé nastaven´ı sloˇzitˇejˇs´ıch druh˚ u komunikace. V souˇcasnosti jsou k dispozici des´ıtky typ˚ u chytr´ ych telefon˚ u s NFC ˇcipy. Kaˇzdé zaˇr´ızen´ı ale ne zcela implementuje vˇsechny pˇredepsané standardy, nebo je naopak rozˇsiˇruje – t´ım vzniká vzájemná nekompatibilita, kdy nˇekteré typy tag˚ u nemus´ı j´ıt na tˇechto pˇr´ıstroj´ıch pˇreˇc´ıst, nebo nemus´ı navázat komunikaci s NFC zaˇr´ızen´ım od jiného v´ yrobce [14].

22


3.3

Mobiln´ı aplikaˇcn´ı platformy

Mobiln´ı aplikaˇ cn´ı platformy

V této kapitole budou pˇredstaveny nejrozˇs´ıˇrenˇejˇs´ı aplikaˇcn´ı platformy mobiln´ıch zaˇr´ızen´ı. Kapitola si neklade za c´ıl detailnˇe rozeb´ırat klady a nedostatky jednotliv´ ych platforem, dojde vˇsak k bliˇzˇs´ımu seznámen´ı ze strany v´ yvojáˇr˚ u aplikac´ı pro tyto platformy a budou uvedeny pˇredpoklady a poˇzadavky, které na v´ yvojáˇre jednotliv´ı vydavatelé platforem kladou. Pod pojmem mobiln´ı aplikaˇcn´ı platforma“ je moˇzné si pˇredstavit nejen sadu ” softwarového vybaven´ı pro fyzické mobiln´ı zaˇr´ızen´ı, vˇcetnˇe napˇr. jádra systému nebo programovému rozhran´ı pro aplikace tˇret´ıch stran, ale i tˇreba základn´ı sadu standard˚ u, které mus´ı koncové zaˇr´ızen´ı splˇ novat, nebo definici metod instalace aplikac´ı tˇret´ıch stran. Protoˇze kaˇzd´ y dodavatel platformy si pro sv˚ uj produkt nastavil vlastn´ı unik´ atn´ı prostˇred´ı a jen velmi obt´ıˇznˇe se stanov´ı hranice co je definováno platformou a co je jiˇz v reˇzii v´ yrobc˚ u koncov´ ych zaˇr´ızen´ı, nelze tento pojem pˇr´ıliˇs dobˇre zobecnit. Lze vˇsak ˇr´ıci, ˇze platformy se vzájemnˇe liˇs´ı jak funkcemi poskytovan´ ymi operaˇcn´ım systémem uˇzivateli, tak i rozhran´ım operaˇcn´ıho systému pro v´ yvojáˇre mobiln´ıch aplikac´ı a v neposledn´ı ˇradˇe aplikacemi tˇret´ıch stran, které jsou na dané platformˇe k dispozici.

3.3.1

St´ avaj´ıc´ı mobiln´ı platformy

V souˇcasné dobˇe lze hovoˇrit o tˇrech nejrozˇs´ıˇrenˇejˇs´ıch platformách – iOS od spoleˇcnosti Apple, Android a MS Windows Phone. Mezi dalˇs´ı, minoritn´ı platformy pak patˇr´ı BlackBerry OS nebo napˇr´ıklad Bada od spoleˇcnosti Samsung.

Apple iOS Tento mobiln´ı operaˇcn´ı systém byl urˇcen pouze pro mobiln´ı telefony iPhone, pozdˇeji se vˇsak zaˇcal pouˇz´ıvat i na dalˇs´ıch mobiln´ıch zaˇr´ızen´ıch spoleˇcnosti Apple, jako jsou iPod Touch nebo tablet iPad. Tento systém byl d´ıky své jednoduchosti pouˇz´ıván´ı, orientac´ı na dotykové ovládán´ı a zamˇeˇren´ım na stˇrednˇeproudého zákazn´ıka prvn´ı svého druhu a odstartoval dneˇsn´ı éru popularity mobiln´ıch zaˇr´ızen´ı. Obdobné systémy samozˇrejmˇe existovaly i pˇred iOS, byly vˇsak sp´ıˇse na okraji zájmu nebo byly prim´ arnˇe orientov´ any do podnikové sféry. Spoleˇcnost Apple plnˇe kontroluje nejen v´ yvoj tohoto uzavˇreného systému, ale i kompletn´ı v´ yrobu a distribuci fyzick´ ych zaˇr´ızen´ı a má také ve své reˇzii vˇsechny

23



oficiáln´ı distribuˇcn´ı kan´ aly obsahu zákazn´ık˚ um, at’ uˇz se jedná o multimediáln´ı obsah nebo aplikace tˇret´ıch stran. Pouˇzit´ı systému na jin´ ych zaˇr´ızen´ıch nen´ı moˇzné. V´ yvoj aplikac´ı je moˇzn´ y v objektovˇe orientovaném jazyce Objective-C, implementovaném jako rozˇs´ıˇren´ı jazyka C. V´ yvojáˇrské nástroje od programového prostˇred´ı aˇz po pouˇzit´ y hardware, na kterém bude programátor aplikaci vytváˇret, jsou plnˇe pod kontrolou spoleˇcnosti Apple.

Windows Phone Windows Phone je obchodn´ı n´ azev mobiln´ıho operaˇcn´ıho systému spoleˇcnosti Microsoft. V souˇcasné dobˇe jsou jako Windows Phone oznaˇcovány systémy Windows Phone 7 a Windows Phone 8, které vˇsak nejsou vzájemnˇe kompatibiln´ı a internˇe vyuˇz´ıvaj´ı jiné j´ adro a jinou verzi aplikaˇcn´ıho frameworku. Spoleˇcnost Microsoft je vydavatelem tohoto systému, sama ale ˇzádné zaˇr´ızen´ı nevyr´ ab´ı. Licence systému si kupuj´ı jednotliv´ı v´ yrobci mobiln´ıch zaˇr´ızen´ı a nasazuj´ı je do sv´ ych produkt˚ u. V´ yrobci mus´ı dodrˇzet poˇzadavky na koncové zaˇr´ızen´ı pˇredepsané spoleˇcnost´ı Microsoft. Patˇr´ı mezi nˇe napˇr. pouˇzit´ y mikroprocesor, velikost displeje, uˇzivatelsk´ a tlaˇc´ıtka, poˇzadavky na fotoaparát atp. D´ıky tomu má vydavatel platformy ˇc´ asteˇcnou kontrolu nad koncov´ ym zaˇr´ızen´ım a také to dává do rukou v´ yvoj´ aˇr˚ u aplikac´ı generickou specifikaci zaˇr´ızen´ı. V´ yvoj aplikac´ı je moˇzn´ y v jazyce C# nebo Visual Basic za pomoci .NET Frameworku ve verzi Compact, kter´ y je pˇrizp˚ usoben´ y na bˇeh na mobiln´ıch zaˇr´ızen´ıch a jeho vydavatelem je také spoleˇcnost Microsoft.

3.3.2

Mobiln´ı platforma Android

Pro potˇreby této pr´ ace se d´ıky zdaleka nejvˇetˇs´ı rozˇs´ıˇrenosti mezi uˇzivateli, otevˇrenosti, unifikovanosti a ˇsirok´ ym moˇznostem pouˇzit´ı budeme nadále pˇrednostnˇe zab´ yvat platformou Android. Android je aplikaˇcn´ı platforma urˇcená pro mobiln´ı zaˇr´ızen´ı, vyv´ıjená spoleˇcnost´ı Google a sdruˇzen´ım v´ yrobc˚ u mobiln´ıch zaˇr´ızen´ı (Open Handset Alliance) [15]. Zahrnuje operaˇcn´ı systém zaloˇzen´ y na GNU/Linuxu, uˇzivatelské rozhran´ı, sadu knihoven, podporu multimédi´ı a koncové aplikace. Vˇetˇsina ˇcást´ı této platformy je uvolˇ nov´ ana pod ASL (Apache Software License) licenc´ı, jádro systému je licencov´ ano pod GPL (General Public Licence). Jedná se tedy o open-source platformu.

24



Jednotliv´ı v´ yrobci mohou pˇrisp´ıvat do zdrojového kódu nebo jej modifikovat pro sv´ a zaˇr´ızen´ı. Andoid je zcela zdarma a kdokoliv si jej m˚ uˇze stáhnout a upravit sv´ ym potˇreb´ am. D´ıky tomu je tento systém masovˇe rozˇs´ıˇren´ y a dalece pˇresáhl své p˚ uvodn´ı urˇcen´ı – m˚ uˇzeme se s n´ım setkat i v digitáln´ıch fotoaparátech, televiz´ıch, ledniˇck´ ach nebo i na bˇeˇzn´ ych x86 poˇc´ıtaˇc´ıch.

Architektura Architektura platformy Android je rozdˇelena do nˇekolika komponent, které se mohou vz´ ajemnˇe ˇc´ asteˇcnˇe prol´ınat. Nejniˇzˇs´ı vrstva je j´ adro operaˇcn´ıho systému, které je odvozeno z Linuxového jádra. Je plnˇe vyuˇzito jeho vlastnost´ı jako je ˇsiroká podpora hardwaru, podpora správy pamˇeti, spr´ ava s´ıt´ı, ˇr´ızen´ı oprávnˇen´ı a multitaskingu nebo správa proces˚ u. To pˇrisp´ıv´ a ke stabilitˇe a ˇsiroké kompatibilitˇe systému. Naopak jádro neobsahuje moduly pro grafické uˇzivatelské rozhran´ı X Window System a ani u ´pln´ y toolkit GNU knihoven. Jádro je vyuˇz´ıv´ ano sadou knihoven napsan´ ych v jazyce C nebo C++, at’ uˇz odvozen´ ych z jin´ ych projekt˚ u nebo napsan´ ych pˇr´ımo pro Android. Jednou z tˇechto knihoven je napˇr. standardn´ı knihovna jazyka C, modifikovaná speciálnˇe pro mobiln´ı zaˇr´ızen´ı, nebo napˇr´ıklad implementace OpenGL. Komponenta zajiˇst’uj´ıc´ı bˇeh uˇzivatelsk´ ych aplikac´ı se oznaˇcuje jako Android Runtime. Obsahuje virtu´ aln´ı stroj Dalvik (DVM – Dalvik Virtual Machine), kter´ y je optimalizov´ an pro bˇeh na mobiln´ıch zaˇr´ızen´ıch. Vyuˇz´ıvá základn´ıch vlastnost´ı Linuxového j´ adra, jako je spr´ ava pamˇeti nebo práce s vlákny. V této vrstvˇe jsou také obsaˇzeny z´ akladn´ı knihovny programovac´ıho jazyka Java. Knihovny se bl´ıˇz´ı platformˇe Java SE, neposkytuj´ı vˇsak bal´ıky napˇr. pro práci s XML (eXtensible Markup Language) nebo AWT – ty byly obvykle nahrazeny vlastn´ı implementac´ı nebo bylo pouˇzito r˚ uzn´ ych projekt˚ u Apache (napˇr. pro práci se s´ıt’ov´ ym rozhran´ım). Aˇc by se tak na prvn´ı pohled mohlo zdát, Dalvik nen´ı virtuáln´ı stroj urˇcen´ y pro bˇeh klasického Java bytek´ odu. Pˇreklad aplikace prob´ıhá zkompilován´ım zdrojového kódu do Java bytek´ odu pomoc´ı klasického javac kompilátoru. Poté se tento bytekód pˇrekompiluje pomoc´ı Dalvik kompilátoru a v´ ysledn´ y Dalvik bytekód lze teprve spustit v DVM. Kaˇzd´ a spuˇstˇen´ a aplikace bˇeˇz´ı ve svém vlastn´ım procesu a s vlastn´ı instanc´ı virtu´ aln´ıho stroje. Komponenta Application framework je samotné programové rozhran´ı pro uˇzivatelskou aplikaci. Zpˇr´ıstupˇ nuje r˚ uzné sluˇzby platformy, uˇzivatelské rozhran´ı, upozorˇ novac´ı stavov´ y ˇr´ adek, aplikace bˇeˇz´ıc´ı na pozad´ı, u ´loˇziˇstˇe dat, hardware pouˇz´ı-

25



vaného zaˇr´ızen´ı, s´ıt’ové sluˇzby atp.

Android Software Development Kit Pro v´ yvoj´ aˇre aplikac´ı urˇcen´ ych pro platformu Android je vytvoˇren bal´ık r˚ uzn´ ych nástroj˚ u souhrnnˇe naz´ yvan´ y jako Android SDK. Je dostupn´ y pro vˇsechny hlavn´ı platformy operaˇcn´ıch systém˚ u GNU/Linux, Windows i Mac OS a lze jej integrovat do celé ˇsk´ aly programovac´ıch prostˇred´ı. Souˇcást´ı SDK je i emulátor, kter´ y umoˇzn´ı testovat aplikace bez pˇr´ıtomnosti fyzického zaˇr´ızen´ı.

Kompatibilita Velkou nev´ yhodou Androidu je jeho roztˇr´ıˇstˇenost“. Narozd´ıl od ostatn´ıch platfo” rem nevynucuje po v´ yrobc´ıch zaˇr´ızen´ı a v´ yvojáˇr´ıch dodrˇzován´ı základn´ı myˇslenkové linie systému – existuje pouze obecná sada doporuˇcen´ı na hardware a grafické rozhran´ı. D´ıky variabilitˇe koncov´ ych zaˇr´ızen´ı co do v´ ykonu, rozmˇer˚ u obrazovky a integrovaného vybaven´ı je pro v´ yvojáˇre velmi tˇeˇzké vyv´ıjet aplikace schopné bˇehu na vˇsech zaˇr´ızen´ıch. Nav´ıc se programové rozhran´ı u Androidu s kaˇzdou jeho verz´ı velmi rychle mˇen´ı. Zejména s nástupem tablet˚ u (na které se d´ıky velk´ ym displej˚ um mus´ı uˇzivatelské rozhran´ı koncipovat odliˇsnˇe neˇz na chytré telefony) doˇslo k velk´ ym implementaˇcn´ım zmˇenám uvnitˇr systému, které se velmi citelnˇe dotkly i aplikaˇcn´ıho frameworku. Naˇstˇest´ı existuje cel´ a ˇrada postup˚ u, jak se problém˚ um s kompatibilitou alespoˇ n ˇcásteˇcnˇe vyhnout. Zejména je moˇzné v manifestu mobiln´ı aplikace specifikovat minimáln´ı verzi platformy, na jakou je moˇzné aplikaci spustit. Dále je moˇzné specifikovat napˇr´ıklad podporovan´ a rozliˇsen´ı atp. Majitel˚ um zaˇr´ızen´ı, která nesplˇ nuj´ı nastavené podm´ınky, se aplikaci v˚ ubec nepodaˇr´ı nainstalovat, pˇr´ıpadnˇe se jim v˚ ubec nezobraz´ı v distribuˇcn´ım kanálu. Rozhran´ı aplikaˇcn´ıho frameworku je zpˇetnˇe udrˇzov´ ano, takˇze aplikace pro niˇzˇs´ı verzi platformy lze bez problém˚ u spustit na nov´ ych zaˇr´ızen´ıch. Je také moˇzné vytv´ aˇret rozvrˇzen´ı obrazovek aplikace pˇr´ımo pro nˇekolik moˇzn´ ych rozliˇsen´ı. Pokud m´ a aplikace zobrazovat bitmapy, jsou tyto konvertovány do ˇctyˇr r˚ uzn´ ych verz´ı podle u ´rovnˇe jemnosti a rozliˇsen´ı displeje tak, aby se systém sám rozhodl, jakou verzi m´ a zobrazit. Pokud program´ ator potˇrebuje pouˇz´ıvat funkcionalitu vyˇsˇs´ı verze a pˇresto mus´ı b´ yt podporov´ ana i starˇs´ı verze platformy, je to moˇzné s pouˇzit´ım tzv. Support Package Library. Tato knihovna zpˇetnˇe portuje funkcionalitu nov´ ych verz´ı Andoidu.

26


Vývoj mobiln´ıch aplikac´ı

V neposledn´ı ˇradˇe je moˇzné vyuˇz´ıt bohat´ ych moˇznost´ı emulátoru. Tomu lze nastavit ˇsirokou ˇsk´ alu moˇzn´ ych rozliˇsen´ı a je moˇzné emulovat nˇekteré hardwarové funkce re´ alného zaˇr´ızen´ı. Na emulátoru jsou lehce spustitelné vˇsechny existuj´ıc´ı verze platformy. D´ıky tomu je vˇzdy moˇzné dostateˇcnˇe otestovat aplikaci a ujistit se, ˇze se chov´ a a vypad´ a stejnˇe na ˇsiroké ˇskále zaˇr´ızen´ı, aniˇz by je v´ yvojáˇr fyzicky vlastnil.

3.4

V´ yvoj mobiln´ıch aplikac´ı

Jak vypl´ yv´ a z pˇredch´ azej´ıc´ıho pˇrehledu, s kaˇzdou platformou se poj´ı zcela jiná sada technologi´ı a vyuˇziteln´ ych programovac´ıch jazyk˚ u. Nav´ıc i r˚ uzné verze té samé platformy mohou b´ yt mezi sebou navzájem nekompatibiln´ı. Moˇznosti v´ yvoje aplikac´ı pro mobiln´ı platformy jsou nav´ıc limitovány dalˇs´ımi restrikcemi ze strany vydavatele platformy (napˇr. v´ yvojáˇrské nástroje nebo distribuˇcn´ı kanály aplikace).

3.4.1

Pˇ renositelnost aplikac´ı

Nab´ız´ı se ot´ azka, zda by nebylo moˇzné implementovat aplikaci tak, aby byla pˇrenositeln´ a napˇr´ıˇc v´ yˇse zm´ınˇen´ ymi platformami. To by umoˇznilo sn´ıˇzit u ´roveˇ n duplicity kódu a t´ım omezit ˇcasové a finanˇcn´ı náklady na v´ yvoj. Nav´ıc by nebylo nutné udrˇzovat k´ od hned v nˇekolika jazyc´ıch.

HTML5 (HyperText Markup Language) ˇ asteˇcn´ C´ a odpovˇed’ na tuto ot´ azku spoˇc´ıvá v novˇe vznikaj´ıc´ı specifikaci jazyka HTML. Tzv. HTML5 je standard, kter´ y (kromˇe jiného) bude umoˇzn ˇovat pˇrehráván´ı multimédi´ı pˇr´ımo ve webovém prohl´ıˇzeˇci a v kombinaci s dalˇs´ımi technologiemi jako je CSS a JavaScript vytv´ aˇret aplikace, které funguj´ı i bez pˇripojen´ı k Internetu nebo k intern´ı s´ıti organizace [16]. Vˇetˇsina souˇcasn´ ych prohl´ıˇzeˇc˚ u (vˇcetnˇe tˇech pro dˇr´ıve zm´ınˇené mobiln´ı platformy) jiˇz HTML5 na alespoˇ n elementárn´ı u ´rovni podporuj´ı. Pokud by se podaˇrilo vyvinout aplikaci s vyuˇzit´ım na jiˇz ustálen´ ych a implementovan´ ych ˇc´ asti HTML5 standardu, mˇela by tato aplikace b´ yt spustitelná na vˇsech mobiln´ıch platform´ ach, kde je dostupn´ y dostateˇcnˇe sofistikovan´ y webov´ y prohl´ıˇzeˇc. Tento pˇr´ıstup se vˇsak pot´ yk´ a s celou ˇradou problém˚ u. Takto vytvoˇrená aplikace vyˇzaduje pro sv˚ uj bˇeh dalˇs´ı aplikaˇcn´ı vrstvu v podobˇe prohl´ıˇzeˇce – interpretera jazyka HTML5. To s sebou nese zv´ yˇsené nároky na systémové prostˇredky zaˇr´ızen´ı

27



a s t´ım souvisej´ıc´ı sniˇzov´ an´ı v´ ydrˇze baterie. Specifikace HTML5 stále nen´ı koneˇcná a jeho podpora mezi prohl´ıˇzeˇci je velice variabiln´ı. Nejvˇetˇs´ı nev´ yhodou je vˇsak to, ˇze aplikace nem´ a pˇr´ım´ y pˇr´ıstup k aplikaˇcn´ımu frameworku mobiln´ı platformy, coˇz prakticky znemoˇzn ˇuje vyuˇz´ıt technické prostˇredky zaˇr´ızen´ı, jejichˇz rozhran´ı jde nad r´ amec definovaného HTML5 standardu. Pokud je vˇsak aplikace dostateˇcnˇe jednoduch´ a, je jistˇe moˇzné sluˇzeb technologie HTML5 vyuˇz´ıt.

Xamarin toolkit Efektivnˇejˇs´ım ˇreˇsen´ım problému by bylo pouˇzit´ı toolkitu spoleˇcnosti Xamarin. Ta se rozhodla pˇrevz´ıt projekt Mono, kter´ y byl p˚ uvodnˇe veden´ y spoleˇcnost´ı Novell. Mono je open-source projekt, jehoˇz c´ılem je vytvoˇrit multiplatformn´ı implementaci .NET frameworku. Mono je podporováno na operaˇcn´ıch systémech Microsoft Windows, Linux, Unix, OS X, Solaris, BSD, Android, iOS a také na nˇekter´ ych hern´ıch konzol´ıch. Souˇc´ ast´ı projektu jsou také nástroje pro podporu v´ yvoje, multiplatformn´ı C# kompil´ ator a implementace r˚ uzn´ ych dalˇs´ıch knihoven [17]. Jazykem multiplatformn´ı aplikace by se tedy stal C#. Knihovny toolkitu podporuj´ı integraci do platforem iOS a Android, do kaˇzdé trochu jin´ ym zp˚ usobem. Ve druhém pˇr´ıpadˇe lze zjednoduˇsenˇe ˇr´ıci, ˇze kaˇzdá takto vytvoˇrená aplikace pro Android je puˇstˇena ve dvou bˇehov´ ych prostˇred´ıch – NET Mono runtime a DVM, pˇriˇcemˇz je vyuˇzito JNI (Java Native Interface) rozhran´ı pro vzájemnou komunikaci obou prostˇred´ı. Protoˇze je Mono runtime implementován v jazyce C, m˚ uˇze velmi jednoduˇse volat systémové sluˇzby Linuxového jádra Androidu nebo vyuˇz´ıvat pˇridruˇzen´ ych knihoven (napˇr. pro OpenGL grafiku). Technologie m´ a samozˇrejmˇe své limity (nelze pouˇz´ıt ˇzádné Java knihovny, pouze ˇc´ asteˇcn´ a podpora Java generick´ ych tˇr´ıd, nˇekterá standardn´ı rozhran´ı nelze implementovat) a nezaruˇcuje stoprocentn´ı pˇrepouˇzitelnost kódu, nicménˇe pˇredstavuje zaj´ımavou moˇznost jak vyrobit skuteˇcnˇe multiplatformn´ı mobiln´ı aplikaci. Toolkit je bezplatnˇe uvolnˇen pouze k omezenému vyuˇzit´ı, dalˇs´ı funkcionalitu je tˇreba dokoupit.

28


3.4.2


V´ yvojov´ e prostˇ red´ı

V´ yvoj aplikac´ı pro mobiln´ı zaˇr´ızen´ı se ve své elementárn´ı formˇe nijak zásadnˇe neliˇs´ı od klasického programov´ an´ı plnohodnotn´ ych“ desktopov´ ych aplikac´ı. Vydavatel ” platformy poskytuje sadu standardn´ıch v´ yvojáˇrsk´ ych nástroj˚ u, integrované v´ yvojové prostˇred´ı a emul´ ator, na kterém je moˇzné aplikace spouˇstˇet a debuggovat. Na Obrázku 3.1 je sn´ımek obrazovky bˇeˇz´ıc´ıho emulátoru mobiln´ı platformy Android.

Obrázek 3.1: Bˇeˇz´ıc´ı emulátor platformy Android. Spouˇstˇet aplikace je samozˇrejmˇe moˇzné i s fyzick´ ym zaˇr´ızen´ım (zejména proto, ˇze emulátor z principu nem˚ uˇze emulovat vˇsechny funkce zaˇr´ızen´ı jako je gyroskop, telefonn´ı hovory atp.). Nˇekteˇr´ı vydavatelé ovˇsem omezuj´ı vyuˇzit´ı fyzick´ ych zaˇr´ızen´ı (napˇr. Microsoft zavedl maxim´ aln´ı poˇcet takto nainstalovan´ ych aplikac´ı a podmin ˇuje pouˇzit´ı re´ alného zaˇr´ızen´ı jeho online registrac´ı). Nˇekdy je také moˇzné vyuˇz´ıt v´ yvojáˇrské prostˇred´ı tˇret´ıch stran, coˇz se ˇr´ıd´ı licenˇcn´ımi podm´ınkami vydavatel˚ u platformy. Kupˇr´ıkladu u Androidu je moˇzné vyuˇz´ıt hned nˇekolika moˇzn´ ych prostˇred´ı nebo si i vytvoˇrit prostˇred´ı vlastn´ı. Nejobvyklejˇs´ı volbou je zpravidla instalace zásuvného modulu do ˇsiroce pouˇz´ıvaného v´ yvojového prostˇred´ı Eclipse. Modul umoˇzn ˇuje nejen správu fyzick´ ych zaˇr´ızen´ı a emulátor˚ u, ale i pˇr´ımou instalaci a debuggován´ı aplikace a integruje tak Android SDK toolkit a samotné v´ yvojové prostˇred´ı.

29


3.4.3


Distribuce aplikac´ı

Je obvyklé, ˇze vydavatel platformy povoluje distribuci aplikac´ı pouze pˇres sv˚ uj oficiáln´ı centr´ aln´ı distribuˇcn´ı kan´ al – napˇr. na Obrázku 3.2 je ukázka aplikace urˇcené pro distribuci a spr´ avu uˇzivatelsk´ ych aplikac´ı pro mobiln´ı platformu Android.

Obrázek 3.2: Ukázka distribuce aplikac´ı pro platformu Android. V´ yvoj´ aˇr mobiln´ı aplikace mus´ı zpravidla m´ıt vytvoˇren´ y v´ yvojáˇrsk´ yu ´ˇcet u vydavatele platformy a svou aplikaci neposkytuje pˇr´ımo c´ılov´ ym uˇzivatel˚ um, ale nahrává ji vˇzdy pˇres tento u ´ˇcet do distribuˇcn´ıho kanálu. Nˇekteˇr´ı vydavatelé neposkytuj´ı tyto u ´ˇcty zdarma nebo participuj´ı na zisc´ıch z prodeje aplikace.

30


Shrnut´ı

Tento model m´ a nˇekolik v´ yhod – uˇzivatelé vid´ı vˇsechny aplikace pro své zaˇr´ızen´ı na jednom m´ıstˇe. Pokud je aplikace placená, je finanˇcn´ı transakce uskuteˇcnˇena vˇzdy jen mezi z´ akazn´ıkem a vydavatelem platformy – ten se poté postará o rozdˇelen´ı této ˇcástky. Je obvyklé ˇze tyto kan´ aly se staraj´ı i o aktualizace aplikac´ı. V neposledn´ı ˇradˇe distribuˇcn´ı kan´ aly ˇc´ asteˇcnˇe ˇreˇs´ı i otázku bezpeˇcnosti a jisté kvality aplikac´ı – vydavatel platformy m´ a kontrolu nad obsahem distribuˇcn´ıho kanálu. Na druhou stranu m˚ uˇze b´ yt tento model aˇz zbyteˇcnˇe omezuj´ıc´ı. To, jestli bude moˇzné instalovat aplikace i z jin´ ych zdroj˚ u, záleˇz´ı ˇcistˇe na vydavateli platformy.

3.5

Shrnut´ı

Seznámili jsme se s ˇsirok´ ymi moˇznostmi mobiln´ıch zaˇr´ızen´ı, at’ jiˇz po stránce vyuˇzitelnosti v r´ amci informaˇcn´ıch systém˚ u, tak po stránce technologické. Byly pˇredstaveny tˇri nejrozˇs´ıˇrenˇejˇs´ı mobiln´ı platformy s d˚ urazem na moˇznosti v´ yvoje aplikac´ı pro tyto platformy a jejich n´ aslednou distribuci.

31

4 Poˇzadavky na systém správy rezervac´ı Tato kapitola m´ a na z´ akladˇe pˇr´ıpadové studie na Katedˇre informatiky a v´ ypoˇcetn´ı techniky pˇri Z´ apadoˇceské Univerzitˇe v Plzni a pˇredcházej´ıc´ıho zobecnˇen´ı problému v´ yp˚ ujˇcek a rezervac´ı objekt˚ u za c´ıl navrhnout kompletn´ı specifikaci poˇzadavk˚ u na nov´ y systém v´ yp˚ ujˇcek a rezervac´ı. Nejprve dojde k rozboru vyuˇzitelnosti mobiln´ıch technologi´ı pro tento systém. N´ aslednˇe bude definována pˇresná sada funkc´ı, které mus´ı nov´ y systém implementovat.

4.1

Vyuˇ zitelnost mobiln´ıch zaˇ r´ızen´ı

V Kap. 2.4 jsme definovali v´ yˇcet základn´ıch poˇzadavk˚ u na nov´ y systém, aniˇz bychom definovali jejich technologick´ y podklad. Nyn´ı se pokus´ıme spojit tyto poˇzadavky s technologiemi mobiln´ıch zaˇr´ızen´ı tak, abychom maximálnˇe vyuˇzili v´ yhody, které n´ am tyto technologie nab´ızej´ı.

4.1.1

Moˇ znosti pˇ r´ıstupu a autorizace

Je moˇzné si pˇredstavit nˇekolik zp˚ usob˚ u technického ˇreˇsen´ı pˇr´ıstupu do systému za pomoci mobiln´ıch zaˇr´ızen´ı a s t´ım souvisej´ıc´ı autorizace uˇzivatel˚ u.

Jeden termin´ al pro v´ıce uˇ zivatel˚ u V organizaci jsou na pˇredem dan´ ych m´ıstech rozm´ıstˇeny tablety, umoˇzn ˇuj´ıc´ı autorizaci uˇzivatele a n´ aslednou rezervaci objektu. Tyto terminály jsou vybaveny technologi´ı NFC. Uˇzivatel, kter´ y chce provést rezervaci, pˇristoup´ı k tabletu, pˇriloˇz´ı sv˚ uj telefon vybaven´ y NFC technologi´ı a d´ıky unikátn´ımu kl´ıˇci se pˇrihlás´ı do systému. V´ yhody jsou zˇrejmé – d´ıky NFC ˇsifrován´ı je identifikátor nezjistiteln´ y tˇret´ı stranou. V organizaci jiˇz m˚ uˇze existovat princip ovˇeˇrován´ı uˇzivatel˚ u na principu pˇr´ıstupov´ ych karet a v tom pˇr´ıpadˇe lze za pˇredpokladu, ˇze je NFC technologie se standardem karet navz´ ajem kompatibiln´ı, autentizaci sjednotit se stávaj´ıc´ı infrastrukturou (pˇr´ıstupové karty by hrály roli NFC tagu s u ´daji o uˇzivateli). Uˇzivatelé si také nemus´ı pamatovat dalˇs´ı heslo.

32

Poˇzadavky na systém správy rezervac´ı

Vyuˇzitelnost mobiln´ıch zaˇr´ızen´ı

Autorizace pˇres NFC m´ a vˇsak také své nev´ yhody – pouˇzit´ı kompatibiln´ıch pˇr´ıstupov´ ych karet nelze pauˇsalizovat, coˇz se nesluˇcuje se základn´ım poˇzadavkem poskytnout co nejuniverz´ alnˇejˇs´ı ˇreˇsen´ı systému. Mobiln´ıch zaˇr´ızen´ı vybaven´ ych NFC technologi´ı je st´ ale pˇr´ıliˇs m´ alo na to, aby bylo moˇzné omezit autorizaci jen na nˇe. Pro ovˇeˇrov´ an´ı by se daly teoreticky pouˇz´ıt i ˇcárové nebo QR kódy. Kaˇzd´ y uˇzivatel by u sebe nosil visaˇcku s vytiˇstˇen´ ym kódem a pouze by ji pˇriloˇzil k integrovanému fotoapar´ atu tabletu. Toto levné a jednoduché ˇreˇsen´ı (kaˇzd´ y by si sv˚ uj unikátn´ı k´ od mohl svépomoc´ı opakovanˇe vytisknout) ovˇsem naráˇz´ı na nepˇrekonatelnou bariéru – tyto k´ ody nelze nijak ˇsifrovat. Pro jednoduchou autorizaci by jistˇe postaˇcily, ale jejich snadn´ a reprodukovatelnost, ˇcitelnost a nulová moˇznost zabezpeˇcen´ı toto ˇreˇsen´ı pˇredem zavrhuje. Nev´ yhodou celého modelu je také jeho statiˇcnost. Nen´ı ˇzádouc´ı nutit uˇzivatele, aby kv˚ uli rezervov´ an´ı m´ıstnosti leˇz´ıc´ı v pˇr´ızem´ı chodili do pátého patra budovy, protoˇze je tam je um´ıstˇen´ y tablet s aplikac´ı umoˇzn ˇuj´ıc´ı vytvoˇren´ı rezervace. Pokus´ıme se tedy spojit mobiln´ı zaˇr´ızen´ı se systémem jeˇstˇe u ´ˇzeji.

Jeden termin´ al pro jednoho uˇ zivatele V tomto modelu prov´ ad´ı uˇzivatelé rezervace na zaˇr´ızen´ıch, která maj´ı fyzicky u sebe – tedy na sv´ ych osobn´ıch telefonech a tabletech. Zde se jiˇz jev´ı autorizace pomoc´ı NFC nebo optick´ ych k´ od˚ u jako zcela zbyteˇcná. Nen´ı ˇzádného d˚ uvodu proˇc nevyuˇz´ıt intern´ı u ´loˇziˇstˇe zaˇr´ızen´ı a neautorizovat se pomoc´ı jména a hesla, pˇriˇcemˇz tyto u ´daje by byly pauˇs´ alnˇe vyˇzadovány pouze pˇri prvn´ım startu aplikace nebo pˇri ne´ uspˇeˇsném pˇripojen´ı do systému. Tyto u ´daje by mˇelo b´ yt moˇzné kdykoliv zmˇenit. Pˇredch´ azej´ıc´ı model se s t´ımto pˇr´ıstupem pˇritom nijak nevyluˇcuje – je moˇzné poskytnout dalˇs´ı, webové rozhran´ı pro ty uˇzivatele, kteˇr´ı patˇriˇcné zaˇr´ızen´ı nevlastn´ı, nebo je z nˇejakého d˚ uvodu odm´ıtaj´ı pouˇz´ıvat. V tomto webovém rozhran´ı by se uˇzivatelé autorizovali stejn´ ym jménem a heslem jako na mobiln´ıch zaˇr´ızen´ıch s t´ım rozd´ılem, ˇze by mˇelo b´ yt umoˇznˇeno se ze systému kdykoliv odhlásit. Toto webové rozhran´ı je poté moˇzno provozovat kdekoliv jako statick´ y terminál a uˇzivatelé se k nˇemu budou moci pˇripojovat ze sv´ ych poˇc´ıtaˇc˚ u pˇres webov´ y prohl´ıˇzeˇc. Port´ al bude také moˇzné vyuˇz´ıt pro administrátory systému ke správˇe objekt˚ u, uˇzivatel˚ u a rezervac´ı. V r´ amci co nejvˇetˇs´ıho uˇzivatelského komfortu by také mˇelo b´ yt moˇzné vyuˇz´ıt jiˇz pravdˇepodobnˇe existuj´ıc´ı databázi uˇzivatel˚ u a ovˇeˇrovat zadaná jména a hesla proti této datab´ azi. Uˇzivatelé by poté nemuseli spravovat duplicitn´ı pˇrihlaˇsovac´ı u ´daje.

33


4.1.2


Identifikace objekt˚ u

Pro vytvoˇren´ı rezervace je nejprve tˇreba pˇresnˇe urˇcit, k jakému objektu rezervaci vytváˇr´ıme. D´ıky mobiln´ım zaˇr´ızen´ım máme k dispozici v´ıc neˇz jen obvyklou sadu moˇznost´ı (napˇr. fulltextové vyhledáván´ı, databázové dotazy apod.) – m˚ uˇzeme vyuˇz´ıt NFC technologii nebo optické kódy. Obˇe technologie dovol´ı identifikaci ˇrádovˇe urychlit. V prvn´ım pˇr´ıpadˇe jsou objekty fyzicky spárovány s NFC nebo RFID pasivn´ımi tagy. Uˇzivatel vytv´ aˇrej´ıc´ı rezervaci pouze pˇriloˇz´ı zaˇr´ızen´ı vybavené NFC k tagu a prakticky okamˇzitˇe z´ısk´ a identifikátor objektu, se kter´ ym lze poté dále pracovat. V´ yhodou je zejména objem dat, kter´ y se do tagu vejde – je moˇzné do tag˚ u uloˇzit i dalˇs´ı informace o objektu (polohu, inventárn´ı ˇc´ıslo apod.) a ty prohl´ıˇzet libovolnou NFC ˇcteˇckou. Nezanedbatelná je také trvanlivost a odolnost pasivn´ıch tag˚ ua moˇznost jejich snadného um´ıstˇen´ı. Bohuˇzel, ke vˇsem nev´ yhod´ am NFC, které jiˇz byly zm´ınˇeny, se pˇridávaj´ı i pomˇernˇe vysoké n´ aklady za poˇr´ızen´ı tag˚ u a jejich nesnadná replikovatelnost. Protoˇze tagy mus´ı b´ yt kv˚ uli snadné orientaci um´ıstˇeny na dobˇre viditelném m´ıstˇe, jistˇe by se po ˇcase staly c´ılem nenechavc˚ u. ˇ sen´ım je vyuˇzit´ı optick´ Reˇ ych QR kód˚ u. Do tˇechto kód˚ u je moˇzné (narozd´ıl od kód˚ u ˇc´ arov´ ych) uloˇzit obdobn´ y objem dat jako do NFC tag˚ u, ovˇsem nepoj´ı se s nimi ˇz´ adné fyzické zaˇr´ızen´ı. D´ıky tomu je moˇzné QR kódy libovolnˇe replikovat a mˇenit jejich velikost, lepit je po zdech, vkládat je do hlaviˇcek dokument˚ u, nástˇenek, popisk˚ u dveˇr´ı, ˇst´ıtk˚ u notebook˚ u atp. Pokud je ˇst´ıtek poˇskozen, je moˇzné pˇri ˇcten´ı vyuˇz´ıt autoopravn´ ych algoritm˚ u, které umoˇzn ˇuj´ı i z velmi poˇskozeného obrazu z´ıskat p˚ uvodn´ı data. Pˇri nenávratném zniˇcen´ı ˇst´ıtku staˇc´ı pouze vytisknout na obyˇcejné tisk´ arnˇe ˇst´ıtek jin´ y. Uˇzivatel m´ısto NFC ˇcipu vyuˇzije prostého fotoapar´ atu, a t´ım se pouˇzitelnost mobiln´ıch zaˇr´ızen´ı pˇri vytváˇren´ı rezervace ˇrádovˇe rozˇs´ıˇr´ı. Nev´ yhodou oproti NFC je pak niˇzˇs´ı odolnost nosného materiálu a pomalejˇs´ı doba ˇcten´ı – d´ıky obvykle n´ızké kvalitˇe integrovan´ ych fotoaparát˚ u a potˇreby analyzovat jejich obraz dalˇs´ımi algoritmy je ˇcten´ı QR kód˚ u obvykle o nˇeco pomalejˇs´ı. M˚ uˇze doj´ıt k tak velkému fyzickému poˇskozen´ı ˇst´ıtku, ˇze jiˇz nebude ˇciteln´ ya nov´ y nebude moment´ alnˇe k dispozici. Pro tyto pˇr´ıpady by mˇela mobiln´ı aplikace umoˇznit i klasické vyhled´ an´ı objektu podle textového ˇretˇezce, pˇr´ıpadnˇe nab´ıdnout moˇznost vytvoˇrit si seznam ˇcasto pouˇz´ıvan´ ych objekt˚ u. Tato funkcionalita uˇzivatel˚ um mimo jiné umoˇzn´ı rezervovat si libovoln´ y objekt, aniˇz by byli nuceni skenovat QR k´ od.

34


4.1.3


Vyzvednut´ı a vr´ acen´ı objektu

Pro vyzved´ av´ an´ı a vracen´ı objekt˚ u m˚ uˇzeme pouˇz´ıt jiˇz definované postupy pro identifikaci objekt˚ u. Uˇzivatel m˚ uˇze na svém osobn´ım zaˇr´ızen´ı objekt bud’ skenovat, nebo vyuˇzije jinou metodu pro identifikaci. Poté dojde k samotné akci vyzvednut´ı nebo vr´ acen´ı.

4.1.4

Lokalizace objekt˚ u

Lokalizace objekt˚ u v re´ alném ˇcase nen´ı snadná. U nepohybliv´ ych objekt˚ u mimo budovu je moˇzné urˇcit jejich zemˇepisnou polohu na základˇe GPS pˇrij´ımaˇce a tu poté distribuovat spolu s popisem objektu, zakódovat ji do QR popisu atp. Uˇzivatelé si poté mohou snadno zobrazit polohu objektu na svém mobiln´ım zaˇr´ızen´ı v integrovan´ ych mapov´ ych podkladech. U pohybliv´ ych objekt˚ u jistˇe m˚ uˇzeme obdobnˇe definovat jejich obvyklou polohu v dobˇe, kdy nejsou nikomu vyp˚ ujˇceny. Jak ovˇsem zaˇr´ıdit sledován´ı objekt˚ u v reálném ˇcase, tedy i v ˇcase vyp˚ ujˇcen´ı uˇzivatel˚ um? Osazen´ı vˇsech objekt˚ u GPS lokátory je finanˇcnˇe ne´ unosné. Bylo by moˇzné sledovat objekty na základˇe polohy zaˇr´ızen´ı, ze kter´ ych byly tyto objekty vyzvednuty. To se vˇsak rovná sledován´ı polohy majitele zaˇr´ızen´ı a t´ım p´ adem se tento pˇr´ıstup pot´ yká s celou ˇradou problém˚ u: - uˇzivatelé mus´ı d´ at provozovateli systému souhlas se sledován´ım. - mobiln´ı zaˇr´ızen´ı se nesm´ı vzdálit od sledovaného objektu. - uˇzivateli staˇc´ı vypnout GPS navigaci nebo pˇripojen´ı na Internet a sledován´ı je ztraceno. - sledov´ an´ı nebude fungovat uvnitˇr budov. Tyto problémy ˇcin´ı efektivn´ı sledován´ı objekt˚ u velice obt´ıˇzn´ ym. ˇ sen´ı uvnitˇr budov by mohlo b´ Reˇ yt vyuˇzit´ı pasivn´ıch RFID far–field tag˚ u, které by byly fyzicky sv´ az´ any s objekty. To by v kombinaci ˇcteˇcek tˇechto tag˚ u um´ıstˇen´ ych na vˇsech r´ amech dveˇr´ı a dalˇs´ıch strategick´ ych m´ıstech umoˇznilo jakési sledován´ı polohy – ˇcteˇcky by mˇely unik´ atn´ı identifikátor a byly by propojeny s centráln´ım serverem, kter´ y by znal polohu ˇcteˇcek. Pˇri kaˇzdém pr˚ uchodu tagu kolem ˇcteˇcky by tato odeslala na server sv˚ uj identifikátor a identifikátor objektu pˇreˇcten´ y z RFID tagu. T´ım by se dos´ ahlo alespoˇ n pˇribliˇzné polohy. Bohuˇzel, nejenˇze by bylo moˇzné tento systém velmi jednoduˇse obej´ıt, byl by také finanˇcnˇe nákladn´ y a nároˇcn´ y na

35


Obecný popis systému

infrastrukturu. Dˇr´ıve zm´ınˇené moˇznosti IPS navigace se zdaj´ı b´ yt pro u ´ˇcely této práce jen obt´ıˇznˇe vyuˇzitelné. Zvol´ıme proto jin´ y pˇr´ıstup. Objekty budou slouˇceny do skupin – tˇr´ıd, které je budou nˇejak´ ym zp˚ usobem popisovat a seskupovat. Zp˚ usob slouˇcen´ı objekt˚ u z˚ ustane zámˇernˇe nedefinov´ an – m˚ uˇze tak b´ yt z d˚ uvodu geografického (vˇsechny objekty v budovˇe A), technického, na z´ akladˇe podobnosti objekt˚ u, na základˇe stejného dodavatele – konkrétn´ı d˚ uvody pro slouˇcen´ı budou pˇrenechány na administrátorech ´ systému. Udaj o lokaci poté bude moci moˇzné uvést v popisu objektu, nebo v popisu tˇr´ıdy. Vˇetˇsina mobiln´ıch zaˇr´ızen´ı syntaxi geografick´ yh souˇradnic rozpozná a v pˇr´ıpadˇe nutnosti nab´ıdne jejich zobrazen´ı v intern´ıch mapách.

4.1.5

Shrnut´ı

Z anal´ yzy vyuˇzitelnosti mobiln´ıch zaˇr´ızen´ı pro systém správy v´ yp˚ ujˇcek a rezervac´ı vyplynuly pro u ´ˇcely této pr´ ace následuj´ıc´ı obecné poˇzadavky na koncov´ y systém. Uˇzivatelé budou moci na svém mobiln´ım zaˇr´ızen´ı vyuˇz´ıvat aplikaci pro vytváˇren´ı a editaci rezervac´ı objekt˚ u. Z mobiln´ıch technologi´ı bude vyuˇzit fotoaparát jako ˇcteˇcka QR k´ od˚ u a pˇr´ıstup k Internetu. Kaˇzd´ y objekt bude m´ıt unikátn´ı QR kód, jehoˇz naskenov´ an´ım budou moci uˇzivatelé objekt jednoznaˇcnˇe identifikovat. Systém nab´ıdne vyhled´ av´ an´ı objekt˚ u a editovateln´ y seznam obl´ıben´ ych“ objekt˚ u ” pro kaˇzdého uˇzivatele. Vedle této aplikace bude spuˇstˇen i webov´ y portál se stejnou funkcionalitou s v´ yjimkou skenov´ an´ı QR k´ od˚ u. Portál bude slouˇzit nejen uˇzivatel˚ um pro správu vlastn´ıch rezervac´ı a seznamu obl´ıben´ ych objekt˚ u, ale i administrátor˚ um pro správu objekt˚ u, uˇzivatel˚ u a jejich rezervac´ı. Objekty budou sluˇcov´ any do tˇr´ıd podle logick´ ych pravidel definovan´ ych administrátory systému. Jak objekty, tak tˇr´ıdy objekt˚ u poskytnou moˇznost dodateˇcného popisu, ve kterém mohou b´ yt libovolné informace vˇcetnˇe zemˇepisn´ ych souˇradnic.

4.2

Obecn´ y popis syst´ emu

Pˇredmˇetem tohoto popisu a n´ asledné specifikace je systém pro realizaci rezervac´ı movit´ ych a nemovit´ ych objekt˚ u pomoc´ı centráln´ıho serveru s webov´ ym rozhran´ım a mobiln´ıch klient˚ u.

36


4.2.1

Obecný popis systému

´ cel syst´ Uˇ emu

Systém slouˇz´ı k realizaci ˇcasové rezervace objekt˚ u. Objekty se rozum´ı jak vˇeci movité (jako napˇr´ıklad notebook, projektor atp.), tak i vˇeci nemovité. D´ıky tomuto systému bude moˇzné na Katedˇre informatiky a v´ ypoˇcetn´ı techniky pˇri Západoˇceské Univerzitˇe v Plzni zefektivnit stávaj´ıc´ı procesy vyp˚ ujˇcován´ı a rezervace tˇechto objekt˚ u, rozˇs´ıˇrit oblast pouˇzit´ı i na dalˇs´ı objekty co do typu a mnoˇzstv´ı a decentralizovat spr´ avu objekt˚ u, v´ yp˚ ujˇcek a rezervac´ı.

4.2.2

Rozsah syst´ emu

Uˇzivatelé se pˇripojuj´ı k centr´ aln´ımu serveru systému pomoc´ı klientské aplikace nebo prostˇrednictv´ım webového rozhran´ı. Autorizace uˇzivatel˚ u systému prob´ıhá zadán´ım kombinace unik´ atn´ıho jména a hesla. Souˇcást´ı systému bude databáze uˇzivatel˚ u. Systém bude implementovat dva zp˚ usoby autorizace - oproti lokáln´ı datab´ azi systému a pomoc´ı u ´ˇctu systému Orion. Po pˇripojen´ı je moˇzné vytv´ aˇret nebo editovat rezervace objekt˚ u a uskuteˇcn ˇovat jejich v´ yp˚ ujˇcky. Rezervace je tvoˇrena identifikátorem rezervovaného objektu a ˇcasov´ ym rozpˇet´ım, po které si uˇzivatel chce objekt rezervovat. Identifikátor bude realizov´ an jako textov´ y popisek nebo jako QR kód fyzicky um´ıstˇen´ y na objektu. Objekty budou seskupeny do tˇr´ıd. V´ ysledkem ˇcinnosti systému je kalendáˇr s rezervacemi, kter´ y bude zobrazen pro kaˇzdého uˇzivatele a pro kaˇzd´ y objekt v klientské aplikaci a ve webovém rozhran´ı.

4.2.3

Omezen´ı n´ avrhu a implementace

Pro spr´ avnou funkci celého systému je nutné pˇripojen´ı k internetu. Serverová ˇcást bude implementov´ ana v programovac´ım jazyce Java. Systém bude poskytovat webové rozhran´ı. Klientsk´ a mobiln´ı aplikace bude implementována pro platformu Android.

4.2.4

Tˇ r´ıdy uˇ zivatel˚ u

V systému budou definov´ any tˇri tˇr´ıdy uˇzivatel˚ u: - Uˇzivatel – typicky zamˇestnanec katedry nebo jej´ı spolupracovn´ık, kter´ y si

37


Funkce webového rozhran´ı

potˇrebuje p˚ ujˇcovat objekty z inventáˇre katedry nebo provádˇet jejich rezervace pro napˇr. v´ yukové u ´ˇcely. - Spr´ avce rezervac´ı – zamˇestnanec sekretariátu katedry nebo jiná osoba odpovˇedn´ a za udrˇzov´ an´ı poˇr´ adku v rezervac´ıch a v´ yp˚ ujˇckách majetku. - Administr´ ator – zamˇestnanec sekretariátu katedry, správce s´ıtˇe katedry nebo jin´ a osoba odpovˇedn´ a za udrˇzován´ı informaˇcn´ıho systému katedry.

4.3

Funkce webov´ eho rozhran´ı

V této tapitole dojde k pˇresnému vymezen´ı systému a definici funkc´ı poˇzadovan´ ych od webového rozhran´ı.

4.3.1

Z´ akladn´ı rozvrˇ zen´ı webov´ eho rozhran´ı

Rozvrˇzen´ı webového rozhran´ı se bude skládat z hlaviˇcky s názvem aplikace a hlavn´ıho menu um´ıstˇeného na levé stranˇe obrazovky (Obr. 4.1). V menu se bude zobrazovat konstantn´ı seznam hypertextov´ ych odkaz˚ u. Pˇri kliknut´ı na odkaz se poˇzadovan´ a str´ anka zobraz´ı v pravé ˇcásti vedle menu. Aplikace pro rezervaci předmět ů

Hlavička stránky Menu Odkaz1 Odkaz2 Odkaz3 Odkaz4 Odkaz5

Obsah

...

Obrázek 4.1: Základn´ı rozvrˇzen´ı webového rozhran´ı.

38


4.3.2


Autorizace uˇ zivatel˚ u

Do webového rozhran´ı bude umoˇznˇeno pˇrihláˇsen´ı pomoc´ı uˇzivatelského jména a hesla a n´ asledné u ´plné odhl´ aˇsen´ı (Diagram 4.1). Bez pˇrihláˇsen´ı nebude umoˇznˇena ˇzádná dalˇs´ı interakce se systémem a bude zobrazena stránka s pˇrihlaˇsovac´ım formuláˇrem. Odkaz pro odhl´ aˇsen´ı bude pˇr´ımou souˇcást´ı hlavn´ıho menu aplikace. V pˇr´ıpadˇe neaktivity bude uˇzivatel automaticky odhláˇsen.

Diagram uˇzit´ı 4.1: Autorizace uˇzivatel˚ u pˇres webové rozhran´ı.

4.3.3

Spr´ ava uˇ zivatel˚ u

Pro vˇsechny role budou viditelné profily ostatn´ıch uˇzivatelsk´ ych u ´ˇct˚ u. Administrátor bude moci vytv´ aˇret, mazat a editovat vˇsechny uˇzivatelské u ´ˇcty v systému (Diagram 4.2). Uˇzivatelsk´ yu ´ˇcet se bude skl´ adat ze jména, pˇr´ıjmen´ı, emailu, definice role v systému, pˇrihlaˇsovac´ıho jména a poskytovatele autorizace u ´ˇctu. Vˇsechny poloˇzky mus´ı b´ yt pˇri vytv´ aˇren´ı nebo editaci profilu vyplnˇeny. Pˇri smazán´ı u ´ˇctu uˇzivatele mus´ı b´ yt odstranˇeny i vˇsechny s u ´ˇctem souvisej´ıc´ı rezervace.

Editace profilu a zmˇ ena hesla Pokud je poskytovatel autorizace u ´ˇctu nastaven na intern´ı databázi, je pˇri vytváˇren´ı u ´ˇctu vyˇzadov´ ano i zad´ an´ı hesla. T´ımto heslem poté budou uˇzivatelé systému autorizov´ ani. Vˇsechny role budou moci mˇenit své vlastn´ı heslo, pouze Administrátor bude opr´ avnˇen mˇenit hesla i ostatn´ıch u ´ˇct˚ u (Diagram 4.3).

39



Diagram uˇzit´ı 4.2: Zobrazen´ı a editace uˇzivatelsk´ ych u ´ˇct˚ u. Vˇsechny role také mohou mˇenit poloˇzky svého vlastn´ıho profilu s v´ yjimkou poskytovatele autorizace a definice role. Pˇri editaci profilu mus´ı z˚ ustat unikátn´ı pˇrihlaˇsovac´ı jméno uˇzivatele.

Diagram uˇzit´ı 4.3: Správa uˇzivatel˚ u.

4.3.4

Spr´ ava tˇ r´ıd objekt˚ u

Administr´ ator bude moci pˇrid´ avat, editovat a mazat tˇr´ıdy objekt˚ u (Diagram 4.4). Tˇr´ıda objekt˚ u se skl´ ad´ a z n´ azvu tˇr´ıdy a popisné informace. Název tˇr´ıdy je povinná poloˇzka. Tˇr´ıda bude definovat, zda bude nutné potvrzovat vyzvednut´ı nebo vracen´ı

40



vˇsech objekt˚ u, které budou pˇriˇrazeny do této tˇr´ıdy. Pˇri odstranˇen´ı tˇr´ıdy objekt˚ u mus´ı b´ yt automaticky vymaz´ any i vˇsechny objekty této tˇr´ıdy.

Diagram uˇzit´ı 4.4: Správa tˇr´ıd objekt˚ u.

4.3.5

Spr´ ava objekt˚ u

Administr´ ator bude moci pˇrid´ avat, editovat a mazat objekty (Diagram 4.5). Objekt je definov´ an n´ azvem, popisem a unikátn´ım textov´ ym identifikátorem. Identifikátor nebude moˇzné po vloˇzen´ı objektu do systému v rámci editace mˇenit. Pˇri odstranˇen´ı objektu ze systému mus´ı b´ yt vymazány i vˇsechny s objektem souvisej´ıc´ı rezervace.

Diagram uˇzit´ı 4.5: Správa objekt˚ u.

41



Vˇsechny objekty bude moˇzné zobrazit v tabulce a tuto tabulku bude moˇzné filtrovat na z´ akladˇe textového vyhledáván´ı nebo tˇr´ıd objekt˚ u (Obrázek 4.2). Obj ekty T ída obj ekt : Notebooky Název:

HP 656*

Název

Popis

Akce

HP 6560b

notebook

Editovat

Smazat ...

...

...

...

...

Obrázek 4.2: Základn´ı rozvrˇzen´ı správy objekt˚ u.

Export identifik´ atoru do QR k´ odu Administr´ ator˚ um a Spr´ avc˚ um rezervac´ı bude umoˇznˇen export identifikátoru objektu do podoby QR k´ odu. V´ ystupn´ı formát bude PDF dokument se tˇremi stejn´ ymi QR k´ ody o r˚ uzn´ ych rozmˇerech, textovou reprezentac´ı identifikátoru objektu a názvem objektu.

4.3.6

Spr´ ava obl´ıben´ ych objekt˚ u

Vˇsem rol´ım bude umoˇznˇeno udrˇzovat si sv˚ uj seznam objekt˚ u, se kter´ ymi ˇcasto manipuluj´ı. Do tohoto seznamu bude moˇzné jeho vlastn´ıky libovolnˇe pˇridávat objekty, nebo je n´ aslednˇe odeb´ırat (Diagram 4.6). Seznam tˇechto objekt˚ u bude pˇr´ıstupn´ y z hlavn´ıho menu webového rozhran´ı.

4.3.7

Vytv´ aˇ ren´ı rezervac´ı

Vˇsem rol´ım bude umoˇznˇeno vytváˇret vlastn´ı rezervace. Správc˚ um rezervac´ı a Administr´ ator˚ um bude nav´ıc umoˇznˇeno vytváˇret rezervace za jiné uˇzivatele (Diagram 4.7). Rezervace je definov´ ana poˇc´ ateˇcn´ım a koncov´ ym term´ınem rezervace a objektem, ke kterému se rezervace vztahuje. Poˇcáteˇcn´ı ani koncov´ y term´ın nesm´ı leˇzet v minulosti (vztaˇzeno k ˇcasu vytvoˇren´ı rezervace). Pokud uˇzivatel zadá poˇcáteˇcn´ı term´ın leˇz´ıc´ı v minulosti, systém mus´ı pˇri vytváˇren´ı rezervace zajistit posunut´ı

42



Diagram uˇzit´ı 4.6: Správa obl´ıben´ ych objekt˚ u. poˇcátku rezervace do pˇr´ıtomnosti. Systém mus´ı odm´ıtnout vytvoˇren´ı rezervace, kde je koncov´ y term´ın um´ıstˇen v ˇcase pˇred poˇcáteˇcn´ım term´ınem. Rezervace objektu m˚ uˇze b´ yt vytvoˇrena pouze v pˇr´ıpadˇe, pokud neexistuje jiná platná rezervace na tento objekt ve stejném ˇcasovém rámci nebo rámci, kter´ y se s u ´sekem nové rezervace ˇc´ asteˇcnˇe pˇrekr´ yv´ a.

Diagram uˇzit´ı 4.7: Vytváˇren´ı rezervac´ı. Na centr´ aln´ım serveru bude umoˇznˇena konfigurace minimáln´ı a maximáln´ı pˇr´ıpustné délky rezervace. Pokud uˇzivatel zadá pˇri vytváˇren´ı rezervace kratˇs´ı ˇcasov´ y

43



u ´sek neˇz je minim´ aln´ı pˇr´ıpustn´ a délka rezervace, systém mus´ı rezervaci prodlouˇzit na tuto minim´ aln´ı délku. Pokud uˇzivatel zadá ˇcasov´ yu ´sek delˇs´ı neˇz je maximáln´ı délka rezerace, systém mus´ı vytvoˇren´ı takové rezervace odm´ıtnout.

Periodick´ e rezervace Rezervace objekt˚ u bude moˇzné po pevnˇe daném ˇcasovém u ´seku opakovat. Tento u ´sek je s ohledem na potˇreby katedry stanoven na jeden t´ yden. Pˇri vytváˇren´ı rezervace bude moˇzné zadat poˇcet t´ ydn˚ u, po kter´ y bude rezervace opakována (Obrázek 4.3). Term´ın prvn´ı rezervace je ˇcas poˇcátku rezervace, kter´ y uˇzivatel zadal do formul´ aˇre pro vytvoˇren´ı rezervace.

Rezervovat Notebook HP 6560b Od

Vysouvací kalendá

12:00

Do

Vysouvací kalendá

13:00

Periodická Po et týdn

5

Rezervovat

Obrázek 4.3: Rozvrˇzen´ı vytvoˇren´ı periodické rezervace. Maxim´ aln´ı poˇcet opakov´ an´ı rezervace bude konfigurovateln´ y na centráln´ım serveru a systém nesm´ı umoˇznit pˇrekroˇcen´ı tohoto limitu. Délka ˇcasového u ´seku rezervace nesm´ı pˇrekroˇcit délku jednoho t´ ydne.

4.3.8

Spr´ ava rezervac´ı

Vˇsem rol´ım bude umoˇznˇeno editovat a mazat vlastn´ı rezervace. Správc˚ um rezervac´ı a Administr´ ator˚ um bude nav´ıc umoˇznˇeno editovat a mazat rezervace jin´ ych uˇzivatel˚ u, nebo mˇenit uˇzivatele rezervac´ı (Diagram 4.8). Editovat bude moˇzné ˇcas vyzvednut´ı a ˇcas vrácen´ı. Pro editaci tˇechto term´ın˚ u budou platit stejn´ a pravidla jako pro vytváˇren´ı nové rezervace. Editovat rezervace leˇz´ıc´ı v minulosti (oproti ˇcasu editace) nebude moˇzné.

44



Diagram uˇzit´ı 4.8: Editace rezervac´ı. Platnost rezervac´ı Dalˇs´ı editovatelnou vlastnost´ı rezervac´ı bude tzv. platnost rezervace“. Kaˇzdá nové ” vytvoˇren´ a rezervace bude automaticky vedena jako platná. Uˇzivat˚ um bude umoˇznˇeno zneplatnit rezervaci v r´ amci jej´ı editace. Systém bude interpretovat neplatné rezervace tak, jako by v daném ˇcasovém u ´seku ˇzádná rezervace nevznikla (bude tedy moˇzné v tomto u ´seku vytv´ aˇret jiné rezervace). Neplatná rezervace bude vˇsak stále pro uˇzivatele viditeln´ a a bude moˇzné j´ı opˇet uˇcinit platnou za podm´ınky, ˇze v jejich ˇcasovém u ´seku v okamˇziku editace neexistuje jiná platná rezervace na stejn´ y objekt.

Editace periodick´ ych rezervac´ı Pˇri editaci periodick´ ych rezervac´ı mus´ı b´ yt zachován konstantn´ı pr˚ ubˇeh rezervace. Pokud tedy dojde ke zmˇenˇe term´ınu rezervace, tato zmˇena se mus´ı prom´ıtnout do vˇsech t´ ydenn´ıch u ´sek˚ u rezervace s v´ yjimkou tˇech u ´sek˚ u, které leˇz´ı v minulosti oproti ˇcasu editace. Bude moˇzné zneplatˇ novat jednotlivé u ´seky periodické rezervace, aniˇz by ostatn´ı u ´seky byly touto editac´ı jakkoliv zasaˇzeny. Pokud dojde k odstranˇen´ı periodické rezervace, budou odstranˇeny i vˇsechny jej´ı ˇcasové u ´seky.

45


4.3.9


Vyzved´ av´ an´ı rezervac´ı

Vˇsem rol´ım bude umoˇznˇeno vyzvedávat vlastn´ı rezervace. Administráto˚ um a Správc˚ um rezervac´ı bude umoˇznˇeno vyzvedávat rezervace za jiné uˇzivatele (Diagram 4.9). Vyzvednut´ı rezervace bude systémem povoleno pouze tehdy, pokud objekt svázan´ y s rezervac´ı n´ aleˇz´ı tˇr´ıdˇe, kter´ a vynucuje potvrzen´ı vyzvednut´ı sv´ ych objekt˚ u. Dále mus´ı b´ yt splnˇeny n´ asleduj´ıc´ı podm´ınky: - rezervace mus´ı b´ yt nevyzvednutá. - rezervace mus´ı b´ yt platn´ a. - pokud ˇcas poˇc´ atku rezervace leˇz´ı v budoucnosti oproti ˇcasu pokusu o vyzvednut´ı rezervace, mus´ı b´ yt jejich rozd´ıl menˇs´ı neˇz minimáln´ı délka rezervace objektu. - pokud ˇcas poˇc´ atku rezervace leˇz´ı v minulosti oproti ˇcasu pokusu o vyzvednut´ı rezervace, nesm´ı ˇcas vr´ acen´ı objektu leˇzet v minulosti (nelze vyzvednout rezervace, jejichˇz ˇcasov´ yu ´sek jiˇz skonˇcil).

Diagram uˇzit´ı 4.9: Vyzvedáván´ı a vracen´ı rezervac´ı.

4.3.10

Vracen´ı rezervac´ı

Vˇsem rol´ım bude umoˇznˇeno vracet vlastn´ı rezervace. Administrátor˚ um a Správc˚ um rezervac´ı bude umoˇznˇeno vracet rezervace za jiné uˇzivatele (Diagram 4.9). Vrácen´ı rezervace bude systémem povoleno pouze tehdy, pokud objekt svázan´ y s rezervac´ı náleˇz´ı tˇr´ıdˇe, kter´ a vynucuje potvrzen´ı vracen´ı sv´ ych objekt˚ u. Dále mus´ı b´ yt splnˇeny následuj´ıc´ı podm´ınky:

46



- pokud rezervovan´ y objekt náleˇz´ı tˇr´ıdˇe vynucuj´ıc´ı vyzvednut´ı, rezervace mus´ı b´ yt vyzvednut´ a. - rezervace mus´ı b´ yt platn´ a. Pokud ˇcas konce rezervace leˇz´ı v budoucnosti oproti ˇcasu vrácen´ı rezervace, mus´ı systém zmˇenit ˇcas konce rezervace na tento ˇcas vrácen´ı.

4.3.11

Expirace rezervace

Pokud rezervace vyˇzaduje potvrzen´ı vyzvednut´ı a majitel rezervace nevyzvedne rezervaci pˇred ˇcasem zaˇc´ atku této rezervace, systém umoˇzn´ı vytvoˇren´ı jiné platné rezervace ve stejném ˇcasovém u ´seku nebo zmˇenu ˇcasového rámce jiné rezervace do rámce p˚ uvodn´ı nevyzvednuté rezervace za pˇredpokladu, ˇze od ˇcasu zaˇcátku doby rezervace ubˇehla doba expirace rezervace. Doba expirace bude konfigurovatelná na centráln´ım serveru. Pokud dojde k pˇrekroˇcen´ı doby expirace a je vytvoˇrena nebo pˇresunuta jiná rezervace do stejného ˇcasového r´ amce, mus´ı systém zajistit zneplatnˇen´ı p˚ uvodn´ı vyexpirované rezervace.

4.3.12

Kalend´ aˇ r

Rezervace budou organizov´ any do kalendáˇre rezervac´ı. Kalendáˇr rezervac´ı bude moˇzné zobrazit jak pro objekty tak pro kaˇzdého uˇzivatele. Editac´ı kalendáˇre se rozum´ı jak´ akoliv editace rezervac´ı zobrazen´ ych v kalendáˇri. Tato editace podléhá dˇr´ıve popsan´ ym pravidl˚ um pro editaci rezervace.

Kalend´ aˇ r uˇ zivatele Vˇsem rol´ım bude umoˇznˇeno zobrazit a editovat sv˚ uj kalendáˇr a zobrazit kalendáˇr ostatn´ıch uˇzivatel˚ u. Spr´ avci rezervac´ı a Administrátoˇri systému budou moci editovat kalend´ aˇre jin´ ych uˇzivatel˚ u (Diagram 4.10). Na kalendáˇr aktuálnˇe pˇrihláˇseného uˇzivatele bude moˇzné se dostat pˇr´ımo z hlavn´ıho menu. Jak je naznaˇceno na Obr. 4.4, jednotlivé rezervace se budou od sebe barevnˇe odliˇsovat v z´ avislosti na aktu´ aln´ım stavu rezervace. Schéma bude následuj´ıc´ı: - ˇ zlutˇ e budou vybarveny vˇsechny validn´ı rezervace, jejichˇz ˇcasov´ y u ´sek leˇz´ı

47



Diagram uˇzit´ı 4.10: Kalendáˇr uˇzivatele. v budoucnosti a nevyˇzaduj´ı vyzvednut´ı, nebo prob´ıhaj´ı v aktuáln´ım ˇcase a nevyˇzaduj´ı vr´ acen´ı (rezervace, které jsou aktivn´ı a nevyˇzaduj´ı ˇzádnou akci). - modˇ re budou oznaˇceny validn´ı rezervace, jejichˇz ˇcasov´ yu ´sek leˇz´ı v budoucnosti a vyˇzaduj´ı vyzvednut´ı (aktivn´ı rezervace, které vyˇzaduj´ı akci). - jako zelen´ e budou oznaˇceny rezervace, které byly vyzvednuty, vyˇzaduj´ı vrácen´ı a jejich koncov´ y ˇcas leˇz´ı v budoucnosti (právˇe prob´ıhaj´ıc´ı rezervace, které budou v budoucnu vyˇzadovat akci vrácen´ı). - ˇ cervenˇ e budou zn´ azornˇeny rezervace, které vyˇzaduj´ı vyzvednut´ı a nebyly uˇzivatelem vˇcas vyzvednuty, nebo vyˇzaduj´ı vrácen´ı a nebyly uˇzivatelem vˇcas vr´ aceny. - ˇ sed´ e rezervace jsou neplatné rezervace, nebo rezervace které byly u ´spˇeˇsnˇe vr´ aceny nebo nevyˇzaduj´ı potvrzen´ı vrácen´ı a jejich ˇcasov´ yu ´sek leˇz´ı v minulosti (neaktivn´ı rezervace, jiˇz nevyˇzaduj´ı ˇzádnou dalˇs´ı akci). Krátké popisky popisuj´ıc´ı aktu´ aln´ı stav rezervace budou zobrazeny i pˇri zobrazen´ı profilu rezervace. Ten by mˇelo b´ yt moˇzné zobrazit pˇr´ımo z kalendáˇre.

48


Po

Út

St


Čt

Pá

So

Ne

8:00 8:30 9:00

9:00 11:00 Notebook Dell

9:30 10:00

10:0011:00 Notebook HP6560b

10:30 11:00 11:30 12:00 12:30

12:00 14:30 HP6560b

11:30 13:00 Místnost UP130

13:00

Obrázek 4.4: Rozvrˇzen´ı kalendáˇre uˇzivatele. Kalend´ aˇ r objektu Kalend´ aˇr objektu bude m´ıt obdobné rozvrˇzen´ı jako kalendáˇr uˇzivatele. Vˇsem rol´ım bude umoˇznˇeno pˇrid´ avat a editovat své rezervace. Správci rezervac´ı a Administrátoˇri systému budou v kalend´ aˇri moci editovat rezervace vˇsech uˇzivatel˚ u nebo za nˇe jejich rezervace pˇrid´ avat a mazat. Barevné rozliˇsen´ı bude jiné neˇz v pˇr´ıpadˇe kalendáˇre uˇzivatele. Zelen´ e rezervace budou patˇrit uˇzivateli, kter´ y prohl´ıˇz´ı kalendáˇr objektu. Vˇsechny ostatn´ı rezervace budou ˇ sed´ e.

Export kalend´ aˇ re Kalend´ aˇr kaˇzdého uˇzivatele nebo objektu bude moˇzné exportovat do formátu iCal. To bude moˇzné bud’ jednor´ azovˇe exportem do textového souboru, nebo pomoc´ı veˇrejnˇe dostupné URL unik´ atn´ı pro kaˇzdého uˇzivatele a objekt. Tyto URL budou zobrazeny v profilech uˇzivatel˚ u a objekt˚ u.

49


4.4

Funkce klientské aplikace

Funkce klientsk´ e aplikace

Klientsk´ a aplikace narozd´ıl od webového rozhran´ı nenab´ıdne ˇzádné moˇznosti administrace uˇzivatel˚ u, rezervac´ı, objekt˚ u nebo tˇr´ıd objekt˚ u. Vˇsechny pˇr´ıpady uˇzit´ı systému dosud definované pro role Správce rezervac´ı a Administrátor nebudou v mobiln´ı aplikaci dostupné. Tyto dvˇe role se tedy pˇripojuj´ı k systému pˇres mobiln´ı aplikaci v roli Uˇzivatele. Pˇribliˇzné rozvrˇzen´ı jednotliv´ ych obrazovek a diagram pr˚ uchodu mobiln´ı aplikac´ı jsou uvedeny v Pˇr´ıloze A.

4.4.1

Hlavn´ı obrazovka

Po startu aplikace a u ´spˇeˇsném pˇrihláˇsen´ı k serveru bude zobrazena hlavn´ı obrazovka s navigaˇcn´ımi tlaˇc´ıtky na obrazovky (Obr. A.2) obsahuj´ıc´ı základn´ı funkce aplikace: - M˚ uj kalend´ aˇr – zobrazen´ı kalendáˇre uˇzivatele. - Obl´ıbené – seznam obl´ıben´ ych objekt˚ u. - Vyzvedni – funkce pro vyzvednut´ı rezervace. - Vrat’ – funkce pro vr´ acen´ı rezervace. - Prohl´ıˇzet – prohl´ıˇzeˇc objekt˚ u. - Nastaven´ı – glob´ aln´ı nastaven´ı pˇripojovac´ıch direktiv. Na rozd´ıl od webového rozhran´ı bude mobiln´ı aplikace koncipována pro pˇreváˇzné pouˇz´ıv´ an´ı jedn´ım uˇzivatelem. Zadán´ı jména a hesla pˇri kaˇzdém startu aplikace nesm´ı b´ yt vyˇzadov´ ano.

4.4.2

Nastaven´ı

Aplikace bude obsahovat obrazovku s globáln´ım nastaven´ım pˇripojen´ı k centráln´ımu serveru, jehoˇz souˇc´ ast´ı budou i poloˇzky pro jméno a heslo uˇzivatele. Aplikace bude rozpozn´ avat zmˇeny nastaven´ı a po jejich uloˇzen´ı se pokus´ı pˇripojit na server. V pˇr´ıpadˇe ne´ uspˇeˇsného pˇripojen´ı o tom mus´ı notifikovat uˇzivatele a souˇcasnˇe zak´ azat navigaci na vˇsechny obrazovky aplikace s v´ yjimkou nastaven´ı pˇripojen´ı.

50


4.4.3


Obl´ıben´ e poloˇ zky

Aplikace poskytne obrazovku se zobrazen´ım vˇsech obl´ıben´ ych objekt˚ u uˇzivatele, obdobnˇe jako na webovém rozhran´ı. Po vybrán´ı jednoho z objekt˚ u dojde k automatickému pˇrepnut´ı na profil objektu.

4.4.4

Profil objektu

Na obrazovce s profilem objektu se budou zobrazovat vˇsechny informace vztaˇzené k objektu – jméno, identifik´ ator a popis objektu, název tˇr´ıdy objektu a informace, zdali je vyˇzadov´ ano vyzvednut´ı a vracen´ı objektu. Dále budou dostupné následuj´ıc´ı akce: - Pˇridat do obl´ıbených – zobrazeno v pˇr´ıpadˇe, pokud objekt nebude v seznamu obl´ıben´ ych objekt˚ u. - Odebrat z obl´ıbených – zobrazeno, pokud objekt v tomto seznamu bude pˇr´ıtomen. - Kalend´ aˇr objektu – navigaˇcn´ı tlaˇc´ıtko na kalendáˇr objektu. - Vyzvedni – funkce pro vyzvednut´ı objektu (viz dále).

4.4.5

Prohl´ıˇ zeˇ c objekt˚ u

Aplikace poskytne obrazovku se zobrazen´ım seznamu objekt˚ u. Bude moˇzné zobrazit objekty vˇsechny obl´ıbené poloˇzky pˇrihláˇseného uˇzivatele a objekty vyhledané podle textového vstupu od uˇzivatele nebo podle vyfotografovaného QR kódu (Obr. A.5). Po vybr´ an´ı jednoho z objekt˚ u ze seznamu bude uˇzivatel automaticky pˇresmˇerov´ an na obrazovku s profilem objektu.

Vyhled´ av´ an´ı objekt˚ u Vyhled´ av´ an´ı objekt˚ u bude moˇzné na základˇe jména objektu, popisu objektu, jména tˇr´ıdy nebo vˇsech tˇechto kritéri´ı najednou. Pokud bude nˇekter´ y objekt vyhovovat v´ıce kritéri´ım, mus´ı se v seznamu objevit pouze jednou. Pokud uˇzivatel zvol´ı vyhled´ aván´ı podle QR kódu, aplikace automaticky aktivuje fotoapar´ at zaˇr´ızen´ı a spust´ı detekci QR kódu. Po u ´spˇeˇsném rozpoznán´ı se zobraz´ı objekt, kter´ y odpov´ıd´ a vyfotografovanému identifikátoru.

51


4.4.6


Kalend´ aˇ r

Aplikace bude zobrazovat obdobn´ y formát kalendáˇre jako v pˇr´ıpadˇe webového rozhran´ı. Pˇrihl´ aˇsenému uˇzivateli bude pˇr´ımo z hlavn´ı obrazovky dostupn´ y jeho osobn´ı kalend´ aˇr rezervac´ı.

Rozvrˇ zen´ı kalend´ aˇ re Rozvrˇzen´ı kalend´ aˇre mus´ı b´ yt optimalizováno pro zobrazen´ı na mal´ ych displej´ıch a mus´ı maxim´ alnˇe vyuˇz´ıvat dotykového ovládán´ı. Kalend´ aˇr bude reprezentov´ an dvˇema obrazovkami. Nejprve pˇrijde uˇzivatel do styku s mˇes´ıˇcn´ım kalend´ aˇrem (Obr. A.4). Ten mus´ı umoˇzn ˇovat pˇrechod mezi jednotliv´ ymi mˇes´ıci a zobrazovat poˇcet rezervac´ı na kaˇzd´ y den v mˇes´ıci (v pˇr´ıpadˇe, kdy nebude existovat ˇz´ adn´ a rezervace, nebude tato informace zobrazena). Aktuáln´ı den bude zv´ yraznˇen. Pˇri rozkliku dne v mˇes´ıˇcn´ım kalendáˇri se zobraz´ı posunovateln´ y denn´ı kalendáˇr s jednotliv´ ymi rezervacemi (Obr. A.3). Vizualizace a barevná schémata rezervac´ı budou shodn´ a s webov´ ym rozhran´ım. Kalendáˇr mus´ı podporovat stejné operace s rezervacemi, jaké jsou dostupné pro roli Uˇzivatele ve webovém rozhran´ı systému.

Kalend´ aˇ r objektu Aplikace také umoˇzn´ı vizualizaci kalendáˇre objektu, opˇet se shodn´ ym barevn´ ym schématem a moˇzn´ ymi akcemi a restrikcemi definovan´ ymi pro roli Uˇzivatele v rámci webového rozhran´ı systému. Bude tedy moˇzné vytváˇret a mˇenit vlastn´ı rezervace a prohl´ıˇzet rezervace jin´ ych uˇzivatel˚ u. Tento kalendáˇr bude dostupn´ y z profilu kaˇzdého objektu.

4.4.7

Spr´ ava rezervac´ı

Obrazovky pro vytv´ aˇren´ı a editaci rezervac´ı budou dostupné z kalendáˇre uˇzivatele i objektu a nab´ıdnou stejnou sadu poloˇzek a stejnou funkcionalitu jako je definována pro webové rozhran´ı (Obr. A.6). V obou obrazovkách bude maximálnˇe vyuˇzito prostˇredk˚ u dotykového displeje a grafick´ ych uˇzivatelsk´ ych komponent. Na editaˇcn´ı obrazovce bude nab´ıdnuta moˇznost rezervaci u ´plnˇe smazat ze systému. Dále bude v pˇr´ıpadˇe editace periodické rezervace nab´ıdnuta moˇznost mˇenit platnost vˇsech ˇcasov´ ych u ´sek˚ u rezervace, aniˇz by je bylo nutné dohledávat v kalendáˇri. Zmˇena

52



platnosti ˇcasového u ´seku rezervace bude realizována jako v´ ybˇer ze seznamu vˇsech ˇcasov´ ych u ´sek˚ u rezervace. Jakékoliv zmˇeny uskuteˇcnˇené v rámci správy rezervac´ı se mus´ı okamˇzitˇe po u ´spˇeˇsném odesl´ an´ı prom´ıtnout do vˇsech dotˇcen´ ych kalendáˇr˚ u. V pˇr´ıpadˇe, ˇze nebude moˇzné zmˇenit rezervaci z d˚ uvodu blokace této zmˇeny jinou rezervac´ı, je nutné zobrazit zpr´ avu se jménem majitele této blokuj´ıc´ı rezervace.

4.4.8

Funkce Vyzvedni“ ”

Tato funkce bude zajiˇst’ovat vyzvedáván´ı objekt˚ u na základˇe existuj´ıc´ıch rezervac´ı nebo pˇr´ıpadné vytv´ aˇren´ı nov´ ych rezervac´ı. Navigaˇcn´ı tlaˇc´ıtka zpˇr´ıstupˇ nuj´ıc´ı tuto funkci budou dostupn´ a pˇr´ımo z hlavn´ı obrazovky a z obrazovky profilu objektu. V pˇr´ıpadˇe, ˇze uˇzivatel zvol´ı pˇr´ıstup z hlavn´ı obrazovky aplikace, mus´ı b´ yt nejprve zajiˇstˇena selekce objektu urˇcenému k vyzvednut´ı. Pˇr´ıstup bude obdobn´ y jako v pˇr´ıpadˇe prohl´ıˇzen´ı objekt˚ u – bude moˇzné vybrat objekt ze seznamu obl´ıben´ ych objekt˚ u, ze seznamu objekt˚ u vyhledan´ ych podle urˇcit´ ych kritéri´ı nebo bude moˇzné objekt identifikovat skenov´ an´ım QR kódu. V pˇr´ıpadˇe pˇr´ıstupu z profilu objektu je tento identifikov´ an samotn´ ym profilem. Tato funkce nebude dostupná pro objekty, které nevyˇzaduj´ı potvrzen´ı pˇri vyzvednut´ı. Po identifikaci objektu mus´ı systém vyhledat rezervaci vytvoˇrenou na tento objekt a splˇ nuj´ıc´ı podm´ınky vyzvednutelnosti uvedené v poˇzadavc´ıch na webové rozhran´ı.V pˇr´ıpadˇe nalezen´ı takové rezervace systém zajist´ı jej´ı vyzvednut´ı a informuje o tom uˇzivatele. Pokud taková rezervace nen´ı nalezena, bude umoˇznˇeno vytvoˇren´ı rezervace nové, jej´ıˇz poˇcátek bude v aktuáln´ım ˇcase vyzvednut´ı. Koncov´ y ˇcas bude zvolen uˇzivatelem. Rezervace bude automaticky oznaˇcena jako neperiodická, validn´ı a vyzvednut´ a. Pro vytvoˇren´ı této rezervace budou platit stejné podm´ınky jako pro vytv´ aˇren´ı vˇsech ostatn´ıch rezervac´ı (minimáln´ı a maximáln´ı délka atp.) a v pˇr´ıpadˇe nesplnˇen´ı tˇechto podm´ınek o tom mus´ı b´ yt uˇzivatel informován.

4.4.9

Funkce Vrat’“ ”

Tato funkce bude zajiˇst’ovat vracen´ı objekt˚ u na základˇe existuj´ıc´ıch nevrácen´ ych rezervac´ı. Bude dostupn´ a z hlavn´ı obrazovky aplikace. Uˇzivateli se bude zobrazovat seznam vˇsech nevrácen´ ych rezervac´ı, a to jak aktuálnˇe bˇeˇz´ıc´ıch, tak rezervac´ı nevrácen´ ych v minulosti. Nebudou se zobrazovat rezervace, které potvrzen´ı vr´ acen´ı nevyˇzaduj´ı. Po vybrán´ı jedné z rezervac´ı dojde k jej´ımu vr´ acen´ı a n´ avratu na hlavn´ı obrazovku aplikace.

53


4.5 4.5.1

Mimofunkˇcn´ı poˇzadavky

Mimofunkˇ cn´ı poˇ zadavky Komunikace se serverem

Komunikace s centr´ aln´ım serverem bude zabezpeˇcena HTTPS certifikátem. Bude ˇzádouc´ı, aby autorizace uˇzivatel˚ u mobiln´ıch aplikac´ı a s t´ım souvisej´ıc´ı pˇrenos citliv´ ych u ´daj˚ u prob´ıhal co moˇzn´ a nejménˇe. Jakékoliv chyby komunikace mezi mobiln´ı aplikac´ı a serverem se mus´ı zobrazit uˇzivateli. Rychlost a odezvy komunikace mus´ı korespondovat s pohodln´ ym pouˇz´ıván´ım mobiln´ı aplikace a webového rozhran´ı (maxim´ alnˇe jednotky vteˇrin).

4.5.2

Poˇ zadavky na mobiln´ı aplikaci

Vˇsechny obrazovky bude moˇzné rotovat podle uˇzivatelsk´ ych preferenc´ı. V pˇr´ıpadˇe pˇrekryt´ı jinou aplikac´ı mus´ı obrazovky korektnˇe obnovit sv˚ uj stav i za cenu opakovaného staˇzen´ı dat z centr´ aln´ıho serveru. Aplikace mus´ı b´ yt maximálnˇe ovladatelná pomoc´ı dotykového displeje a vyuˇz´ıvat komponent grafického uˇzivatelského rozhran´ı, které jsou jiˇz zabudov´ any v systému. Nevyˇzaduje se pˇrenositelnost aplikace z Androidu na jiné mobiln´ı platformy.

4.5.3

Poˇ zadavky na v´ ykon syst´ emu

Na centr´ aln´ım serveru mus´ı b´ yt moˇzné uloˇzit ˇrádovˇe des´ıtky uˇzivatel˚ u a objekt˚ u bez ztr´ aty rychlosti pˇr´ıstupu. Server mus´ı zvládnout nar˚ ustaj´ıc´ı poˇcet rezervac´ı v ˇcase bez znatelné ztr´ aty v´ ykonu. Systém mus´ı bez problém˚ u obslouˇzit souˇcasné pˇrihláˇsen´ı jednotek aˇz des´ıtek uˇzivatel˚ u.

54

5 Moˇznosti návrhu webových aplikac´ı V této kapitole budou rozebr´ any moˇznosti návrhu a implementace dˇr´ıve specifikovaného systému pro spr´ avu rezervac´ı a uvedeny nˇekteré vyuˇzitelné technologie ˇ aˇr se seznám´ı s obecn´ zaloˇzené na platformˇe Java. Cten´ ymi architektonick´ ymi principy uplatniteln´ ymi pˇri vytv´ aˇren´ı informaˇcn´ıch systém˚ u a distribuovan´ ych webov´ ych aplikac´ı.

5.1

V´ıcevrstv´ a architektura

V´ıcevrstv´ a architektura je architektonick´ y vzor, ve kterém se model aplikace skládá z v´ıce vz´ ajemnˇe spolupracuj´ıc´ıch vrstev. Soused´ıc´ı vrstvy komunikuj´ı pˇres pˇredem definovan´ a rozhran´ı a d´ıky tomu mohou b´ yt zamˇen ˇovány, aniˇz by to mˇelo dopad na funkˇcnost celé aplikace nebo bylo nutné mˇenit ostatn´ı vrstvy. Pˇrenos dat a definov´ an´ı vz´ ajemného rozhran´ı mezi vrstvami je souˇcást´ı návrhu v´ıcevrstvé architektury. Pravdˇepodobnˇe nejzn´ amˇejˇs´ım zástupcem uplatnˇen´ı v´ıcevrstvé architektury je referenˇcn´ı OSI (Open Systems Interconnection) model. Jeho p˚ uvodn´ım u ´ˇcelem byla snaha o standardizaci komunikace uvnitˇr poˇc´ıtaˇcov´ ych s´ıt´ı [18], dnes se vˇsak pouˇz´ıvaj´ı jeho jednoduˇsˇs´ı odvozeniny (napˇr. protokol TCP/IP) a p˚ uvodn´ı model má sp´ıˇse metodick´ y v´ yznam. Je vˇsak pˇr´ıkladem, ˇze v´ıcevrstvá architektura se nemus´ı omezovat pouze na ˇcistˇe softwarovou implementaci. Model se skl´ ad´ a ze sedmi vrstev. Nejvyˇsˇs´ı vrstva v modelu zajiˇst’uje pˇr´ıstup aplikac´ı k s´ıt’ovému komunikaˇcn´ımu systému. Pokud klientská aplikace vytvoˇr´ı poˇzadavek na pˇr´ıstup do s´ıtˇe, je tento pˇredáván sestupnˇe v zásobn´ıku vstev aˇz do vrstvy nejniˇzˇs´ı, kter´ a zajiˇst’uje pˇr´ım´ y pˇr´ıstup k fyzickému médiu. Kaˇzdá vrstva má pˇresnˇe vymezenou sadu u ´kol˚ u jako je ˇsifrován´ı, navazován´ı spojen´ı, synchronizace, smˇerov´ an´ı atp. a m´ a jednoznaˇcnˇe definováno rozhran´ı mezi sousedn´ımi vrstvami v zásobn´ıku. Na tom lze n´ azornˇe demonstrovat v´ yhody v´ıcerstv´ ych architektur. D´ıky tomu, ˇze se kaˇzd´ a vrstva omezuje na pˇredem definovanou sadu u ´kol˚ u a kaˇzdá pracuje s jinou u ´rovn´ı abstrakce, zb´ yv´ a jen mal´ y krok k vytvoˇren´ı standardizovan´ ych protokol˚ u pro kaˇzdou vrstvu. Jednotlivé implementace tˇechto protokol˚ u bude poté moˇzné libovolnˇe vymˇen ˇovat bez ovlivnˇen´ı funkcionality ostatn´ıch vrstev. Pokud se ukáˇze, ˇze souˇcasn´ a implementace je jiˇz pˇr´ıliˇs sloˇzitá, je moˇzné vrstvy dále dˇelit.

55

Moˇznosti návrhu webových aplikac´ı

V´ıcevrstvá architektura

Tyto lze dokonce i sluˇcovat, jak se také stalo ve v´ yˇse zm´ınˇené od OSI modelu odvozené architektuˇre TCP/IP, která vyuˇz´ıvá pouze ˇctyˇr vrstev.

5.1.1

Z´ asady pro n´ avrh v´ıcevrstv´ eho modelu

Architekt aplikace by mˇel navrhnout novou vrstvu vˇsude tam, kde je zapotˇreb´ı jin´ y stupeˇ n abstrakce. Kaˇzd´ a vrstva by mˇela zajiˇst’ovat pˇresnˇe vymezené funkce zvolené tak, aby pro jejich realizaci mohly b´ yt vytvoˇreny standardizovaná rozhran´ı nebo protokoly. Poˇcet vrstev by mˇel b´ yt tak velk´ y, aby vzájemnˇe odliˇsné funkce nemusely b´ yt zaˇrazov´ any do stejné vrstvy, a souˇcasnˇe s t´ım tak mal´ y, aby celá architektura z˚ ustala dostateˇcnˇe pˇrehledná. Moˇzné budouc´ı komplexn´ı pˇrepracován´ı vrstvy nesm´ı z´ asadnˇe ovlivnit sousedn´ı vrstvy. Rozhran´ı mezi vrstvami by mˇela b´ yt zvolena tak, aby byl minimalizován tok dat.

5.1.2

Tˇ r´ıvrstv´ a architektura

Tˇr´ıvrstv´ a architektura je obecn´ y typ v´ıcevrstvé architektury. Je s oblibou vyuˇz´ıvána v kombinaci s modelem distribuované aplikace klient-server. Rozdˇeluje aplikaci do tˇr´ı separ´ atn´ıch logick´ ych vrstev, které nemus´ı nutnˇe bˇeˇzet na stejn´ ych zaˇr´ızen´ıch nebo operaˇcn´ıch systémech. Rozdˇelen´ı architektury je zjednoduˇsenˇe znázornˇeno na Obr. 5.1.

Obrázek 5.1: Základn´ı schéma tˇr´ıvrstvé aplikace. Prezentaˇcn´ı vrstva zajiˇstuje vizualizaci dat pro uˇzivatele a interakci s uˇzivatelem [20]. Aplikaˇcn´ı (doménov´ a) vrstva obsahuje samotné jádro aplikace, funkce pro v´ ypoˇcty nebo zpracov´ an´ı dat. Datová vrstva se poté stará o persistenci dat. Je nutné zm´ınit, ˇze v ˇcistˇe tˇr´ıvrstvé architektuˇre se tok dat dˇeje vˇzdy jen mezi soused´ıc´ımi vrstvami, tzn. pˇri pˇr´ıstupu z prezentaˇcn´ı vrstvy nem˚ uˇze b´ yt prostˇredn´ı vrstva ´ pˇrekroˇcena a opaˇcnˇe. Ukolem tˇr´ıvrstvé architektury nen´ı definován´ı rozhran´ı mezi

56


V´ıcevrstvá architektura

vrstvami nebo technologického z´ akladu pro tˇr´ıvrstvé aplikace, klade si za c´ıl pouze rozvrˇzen´ı logického modelu aplikace. Na Obr´ azku 5.2 je zn´ azornˇeno typické rozvrˇzen´ı tˇr´ıvrstvé aplikace. Datová vrstva je zde reprezentov´ ana relaˇcn´ı databáz´ı na vzdáleném serveru. K této databázi se pˇripojuje aplikaˇcn´ı server, zajiˇst’uj´ıc´ı v´ ypoˇcetn´ı jádro systému. K aplikaˇcn´ımu serveru se pˇripojuj´ı jednotliv´ı klienti – na tˇechto zaˇr´ızen´ıch jsou data vizualizov´ ana a je umoˇznˇeno uˇzivatel˚ um tˇechto klient˚ u s daty pracovat. D´ıky existenci aplikaˇcn´ıho serveru tito klienti neobsahuj´ı ˇzádnou dalˇs´ı aplikaˇcn´ı logiku a hraj´ı roli tzv. tenkých klient˚ u.

Obrázek 5.2: Pˇr´ıklad tˇr´ıvrstvé architektury (tenký klient). Nicménˇe d´ıky obecnosti tˇr´ıvrstvé architektury je moˇzné si pˇredstavit celou ˇradu jin´ ych scén´ aˇr˚ u. Kupˇr´ıkladu relaˇcn´ı databáze m˚ uˇze fungovat pˇr´ımo na aplikaˇcn´ım serveru nebo m˚ uˇze u ´plnˇe chybˇet a roli datové vrstvy sehraje napˇr. implementace transformuj´ıc´ı data do XML soubor˚ u. Na Obr. 5.3 je pak znázornˇena situace, kde aplikaˇcn´ı server zcela chyb´ı. Aplikaˇcn´ı vrstva m˚ uˇze b´ yt poté pˇr´ıtomna jako souˇcást relaˇcn´ı datab´ aze v podobˇe uloˇzen´ ych procedur a tzv. trigger˚ u (viz dále), nebo mohou jednotliv´ı klienti s sebou nést i aplikaˇcn´ı logiku – stanou se tzv. tlustými klienty. Je moˇzné tyto postupy i kombinovat. Je moˇzné (a dnes jiˇz celkem obvyklé), aby ˇc´ ast aplikaˇcn´ı logiky leˇzela na aplikaˇcn´ım serveru a ˇcást kódu se spouˇstˇela na jednotliv´ ych klientech. Vyuˇzit´ı tˇr´ıvrstvé architektury je tedy velice flexibiln´ı. Pˇri návrhu systému si softwarov´ y architekt mus´ı velmi dobˇre rozmyslet celkové rozvrˇzen´ı jednotliv´ ych logick´ ych vrstev s ohledem na v´ ykon, bezpeˇcnost, udrˇzitelnost, technické vlastnosti a moˇznosti klientsk´ ych zaˇr´ızen´ı a dalˇs´ı rozˇsiˇritelnost navrhovaného systému. Je také

57


Aplikaˇcn´ı vrstva

Obrázek 5.3: Pˇr´ıklad tˇr´ıvrstvé architektury (tlustý klient). nutné vˇzdy jednoznaˇcnˇe definovat komunikaˇcn´ı rozhran´ı mezi vrstvami podle zásad návrhu v´ıcevrstv´ ych aplikac´ı tak, aby bylo moˇzné jednotlivé vrstvy zamˇenit nebo je standardizovat. Nyn´ı si detailnˇeji rozebereme jednotlivé ˇcásti a dalˇs´ı architektonické vzory tˇr´ıvrstvé architektury s ohledem na moˇzné vyuˇzit´ı pˇri implementaci distibuovan´ ych webov´ ych aplikac´ı.

5.2

Aplikaˇ cn´ı vrstva

Aplikaˇcn´ı (nebo také doménov´ a) vrstva je taková vrstva, do které by mˇelo b´ yt soustˇredˇeno maximum v´ ykonného kódu a vlastn´ı logiky aplikace. Existuje celá ˇrada obecn´ ych architektonick´ ych vzor˚ u uplatniteln´ ych pˇri návrhu této vrstvy, nicménˇe zejména u webov´ ych aplikac´ı se vrstva obvykle rozdˇel´ı na doménový model, ve kterém jsou definov´ any z´ akladn´ı entity aplikace a jejich vzájemné vazby, a servisn´ı vrstvu, kter´ a s t´ımto modelem manipuluje nebo vytváˇr´ı jeho rozhran´ı [20].

58


5.2.1

Aplikaˇcn´ı vrstva

Dom´ enov´ y model

Doménov´ y model vytv´ aˇr´ı jakousi s´ıt’ objekt˚ u navzájem spojen´ ych vazbami, kde kaˇzd´ y objekt obvykle reprezentuje nˇejakou entitu v reálném svˇetˇe. Návrhem doménového modelu by mˇel zaˇc´ınat jak´ ykoliv návrh implementace aplikace a jeho programové realizaci obvykle pˇredcház´ı vytvoˇren´ı analytického doménového modelu za vyuˇzit´ı jazyka UML (Unified Modeling Language). Objekty doménového modelu maj´ı sadu atribut˚ u definovanou tak, aby se co nejv´ıce pˇribl´ıˇzily svému re´ alnému vzoru. Kaˇzd´ y objekt doménového modelu by vˇsak mˇel b´ yt jen tak velk´ y, jak je to bezpodm´ıneˇcnˇe nutné. V pˇr´ıpadˇe pˇr´ıliˇs komplexn´ıho objektu je vhodné ho rozdˇelit na menˇs´ı objekty a tyto propojit vazbami. Kv˚ uli snadné rozˇsiˇritelnosti a udrˇzitelnosti je d˚ uleˇzité m´ıt neustále moˇznost bˇehem ˇzivotn´ıho cyklu aplikace snadno doménov´ y model mˇenit a testovat. Dále je nutné udrˇzovat co nejménˇe vazeb modelu na ostatn´ı ˇcásti systému (coˇz je mimo jiné c´ılem mnoha n´ avrhov´ ych vzor˚ u). Ve svˇetˇe Javy jsou obvykle jednotlivé doménové objekty realizovány pomoc´ı POJO (Plain Old Java Object) objekt˚ u. Definice POJO vznikla jako reakce na nepˇr´ıliˇs flexibiln´ı EJB2 (Enterprise Java Bean), které se váˇz´ı na pouˇzit´ y framework a nesplˇ nuj´ı tak poˇzadavek na co nejniˇzˇs´ı poˇcet vazeb modelu na okoln´ı programové prostˇred´ı. Pro POJO neexistuje ˇzádn´ y uchopiteln´ y standard, nicménˇe lze je definovat jako instance kaˇzdé Java Beany, která se snaˇz´ı minimalizovat své vazby v˚ uˇci okol´ı at’ uˇz po str´ ance anotac´ı, dˇediˇcnosti nebo implementace rozhran´ı. To samozˇrejmˇe nen´ı (napˇr´ıklad v pˇr´ıpadˇe spolupráce aplikace s jin´ ymi frameworky) témˇeˇr nikdy moˇzné, nicménˇe zejména podm´ınka neexistuj´ıc´ı dˇediˇcnosti od nˇejaké komponenty uˇzitého frameworku by mˇela b´ yt splnˇena. Pod pojmem Java Bean se poté chápe taková tˇr´ıda, k jej´ımˇz ˇclensk´ ym promˇenn´ ym se pˇristupuje pouze pomoc´ı veˇrejn´ ych getter˚ u a setter˚ u a tyto dodrˇzuj´ı jisté jmenné konvence. Pro pˇr´ıstup k jednotliv´ ym ˇclensk´ ym promˇenn´ ym se d´ıky jednoduchosti POJO m˚ uˇze vyuˇz´ıt pokroˇcil´ ych programovac´ıch technik, jako je aspektové programov´ an´ı a reflexe. Obdobná situace je i v jin´ ych programov´ ych prostˇred´ıch (napˇr. v .NET Frameworku), i kdyˇz syntax kódu a uˇzitá terminologie se samozˇrejmˇe liˇs´ı.

5.2.2

Servisn´ı vrstva

Jak ukazuje Obr. 5.4, servisn´ı vrstva je v hierarchii vrstev um´ıstˇena na vyˇsˇs´ı u ´rovni abstrakce neˇz je doménov´ y model a souˇcasnˇe vytváˇr´ı programové rozhran´ı (Application Programming Interface, zkratkou API) pro prezentaˇcn´ı vrstvu. Jinak neˇz skrze servisn´ı vrstvu nelze s doménov´ ym modelem pracovat.

59


Vrstva persistence dat

Obrázek 5.4: Základn´ı rozdˇelen´ı aplikaˇcn´ı vrstvy. Servisn´ı vrstva je d´ıky tomu, ˇze tvoˇr´ı u ´zké hrdlo“ v toku dat, dobr´ ym m´ıstem ” nejen pro um´ıstˇen´ı aplikaˇcn´ı logiky, ale i zabezpeˇcen´ı nebo kontroly dat. Podle [20] existuj´ı dva pˇr´ıstupy, jak vytvoˇrit servisn´ı vrstvu. Prvn´ı z nich je tzv. Dom´ enov´ a Fas´ ada. Ta principi´ alnˇe deleguje aplikaˇcn´ı logiku do doménového modelu a tvoˇr´ı pouze zmiˇ nované rozhran´ı mezi prezentaˇcn´ı a aplikaˇcn´ı vrstvou a celou servisn´ı vrstvu tvoˇr´ı pouze mnoˇzina fas´ ad nad doménov´ ym modelem. Fasády obsahuj´ı pouze ty operace, které jsou poskytnuty klientovi nad doménov´ ym modelem a samotn´ a servisn´ı vrstva je tak velice tenká. Druh´ y princip, tzv. Operation Script, funguje pˇresnˇe opaˇcnˇe. Doménov´ y model neimplementuje ˇz´ adnou aplikaˇcn´ı logiku a tato je celá implementována pˇr´ımo v servisn´ı vrstvˇe. Rozhran´ı dostupné klientovi tedy nedeleguje práci do doménového modelu, ale s doménov´ ym modelem pˇr´ımo pracuj´ı. V tomto pˇr´ıpadˇe se dá jiˇz hovoˇrit o robustn´ı servisn´ı vrstvˇe a tˇr´ıdy hraj´ıc´ı roli servis b´ yvaj´ı programovˇe velmi rozs´ ahlé. Oba pˇr´ıstupy maj´ı své klady a zápory. V pˇr´ıpadˇe doménové fasády se dá jistˇe hovoˇrit o lepˇs´ı dekompozici aplikaˇcn´ı logiky a t´ım pádem rozˇsiˇretelnˇejˇs´ı implementaci. S t´ım se ovˇsem také poj´ı netriviáln´ı návrh aplikace. Nav´ıc d´ıky tomu, ˇze je aplikaˇcn´ı logika rozeseta do mnoha m´ıst v doménovém modelu, m˚ uˇze se s rostouc´ım poˇctem doménov´ ych objekt˚ u tvoˇrit duplicitn´ı kód. U druhého pˇr´ıstupu je aplikaˇcn´ı kód pouze na nˇekolika m´ alo m´ıstech a to umoˇzn ˇuje snaˇzˇs´ı refaktorizaci kódu, na druhou stranu to znesnadˇ nuje budouc´ı rozˇsiˇritelnost doménového modelu.

5.3


V pˇredchoz´ım textu jsme zavedli základn´ı terminologii vrstev a tˇr´ıvrstvého architektonického vzoru. Nyn´ı je nutné detailnˇeji rozebrat otázku zachován´ı persistence dat a programového pˇr´ıstupu k tˇemto dat˚ um (tedy nejniˇzˇs´ı vrstvy tˇr´ıvrstvého modelu).

60


5.3.1


Syst´ em ˇ r´ızen´ı b´ aze dat

ˇ sen´ı problému uchov´ Reˇ av´ an´ı dat spoˇc´ıvá obvykle v nasazen´ı nˇekteré z implemenˇ tac´ı systému ˇr´ızen´ı b´ aze dat (SRBD nebo anglicky DBMS – Database management system). Jejich hlavn´ım u ´ˇcelem je poskytnut´ı ˇr´ızen´ı (vkládán´ı, editace, mazán´ı) nad b´ az´ı dat (neboli datab´ az´ı), definovat strukturu uloˇzen´ı tˇechto dat a vytvoˇrit rozhran´ı mezi aplikaˇcn´ımi programy a uloˇzen´ ymi daty [19]. Pojmem databázov´ y ” ˇ systém“ poté obvykle oznaˇcuje spojen´ı SRBD se samotnou báz´ı dat. Pouˇzit´ı nˇekterého z datab´ azov´ ych systém˚ u pˇrináˇs´ı celou ˇradu v´ yhod, jako je udrˇzov´ an´ı strukturovanosti dat, podpora transakc´ı, moˇznost agregace dat, ˇr´ızen´ı pˇr´ıstupov´ ych pr´ av atd. Datab´ azové systémy se obvykle snaˇz´ı maximálnˇe vyuˇz´ıt operaˇcn´ıho a souborového systému tak, aby bylo z´ıskáván´ı a ukládán´ı dat co nejv´ıce ˇ efektivn´ı. Pˇrev´ aˇzn´ a vˇetˇsina dnes pouˇz´ıvan´ ych SRBD pak pro strukturován´ı dat v datab´ azi vyuˇz´ıv´ a tzv. relaˇcn´ı model.

Relaˇ cn´ı model Relaˇcn´ı model sdruˇzuje data do tabulek, které obsahuj´ı n-tice jednotliv´ ych entit (ˇrádk˚ u). Tabulka je struktura entit s pevnˇe stanoven´ ymi atributy (sloupci). Kaˇzd´ y sloupec m´ a jasnˇe definov´ an jednoznaˇcn´ y název, typ a moˇzn´ y rozsah vkládan´ ych dat. Pokud jsou v r˚ uzn´ ych tabulkách sloupce stejného typu, pak tyto sloupce mohou vytv´ aˇret vazby mezi jednotliv´ ymi tabulkami. Tabulky se poté naplˇ nuj´ı konkrétn´ımi daty. Kolekce v´ıce tabulek, jejich funkˇcn´ıch vztah˚ u, index˚ u a dalˇs´ıch souˇcást´ı tvoˇr´ı samotnou relaˇcn´ı databázi. Relaˇcn´ı model umoˇzn ˇuje pˇrirozenou reprezentaci zpracovávan´ ych dat a je v nˇem moˇzné pˇri n´ avrhu datab´ aze snadno a pomˇernˇe intuitivnˇe definovat jednotlivé vazby mezi tabulkami. Model také klade velk´ y d˚ uraz na zachován´ı integrity dat. Model dále pracuje s term´ıny jako je referenˇcn´ı integrita, ciz´ı kl´ıˇc, prim´ arn´ı kl´ıˇc, norm´ aln´ı forma apod. Relaˇcn´ı datab´ azov´ y systémy obvykle pro kontrolu databáze a nastavován´ı dalˇs´ıch direktiv vyuˇz´ıvaj´ı strukturovan´ y dotazovac´ı jazyk SQL (Structured Query Language). Problematika datab´ az´ı je velmi obsáhlá a pro u ´ˇcely této práce postaˇc´ı, pokud se nadále budeme zab´ yvat jen nˇekter´ ymi vlastnostmi relaˇcn´ıch databázov´ ych systém˚ u uplatniteln´ ych v prostˇred´ı webov´ ych distribuovan´ ych aplikac´ı.

61



Uloˇ zen´ e procedury a triggery Jak jiˇz bylo zm´ınˇeno v pˇredchoz´ım textu, databázové systémy umoˇzn ˇuj´ı ˇcásteˇcnˇe pˇrevz´ıt roli aplikaˇcn´ı vrstvy d´ıky uloˇzen´ ym procedurám a tzv. trigger˚ um. To jsou v podstatˇe bloky k´ odu napsaného v nˇekterém programovac´ım jazyce (napˇr. PL/SQL) vytvoˇreného speci´ alnˇe pro u ´ˇcel bˇehu v prostˇred´ı relaˇcn´ı databáze. Lze je kupˇr´ıkladu vyuˇz´ıt pro zachov´ an´ı referenˇcn´ı integrity dat. V´ yhodou je zpravidla mnohem vˇetˇs´ı rychlost zpracov´ an´ı neˇz pokud by tyto bloky kódu mˇely b´ yt ˇr´ızeny vzdálenˇe klientskou aplikac´ı. Kromˇe velmi specifick´ ych pˇr´ıpad˚ u vˇsak nelze pouˇzit´ı procedur a trigger˚ u pˇr´ıliˇs doporuˇcit. Jsou jen velmi obt´ıˇznˇe udrˇzovatelné, na velmi n´ızké u ´rovni abstrakce, nen´ı moˇzné je rozumnˇe debuggovat a jejich podpora se liˇs´ı v závislosti na pouˇzité implementaci datab´ azového systému.

Nev´ yhody relaˇ cn´ıch datab´ az´ı Aˇckoliv existuj´ı standardy pro jazyk SQL, mezi jednotliv´ ymi implementacemi relaˇcn´ıch datab´ az´ı jsou znaˇcné rozd´ıly v jejich podpoˇre. Obvykle nejsou implementovány vˇsechny poˇzadavky standardu a naopak, kaˇzdá implementace obsahuje nejr˚ uznˇejˇs´ı prvky, které nejsou ve standardech obsaˇzeny. Pˇrenositelnost SQL sekvenc´ı mezi jednotliv´ ymi datab´ azemi je proto omezená. Souˇcasnˇe nen´ı moˇzné jednoduˇse pˇrenáˇset data mezi r˚ uzn´ ymi databázemi. Relaˇcn´ı datab´ azové systémy jsou dobré pro ˇr´ızen´ı velkého mnoˇzstv´ı dat, ale poskytuj´ı n´ızkou podporu pro manipulaci s nimi. Jsou zaloˇzeny na dvourozmˇern´ ych tabulk´ ach a vztahy mezi daty jsou vyjadˇrovány porovnáván´ım hodnot v nich uloˇzen´ ych. SQL sice umoˇzn ˇuje tabulky za bˇehu propojit, nicménˇe tento pˇr´ıstup je velmi neintuitivn´ı a nepˇrehledn´ y. Relaˇcn´ı model databáz´ı je sice jednoduch´ ya pˇritom velmi robustn´ı a flexibiln´ı, je ale také naprosto rozd´ıln´ y od objektového modelu. Relaˇcn´ı datab´ aze nejsou navrhovány pro ukládán´ı objekt˚ u a vytvoˇren´ı rozhran´ı pro ukl´ ad´ an´ı tˇechto objekt˚ u v relaˇcn´ı databázi je netriviáln´ı u ´kol. Alespoˇ n ˇc´ asteˇcné ˇreˇsen´ı obou v´ yˇse nast´ınˇen´ ych problém˚ u tkv´ı v pouˇzit´ı bud’ objektovˇe orientovan´ ych datab´ az´ı (které ovˇsem nejsou pˇr´ıliˇs vyuˇz´ıvané), nebo v nasazen´ı tzv. objektovˇe-relaˇcn´ıho mapov´ an´ı.

5.3.2

Objektovˇ e-relaˇ cn´ı mapov´ an´ı

Jako objektovˇe-relaˇcn´ı mapov´ an´ı (Object-Relational Mapping, zkratkou ORM) se oznaˇcuje sada programovac´ıch technik, které se snaˇz´ı zajistit automatickou kon-

62



verzi dat mezi relaˇcn´ı datab´ az´ı a doménov´ ym modelem a následnou synchronizaci doménov´ ych objekt˚ u v aplikaci a jejich reprezentaci v databázovém systému tak, aby byla zajiˇstˇena persistence dat (Obr. 5.5). D´ıky ORM je moˇzné pˇrirozenˇe pracovat s doménov´ ymi objekty, aniˇz by se programátor staral jak zajistit jejich perzistenci. Ve [20] jsou rozebr´ any nˇekteré základn´ı návrhové vzory, které umoˇzn´ı svépomoc´ı implementovat ORM. Nicménˇe protoˇze zajiˇstˇen´ı synchronizace mezi databáz´ı a doménov´ ym modelem je netriviáln´ı problém zejména v kontextu paraleln´ıho pˇr´ıstupu a v´ ykonnosti celé aplikace, vyuˇz´ıvá se dnes obvykle jiˇz ustálen´ ych a standardizovan´ ych framework˚ u, které ORM mapován´ı zajist´ı.

Obrázek 5.5: Vyuˇzit´ı objektovˇe-relaˇcn´ıho mapován´ı. Nˇekteré implementace ORM framework˚ u nav´ıc programátora odst´ın´ı od ponˇekud nepohodlného SQL jazyka a poskytnou mu jiné moˇznosti pˇr´ıstupu do databáze, které obvyklé implementace databázov´ ych systém˚ u nenab´ız´ı. Dále také umoˇzn ˇuj´ı ˇcásteˇcnˇe smazat rozd´ıly mezi jednotliv´ ymi implementacemi databázov´ ych systém˚ u – je moˇzné konfigurovat SQL dialekt, se kter´ ym framework komunikuje s databáz´ı a t´ım je lze pˇri zmˇenˇe datab´ azového systému m´ısto pˇrepisován´ı celé datové vrstvy pouze pˇrekonfigurovat ORM framework. I pˇres nesporné v´ yhody je vˇsak nasazen´ı tˇechto framework˚ u sp´ıˇse poˇcátek cesty za bezproblémov´ ym mapov´ an´ım mezi doménov´ ym modelem a relaˇcn´ı databáz´ı a v nˇekter´ ych pˇr´ıpadech se dokonce vyplat´ı jejich nasazen´ı u ´plnˇe vyhnout.

Java Persistence API Specifikac´ı pro ORM frameworky na platformˇe Java je tzv. Java Persistence API (zkratkou JPA). P˚ uvodnˇe existovalo nˇekolik r˚ uzn´ ych ORM framework˚ u, které vznikly jako reakce na pˇr´ıliˇs komplikovan´ y tehdejˇs´ı model EJB, kter´ y se nav´ıc dal pouˇz´ıt pouze ve svˇetˇe rozs´ ahl´ ych Java EE aplikac´ı [21]. V rámci standardizace tˇechto ORM framework˚ u poté dodateˇcné vznikla specifikace JPA, jej´ıˇz podporu

63



následnˇe st´ avaj´ıc´ı frameworky pˇrevzaly. Nejznámˇejˇs´ımi implementacemi JPA je Hibernate a EclipseLink. Pˇri dodrˇzen´ı konvenc´ı pˇredepsan´ ych JPA je moˇzné tyto dva frameworky na ORM vrstvˇe navzájem zamˇenit bez zmˇeny implementace. JPA mimo jiné definuje i dotazovac´ı jazyk JPQL (Java Persistence Query Language). Ten je syntax´ı podobn´ y SQL, nicménˇe nam´ısto tabulek se pohybuje na u ´rovni doménov´ ych objekt˚ u. Nˇekteré frameworky jazyk dále rozˇsiˇruj´ı, napˇr´ıklad Hibernate m´ a vlastn´ı jazyk HQL (Hibernate Query Language), jemuˇz je JPQL podmnoˇzinou.

5.3.3

Data Gateway

I v okamˇziku vyuˇzit´ı ORM framework˚ u se nelze vyhnout kódu, kter´ y pˇr´ımo závis´ı na logice relaˇcn´ıch datab´ az´ı. Zejména pro CRUD (Create-Read-Update-Delete) operace je st´ ale nutné vyuˇz´ıt at’ uˇz generické SQL nebo napˇr´ıklad v´ yˇse zm´ınˇen´ y jazyk JPQL. Je naprosto neˇz´ adouc´ı m´ıchat“ tento specifick´ y kód do aplikaˇcn´ı ” vrstvy uˇz jen s ohledem na to, ˇze nˇekterá z budouc´ıch odvozenin aplikace m˚ uˇze vyuˇz´ıvat m´ısto relaˇcn´ıch datab´ az´ı napˇr´ıklad XML soubory, s nimiˇz se ovˇsem pracuje diametr´ alnˇe odliˇsnˇe. Obvykl´ ym postupem je tedy vytvoˇren´ı programového rozhran´ı pro pˇr´ıstup k persistentn´ı vrstvˇe. Implementace tohoto rozhran´ı bude poté obsahovat vˇsechen kód specifick´ y pro technologii pouˇzitou pro persistenci dat. Takové implementace poté tvoˇr´ı jakousi br´ anu (gateway) mezi architektonick´ ymi vˇety aplikaˇcn´ı a persistentn´ı vrstvy (Obr. 5.6).

Obrázek 5.6: Rozhran´ı mezi aplikaˇcn´ı a persistentn´ı vrstvou. Nen´ı ˇz´ adouc´ı do tˇechto objekt˚ u vkládat aplikaˇcn´ı logiku – rozhran´ı by mˇelo b´ yt co nejjednoduˇsˇs´ı a zajiˇst’ovat pouze základn´ı CRUD operace. Jakákoliv komplexn´ı logika by mˇela b´ yt souˇc´ ast´ı klienta tohoho rozhran´ı. Implementace se poté ˇcasto neprogramuj´ı ruˇcnˇe, ale vyuˇz´ıv´ a se sp´ıˇse r˚ uzn´ ych moˇznost´ı dˇediˇcnosti nebo gene-

64


Prezentaˇcn´ı vrstva

rátor˚ u k´ odu. Je dokonce moˇzné vytváˇret implementace rozhran´ı pˇr´ımo za bˇehu aplikace pomoc´ı aspektovˇe orientovaného programov´ an´ı (viz dále).

Data Access Object Jako Data Access Object (objekt zpˇr´ıstupˇ nuj´ıc´ı data, zkratkou DAO) se tradiˇcnˇe oznaˇcuje uplatnˇen´ı n´ avrhového vzoru Data Gateway v prostˇred´ı Java aplikac´ı. Rozhran´ı DAO navenek poskytuje metody pro práci s doménov´ ymi objekty – instancemi POJO nebo EJB, a umoˇzn ˇuje jejich persistenci. Vnitˇrnˇe poté zajiˇst’uj´ı pˇreklad“ tˇechto objekt˚ u do tvaru, kterému rozum´ı relaˇcn´ı databáze. To m˚ uˇze b´ yt ” zajiˇstˇeno mnoha cestami – parametrizac´ı generick´ ych SQL dotaz˚ u nebo napˇr´ıklad vyuˇzit´ım jiˇz zmiˇ novan´ ych ORM framework˚ u. Sezn´ amili jsme se s obvykl´ ymi architektonick´ ymi návrhov´ ymi vzory pro spojen´ı datové a aplikaˇcn´ı vrstvy. Nyn´ı je nutné vyˇreˇsit posledn´ı prázdné m´ısto v rozboru tˇr´ıvrstvé architektury – prezentaˇcn´ı vrstvu.

5.4

Prezentaˇ cn´ı vrstva

´ Ukolem této kapitoly je uk´ azat obvyklá architektonická ˇreˇsen´ı rozhran´ı mezi aplikaˇcn´ı a prezentaˇcn´ı vrstvou specifická pro webové aplikace a pˇredstavit nˇekteré technologie, které tyto obecné vzory implementuj´ı.

5.4.1

Architektura MVC (Model-View-Controller )

MVC je architektonick´ y vzor, kter´ y oddˇeluje doménov´ y model aplikace od uˇzivatelského rozhran´ı. Vznikl spolu s prvn´ımi návrhy grafického uˇzivatelského rozhran´ı a dnes se uplatuje zejména v r´ amci distribuovan´ ych webov´ ych aplikac´ı. Popis jednotliv´ ych komponent je n´ asleduj´ıc´ı: - Model – v klasickém tˇr´ıvrstvém modelu obvykle odpov´ıdá doménovému modelu v aplikaˇcn´ı vrstvˇe. Nicménˇe frameworky implementuj´ıc´ı MVC obvykle tyto komponenty neum´ı navzájem synchronizovat a je tedy na programátorovi, aby synchronizaci zajistil (napˇr´ıklad pˇres servisn´ı vrstvu). - Pohled (View) –pˇrev´ ad´ı data reprezentovaná modelem do podoby vhodné k zobrazen´ı uˇzival˚ um.

65



ˇ c (Controler) – reaguje na události od uˇzivatele a zajiˇst’uje zmˇeny v mo- Radiˇ delu nebo v pohledu. Aˇckoliv by se mohlo zd´ at, ˇze MVC je vlastnˇe tˇr´ıvrstvá architektura (a oba architektonické vzory opravdu b´ yvaj´ı ˇcasto zamˇen ˇovány a jsou si na prvn´ı pohled podobné), nen´ı to v˚ ubec pravda. Topologie MVC totiˇz nen´ı lineárn´ı, ale tvoˇr´ı jak´ ysi troj´ uheln´ık. Na rozd´ıl od obecné tˇr´ıvrstvé architektury také definuje základn´ı tok dat a pohybuje se na rozhran´ı aplikaˇcn´ı a prezentaˇcn´ı vrstvy, zp˚ usoby zajiˇstˇen´ı persistence doménového modelu nejsou architekturou nijak pokryty a obecnˇe nelze zamˇen ˇovat datovou vrstvu s MVC Modelem. Na Obrázku 5.7 je zobrazeno základn´ı schéma MVC architektury.

Obrázek 5.7: Základn´ı schéma MVC architektury. ˇ c a Pohled závisej´ı na Modelu, ale Model nezávis´ı D˚ uleˇzit´ y je zejména fakt, ˇze Radiˇ ani na jedné z tˇechto dvou komponent. To (mimo jiné) umoˇzn ˇuje testovat doménov´ y model aplikace nez´ avisle na vizuáln´ı prezentaci dat. Dále m˚ uˇzeme podle [20] rozdˇelit MVC architekturu na dva základn´ı typy.

Pasivn´ı MVC ˇ c, kter´ V pasivn´ım modelu je to pouze Radiˇ y je oprávnˇen manipulovat s Modelem. ˇ c modifikuje Model a poté informuje Pohled, ˇze se Model zmˇenil. Tento se Radiˇ poté pˇrekresl´ı, aby zobrazoval aktuáln´ı data. Model je v pasivn´ım MVC naprosto nezávisl´ y a proto nemus´ı nijak notifikovat zmˇenu sám sebe – tuto ˇcinnost obstará ˇ c. Radiˇ Pˇr´ıkladem pasivn´ıho MVC m˚ uˇze b´ yt klasická webová prezentace pˇres HTTP protokol. Bez vyuˇzit´ı dalˇs´ıch technologi´ı neexistuje cesta, jak jednoduˇse pˇrij´ımat asynchronn´ı aktualizace dat ze serveru. Webov´ y prohl´ıˇzeˇc zobraz´ı Pohled a um´ı zachyt´ avat vstupy od uˇzivatele, neum´ı vˇsak detekovat ˇzádné zmˇeny modelu na serveru.

66



Aktivn´ı MVC ˇ ce. To V aktivn´ım MVC m˚ uˇze Model mˇenit sv˚ uj stav bez jakéhokoliv zapojen´ı Radiˇ se m˚ uˇze st´ at v pˇr´ıpadˇe, kdy jsou data mˇenˇena z nˇejak´ ych dalˇs´ıch zdroj˚ u (napˇr´ıklad jin´ ym uˇzivatelem, pˇr´ımo v databázi, opakuj´ıc´ı se paraleln´ı u ´lohou atp.) a zmˇeny se mus´ı okamˇzitˇe projevit do Pohledu. Model tedy notifikuje zmˇenu sama sebe, Pohled tuto zmˇenu zachyt´ı a dojde k pˇrekreslen´ı okna grafického uˇzivatelského ˇ ce se nicménˇe nijak nevyluˇcuje. M˚ ˇ c, rozhran´ı. Zapojen´ı Radiˇ uˇze to b´ yt právˇe Radiˇ kter´ y Model zmˇen´ı, nicménˇe aktualizaci Pohledu nebude sám zajiˇst’ovat a nechá ji plnˇe v kompetenci Modelu.

Tok ud´ alost´ı v MVC Pro u ´plné pochopen´ı MVC architektury jsou na Obrázku 5.8 znázornˇeny typické interakce mezi uˇzivatelem a aplikac´ı vyuˇz´ıvaj´ıc´ı MVC. Tok událost´ı v aplikaci vypadá n´ asledovnˇe: - uˇzivatel vykon´ a nˇejakou akci v uˇzivatelském rozhran´ı. ˇ cem. - ud´ alost je zachycena Radiˇ ˇ c provede rozhodnut´ı o tom, jak na událost zareagovat a zmˇen´ı hodnoty - Radiˇ v modelu nebo pˇr´ımo ovlivn´ı Pohled. - Pohled se aktualizuje a uˇzivateli zobraz´ı zmˇeny v Modelu (nebo se zobraz´ı zcela jin´ y Pohled ).

Obrázek 5.8: Scénáˇr interakce v MVC architektuˇre.

67



ˇ c, kter´ V celém modelu je to tedy Radiˇ y hraje dominantn´ı u ´lohu a urˇcuje, jak se bude reagovat na ud´ alosti vzniklé na stranˇe uˇzivatele – odtud anglick´ y název Controller.

Spojen´ı MVC a servisn´ı vrstvy Nab´ız´ı se ot´ azka, jak vyˇreˇsit jiˇz dˇr´ıve zm´ınˇen´ y problém synchronizace Modelu s doménov´ ym modelem aplikace. V Kap. 5.2 jsme definovali servisn´ı vrstvu, která bude vytváˇret programové rozhran´ı mezi prezentaˇcn´ı vrstvou a doménov´ ym modelem aplikace. Na obr´ azku 5.9 je zn´ azornˇeno jedno z moˇzn´ ych spojen´ı MVC se servisn´ı vrstvou (nˇekdy naz´ yvané jako MVCS - Model View Controller Service). Jak jiˇz bylo dˇr´ıve zm´ınˇeno, servisn´ı vrstva m˚ uˇze s doménov´ ym modelem manipulovat pˇr´ımo podle vzoru Operation Script, nebo m˚ uˇze tvoˇrit pouze doménovou fasádu a delegovat logiku do doménového modelu.

Obrázek 5.9: MVC architektura ve spojen´ı se servisn´ı vrstvou. ˇ c tedy m˚ Radiˇ uˇze pˇr´ımo mˇenit Model a na ˇzádost uˇzivatele m˚ uˇze provést napˇr´ıklad uloˇzen´ı dat z Modelu do datab´ aze prostˇrednictv´ım servisn´ı vrstvy. Servisn´ı vrstva m˚ uˇze m´ıt pˇr´ımou referenci na Model nebo m˚ uˇze b´ yt aktualizace provedena pˇres ˇ c. Radiˇ

5.4.2

MVC v prostˇ red´ı webu

ˇ cem nen´ı u desktopov´ Rozliˇsovat rozd´ıl mezi Pohledem a Radiˇ ych aplikac´ı aˇz tak d˚ uleˇzité a nˇekteré frameworky explicitnˇe logické rozdˇelen´ı pˇr´ısluˇsné ˇcásti prezentaˇcn´ı vrstvy do tˇechto MVC komponent nevyˇzaduj´ı (napˇr´ıklad stále ˇsiroce pouˇz´ıvan´ y Swing toolkit).

68



Nicménˇe zejména u webov´ ych aplikac´ı je situace zcela jiná a MVC architektura je zde naprosto pˇrirozenˇe vyuˇzita pro dekompozici komponent staraj´ıc´ıch se o generován´ı HTML k´ odu od ˇc´ ast´ı systému obsluhuj´ıc´ıch HTTP poˇzadavky: - Model je identick´ y s Modelem v desktopov´ ych technologi´ıch (obsahuje data a doménovou logiku). - Pohled je ta ˇc´ ast serverového kódu, která se stará o generován´ı HTML kódu. M˚ uˇze vˇsak prezentovat data i jinak, napˇr´ıklad ve formátu XML, JSON (JavaScript Object Notation), PDF (Portable Document Format) atp. ˇ c se v prostˇred´ı webu nejˇcastˇeji skládá ze dvou hlavn´ıch ˇcást´ı. Prvn´ı - Radiˇ je tzv. Front Controller, kter´ y zachytává vˇsechny HTTP poˇzadavky. Ty náˇ c˚ slednˇe zpracuje a pˇrepoˇsle dalˇs´ım Radiˇ um, které jsou obvykle identifikovány ˇ uvodnˇe pocházepodle URI. Konkrétn´ı Radiˇc potom typicky pˇrijme data p˚ j´ıc´ı z HTTP poˇzadavku, uloˇz´ı je do Modelu a ten prováˇze s konkrétn´ım Pohledem. Situace se komplikuje v pˇr´ıpadˇe, kdy je vyuˇzito technologi´ı jako je AJAX (Asynchronous JavaScript and XML). V tˇechto situac´ıch je znaˇcná ˇcást prezentaˇcn´ı logiky (tedy Pohledu) pˇresunuta na klienta (jak velká ˇcást záleˇz´ı na konkrétn´ı implementaci). Nicménˇe lze ˇr´ıci, ˇze i v tˇechto pˇr´ıpadech je architektura MVC vyuˇziteln´ a.

JavaServer Pages Jako nejtypiˇctˇejˇs´ıho pˇredstavitele uplatnˇen´ı MVC ve svˇetˇe webov´ ych Java aplikac´ı m˚ uˇzeme jmenovat technologii tzv. servlet˚ u a s t´ım souvisej´ıc´ı JavaServer Pages (JSP). Servlet je velmi obecnˇe ˇreˇceno tˇr´ıda odpovˇedná za zpracován´ı HTTP poˇzadavku a vytvoˇren´ı odpov´ıdaj´ıc´ı odpovˇedi [22]. Servletu b´ yvá v pr˚ umˇerné webové aplikaci cel´ a ˇrada a jejich organizaci a mapován´ı na jednotlivá URL má na starosti tzv. servletové nebo také webové kontejnery, coˇz jsou vlastnˇe obecnˇe známé Java servery“ jako je napˇr´ıklad Apache Tomcat nebo GlassFish. Tyto kontejnery ” obvykle vytvoˇr´ı jednu nebo v´ıce instanc´ı od kaˇzdého servletu a pokud na server pˇrijde HTTP poˇzadavek, je vyvolána odpov´ıdaj´ıc´ı metoda instance servletu namapovaného na URL tohoto poˇzadavku. JSP servlet je poté velmi specifick´ y typ servletu. Jeho programov´ y zápis totiˇz nen´ı realizov´ an v Javˇe, ale ve struktuˇre velmi bl´ızké HTML. Je moˇzné do znaˇcek HTML m´ıchat“ dalˇs´ı tagy ze standardn´ıch JSP knihoven, vytvoˇrit si knihovnu ” vlastn´ı nebo d´ ale pouˇz´ıvat dalˇs´ıch ˇsablonovac´ıch nástroj˚ u. Lze také omezenˇe vyuˇz´ıt

69



Java k´ od. Takto zapsan´ y servlet je poté internˇe v servletovém kontejneru automaticky konvertov´ an na Java zdrojov´ y kód a následnˇe se chová jako kaˇzdá jiná tˇr´ıda. Nicménˇe jak ukazuje Obr. 5.10, c´ılem JSP servlet˚ u je jediná vˇec – formátovat data ˇ obdrˇzen´ a ve od Radiˇce do podoby HTML kódu (schéma nen´ı zcela pˇresné, obvykle ˇ c, ale pˇres nadˇrazen´ nejsou data do JSP servletu pˇredána pˇr´ımo pˇres Radiˇ y Front Controller ).

Obrázek 5.10: Základn´ı architektura JSP. ˇ c poté obvykle b´ Radiˇ yv´ a realizovan´ y jako klasick´ y programovˇe implementovan´ y ˇ ce m˚ servlet. V servletu Radiˇ uˇze b´ yt soustˇredˇena veˇskerá logika souvisej´ıc´ı s pˇr´ıˇ c pravou dat k zobrazen´ı nebo vol´ an´ı niˇzˇs´ıch vrstev pro naˇcten´ı dat do Modelu. Radiˇ také m˚ uˇze prov´ adˇet pˇresmˇerov´ an´ı a dalˇs´ı vˇeci, které nutnˇe nesouvis´ı s aplikaˇcn´ı logikou – ta by mˇela leˇzet vˇzdy v aplikaˇcn´ı vrstvˇe. P˚ uvodn´ı ˇcisté JSP se dnes jiˇz u d˚ uvodu velké pracnosti v´ yvoje moc nepouˇz´ıvá a v praxi tuto technologii nahradily frameworky, které moˇznosti JSP dále rozˇsiˇruj´ı. Je vˇsak nutné pochopit principy fungován´ı JSP a MVC architektury obecnˇe, protoˇze z nich vˇetˇsina modern´ıch framework˚ u pˇr´ımo vycház´ı.

70


5.4.3


Architektura MVP (Model-View-Presenter )

Architektonick´ y vzor MVP je principiálnˇe podobn´ y MVC a oba vzory b´ yvaj´ı dost ˇcasto navz´ ajem zamˇen ˇov´ any. Nicménˇe jednotlivé komponenty hraj´ı v MVP trochu jinou roli (Obr. 5.11).

Obrázek 5.11: Scénáˇr interakce v MVP achitektuˇre. Uˇzivatelsk´ y vstup a v´ ystup tentokrát plnˇe kontroluje Pohled skrze ovládac´ı prvky uˇzivatelského rozhran´ı. Prim´ arn´ı motivac´ı pro oddˇelen´ı Pohledu a Presenteru (budeme nad´ ale pouˇz´ıvat anglické slovo presenter“, protoˇze pro nˇe nen´ı ˇzádn´ y vhodn´ y ” ˇcesk´ y ekvivalent) uˇz nen´ı nutnost oˇsetˇren´ı událost´ı od uˇzivatele a kontroly vstupu, d˚ uvody jsou ˇcistˇe architektonické (lepˇs´ı udrˇzovatelnost kódu). Pohled má typicky pˇr´ımou vazbu na Presenter a ten obvykle pˇr´ımo pracuje s Pohledem, takˇze i tato vazba je silnˇejˇs´ı neˇz v pˇr´ıpadˇe MVC. Pohled oproti MVC nav´ıc zpracovává uˇzivatelsk´ y vstup a je zde tedy dominantn´ı komponentou (typicky v reakci na událost od uˇzivatele zavol´ a nˇejakou metodu v Presenteru). Presenter m˚ uˇze obsahovat prezentaˇcn´ı a aplikaˇcn´ı logiku (nebo deleguje aplikaˇcn´ı logiku do dˇr´ıve popsané servisn´ı vrstvy). Manipuluje s Modelem, coˇz (napˇr´ıklad pomoc´ı systému posluchaˇc˚ u a notifikac´ı) zajist´ı aktualizaci Pohledu, nebo ovlivˇ nuje Pohled pˇr´ımo (z´ aleˇz´ı na implementaci a moˇznostech jazyka). Popsan´ y architektonick´ y vzor se také oznaˇcuje jako Supervising Presenter. Existuj´ı dalˇs´ı modifikace MVP, napˇr´ıklad Passive View, kdy je naopak zv´ yˇsena odpovˇednost Presenteru a Pohled u ´plnˇe ztrác´ı vazbu na Model. Jejich popis vˇsak pˇresahuje u ´ˇcel tohoto textu. D˚ uvod, proˇc zde uvád´ıme tento architektonick´ y vzor je zejména fakt, ˇze se MVP velice ˇcasto a zcela nesprávnˇe zamˇen ˇuje s MVC. Pˇr´ıkladem vyuˇzit´ı MVP m˚ uˇze b´ yt toolkit WinForms, kter´ y je souˇcást´ı .NET Frameworku od spoleˇcnosti Microsoft.

71



MVP v prostˇ red´ı webu MVC se dobˇre hod´ı pro klasické webové aplikace, kde jsou statické HTML stránky generov´ any pˇr´ımo na serveru. Nicménˇe v pˇr´ıpadˇe modern´ıch AJAX aplikac´ı, kdy se ˇcást prezentaˇcn´ı vrstvy pˇresouvá do klientského prohl´ıˇzeˇce, zaˇc´ıná b´ yt MVC nevyhovuj´ıc´ı. Oproti tomu MVP architektura je pro tento u ´ˇcel jako stvoˇrená. Jak je vidˇet na Obr´ azku 5.12, komponenta Pohledu (obvykle implementovaná pomoc´ı JavaScriptu) se pˇresouv´ a do klientského prohl´ıˇzeˇce a m´ısto programového rozhran´ı a vol´ an´ı metod budou tyto komunikovat napˇr´ıklad pomoc´ı HTTP protokolu. Pˇri vyplˇ nov´ an´ı formul´ aˇr˚ u je moˇzné validovat data pˇr´ımo na stranˇe klienta. Pokud tedy uˇzivatel klikne na tlaˇc´ıtko, které má zobrazit nˇejaké poloˇzky z databáze, je tento poˇzadavek zpracován na stranˇe webového prohl´ıˇzeˇce a na pozad´ı se odeˇsle ˇz´ adost do Presenteru. Ten m˚ uˇze ze servisn´ı vrstvy naˇc´ıst patˇriˇcná data za datab´ aze a uloˇzit do Modelu. Poté dojde opˇet pomoc´ı HTTP protokolu k aktualizován´ı Pohledu tak, aby zobrazil aktuáln´ı data. Z toho vypl´ yv´ a také potenci´ al sn´ıˇzit zátˇeˇz na servery a s´ıt’ obecnˇe. Jelikoˇz nen´ı potˇreba pˇri kaˇzdém poˇzadavku sestavit cel´ y HTML dokument, ale pouze zobrazit aktualizovan´ y Model, je mnoˇzstv´ı vymˇen ˇovan´ ych dat v´ yraznˇe niˇzˇs´ı. Nicménˇe tento pˇr´ıstup naopak m˚ uˇze zv´ yˇsit poˇcet vymˇen ˇovan´ ych HTTP poˇzadavk˚ u, a tˇrebaˇze pˇrenáˇsej´ı niˇzˇs´ı mnoˇzstv´ı dat, pˇri nevhodné implementaci zátˇeˇz neklesne.

Obrázek 5.12: Scénáˇr interakce ve webové MVP aplikaci.

5.4.4

JavaServer Faces

Jiˇz dˇr´ıve jsme si uk´ azali JSP jako jedno z ukázkov´ ych nasazen´ı architektury MVC ve webové aplikaci. Nyn´ı si detailnˇeji rozebereme technologii JavaServer Faces

72



(zkratkou JSF), kter´ a i pˇres to, ˇze z JSP pˇr´ımo vycház´ı, se naopak bl´ıˇz´ı sp´ıˇse MVP architektuˇre. Myˇslenkou je opˇet oddˇelen´ı definice uˇzivatelského rozhran´ı (tzv. Faces) od vlastn´ı aplikaˇcn´ı a prezentaˇcn´ı logiky. I zde se tak dˇeje pomoc´ı soubor˚ u podobn´ ych HTML, ve kter´ ych je definov´ ano vlastn´ı uˇzivatelské rozhran´ı. Pˇri psan´ı tˇechto XML soubor˚ u se pouˇz´ıvaj´ı speci´ aln´ı XML tagy, které se importuj´ı z tzv. Tag Library Description (TLD) knihoven. I zde je vyuˇzito Front Controlleru a vykreslován´ı HTML str´ anky se odehr´ av´ a na serveru [23]. Prvn´ı rozd´ıl pˇrich´ az´ı v okamˇziku, kdy si uvˇedom´ıme, ˇze konfigurace grafického rozhran´ı je komponentovˇe orientovaná. Kaˇzd´ y tag má internˇe v rámci své knihovny pˇriˇrazeno nˇekolik Java tˇr´ıd. Soubor tˇechto tˇr´ıd se naz´ yvá Komponenta. Tato programov´ a reprezentace vytv´ aˇr´ı aplikaˇcn´ı logiku tagu (jako konverzi hodnot na text, validaci a pˇr´ıpravu pro vykreslen´ı“ informace). Ke kaˇzdé komponentˇe je vytvo” ˇren jej´ı programov´ y Renderer, kter´ y zap´ıˇse do v´ ystupu vlastn´ı HTML kód a data z reprezentace tagu. Je tedy moˇzné vytvoˇrit celé uˇzivatelské rozhran´ı aniˇz bychom pouˇzili jedin´ y HMTL tag. V JSF také odpadá nutnost vyuˇzit´ı ˇsablonovac´ıch framework˚ u (souˇc´ ast´ı je framework Facelets, kter´ y umoˇzn ˇuje ˇsablonován´ı). Jak je vidˇet na Obr´ azku 5.13, JSF zavád´ı také pojem backing nebo také managed beans. Pˇrestoˇze jsou tyto beany“ ˇcasto realizovány jako POJO objekty, ” nemaj´ı v˚ ubec nic spoleˇcného s doménov´ ym modelem aplikace. Reprezentuj´ı ty tˇr´ıdy, jejichˇz instance by mˇely b´ yt dynamicky vytváˇreny za bˇehu aplikace spolu s generov´ an´ım HTML str´ anek, pˇriˇcemˇz je moˇzné urˇcit jejich rozsah“ (scope) ne” boli kontext ve kterém budou konkrétn´ı instance referencovatelné (je moˇzné urˇcit rozsah v r´ amci jednoho HTTP poˇzadavku, uˇzivatelské relace, v rámci celého bˇehu aplikace atp.). Jednotlivé ˇclenské promˇenné a metody tˇechto objekt˚ u jsou poté za pomoci tzv. bindov´ an´ı moˇzné referencovat pˇr´ımo z XML soubor˚ u jednotliv´ ych Pohled˚ u a na ud´ alosti vyvolané uˇzivatelem (napˇr´ıklad odeslán´ı vyplnˇeného formuláˇre) volat pˇr´ımo metody backing beany. Jak je tedy patrné, architektura JSF je v pˇr´ımé shodˇe s architektonick´ ym ˇ vzorem MVP – dominantn´ı komponentou zde nen´ı Radiˇc ani Presenter, ale je to pr´ avˇe Pohled, kter´ y je pˇri konstrukci HTML stránky vytvoˇren jako prvn´ı a jednotlivé backing beany hraj´ı roli zpˇr´ıstupnˇen´ı Modelu a dodateˇcné prezentaˇcn´ı logiky. Backing beany také mohou pˇr´ımo ovlivˇ novat Pohled, protoˇze jednotlivé komponenty jsou referencovatelné jako klasické Java objekty pˇr´ımo z aplikaˇcn´ıho kódu, coˇz je dalˇs´ı obrovsk´ a v´ yhoda oproti JSP (i kdyˇz trochu navád´ı k vytváˇren´ı r˚ uzn´ ych form´ atovac´ıch zkratek“ v Presenteru, coˇz je principiálnˇe ˇspatnˇe). ” JSF nicménˇe zach´ az´ı jeˇstˇe dál. Nˇekteré TLD knihovny (napˇr. MyFaces nebo Primefaces) obsahuj´ı komponenty, které mohou s backing beanou pˇr´ımo komunikovat pomoc´ı AJAXu. Renderery tˇechto komponent pˇri vytváˇren´ı (z principu

73



Obrázek 5.13: Základn´ı architektura JSF. statického) HTML k´ odu jednoduˇse pˇridaj´ı do stránky JavaScript, kter´ y umoˇzn´ı obousmˇernou komunikaci mezi serverem a webov´ ych prohl´ıˇzeˇcem klienta. Pohled se pak ˇc´ asteˇcnˇe pˇresouv´ a do webového prohl´ıˇzeˇce a programátor˚ um je umoˇznˇeno vytváˇret velice rychle robustn´ı interaktivn´ı webové grafické rozhran´ı, aniˇz by napsali jedinou ˇr´ adku HTML nebo JavaScriptového kódu.

5.4.5

Shrnut´ı

V pˇredchoz´ıch kapitol´ ach jsme se seznámili s architektonick´ ymi postupy uplatniteln´ ymi pˇri n´ avrhu rozs´ ahl´ ych webov´ ych aplikac´ı a distribuovan´ ych informaˇcn´ıch systém˚ u a nejpouˇz´ıvanˇejˇs´ımi frameworky, které tyto postupy implementuj´ı pro platformu postavenou na programovac´ım jazyce Java. Definovali jsme základn´ı architektonické pojmy jako je tˇr´ıvrstv´ a architektura, doménový model a bude ˇzádouc´ı se tˇechto term´ın˚ u a postup˚ u drˇzet i nadále. Nicménˇe dosud jsme se zab´ yvali architekturou, která sledovala jedin´ y c´ıl – poskytnut´ı webového rozhran´ı ˇcitelného a pouˇzitelného pro lidského uˇzivatele. Nyn´ı je tˇreba si poloˇzit ot´ azku, jak mohou s webov´ ymi aplikacemi komunikovat jiné systémy nebo klienti, kteˇr´ı neumoˇzn ˇuj´ı zobrazovat webové stránky nebo je z nˇejakého d˚ uvodu neˇz´ adouc´ı ˇci nepraktické tˇemto klient˚ um webové rozhran´ı poskytovat.

74


5.5

Architektura orientovaná na sluˇzby

Architektura orientovan´ a na sluˇ zby

Architektura orientovan´ a na sluˇzby (Service-oriented architecture, zkratkou SOA) je obecn´ y architektonick´ y vzor zaloˇzen´ y na spolupráci navzájem nezávisl´ ych sluˇzeb [24]. Motivac´ı pro vytvoˇren´ı SOA byla rostouc´ı nároˇcnost na udrˇzován´ı spolupráce r˚ uzn´ ych vnitropodnikov´ ych systém˚ u. D´ıky jejich platformn´ı závislosti a navzájem nekompatibiln´ıch programov´ ych rozhran´ı bylo jen velmi obt´ıˇznˇe zajistit vzájemnou komunikaci tˇechto systém˚ u.

5.5.1

Sluˇ zba v SOA

Sluˇzba je urˇcit´ a ˇc´ ast funkˇcnosti aplikace, která je zpˇr´ıstupnˇená pomoc´ı definovaného rozhran´ı. Kaˇzd´ y jednotliv´ y informaˇcn´ı systém m˚ uˇze poskytovat sadu sluˇzeb svému okol´ı. Za sluˇzbou v SOA stoj´ı vˇetˇsinou pomˇernˇe velké mnoˇzstv´ı programového k´ odu a jakkoliv je princip volán´ı sluˇzeb podobn´ y volán´ı metod, prob´ıhá zde na vyˇsˇs´ı u ´rovni granularity. Rozhran´ı sluˇzeb také nen´ı z´ avislé na implementaci hostitelského systému. Hranice systému se od programov´ ych rozhran´ı posunuj´ı dále od klasického programového API k jasnˇe definovanému rozhran´ı, ve kterém daná sluˇzba data produkuje ˇci pˇrij´ım´ a bez ohledu na to, v jaké technologii je tato sluˇzba implementována. Ve vˇetˇsinˇe pˇr´ıpad˚ u se pak pro komunikaci mezi sluˇzbami d´ıky vysoké prostupnosti s´ıt´ı, platformn´ı nez´ avislosti a pˇrenositelnosti vyuˇz´ıvá HTTP protokol. Pˇrenáˇsen´ y form´ at dat m˚ uˇze b´ yt v podstatˇe libovoln´ y, pokud vˇsichni aktéˇri komunikace tento form´ at podporuj´ı. Nicménˇe zdaleka nejvyuˇz´ıvanˇejˇs´ı jsou formáty postavené (zejména z d˚ uvodu transparentnosti a multiplatformnosti) na bázi XML. Takové sluˇzby se poté zpravidla oznaˇcuj´ı jako sluˇzby webové (Web Services). Takové sluˇzby se pak obvykle jednoznaˇcnˇe identifikuj´ı na základˇe URL adresy.

5.5.2

SOA a tˇ r´ıvrstv´ a architektura

V´ıcevrstv´ a architektura se SOA spolu navzájem velice u ´zce souvis´ı. Jednotlivé systémy jsou obvykle distribuované, v´ıcevrstvé aplikace s prezentaˇcn´ı, aplikaˇcn´ı a perzistentn´ı vrstvou. Nicménˇe veˇskerá funkcionalita takové aplikace je vystavena prostˇrednictv´ım sluˇzeb, nebo je vytvoˇreno rozhran´ı, které tyto sluˇzby navenek poskytuje. V SOA aplikac´ıch se typicky neudrˇzuje stav konverzace s klientem, komunikace obvykle prob´ıh´ a zp˚ usobem dotaz-odpovˇed’. T´ım se nápadnˇe bl´ıˇz´ı jednodu-

75



chému HTTP poˇzadavku s t´ım rozd´ılem, ˇze URL poˇzadavku tentokrát neidentifikuje HTML str´ anku, ale pˇr´ımo konkrétn´ı webovou sluˇzbu. Je tedy zcela jistˇe moˇzné (v pˇr´ıpadˇe pˇredchoz´ı dobré dekompozice problému) rozhran´ı webov´ ych sluˇzeb implementovat za vyuˇzit´ı architektonického vzoru MVC na prezentaˇcn´ı vrstvˇe, kdy jedin´ y rozd´ıl nastane v Pohledu, kter´ y m´ısto zobrazitelného HTML bude generovat XML dokument o pˇredem daném schématu.

5.5.3

V´ yhody SOA

D´ıky bezstavosti a slabému provázán´ı komponent je moˇzné sluˇzby skládat do vˇetˇs´ıch celk˚ u, coˇz ide´ alnˇe splˇ nuje potˇrebu podnik˚ u pokr´ yt a integrovat své vnitropodnikové procesy pomoc´ı informaˇcn´ıho systému. Jednotlivé komponenty je moˇzné pˇri v´ ypadku velice rychle nahradit nebo zavést centráln´ı registr sluˇzeb, kter´ y umoˇzn´ı vyhled´ av´ an´ı aktivn´ıch sluˇzeb a z´ıskán´ı jejich popisu (mechanismus Universal Description, Discovery and Integration, zkratkou UDDI).

5.5.4

Protokoly komunikace v SOA

Jiˇz dˇr´ıve jsme si ˇrekli, ˇze data jsou v SOA architektuˇre obvykle pˇrenáˇseny pomoc´ı XML dokument˚ u. Tyto lze ale dále strukturovat podle pˇredem definovan´ ych schémat a pravidel a vytv´ aˇret komunikaˇcn´ı protokoly, kter´ y jsou na XML formátu zaloˇzené.

Simple Object Access Protocol (SOAP) SOAP je standardizovan´ y protokol pro v´ ymˇenu dat mezi webov´ ymi sluˇzbami [25], kter´ y je obvykle pouˇzit spolu s HTTP protokolem. Zprávu zde reprezentuje jednoduch´ y XML dokument, kter´ y má koˇrenov´ y element Envelope. V této obálce jsou pak uzavˇreny dva elementy Header (hlaviˇcka) a Body (tˇelo). Hlaviˇcka se zpravidla pouˇz´ıv´ a pro pˇrenos pomocn´ ych informac´ı pro zpracován´ı zprávy – napˇr´ıklad autorizaci klienta. V tˇele zprávy se pˇrenáˇs´ı identifikátor volané sluˇzby a parametry zpr´ avy, resp. návratové hodnoty sluˇzby. SOAP pouˇz´ıvá jmenné prostory pro identifikov´ an´ı jednotliv´ ych ˇcást´ı XML zprávy. Je tˇreba zd˚ uraznit, ˇze SOAP protokol je orientov´ an procedurálnˇe a funguje na principu RPC (Remote Procedure Call ). Komunikace m˚ uˇze b´ yt v SOAP stavová.

76



Typick´ y SOAP poˇzadavek se zas´ılá v tˇele HTTP poˇzadavku. Pouˇz´ıvá se pˇritom metoda POST, kter´ a podle [26] dovoluje pos´ılat data v tˇele HTTP poˇzadavku. Nicménˇe ten m˚ uˇze m´ıt i dalˇs´ı metody, které je moˇzné vyuˇz´ıt. Z toho by mˇelo b´ yt patrné, ˇze klasick´ a SOAP komunikace vytváˇr´ı vlastn´ı protokol nad klasick´ ym HTTP a nesnaˇz´ı se jej nijak d´ ale vyuˇz´ıt. HTTP protokol je pˇritom dostateˇcnˇe robustn´ı na to, aby bylo moˇzné jej rozˇs´ıˇrit aˇz do u ´rovnˇe protokolu urˇceného pro webové sluˇzby.

Representational State Transfer (REST) REST je architektura rozhran´ı navrˇzená pro distribuované prostˇred´ı. REST je narozd´ıl od SOAP orientov´ an datovˇe, nikoli procedurálnˇe: rozhran´ı webov´ ych REST sluˇzeb je pouˇzitelné pro jednotn´ y a snadn´ y pˇr´ıstup k tzv. zdroj˚ um (dat˚ um nebo stav˚ um aplikace, pokud je lze popsat konkrétn´ımi daty). Vˇsechny zdroje jsou jednoznaˇcnˇe identifikovatelné pomoc´ı URI a jsou reprezentovány (a pˇrenáˇseny) pomoc´ı r˚ uzn´ ych datov´ ych form´ at˚ u (XML, JSON nebo jiného formátu, kter´ y je moˇzné odeslat pomoc´ı HTTP). REST definuje z´ akladn´ı CRUD(Create-Read-Update-Delete) metody pro manipulaci s tˇemito zdroji (metody mˇen´ı stav zdroje). Tyto metody jsou poté realizovány pomoc´ı odpov´ıdaj´ıc´ıch HTTP metod (GET, POST, PUT, DELETE ). Je tedy patrné, ˇze zat´ımco SOAP pouˇz´ıval HTTP pouze jako jeden z moˇzn´ ych komunikaˇcn´ıch kan´ al˚ u, REST na architektuˇre HTTP pˇr´ımo stav´ı a dále ji rozˇsiˇruje. Narozd´ıl od SOAP neexistuj´ı ˇzádné specifikace kladené na strukturu dat. REST je také koncipov´ an jako bezestavov´ y. Jednotlivé implementace REST rozhran´ı (tedy webové sluˇzby) se poté pˇri splnˇen´ı tˇechto podm´ınek obvykle oznaˇcuj´ı jako RESTful. SOAP definuje vlastn´ı zp˚ usoby autorizace, REST vyuˇz´ıvá HTTP autorizace. Autorizaˇcn´ı tokeny ale mus´ı b´ yt odeslány s kaˇzd´ ym poˇzadavkem, jinak nen´ı splnˇena podm´ınka bezestavosti (webov´ a sluˇzba si o klientovi nesm´ı nic pamatovat“). ”

Srovn´ an´ı REST a SOAP Uˇcinit objektivn´ı srovn´ an´ı tˇechto dvou protokol˚ u nen´ı zcela moˇzné uˇz jen kv˚ uli tomu, ˇze se oba od sebe odliˇsuj´ı samotnou svou koncepc´ı. Aˇc je to dnes populárn´ı názor, REST nen´ı vˇzdy tou spr´ avnou volbou. Sice je implementaˇcnˇe mnohem ménˇe nároˇcn´ y a pouze rozˇsiˇruje standardn´ı HTTP protokol, d´ıky jeho datacentrismu“ ” a omezené mnoˇzinˇe CRUD operac´ı m˚ uˇze b´ yt implementaˇcnˇe pˇr´ıliˇs svazuj´ıc´ı. Také bezestavost komunikace se m˚ uˇze ukázat jako velk´ y problém. Jednoduchost REST

77


Technologické nástroje pro vývoj

rozhran´ı m˚ uˇze b´ yt v´ yhoda a slabina zároveˇ n, vˇzdy záleˇz´ı na pˇr´ıpadu implementace. Obecnˇe lze ˇr´ıci ˇze REST je velmi siln´ y ve spojen´ı s technologiemi jako je AJAX nebo ke vzd´ alené spr´ avˇe datab´ aze (k ˇcemuˇz vyb´ız´ı uˇz jen základn´ı CRUD matice operac´ı). SOAP je robustnˇejˇs´ı a d´ıky stavové komunikaci a proceduráln´ı orientaci je mnohem vhodnˇejˇs´ı k realizaci komunikace mezi dvˇema netriviáln´ımi informaˇcn´ımi systémy, coˇz je ovˇsem vykoupeno potˇrebou mnohem rozsáhlejˇs´ı implementace. Nav´ıc funguje stejnˇe dobˇre i na jin´ ych s´ıt’ov´ ych vrstvách a nen´ı tˇreba se omezovat na pouh´ y HTTP protokol.

5.6

Technologick´ e n´ astroje pro v´ yvoj

Vˇsechny dˇr´ıve zm´ınˇené architektonické vzory je moˇzné implementovat manuálnˇe“ ” a svépomoc´ı spravovat a udrˇzovat jednotlivé vazby mezi doménov´ ymi objekty, mezi vrstvami, komponentami ˇci uˇzit´ ymi frameworky. Nicménˇe takto postavená aplikace je jen obt´ıˇznˇe znovupouˇziteln´ a a nen´ı nutné vlastn´ım kódem ˇreˇsit problémy, které jiˇz nˇekdo vyˇreˇsil pˇred n´ ami. V této kapitole si ukáˇzeme postupy, které vedou ke zjednoduˇsen´ı vlastn´ıho aplikaˇcn´ıho kódu a pˇredstav´ıme si framework, kter´ y tyto postupy implementuje.

5.6.1

Aspektovˇ e orientovan´ e programov´ an´ı

Principem aspektovˇe orientovaného programov´ an´ı (zkratkou AOP) je oddˇelen´ı nˇekter´ ych ˇc´ ast´ı k´ odu, tzv. pr˚ uˇrezových koncern˚ u (cross-cutting concerns), od vlastn´ı aplikaˇcn´ı logiky. Jako pr˚ uˇrezov´ y koncern m˚ uˇzeme definovat takov´ y kód, kter´ y se dot´ yk´ a mnoha r˚ uzn´ ych ˇc´ ast´ı aplikace (pˇr´ıkladem mohou b´ yt napˇr´ıklad transakˇcn´ı a bezpeˇcnostn´ı algoritmy nebo logován´ı) a nen´ı jednoduché ho dekomponovat. AOP se snaˇz´ı tyto koncerny organizovat do tzv. aspekt˚ u. AOP nen´ı n´ ahrada jin´ ych programovac´ıch technik jako je napˇr. objektovˇe orientované programov´ an´ı, slouˇz´ı sp´ıˇse jako architektonick´ y doplnˇek k jiˇz zaveden´ ym technik´ am a uplatn´ı se zejména tam, kde tyto techniky ve snaze dobˇre dekomponovat k´ od jiˇz nestaˇc´ı nebo je jejich uplatnˇen´ı neˇsikovné. Aspekty upravuj´ı chov´ an´ı programu pˇri spouˇstˇen´ı metod, pˇr´ıstupu k atribut˚ um tˇr´ıdy nebo pˇri vyhozen´ı v´ yjimky. Tato m´ısta se oznaˇcuj´ı jako pˇr´ıpojné body (joinpoints). Samotn´ au ´prava chov´ an´ı aplikaˇcn´ıho kódu (realizovaná opˇet jako prost´ y blok k´ odu) se poté oznaˇcuje jako advice. V Javˇe se pak oznaˇcen´ı pˇr´ıpojn´ ych bod˚ u v aplikaˇcn´ım k´ odu obvykle ˇreˇs´ı pomoc´ı anotac´ı.

78


Technologické nástroje pro vývoj

Java Anotace Anotace jsou vlastnˇe jenom textové znaˇcky v kódu o urˇcitém pˇredepsaném formátu (anotac´ı je i notoricky zn´ amé @Override), jejichˇz c´ılem je nˇejakému programovému primitivu pˇriˇradit pˇr´ıznak nebo metadata. Anotace je moˇzné vyhodnocovat pˇri pˇrekladu nebo pˇri samotném bˇehu programu (to ovˇsem vyˇzaduje speciáln´ı classloader ). Ve spojen´ı s AOP mohou identifikovat ta programová primitiva, kter´ ym se má pˇriˇradit aspekt (ten je identifikovan´ y samotnou anotac´ı). I bez vyuˇzit´ı AOP je moˇzné vytv´ aˇret anotace vlastn´ı pro u ´ˇcely napˇr. dokumentace, statického generován´ı k´ odu atp. Anotac´ım je moˇzné vytv´ aˇret parametry a tˇem pˇri pouˇzit´ı anotace pˇredávat hodnoty, coˇz jejich moˇznosti d´ ale rozˇsiˇruje (je moˇzné tyto hodnoty pˇredávat aspekt˚ um, které jsou anotacemi identifikov´ any).

5.6.2

Spring Framework

C´ılem této kapitoly je pˇredstavit framework, kter´ y umoˇzn ˇuje spojit vˇetˇsinu uveden´ ych technologi´ı a postup˚ u do jednoho kompaktn´ıho celku – Spring Framework. Tento velice popul´ arn´ı modul´ arn´ı aplikaˇcn´ı framework umoˇzn ˇuje velice rychle vytváˇret rozs´ ahlé aplikace za vyuˇzit´ı principu Inversion of Control, kdy je framework za bˇehu aplikace zodpovˇedn´ y za vytvoˇren´ı a provázán´ı objekt˚ u implementované aplikace a na program´ atorovi z´ avis´ı pouze samotná implementace aplikaˇcn´ı logiky [27]. To je moˇzné d´ıky pokroˇcil´ ym programovac´ım technikám, jako je napˇr´ıklad reflexe. Nicménˇe hlavn´ı ˇc´ ast Spring Frameworku stoj´ı právˇe na anotac´ıch a AOP. Jednotlivé komponenty aplikaˇcn´ı logiky, jako jsou napˇr. POJO objekty, se doslova zaregistruj´ı“ do aplikaˇcn´ıho frameworku a tento s tˇemito komponentami ” dále manipuluje. Je moˇzné si pˇredstavit napˇr´ıklad implementaci návrhového vzoru MVC, kdy program´ ator implementuje vˇsechny tˇri komponenty Pohledu, Modelu a ˇ ce, aniˇz by tyto na sebe mˇely navzájem jakoukoliv programovou vazbu nebo Radiˇ dˇedily nˇejakou generickou implementaci. Aplikaˇcn´ı framework se pak za bˇehu aplikace postar´ a o jejich vz´ ajemné provázán´ı. Za vyuˇzit´ı reflexe a AOP Spring Framework d´ ale injektuje vlastn´ı aplikaˇcn´ı kód (neboli aspekty) do zdrojového kódu vytváˇrené aplikace, a to bud’ na základˇe XML konfigurace, nebo pomoc´ı jiˇz zm´ınˇen´ ych anotac´ı. Mezi ˇc´ asti Spring Frameworku patˇr´ı komponenty pro ORM mapován´ı, testovac´ı nástroje, integraci uˇzivatelsk´ ych komponent, modulárnˇe orientovan´ y v´ yvoj, webové aplikace a webové sluˇzby, bezpeˇcnost na základˇe rol´ı a ˇrada dalˇs´ıch. Podrobn´ y popis tˇechto komponent jde dalece nad rámec této práce a v pˇr´ıpadˇe nutnosti budou jednotlivé komponenty v dalˇs´ım textu struˇcnˇe popsány.

79


5.7

Shrnut´ı

Shrnut´ı

Nyn´ı jiˇz m´ ame obecn´ y pˇrehled o tom, jaké architektonické vzory m˚ uˇzeme vyuˇz´ıt pro programov´ an´ı rozs´ ahl´ ych distribuovan´ ych systém˚ u a známe ˇsiroce vyuˇz´ıvané technologie stavˇej´ıc´ı na Java platformˇe, které tyto postupy implementuj´ı. V dalˇs´ı kapitole si uk´ aˇzeme konkrétn´ı systém, kter´ y byl implementován s c´ılem pokr´ yt poˇzadavky na systém spr´ avy rezervac´ı, které byly uvedeny v Kapitole 4.

80

6 RAT - Reserve A Thing! V této kapitole se sezn´ am´ıme s informaˇcn´ım systémem RAT a detailnˇeji rozebereme implementaˇcn´ı detaily vˇsech jeho ˇcást´ı zejména s ohledem na obecné postupy a technologie, které byly uvedeny v Kap. 5. Na závˇer se seznám´ıme s uskuteˇcnˇen´ ym testov´ an´ım a nasazen´ım tohoto systému.

6.1

Informaˇ cn´ı syst´ em RAT

RAT je n´ azev informaˇcn´ıho systému, kter´ y byl implementován za c´ılem pokr´ yt poˇzadavky na systém spr´ avy rezervac´ı definované v Kap. 4. Sestává se z centráln´ıho serveru RatServer a mobiln´ı aplikace RatDroid, která byla implementována pro mobiln´ı platformu Android. Nad rámec specifikace byla vytvoˇrena i aplikace pro platformu Windows Phone s n´ azvem RatSharp.

6.1.1

Z´ akladn´ı rozvrˇ zen´ı syst´ emu

Jednotlivé mobiln´ı aplikace hraj´ı roli klient˚ u centráln´ıho serveru. Server ve shodˇe se specifikac´ı poskytuje také webové rozhran´ı. Jednotlivé klientské mobiln´ı aplikace vyuˇz´ıvaj´ı webov´ ych sluˇzeb, které centráln´ı server poskytuje (Obr. 6.1).

Obrázek 6.1: Informaˇcn´ı systém RAT. 81

RAT - Reserve A Thing!

6.2 6.2.1

RAT server

RAT server Z´ akladn´ı architektura serveru

Na Obr´ azku 6.2 je zn´ azornˇeno zjednoduˇsené schéma serverové aplikace, vˇcetnˇe rozpisu nejvˇetˇs´ıch uˇzit´ ych framework˚ u. V dalˇs´ım textu se budeme podrobnˇe vˇenovat jednotliv´ ym ˇc´ astem systému, pˇriˇrazovat jim jednotlivé Java bal´ıky z reálné implementace a zaob´ırat se kontextem komponent v˚ uˇci zbytku systému (rozkreslit celou serverovou aplikaci do jednoho schématu nen´ı vzhledem k jej´ı obsáhlosti dost dobˇre moˇzné).

Obrázek 6.2: Architektura a pouˇzité technologie. Architektura serverové ˇc´ asti je datacentrická a servisovˇe orientovaná podle vzoru Operation Script (viz Kap. 5). Doménov´ y model tvoˇr´ı pouze POJO objekty bez aplikaˇcn´ı logiky, kter´ a je soustˇredˇena v servisn´ı vrstvˇe. V´ yhodou tohoto pˇr´ıstupu je zejména jednoduch´ a implementace SOA architektury, která s vnitˇrn´ı servisn´ı vrstvou nepˇr´ımo souvis´ı.

82


6.2.2

RAT server


Základ celé architektury centr´ aln´ıho serveru je sada doménov´ ych POJO objekt˚ u, um´ıstˇen´ ych v bal´ıku beans. Objekty jsou vˇcetnˇe vzájemn´ ych vazeb znázornˇeny na Diagramu 6.1.

Diagram 6.1: Doménov´ y diagram systému. Následuje popis jednotliv´ ych doménov´ ych objekt˚ u a jejich vazeb.

ObjectClass POJO objekt reprezentuj´ıc´ı tˇr´ıdu objekt˚ u. Kromˇe specifikac´ı jiˇz pˇredem urˇcen´ ych atribut˚ u (name a description) pˇridává také binárn´ı pˇr´ıznaky pickable a returnable, které definuj´ı nutnost potvrzen´ı vyzvednut´ı a vrácen´ı objekt˚ u, které patˇr´ı do této tˇr´ıdy.

83


RAT server

Object Reprezentuje pˇredmˇet rezervace a v´ yp˚ ujˇcky.

User Objekt reflektuj´ıc´ı uˇzivatele systému. K atribut˚ um, které pˇr´ımo vypl´ yvaj´ı z poˇzadavk˚ u na systém, jsou jeˇstˇe nav´ıc definovány atributy Role a Implementor. Budeme se jimi zab´ yvat v dalˇs´ım textu.

Reservation Reprezentace rezervace objektu. Jej´ım c´ılem je svázat uˇzivatele, objekt a ˇcasové periody n´ aleˇzej´ıc´ı této rezervaci do jednoho logického celku.

Period ˇ Casov´ a perioda rezervace. Definuje ˇcasové rozpˇet´ı rezervace (atributy fromDate a toDate) a platnost rezervace (atribut valid). Za zm´ınku vˇsak stoj´ı zejména atributy ud´ avac´ıc´ı ˇzivotn´ı cyklus“ periody rezervace – pickAction a returnAction. ” Datov´ y typ pickAction atributu je v´ yˇctov´ y enum PickAction se ˇcleny PICKED, NOT_PICKED a NOT_PICKABLE. Tento atribut je pˇr´ımo svázan´ y s objektem rezervace – pokud je objekt nastaven´ y jako nepotvrzovan´ y pˇri vyzvednut´ı, jsou vˇsechny periody takové rezervace automaticky nastaveny jako NOT_PICKABLE, v opaˇcném pˇr´ıpadˇe pak na NOT_PICKED. Systém tak m˚ uˇze od sebe odliˇsit jednotlivé poˇzadované akce pro rezervace a podle toho ˇr´ıdit dalˇs´ı chován´ı. Pˇri vyzvednut´ı se atribut pˇreklop´ı do stavu PICKED. Obdobná situace plat´ı i pro atribut returnAction.

6.2.3

Datov´ a vrstva

V projektu je plnˇe vyuˇzito moˇznost´ı relaˇcn´ıch databáz´ı a ORM mapován´ı. Jako mapovac´ı framework byl pouˇzit Hibernate. Na Digramu 6.2 je znázornˇena základn´ı struktura relaˇcn´ı datab´ aze, vˇcetnˇe vzájemn´ ych vazeb jednotliv´ ych databázov´ ych entit (prim´ arn´ı kl´ıˇce tabulek jsou podtrˇzeny a znaˇceny tuˇcn´ ym p´ısmem, povinnˇe vyplnitelné poloˇzky zaˇc´ınaj´ı ˇcernˇe vybarven´ ym koleˇckem).

84


RAT server

Diagram 6.2: ER diagram databáze. Doménové POJO objekty jsou mapovány pomoc´ı Hibernate na koresponduj´ıc´ı databázové entity. Kaˇzd´ y doménov´ y objekt má k sobˇe vytvoˇren odpov´ıdaj´ıc´ı mapovac´ı hbm.xml soubor, ve kterém jsou mapovac´ı direktivy vˇcetnˇe vzájemn´ ych entitn´ıch vazeb.

Spring ORM Spring ORM je jak´ asi mezivrstva mezi frameworkem Hibernate a zbytkem aplikace. Umoˇzn ˇuje zejména konfiguraci Hibernate napojit pˇr´ımo na konfiguraˇcn´ı soubory Spring Frameworku, d´ ale do nˇej zavád´ı nˇekteré své vlastn´ı implementace jako je sessionFactory a transakˇcn´ı manaˇzer (d´ıky tomu bude napˇr´ıklad moˇzné ˇr´ıdit transakce pomoc´ı anotac´ı pˇr´ımo z aplikaˇcn´ıho kódu). Pomáhá tedy bezproblémovˇe integrovat Hibernate se zbytkem aplikace. Veˇskerá konfigurace persistentn´ı vrstvy je v XML souboru persistence.xml a aˇz na v´ yjimky (viz dále) nijak nevyboˇcuje ze standardn´ı konfigurace.

GenericDAO Jiˇz dˇr´ıve jsme mluvili o n´ avrhovém vzoru Data Gateway a DAO objektech. V RAT systému je pro kaˇzd´ y doménov´ y objekt vytvoˇren odpov´ıdaj´ıc´ı DAO objekt, kter´ y

85


RAT server

oddˇeluje aplikaˇcn´ı vrstvu aplikace od kódu závislého na databázovém systému (respektive na Hibernate frameworku). Nicménˇe protoˇze DAO objekty obvykle zajiˇst’uj´ı pouze CRUD operace a spouˇstˇen´ı nˇekter´ ych specifick´ ych dotaz˚ u, je kv˚ uli snaze o minimalizaci k´ odu vytvoˇrena hierarchická struktura vyuˇz´ıvaj´ıc´ı genericity, dˇediˇcnosti a aspektového programován´ı. Na Diagramu 6.3 je vidˇet z´ akladn´ı struktura DAO vrstvy. Rozhran´ı kaˇzdého DAO objektu mus´ı dˇedit od GenericDAO rozhran´ı. To definuje základn´ı CRUD operace, které lze prov´ adˇet s objekty. Rozhran´ı specifické pro doménov´ y objekt poté m˚ uˇze tyto z´ akladn´ı operace rozˇs´ıˇrit o dalˇs´ı metody (v naˇsem pˇr´ıpadˇe je to rozhran´ı ObjectClassDAO, které umoˇzn ˇuje nav´ıc vyhledat tˇr´ıdu objektu podle jej´ıho jména). Takové rozhran´ı budeme dále naz´ yvat jako rozˇsiˇruj´ıc´ı rozhran´ı. Konkrétn´ı implementace generického DAO rozhran´ı (GenericDAOHibernateImpl) jiˇz má odkaz na Hibernate sessionFactory (ta jiˇz umoˇzn ˇuje pˇr´ım´ y objektov´ y pˇr´ıstup do relaˇcn´ı datab´ aze).

Diagram 6.3: Diagram tˇr´ıd GenericDAO. Nicménˇe z diagramu je patrné, ˇze chyb´ı tˇr´ıda implementuj´ıc´ı rozˇsiˇruj´ıc´ı rozhran´ı, která by tak mohla pˇrekr´ yt metodu s patˇriˇcn´ ym HQL dotazem pro z´ıskán´ı tˇr´ıdy objektu podle jej´ıho jména. Jistˇe bychom ji mohli vytvoˇrit programovˇe, nicménˇe pˇresnˇe tomu jsme se chtˇeli hned zpoˇcátku vyhnout (a v programu ˇzádné takové tˇr´ıdy skuteˇcnˇe nenajdeme). Lepˇs´ı moˇznost je vyuˇz´ıt zn´ azornˇen´ y FinderExecutor, jehoˇz implementace za pouˇzit´ı malé knihovny v bal´ıku genericdao umoˇzn´ı HQL dotazy naˇc´ıtat pˇr´ımo

86


RAT server

z Hibernate frameworku na z´ akladˇe názvu mapované entity (to se dˇeje v v metodˇe executeFinder()). HQL dotazy následnˇe staˇc´ı pojmenovat stejnˇe jako je název metody rozˇsiˇruj´ıc´ıho rozhran´ı, která má dan´ y dotaz volat, a um´ıstit je do mapovac´ıho XML souboru entity. Samotná implementace je poté d´ıky aspektovému programov´ an´ı doslova poskl´ ad´ ana“ pˇr´ımo za bˇehu programu. Novˇe vzniknuvˇs´ı ” proxy DAO dˇed´ı od GenericDAOHibernate a implementuje ObjectClassDAO, dotazy jsou poté naˇc´ıt´ any na z´ akladˇe aspektu pˇr´ımo z hbm.xml soubor˚ u. Injektov´ an´ı rozˇsiˇruj´ıc´ıch rozhran´ı na generickou DAO implementaci je souˇcást´ı konfiguraˇcn´ıch soubor˚ u persistence.xml a genericdao.xml. Vˇsechna DAO rozˇsiˇruj´ıc´ı rozhran´ı a generické implementace jsou souˇcást´ı bal´ıku dataaccess.dao.

Hibernate Search Jedn´ım z poˇzadavk˚ u na systém bylo i zajiˇstˇen´ı vyhledáván´ı v datech nˇekter´ ych entit na z´ akladˇe jejich atribut˚ u. To m˚ uˇze opˇet velmi jednoduˇse zajistit framework Hibernate, kter´ y implementuje nepˇr´ımé indexované vyhledáván´ı v databázi (ˇc´ımˇz se liˇs´ı od vyhled´ av´ an´ı pomoc´ı SQL nebo HQL). Nejenˇze je toto vyhledáván´ı mnohem rychlejˇs´ı, protoˇze funguje na principu velmi sofistikované hashovac´ı tabulky a nemus´ı m´ıt pˇr´ım´ y pˇr´ıstup do databáze, je také flexibilnˇejˇs´ı, protoˇze programátor má moˇznost jeho implementaci programovˇe ovlivnit. Hibernate sám zajist´ı správu indexov´ an´ı pˇri jakékoliv zmˇenˇe v databázi (indexy jsou mimo jiné vytvoˇreny pˇri kaˇzdém startu aplikace). Jedin´ y poˇzadavek kladen´ y na stranu programátora je vloˇzen´ı anotac´ı do patˇriˇcn´ ych POJO objekt˚ u. V aplikaci je poté vytvoˇrena SearchService, která vyhledáván´ı zprostˇredkovává. Ta sice obch´ az´ı standardn´ı DAO mechanismus a pˇristupuje pˇr´ımo k Hibernate frameworku, nicménˇe sv´ ym urˇcen´ım patˇr´ı do aplikaˇcn´ı vrstvy.

Nastaven´ı aplikace Jedn´ım z poˇzadavk˚ u na systém je i moˇznost konfigurace nˇekter´ ych ˇcasov´ ych primitiv, jako je napˇr´ıklad minim´ aln´ı a maximáln´ı délka periody rezervace atp. Tyto direktivy jsou uloˇzeny ve formˇe Java property souboru pod jménem rat.properties. Pro jejich naˇc´ıt´ an´ı nebylo tˇreba nic manuálnˇe programovat, pouze staˇcilo nakonfigurovat Spring framework tak, aby tento soubor naˇcetl pˇri startu aplikace.

87


6.2.4

RAT server

Servisn´ı vrstva

ˇ ast oznaˇcená Na Obr´ azku 6.3 je zn´ azornˇeno jednoduché scéma servisn´ı vrstvy. C´ jako DataFlowServices je pˇr´ım´ ym pokraˇcován´ım DAO objekt˚ u a poskytuje tedy rozhran´ı do datab´ aze, nicménˇe tentokrát je moˇzné v kaˇzdé servisn´ı tˇr´ıdˇe referencovat jak´ ykoliv DAO objekt z datové vrstvy. SearchService poté pˇristupuje pˇr´ımo k sessionFactory ze Spring ORM.

Obrázek 6.3: Schéma servisn´ı vrstvy.

DataFlowServices Na Diagramu 6.4 je moˇzné vidˇet základn´ı architekturu té ˇcásti servisn´ı vrstvy, která kontroluje pˇr´ıstup do datab´ aze. Základn´ı implementace GenericDataServiceImpl váˇze b´ azov´ y DAO objekt na servisn´ı vrstvu a implementuje základn´ı rozhran´ı. Rozˇsiˇruj´ıc´ı rozhran´ı (v diagramu je to ObjectClassService) poté umoˇzn ˇuje definovat dalˇs´ı rozˇsiˇruj´ıc´ı metody a funkce.

Diagram 6.4: Diagram tˇr´ıd servisn´ı vrstvy.

88


RAT server

Servisn´ı vrstva je z ostatn´ıch ˇc´ ast´ı aplikace referencována pˇres tyto rozˇsiˇruj´ıc´ı rozhran´ı. D´ıky tomu je moˇzné velmi jednoduˇse tzv. mockovat servisn´ı vrstvu a t´ım usnadnit testov´ an´ı nadˇrazen´ ych vrstev. Vˇsechny jednotlivé servisn´ı implementace jsou zaregistrov´ any do Spring aplikaˇcn´ıho kontextu pˇres anotaci @Service a je moˇzné pouˇz´ıt pokroˇcilé metody referencován´ı jako je napˇr´ıklad autowiring. Servisn´ı vrstva pak zajiˇst’uje i transakˇcn´ı ˇr´ızen´ı pˇr´ıstupu do databáze (pˇres anotaci metod @Transactional), poˇzadavky specifikace na odstraˇ nován´ı objekt˚ u z datab´ aze (to obvykle zajiˇst’uje Hibernate pˇres cascade delete, bohuˇzel tuto techniku nen´ı moˇzné vˇzdy pouˇz´ıt) a zejména v sobˇe koncentruje veˇskerou aplikaˇcn´ı logiku souvisej´ıc´ı se spr´ avou rezervac´ı, jejich vyzvedáván´ı, vracen´ı atd. Podrobn´ y popis je moˇzné naj´ıt v programové dokumentaci. Kompletn´ı implementace je v bal´ıku dataaccess.service.

Settings Service ´ Ukolem je zpˇr´ıstupnit konfiguraˇcn´ı direktivy správy rezervac´ı pro ostatn´ı ˇcásti systému. Spring Framework s´ am injektuje pˇri vytváˇren´ı instance potˇrebné parametry pˇr´ımo z konfiguraˇcn´ıho souboru a tyto jsou pak pˇr´ıstupné pˇres klasické gettery. V této servise jsou také inicializovány pˇrednastavené hodnoty, které jsou pouˇzity v pˇr´ıpadˇe, kdy data z konfiguraˇcn´ıho souboru neodpov´ıdaj´ı oˇcekávanému formátu.

6.2.5

Spring Security

Souˇcást´ı specifikace jsou i poˇzadavky na uˇzivatelské role systému a integraci s celouniverzitn´ım kontem Orion. Uˇzivatel se m˚ uˇze autorizovat bud’ oproti intern´ı databázi, kde bude uloˇzeno heslo v hashované podobˇe, nebo je umoˇznˇeno pˇrihláˇsen´ı proti celouniverzitn´ımu systému IS/STAG pomoc´ı protokolu Kerberos – v tomto pˇr´ıpadˇe naopak nesm´ı b´ yt heslo v intern´ı databázi uloˇzeno. Pro implementaci byl pouˇzit modul Spring Security. Spring Security je souˇc´ ast Spring Frameworku, která umoˇzn ˇuje pokroˇcilou správu autorizace a uˇzivatelsk´ ych rol´ı. Pro kaˇzdého uˇzivatele, kter´ y byl u ´spˇeˇsnˇe ovˇeˇren, vytvoˇr´ı unik´ atn´ı identifikátor (sessionID), kter´ y je klientovi uˇzivatele zaslán jako reakce na pokus o pˇrihláˇsen´ı. Klienti se poté následnˇe ovˇeˇruj´ı pomoc´ı tohoto unik´ atn´ıho kl´ıˇce, bez zad´ an´ı jména a hesla. Framework také ˇreˇs´ı správu rol´ı (viz d´ ale) a um´ı na z´ akladˇe pˇr´ıchoz´ıho sessionID umoˇznit nebo zakázat pˇr´ıstup do systému, a to na tˇrech u ´rovn´ıch – na u ´rovni volán´ı metod, na u ´rovni URL poˇzadavku a na u ´rovni vykreslovan´ ych HTML stránek pomoc´ı tzv. security tag˚ u (viz dále).

89


RAT server

´ Upln´ y popis tohoto modulu jde dalece nad rámec této práce. Pro naˇse u ´ˇcely postaˇc´ı vˇedˇet, ˇze Spring Security umoˇzn ˇuje programovˇe vytvoˇrit a zaregistrovat vlastn´ı autorizaˇcn´ı mechanismy (Security Providers). Framework poté ovˇeˇruje pˇr´ıchoz´ı autorizaˇcn´ı data pomoc´ı zaregistrovan´ ych autorizaˇcn´ıch poskytovatel˚ u a teprve v okamˇziku, kdy nˇekter´ y z tˇechto poskytovatel˚ uu ´spˇeˇsnˇe ovˇeˇr´ı klientskou stranu, vygeneneruje framework pˇr´ısluˇsné sessionId a u ´spˇeˇsnˇe autorizuje uˇzivatele. Jak ukazuje Obr. 6.4, bylo tˇechto vlastnost´ı vyuˇzito pro implementaci poˇzadavk˚ u na autorizaci uˇzivatel˚ u.

Obrázek 6.4: Základn´ı schéma autorizace.

Security Implementor Jak jiˇz bylo zm´ınˇeno v dˇr´ıvˇejˇs´ım textu, existuj´ı dva diametrálnˇe odliˇsné zp˚ usoby autorizace. Obˇe jsou pevnˇe sv´ azané s uˇzivatelsk´ ym u ´ˇctem (je moˇzné mezi nimi volit pˇri vytv´ aˇren´ı tohoto u ´ˇctu). Abychom jednotlivé typy u ´ˇct˚ u od sebe oddˇelili, vznikl jiˇz ve f´ azi n´ avrhu pro doménov´ y objekt uˇzivatele nov´ y atribut – Implementor. To je vlastnˇe jen textov´ y ˇretˇezec, kter´ y umoˇzn ˇuje mapovat u ´ˇcet s autorizaˇcn´ım poskytovatelem. Kaˇzd´ y zaregistrovan´ y autorizaˇcn´ı poskytovatel poskytuje sv˚ uj unikátn´ı Implementor idenfifik´ ator a proto je tedy oznaˇcen´ı atributu v databázi jako textov´ y ˇretˇezec nepˇresné – ve skuteˇcnosti je tento ˇretˇezec jedn´ım z dynamického v´ yˇctu identifik´ ator˚ u zaregistrovan´ ych autorizaˇcn´ıch poskytovatel˚ u (viz dále).

90


RAT server

Implementace autorizaˇ cn´ıch poskytovatel˚ u Na Diagramu 6.5 je zn´ azornˇena základn´ı implementace autorizaˇcn´ıch poskytovatel˚ u. Registrovat vlastn´ı autorizaˇcm´ı mechanismus do Spring Security frameworku je moˇzné bud’ jako AuthenticationProvider, kter´ y má k dispozici cel´ y autorizaˇcn´ı kontext pˇrihlaˇsov´ an´ı (jméno i heslo), nebo jako UserDetailsService, která funguje v r´ amci zm´ınˇeného AuthenticationProvideru. Ta má k dispozici pouze jméno uˇzivatele a jej´ım u ´kolem je bud’ vrátit instanci tˇr´ıdy UserDetails (která reprezentuje pˇrihl´ aˇseného uˇzivatele a mus´ı do n´ı b´ yt uloˇzeno vˇsechno podstatné vˇcetnˇe hesla a role), nebo vyhodit v´ yjimku UserNotFoundException.

Diagram 6.5: Diagram tˇr´ıd autorizaˇcn´ıch poskytovatel˚ u. Kaˇzd´ y autorizaˇcn´ı poskytovatel mus´ı implementovat metodu getImplementor(). Ta vrac´ı instanci POJO tˇr´ıdy LoginImplementor, ve které jsou vˇsechny d˚ uleˇzité u ´daje o poskytovateli. V aplikaci existuje veˇrejn´ y statick´ y seznam vˇsech takov´ ych objekt˚ u. Do nˇej se jednotliv´ı poskytovatelé registruj´ı hned po svém instancován´ı v rámci metody init() (anotace @PostConstruct). Poskytovatel autorizace oproti intern´ı databázi implementuje rozhran´ı UserDetailsService a funguje v r´ amci pˇrednastaveného autorizaˇcn´ıho poskytovatele integrovaného ve Spring Security. Jak je vidˇet, vlastn´ı implementace má referenci na UserService a tak m˚ uˇze libovolnˇe komunikovat s datovou vrstvou. Jej´ım jedin´ ym u ´kolem je tedy pouze naj´ıt uˇzivatele v databázi podle jeho pˇrihlaˇsovac´ıho jména, ovˇeˇren´ı hesla provede Spring Security.

91


RAT server

Zaj´ımavˇejˇs´ı situace nast´ av´ a v pˇr´ıpadˇe autorizace oproti IS/STAG. Zde je jiˇz nutné znát cel´ y pˇrihlaˇsovac´ı kontext, protoˇze jméno a heslo se mus´ı odeslat na vzdálen´ y autorizaˇcn´ı server. Proto poskytovatel implementuje rozhran´ı AuthenticationProvider. Jak je patrné, i ten m´ a referenci na servisn´ı vrstvu zpˇr´ıstupˇ nuj´ıc´ı intern´ı seznam uˇzivatel˚ u – to je kv˚ uli mapován´ı mezi uloˇzen´ ym záznamem a autorizaˇcn´ım poskytovatelem. Kaˇzd´ y poskytovatel se nejprve pokus´ı vyhledat pˇr´ısluˇsného uˇzivatele v datab´ azi, a pokud nesed´ı Implementor uˇzivatele se záznamem o aktuálnˇe spuˇstˇeném poskytovateli, je autorizace rovnou odm´ıtnuta (uˇzivatel má jiného poskytovatele autorizace). D˚ uvod, proˇc jsou ve tˇr´ıdˇe tohoto poskytovatele ˇclenské promˇenné pˇr´ıstupné pˇres settery je prost´ y – pˇri registraci m˚ uˇzeme zaregistrovat tohoto poskytovatele v´ıcekr´ at a injektovat mu jiné konfiguraˇcn´ı soubory, název a dalˇs´ı parametry. Tento poskytovatel je tedy obecnˇe pouˇziteln´ y pro jak´ ykoliv Kerberos ovˇeˇrovac´ı protokol a lze tedy napˇr´ıklad vytvoˇrit autorizaci uˇzivatele oproti systém˚ um jin´ ych univerzit pouhou registrac´ı v XML konfiguraˇcn´ım souboru, jak ukazuje tento v´ ypis:

<property name="jaasConfig" value="jaas.conf" /> <property name="krb5Config" value="krb5.conf" /> <property name="jaasContextName" value="WSKerberosAuth" /> <property name="implementor" value="ZCU-KERBEROS" /> <property name="localPasswordRequired" value="false" />

Uˇ zivatelsk´ e role V systému jsou definov´ any pomoc´ı v´ yˇctového typu role ADMIN, MASTER a USER. Pˇrid´ av´ an´ı nov´ ych rol´ı nen´ı bez rozsáhl´ ych programov´ ych zmˇen moˇzné. Kaˇzd´ y uˇzivatel m´ a v datab´ azi uloˇzenu svoji roli v systému. Tato role je pˇri u ´spˇeˇsné autorizaci uloˇzena do aplikaˇcn´ıho kontextu Spring Frameworku v rámci jiˇz zmin ˇované instance tˇr´ıdy UserDetails. Autorizace pˇr´ıstupu na základˇe rol´ı je plnˇe automatick´ a a je ˇr´ızena pouze za pomoci anotac´ı, konfiguraˇcn´ıch soubor˚ u a security tag˚ u. Na z´ akladˇe anotac´ı je zabezpeˇcen napˇr´ıklad pˇr´ıstup k nˇekter´ ym metodám servisn´ı vrstvy, které edituj´ı databázové poloˇzky (napˇr. role USER nen´ı oprávnˇena mazat objekty). Implementace vˇsech zm´ınˇen´ ych bezpeˇcnostn´ıch mechanism˚ u se nacház´ı v v bal´ıku security.

92


6.2.6

RAT server


Aplikaˇcn´ı vrstva se skl´ ad´ a ze dvou velk´ ych komponent – JSF pro webové rozhran´ı a Spring MVC pro webové REST sluˇzby, které budou poskytované pro mobiln´ı aplikace. Jak ukazuje schéma zn´ azornˇené na Obr. 6.5, aplikace rozhoduje na základˇe URL pˇr´ıchoz´ıho poˇzadavku o tom, kter´ y framework bude dále HTTP poˇzadavek obsluhovat.

Obrázek 6.5: Základn´ı schéma filtrován´ı poˇzadavk˚ u.

6.2.7

Webov´ e rozhran´ı

Architektura pouˇzit´ı JSF nijak nevyboˇcuje z jiˇz dˇr´ıve rozebran´ ych postup˚ u. Pro vˇetˇsinu webov´ ych komponent a celkového grafického rozvrˇzen´ı a stylu webového rozhran´ı je vyuˇzita zejména TLD knihovna PrimeFaces. V programovém Java bal´ıku managed je veˇskeré programové vybaven´ı aplikace souvisej´ıc´ı s JSF. Bal´ık se d´ ale dˇel´ı na dalˇs´ı sadu podbal´ık˚ u: - managed.bean – vˇsechny backing beany pro Faces stránky. - managed.converter – dodateˇcné konvertory, které transformuj´ı data z backing beans do podoby, která je zobrazitelná v TLD komponentách. - managed.locale – utility, které zpˇr´ıstupˇ nuj´ı lokalizované ˇretˇezce JSF do programové ˇc´ asti. - managed.validator – dodateˇcné validátory formuláˇr˚ u, které nelze kontrolovat pˇr´ımo pomoc´ı komponent TLD knihoven.

93


RAT server

Vyuˇz´ıv´ a se integrovan´ y ˇsablonovac´ı systém Facelets. Vˇsechny Faces stránky jsou um´ıstˇeny mimo zdrojové k´ ody ve sloˇzce WebContent. S ohledem na mapován´ı Spring Security je rozdˇelen´ı n´ asleduj´ıc´ı: - */* – str´ anky, na které mohou pˇristupovat uˇzivatelé i bez autorizace (iCal rozhran´ı). - */templates/* – ˇsablony, ze kter´ ych se skládá webové rozhran´ı systému. - */login/* – str´ anky urˇcené pro pˇrihláˇsen´ı. - */secured/* – str´ anky zobrazitelné pro vˇsechny pˇrihláˇsené role. - */admin/* – str´ anky zobrazitelné pouze pro roli Administr´ ator.

Integrace JSF – Spring Bohuˇzel, Spring Framework nemá plnou podporu pro integraci s JSF (a naopak). To pˇrin´ aˇs´ı nˇekteré problémy, které bylo tˇreba uspokojivˇe vyˇreˇsit. Spring Security poskytuje moˇznost vytváˇret security tagy, které vytváˇrej´ı restrikce na vykreslov´ an´ı jejich vnoˇren´ ych element˚ u (neboli JSF komponent) na základˇe role pˇrihl´ aˇseného uˇzivatele. To velmi dobˇre funguje v prostˇred´ı JSP servlet˚ u. V JSF ale nexistuje integrovan´ a Spring Security TLD knihovna, a je tedy nutné ji vytvoˇrit a naimportovat ruˇcnˇe. Knihovna je um´ıstˇena v WebContent/WEB-INF pod n´ azvem springsecurity.taglib.xml. Vˇetˇs´ım problémem je vˇsak samotné spojen´ı backing beans s aplikaˇcn´ım kontextem Spring Frameworku (WebApplicationContext). JFS má vlastn´ı programov´ y kontext (FacesContext) a vlastn´ı správu komponent. Lze tedy zjednoduˇsenˇe ˇr´ıci, ˇze JSF komponenty (valid´ atory, konvertory atp.) nevid´ı“ servisn´ı vrstvu, která je ” v aplikaˇcn´ım kontextu Springu. Jedno z moˇzn´ ych ˇreˇsen´ı je vyjmout vˇsechny komponenty z JSF kontextu a spravovat je Spring Frameworkem. Toto ˇreˇsen´ı funguje, ale má mnoho omezen´ı – nen´ı moˇzné pouˇz´ıvat ˇz´ adné JSF specifické anotace, tedy nelze napˇr´ıklad dost dobˇre urˇcovat scope nebo jednoduˇse injektovat parametry z URL. Spring má sice vlastn´ı sadu anotac´ı pro scope, ty vˇsak nejsou plnˇe kompatibiln´ı s JSF (a nˇekteré zcela chyb´ı). Jednoduˇsˇs´ı ˇreˇsen´ı je vytvoˇrit programov´ y m˚ ustek mezi oba frameworky. V bal´ıku managed.beans je um´ıstˇena statická tˇr´ıda SpringBeanFactory, která umoˇzn ˇuje z´ıskat reference na libovolnou instanci tˇr´ıdy z aplikaˇcn´ıho kontextu Spring Frameworku, kter´ a byla zaregistrov´ ana jako @Component, @Service nebo @Controller.

94


RAT server

Komponenty je moˇzné z´ıskat na základˇe zaregistrovaného jména nebo rozhran´ı. Spojen´ı JSF a servisn´ı vrstvy je ukázáno na Obr. 6.6.

Obrázek 6.6: Spojen´ı Spring a JSF. JSF komponenty mohou b´ yt v závislosti na svém scope doˇcasnˇe serializovány. Napˇr´ıklad kalend´ aˇre vyˇzaduj´ı AJAX komunikaci mezi klientem a serverem. Proto jsou pˇr´ısluˇsné managed beans anotovány jako @ViewScoped (instance je udrˇzována dokud uˇzivatel neopust´ı str´ anku), aby byl vˇzdy zachován jejich stav vˇcetnˇe Modelu. Je nutné oznaˇcit vˇsechny reference na objekty ze servisn´ı vrstvy jako transient, aby nedoˇslo k jejich serializaci spolu s drˇzitelem reference.

Tisk QR k´ od˚ u Pro tisk QR k´ od˚ u byla pouˇzita open-source knihovna itextpdf. Programov´ y kód nezávisl´ y na JSF je um´ıstˇen v bal´ıku qrcode. Jak jiˇz bylo zm´ınˇeno, JSF je technologie ve které primárn´ı roli hraje Pohled, tedy konkrétn´ı Faces str´ anka. Ty jsou nicménˇe primárnˇe orientovány na generován´ı HTML k´ odu. Pro tisk QR kódu je potˇreba zmˇenit HTTP odpovˇed’ na Content-Type na application/pdf a m´ısto HTML zapsat pˇr´ımo PDF soubor. To se vˇsak ned´ a realizovat pomoc´ı ˇzádné TLD knihovny. Je tedy nutné celou architekturu JSF pˇreklopit“ z MVP do MVC tak, abychom ” z backing beany udˇelaly Controller, kter´ y pouˇzije v´ yˇse zm´ınˇeného bal´ıku qrcode a zap´ıˇse v´ ystup (PDF soubor) pˇr´ımo do HTTP odpovˇedi. Je nejprve nutné pˇredat odpovˇednost za vygenerován´ı odpovˇedi z JSF stránky pˇr´ısluˇsné backing beanˇe : Metoda render() poté naˇcte HTTP odpovˇed’, vyresetuje ji a následnˇe ji m˚ uˇze znovu vytvoˇrit:

95


RAT server

HttpServletResponse response = externalContext.getResponse(); response.reset(); response.setContentType("application/pdf"); OutputStream browserStream = response.getOutputStream(); ObjectQRCodeGenerator gen = ...naˇ cti ze SpringBeanFactory... gen.createPDF(browserStream, objectId); browserStream.close(); facesContext.responseComplete(); Samotn´ y gener´ ator PDF jenom zap´ıˇse PDF dokument do v´ ystupn´ıho proudu. Je moˇzné tedy pouˇz´ıvat tuto tˇr´ıdu univerzálnˇe pro jak´ ykoliv v´ ystupn´ı proud.

Export kalend´ aˇ re do iCal form´ atu Pro export kalen´ aˇre je je pouˇzita knihovna iCal4j. Programov´ y kód nezávisl´ y na JSF je v bal´ıku ical. Princip zmˇeny fungován´ı JSF pro export kalenáˇre je totoˇzn´ y s vytv´ aˇren´ım QR k´ od˚ u.

6.2.8

REST webov´ e sluˇ zby

Pro komunikaci mezi mobiln´ı aplikac´ı a centráln´ım serverem byly vytvoˇreny REST sluˇzby, které zajiˇst’uj´ı mobiln´ım aplikac´ım vˇsechnu potˇrebnou funkcionalitu. Sluˇzby jsou zabezpeˇceny pomoc´ı Spring Security obdobnˇe jako webové rozhran´ı. Po kaˇzdé u ´spˇeˇsné HTTP autorizaci uˇzivatele server vloˇz´ı do odpovˇedi sessionId, které je moˇzné pouˇz´ıvat jako autorizaˇcn´ı token v následné komunikaci. T´ım je sice poruˇsena bezestavovost REST rozhran´ı, na druhou stranu nen´ı nutné klienta pˇri kaˇzdém poˇzadavku ovˇeˇrovat proti vzd´ alenému serveru (pokud to uˇzivatelsk´ yu ´ˇcet klienta vyˇzaduje), coˇz pˇrin´ aˇs´ı znatelné urychlen´ı komunikace. Nˇekteré sluˇzby jsou také orientov´ any sp´ıˇse procedur´ alnˇe neˇz datovˇe (viz dále). Implementace je um´ıstˇená v bal´ıku rest. ´ Zde budou uvedeny pouze implementaˇcn´ı detaily. Upln´ y popis REST webov´ ych sluˇzeb je moˇzné naj´ıt v Pˇr´ıloze B.

Serializace dat Jako pˇrenosov´ y form´ at dat byl zvolen XML. Jednotlivé objekty jsou serializovány a deserializov´ any pomoc´ı technologie JAXB (Java Architecture for XML Binding). Nicménˇe protoˇze serializace pˇr´ımo doménov´ ych objekt˚ u nen´ı pˇr´ıliˇs vhodná (svázán´ı

96


RAT server

s Hibernate session, zan´ aˇsen´ı modelu netypick´ ymi anotacemi) a nav´ıc chceme minimalizovat pˇrenosy dat, byla vytvoˇrena nová sada mapovac´ıch objekt˚ u, které lépe reflektuj´ı potˇreby mobiln´ı aplikace a nav´ıc umoˇzn´ı oddˇelit serializaˇcn´ı anotace od doménového modelu. S ohledem na struktuxu XML dokumentu lze objekty rozdˇelit d´ ale na mapovac´ı doménové objekty a mapovac´ı kontejnery. ´ Ukolem mapovac´ıch kontejner˚ u je umoˇznit pˇrenáˇsen´ı v´ıce objekt˚ u v rámci jedné reference, reprezentuj´ı tedy vlastnˇe seznam instanc´ı stejné tˇr´ıdy. Pomoc´ı JAXB anotace @XmlRootElement je poté definován název koˇrenového elementu takového seznamu pˇri XML serializaci. Takov´ ymi kontejnery jsou napˇr. PeriodsMapping, ReservationsMapping, atd. Mapovac´ı doménové objekty jsou poté reprezentace doménov´ ych objekt˚ u, které jsou ovˇsem pˇr´ımo urˇcené k serializaci. Jejich atributy se pˇritom od doménov´ ych objekt˚ u m´ırnˇe liˇs´ı, jak ukazuje Obr. 6.7.

Obrázek 6.7: Základn´ı mapovac´ı objekty. Napˇr´ıklad ObjectMapping nahrazuje referenci na tˇr´ıdu objektu dvojic´ı atribut˚ u objectClassId a objectClassName. Dále dˇed´ı jej´ı pickable a returnable atributy. C´ılem tˇechto zmˇen je poskytnout maximum informac´ı v jednom poˇzadavku a umoˇznit v r´ amci v dalˇs´ıch poˇzadavk˚ u jejich zpˇresnˇen´ı (mobiln´ı aplikace napˇr´ıklad v profilu rezervace zobraz´ı jméno objektu a pokud bude cht´ıt uˇzivatel zobrazit i dalˇs´ı informace o tomto objektu, je moˇzné zaslat poˇzadavek pˇr´ısluˇsné webové sluˇzbˇe na z´ akladˇe atributu objectId). Tˇr´ıdy tˇechto mapovac´ıch objekt˚ u jsou um´ıstˇeny v bal´ıku rest.beans.

97


RAT server

Pˇ remapov´ an´ı dom´ enov´ ych objekt˚ u Pro pˇremapov´ an´ı je vyuˇzita kaskáda factory tˇr´ıd. Ty jsou um´ıstˇené v bal´ıku rest.factory a jsou zaregistrovány do Spring Frameworku jako @Component. Kaˇzdá z nich zajiˇst’uje pˇremapován´ı jednoho typu objektu. V pˇr´ıpadˇe, kdy je vazba mezi doménov´ ymi objekty typu 1:N (napˇr´ıklad Reservation – Period), je vyuˇzito kontejnerov´ ych mapovac´ıch objekt˚ u. V pˇr´ıpadˇe pˇremapován´ı kolekce instanc´ı tˇr´ıdy Reservation je tedy zavol´ ana mapovac´ı metoda z ReservationsMappingFactory, ta vytvoˇr´ı novou instanci ReservationsMapping, poté pˇremapuje kaˇzd´ y objekt z kolekce pomoc´ı factory ReservationMappingFactory, a tak dále. Kaˇzdá u ´roveˇ n zanoˇren´ı této kask´ ady pak je vlastnˇe u ´roveˇ n zanoˇren´ı v´ ysledného XML dokumentu, kter´ y vznikne JAXB serializac´ı vzniknuvˇs´ıho ReservationsMapping objektu (Obr. 6.8). Factory um´ı mapovat i obrácenˇe, tj. z mapovac´ıch objekt˚ u do doménov´ ych.

Obrázek 6.8: Vztah mapovac´ıch objekt˚ u a XML.

Spring MVC V´ yˇse zm´ınˇen´ ych princip˚ u je vyuˇzito k vytváˇren´ı XML dokument˚ u, které jsou pˇrikládány k HTTP odpovˇedi nebo jsou deserializovány z HTTP poˇzadavku. V bal´ıku ˇ ce), jejichˇz metody jsou za pomoci Spring MVC rest.controller jsou tˇr´ıdy (Radiˇ pˇr´ımo pouˇzité pro vytvoˇren´ı webov´ ych sluˇzeb. U kaˇzdé metody je nutné pomoc´ı anotac´ı urˇcit podporovan´ y HTTP protokol a sadu URL parametr˚ u, které budou injektov´ any samotn´ ym Spring Frameworkem. Metody maj´ı pˇr´ım´ y pˇr´ıstup do servisn´ı vrstvy aplikace a vyuˇz´ıvaj´ı zm´ınˇeného factory bal´ıku pro konvertován´ı pˇr´ıchoz´ıch XML soubor˚ u na doménové objekty a naopak. Roli Modelu pak hraj´ı pˇr´ıchoz´ı nebo odchoz´ı data a jako Pohled je moˇzné interpretovat JAXB Marshaller, kter´ y ˇ je zaregistrov´ an pro kaˇzd´ y Radiˇc v souboru applicationContext.xml.

98


RatDroid

REST error handling Pˇri konstruov´ an´ı odpovˇedi na HTTP poˇzadavek m˚ uˇze ve webové sluˇzbˇe doj´ıt k chybˇe aplikace a n´ aslednˇe m˚ uˇze b´ yt vyhozena v´ yjimka. Abychom tyto stavy oˇsetˇrili a korektnˇe namapovali do HTTP kód˚ u, je v bal´ıku rest.errorhandling komponenta RestExceptionHandler, která umoˇzn ˇuje zachytáván´ı v´ yjimek z aplikaˇcn´ıho k´ odu. V´ yjimka je vˇzdy zachycena a pˇremapována na XML dokument se zprávou o chybˇe a dalˇs´ımi konfigurovateln´ ymi u ´daji (tˇr´ıda XmlRestErrorConverter). Ten je pˇriloˇzen k HTTP odpovˇedi. Dále bylo nutné v souboru RAT-servlet.xml (konfiguraˇcn´ı soubor Spring Dispatcher servletu) definovat chybov´ y kód, kter´ y bude s v´ yjimkou sv´ az´ an: <entry key="UnknownResourceException" value="404, _exmsg" /> <entry key="UnauthorizedAccessRestException" value="403, _exmsg" /> <entry key="Throwable" value="500, error.internal" /> Jak je vidˇet, existuj´ı dvˇe namapované uˇzivatelské v´ yjimky pro situace, kdy je zadán ˇspatn´ y identifik´ ator zdroje nebo se uˇzivatel snaˇz´ı pˇristoupit ke zdroj˚ u, které leˇz´ı mimo jeho kompetence (napˇr´ıklad se pokouˇs´ı editovat rezervaci, která nen´ı jeho). Vˇsechny ostatn´ı v´ yjimky (instance rozhran´ı Throwable) se vyhodnocuj´ı jako intern´ı chyba serveru.

6.3

RatDroid

RatDroid je n´ azev klientské aplikace systému RAT pro operaˇcn´ı systém Android. Tato aplikace se pˇripojuje k REST webov´ ych sluˇzbám centráln´ıho serveru a zajiˇst’uje uˇzivatel˚ um funkˇcnost specifikovanou pro mobiln´ı zaˇr´ızen´ı v Kap. 4.

6.3.1

Z´ akladn´ı architektura aplikace

Na Obr´ azku 6.9 je zn´ azornˇeno zjednoduˇsené schéma mobiln´ı aplikace, vˇcetnˇe rozpisu nejvˇetˇs´ıch uˇzit´ ych komponent. Jak je vidˇet, i mobiln´ı aplikace sleduje základn´ı

99


RatDroid

rozvrˇzen´ı tˇr´ıvrstvé architektury. Klient neobsahuje ˇzádnou aplikaˇcn´ı logiku s v´ yjimkou základn´ıch validac´ı uˇzivatelského vstupu a v´ıceménˇe hraje roli tenkého klienta.

Obrázek 6.9: Architektura a pouˇzité technologie.

6.3.2


Doménov´ y model aplikace kop´ıruje strukturu mapovac´ıch POJO objekt˚ u implementovan´ ych na serveru. Pˇri komunikaci se serverem docház´ı k serializaci a deserializaci tˇechto objekt˚ u. Protoˇze v aplikaˇcn´ım frameworku Androidu chyb´ı nˇekteré standardn´ı Java knihovny, nen´ı moˇzné pouˇz´ıt napˇr. JAXB technologii. Proto byl pouˇzit Simple Framework, kter´ y na tˇechto knihovnách implmementaˇcnˇe nezávis´ı. Tento framework poskytuje komponentu SimpleXmlHttpMessageConverter, kterou je moˇzné zaregistrovat pˇr´ımo do Spring REST komunikaˇcn´ıho rozhran´ı (viz dále). Serializace je ˇr´ızena na z´ akladˇe anotac´ı. Samotné doménové objekty jsou um´ıstˇeny v bal´ıku bean. Nˇekteré pomocné XML konvertory nutné pro serializaci objekt˚ u jsou v bal´ıku xml.

6.3.3

Datov´ a vrstva

Jako datovou vrstvu je moˇzné interpretovat komunikaˇcn´ı rozhran´ı mezi mobiln´ım klientem a centr´ aln´ım serverem. C´ıle této vrstvy vˇsak z˚ ustávaj´ı stejné – bylo tˇreba oddˇelit k´ od specifick´ y pro REST komunikaci od vlastn´ıho aplikaˇcn´ıho kódu. Dále bylo tˇreba zohlednit asynchronn´ı povahu této komunikace. Veˇskerá implementace datové vrstvy se nach´ az´ı v bal´ıku service.

100


RatDroid

RestTemplate Pro z´ akladn´ı REST komunikaci je pouˇzita komponenta RestTemplate z knihovny Spring For Android. Spring zde jiˇz nehraje roli rozsáhlého aplikaˇcn´ıho frameworku, jedná se sp´ıˇse o malou knihovnu poskytuj´ıc´ı uˇziteˇcnou funkcionalitu pro vzdálenou OAuth autorizaci a REST komunikaci. Komponenta RestTemplate poté podporuje spoustu uˇziteˇcn´ ych funkc´ı, jako je správa Cookies, HTTP autorizace, automatická deserializace dat pˇrenáˇsen´ ych jako XML nebo JSON atp.

RestTask Komponenta RestTask je z´ akladn´ı komunikaˇcn´ı u ´loha aplikace. Bez ohledu na pˇrenáˇsen´ a data nebo URL c´ılové webové sluˇzby jsou vˇsechny uskuteˇcnˇené pokusy o komunikaci ˇreˇseny jako instance objektu RestTask. Prvn´ı vlastnost´ı této komponenty je realizace stavové komunikace na základˇe serverové sessionId. Nad r´ amec obvyklé REST komunikace je vystavˇen mechanismus, kter´ y umoˇzn ˇuje pˇren´ aˇset jméno a heslo uˇzivatele pouze pokud je to nezbytnˇe nutné. Samotn´ a programov´ a realizace poté poˇc´ıtá se dvˇema pokusy o komunikaci s webovou sluˇzbou . Pˇri prvn´ım pokusu je do HTTP poˇzadavku vloˇzeno sessionId (pokud existuje). Pokud se po odeslán´ı poˇzadavku ze serveru vrát´ı odpovˇed’ s HTTP kódem 404 - Unauthorized, znamená to, ˇze vyprˇsela platnost sessionId. V tˇechto situac´ıch je odesl´ an naprosto stejn´ y HTTP poˇzadavek jako v prvn´ım kroku, tentokrát vˇsak s pˇr´ısluˇsn´ ym jménem a heslem. Z odpovˇedi je poté (pokud tato také nekonˇc´ı chybov´ ym k´ odem, v tom pˇr´ıpadˇe má uˇzivatel ˇspatné jméno nebo heslo) vyjmuto nové sessionId, které je poté pouˇz´ıváno v dalˇs´ı komunikaci. Dalˇs´ım u ´kolem této komponenty je vytvoˇren´ı asynchronn´ı komunikace. Tˇr´ıda dˇed´ı od systémové AsyncTask a vlastn´ı v´ ykonn´ y kód je pouˇstˇen asynchronnˇe v˚ uˇci hlavn´ımu vl´ aknu aplikace. Aby bylo moˇzné nˇejak notifikovat zbytek aplikace o v´ ysledku komunikace, mus´ı se kaˇzdé instanci tˇr´ıdy RestTask pˇredat implementace rozhran´ı IRestListener.

RestTaskFactory Jak jiˇz n´ azev napov´ıd´ a, RestTaskFactory zajiˇst’uje vytváˇren´ı jednotliv´ ych komunikaˇcn´ıch u ´loh. D´ ale udrˇzuje referenci na sessionId a rekonfiguruje nastaven´ı

101


RatDroid

RestTemplate komponenty pokud uˇzivatel zmˇen´ı nastaven´ı komunikace.

RestService Tˇr´ıda RestService je implementace jiˇz zmiˇ novaného návrhového vzoru Data Gateway. Obsahuje sadu metod, které jsou namapovány na jednotlivé webové sluˇzby a je tedy skuteˇcn´ ym rozhran´ım mezi REST webov´ ymi sluˇzbami a doménov´ ym modelem aplikace.

6.3.4

Aplikaˇ cn´ı vrstva

Aplikaˇcn´ı vrstva je realizov´ ana pomoc´ı ˇrady tˇr´ıd, které obvykle dˇed´ı od tˇr´ıdy SkeletonRestActivity. Tato z´ akladn´ı tˇr´ıda rozˇsiˇruje známou systémovou tˇr´ıdu Activity a souˇcasnˇe implementuje rozhran´ı IRestListener tak, aby kaˇzdá aktivita aplikace mohla reagovat na dokonˇcenou komunikaci se serverem a aktualizovat prezentaˇcn´ı vrstvu. Protoˇze m˚ uˇze b´ yt jakákoliv instance aktivity kdykoliv mobiln´ım systémem za jist´ ych okolnost´ı uklizena“ (destroyed ), je jiˇz na u ´rovni ” SkeletonRestActivity zajiˇstˇeno podchycen´ı takové události a korektn´ı ukonˇcen´ı komunikace, pokud tato zrovna prob´ıhá. Obdobné tˇr´ıdy jako je SkeletonRestActivity existuj´ı i pro dalˇs´ı komponenty systému – fragmenty (SkeletonRestFragmentActivity) a v´ıcepoloˇzkové aktivity (SkeletonRestListActivity).

6.3.5


Pohled prezentaˇcn´ı vrstvy je v aplikaˇcn´ım prostˇred´ı Androidu obvykle zapisován ve formˇe jako XML dokument˚ u. Kaˇzdá aktivita poté m˚ uˇze sobˇe pˇriˇradit patˇriˇcn´ y Pohled a d´ ale s n´ım pracovat. Pohled je moˇzné z aktivit vytváˇret i programovˇe, ˇc´ımˇz se prezentaˇcn´ı vrstva pˇribliˇzuje napˇr´ıklad klasickému frameworku Swing. Tento pˇr´ıstup neposkytuje ˇza´dné moˇznosti bindov´ an´ı a dalˇs´ıch pokroˇcil´ ych programovac´ıch technik. Vˇse mus´ı b´ yt programovovˇe ˇr´ızeno z aktivit pomoc´ı posluchaˇc˚ u, vˇcetnˇe reakc´ı na ud´ alosti apod., coˇz znatelnˇe znepˇrehledˇ nuje aplikaˇcn´ı kód. Na druhou stranu lze v XML zapsané (aˇc velice jednoduché) Pohledy pouˇz´ıvat u celé ˇrady aktivit, coˇz se napˇr´ıklad u technologie JSF realizuje jen velice obt´ıˇznˇe.

102


6.3.6

RatDroid

Shrnut´ı

Na Obr. 6.10 je uk´ azka jedné z obrazovek aplikace RatDroid. D´ıky napojen´ı na webové sluˇzby centr´ aln´ıho serveru je moˇzné efektivnˇe vytváˇret a spravovat vlastn´ı rezervace, kdy jedinou podm´ınkou je dostateˇcnˇe stabiln´ı pˇripojen´ı k s´ıti. Aplikace se maxim´ alnˇe snaˇz´ı vyuˇz´ıt moˇznosti dotykového displeje a je moˇzné ji ovládat jak v horizont´ aln´ım tak ve vertik´ aln´ım módu pˇr´ıstroje.

Obrázek 6.10: Ukázka mobiln´ı aplikace RatDroid.

103


6.4

RatSharp

RatSharp

Nad r´ amec této pr´ ace byla vytvoˇrena mobiln´ı aplikace s názvem RatSharp. Tato aplikace je urˇcena pro mobiln´ı operaˇcn´ı systém Windows Phone 7 a implementuje stejnou sadu poˇzadavk˚ u jako klient pro systém Android. Je tedy plnˇe pouˇzitelná v rámci celého informaˇcn´ıho systému RAT. Ukázka jedné z obrazovek této aplikace je na Obr. 6.11.

Obrázek 6.11: Ukázka mobiln´ı aplikace RatSharp.

104


6.5

Testován´ı a nasazen´ı systému

Testov´ an´ı a nasazen´ı syst´ emu

Bˇehem celého v´ yvoje byl dostupn´ y produkˇcn´ı server, na kterém docházelo k automatickému staˇzen´ı aktu´ aln´ı revize zdrojov´ ych kód˚ u ze Subversion repozitáˇre projektu, sestaven´ı webové aplikace a nasazen´ı na webov´ y kontejner Tomcat. V ran´ ych fáz´ıch v´ yvoje se jednalo pouze o pom˚ ucku, jak pr˚ ubˇeˇznˇe kontrolovat sestavitelnost aplikace i na jin´ ych systémech neˇz je poˇc´ıtaˇc v´ yvojáˇre. V okamˇziku, kdy byla hlavn´ı serverová ˇcást jiˇz pouˇzitelná spolu s mobiln´ı aplikac´ı, byl produkˇcn´ı server spuˇstˇen spolu na veˇrejné IP adrese a funkcionalita celého systému byla pr˚ ubˇeˇznˇe kontrolována jak autorem systému, tak zadavatelem práce. Pro u ´ˇcely hl´ aˇsen´ı chyb byl nasazen bug tracking system, do kterého byly jednotlivé nalezené chyby pr˚ ubˇeˇznˇe hláˇseny ve formˇe u ´loh urˇcen´ ych k vyˇreˇsen´ı. Mobiln´ı aplikace byla vyv´ıjena a testována na referenˇcn´ım zaˇr´ızen´ı Nexus S, které je ve vlastnicv´ı Katedry informatiky a v´ ypoˇcetn´ı techniky. Byl vytvoˇreno nˇekolik typick´ ych scén´ aˇr˚ u uˇzit´ı systému zamˇestnanci katedry, souvisej´ıc´ıch zejména se soubˇeˇzn´ ymi rezervacemi téhoˇz objektu r˚ uzn´ ymi uˇzivateli a schopnost´ı mobiln´ı aplikace rychle vyzvednout objekt, na kter´ y pˇredt´ım nebyla vytvoˇrena ˇzádná rezervace (funkce Vyzvedni ). Scén´ aˇre uˇzit´ı byly pr˚ ubˇeˇznˇe ovˇeˇrovány na v´ yˇse zm´ınˇeném reálném zaˇr´ızen´ı. Dále byly vybr´ any nˇekteré existuj´ıc´ı movité i nemovité objekty nalézaj´ıc´ı se ve vlastnictv´ı katedry. Tyto byly n´ aslednˇe oznaˇceny patˇriˇcn´ ymi QR kódy a byly testovány re´ alné moˇznosti systému efektivnˇe spravovat v´ yp˚ ujˇcky tˇechto objekt˚ u. Nˇekteré poˇzadavky byly na z´ akladˇe tohoto testován´ı shledány jako nevyhovuj´ıc´ı a byly ze specifikace odstranˇeny (tyto nakonec neimplementované poˇzadavky nejsou souˇcást´ı této pr´ ace), naopak nˇekteré vznikly bˇehem uˇzivatelského testován´ı jako snaha o zv´ yˇsen´ı pouˇzitelnosti systému (napˇr´ıklad funkce obl´ıbených objekt˚ u nebo moˇznost zobrazit profil objektu pˇr´ımo z editaˇcn´ıch obrazovek rezervac´ı). D´ıky tomu je moˇzné ˇr´ıci, ˇze vznikl´ y systém plnˇe pokr´ yvá poˇzadavky a nároky na nˇej kladené a je schopen re´ alného nasazen´ı.

105

7 Závˇer C´ılem této pr´ ace bylo zobecnit problém správy v´ yp˚ ujˇcek a rezervac´ı objekt˚ u movit´ ych i nemovit´ ych, a to na z´ akladˇe pˇr´ıpadové studie stávaj´ıc´ıho ˇreˇsen´ı na Katedˇre informatiky a v´ ypoˇcetn´ı techniky pˇri Západoˇceské univerzitˇe v Plzni. Nejprve byl vytvoˇren obecn´ y logick´ y model správy v´ yp˚ ujˇcek a rezervac´ı a definovány základn´ı term´ıny a vazby v tomto modelu. Následnˇe doˇslo k vytvoˇren´ı kompletn´ı specifikace poˇzadavk˚ u na informaˇcn´ı systém, kter´ y se snaˇz´ı problém správy v´ yp˚ ujˇcek a rezervaci efektivnˇe ˇreˇsit za vyuˇzit´ı unikátn´ıch moˇznost´ı mobiln´ıch zaˇr´ızen´ı. Na z´ avˇer byla pˇredvedena konkrétn´ı realizace tohoto informaˇcn´ıho systému. Tato realizace vytv´ aˇr´ı architekturu klient-server, ve které jednotlivé klienty pˇredstavuj´ı mobiln´ı zaˇr´ızen´ı postavené na platformˇe Android. Tyto klienti se pˇripojuj´ı k centr´ aln´ımu serveru za u ´ˇcelem vytváˇren´ı a správy rezervac´ı objekt˚ u, kdy kaˇzd´ y objekt je jednoznaˇcnˇe identifikov´ yn pomoc´ı QR kódu, kter´ y je na objektu fyzicky um´ıstˇen. Server také poskytuje pohodlné webové rozhran´ı. Je moˇzné se pˇrihlaˇsovat s vyuˇzit´ım uˇzivatelsk´ ych u ´ˇct˚ u Orion celouniverzitn´ıho systému IS/STAG. Pr´ aci povaˇzuji za u ´spˇeˇsnou a tato by mˇela splˇ novat vˇsechny poˇzadavky, které na ni byly kladeny. Nad r´ amec p˚ uvodn´ıho zadán´ı byla implementována klientská aplikace i pro mobiln´ı platformu Windows Phone. Moˇznost rozˇs´ıˇren´ı této pr´ ace spoˇc´ıvá zejména v implementaci dalˇs´ıch zp˚ usob˚ u pˇrihláˇsen´ı, kupˇr´ıkladu za vyuˇzit´ı u ´ˇct˚ u webov´ ych sluˇzeb jako je GMail nebo Facebook a dalˇs´ı sbliˇzov´ an´ı tˇechto sluˇzeb se systémem. Dále je jistˇe ˇzádouc´ı vytvoˇrit klientské aplikace i pro dalˇs´ı mobiln´ı platformy tak, aby byla pouˇzitelnost systému co moˇzn´ a nejˇsirˇs´ı.

106

A Rozvrˇzen´ı mobiln´ı aplikace V této pˇr´ıloze je uk´ az´ ano z´ akladn´ı schéma mobiln´ı aplikace a nˇekteré návrhy obrazovek, které vznikly v r´ amci specifikace poˇzadavk˚ u. Tˇemto návrh˚ um by se mˇela fináln´ı implementace co nejv´ıce pˇribl´ıˇzit. Obrázek A.1 ukazuje moˇzné pr˚ uchody obrazovkami mobiln´ı aplikace. Ty pˇri pr˚ uchodu z hlavn´ı obrazovky vytváˇr´ı zásobn´ık pˇredchoz´ıch obrazovek a je moˇzné se v cestˇe grafem vracet pomoc´ı tlaˇc´ıtka Zpˇet, které by mˇelo at’ uˇz v hardwarové nebo softwarové podobˇe kaˇzdé zaˇr´ızen´ı s mobiln´ı platformou Android implementovat.

Obrázek A.1: Graf pr˚ uchodu mobiln´ı aplikac´ı.

107

Rozvrˇzen´ı mobiln´ı aplikace

Obrázek A.2: Rozvrˇzen´ı hlavn´ı obrazovky aplikace.

108


Obrázek A.3: Rozvrˇzen´ı mˇes´ıˇcn´ıho kalendáˇre.

109


Obrázek A.4: Rozvrˇzen´ı mˇes´ıcn´ıho kalendáˇre.

110


Obrázek A.5: Kritéria vyhledáván´ı objekt˚ u.

111


Obrázek A.6: Obrazovka pro vytváˇren´ı a editaci rezervac´ı.

112

B Popis webových REST sluˇzeb V této pˇr´ıloze je uveden v´ yˇcet vˇsech webov´ ych sluˇzeb, které poskytuje centráln´ı server informaˇcn´ıho systému RAT. Sluˇzby vyˇzaduj´ı HTTP autorizaci a po pˇrihláˇsen´ı je vytvoˇrena pro klienstkou stranu session, v rámci které je poskytován kontext pro pˇrihl´ aˇseného uˇzivatele (viz dále). URL vˇsech sluˇzeb zaˇc´ıná relativn´ı cestou /api/rest/*. Na pˇriloˇzeném médiu jsou uloˇzeny XSD schémata XML reprezentace pˇrenáˇsen´ ych dat.

Seznam sluˇ zeb URI: HTTP Metoda: Atributy:

/users/user/name GET name=(String)

XSD sch´ ema:

Vr´ at´ ı uˇ zivatele podle jeho pˇ rihlaˇ sovac´ ıho jm´ ena, nebo HTTP 404 - Unknown, pokud uˇ zivatel neexistuje. user.xsd

URI: HTTP Metoda: Atributy:

/users/user GET id=(Integer)

Popis: XSD sch´ ema:

Vr´ at´ ı uˇ zivatele podle jeho identifik´ atoru nebo HTTP 404 - Unknown, pokud uˇ zivatel neexistuje. user.xsd

URI: HTTP Metoda:

/users/user/favourites GET

Popis:

Vr´ at´ ı seznam objekt˚ u obl´ ıben´ ych uˇ zivatelem, jehoˇ z session je pr´ avˇ e aktivn´ ı. objects.xsd

Popis:

XSD sch´ ema:

113

Popis webových REST sluˇzeb URI: HTTP Metoda:

/users/session/properties GET

XSD sch´ ema:

Vr´ at´ ı glob´ aln´ ı nastaven´ ı serveru, souvisej´ ıc´ ı s vytv´ aˇ ren´ ım rezervac´ ı (d˚ uleˇ zit´ e pro mobiln´ ı kalend´ aˇ r). properties.xsd

URI: HTTP Metoda:

/users/session/reservations/occupation GET

Atributy:

month=(Integer) year=(Integer)

Popis:

XSD sch´ ema:

Vr´ at´ ı ty dny v mˇ es´ ıci, ve kter´ ych m´ a majitel session vytvoˇ ren´ e nˇ ejak´ e rezervace, a poˇ cet tˇ echto rezervac´ ı v kaˇ zd´ em takov´ em dni. occupations.xsd

URI: HTTP Metoda:

/users/session/reservations/notreturned GET

Popis:

XSD sch´ ema:

Vr´ at´ ı vˇ sechny nevr´ acen´ e periody rezervac´ ı, kter´ e patˇ r´ ı uˇ zivateli vlastn´ ıc´ ı session, jsou oznaˇ ceny jako nevr´ acen´ e a je moˇ zn´ e je vr´ atit. reservations.xsd


/users/session/favourite POST id=(Integer)

Popis:

XSD sch´ ema:

Pˇ rid´ a nov´ y objekt do seznamu obl´ ıben´ ych objekt˚ u uˇ zivatele, kter´ y je majitelem session, a vr´ at´ ı tento aktualizovan´ y objekt. Pokud objekt neexistuje, vr´ at´ ı HTTP 404 - Unknown. objects.xsd


/reservations/reservation GET id=(Integer)

Popis:

Vr´ at´ ı rezervaci vˇ cetnˇ e vˇ sech period na z´ akladˇ e pˇ redan´ eho identifik´ atoru. reservations.xsd

Popis:

XSD sch´ ema:

114

Popis webových REST sluˇzeb URI: HTTP Metoda: Atributy:

Popis:

XSD sch´ ema: URI: HTTP Metoda: Atributy:

/users/session/reservation DELETE id=(Integer) Odstran´ ı rezervaci patˇ r´ ıc´ ı majiteli session ze syst´ emu. Pokud rezervace neexistuje, vr´ at´ ı HTTP 404 - Unknown. Pokud je rezervace vedena na jin´ eho uˇ zivatele, vr´ at´ ı 401 - Unauthorized. Jinak vr´ at´ ı odstranˇ enou rezervaci vˇ cetnˇ e vˇ sech jej´ ıch period. reservations.xsd /users/session/reservations GET since=(yyyy-MM-dd-HH-mm) to=(yyyy-MM-dd-HH-mm)

XSD sch´ ema:

Vr´ at´ ı vˇ sechny periody (vˇ cetnˇ e jejich rezervac´ ı), jejichˇ z ˇ casov´ e ´ useky se alespoˇ n ˇ c´ asteˇ cnˇ e kryj´ ı s ˇ casov´ ym ´ usekem stanoven´ ym URL atributy a jejichˇ z majitelem je majitel session. reservations.xsd

URI: HTTP Metoda:

/users/session/reservation PUT

Popis:

Popis:

XSD sch´ ema: URI: HTTP Metoda: Atributy:

Popis:

XSD sch´ ema:

Vytvoˇ r´ ı nov´ e rezervace pro majitele session. Nevrac´ ı bud’ ˇ z´ adnou rezervaci pokud se vytvoˇ ren´ ı podaˇ rilo, nebo tu rezervaci, kter´ a blokuje vytvoˇ ren´ ı rezervace nov´ e. reservations.xsd /users/session/reservation/period POST since=(yyyy-MM-dd-HH-mm) to=(yyyy-MM-dd-HH-mm) valid=(true|false) Editov´ an´ ı periody rezervace. Pokud perioda s pˇ redan´ ym identifik´ atorem neexistuje, vrac´ ı HTTP 404 - Unknown. Pokud je rezervace periody vedena na jin´ eho uˇ zivatele, vr´ at´ ı 401 - Unauthorized. Vrac´ ı bud’ editovanou periodu, nebo periodu, kter´ a editaci br´ an´ ı z d˚ uvodu kolize ˇ cas˚ u. reservations.xsd

115

Popis webových REST sluˇzeb URI: HTTP Metoda: Atributy:

/objects/object/id GET id=(Integer)

XSD sch´ ema:

Vr´ at´ ı objekt podle jeho identifik´ atoru. Pokud objekt s pˇ redan´ ym identifik´ atorem neexistuje, vr´ at´ ı HTTP 404 - Unknown. objects.xsd


/objects/object/identifier GET identifier=(String)

Popis:

XSD sch´ ema:

Vr´ at´ ı objekt podle jeho textov´ eho identifik´ atoru. Pokud objekt s pˇ redan´ ym identifik´ atorem neexistuje, vr´ at´ ı pr´ azdn´ y seznam objekt˚ u. objects.xsd

URI: HTTP Metoda:

/objects/object/search GET

Atributy:

type=(ALL|OBJ_NAME|CLASS_NAME|OBJ_DESCRIPTION) key=(String)

Popis: XSD sch´ ema:

Vr´ at´ ı vˇ sechny nalezen´ e objekty odpov´ ıdaj´ ıc´ ı vyhled´ avac´ ım krit´ eri´ ım. objects.xsd


/objects/session/object/pickup POST id=(Integer)

Popis:

Popis:

XSD sch´ ema:

Pokus´ ı se o vyzvednut´ ı objektu s pˇ redan´ ym identifik´ atorem majitelem session. Vr´ at´ ı bud’ pr´ azdn´ y seznam pokud nen´ ı jak rezervaci vyzvednout, ciz´ ı blokuj´ ıc´ ı rezervaci (pokud existuje), nebo vyzvednutou rezervaci, kterou majitel pˇ redt´ ım vytvoˇ ril. reservations.xsd

116

Popis webových REST sluˇzeb URI: HTTP Metoda:

/object/reservations GET

Atributy:

since=(yyyy-MM-dd-HH-mm) to=(yyyy-MM-dd-HH-mm) id=(Integer)

XSD sch´ ema:

Vr´ at´ ı vˇ sechny periody rezervac´ ı vytvoˇ ren´ ych na objekt s pˇ redan´ ym identifik´ atorem, jejichˇ z ˇ casov´ e rozmez´ ı se alespoˇ n ˇ c´ asteˇ cnˇ e kreje s ˇ casov´ ym rozpˇ et´ ım z parametr˚ u. reservations.xsd

URI: HTTP Metoda:

/objects/object/reservations/occupation GET

Atributy:

month=(Integer) year=(Integer) id=(Integer)

Popis:

Popis:

XSD sch´ ema:

Vr´ at´ ı ty dny v mˇ es´ ıci, ve kter´ ych je vytvoˇ rena nˇ ejak´ a rezervace na objekt s pˇ redan´ ym identifik´ atorem, a poˇ cet tˇ echto rezervac´ ı v kaˇ zd´ em takov´ em dni. occupations.xsd

117

C Uˇzivatelská pˇr´ıruˇcka V této pˇr´ıloze bude uveden struˇcn´ y manuál k pouˇz´ıván´ı webového rozhran´ı a mobiln´ı aplikace RatDroid informaˇcn´ıho systému RAT.

C.1

Webov´ e rozhran´ı

Pro pouˇz´ıv´ an´ı webového rozhran´ı je nejpre nutné zadat jméno a heslo na pˇrihlaˇsovac´ı obrazovce. Bez tohoto aktu nen´ı moˇzné ˇzádn´ ym zp˚ usobem se systémem pracovat. Po u ´spˇeˇsném pˇrihl´ aˇsen´ı bude uˇzivatel vpuˇstˇen“ do systému a bude mu ” umoˇznˇeno prov´ adˇet u ´kony n´ aleˇzej´ıc´ı jeho roli (Obr. C.1).

Obrázek C.1: Pˇrihlaˇsovac´ı dialog.

C.1.1

Z´ akladn´ı navigace

Po u ´spˇeˇsném pˇrihl´ aˇsen´ı bude po levé stranˇe obrazovky dostupné navigaˇcn´ı menu, které umoˇzn´ı uˇzivateli pˇrep´ın´ an´ı mezi jednotliv´ ymi hlavn´ımi obrazovkami (Obr. C.2). Rozvrˇzen´ı tohoto menu je následuj´ıc´ı: - Spr´ ava objekt˚ u – prohl´ıˇzen´ı vˇsech objekt˚ u a tˇr´ıd objekt˚ u v systému a provádˇen´ı akc´ı nad objekty, které pˇr´ısluˇsej´ı roli pˇrihláˇseného uˇzivatele. - Uˇzivatelé – prohl´ıˇzen´ı vˇsech uˇzivatel˚ u v systému a provádˇen´ı tˇech akc´ı nad uˇzivatelsk´ ymi u ´ˇcty, které pˇr´ısluˇsej´ı roli pˇrihláˇseného uˇzivatele. - Obl´ıbené – zobrazen´ı obl´ıben´ ych objekt˚ u pˇrihláˇseného uˇzivatele. - M˚ uj kalend´ aˇr – zobrazen´ı kalendáˇre vˇsech rezervac´ı patˇr´ıc´ıch pˇrihláˇsenému uˇzivateli.

118

Uˇzivatelská pˇr´ıruˇcka

Webové rozhran´ı

- M˚ uj profil – tato poloˇzka obsahuje moˇznosti správy uˇzivatelského u ´ˇctu pˇrihl´ aˇseného uˇzivatele, tj. editaci profilu, zmˇenu hesla a odhláˇsen´ı ze systému. Menu je moˇzné kdykoliv skr´ yt tlaˇc´ıtkem um´ıstˇen´ ym v pravém horn´ım rohu menu.

Obrázek C.2: Navigaˇcn´ı menu webového rozhran´ı.

C.1.2

V´ıcepoloˇ zkov´ e zobrazen´ı

Zobrazen´ı objekt˚ u, tˇr´ıd objekt˚ u, uˇzivatel˚ u a obl´ıben´ ych objekt˚ u má vˇzdy stejné rozvrˇzen´ı, proto jej pop´ıˇseme jako generickou komponentu v´ıcepoloˇzkového zobrazen´ı. Ta je realizov´ ana jako fitrovatelná stránkovac´ı tabulka (Obr. C.3).

Obrázek C.3: V´ıcepoloˇzkové zobrazen´ı objekt˚ u. V prvn´ıch nˇekolika sloupc´ıch jsou uvedeny nˇekteré základn´ı u ´daje o listované poloˇzce (na Obr´ azku C.3 jsou to konkrétn´ı objekty a jejich názvy, textové identifikátory atp.). Tyto je moˇzné d´ ale filtrovat podle kl´ıˇce, pro jehoˇz zadán´ı je pˇripraveno vstupn´ı textové pole v hlaviˇcce nˇekter´ ych sloupc˚ u. Filtraci je moˇzno kombinovat napˇr´ıˇc vˇsemi sloupci. Pokud se vˇsechny poloˇzky nevejdou na jednu stránku, je moˇzné celou tabulku str´ ankovat.

119



V posledn´ım sloupci jsou poté dostupné akce, které m˚ uˇze role pˇrihláˇseného uˇzivatele prov´ adˇet s poloˇzkami. Typickou akc´ı je zejména zobrazen´ı profilu poloˇzky (objektu, tˇr´ıdy objektu, uˇzivatele). Dalˇs´ı akce vypl´ yvaj´ı z poˇzadavk˚ u kladen´ ych na systém a popis tˇechto akc´ı je moˇzné z´ıskat z vyskakovac´ı textové nápovˇedy zobrazené pˇri najet´ı kurzoru myˇsi na tlaˇc´ıtko akce.

C.1.3

Kalend´ aˇ r

Kalend´ aˇr je nejd˚ uleˇzitˇejˇs´ı komponentou systému, protoˇze umoˇzn ˇuje prohl´ıˇzet, spravovat, vyzved´ avat a vracet rezervace. Kalendáˇr˚ u v systému existuje celá ˇrada (napˇr. pro konkrétn´ı objekt, administr´ atorsk´ y kalendáˇr atp.), nicménˇe jeho moˇznosti si budeme demonstrovat na jeho nejtypiˇctˇejˇs´ım uˇzit´ı – na kalendáˇri aktuálnˇe pˇrihláˇseného uˇzivatele (funkce M˚ uj kalend´ aˇr ). Kalendáˇr je zobrazen na Obrázku C.4.

Obrázek C.4: Mˇes´ıˇcn´ı zobrazen´ı kalendáˇre.

120



Kalend´ aˇr umoˇzn ˇuje tˇri druhy pohledu – mˇes´ıˇcn´ı, t´ ydenn´ı a denn´ı. Na vˇsech tˇechto pohledech jsou pak zobrazeny vytvoˇrené rezervace. Mezi zobrazen´ ymi ˇcasov´ ymi u ´seky je moˇzné se posouvat pomoc´ı posuvn´ ych tlaˇc´ıtek v pravém horn´ım rohu kalend´ aˇre, nebo lze okamˇzitˇe zobrazit aktuáln´ı den. Na Obrázku C.5 je znázornˇen t´ ydenn´ı pohled kalend´ aˇre. Pohled je posunovateln´ y v ˇcase a jednotlivé události rezervac´ı (kdy je kaˇzd´ a na jin´ y objekt) se mohou pˇrekr´ yvat.

Obrázek C.5: T´ ydenn´ı zobrazen´ı kalendáˇre.

Vytvoˇ ren´ı rezervace Rezervaci je moˇzné vytvoˇrit pouh´ ym kliknut´ım na jakékoliv m´ısto v kalendáˇri, ve kterém nen´ı ˇz´ adn´ a jin´ a rezervace. Následné dialogové okno umoˇzn ˇuje definovat ˇcasy rezervace (jsou pˇrednastavené podle m´ısta kliknut´ı do kalendáˇre) a periodicitu (Obr. C.6). D´ ale je nutné ze seznamu vybrat objekt, na kter´ y má b´ yt rezervace vytvoˇrena. V seznamu objekt˚ u je moˇzné vyhledávat stejn´ ym zp˚ usobem jako v tabulce objekt˚ u a pokud si uˇzivatel nen´ı jist identitou objektu, je moˇzné pˇr´ımo ze seznamu otevˇr´ıt nové okno s profilem objektu.

121



Obrázek C.6: Vytvoˇren´ı rezervace. Dialogové okno vytvoˇren´ı objektu se m˚ uˇze liˇsit v závislosti na zobrazeném kalendáˇri. Napˇr´ıklad role Administr´ ator mus´ı v nˇekter´ ych pˇr´ıpadech definovat i uˇzivatele rezervace. Jeho v´ ybˇer je implementován obdobnˇe jako v´ ybˇer objektu.

Editace rezervace Rezervaci je moˇzné editovat hned nˇekolika zp˚ usoby. Uˇzivatel m˚ uˇze rezervace pˇr´ımo v kalend´ aˇri za pomoci kurzoru myˇsi roztahovat“ nebo smrˇst’ovat“ a t´ım mˇenit ” ” jejich ˇcasové rozpˇet´ı. To je moˇzné ve vˇsech pohledech kalendáˇre. Pokud chce uˇzivatel zachovat ˇcasové rozpˇet´ı a pouze zmˇenit pozici rezervace v kalendáˇri, je moˇzné jednotlivé rezervace pˇret´ ahnout“ mezi hodinami, dny, t´ ydny atp. Pokud dojde ke ” kolizi rezervace, nen´ı tato editace uskuteˇcnˇena. Dalˇs´ım zp˚ usobem editace je kliknut´ı na samotnou rezervaci. Následné dialogové okno umoˇzn ˇuje kromˇe samotné editace ˇcasového u ´seku rezervace také zmˇenu platnosti periody a dalˇs´ı ˇradu akc´ı vˇcetnˇe u ´plného odstranˇen´ı rezervace, jej´ıho vyzvednut´ı a vr´ acen´ı a d´ ale také informuje o stavu rezervace (Obr. C.7). Tlaˇc´ıtka tˇechto akc´ı mohou b´ yt zaˇsedivˇena, pokud je napˇr. rezervace nevyzvednuteln´ a, um´ıstˇen´ a v minulosti atp. Dostupnost akc´ı se ˇr´ıd´ı poˇzadavky kladen´ ymi na systém. Také pro role Spr´ avce rezervac´ı a Administr´ ator nab´ız´ı toto okno dalˇs´ı moˇznosti editace, jako je napˇr´ıklad zmˇena vlastn´ıka rezervace.

122



Obrázek C.7: Editace rezervace.

C.1.4

Administrace

Pokud se uˇzivatel pˇrihl´ as´ı jako Administr´ ator, systém zpˇr´ıstupn´ı dalˇs´ı moˇznosti správy systému. Zejména je moˇzné editovat a mazat objekty, tˇr´ıdy objekt˚ u a uˇzivatelské u ´ˇcty. Jak ukazuje Obr´ azek C.8, oproti bˇeˇzn´ ym uˇzivatel˚ um také nar˚ ustá poˇcet moˇzn´ ych akc´ı. Odstranˇen´ı jakkoliv poloˇzky je realizováno jako v´ ybˇer jedné nebo v´ıce poloˇzek a n´ asledné kliknut´ı na tlaˇc´ıtko Odstranit, které je um´ıstˇeno v patiˇcce tabulky. N´ aslednˇe je nutné volbu jeˇstˇe jednou potvrdit v dialogovém oknu.

Obrázek C.8: V´ıcepoloˇzkové administraˇcn´ı zobrazen´ı objekt˚ u. Obdobnˇe je realizov´ ano vytv´ aˇren´ı poloˇzek. Pˇri kliknut´ı na tlaˇc´ıtko Nový, um´ıstˇeného v patiˇcce tabulky, dojde k pˇresmˇerován´ı na vstupn´ı formuláˇr nové poloˇzky.

123


C.2

Aplikace RatDroid

Aplikace RatDroid

Mobiln´ı aplikace RatDroid nenab´ız´ı ˇzádné moˇznosti administrace systému, pouze základn´ı spr´ avu vlastn´ıch obl´ıben´ ych poloˇzek a rezervac´ı. Na Obrázku C.9 je znázornˇena hlavn´ı obrazovka aplikace, tvoˇr´ıc´ı základn´ı navigaˇcn´ı menu aplikace.

Obrázek C.9: Hlavn´ı obrazovka aplikace.

C.2.1

Nastaven´ı

Narozd´ıl od webového rozhran´ı vyˇzaduje mobiln´ı aplikace základn´ı nastaven´ı direktiv pro pˇripojen´ı k centr´ aln´ımu serveru. Pokud se pˇripojen´ı k serveru nezdaˇr´ı, jsou vypnuty vˇsechny navigaˇcn´ı prvky na obrazovky, které pˇripojen´ı k serveru explicitnˇe vyˇzaduj´ı. Jednotlivé poloˇzky nastaven´ı sleduj´ı obvykl´ y scénáˇr nastaven´ı pˇripojen´ı (URL, Port atp.), d´ ale je nutné zadat jména heslo uˇzivatele. Je moˇzné

124


Aplikace RatDroid

kdykoliv za bˇehu aplikace zmˇenit jméno a heslo uˇzivatele. Aplikace zmˇenu uˇzivatelského jména rozpozn´ a a pˇrepne kontext uˇzivatele (tj. kalendáˇre, obl´ıbené poloˇzky atp.).

C.2.2

Funkce Prohl´ıˇ zet“ ”

Aplikace umoˇzn ˇuje prohled´ avat seznam existuj´ıc´ıch objekt˚ u. Je moˇzné bud’ pouˇz´ıt ˇcteˇcku QR k´ od˚ u, v´ ybˇer z obl´ıben´ ych objekt˚ u pˇrihláˇseného uˇzivatele nebo pouˇz´ıt vyhled´ av´ an´ı. Obrazovka na Obrázku C.10 ukazuje situaci po otevˇren´ı obrazovky s funkc´ı Prohl´ıˇzet.

Obrázek C.10: Prohl´ıˇzen´ı objekt˚ u. V´ ybˇer z dialogového menu reprezentuje akci v´ ybˇeru objekt˚ u, které se po dokonˇcen´ı akce zobraz´ı v seznamu leˇz´ıc´ım pod t´ımto dialogov´ ym menu. Menu je kdykoliv moˇzné vyvolat znovu stisknut´ım (hardwarového nebo emulovaného) tlaˇc´ıtka Menu,

125


Aplikace RatDroid

a t´ım zmˇenit aktu´ aln´ı selekci objekt˚ u. V´ ybˇerem objektu ze seznamu dojde k vyvolán´ı obrazovky s profilem objektu (viz dále).

C.2.3

Funkce Obl´ıben´ e“ ”

Aplikace umoˇzn ˇuje zobrazen´ı vˇsech obl´ıben´ ych objekt˚ u pˇr´ımo z hlavn´ıho menu aplikace. Pˇri dotyku na poloˇzku ze seznamu objekt˚ u dojde k zobrazen´ı profilu tohoto objektu obdobnˇe jako v pˇr´ıpadˇe obrazovky Prohl´ıˇzet.

C.2.4

Profil objektu

Profil objektu obsahuje vˇsechny d˚ uleˇzité informace o objektu. Souˇcasnˇe v pravém horn´ım rohu obsahuje sadu akc´ı, které je moˇzné nad objektem provést – pˇridat nebo odebrat jej ze seznamu obl´ıben´ ych poloˇzek, zobrazit jeho kalendáˇr nebo jej vyzvednout (viz d´ ale).

Obrázek C.11: Profil objektu. 126


C.2.5

Aplikace RatDroid

Funkce Vrat’“ ”

Aplikace umoˇzn ˇuje vracen´ı objekt˚ u podle pravidel uveden´ ych ve specifikaci poˇzadavk˚ u. Narozd´ıl od webového rozhran´ı tak ale nedˇelá prostˇrednictv´ım kalendáˇre, ale za pomoci seznamu vˇsech objekt˚ u, které si dan´ y uˇzivatel v minulosti vyp˚ ujˇcil a nepotvrdil jejich vr´ acen´ı (pokud to objekt vyˇzaduje). Pouh´ ym dotykem poloˇzky ze seznamu dojde k jej´ımu vr´ acen´ı a návratu na hlavn´ı obrazovku.

C.2.6

Kalend´ aˇ r

V mobiln´ı aplikaci existuj´ı dva kalendáˇre – vázan´ y na pˇrihláˇseného uˇzivatele a vázan´ y na objekt. Uˇzivatelsk´ y kalendáˇr je moˇzné zobrazit z hlavn´ıho menu navigaˇcn´ım tlaˇc´ıtkem M˚ uj kalend´ aˇr, kalendáˇr objektu pak lze zobrazit z profilu tohoto objektu akˇcn´ım tlaˇc´ıtkem. Kalendáˇr se skládá z mˇes´ıˇcn´ıho (Obr. C.12) a denn´ıho pohledu.

Obrázek C.12: Mˇes´ıˇcn´ı pohled kalendáˇre.

127


Aplikace RatDroid

Mˇes´ıˇcn´ı pohled zobrazuje ˇcervenˇe vˇsechny dny, ve kter´ ych je vytvoˇrena nˇejaká rezervace. Zn´ azorˇ nuje také poˇcet tˇechto rezervac´ı v jednom dni. Navigace mezi jednotliv´ ymi mˇes´ıci je moˇzn´ a pomoc´ı boˇcn´ıch navigaˇcn´ıch ˇsipek. Pˇri dotyku nˇekterého dne z kalend´ aˇre dojde k vyvolán´ı denn´ıho pohledu kalendáˇre (Obr. C.13).

Obrázek C.13: Denn´ı pohled kalendáˇre. Denn´ı pohled vypad´ a pˇribliˇznˇe jako kalendáˇr webového rozhran´ı a také se s n´ım obdobnˇe pracuje. Je moˇzné s n´ım dotykov´ ymi gesty libovolnˇe vertikálnˇe posouvat. Pˇri dotyku na m´ısto, kde nen´ı ˇza´dná rezervace, dojde k vyvolán´ı obrazovky urˇcené k vytvoˇren´ı rezervace (pokud se uˇzivatel nesnaˇz´ı vytvoˇrit rezervaci v minulosti“). ” Pˇri dotyku samotné rezervace se poté zobraz´ı editaˇcn´ı obrazovka.

C.2.7

Vytv´ aˇ ren´ı a editace rezervace

Obrazovky vytv´ aˇren´ı a editace rezervace jsou velmi podobné dialog˚ um na centráln´ım serveru. Jedin´ ym rozd´ılem je snaha maximálnˇe vyuˇz´ıt prostˇredky doty-

128


Aplikace RatDroid

kov´ ych displej˚ u mobiln´ıch zaˇr´ızen´ı (Obr. C.14). Pro vytvoˇren´ı rezervace je vˇzdy nejprve nutné definovat rezervovan´ y objekt – z pozice kalendáˇre objektu je jiˇz objekt vlastnˇe identifikov´ an, nicménˇe v kalendáˇri uˇzivatele se pˇred samotnou obrazovkou urˇcenou k vytvoˇren´ı objektu zobraz´ı komponenta podobná dˇr´ıve zm´ınˇené obrazovce Prohl´ıˇzet, ve které uˇzivatel mus´ı rezervovan´ y objekt vybrat.

Obrázek C.14: Denn´ı pohled kalendáˇre. Obrazovka pro editaci rezervac´ı pˇrináˇs´ı oproti webovému rozhran´ı jednu moˇznost nav´ıc – je moˇzné zobrazit vˇsechny ˇcásti periodické rezervace v jedné obrazovce a pˇr´ımo nastavovat jejich platnost (Obr. C.15). Je to kompromis v˚ uˇci menˇs´ım displej˚ um mobiln´ıch zaˇr´ızen´ı, kdy nen´ı zcela jednoduché se zorientovat v rozsáhlém kalend´ aˇri. Navigaˇcn´ı tlaˇc´ıtko pro zobrazen´ı této obrazovky je v pravém horn´ım rohu editaˇcn´ı obrazovky spolu s tlaˇc´ıtkem pro odstranˇen´ı rezervace.

129


Aplikace RatDroid

Jinak je obrazovka editace rezervace prakticky totoˇzná s editaˇcn´ım dialogov´ ym oknem ve webovém formul´ aˇri, pouze nenab´ız´ı moˇznosti vyzvednut´ı a vrácen´ı. Ty byly v mobiln´ı aplikaci implementovány jin´ ym zp˚ usobem.

Obrázek C.15: Editace platnosti periodick´ ych rezervac´ı.

C.2.8

Funkce Vyzvedni“ ”

Tato funkce je dostupn´ a pˇr´ımo z hlavn´ı obrazovky aplikace a funguje odliˇsnˇe neˇz je tomu u webového rozhran´ı. Jej´ım c´ılem je p˚ ujˇcován´ı a vyzvedáván´ı objekt˚ u co nejv´ıce urychlit. Nejprve se zobraz´ı komponenta podobná dˇr´ıve zm´ınˇené obrazovce Prohl´ıˇzet, ve které mus´ı uˇzivatel urˇcit vyzvedávan´ y objekt (pokud uˇzivatel vyzvedává objekt pˇr´ımo z profilu objektu, tato komponenta se nezobraz´ı). Po vybrán´ı objektu dojde k automatického vyhledán´ı nejbliˇzˇs´ı vyzvednutelné rezervace uˇcinˇené na tento objekt. Pokud taková rezervace existuje, je automaticky vyzvednuta a po uˇzivateli nen´ı vyˇzadov´ ana ˇzádná dalˇs´ı akce. V opaˇcném pˇr´ıpadˇe je uˇzivatel

130


Aplikace RatDroid

pˇresmˇerov´ an na obrazovku urˇcenou pro vytvoˇren´ı rezervace, kde si m˚ uˇze zvolit ˇcas konce novˇe vzniknuvˇs´ı rezervace. Takové rezervace nelze vytváˇret jako periodické a jsou automaticky vedeny jako platné a vyzvednuté. Funkce Vyzvedni neumoˇzn ˇuje vytváˇret rezervace na objekty, které nevyˇzaduj´ı potvrzen´ı vyzvednut´ı.

131

D Administrátorská dokumentace V této pˇr´ıloze bude uveden struˇcn´ y manuál k nasazen´ı vˇsech ˇcást´ı informaˇcn´ıho systému RAT.

D.1

Nasazen´ı webov´ e aplikace

Aplikace je distribuov´ ana jako WAR (Web application ARchive) soubor. Pro bˇeh je vyˇzadov´ an webov´ y kontejner Tomcat ve verzi 7. Jiné kontejnery nebyly testovány a jejich pouˇzit´ı je tedy bez z´ aruky. Dále je potˇreba nainstalovat Java bˇehové prostˇred´ı v minim´ aln´ı verzi 7. Pro kompilaci a sestaven´ı WAR souboru pˇr´ımo ze zdrojov´ ych kód˚ u je dostupn´ y Maven skript. Vˇsechny závislosti spravuje také Maven. Pˇred samotn´ ym spuˇstˇen´ım kontejneru je vˇsak nutné nakonfigurovat zejména pˇr´ıstup do datab´ aze, zabezpeˇcen´ı pˇrenosu a dalˇs´ı nastaven´ı.

D.1.1

Pˇ r´ıstup do datab´ aze

Nejprve je nutné nakonfigurovat datovou vrstvu. V aplikaci nen´ı integrována ˇzádná relaˇcn´ı datab´ aze a je tedy na bedrech administrátora jej´ı nasazen´ı a patˇriˇcné nastaven´ı aplikace. Konfiguraˇcn´ı direktivy datové vrstvy aplikace jsou um´ıstˇeny v souboru WEB-INF/classes/persistence.xml. Doporuˇcená relaˇcn´ı databáze pro bˇeh aplikace je H2 Database Engine. Aplikace také jiˇz obsahuje patˇriˇcné knihovny potˇrebné pro pˇripojen´ı k této databázi. Je vˇsak moˇzné pouˇz´ıt libovolnou implementaci, jej´ıˇz dialekt framework Hibernate podporuje. Pro vytvoˇren´ı struktury databáze je moˇzné vyuˇz´ıt mapován´ı frameworku Hibernate. Pˇred prvn´ım spuˇstˇen´ım je nutné v konfiguraˇcn´ım souboru odkomentovat“ ” následuj´ıc´ı ˇr´ adek:

<prop key="hibernate.hbm2ddl.auto">update

Hibernate poté s´ am vytvoˇr´ı relaˇcn´ı strukturu vˇcetnˇe vˇsech vazeb (po vytvoˇren´ı struktury datab´ aze ve vˇsak nutné ˇrádek znovu zakomentovat). Následnˇe je nutné se libovoln´ ym konektorem pˇripojit do databázového systému a spustit následuj´ıc´ı SQL dotaz (syntaxe se m˚ uˇze liˇsit v závisloti na pouˇzitém databázovém systému):

132

Administrátorská dokumentace

Nasazen´ı webové aplikace

INSERT INTO "PUBLIC"."USER" ("USERID", "FIRSTNAME", "SURNAME", "EMAIL", "NICKNAME","PASSHASH", "ROLE", "IMPLEMENTOR") VALUES(0, ’admin’,’admin’, ’’, ’admin’,’21232f297a57a5a743894a0e4a801fc3’, ’ADMIN’, ’DEFAULT’) Spuˇstˇen´ım dotazu bude vytvoˇren administrátorsk´ y u ´ˇcet admin s heslem admin. Tento u ´ˇcet je pak moˇzné pouˇz´ıt pro vytvoˇren´ı dalˇs´ıch uˇzivatelsk´ ych nebo administrátorsk´ ych u ´ˇct˚ u.

Indexov´ an´ı datab´ aze Nˇekteré datab´ azové entity jsou indexovány enginem Hibernate Search. Protoˇze jsou tyto indexy uchov´ av´ any mimo databázi, je nutné definovat cestu k jejich uloˇzen´ı. To je moˇzné ve v´ yˇse zm´ınˇeném konfiguraˇcn´ım souboru v rámci následuj´ıc´ı direktivy: <prop key="hibernate.search.default.indexBase">cesta_k_indexum

D.1.2

Konfigurace REST rozhran´ı

Pokud dojde pˇri bˇehu webové REST sluˇzby k chybˇe, aplikace vygeneruje o této události zpr´ avu a pˇriloˇz´ı ji k HTTP odpovˇedi. Do této zprávy je moˇzné vkládat nˇekter´ a uˇziteˇcn´ a data pro ladˇen´ı aplikace. Jedn´ım z nich je i e-mailová adresa (nebo URL bug-tracking systému), kam m˚ uˇze klientská strana hlásit chybu serveru. Tato direktiva se nach´ az´ı v konfiguraˇcn´ım souboru WEB-INF/RAT-servlet.xml a vypadá následovnˇe: <property name="defaultMoreInfoUrl" value="mailto:email">

D.1.3

Nastaven´ı syst´ emu rezervac´ı

V souboru WEB-INF/classes/rat.properties jsou základn´ı konfiguraˇcn´ı direktivy rezervac´ı. Je ˇz´ adouc´ı provést konfiguraci tˇechto direktiv hned pˇri nasazen´ı systému. N´ asledné zmˇeny této konfigurace nejsou podporovány zejména proto, protoˇze nastaven´ı systému si vˇsichni mobiln´ı klienti stáhnou ze serveru pˇri prvn´ım svém spuˇstˇen´ı. N´ asleduj´ıc´ı v´ ypis souˇcasnˇe ukazuje pˇrednastavené hodnoty, které jsou pouˇzity v okamˇziku, kdy se nezdaˇr´ı parsován´ı konfiguraˇcn´ıho souboru (tato událost je zalogov´ ana):

133


Nasazen´ı webové aplikace

reservation.duration.minimum=60 (minuty) - jedna hodina reservation.duration.maximum=10080 (minuty) - jeden t´ yden reservation.periodical.maximum=52 (t´ ydny) reservation.expiration.limit=10 (minuty)

D.1.4

Nastaven´ı jazyka aplikace

Pro webové rozhran´ı je podporována ˇcestina a angliˇctina. Zmˇena jazyka za bˇehu aplikace nen´ı moˇzn´ a. Mezi jazyky lze programovˇe pˇrep´ınat v konfiguraˇcn´ım souboru WEB-INF/faces-config.xml: <default-locale>cs <supported-locale>en

D.1.5

Konfigurace SSL certifik´ atu

Systém vyˇzaduje speci´ aln´ı konfiguraci SSL certifikátu zejména proto, ˇze Android velmi obt´ıˇznˇe pracuje s certifik´ aty, které nebyly ovˇeˇreny ˇzádnou certifikaˇcn´ı autoritou. Pro vytvoˇren´ı certifik´ atu (kter´ y bude uloˇzen´ y v tzv. keystore) je nutné pouˇz´ıt knihovnu Bouncy Castle: 1. Nejprve je nutné st´ ahnout Bouncy Castle knihovnu, napˇr´ıklad z oficiáln´ıho Maven repozit´ aˇre (bcprov-ext-jdkxx-1.xx.jar). 2. D´ ale se tato knihovna mus´ı nakop´ırovat do sloˇzek JAVA_HOME/jre/lib/ext a (pokud existuje) JAVA_HOME/lib/ext. 3. Do vˇsech konfiguraˇcn´ıch soubor˚ u java.security v JAVA_HOME je nutné pˇridat n´ asleduj´ıc´ı ˇr´ adku: security.provider.7=org.bouncycastle.jce.provider.BouncyCastle Provider 4. Nyn´ı je moˇzné vygenerovat keystore s certifikátem, a to následovnˇe: keytool -genkey -alias RAT -keystore RAT.keystore -storepass heslo -storetype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider

134


Nasazen´ı mobiln´ı aplikace RatDroid

Gener´ ator se bude pt´ at na nˇekteré dalˇs´ı u ´daje, d˚ uleˇzit´ y je vˇsak pouze tzv. CN, neboli obecné jméno. Zde je nutné zadat doménu, na které bude server s aplikac´ı spuˇstˇen – bez tohoto kroku se nelze k serveru pˇripojit z mobiln´ı aplikace. Je také nutné si poznamenat pˇr´ıstupovˇe heslo k vygenerovanému RAT.keystore. Nyn´ı je nutné konfigurovat Tomcat spolu s Bouncy Castle a vygenerovan´ ym keystore, a to vloˇzen´ım n´ asleduj´ıc´ı direktivy do konfiguraˇcn´ıho souboru server.xml, kter´ y je um´ıstˇen v Tomcat distribuci:

T´ım vˇsak konfigurace nekonˇc´ı. Vygenerovan´ y keystore je nutné také zakomponovat do mobiln´ı aplikace Ratdroid (viz dále).

D.1.6

Nastaven´ı Cookies

Posledn´ım krokem je nastaven´ı Cookies. Tˇemi je mimo jiné pˇrenáˇseno sessionId a je nutné nastavit jejich Domain-Name. Bez této konfigurace nefunguje mobiln´ı aplikace RatSharp, protoˇze Windows Phone Cookies bez doménového jména nepodporuje. Nastaven´ı je v konfiguraˇcn´ım souboru META-INF/context.xml:

D.2


Aplikace je urˇcena pro Android 4.1.2 a vyˇsˇs´ı. Mobiln´ı aplikaci je bohuˇzel vzhledem k integraci keystore nutné vˇzdy sestavit ze zdrojového kódu. Pro sestaven´ı je opˇet moˇzné pouˇzit Maven. Aplikace vyuˇz´ıvá knihovny Caldroid, která je um´ıstˇena na pˇriloˇzeném médiu. Vˇsechny ostatn´ı závislosti spravuje Maven.

135


D.2.1


Integrace keystore

Projekt aplikace je nutné otevˇr´ıt v libovolném v´ yvojovém prostˇred´ı, ve kterém je moˇzné vyv´ıjet aplikace pro mobiln´ı platformu Android. Následnˇe je tˇreba do sloˇzky res/raw nakop´ırovat pod názvem rat_keystore v pˇredchoz´ım kroku vytvoˇren´ y Bouncy Castle keystore. Ve tˇr´ıdˇe MyHttpClient je poté statická konstanta RAT_KEYSTORE_PASSWORD, kterou je nutné inicializovat na heslo pro pˇr´ıstup do keystore. Následnˇe je moˇzné aplikaci sestavit a distribuovat ji jako APK bal´ıˇcek.

136

E Obsah pˇriloˇzeného média Souˇcást´ı této pr´ ace je rovnˇeˇz i pamˇet’ové médium (DVD) obsahuj´ıc´ı tyto adresáˇre a soubory: - readme.txt – textov´ y soubor obsahuj´ıc´ı popis a v´ yznam jednotliv´ ych adres´ aˇr˚ u na médiu. - /bin – obsahuje WAR soubor s aplikac´ı centráln´ıho serveru. - /doc – obsahuje PDF verzi této práce. - /src – obsahuje zdrojové kódy mobiln´ı aplikace RatDroid a webové aplikace RatServer. - /rest – obsahuje XSD schémata XML reprezentace dat, které jsou pˇrenáˇseny v r´ amci REST komunikace.

137

Literatura [1] GALUSHA, C. Getting started with IT asset management. IT Professional [online]. vol. 3, issue 3, s. 3740 [cit. 2013-05-10]. DOI: 10.1109/6294.939973. Dostupné z: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=939973 [2] MANOHARAN, Sathiamoorthy. On GPS Tracking of Mobile Devices. 2009 Fifth International Conference on Networking and Services [online]. IEEE, 2009, s. 415-418 [cit. 2013-04-17]. DOI: 10.1109/ICNS.2009.103. Dostupné z: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4976795 [3] SPIRITO, M.A. On the accuracy of cellular mobile station location estimation. IEEE Transactions on Vehicular Technology [online]. roˇc. 50, ˇc. 3, s. 674685 [cit. 2013-04-17]. ISSN 0018-9545. DOI: 10.1109/25.933304. Dostupné z: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=933304 [4] OLIVER, R. Why the BYOD boom is changing how we think about business it. Engineering & Technology. 2012, roˇc. 7, ˇc. 10, s. 28. Dostupné z: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6413056&isnum ber=6355539 [5] INGKHWAN, A. WI-FI Tracker: an Organization WI-FI Tracking System. 2006 Canadian Conference on Electrical and Computer Engineering [online]. IEEE, 2006, s. 231-234 [cit. 2013-04-17]. DOI: 10.1109/CCECE.2006.277387. Dostupné z: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4054833 [6] YEUNG, Wilson M. a Joseph K. NG. Wireless LAN Positioning based on Received Signal Strength from Mobile device and Access Points. 13th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications (RTCSA 2007). IEEE, 2007, roˇc. 7, ˇc. 10, s. 131-137. ISSN 1533-2306. DOI: 10.1109/RTCSA.2007.73. Dostupné z: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4296845 [7] AGRAWAL, Rohit a Ashesh VASALYA. Bluetooth Navigation System using Wi-Fi Access Points. 2012, 8 s. Dostupné z: http://arxiv.org/abs/1204.1748

138

LITERATURA

LITERATURA

[8] GOZICK, Brandon, Kalyan Pathapati SUBBU, Ram DANTU a Tomyo MAESHIRO. Magnetic Maps for Indoor Navigation. IEEE Transactions on Instrumentation and Measurement [online]. roˇc. 60, ˇc. 12, s. 3883-3891 [cit. 2013-04-18]. ISSN 0018-9456. DOI: 10.1109/TIM.2011.2147690. Dostupné z: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5773083 [9] RIEHLE, T. H., S. M. ANDERSON, P. A. LICHTER, J. P. CONDON, S. I. SHEIKH a D. S. HEDIN. Indoor waypoint navigation via magnetic anomalies. 2011 Annual International Conference of the IEEE Engineering in Medicine and Biology Society [online]. IEEE, 2011, s. 53155318 [cit. 2013-04-18]. DOI: 10.1109/IEMBS.2011.6091315. Dostupné z: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6091315 [10] INDOORATLAS. IndoorAtlas [online]. 2013 [cit. 2013-04-18]. Dostupné z: http://www.indooratlas.com [11] CHUNG, Jaewoo, Matt DONAHOE, Chris SCHMANDT, Ig-Jae KIM, Pedram RAZAVAI a Micaela WISEMAN. Indoor location sensing using geomagnetism. Proceedings of the 9th international conference on Mobile systems, applications, and services - MobiSys ’11 [online]. New York, New York, USA: ACM Press, 2011, s. 141- [cit. 2013-04-18]. DOI: 10.1145/1999995.2000010. Dostupné z: http://portal.acm.org/citation.cfm?doid=1999995.2000010 [12] OHBUCHI, E., H. HANAIZUMI a LIM AH HOCK. Barcode Readers using the Camera Device in Mobile Phones. 2004 International Conference on Cyberworlds [online]. IEEE, 2004, s. 260-265 [cit. 2013-04-18]. DOI: 10.1109/CW.2004.23. Dostupné z: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1366183 [13] WANT, R. An Introduction to RFID Technology. IEEE Pervasive Computing [online]. roˇc. 5, ˇc. 1, s. 25-33 [cit. 2013-0418]. ISSN 1536-1268. DOI: 10.1109/MPRV.2006.2. Dostupné z: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1593568 [14] NFC Phones list, all available handsets: Complete list with all mobile phones with nfc chip. List of NFC Phones, availability by country and by carrier [online]. 2013 [cit. 2013-04-18]. Dostupné z: http://www.nfc-phones.org/summarylist-of-all-available-nfc-phones/ [15] ABLESON, W. Android in action. 3rd ed. Greenwich, Conn.: Manning, c2012, xxviii, 632 p. ISBN 16-172-9050-5. [16] HTML 5.1 Nightly: A vocabulary and associated APIs for HTML and XHTML. World Wide Web Consortium (W3C) [online]. 2013, 29.4.2013 [cit. 2013-04-29]. Dostupné z: http://www.w3.org/html/wg/drafts/html/master

139

LITERATURA

LITERATURA

[17] Introduction to Mobile Development: Developing Mobile Applications using Xamarin. Xamarin: Build cross-platform iOS, Android, Mac and Windows apps with C# and .NET [online]. 2013 [cit. 2013-04-29]. Dostupné z: http://docs.xamarin.com/guides/crossplatform/getting started/introduction to mobile development [18] DAY, J.D. a H. ZIMMERMANN. The OSI reference model. Proceedings of the IEEE [online]. roˇc. 71, ˇc. 12, s. 1334-1340 [cit. 201304-30]. ISSN 0018-9219. DOI: 10.1109/PROC.1983.12775. Dostupné z: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1457043 ¨ [19] LIU, Ling a M OZSU. Encyclopedia of database systems. New York: Springer, c2009, 5 v. (lxix, 3749 p.). ISBN 978-038-7496-160. [20] FOWLER, Martin. Patterns of enterprise application architecture. Boston: Addison-Wesley, c2003, xxiv, 533 p. ISBN 03-211-2742-0. [21] ELLIOTT, James, Ryan FOWLER a Tim O’BRIEN. Harnessing Hibernate. Sebastopol: O’Reilly, 2008, xiv, 363 s. ISBN 978-0-596-51772-4. [22] JOEL MURACH, Andrea Steelman, Ryan FOWLER a Tim O’BRIEN. Murach’s Java servlets and JSP: training. 2nd ed. Fresno, CA: Mike Murach, 2008, xiv, 363 s. ISBN 18-907-7444-8. [23] BERGSTEN, Hans, Ryan FOWLER a Tim O’BRIEN. JavaServer faces: training. 2nd ed. Sebastopol, CA: O’Reilly, c2004, xiv, 589 p. ISBN 05-960-0539-3. [24] HEWITT, Eben, Ryan FOWLER a Tim O’BRIEN. Java SOA cookbook: training. 1st ed. Sebastopol, Calif.: O’Reilly, c2009, xxiv, 714 p. ISBN 05-9652072-7. [25] SOAP Specifications. World Wide Web Consortium (W3C) [online]. 2013 [cit. 2013-05-07]. Dostupné z: http://www.w3.org/TR/soap [26] HTTP/1.1: Method Definitions. World Wide tium (W3C) [online]. 2013 [cit. 2013-05-05]. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Web ConsorDostupné z:

[27] WALLS, Craig. Spring in action. 3rd ed. Shelter Island: Manning, c2011, xxiii, 400 p. ISBN 19-351-8235-8.

140

Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky. Mobilní aplikace pro rezervace objektů

Recommend Documents