}w!"#$%&'()+,-./012345<ya

}w!"#$%&'()+,-./012345<ya MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Aplikace pro správu docházkového/bezpečnostního systému BAKALÁŘSKÁ PRÁCE Martin Jakubec Brno, podzim 2010

Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem 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. Martin Jakubec Vedoucí práce: Mgr. Martin Jakubička ii

Poděkování Chtěl bych poděkovat vedoucímu práce Mgr. Martinovi Jakubičkovi za rady a připomínky a za umožnění práce na vlastní téma. iii

Shrnutí Cílem této bakalářské práce je navrhnout a implementovat webovou aplikaci pro správu docházkového/bezpečnostního systému. Aplikace bude implementována v jazyce Java EE za pomoci Stripes Frameworku a Enterprise Java Beans 3.0. iv

Klíčová slova docházkový systém, webová aplikace, Java EE, EJB 3, Stripes Framework, objektová analýza a návrh v

Obsah 1 Úvod................................ 3 2 Analýza.............................. 4 2.1 Současné systémy...................... 4 2.2 Proč zavádět přístupové/docházkové systémy?.... 4 2.3 Možnosti zamezení přístupu............... 5 2.4 Komunikace s terminálem................. 5 2.5 Rozdělení terminálů.................... 6 2.5.1 Kontaktní...................... 6 2.5.2 Bezkontaktní.................... 6 2.5.3 On-line........................ 6 2.5.4 Off-line........................ 7 2.6 Dodavatelé docházkových systémů............ 7 2.6.1 EFG CZ spol. s r.o.................. 8 2.6.2 AVARIS, s.r.o..................... 8 2.6.3 ANeT-Advanced Network Technology, s.r.o... 8 2.6.4 IReSoft, s.r.o..................... 9 2.7 Zhodnocení......................... 9 2.8 Požadavky na systém.................... 9 2.9 Embedded modul SFM3520................ 10 2.10 Aplikace pro sběr dat.................... 10 2.11 Use Case diagram...................... 12 3 Návrh a implementace...................... 13 3.1 Použité technologie a nástroje............... 13 3.1.1 Java Enterprise Edition (Java EE)......... 13 3.1.2 GlassFish Server.................. 13 3.1.3 Enterprise Java Beans 3 (EJB 3).......... 13 3.1.4 Stripes Framework................. 15 3.1.5 Java Server Pages (JSP)............... 16 3.1.6 HyperText Markup Language (HTML)..... 16 3.1.7 MySQL........................ 16 3.2 Aplikační část........................ 17 3.2.1 Balíček Users.................... 17 3.2.2 Balíček Buildings.................. 17 3.2.3 Balíček Permissions................ 18 3.2.4 Balíček Transactions................ 18 1

3.2.5 Příklady rozhraní v balíčku bcthesis.model.users 18 3.3 Datový model........................ 19 3.4 ERD diagram........................ 20 3.5 Webová část......................... 20 3.5.1 Model View Controller.............. 20 3.5.2 Registrace uživatele................ 22 3.5.3 Návrh uživatelského rozhraní.......... 22 3.5.4 Ukázka uživatelského rozhraní.......... 23 3.6 Vzdálený přístup...................... 23 4 Závěr................................ 24 5 Příloha A.............................. 26 2

1 Úvod Elektronické informační systémy (IS) se dnes staly již nezbytnou součástí řízení moderního podniku. Umožňují mimo jiné rychlejší práci, efektivnější plánování a lepší využití finančních a lidských zdrojů. Využití výhod automatizované správy a uložení dat si dnes uvědomuje drtivá většina společností. Finanční prostředky, investované do nákupu nebo vývoje takového systému, se mnohonásobně vrátí časem ušetřeným za správu papírové kartotéky. Informační systémy mohou být rozsáhlé a mohou řešit celou sadu úloh (účetnictví, sklad, řízení podniku), nebo naopak mohou být zaměřeny na jeden konkrétní problém. Tato bakalářská práce se zabývá návrhem a implementací aplikace pro správu docházky. Na českém i zahraničním trhu je spousta společností, které poskytují přístupové systémy různého zaměření a různého rozsahu. Tyto systémy většinou slouží pro evidenci docházky zaměstnanců nebo sledování jejich pohybu po areálu po dobu pracovní doby. Cena těchto systémů se odvíjí od počtu zaměstnanců a počtu vstupních zařízení (terminálů). Tato investice se většinou vyplatí i menším firmám do 50 zaměstnanců. Problém nastává v případě, kdy máme k dispozici vlastní terminály a potřebujeme pouze software. Většina firem dodává pouze kompletní řešení, včetně hardwarových součástí. Vývoj aplikace pro správu vlastních hardwarových součástí bývá obvykle velmi nákladný. Cílem této bakalářské práce je navrhnout a implementovat aplikaci pro jednoduchou správu takovéhoto systému. V kapitole 2 se věnuji získávání poznatků o dostupných systémech, abych mohl co nejlépe navrhnout aplikaci pro naše potřeby. Postupně uvádím informace o moderních docházkových systémech, o typech a konstrukci vstupních terminálů a v neposlední řadě zmiňuji několik českých společností, které se vývojem takových systémů zabývají a stručně představuji jejich řešení. Ve 3. kapitole získané poznatky aplikuji v samotném návrhu a implementaci vlastního řešení. 3

2 Analýza V současné době je každá firma v ČR podle zákona č. 262/2006 Sb., zákoník práce [3], povinna evidovat docházku svých zaměstnanců. Evidence docházky má ale i jiná opodstatnění, snadno lze například kontrolovat pozdní příchody. Výstupy těchto systémů (at už elektronických nebo papírových) lze použít pro statistické účely, nebo k výpočtu mzdy. Při použití elektronického informačního systému se tyto možnosti ještě více zjednoduší. Odpadá nutnost ručního přepočítávání údajů z papírové karty zaměstnance, počítačový systém za vás udělá vše potřebné a bez chyb. Pro areály podléhající přísnějším bezpečnostním podmínkám lze monitorovat pohyb osob a řídit přístup do jednotlivých objektů. 2.1 Současné systémy V současné době existuje už jen minimální množství společností, které stále využívají papírové karty pro evidenci docházky. 2.2 Proč zavádět přístupové/docházkové systémy? Automatická kontrola pozdních příchodů do zaměstnání. Automatizované získání statistických informací pro řízení firmy. Pohyb osob je možný omezit v čase. Je možné měnit oprávnění vstupu zaměstnanců z jednoho místa, aniž by konkrétní zaměstnanec musel být přítomen. Je možné sledovat pohyb osob po areálu. Je možné zpoplatnit pobyt v určitých objektech např. hodinovou sazbou. Tento způsob se dá využít například na parkovištích, ve fitcentrech, ve sportovních nebo jiných rekreačních zařízeních. 4

2. ANALÝZA K přístupu do uzamknutých částí areálu není nutný fyzický klíč (větší množství klíčů). Všechny klíče nahradí např. jedna čipová karta nebo otisk prstu. 2.3 Možnosti zamezení přístupu Turniket Turniket je nejméně bezpečné vstupní zařízení. Nepovolaná osoba může velmi snadno přes turniket projít, pokud není vybaven další mřížovou konstrukcí okolo samotné závory. Konstrukce turniketu většinou umožňuje nežádoucí přístup více osobám najednou, proto je tento typ vstupního zařízení vhodný pro objekty s nízkou požadovanou úrovní zabezpečení, nebo pro místa s dodatečnou ostrahou, např. vrátným. Závora Vstupní zařízení vhodné pro omezení přístupu automobilů. Zavřená závora neumožňuje volný průjezd automobilu. Konstrukce závory umožňuje průchod osoby. Tento typ zařízení je proto vhodný pro parkoviště. Dveře s elektromagnetickým zámkem Nejbezpečnější vstupní zařízení ze jmenovaných. Předpokládá se, že neautorizované osoby nejsou schopny dveře otevřít bez použití hrubé síly. U dveří je umístěn terminál, který dveře odemkne po identifikaci a úspěšné autorizaci zaměstnance. Jakmile se dveře otevřou, je umožněn průchod více osobám. 2.4 Komunikace s terminálem Nejlevnější varianta terminálu je tzv. terminál programovatelný master kartou. Tyto terminály jsou schopny pracovat bez použití počítače a není potřeba, aby byly připojeny do sítě. Programování a nastavení tohoto typu terminálu se provádí pomocí master karty, která je jedinečná, a terminál si ji zapamatuje jako první kartu přiloženou po 5

2. ANALÝZA zapnutí napájení. Další karty již bere jako normální přístupové. Tato varianta je vhodná pouze pro menší firmy, kde není nutné data v terminálu často měnit. Nastavení je totiž nepohodlné a časově náročné. Všechny ostatní terminály jsou nějakým způsobem propojeny s centrální řídicí jednotkou. Komunikačním médiem je obvykle ethernetová sít nebo sériová linka (RS-232, RS-485), případně wi-fi. 2.5 Rozdělení terminálů Terminálů existuje celá řada. Volba konkrétního typu terminálu závisí na požadavcích investora. Solidní dodavatel s výběrem poradí a dodá řešení na míru potřebám konkrétního podniku. Terminály můžeme dělit podle mnoha kritérií (způsob komunikace, způsob identifikace osoby, konstrukční provedení, a jiné). Níže uvádím několik typů zařízení, jejichž volba má zásadní vliv na funkci požadovaného řešení. 2.5.1 Kontaktní Identifikace pracovníka probíhá díky fyzickému kontaktu s terminálem. Např. klávesnice pro zadání ID zaměstnance, snímač otisku prstu, snímač magnetické karty. 2.5.2 Bezkontaktní Identifikace pracovníka probíhá bez fyzického kontaktu. Např. bezkontaktní čipová karta. 2.5.3 On-line Veškeré informace o přístupech a interakcích s uživatelem jsou ukládány na server v reálném čase, terminál sám odesílá data ihned po interakci se zaměstnancem. Výhody: Možnost sledovat pohyb zaměstnanců v reálném čase. 6

2. ANALÝZA Není potřeba žádný další program pro sběr dat. Nevýhody: Teoreticky větší zatížení sít ě díky neustálému zasílání paketů. Složitější řídicí jednotka. Musí být naprogramována tak, aby volala vzdálené metody pro uložení transakce. 2.5.4 Off-line Veškeré informace o interakcích jsou ukládány přímo do interní paměti terminálu. Je potřeba další program, který v časových intervalech prochází jednotlivé terminály, data z nich sbírá a ukládá na server. Uplatnění naleznou tam, kde není nutné sledovat pohyb osob v reálném čase. Výhody: Terminál není nutno nijak programovat. Informace jsou ukládány do vnitřní paměti. Sběr dat je možné provádět v době nejmenší zátěže sítě. Nevýhody: Nutná vyšší kapacita interní paměti. Aktualizovaná data o přístupech se v aplikaci projeví až po sběru dat z terminálů. 2.6 Dodavatelé docházkových systémů Existuje mnoho společností, jak v České Republice, tak i v zahraničí, které dodávají systémy sloužící k evidenci docházky. Tyto firmy se většinou zabývají jak vývojem docházkových systémů, tak všeobecně vývojem systémů, které ke své činnosti využívají přístupové terminály nebo senzory pohybu. Může se jednat například o systémy pro závodní jídelny (objednávky a výdej obědů), požární systémy, 7

2. ANALÝZA systémy pro kontrolu obchůzky, skladové systémy (s použitím čárových kódů) nebo systémy pro zpoplatnění návštěv (např. sportovní centra). Zmíním pár tuzemských společností, které se zabývají vývojem průmyslových přístupových a bezpečnostních systémů, a představím jejich řešení. 2.6.1 EFG CZ spol. s r.o. Česká společnost, která pro koncové zákazníky dodává systémy pro ochranu objektů nebo identifikaci zaměstnanců, včetně kamerových systémů a požární signalizace. Jejich identifikační systém AK- TION obsahuje moduly pro evidenci docházky, stravování, kontrolu osob a vozidel (s rozpoznáváním SPZ 1 ), kontrolu obchůzky, registraci návštěv a další. Společnost dodává také webovou nástavbu pro svůj software. Tento systém je velice rozsáhlý a disponuje velkým množstvím různých typů terminálů, přesně podle potřeb zákazníka [9]. 2.6.2 AVARIS, s.r.o. Kromě průmyslových docházkových a bezpečnostních systémů (UNIGate, A-pro, COP) nabízí také školní docházkový systém (SchoolGate), stravovací systém (AJSmenu), teplotní evidenční systém (TESScan) nebo systém pro kontrolu práce strážného (KOSGuard, ActiveGuard) v areálu podniku [5]. Spolu se svým softwarem firma dodává elektromagnetické zámky, turnikety a branky nebo domácí telefony. 2.6.3 ANeT-Advanced Network Technology, s.r.o. Brněnská společnost, která dodává kompletní aplikace pro řízení a využití lidských zdrojů, včetně docházkových, přístupových systémů a stravovacích systémů. 1. Státní Poznávací Značka 8

2. ANALÝZA 2.6.4 IReSoft, s.r.o. IReSoft, s.r.o., je další brněnská firma. Jejich stěžejní produkt CYG- NUS je komplexní informační systém pro poskytovatele sociálních služeb. Mimo to firma dodává systém pro evidenci docházky, nazvaný Alveno. Tento systém využívá pro identifikaci osob čtečky otisku prstu nebo bezkontaktní čipové karty a přívěšky. 2.7 Zhodnocení Na trhu je dostupná celá řada systémů, které umožňují správu docházky, bezpečnosti uvnitř podniku nebo celkové řízení, včetně napojení na ostatní moduly, jako jsou účetnictví nebo mzdy. Pokud chceme vybrat systém, který bude nejlépe odpovídat našim potřebám, musíme si položit pár základních otázek. Jaká je požadovaná úroveň zabezpečení? Jaký chceme typ přístupového terminálu? Kolik lidí bude mít přístup do objektu? Jaký požadujeme počet přístupových zařízení? Moderních přístupových systému je spousta a liší se velikostí, rozsahem, úrovní zabezpečení, rozšiřitelností, nebo propojitelností s ostatními komerčními systémy. 2.8 Požadavky na systém Základním požadavkem je propojitelnost se zařízeními pro čtení otisku prstů typu SFM3520 od firmy Suprema, Inc. Je ovšem nutné, aby bylo v budoucnu možné systém jednoduše propojit s moduly jiných typů a výrobců. Správa systému, tj. evidence zaměstnanců, evidence objektů v areálu a správa oprávnění budou prováděny přes webové rozhraní. Registrace nových otisků bude prováděna pomocí desktopové aplikace. Je proto nutné, aby k systému bylo možné přistupovat 9

2. ANALÝZA vzdáleně. Toto vzdálené rozhraní bude využíváno také programem pro sběr dat z terminálů. Vzdálené rozhraní bude obsahovat metody pro registraci přihlašovacích údajů a pro uložení transakce (interakce zaměstnance s terminálem) do databáze. 2.9 Embedded modul SFM3520 Vstupní terminál, který bude použit jako reference, vyrábí společnost Suprema, Inc. a jedná se o embeded modul SFM3520 2, disponující čtečkou otisku prstu a 4 MB interní flash pamětí. Otisk prstu se v paměti ukladá v podobě tzv. šablony, což je 256 B hash. Specifikace uvádí [1], že pamět je schopna těchto šablon uchovat až 9000. Při pokusu o identifikaci uživatele je tento hash vypočítán z nově sejmutého otisku a porovnán s šablonami uloženými v paměti. Každá transakce (pokus o ověření), at už úspěšná, či neúspěšná, je taktéž uložena v paměti. Těchto transakcí se do paměti vejde 12800. Neúspěšné transakce nemusí znamenat pouze pokus o neoprávněný vstup do objektu. Pokud je povolané osobě umožněn vstup až po několikanásobném pokusu o indentifikaci, znamená to, že je zřejmě nutná nová registrace otisku prstu, nebo dodatečné proškolení osoby o používání čtecího zařízení. 2.10 Aplikace pro sběr dat Aplikace pro sběr dat z terminálů, napsaná v jazyku C++, využívá API 3 modulu SFM3520, které je dodáváno společně s modulem. Tato aplikace je již hotová, nejsem jejím autorem, a proto se jí dále v této práci nebudu věnovat. V kapitole Návrh a implementace je uveden část kódu, který je možno použít pro připojení k EJB modulu z desktopové aplikace, psané v C++. 2. http://www.supremainc.com/eng/product/em_12_n.php 3. Application programming interface 10

2. ANALÝZA Funkční požadavky na systém 1. Systém bude spravovat oprávnění uživatelů ke vstupu do chráněných zón organizace. 2. Systém bude umožňovat registraci nového pracovníka, včetně editace jeho osobních údajů. 3. Systém bude umožňovat správu oprávnění pro vstup do objektů pro jednotlivé role. 4. Systém bude umožňovat správu budov, podbudov (místností) a příslušných vstupních zařízení. 5. Systém bude umožňovat oprávněným uživatelům kontrolovat pohyb lidí po areálu. 6. Při kontrole pohybu bude možné zvolit sledované časové období a/nebo objekt a/nebo uživatele, kterého chceme sledovat. 7. Jednotlivým rolím bude možné omezit přístup do jednotlivých částí aplikace. Nefunkční požadavky na systém 1. Systém bude implementován jako webová aplikace v jazyce Java EE. 2. Aplikační vrstva bude tvořena technologií Enterprise Java Beans a bude umožňovat přístup jak přes webovou aplikaci, tak přes desktopovou aplikaci (pouze pro některé funkce). 11

2. ANALÝZA 2.11 Use Case diagram 12

3 Návrh a implementace 3.1 Použité technologie a nástroje 3.1.1 Java Enterprise Edition (Java EE) Java EE je součást platformy Java, určená pro vývoj informačních systémů a serverových aplikací. Vývoj platformy, resp. jejich dílčích specifikací funguje ve spolupráci více firem v tzv. Java Community Process (JCP) 1. Součástí Javy EE jsou specifikace pro vývoj webových aplikací (např. Java Server Pages), vývoj business logiky (např. Enterprise Java Beans nebo Spring), přístup ke zprávovému middleware (Java Messaging Services), podpora webových služeb a další. 3.1.2 GlassFish Server Aplikační server vyvinutý společností Sun Microsystems. Slouží jako referenční server, tzn. jako ukázka implementace nových vlastnostní specifikace Java EE. Od verze 2 je ale ve stavu production-ready, je tedy možné jeho produkční nasazení [6]. Jeho použití se řídí licencemi GPL (GNU General Public Licence) 2 a CDDL (Common Development and Distribution License) 3. 3.1.3 Enterprise Java Beans 3 (EJB 3) Enterprise Java Beans je součástí specifikace Java EE a slouží pro vývoj aplikační vrstvy informačního systému. Architektura EJB je založena na komponentách, což jsou části systému, které zajišt ují business logiku aplikace [8]. V EJB můžeme využívat následující typy komponent. Entity Bean Třída, které přiřadíme anotaci @EntityBean reprezentuje entitu aplikace a slouží jako základ objektově-relačního mapování (ORM). 1. http://jcp.org/en/home/index 2. http://www.gnu.org/licenses/old-licenses/gpl-2.0.html 3. http://www.sun.com/cddl/cddl.html 13

3. NÁVRH A IMPLEMENTACE EJB pro tyto entity zajišt uje persistenci pomocí Java Persistence API (JPA). Stateless Session Bean Třída s anotací @Stateless je obvykle implementací veřejného rozhraní aplikace. Klienti tato rozhraní využívají pro provádění business operací. Jak název napovídá, tato třída je bezstavová, tzn. neuchovává žádné informace napříč jednotlivými požadavky. Stateful Session Bean Podobně jako Stateless Session Bean, i Stateful Session Bean obvykle implementuje veřejné rozhraní aplikace. Tato třída je ale stavová, tzn. podobně jako HTTP Session si uchovává stav po celou dobu komunikace s klientem. Klient se proto může spolehnout, že uložené informace zůstanou i při dalším požadavku. Třída je označená anotací @Stateful. Každý klient má svou vlastní Stateful Session Bean, se kterou komunikuje. Typickým příkladem použití je nákupní košík. Message-Driven Bean Slouží pro asynchronní komunikaci pomocí Java Messaging Services. Tento typ komponenty se označuje anotací @MessageDriven a kromě této anotace musí navíc implementovat rozhraní služby pro zasílání zpráv (např. javax.jms.messagelistener, který je nejběžnější). Příklad kódu pro vzdálené připojení k EJB modulu (C++): try { InitialContext ictx(_use_java_ctor); Context ctx = Context::dyna_cast( ictx.lookup("java:comp/env")); Object ref = myenv.lookup( "ejb/iremotetransactionsmanager"); IRemoteTransactionsManager manager = RemoteTransactionsManager::dyna_cast( 14

3. NÁVRH A IMPLEMENTACE )); PortableRemoteObject::narrow(ref, Class::forName(REMOTE_CLASS_NAME) // volani vzdalene metody manager.savetransaction(user_id, timestamp); } catch(exception & e) { cerr<<"unexpected exception!"<<endl; e.printstacktrace(); } Příklad vzdáleného EJB rozhraní: @Remote public interface IRemoteTransactionsManager { public void savetransaction(int user_id, int timestamp); } 3.1.4 Stripes Framework Stripes je prezentační framework pro jazyk Java EE, který tvoří nástavbu nad Java Servlety. Vývoj webových aplikací pomocí tohoto frameworku je velice snadný díky některým jeho klíčovým vlastnostem [7]: Stripes nevyžaduje žádnou zbytečnou konfiguraci. Pro první spuštění stačí velmi malý XML soubor, ostatní vlastnosti se definují pomocí anotací. Velmi jednoduchá možnost validace uživatelských vstupů (s podporou lokalizace). Snadná práce s formuláři a podpora více akcí u jednoho formuláře. A další... 15

3. NÁVRH A IMPLEMENTACE 3.1.5 Java Server Pages (JSP) JSP společně s JSTL (JSP Standard Tag Library) 4 slouží k vytváření šablon internetových stránek. 3.1.6 HyperText Markup Language (HTML) Značkovací jazyk používaný pro popis a vytvoření struktury webových stránek [2]. Jeho počátky sahají do roku 1990, kdy základy tomuto jazyku položili Tim Berners-Lee a Robert Cailliau. Jazyk HTML byl vyvinut jako aplikace jazyka SGML (Standard Generalized Markup Language). V současné době nejpoužívanější specifikace je HTML 4.01 5. Touto verzí byl také vývoj jazyka původně ukončen a jeho následovníkem měl být jazyk XHTML (extensible Hyper- Text Markup Language), který je založený na univerzální specifikaci jazyka XML (extensible Markup Language). Tento vývoj jazyka se ale ukázal jako slepá větev. Nejnovější specifikace jazyka se nazývá HTML 5. Jeho vývoj začal v roce 2004 a nyní se nachází teprve na počátku. 3.1.7 MySQL Jako úložiště dat je použit databázový systém MySQL 6. Využita je verze MySQL Community Server, která je dostupná pod licencí GPL. S vývojem začala švédská firma MySQL AB. Nyní jej vlastní Sun Microsystems a nabízí také placenou verzi pro komerční účely, označenou MySQL Enterprise Edition. Jako naprostá většina relačních databázových systémů, i MySQL používá pro komunikaci jazyk SQL (Structured Query Language), resp. jeho dialekt. V současné době je k dispozici verze s označením 5.5. Od verze 5.1 MySQL plně podporuje pohledy, uložené procedury a triggery [4]. MySQL nabízí podporu různých úložných enginů, z nichž nejpoužívanější jsou MyISAM a InnoDB. Všeobecně je InnoDB novější 4. http://java.sun.com/products/jsp/jstl/reference/docs/ index.html 5. http://www.w3.org/tr/1999/rec-html401-19991224/ 6. http://www.mysql.com 16

3. NÁVRH A IMPLEMENTACE a nabízí více možností (podporuje cizí klíče, row-level 7 uzamykání tabulek, transakce), oproti staršímu MyISAM. Nicméně i MyISAM podporuje některé věci, kterými InnoDB nedisponuje, například fulltextové indexy (indexují se jednotlivá slova) použitelné pro složitější vyhledávací operace. 3.2 Aplikační část Jak již bylo řečeno, model aplikace bude vytvořen pomocí technologie EJB. Podle analýzy můžeme model rozdělit na 4 balíčky. 3.2.1 Balíček Users Balíček bcthesis.model.users bude obsahovat všechny entity týkající se správy uživatelů (User, Role, UserAcl) a rozhraní IUsersManager, které bude obsahovat metody pro práci s těmito entitami, jako jsou například vytváření, úprava a mazání uživatelů systému, vytváření a přiřazování rolí jednotlivým uživatelům a další. Implementace rozhraní IUsersManager se jmenuje UsersManager. Dalé balík obsahuje rozhraní IAuthenticator, obsahující jedinou metodu authenticate(string email, String password), která slouží k autentizaci uživatele pro přístup do webové aplikace a vzdálené rozhraní IRemoteUsersManager, které slouží pro registraci otisku prstů. Balíček také zajišt uje nastavení ACL 8 pro přístup do webové aplikace. 3.2.2 Balíček Buildings Tento balíček (bcthesis.model.buildings) bude obsahovat veškeré entity týkající se správy budov a vstupních zařízení a rozhraní IBuildingsManager, který bude s těmito entitami pracovat. 7. InnoDB podporuje uzamykání tabulky po řádcích. MyISAM podporuje uzamykání pouze celé tabulky. 8. Access Control List 17

3. NÁVRH A IMPLEMENTACE 3.2.3 Balíček Permissions Balíček bcthesis.model.permissions je určen ke správě oprávnění zaměstnanců ke vstupu do chráněných objektů organizace. Obsahuje entitu Permission a rozhraní IPermissionManager, který tyto oprávnění nastavuje. Dále obsahuje rozhraní IRemotePermissionsManagement, které slouží pro vzdálené dotazování na oprávnění osoby ke vstupu do konkrétní budovy. 3.2.4 Balíček Transactions Balíček bcthesis.model.transactions je určen k ukládání a prohlížení interakcí zaměstnanců a vstupních zařízení, tzn. jednotlivých průchodů přes terminály. Kromě entity Transaction a rozhraní ITransactionsManager obsahuje také již zmíněné rozhraní IRemoteTransactionsManager, které slouží pro ukládání transakcí vzdáleným zařízením. 3.2.5 Příklady rozhraní v balíčku bcthesis.model.users Rozhraní IUsersMnager: @Local public interface IUsersManager { public boolean hasaccessto(user user, AclResource resource, AclAction action); public User finduserbyid(int id); public void saveuser(user user); public void deleteuser(user user); public List<User> findusersbyname(string name); public List<User> findallusers(); public List<Role> findallroles(); public List<UserAcl> findalluseracls(role role); public boolean isinrole(user user, Role role); public void updateroles(user user, int[] roles); public Role findrolebyid(int id); public void insertuseracl(role role, 18

3. NÁVRH A IMPLEMENTACE AclResource resource, AclAction action); public void deleteuseracl(int id); } Rozhraní IAuthenticator: @Local public interface IAuthenticator { public User authenticate(string email, String password) throws AuthenticationException; } 3.3 Datový model Data aplikace budou uchovávány v relační databázi (RDBS 9 ). Pro vývoj jsem použil databázi MySQL, ale vzhledem k univerzálnosti Enterprise Java Beans je možné použit jakýkoliv relační databázový systém. Stačí upravit SQL skript pro vytvoření databázového schéma, aby odpovídal případné odlišné syntaxi použitého RDBS. Kompletní skript pro vytvoření databázového schématu je uveden v příloze A. 9. Relational Database Management System 19

3. NÁVRH A IMPLEMENTACE 3.4 ERD diagram 3.5 Webová část Webová aplikace je vytvořena pomocí Stripes Frameworku a Java Server Pages. Stripes Framework využívá principů MVC architektury 10. 3.5.1 Model View Controller MVC architektura (dříve označovaná také jako Model 2) rozděluje aplikaci na 3 části model, view a controller. Model představuje business logiku aplikace a view se stará o vykreslení uživatelského roz- 10. Model View Controller 20

3. NÁVRH A IMPLEMENTACE hraní. Controller přijímá požadavky od uživatele a reaguje na ně voláním business metod modelu a odesláním správného view zpět k uživateli. Mezi hlavní výhody tohoto přístupu patří rychlejší údržba, efektivnější odhalování chyb, znovupoužitelnost kódu nebo snadnější rozšiřitelnost aplikace. Model aplikace je v tomto případě vytvořen pomocí Enterprise Java Beans. I když jsou view a controller víceméně logicky propojeny, o zobrazování dat se starají Java Server Pages. Jejich úlohou je generovat HTML výstup, který je odeslán uživateli. Stripes Framework obsahuje rozhraní nazvané ActionBean. Třídy implementující toto rozhraní se dají považovat za controller a jsou stěžejní částí webové aplikace. Následující obrázek ukazuje, jak probíhá komunikace celého systému při konkrétním požadavku od uživatele (Registrace nového zaměstnance). 21

3. NÁVRH A IMPLEMENTACE 3.5.2 Registrace uživatele 3.5.3 Návrh uživatelského rozhraní Grafické uživatelské rozhraní (GUI 11 nebo také UI 12 ) je důležitou částí každé aplikace. Právě uživatelské rozhraní je jedinou částí aplikace (mimo hardwarové prvky), která je viditelná pro uživatele systému. Úspěch aplikace z velké části závisí na kvalitě uživatelského rozhraní. UI musí být přívětivé, jednoduché a snadno ovladatelné. Existuje řada metod jak testovat použitelnost 13 UI. Nejčastější metodou testování webových aplikací je uživatelské testování. 11. Graphic User Interface 12. User Interface 13. http://en.wikipedia.com/usability 22

3. NÁVRH A IMPLEMENTACE 3.5.4 Ukázka uživatelského rozhraní 3.6 Vzdálený přístup Díky technologii EJB je možné k aplikaci přistupovat vzdáleně, tzn. klient nemusí běžet na stejném aplikačním serveru jako samotná aplikace. Tento přístup využijeme při registraci otisku prstu. Program, který bude registraci zajišt ovat, bude využívat vzdálené rozhraní IRemoteUsersManager. Toto rozhraní vypadá následovně: @Remote public interface IRemoteUsersManager { public boolean registerfingerprint( int user_id, String template ); } 23

4 Závěr Cílem práce bylo navrhnout a implementovat webovou aplikaci pro správu docházkového systému. Hlavní důraz měl být kladen na to, aby byla aplikace univerzální, tj. aby se dala používat ve spolupráci s různými typy přístupových terminálů. Implementace tohoto požadavku byla provedena pomocí technologie EJB, díky které je možné k aplikaci přistupovat jak lokálně (tzn. z aplikace běžící na stejném serveru), tak vzdáleně z různých typů zařízení a platform. Aplikaci se mi podařilo zrealizovat a všechny požadované klíčové vlastnosti byly implementovány. Velkým přínosem pro mě samotného bylo detailnější porozumění použitým technologiím, hlavně EJB a Stripes Frameworku. V budoucnu je možné aplikaci rozšířit například o modul pro výpočet mzdy podle odpracovaných hodin nebo statistiky příchodů a odchodů. Webovou část aplikace je možné rozšířit o vylepšené grafické zobrazení půdorysu areálu s jednotlivými sledovanými objekty a zobrazování pohybu osob v těchto objektech. 24

Literatura [1] Suprema SFM3520 Specification. http://www.supremainc. com/eng/product/em_12_n.php#tab2. [2] Wikipedia: HTML [online]. http://en.wikipedia.org/ wiki/html, 20. 12. 2010. [3] Zákoník práce. http://www.mpsv.cz/files/clanky/ 2919/262-2006.pdf, 2006. [4] Wikipedia: MySQL [online]. http://cs.wikipedia.org/ wiki/mysql, 8. 11. 2010. [5] AVARIS, s.r.o. Prezentační CD. http://www.avaris.cz/ ke-stazeni/prospekty/prezentace.zip, 2006. [6] The GlassFish Comunity. Glassfish overview. http:// glassfish.java.net/faq/v2/glassfishoverview.pdf, 2007. [7] Daoud, F., Fennell, T. Stripes...and Java Web Development Is Fun Again. The Pragmatik Bookshelf, 2008. [8] Keith, M., Schincariol, M. Pro EJB 3: Java Persistence API. APress, 2006. [9] EFG CZ spol. s r.o. Katalog produktů. http://www.efg. cz/documents/identifikacni%20systemy/aktion/ Katalog%20Aktion%202006.pdf, 2005. 25

5 Příloha A SQL kód -- t a b l e d e f i n i t i o n s CREATE TABLE building ( id int(11) NOT NULL AUTO_INCREMENT, idc varchar(10) NOT NULL, parent_id int(11) DEFAULT NULL, name varchar(100) NOT NULL, active tinyint(1) NOT NULL DEFAULT 1, purpose varchar(100) DEFAULT NULL, PRIMARY KEY ( id ), KEY parent_id ( parent_id ) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE enter_device ( id int(11) NOT NULL AUTO_INCREMENT, building_id int(11) NOT NULL, name varchar(100) NOT NULL, active tinyint(1) NOT NULL, address varchar(60) NOT NULL, PRIMARY KEY ( id ), KEY building_id ( building_id ), KEY active ( active ) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE user ( id int(11) NOT NULL AUTO_INCREMENT, idc varchar(10) NOT NULL, email varchar(60) NOT NULL, firstname varchar(60) NOT NULL, surname varchar(60) NOT NULL, password varchar(200) DEFAULT NULL, salt varchar(200) DEFAULT NULL, 26