}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Aplikace pro správu docházkového/bezpeˇcnostního systému ˇ B AKALÁ RSKÁ PRÁCE
Martin Jakubec
Brno, podzim 2010
Prohlášení Prohlašuji, že tato bakaláˇrská práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.
Martin Jakubec
Vedoucí práce: Mgr. Martin Jakubiˇcka ii
Podˇekování Chtˇel bych podˇekovat vedoucímu práce Mgr. Martinovi Jakubiˇckovi za rady a pˇripomínky a za umožnˇení práce na vlastní téma.
iii
Shrnutí Cílem této bakaláˇrské práce je navrhnout a implementovat webovou aplikaci pro správu docházkového/bezpeˇcnostního systému. Aplikace bude implementována v jazyce Java EE za pomoci Stripes Frameworku a Enterprise Java Beans 3.0.
iv
Klíˇcová slova docházkový systém, webová aplikace, Java EE, EJB 3, Stripes Framework, objektová analýza a návrh
v
Obsah 1 2
3
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analýza . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Souˇcasné systémy . . . . . . . . . . . . . . . . . . . . 2.2 Proˇc zavádˇet pˇrístupové/docházkové systémy? . . 2.3 Možnosti zamezení pˇrístupu . . . . . . . . . . . . . 2.4 Komunikace s terminálem . . . . . . . . . . . . . . . 2.5 Rozdˇelení terminálu˚ . . . . . . . . . . . . . . . . . . 2.5.1 Kontaktní . . . . . . . . . . . . . . . . . . . . 2.5.2 Bezkontaktní . . . . . . . . . . . . . . . . . . 2.5.3 On-line . . . . . . . . . . . . . . . . . . . . . . 2.5.4 Off-line . . . . . . . . . . . . . . . . . . . . . . 2.6 Dodavatelé docházkových systému˚ . . . . . . . . . . 2.6.1 EFG CZ spol. s r.o. . . . . . . . . . . . . . . . 2.6.2 AVARIS, s.r.o. . . . . . . . . . . . . . . . . . . 2.6.3 ANeT-Advanced Network Technology, s.r.o. 2.6.4 IReSoft, s.r.o. . . . . . . . . . . . . . . . . . . 2.7 Zhodnocení . . . . . . . . . . . . . . . . . . . . . . . 2.8 Požadavky na systém . . . . . . . . . . . . . . . . . . 2.9 Embedded modul SFM3520 . . . . . . . . . . . . . . 2.10 Aplikace pro sbˇer dat . . . . . . . . . . . . . . . . . . 2.11 Use Case diagram . . . . . . . . . . . . . . . . . . . . Návrh a implementace . . . . . . . . . . . . . . . . . . . . 3.1 Použité technologie a nástroje . . . . . . . . . . . . . 3.1.1 Java Enterprise Edition (Java EE) . . . . . . . 3.1.2 GlassFish Server . . . . . . . . . . . . . . . . 3.1.3 Enterprise Java Beans 3 (EJB 3) . . . . . . . . 3.1.4 Stripes Framework . . . . . . . . . . . . . . . 3.1.5 Java Server Pages (JSP) . . . . . . . . . . . . . 3.1.6 HyperText Markup Language (HTML) . . . 3.1.7 MySQL . . . . . . . . . . . . . . . . . . . . . . 3.2 Aplikaˇcní cˇ ást . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Balíˇcek Users . . . . . . . . . . . . . . . . . . 3.2.2 Balíˇcek Buildings . . . . . . . . . . . . . . . . 3.2.3 Balíˇcek Permissions . . . . . . . . . . . . . . 3.2.4 Balíˇcek Transactions . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 4 4 4 5 5 6 6 6 6 7 7 8 8 8 9 9 9 10 10 12 13 13 13 13 13 15 16 16 16 17 17 17 18 18 1
3.2.5 Pˇríklady rozhraní v balíˇcku bcthesis.model.users Datový model . . . . . . . . . . . . . . . . . . . . . . . . ERD diagram . . . . . . . . . . . . . . . . . . . . . . . . Webová cˇ ást . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Model–View–Controller . . . . . . . . . . . . . . 3.5.2 Registrace uživatele . . . . . . . . . . . . . . . . 3.5.3 Návrh uživatelského rozhraní . . . . . . . . . . 3.5.4 Ukázka uživatelského rozhraní . . . . . . . . . . 3.6 Vzdálený pˇrístup . . . . . . . . . . . . . . . . . . . . . . Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pˇríloha A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 3.4 3.5
4 5
18 19 20 20 20 22 22 23 23 24 26
2
1 Úvod Elektronické informaˇcní systémy (IS) se dnes staly již nezbytnou soucˇ ástí rˇ ízení moderního podniku. Umožnují ˇ mimo jiné rychlejší práci, efektivnˇejší plánování a lepší využití finanˇcních a lidských zdroju. ˚ Využití výhod automatizované správy a uložení dat si dnes uvˇedomuje drtivá vˇetšina spoleˇcností. Finanˇcní prostˇredky, investované do nákupu nebo vývoje takového systému, se mnohonásobnˇe vrátí cˇ asem ušetˇreným za správu papírové kartotéky. Informaˇcní systémy mohou být rozsáhlé a mohou rˇ ešit celou sadu úloh (úˇcetnictví, sklad, rˇ ízení podniku), nebo naopak mohou být zamˇerˇ eny na jeden konkrétní problém. Tato bakaláˇrská práce se zabývá návrhem a implementací aplikace pro správu docházky. Na cˇ eském i zahraniˇcním trhu je spousta spoleˇcností, které poskytují pˇrístupové systémy ruzného ˚ zamˇerˇ ení a ruzného ˚ rozsahu. Tyto systémy vˇetšinou slouží pro evidenci docházky zamˇestnancu˚ nebo sledování jejich pohybu po areálu po dobu pracovní doby. Cena tˇechto systému˚ se odvíjí od poˇctu zamˇestnancu˚ a poˇctu vstupních zaˇrízení (terminálu). ˚ Tato investice se vˇetšinou vyplatí i menším firmám do 50 zamˇestnancu. ˚ Problém nastává v pˇrípadˇe, kdy máme k dispozici vlastní terminály a potˇrebujeme pouze software. Vˇetšina firem dodává pouze kompletní rˇ ešení, vˇcetnˇe hardwarových souˇcástí. Vývoj aplikace pro správu vlastních hardwarových souˇcástí bývá obvykle velmi nákladný. Cílem této bakaláˇrské práce je navrhnout a implementovat aplikaci pro jednoduchou správu takovéhoto systému. V kapitole 2 se vˇenuji získávání poznatku˚ o dostupných systémech, abych mohl co nejlépe navrhnout aplikaci pro naše potˇreby. Postupnˇe uvádím informace o moderních docházkových systémech, o typech a konstrukci vstupních terminálu˚ a v neposlední rˇ adˇe zminuji ˇ nˇekolik cˇ eských spoleˇcností, které se vývojem takových systému˚ zabývají a struˇcnˇe pˇredstavuji jejich rˇ ešení. Ve 3. kapitole získané poznatky aplikuji v samotném návrhu a implementaci vlastního rˇ ešení.
3
2 Analýza ˇ podle zákona cˇ . 262/2006 Sb., V souˇcasné dobˇe je každá firma v CR zákoník práce [3], povinna evidovat docházku svých zamˇestnancu. ˚ Evidence docházky má ale i jiná opodstatnˇení, snadno lze napˇríklad kontrolovat pozdní pˇríchody. Výstupy tˇechto systému˚ (at’ už elektronických nebo papírových) lze použít pro statistické úˇcely, nebo k výpoˇctu mzdy. Pˇri použití elektronického informaˇcního systému se tyto možnosti ještˇe více zjednoduší. Odpadá nutnost ruˇcního pˇrepoˇcítávání údaju˚ z papírové karty zamˇestnance, poˇcítaˇcový systém za vás udˇelá vše potˇrebné a bez chyb. Pro areály podléhající pˇrísnˇejším bezpeˇcnostním podmínkám lze monitorovat pohyb osob a rˇ ídit pˇrístup do jednotlivých objektu. ˚
2.1
Souˇcasné systémy
V souˇcasné dobˇe existuje už jen minimální množství spoleˇcností, které stále využívají papírové karty pro evidenci docházky.
2.2
Proˇc zavádˇet pˇrístupové/docházkové systémy?
•
Automatická kontrola pozdních pˇríchodu˚ do zamˇestnání.
•
Automatizované získání statistických informací pro rˇ ízení firmy.
•
Pohyb osob je možný omezit v cˇ ase.
•
Je možné mˇenit oprávnˇení vstupu zamˇestnancu˚ z jednoho místa, aniž by konkrétní zamˇestnanec musel být pˇrítomen.
•
Je možné sledovat pohyb osob po areálu.
•
Je možné zpoplatnit pobyt v urˇcitých objektech napˇr. hodinovou sazbou. Tento zpusob ˚ se dá využít napˇríklad na parkovištích, ve fitcentrech, ve sportovních nebo jiných rekreaˇcních zaˇrízeních. 4
2. A NALÝZA •
2.3
K pˇrístupu do uzamknutých cˇ ástí areálu není nutný fyzický klíˇc (vˇetší množství klíˇcu). ˚ Všechny klíˇce nahradí napˇr. jedna cˇ ipová karta nebo otisk prstu.
Možnosti zamezení pˇrístupu
Turniket Turniket je nejménˇe bezpeˇcné vstupní zaˇrízení. Nepovolaná osoba muže ˚ velmi snadno pˇres turniket projít, pokud není vybaven další mˇrížovou konstrukcí okolo samotné závory. Konstrukce turniketu vˇetšinou umožnuje ˇ nežádoucí pˇrístup více osobám najednou, proto je tento typ vstupního zaˇrízení vhodný pro objekty s nízkou požadovanou úrovní zabezpeˇcení, nebo pro místa s dodateˇcnou ostrahou, napˇr. vrátným. Závora Vstupní zaˇrízení vhodné pro omezení pˇrístupu automobilu. ˚ Zavˇrená závora neumožnuje ˇ volný prujezd ˚ automobilu. Konstrukce závory umožnuje ˇ pruchod ˚ osoby. Tento typ zaˇrízení je proto vhodný pro parkovištˇe. Dveˇre s elektromagnetickým zámkem Nejbezpeˇcnˇejší vstupní zaˇrízení ze jmenovaných. Pˇredpokládá se, že neautorizované osoby nejsou schopny dveˇre otevˇrít bez použití hrubé síly. U dveˇrí je umístˇen terminál, který dveˇre odemkne po identifikaci a úspˇešné autorizaci zamˇestnance. Jakmile se dveˇre otevˇrou, je umožnˇen pruchod ˚ více osobám.
2.4
Komunikace s terminálem
Nejlevnˇejší varianta terminálu je tzv. terminál programovatelný master kartou. Tyto terminály jsou schopny pracovat bez použití poˇcítaˇce a není potˇreba, aby byly pˇripojeny do sítˇe. Programování a nastavení tohoto typu terminálu se provádí pomocí master karty, která je jedineˇcná, a terminál si ji zapamatuje jako první kartu pˇriloženou po 5
2. A NALÝZA zapnutí napájení. Další karty již bere jako normální pˇrístupové. Tato varianta je vhodná pouze pro menší firmy, kde není nutné data v terminálu cˇ asto mˇenit. Nastavení je totiž nepohodlné a cˇ asovˇe nároˇcné. Všechny ostatní terminály jsou nˇejakým zpusobem ˚ propojeny s centrální rˇ ídicí jednotkou. Komunikaˇcním médiem je obvykle ethernetová sít’ nebo sériová linka (RS-232, RS-485), pˇrípadnˇe wi-fi.
2.5
Rozdˇelení terminálu˚
Terminálu˚ existuje celá rˇ ada. Volba konkrétního typu terminálu závisí na požadavcích investora. Solidní dodavatel s výbˇerem poradí a dodá rˇ ešení na míru potˇrebám konkrétního podniku. Terminály mužeme ˚ dˇelit podle mnoha kritérií (zpusob ˚ komunikace, zpusob ˚ identifikace osoby, konstrukˇcní provedení, a jiné). Níže uvádím nˇekolik typu˚ zaˇrízení, jejichž volba má zásadní vliv na funkci požadovaného rˇ ešení. 2.5.1 Kontaktní Identifikace pracovníka probíhá díky fyzickému kontaktu s terminálem. Napˇr. klávesnice pro zadání ID zamˇestnance, snímaˇc otisku prstu, snímaˇc magnetické karty. 2.5.2 Bezkontaktní Identifikace pracovníka probíhá bez fyzického kontaktu. Napˇr. bezkontaktní cˇ ipová karta. 2.5.3 On-line Veškeré informace o pˇrístupech a interakcích s uživatelem jsou ukládány na server v reálném cˇ ase, terminál sám odesílá data ihned po interakci se zamˇestnancem. Výhody: •
Možnost sledovat pohyb zamˇestnancu˚ v reálném cˇ ase. 6
2. A NALÝZA •
Není potˇreba žádný další program pro sbˇer dat.
Nevýhody: •
Teoreticky vˇetší zatížení sít’ˇe díky neustálému zasílání paketu. ˚
•
Složitˇejší rˇ í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ˇrímo do interní pamˇeti terminálu. Je potˇreba další program, který v cˇ asových intervalech prochází jednotlivé terminály, data z nich sbírá a ukládá na server. Uplatnˇení naleznou tam, kde není nutné sledovat pohyb osob v reálném cˇ ase. Výhody: •
Terminál není nutno nijak programovat. Informace jsou ukládány do vnitˇrní pamˇeti.
•
Sbˇer dat je možné provádˇet v dobˇe nejmenší zátˇeže sítˇe.
Nevýhody: •
Nutná vyšší kapacita interní pamˇeti.
•
Aktualizovaná data o pˇrístupech se v aplikaci projeví až po sbˇeru dat z terminálu. ˚
2.6
Dodavatelé docházkových systému˚
ˇ Existuje mnoho spoleˇcností, jak v Ceské Republice, tak i v zahraniˇcí, které dodávají systémy sloužící k evidenci docházky. Tyto firmy se vˇetšinou zabývají jak vývojem docházkových systému, ˚ tak všeobecnˇe vývojem systému, ˚ které ke své cˇ innosti využívají pˇrístupové terminály nebo senzory pohybu. Muže ˚ se jednat napˇríklad o systémy pro závodní jídelny (objednávky a výdej obˇedu), ˚ požární systémy, 7
2. A NALÝZA systémy pro kontrolu obchuzky, ˚ skladové systémy (s použitím cˇ árových kódu) ˚ nebo systémy pro zpoplatnˇení návštˇev (napˇr. sportovní centra). Zmíním pár tuzemských spoleˇcností, které se zabývají vývojem prumyslových ˚ pˇrístupových a bezpeˇcnostních systému, ˚ a pˇredstavím jejich rˇ ešení. 2.6.1 EFG CZ spol. s r.o. ˇ Ceská spoleˇcnost, která pro koncové zákazníky dodává systémy pro ochranu objektu˚ nebo identifikaci zamˇestnancu, ˚ vˇcetnˇe kamerových systému˚ a požární signalizace. Jejich identifikaˇcní systém AKTION obsahuje moduly pro evidenci docházky, stravování, kontrolu osob a vozidel (s rozpoznáváním SPZ1 ), kontrolu obchuzky, ˚ registraci návštˇev a další. Spoleˇcnost dodává také webovou nástavbu pro svuj ˚ software. Tento systém je velice rozsáhlý a disponuje velkým množstvím ruzných ˚ typu˚ terminálu, ˚ pˇresnˇe podle potˇreb zákazníka [9]. 2.6.2 AVARIS, s.r.o. Kromˇe prumyslových ˚ docházkových a bezpeˇcnostních systému˚ (UNIGate, A-pro, COP) nabízí také školní docházkový systém (SchoolGate), stravovací systém (AJSmenu), teplotní evidenˇcní 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ˇenská spoleˇcnost, která dodává kompletní aplikace pro rˇ ízení a využití lidských zdroju, ˚ vˇcetnˇe docházkových, pˇrístupových systému˚ a stravovacích systému. ˚ 1.
Státní Poznávací Znaˇcka
8
2. A NALÝZA 2.6.4 IReSoft, s.r.o. IReSoft, s.r.o., je další brnˇenská firma. Jejich stˇežejní produkt CYGNUS je komplexní informaˇcní 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 cˇ teˇcky otisku prstu nebo bezkontaktní cˇ ipové karty a pˇrívˇešky.
2.7
Zhodnocení
Na trhu je dostupná celá rˇ ada systému, ˚ které umožnují ˇ správu docházky, bezpeˇcnosti uvnitˇr podniku nebo celkové rˇ ízení, vˇcetnˇe napojení na ostatní moduly, jako jsou úˇcetnictví nebo mzdy. Pokud chceme vybrat systém, který bude nejlépe odpovídat našim potˇrebám, musíme si položit pár základních otázek. •
Jaká je požadovaná úrovenˇ zabezpeˇcení?
•
Jaký chceme typ pˇrístupového terminálu?
•
Kolik lidí bude mít pˇrístup do objektu?
•
Jaký požadujeme poˇcet pˇrístupových zaˇrízení?
Moderních pˇrístupových systému je spousta a liší se velikostí, rozsahem, úrovní zabezpeˇcení, rozšiˇritelností, nebo propojitelností s ostatními komerˇcními systémy.
2.8
Požadavky na systém
Základním požadavkem je propojitelnost se zaˇrízeními pro cˇ tení otisku prstu˚ 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 typu˚ a výrobcu. ˚ Správa systému, tj. evidence zamˇestnancu, ˚ evidence objektu˚ v areálu a správa oprávnˇení budou provádˇeny pˇres webové rozhraní. Registrace nových otisku˚ bude provádˇena pomocí desktopové aplikace. Je proto nutné, aby k systému bylo možné pˇristupovat 9
2. A NALÝZA vzdálenˇe. Toto vzdálené rozhraní bude využíváno také programem pro sbˇer dat z terminálu. ˚ Vzdálené rozhraní bude obsahovat metody pro registraci pˇrihlašovacích údaju˚ a pro uložení transakce (interakce zamˇestnance s terminálem) do databáze.
2.9
Embedded modul SFM3520
Vstupní terminál, který bude použit jako reference, vyrábí spoleˇcnost Suprema, Inc. a jedná se o embeded modul SFM35202 , disponující cˇ teˇckou otisku prstu a 4 MB interní flash pamˇetí. Otisk prstu se v pamˇeti ukladá v podobˇe tzv. šablony, což je 256 B hash. Specifikace uvádí [1], že pamˇet je schopna tˇechto šablon uchovat až 9000. Pˇri pokusu o identifikaci uživatele je tento hash vypocˇ ítán z novˇe sejmutého otisku a porovnán s šablonami uloženými v pamˇeti. Každá transakce (pokus o ovˇerˇ ení), at’ už úspˇešná, cˇ i neúspˇešná, je taktéž uložena v pamˇeti. Tˇechto transakcí se do pamˇeti vejde 12800. Neúspˇešné transakce nemusí znamenat pouze pokus o neoprávnˇený vstup do objektu. Pokud je povolané osobˇe umožnˇen vstup až po nˇekolikanásobném pokusu o indentifikaci, znamená to, že je zˇrejmˇe nutná nová registrace otisku prstu, nebo dodateˇcné proškolení osoby o používání cˇ tecího zaˇrízení.
2.10 Aplikace pro sbˇer dat Aplikace pro sbˇer dat z terminálu, ˚ napsaná v jazyku C++, využívá 3 API modulu SFM3520, které je dodáváno spoleˇcnˇe s modulem. Tato aplikace je již hotová, nejsem jejím autorem, a proto se jí dále v této práci nebudu vˇenovat. V kapitole Návrh a implementace je uveden cˇ ást kódu, který je možno použít pro pˇripojení k EJB modulu z desktopové aplikace, psané v C++. 2. 3.
http://www.supremainc.com/eng/product/em_12_n.php Application programming interface
10
2. A NALÝZA Funkˇcní požadavky na systém 1.
Systém bude spravovat oprávnˇení uživatelu˚ ke vstupu do chránˇených zón organizace.
2.
Systém bude umožnovat ˇ registraci nového pracovníka, vˇcetnˇe editace jeho osobních údaju. ˚
3.
Systém bude umožnovat ˇ správu oprávnˇení pro vstup do objektu˚ pro jednotlivé role.
4.
Systém bude umožnovat ˇ správu budov, podbudov (místností) a pˇríslušných vstupních zaˇrízení.
5.
Systém bude umožnovat ˇ oprávnˇeným uživatelum ˚ kontrolovat pohyb lidí po areálu.
6.
Pˇri kontrole pohybu bude možné zvolit sledované cˇ asové období a/nebo objekt a/nebo uživatele, kterého chceme sledovat.
7.
Jednotlivým rolím bude možné omezit pˇrístup do jednotlivých cˇ ástí aplikace.
Nefunkˇcní požadavky na systém 1.
Systém bude implementován jako webová aplikace v jazyce Java EE.
2.
Aplikaˇcní vrstva bude tvoˇrena technologií Enterprise Java Beans a bude umožnovat ˇ pˇrístup jak pˇres webovou aplikaci, tak pˇres desktopovou aplikaci (pouze pro nˇekteré funkce). 11
2. A NALÝ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ˇcást platformy Java, urˇcená pro vývoj informaˇcních systému˚ a serverových aplikací. Vývoj platformy, resp. jejich dílˇcích specifikací funguje ve spolupráci více firem v tzv. Java Community Process (JCP)1 . Souˇcástí Javy EE jsou specifikace pro vývoj webových aplikací (napˇr. Java Server Pages), vývoj business logiky (napˇr. Enterprise Java Beans nebo Spring), pˇrístup ke zprávovému middleware (Java Messaging Services), podpora webových služeb a další. 3.1.2 GlassFish Server Aplikaˇcní server vyvinutý spoleˇcností Sun Microsystems. Slouží jako referenˇcní 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ˇcní nasazení [6]. Jeho použití se rˇ í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ˇcástí specifikace Java EE a slouží pro vývoj aplikaˇcní vrstvy informaˇcního systému. Architektura EJB je založena na komponentách, což jsou cˇ ásti systému, které zajišt’ují business logiku aplikace [8]. V EJB mužeme ˚ využívat následující typy komponent. Entity Bean Tˇrída, které pˇriˇradíme anotaci @EntityBean reprezentuje entitu aplikace a slouží jako základ objektovˇe-relaˇcního mapování (ORM). 1. 2. 3.
http://jcp.org/en/home/index http://www.gnu.org/licenses/old-licenses/gpl-2.0.html 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ˇrída s anotací @Stateless je obvykle implementací veˇrejného rozhraní aplikace. Klienti tato rozhraní využívají pro provádˇení business operací. Jak název napovídá, tato tˇrída je bezstavová, tzn. neuchovává žádné informace napˇríˇc jednotlivými požadavky. Stateful Session Bean Podobnˇe jako Stateless Session Bean, i Stateful Session Bean obvykle implementuje veˇrejné rozhraní aplikace. Tato tˇrída je ale stavová, tzn. podobnˇe jako HTTP Session si uchovává stav po celou dobu komunikace s klientem. Klient se proto muže ˚ spolehnout, že uložené informace zustanou ˚ i pˇri dalším požadavku. Tˇrída je oznaˇcená anotací @Stateful. Každý klient má svou vlastní Stateful Session Bean, se kterou komunikuje. Typickým pˇríkladem použití je nákupní košík. Message-Driven Bean Slouží pro asynchronní komunikaci pomocí Java Messaging Services. Tento typ komponenty se oznaˇcuje anotací @MessageDriven a kromˇe této anotace musí navíc implementovat rozhraní služby pro zasílání zpráv (napˇr. javax.jms.MessageListener, který je nejbˇežnˇejší). Pˇríklad kódu pro vzdálené pˇripojení 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ˇrí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ˇcní framework pro jazyk Java EE, který tvoˇrí nástavbu nad Java Servlety. Vývoj webových aplikací pomocí tohoto frameworku je velice snadný díky nˇekterým jeho klíˇcovým vlastnostem [7]: •
Stripes nevyžaduje žádnou zbyteˇcnou konfiguraci. Pro první spuštˇení staˇcí velmi malý XML soubor, ostatní vlastnosti se definují pomocí anotací.
•
Velmi jednoduchá možnost validace uživatelských vstupu˚ (s podporou lokalizace).
•
Snadná práce s formuláˇri a podpora více akcí u jednoho formuláˇre.
•
A další . . . 15
3. N ÁVRH A IMPLEMENTACE 3.1.5 Java Server Pages (JSP) JSP spoleˇcnˇe s JSTL (JSP Standard Tag Library)4 slouží k vytváˇrení šablon internetových stránek. 3.1.6 HyperText Markup Language (HTML) Znaˇckovací jazyk používaný pro popis a vytvoˇrení struktury webových stránek [2]. Jeho poˇcá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ˇcasné dobˇe nejpoužívanˇejší specifikace je HTML 4.015 . Touto verzí byl také vývoj jazyka puvodnˇ ˚ e ukoncˇ en a jeho následovníkem mˇel být jazyk XHTML (eXtensible HyperText 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ˇetev. Nejnovˇejší specifikace jazyka se nazývá HTML 5. Jeho vývoj zaˇcal v roce 2004 a nyní se nachází teprve na pocˇ átku. 3.1.7 MySQL Jako úložištˇe dat je použit databázový systém MySQL6 . Využita je verze MySQL Community Server, která je dostupná pod licencí GPL. S vývojem zaˇcala švédská firma MySQL AB. Nyní jej vlastní Sun Microsystems a nabízí také placenou verzi pro komerˇcní úˇcely, oznacˇ enou MySQL Enterprise Edition. Jako naprostá vˇetšina relaˇcních databázových systému, ˚ i MySQL používá pro komunikaci jazyk SQL (Structured Query Language), resp. jeho dialekt. V souˇcasné dobˇe je k dispozici verze s oznaˇcením 5.5. Od verze 5.1 MySQL plnˇe podporuje pohledy, uložené procedury a triggery [4]. MySQL nabízí podporu ruzných ˚ úložných enginu, ˚ z nichž nejpoužívanˇejší jsou MyISAM a InnoDB. Všeobecnˇe je InnoDB novˇejší 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íˇce, row-level7 uzamykání tabulek, transakce), oproti staršímu MyISAM. Nicménˇe i MyISAM podporuje nˇekteré vˇeci, kterými InnoDB nedisponuje, napˇríklad fulltextové indexy (indexují se jednotlivá slova) použitelné pro složitˇejší vyhledávací operace.
3.2
Aplikaˇcní cˇ ást
Jak již bylo rˇ eˇceno, model aplikace bude vytvoˇren pomocí technologie EJB. Podle analýzy mužeme ˚ model rozdˇelit na 4 balíˇcky. 3.2.1 Balíˇcek Users Balíˇcek bcthesis.model.users bude obsahovat všechny entity týkající se správy uživatelu˚ (User, Role, UserAcl) a rozhraní IUsersManager, které bude obsahovat metody pro práci s tˇemito entitami, jako jsou napˇríklad vytváˇrení, úprava a mazání uživatelu˚ systému, vytváˇrení a pˇriˇrazování rolí jednotlivým uživatelum ˚ 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ˇrístup do webové aplikace a vzdálené rozhraní IRemoteUsersManager, které slouží pro registraci otisku prstu. ˚ Balíˇcek také zajišt’uje nastavení ACL8 pro pˇrístup do webové aplikace. 3.2.2 Balíˇcek Buildings Tento balíˇcek (bcthesis.model.buildings) bude obsahovat veškeré entity týkající se správy budov a vstupních zaˇrízení a rozhraní IBuildingsManager, který bude s tˇemito entitami pracovat. 7. InnoDB podporuje uzamykání tabulky po rˇ ádcích. MyISAM podporuje uzamykání pouze celé tabulky. 8. Access Control List
17
3. N ÁVRH A IMPLEMENTACE 3.2.3 Balíˇcek Permissions Balíˇcek bcthesis.model.permissions je urˇcen ke správˇe oprávnˇení zamˇestnancu˚ ke vstupu do chránˇených objektu˚ organizace. Obsahuje entitu Permission a rozhraní IPermissionManager, který tyto oprávnˇení nastavuje. Dále obsahuje rozhraní IRemotePermissionsManagement, které slouží pro vzdálené dotazování na oprávnˇení osoby ke vstupu do konkrétní budovy. 3.2.4 Balíˇcek Transactions Balíˇcek bcthesis.model.transactions je urˇcen k ukládání a prohlížení interakcí zamˇestnancu˚ a vstupních zaˇrízení, tzn. jednotlivých pruchod ˚ u˚ pˇres terminály. Kromˇe entity Transaction a rozhraní ITransactionsManager obsahuje také již zmínˇené rozhraní IRemoteTransactionsManager, které slouží pro ukládání transakcí vzdáleným zaˇrízením. 3.2.5 Pˇríklady rozhraní v balíˇcku 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
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ˇcní databázi (RDBS9 ). 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ˇcní databázový systém. Staˇcí upravit SQL skript pro vytvoˇrení databázového schéma, aby odpovídal pˇrípadné odlišné syntaxi použitého RDBS. Kompletní skript pro vytvoˇrení databázového schématu je uveden v pˇríloze A.
9.
Relational Database Management System
19
3. N ÁVRH A IMPLEMENTACE
3.4
ERD diagram
3.5
Webová cˇ ást
Webová aplikace je vytvoˇrena pomocí Stripes Frameworku a Java Server Pages. Stripes Framework využívá principu˚ MVC architektury10 . 3.5.1 Model–View–Controller MVC architektura (dˇríve oznaˇcovaná také jako Model 2) rozdˇeluje aplikaci na 3 cˇ ásti – model, view a controller. Model pˇredstavuje business logiku aplikace a view se stará o vykreslení uživatelského roz10. Model–View–Controller
20
3. N ÁVRH A IMPLEMENTACE hraní. Controller pˇrijímá požadavky od uživatele a reaguje na nˇe voláním business metod modelu a odesláním správného view zpˇet k uživateli. Mezi hlavní výhody tohoto pˇrístupu patˇrí rychlejší údržba, efektivnˇejší odhalování chyb, znovupoužitelnost kódu nebo snadnˇejší rozšiˇritelnost aplikace. Model aplikace je v tomto pˇrípadˇe vytvoˇren pomocí Enterprise Java Beans. I když jsou view a controller víceménˇe 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ˇrídy implementující toto rozhraní se dají považovat za controller a jsou stˇežejní cˇ ástí webové aplikace. Následující obrázek ukazuje, jak probíhá komunikace celého systému pˇri konkrétním požadavku od uživatele (Registrace nového zamˇestnance).
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í (GUI11 nebo také UI12 ) je duležitou ˚ cˇ ástí každé aplikace. Právˇe uživatelské rozhraní je jedinou cˇ ástí aplikace (mimo hardwarové prvky), která je viditelná pro uživatele systému. Úspˇech aplikace z velké cˇ ásti závisí na kvalitˇe uživatelského rozhraní. UI musí být pˇrívˇetivé, jednoduché a snadno ovladatelné. Existuje rˇ ada metod jak testovat použitelnost13 UI. Nejˇcastˇejší 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ˇrístup
Díky technologii EJB je možné k aplikaci pˇristupovat vzdálenˇe, tzn. klient nemusí bˇežet na stejném aplikaˇcním serveru jako samotná aplikace. Tento pˇrístup využijeme pˇri registraci otisku prstu. Program, který bude registraci zajišt’ovat, bude využívat vzdálené rozhraní IRemoteUsersManager. Toto rozhraní vypadá následovnˇe: @Remote public interface IRemoteUsersManager { public boolean registerFingerprint( int user_id, String template ); }
23
4 Závˇer Cílem práce bylo navrhnout a implementovat webovou aplikaci pro správu docházkového systému. Hlavní duraz ˚ mˇel být kladen na to, aby byla aplikace univerzální, tj. aby se dala používat ve spolupráci s ruznými ˚ typy pˇrístupových terminálu. ˚ Implementace tohoto požadavku byla provedena pomocí technologie EJB, díky které je možné k aplikaci pˇristupovat jak lokálnˇe (tzn. z aplikace bˇežící na stejném serveru), tak vzdálenˇe z ruzných ˚ typu˚ zaˇrízení a platform. Aplikaci se mi podaˇrilo zrealizovat a všechny požadované klícˇ ové vlastnosti byly implementovány. Velkým pˇrínosem pro mˇe samotného bylo detailnˇejší porozumˇení použitým technologiím, hlavnˇe EJB a Stripes Frameworku. V budoucnu je možné aplikaci rozšíˇrit napˇríklad o modul pro výpoˇcet mzdy podle odpracovaných hodin nebo statistiky pˇríchodu˚ a odchodu. ˚ Webovou cˇ ást aplikace je možné rozšíˇrit o vylepšené grafické zobrazení pudorysu ˚ areálu s jednotlivými sledovanými objekty a zobrazování pohybu osob v tˇechto objektech.
24
Literatura [1] Suprema SFM3520 Specification. http://www.supremainc. com/eng/product/em_12_n.php#tab2. [2] Wikipedia: HTML [online]. wiki/HTML, 20. 12. 2010.
http://en.wikipedia.org/
[3] Zákoník práce. http://www.mpsv.cz/files/clanky/ 2919/262-2006.pdf, 2006. [4] Wikipedia: MySQL [online]. wiki/MySQL, 8. 11. 2010.
http://cs.wikipedia.org/
[5] AVARIS, s.r.o. Prezentaˇcní 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 produktu. ˚ http://www.efg. cz/documents/Identifikacni%20systemy/Aktion/ Katalog%20Aktion%202006.pdf, 2005.
25
5 Pˇrí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
ˇ 5. P RÍLOHA A
‘active‘ tinyint(1) NOT NULL DEFAULT ’1’, ‘picture‘ longblob, ‘fingerprint‘ longblob, ‘rc‘ varchar(11) NOT NULL, PRIMARY KEY (‘id‘), KEY ‘email‘ (‘email‘), KEY ‘active‘ (‘active‘) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE ‘user_role‘ ( ‘id‘ int(11) NOT NULL AUTO_INCREMENT, ‘name‘ varchar(50) NOT NULL, ‘description‘ varchar(100) DEFAULT NULL, PRIMARY KEY (‘id‘) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE ‘user_has_role‘ ( ‘user_id‘ int(11) NOT NULL, ‘role_id‘ int(11) NOT NULL, PRIMARY KEY (‘user_id‘,‘role_id‘), KEY ‘role_id‘ (‘role_id‘) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE ‘user_acl‘ ( ‘id‘ int(11) NOT NULL AUTO_INCREMENT, ‘role_id‘ int(11) NOT NULL, ‘resource‘ varchar(40) NOT NULL, ‘res_action‘ varchar(40) NOT NULL, PRIMARY KEY (‘id‘), KEY ‘role_id‘ (‘role_id‘), KEY ‘resource‘ (‘resource‘), KEY ‘res_action‘ (‘res_action‘) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE ‘role_permission‘ ( ‘id‘ int(11) NOT NULL AUTO_INCREMENT, ‘role_id‘ int(11) NOT NULL, ‘building_id‘ int(11) NOT NULL, 27
ˇ 5. P RÍLOHA A
‘since‘ timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, ‘to‘ timestamp NULL DEFAULT NULL, ‘start_time‘ timestamp NULL, ‘end_time‘ timestamp NULL, ‘repeat_type‘ varchar(20), PRIMARY KEY (‘id‘), KEY ‘role_id‘ (‘role_id‘), KEY ‘building_id‘ (‘building_id‘) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE ‘transaction‘ ( ‘id‘ int(11) NOT NULL AUTO_INCREMENT, ‘user_id‘ int(11) NOT NULL, ‘enter_device_id‘ int(11) NOT NULL, ‘type‘ enum(’in’,’out’) NOT NULL, ‘timestamp‘ timestamp NOT NULL, PRIMARY KEY (‘id‘), KEY ‘role_id‘ (‘user_id‘), KEY ‘building_id‘ (‘enter_device_id‘) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
-- t a b l e
c o n s t r a i n t s
ALTER TABLE ‘building‘ ADD CONSTRAINT ‘building_ibfk_1‘ FOREIGN KEY (‘parent_id‘) REFERENCES ‘building‘ (‘id‘); ALTER TABLE ‘enter_device‘ ADD CONSTRAINT ‘enter_device_ibfk_1‘ FOREIGN KEY (‘building_id‘) REFERENCES ‘building‘ (‘id‘); ALTER TABLE ‘user_has_role‘ ADD CONSTRAINT ‘user_has_role_ibfk_1‘ FOREIGN KEY (‘user_id‘) 28
ˇ 5. P RÍLOHA A
REFERENCES ‘user‘ (‘id‘), ADD CONSTRAINT ‘user_has_role_ibfk_2‘ FOREIGN KEY (‘role_id‘) REFERENCES ‘user_role‘ (‘id‘); ALTER TABLE ‘user_acl‘ ADD CONSTRAINT ‘user_acl_ibfk_1‘ FOREIGN KEY (‘role_id‘) REFERENCES ‘user_role‘ (‘id‘) ON DELETE CASCADE; ALTER TABLE ‘role_permission‘ ADD CONSTRAINT ‘fk2‘ FOREIGN KEY (‘building_id‘) REFERENCES ‘building‘ (‘id‘), ADD CONSTRAINT ‘fk1‘ FOREIGN KEY (‘role_id‘) REFERENCES ‘user_role‘ (‘id‘); ALTER TABLE ‘transaction‘ ADD CONSTRAINT ‘rpedfk1‘ FOREIGN KEY (‘enter_device_id‘) REFERENCES ‘enter_device‘ (‘id‘); ALTER TABLE ‘transaction‘ ADD CONSTRAINT ‘rpedfk2‘ FOREIGN KEY (‘user_id‘) REFERENCES ‘user‘ (‘id‘); -- i n i t i a l
d a t a
INSERT INTO ‘building‘ (‘id‘, ‘parent_id‘, ‘name‘, ‘active‘, ‘idc‘) VALUES (1, NULL, ’Areál’, 1, ’’); INSERT INTO ‘enter_device‘ (‘id‘, ‘building_id‘, ‘name‘, ‘active‘, ‘address‘) VALUES (1, 1, ’Hlavní vstup’, 1, ’’); 29
ˇ 5. P RÍLOHA A
INSERT INTO ‘user_role‘ (‘id‘, ‘name‘, ‘description‘) VALUES (1, ’Employee’, ’’); INSERT INTO ‘user_role‘ (‘id‘, ‘name‘, ‘description‘) VALUES (2, ’Administrator’, ’’); INSERT INTO ‘role_permission‘ (‘role_id‘, ‘building_id‘) VALUES (1, 1), (2, 1); INSERT INTO ‘user‘ (‘id‘, ‘email‘, ‘firstname‘, ‘surname‘, ‘password‘, ‘salt‘, ‘active‘, ‘picture‘, ‘idc‘, ‘rc‘) VALUES (1, ’[email protected]’, ’Martin’, ’Jakubec’, ’’, ’’, 1, NULL, ’’, ’’); INSERT INTO ‘user_has_role‘ (‘user_id‘, ‘role_id‘) VALUES (1, 1), (1, 2); INSERT INTO ‘user_acl‘ (‘role_id‘, ‘resource‘, ‘res_action‘) VALUES (2, ’Users’, ’List’), (2, ’Users’, ’Edit’), (2, ’Users’, ’Create’), (2, ’Users’, ’Delete’), (2, ’Buildings’, ’List’), (2, ’Buildings’, ’Edit’), (2, ’Buildings’, ’Create’), (2, ’Buildings’, ’Delete’), (2, ’Permissions’, ’List’), (2, ’Permissions’, ’Edit’), (2, ’Permissions’, ’Create’), (2, ’Permissions’, ’Delete’);
30
