Masarykova univerzita Fakulta informatiky. Rezervační systém. Bakalářská práce Tomáš Blaho

Masarykova univerzita Fakulta informatiky

Rezervační systém Bakalářská práce

2005

Tomáš Blaho

Bakalářská práce

Rezervační systém

Čestné prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, kterou jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsme při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

-------------------------------------

Strana 2



Poděkování Na tomto místě bych se rád poděkoval vedoucímu mojí bakalářské práce Ing. Petrovi Adámkovi za čas, který mi věnoval, za pomoc a rady, které mi poskytl během psaní bakalářské práce. Dál bych se rád poděkoval Petrovi Juhászovi a Kristiánovi Mandíkovi za užitečné rady poskytnuté při psaní této práce.

Strana 3



Shrnutí Předmětem této práce je popsat funkcionalitu komplexního přístupového a rezervačního systému a vypracovat řešení na jednotlivé části problematiky. Druhá část práce je věnovaná psaní webové aplikace v jazyce Java, která prezentuje jednu z možností implementace rezervačního systému na základě níže popsaných znalostí. První kapitola seznamuje čtenáře s obecnou problematikou přístupových systémů. V další části jsou popsané jednotlivé komponenty konkrétního systému. Dále jsou rozebrané jednotlivé možnosti při výběru identifikačního média. Na závěr je stručně rozepsán postup při implementaci rezervační aplikace a některé plánované úpravy v systému.

Strana 4



Klíčová slova Rezervace, SQL, databáze, vstupenka, karta, terminál, server

Strana 5



Obsah 1

Úvod .................................................................................................................. 7

2

O systému........................................................................................................... 8

3

4

5

2.1

Hardware ................................................................................................... 8

2.2

Software..................................................................................................... 9

2.3

Registrace komponentů ............................................................................ 13

Použitelná média .............................................................................................. 14 3.1

Čárový kód............................................................................................... 14

3.2

Magnetický pás ........................................................................................ 14

3.3

RFID čip .................................................................................................. 14

3.4

Čipové karty............................................................................................. 14

3.5

Dallas TouchMemory............................................................................... 15

Pojmy............................................................................................................... 16 4.1

Areály a zóny ........................................................................................... 16

4.2

Měny a kredity ......................................................................................... 17

4.3

Transakce a uzávěrky ............................................................................... 17

4.4

Definice sazeb a výpočet ceny .................................................................. 18

Webová aplikace pro CAC................................................................................ 20 5.1

Účel aplikace............................................................................................ 20

5.2

Příprava.................................................................................................... 20

5.3

Struktura programu .................................................................................. 21

5.4

Vzhled programu...................................................................................... 21

6

Plány do budoucna............................................................................................ 22

7

Závěr ................................................................................................................ 23

8

Literatura.......................................................................................................... 24

Strana 6



1 Úvod Žijeme v éře informačních systémů. Objednám si knihu přes internet – pracuji s informačním systémem. Chci zkontrolovat kolik jsem natankoval, jestli už z těch věrnostních bodů můžu zakoupit tu sadu nářadí – používám informační systém. Platím přes e-banking, rezervuji jízdenku na autobus do Prahy anebo chci zjistit jak dopadla ta zkouška z minulého týdne – vždy používám informační systém. Informační systémy jsou součástmi našeho života. A jak si lidé zvyknou na používání těchto systému, tak je stále větší výzvou uspokojit prostého uživatele. Předmětem této práce není podrobně napsat postup implementace jednotlivých částí konkrétního systému, hlavně z kapacitních důvodu. Mým cílem je obeznámit čtenáře, jaké funkce a parametre musí mít takový systém. K tomuto účelu používám systém Cerberus Access Control, jako prostředek na čem jsem své zkušenosti získal. Tento přístupový a rezervační systém je výrobkem firmy Identcode, ale největší část návrhu a implementace systému jsem dělal já. Podle těchto znalostí se pokusím čtenáři alespoň povrchově popsat problematiku takových systémů. Nejdůležitější vlastností přístupového systému je jeho robustnost. Samozřejmě, v ideálním případe musí každý program fungovat správně a spolehlivě a navíc musí být příjemný pro uživatele, ale bez dostatečné flexibility každá instalace takovéto systém bude dělat potíže. Samozřejmě, každý kupec takového systému má své jedinečné představy, a nemá rád odpovědí typu „nelze to udělat“.

Strana 7



2 O systému Systém Cerberus Access Control byl navržen tak, aby byl vhodný pro nejrůznější aplikace: parkovné domy, kina, vleky, galerie, stadiony nebo plovárně. Systém byl stavěn primárně pro aplikace, kde zákazník platí za pobyt v kontrolovaném areálu. Samozřejmě lze vydat neplacené karty i pro obsluhu. Kromě základních funkcí výdeje, validace a rezervaci vstupenek systém umožní i další funkce, jako ovládání přístupových terminálu, bezobslužných pokladen a kamer, správu uživatelů a zákazníků, zapůjčení různých věcí nebo použití a dobíjení kreditů na vstupenkách. Komponenty systému lze rozdělit na dvě hlavní části: softwarové a hardwarové.

2.1

Hardware

Systémy jako je i CAC jsou velice závislé na použití hardwaru. Software sám nemůže číst nebo zapisovat na používané médium nebo kontrolovat průchody bez potřebného hardwaru. Podpora zařízení různých výrobců je žádoucí, protože to, že jaké zařízení bude vybrané pro danou aplikaci závisí na mnoha faktorech, z kterých jsou nejvýznamnější rozloha kontrolovaného areálu a požadované funkce a kontroly průchodů. Často je potřebné podporovat již nainstalované hardwarové prostředky při přechodu z ručního systému na automatický. Dalším faktorem s kterým musíme počítat je, že stejně jako u každého softwaru pracujícím s penězi často je žádaná podpora fiskálních modulů. Protože komunikační protokoly těchto zařízení můžou být velice rozlišný, při implementaci systému se musíme snažit k modularitě. Rozhraní mezi hlavní aplikační logikou a hardwarem musíme vytvořit jako rozdělitelný modul, který je zkompilovaný nezávisle od hlavních programů. Na tento účel jsou vhodné knihovny DLL. Vytvoříme knihovny pro každý typ zařízení: ovládač tiskárny, peněžní zásuvky a displeje pro pokladnu Delia a ovladač pro sběrný modul terminálu pro software Datastation. Aby takové systémy mohli fungovat i automaticky, je potřebné zařízení, které fyzicky omezuje průchod nebo umožňuje bezobslužní platby. Během práce na problematice přístupových systému jsem měl možnost poznat zařízení vhodné pro tento účel. Jsou to terminály řady VPxxx firmy Identcode, které můžou fungovat samostatně i propojené do síti RS485. Pro tuto aplikaci je preferován síťový režim, avšak možnost fungovat offline umožňuje nepřerušený provoz i v případě výpadku síti RS485 anebo softwaru Datastation. Tyto terminály můžeme použít v různých rolích (vstupní nebo výstupní terminál, automatická pokladna, počítadlo obsazenosti) protože k něm lze připojit různé periferie:

Strana 8



•

klávesnice

•

display

•

snímač čárového kódu

•

tiskárnu čárového kódu

•

čtečku nebo zapisovač různých médii (magnetické nebo bezdotykové karty, TouchMemory, atd.)

•

závory, turnikety, branky

•

semafory

•

mincíř, bankomat

•

indukční smyčky pro detekci vozidla K jedné síti RS485 lze současně připojit až 32 zařízení. Komunikace probíhá ve formě

výzva-odpověď (polling). Hlavní terminál (master) zkontroluje zda ostatní terminály nemají nějaká data k odesílání. Ostatní terminály neposílají žádná data aniž by hlavní terminál se na to ptal. Komunikace mezi terminály a softwarovou nadstavbou má na starosti tzv. sběrný komunikační modul, který funguje v roli master terminálu a je připojen přes rozhraní RS232 k počítači, na kterém běží software DataStation. Počet sběrných modulů je limitován počtem sériových portu na počítači s aplikací Datastation.

2.2

Software

Pro větší flexibilitu při konkrétném použití „na místě“ tj. u zákazníka, je systém rozdělen na čtyři (softwarové) části. Každou část tvoří jedna aplikace, která má svou jedinečnou roli v systému. Aplikace Datastation je základem systému. Má na starosti řízení terminálů a ostatních komponentů systému. Název pokladního softwaru je Delia, umožňuje veškeré pokladní operace anebo i vydat příkaz programu Datastation na ovládání závor resp. turniketů. Pro konfiguraci a monitorování systému se používá aplikace Console. Stejně jako Delia umí navázat přímé spojení s Datastation a tak aktivně ovlivnit chod systému, např. ovládat, zastavit a spouštět terminály. Argos je software pro ovládání kamer a focení obrázků, přímo komunikuje s programem Datastation. Každý program pracuje se stejnou SQL databází a potřebuje pro funkčnost stálé připojení k ní.

2.2.1

Datastation

Aplikace Datastation (spolu s programem Console) tvoří nezbytnou část systému. Kromě jiného, Datastation inicializuje systém zaregistrováním sebe a připojených terminálů a zapsáním implicitních údajů do databáze. Protože terminály nemají přístup k databázi, nemůžou ani rozhodnout o tom, jestli při přiložení karty zákazníka povolit průchod, anebo

Strana 9



nikoliv. Samozřejmě na některá média můžeme uložit veškeré informace až do stovky bytů o platnosti karty, ale i když karta obsahuje všechny informace o sebe, tyto informace nemůžou být vždy aktuální bez online kontroly. Z tohoto důvodu se každý hardwarový komponent systému dotazuje Datastation, jakou operaci provést při načtení karty na terminálu. Odpověď Datastation neobsahuje pouze to, jestli se má povolit anebo zakázat průchod, ale i mnoha vedlejších informací: délku zvukové signalizace, jakou informaci vypsat na display zařízení anebo v případě karty pro invalidní osobu otevřít branku namísto turniketu. V podstatě

Datastation

provádí

operace

ve

dvou

případech:

automaticky

v pravidelných intervalech, anebo pokud je na to vyzván od některého z ostatních komponent. Protože Datastation propojí všechny komponenty systému, příkazy čeká jak ze strany ostatních softwarových komponentů (přes protokol TCP/IP), tak ze strany hardwarů ze sítě RS485. Ovládací příkazy ze strany softwaru můžou být některé z následujících: •

Nastavení semaforu

•

Ovládání závory

•

Zastavení terminálů

•

Pokyn na vytvoření uzávěrky

•

Nahlásit změnu nastavení

•

Nastavení sumy v automatické pokladně

•

Nastavení obsazenosti

•

Žádost o vytvoření obrázku

•

Zpráva o hotovém obrázku

•

Změna počtu volného média Mezi automaticky provedené operace patří:

•

Kontrola přechodu z letního času na zimní a opačně Je potřeba aktualizovat vestavěné hodiny terminálů při přechodu mezi letním a zimním časem, aby systém mohl správně vypočítat rozdíly, pokud karta byla vydána v letním čase a kontrola se již provádí v zimním anebo opačně.

•

Příkaz pro automatické pokladny na vytvoření uzávěrky Průběžné uzávěrky pokladny s obsluhou se dělají při odhlášení. Protože automatické pokladny fungují nepřetržitě, teda není odhlášení u kterého by se dělali uzávěrky, co ale může být žádoucí pro provozovatele systému. Z tohoto důvodu lze nastavit Datastation tak, aby každý den ve stejný čas vydal příkaz každé automatické pokladně na vytvoření uzávěrky.

•

Vymazání starých obrázků

Strana 10



Obrázky zákazníků (resp. jejich aut) jsou doslova největším údajem v databázi. Bez pravidelné údržby – co v tomto případě znamená jejich vymazání – by taková databáze vyrostla na obrovskou velikost. Tato funkce každý den překontroluje tuto databázi, a vymaže nejstarší obrázky. To, že které obrázky zůstanou v databázi nastavíme zadáním maximálního počtu a stáří obrázku. •

Vyprázdnění zóny Může se stát, že nejsou evidované všechny události o odchodu ze zón (výpadek komunikace mezi terminály a DataStation, chyba zákazníka nebo uživatele, atd.). V tomto případě je doporučeno upravit záznamy průchodů tak, aby zóny byly prázdné nejenom fyzicky, ale i v systému. Tuto operaci lze aplikovat správně pouze u systémů, které nejsou „aktivní“ nepřetržitě, teda každý den existuje takový časový interval, kdy zóna je fyzicky prázdná. Obsluha systému nastaví čas automatické vyprázdnění zóny v tomto intervalu.

•

Synchronizace času Jednotný čas v systémů je neodmyslitelný pro přesnou funkčnost. Ačkoliv synchronizace času mezi softwarovými komponentami lze provádět na úrovni operačního systému, je však potřeba pravidelně nastavit čas v terminálech podle času SQL serveru.

•

Resetování neaktivních komunikačních modulů Může nastat situace, že i když jsou některé komunikační moduly v systému nakonfigurované, neposílají žádné informace. V tomto případě se Datastation pokusí tyto moduly zprovoznit pravidelním posíláním RESET signálu.

•

Stahování ovládacích emailových zpráv Datastation může přijímat příkazy přes e-mail. Aby tyto příkazy mohl provést, musí tyto maily periodicky stáhnout z mailserveru.

2.2.2

Console

Tento program byl vyvinutý pro správu systému CAC. Pomocí tohoto softwaru lze konfigurovat celý systém. Zde jsou nastavené sazby, terminály a ostatní komponenty systému. Umožní nadefinování areálů a zón, svátků a měn, uživatelů a jejich oprávnění. Konfigurační nástroje jsou přístupné pouze uživatelům oprávněním z vyššího stupně. V aplikaci Console jsou implementované funkce týkající se sledování systému. Můžeme zde kontrolovat obsazenost zón, stav terminálů, uzávěrky pokladen, uskutečněné události a další užitečné sestavy. Z tohoto programu můžeme přímo kontrolovat všechny propojené hardwarové komponenty systému: ovládání závor, odblokování dveří a turniketů, změnit stav pokladen a semaforů.

Strana 11


2.2.3


Delia

Používání programu Delia je jedna z možností k inkasování peněz za používání služeb v areálu. Alternativou je použití bezobslužných automatických pokladen, ale tyto zařízení můžou řešit pouze jednodušší platební operace. U středně větších implementací je většinou instalována alespoň jedna aplikace Delia a automatická pokladna je přítomen pouze jako ulehčovací prostředek pro rutinní operace. Delia je pokladní software, přímo spolupracuje s hardwarem jako např.: čtečka resp. vydavač lístků, peněžní zásuvka, zákaznický displej anebo fiskální modul. Před zahájením práce se pokladník autentizuje s heslem anebo identifikátorem TouchMemory. Podle oprávnění uživatele se aplikace umožňuje pokladníkovi povolit nebo zakázat použití jednotlivých funkcí. Tato část systému je jedna z nejcitlivějších míst v systému ze strany uživatelského rozhraní, protože tato aplikace je používána nejintenzivněji. Na hlavní obrazovce jsou ovládací prvky pro nejpoužívanější pokladní funkce: •

Výdej nové karty

•

Načtení existující karty

•

Přepínač mezi sazbami a měnami

•

Seznam areálů, zón a (sportovních) akcí

•

Funkce pro rezervaci a zapůjčení předmětů Samozřejmě aplikace má i funkce pro vyřešení nestandardních situací, z kterých je

nejčastější výdej duplikátu ztracené karty, tisk duplikátu daňového dokladu anebo zrušení omylem provedených transakcí.

2.2.4

Argos

Tato aplikace je nejmenší a nejjednodušší ze čtyř programu tvořící softwarovou část systému CAC. Její jedinou úlohou je snímat obrázky a uložit je do databáze. Pomocí funkcí DirectX zachytává fotografie zákazníků kontrolovaného areálů. Samozřejmě aby mohla fungovat, je potřeba mýt nainstalovanou kartu k zachycení videa a k tomu připojit alespoň jednu kameru. Při spuštění se připojí k SQL databázi a k Datastation, a čeká na příkazy. Jakmile některý komponent požádá Datastation o obrázek, podle zdroje požadavku Datastation rozhodne, která instance programu Argos může poskytnout potřebný obrázek. Po úspěšném focení Argos pošle odpověď aplikaci Datastation, která informuje komponent (který původně požádal o fotku) o tom, že fotografie je přístupná z databáze.

Strana 12



Jak z předchozího odstavce vyplývá, v systémů může fungovat současně více programu Argos. Toto je jeden z důvodů, proč nejsou tyto funkce implementované přímo v Datastation.

2.3

Registrace komponentů

Všechny komponenty jsou při prvním použití zaregistrované do databáze. Softwarové komponenty registrují sebe, ale protože terminály nemají přímý přístup do databáze, tento úkol má na starosti jejich „rozhraní“ do systému, aplikace Datastation. Registrace součástí je vázán ke (více-méně) konstantnímu údaji počítačů (připojené do počítačové sítě) k adrese MAC (Media Access Control). Samozřejmě ani MAC adresa není zcela unikátní a konstantní (existují síťové karty, které umožňují klonování MAC adresy, některé operační systémy nevrátí MAC adresu při odpojeném síťovém kabelu, atd.), ale je to ještě stále lepší řešení než to vázat k adrese IP. Terminály jsou identifikované podle síťového čísla, které je nastavitelné pořadové číslo v síti RS485. V síti RS485 musí být toto číslo unikátní, takže jedinečnost identifikačního čísla je zabezpečena. Toto ale neplatí obecně, z důvodu že Datastation umí ovládat více sítí RS485. V tomto případě unikátnost musí zabezpečit uživatel nastavující tyto čísla. Registrace komponentů přináší nejlepší příležitost pro kontrolu licenčních omezení. Tyto omezení - které kromě počtů a typů komponentů ještě obsahuje i číslo systému a datum vypršení funkčnosti systému – jsou uložené v hardwarovém klíči. Při prvním spuštění systému jsou tyto údaje přeneseny do databáze, aby měli všechny komponenty přístup k těmto datům. Registrace je důležitá i z hlediska toho, že všechny události jsou (mimo jiné) vázané k evidenci těchto komponentů.

Strana 13



3 Použitelná média Aby systém mohl sledovat průchody osob v areálu, musí je nějak identifikovat. Systém CAC nepodporuje žádnou identifikaci pomocí biometriky, proto osoby a auta jsou identifikované pomocí nějakého média.

3.1

Čárový kód

Identifikace pomocí čárového kódu je velmi oblíbeným způsobem. Hlavním důvodem je příznivější cena, než u ostatních médií. Kvalitní čárové kódy zaručují spolehlivé čtení i po delším užívání, avšak může být více náchylné na větší nečistoty kvůli tomu, že čtení je na vizuální bázi. Další nevýhodou je, že čárové kódy nejsou přepisovatelé. Bez dodatečné ochrany je velice náchylné na padělání, proto je doporučen použít ochranné maskování a infračervené snímače.

3.2

Magnetický pás

Podle mých zkušeností jedinou výhodou karet s magnetickým pruhem je jejich přepisovatelnost, co umožňuje doplnění kreditů na kartu a validace karty v offline (nepropojeném) módu. Protože při čtení a zápisu je potřeba fyzický kontakt s čtečkou/zapisovačkou, tyto operace nejsou tak bezproblémové jako u bezdotykových technologií [All97].

3.3

RFID čip

Jedná se o poměrně drahý médium, ale když potřebujeme větší spolehlivost, RFID čipy jsou ideálním řešením. Existují různé varianty: nepřepisovatelné a přepisovatelné, ve formě karty anebo hodinek, atd. V dnešní době je nejoblíbenějším typem karty, protože jeho pořizovací cena klesla dostatečně na to, aby provozovatelé byli ochotní obětovat větší výdeje pro pohodlnější způsob identifikace.

3.4

Čipové karty

Tento typ karty je vhodný jako servisní karta anebo karta pokladníka pro přihlášení do systému. Přestože existují čipové karty na které lze i zapisovat, pro zákaznické karty je vhodnější jiný typ média [All97].

Strana 14


3.5


Dallas TouchMemory

Tato technologie se příliš nepoužívá. Jedná se o čipy v kovovém pouzdře. Při čtení musíme přitlačit pouzdro k čtečce tak, aby oba kontakty byly spojené.V systém CAC je používán spíš pro autentizaci uživatelů než jako médium pro návštěvníky areálu.

Strana 15



4 Pojmy 4.1

Areály a zóny

Objekty kontrolované systémem CAC můžeme rozdělit na více areálů avšak v systému musí být definován alespoň jeden areál. Ke každému areálu můžeme přiřadit jednu nebo více fyzických zón. Fyzická zóna je základnou nerozdělitelnou součásti kontrolovaného objektu, můžeme k něm definovat kapacitu a přiřadit k něm aktivní komponenty systému (terminály, pokladny). Dalším parametrem fyzických zón je polygon, který je ohraničuje. Tato vlastnost je nevyhnutná pro zobrazení zón v jednotlivých programech, v databázi je uložena jako seznam bodů. Fyzické zóny jsou nejpodrobnější rozdělení objektů, co umožní dostatečnou flexibilitu při zavedení kontrolovaných objektů do systému, avšak zkomplikuje jiné operace s nimi. Ve většině případů existují taková místa, která samotná nemají význam ale jsou potřebné pro více nebo všechny části objektu (chodby, vestibuly).

4

6

8

55 1 A

3

7

9

B,C,D,E,F,G,H,I

G,I

10

E,I

B,I C,I

F,I

D,I

H,I

2 B,C,D,E,F,G,H,I Obrázek 1. Zóny

Při běžných operacích, jako jsou výdej nebo rezervace lístků, by jsme museli zadat i tyto místa. Řešením jsou logické zóny, které jsou množiny fyzických zón. Každá fyzická zóna může patřit k více logickým zónám. Všechny operace a definice jsou vázané na logické zóny kromě umístění aktivních komponentů – ty jsou vázané k fyzickým zónám, aby

Strana 16



umístění terminálů a pokladen zůstala stejná i po předefinování relací mezi fyzickými a logickými zónami. Na obrázku 1 vidíme rozdělení plovárně jako příklad na použití obou typů zón. Čísla označují fyzické, písmena logické zóny. Zóna 1 je venkovní bazén, zóny číslem 2 a 3 jsou areál před budovou krytého bazénu a budovu krytého bazénu. Zóny 4 až 9 označují jednotlivé dráhy bazénu a číslo 10 je dětský bazén. V případě venkovního bazénu je situace jednoduchá, protože není rozdělena nijak – logická zóna je v tomto případě definována pouze z důvodu, že uživatelé systému pracují s logickými zónami. Vidíme, že ke všem ostatním (fyzickým) zónám je přiřazena zóna I, protože ta označuje celý krytý bazén včetně areálu před budovou. Operace s touto zónou budou mýt vliv na všechny dráhy a bazény této budovy. Tato konfigurace umožní i akce pro separátní dráhy a pro dětský bazén (na tento účel slouží zóny B až H), na druhé straně zakáže vydat rezervace a lístky pro pasivní zóny 2 a 3. Chceme-li vydat vstupenku jenom pro diváky, stačí přidat další zónu G a přiřadit k něm zónu 2 a 3.

4.2

Měny a kredity

V systému CAC počet podporovaných měn je neomezený. K určité měně jsou vázané sazby pro výdej vstupenek, sazby pro rezervace, transakce a uzávěrky, slevy u nabíjení kreditů a ceny zápůjček. Protože systém byl navržen primárně pro placené aplikace, při inicializaci databáze systém automaticky přidá měnu z národní nastavení Windows-u. Tato měna bude implicitní měna, tj. tuto měnu budou implicitně nabízet uživateli, operace u kterých je možnost výběru z více měn a tato měna bude používaná v automatických pokladnách. Kromě třípísmenné zkratky názvu pro každou měnu můžeme definovat poměr kredit/měna. Kredity umožňují zákazníkům areálu zaplacení určité částky předem, kterou pak mohou použít na libovolné služby areálu od parkování přes používání sauny

koupu

zmrzliny. Výše zbývajícího kreditu je uložena v databázi resp. na kartě (souvisí od typu média a od druhu prodávajícího bodu). Výše zmíněný poměr kredit/měna je užitečný právě při ukládání kreditu na médium.

4.3

Transakce a uzávěrky

Transakce může probíhat ve dvou případech: příjem nebo výdej hotovosti z kasy anebo při platbě. Platba je uskutečněná po výdeji nebo validace karty, po dobíjení nebo použití kreditů nebo po rezervaci zón. Systém CAC podporuje standardní i bezhotovostní platby. Po platbě v hotovosti je stav kasy změněný o částku transakce a je otevřena peněžní zásuvka. Bezhotovostní platba může probíhat podle zaplacené faktury, pomocí bankovní karty nebo z kreditů na vstupence. První dva způsoby jsou možné pouze u pokladen

Strana 17



s obsluhou. Platba podle faktury je často používána metoda při větších transakcích, např. když někdo zakoupí větší množství vstupenek. K implementaci platby podle bankovních karet je potřebné zařízení pro čtení těchto karet, proto tato možnost je podporována pouze v omezené míře, do systému je pouze zapsané číslo bankovní karty. Platba kreditem z karty funguje podobným způsobem, v tomto případě je kredit zákazníka snížen o částku transakce. Po každé transakce je vytisknutý daňový doklad a parametry transakce jsou zapsané do databáze a do fiskálního modulu (jestli je používaný). Systém umožňuje vytvoření 4 typů uzávěrek: průběžné, denní, měsíční nebo roční. Průběžné uzávěrky jsou vytvořené při odhlášení pokladníka (nebo libovolně u automatických pokladen). Ostatní tři typy uzávěrek nejsou vytvořené automaticky, uživatel je může vygenerovat po uplynutí daného období.

4.4

Definice sazeb a výpočet ceny

Speciálním parametrem placených aplikací jsou sazby. Z pohledu provozovatele je důležitý, aby měl možnost vytvářet sazby s nejrůznějšími průběhy. Definice sazeb systému CAC jsou rozdělené na tři části: hlavní parametry sazby, definice průběhu sazby a koeficienty sazby. Tato metoda umožňuje platby předem nebo po výužívání služeb, výdej nebo validace jednorázových karet a permanentek. Nejzákladnějším parametrem sazby je počet použití. Jednorázové karty jsou pohlcené resp. znehodnocené na výstupu. Další rozdíl od abonentek je, že u těchto typů vstupenek může ale nemusí být povinný údaj o majiteli karty a je možnost i platba po použití služeb. U abonentkách zadat základní údaje o zákazníka a platba předem jsou povinné. Protože některé sazby jsou definované tak, že nejsou použitelné vždy (např.: večerní nebo víkendové), je potřebné zadat sazbu, která bude používána pro výpočet ceny v intervalech, když tato sazba není použitelná. Tuto sazbu nazýváme alternativní sazbou. Samozřejmě i alternativní sazba může mýt svou alternativní sazbu, nebo jestli to není potřebné, musíme nastavit jako alternativní sazbu sám sebe. Aby možnosti byly opravdu široké, jsou podporované ještě další pomocné parametry, jako délka zvuku vydané terminálem při použití karty, hodnota média (kterou zákazník musí zaplatit jako zálohu při koupě karty), počáteční kredity, dny v kterém bude vstupenka platná, možnost omezení výdeji resp. validace karty s určitou sazbou nebo nastavit implicitní počet karet na vydání při výběru této sazby. Průběh sazby je seznam řádků definující částku k zaplacení v závislosti na délky pobytu v areálu. Prvním parametrem každého řádku je počet časových jednotek pro kterou je spočítaná cena, která je uložena v druhém parametru. Délka časové jednotky je součásti definice sazby a může být různá pro každou sazbu. Algoritmus skočí na další řádek definice

Strana 18



potom, až inkrementoval částku tolikrát, jaká hodnota je v prvním parametru. Při zahájení výpočtu algoritmu použije pro výpočet první řádek a postupně použije další řádky, pokud není vypočítaná celková suma. Jestli již algoritmus použil každý řádek a částka ještě není vypočítaná, skočí na určený řádek a pokračuje ve výpočtu. Kromě standardní sazby pro abonentky, kde je potřebný zadat počet minut relativní platnosti a cenu, existují ještě denní, měsíční a roční sazby, které jsou platné vždy od začátku do konce daného období tj. dne, měsíce nebo roku. U sazeb pro abonentky není povinné zadat průběh sazby, v tomto případě vstupenka bude platná na neomezené použití v intervalu její platnosti. Jestli definujeme tento průběh, systém po každém použití karty vypočítá částku podle tohoto průběhu, a tuto částku žádá od zákazníka při výstupu, anebo odečítá z kreditů karty. Třetí částí definice jsou koeficienty, které definují ve kterém období dne jakým koeficientem je násobena vypočítaná sazba. Pokud nenadefinujeme koeficient na některé období, karta nebude řádně použitelná v tomto období a částka bude vypočítaná podle alternativní sazby aktuální sazby pro toto období.

Strana 19



5 Webová aplikace pro CAC 5.1

Účel aplikace

Tato webová aplikace je ukázkou na to, jakým způsobem lze umožnit vzdálenou kontrolu přístupového systému. Tuto aplikaci lze při zprovoznění modifikovat podle očekávání budoucího provozovatele systému. Například pokud chceme potenciálním návštěvníkům poskytovat informace o návštěvnosti anebo umožnit rezervaci služeb, do aplikace stačí doplnit tyto funkce. Další možností je, že pokud správce systému není nepřetržitě v areálu, pomocí webové aplikace může změnit kterýkoliv parametr systému. Základní podmínkou pro tuto aplikaci je, aby uživatel nemusel nic instalovat na svůj počítač. K tomuto účelu nám se perfektně hodí rozhraní internetového prohlížeče.

5.2

Příprava

Přestože jazyk, ve kterém jsem měl tuto aplikaci napsat byl definován zadáním práce, já jsem mohl rozhodnout, jaké Java technologie použít při implementaci aplikace. Během svého výzkumu jsem narazil na tři možnosti, které na první pohled byly vhodné pro tento účel. První varianta byla použití appletů. Samozřejmě tato možnost hned na začátku vypadla z těchto důvodů [Sil02]: •

Oproti servletů, applet běží na počítače uživatele, takže uživatel musí stáhnout (současně s webovou stránkou) celý applet před používáním.

•

Je používán Java Virtual Machine (JVM) ze strany klienta, proto JVM nemusí být stejný u všech uživatelů

•

Prohlížeč je musí podporovat a ve většině prohlížečů je potřeba povolit spouštění appletů

•

Nedostatek zabezpečení – aplikace ze strany přistupuje k citlivým údajům přes prohlížeč Další možností jsou čisté servlety. Tato technologie již byla vhodnější, ale použít

pouze servlety jsem neviděl nejlepším řešením [Hal99]: •

I statické HTML kódy musím vygenerovat pomocí příkazů jako například println.

•

Kombinováním s JSP můžu rozdělit vzhled a funkcionalitu.

Strana 20



Proto jsem se rozhodl JSP s JavaBeany, doplněné s technologiemi Server-side Include (SSI) a Cascade Style Sheets (CSS). V další fáze přípravy jsem vybral vhodný databázový server. Zkušenosti jsem měl s trojími SQL servery: MySQL, MSSQL a Sybase SQL Anywhere. Protože systém CAC je komerční aplikace, možnost používání MySQL serveru jsem hned na začátku vyloučil. Mezi servery od Microsoft a Sybase jsem nenašel významné rozdíly, snad jenom to že Microsoft nabízí lepší nástroje pro zpracování databáze. Nakonec teda zvítězil server od firmy Microsoft a to i proto, že existuje zjednodušená varianta MSSQL serveru s názvem Microsoft Data Engine (MSDE), která je použitelná zdarma.

5.3

Struktura programu

Důležitou součásti programu je JavaBean s názvem DataBean. Přes tuto třídu je aplikace připojena k databázi. Toto připojení je realizováno pomocí ovladače JDBC. Třída navíc obsahuje metody pro přihlášení a odhlášení ze systému. Při přihlášení se rozlišuje, jestli je přihlášená osoba zákazníkem anebo správcem systému. Toto rozdělení je důležité k tomu, aby aplikace mohla rozhodnout, ke které funkcím povolit přístup. Ostatní třídy mají na starosti vizualizaci funkcí, jako například JavaBean SetupBean (se stránkou setup.jsp), ve kterém jsou implementované metody pro nastavení areálů a zón. Tyto vedlejší třídy jsou vždycky spárované se stránkami JSP. Toto spárování je pomocí prvku <jsp:useBean>. Ke každé stránce je stejným způsobem připojena i třída DataBean, aby stránky mohli zkontrolovat stav přihlášení před vypsáním jakékoliv informace anebo před provedením nějaké operace.

5.4

Vzhled programu

V první řade jsem se musel rozhodnout o tom, jestli použít rámce anebo tabulky pro umístění jednotlivých objektů na stránce. Toto rozhodnutí bylo spíš subjektivní než podle faktu, protože nelze jednoznačně říci, který způsob je lepší. Osobně se mi webové stránky rozdělené tabulkami více líbí, z tohoto důvodu jsem se rozhodl řešit uživatelské rozhraní tímhle způsobem. JSP stránky, které dělají vizualizaci jednotlivých funkcí se na začátku připojí k sobě stránku header.jsp a na konci footer.jsp. Takto je zabezpečen, aby vzhled stránek byl stejný. Soubor header.jsp obsahuje prvek a v souboru footer.jsp je prvek
. Takovém souboru se záhlavím je definováno umístění a styl tabulky, do kterého je vložen JSP s komponentami (HTML prvky) aktuálně použité funkce.

Strana 21



6 Plány do budoucna •

Grafické zobrazení zón Aby internetová aplikace byla příjemnější pro potenciální návštěvníky areálu, je potřeba doplnit možnost grafického zobrazení zón v areálu.

•

Konfigurační funkce V současné verzi webové aplikace jsou implementované pouze funkce pro správu areálu a zón. Podle potřeby zde lze dodělat další konfigurační nástroje jako nastavení pro sazby anebo pro jednotlivé hardwarové anebo softwarové komponenty.

•

Monitorovací funkce Stávající verze systému CAC umožňuje implementaci do webové aplikace takové funkce, které by poskytovali informaci administrátorovi o stavu systému. Tento report by obsahoval stavy a případné chyby jednotlivých částí systému resp. obsazenost zón.

•

Ovládací funkce Ovládání zařízení (hardwarové komponenty systému) v reálném čase není nejvhodnější úkol pro webovou aplikaci. Není však nemožné. Podle mých představ by to bylo možné realizovat pomocí tzv. úkolů. Uživatel – prostřednictvím webové aplikace – by přidával úkoly do přidané databázové tabulky a Datastation by periodicky zkontroloval tuto tabulku, a provedl by tyto příkazy.

Strana 22



7 Závěr Cílem této práce bylo probrat problematiku placených aplikací přístupových a rezervačních systémů pomocí existujícího systému Cerberus Access Control (CAC) a vytvořit webovou aplikaci, která by sloužila jako rozhraní k systému. Podařilo se mi napsat aplikaci v jazyce Java s využitím JavaBean-ů a JSP stránek, která je schopná navázat spojení s databázi systému CAC a provést základní operace nastavení systému. Tento program může sloužit jako základ větší extranetové aplikace.

Strana 23



8 Literatura [Sil02]

Silver, L. Daniel, Java Servlet Basics, 2002, je dostupné na URL: http://plato.acadiau.ca/courses/comp/dsilver/2513/Slides/Java_Servlet.ppt

[Hal99]

Hall, Marty, Tutorial on Java Servlets and JSP, 1999, je dostupné na URL: http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/Servlet-TutorialOverview.html

[All97]

Allaga, Gyula: Kártyás rendszerek, 1997, Prim

Strana 24



Přílohy Příloha A:

Infrastruktura systému .....................................................................26

Příloha B:

Diagram výpočtu sazby ...................................................................27

Strana 25



Příloha A:

Kamery

Infrastruktura systému

Video capture card

Argos

Delia

Čtečka a zapisovač média

Datastation Display Komunikační modul Peněžní zásuvka

SQL server Pokladna

Webová aplikace Console Server TCP/IP Konekce SQL HTTP RS485 RS232

Vstupní terminál

Výstupní terminál

Správ a

Webový prohlížeč

Internet

Automatická pokladna

Počítadlo obsazenosti

Bankomat Závora

Závora



Semafory

Mincíř LED display Čtečka a zapisovač média

Strana 26



Příloha B:

Diagram výpočtu sazby

Začátek

Výdej?

Pracujeme s příplatkovou sazbou aktuální sazby

ID Sazby s kterou pracujeme

ano

ne

ne ID vybrané sazby

ID sazby na kartě

Je příplatková sazba aktuální sazby a aktuální sazba stejná?

Je tato sazba platba předem? ano

ne

Je koeficient příplatkové sazby této sazby NULL při vypršení platnosti karty?

ano ne

Pracujeme s příplatkovou sazbou

ID sazby napsaná na kartu

ano

Pracujeme s touto sazbou ne

ID Sazby s kterou pracujeme

Výpočet sazby na období když koeficienty této sazby nejsou NULL

Pracujeme s příplatkovou sazbou aktuální sazby

Zápis dat na kartu

ano

Je potřebný pokračovat ve výpočtu?

Konec

Strana 27

Masarykova univerzita Fakulta informatiky. Rezervační systém. Bakalářská práce Tomáš Blaho

Recommend Documents