Personální IS nemocnice v ƒeské Líp. Petr Va²ák. ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická. Diplomová práce

Transkript

1 ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Diplomová práce Personální IS nemocnice v ƒeské Líp Petr Va²ák Vedoucí práce: Ing. Martin Molhanec, CSc. Studijní program: Elektrotechnika a informatika (magisterský), dobíhající Obor: Výpo etní technika leden 2009

2 iv

3 Pod kování D kuji panu Ing. Martinu Molhancovi, CSc., vedoucímu diplomové práce, za trp livost, vedení a pomoc p i vývoji této práce a panu Ing. tefanu Nebusovi za poskytnutí zadání práce a za cenné rady b hem celého vývoje. v

4 vi

5 Prohlá²ení Prohla²uji, ºe jsem svou diplomovou práci vypracoval samostatn a pouºil jsem pouze podklady uvedené v p iloºeném seznamu. Nemám závaºný d vod proti uºití tohoto ²kolního díla ve smyslu Ÿ60 Zákona. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm n n kterých zákon (autorský zákon). V Liberci dne vii

6 viii

7 Abstract The aim of this work is to describe a development of a web application, which is instrumental to creating and managing petitions in human resources questions in the hospital of ƒeská Lípa. It should replace an ineective system of classic-paper forms manual lling and sending in the hospital. The web application should provide to the users more well-arranged and eective system of submitting, approving and/or rejection the human resources petitions. The text of the thesis contains a short introduction into the technology of Java EE and frameworks, whose funcionalities are explained on pieces of a source code of the application. Next, it pursues the analysis and the design of the application according to the method UP and the UML language. Then follows a description of the implementation of the most important application s sections from a point of view based on independent layers. Finally, it describes a usability testing of the nal application. The appendix contains i.a. an user guide in czech and a term dictionary. Abstrakt Cílem práce je popsat vývoj webové aplikace pro vytvá ení a správu ºádostí o personální zm ny v nemocnici v ƒeské Líp. M la by nahradit neefektivní manuální vypl ování a posílání papírových ºádostí v nemocnici. Aplikace by m la uºivatel m umoºnit podávání, schvalování a zamítání personálních ºádostí co nejp ehledn j²í a nejefektivn j²í formou. Text této práce podává krátký úvod do technologie Java EE a pouºitých framework, jejichº funk nost je popsána na p íkladech z aplikace. Dále se zabývá analýzou a návrhem aplikace podle metodiky UP a jazyka UML. Následuje popis implementace nejd leºit j²ích ástí, a to z pohledu aplikace zaloºené na nezávislých vrstvách. Nakonec je popsáno testování výsledné aplikace. V p íloze je pak mj. slovník pojm spolu s uºivatelskou p íru kou. ix

8 x

9 Obsah Seznam obrázk Seznam tabulek xvi xvii 1 Úvod 1 2 Pouºité technologie Technologie pro návrh a analýzu UML a Visual Paradigm for UML Unied Process Java Enterprise Edition Platforma Java a JDK Java EE Servlety a JSP Apache Tomcat IDE NetBeans MVC Webové Java frameworky Návrhové vzory Model-View-Controller Model Model Rozd lení webových Java framework MVC framework JavaServer Fages P íklad Knihovna Apache MyFaces Tomahawk ORM framework Hibernate P íklad Rela ní databáze MySQL XML technologie Knihovna DOM4J XML Schema XSL - XSLT a XPath Technologie na klientské stran HTML CSS JavaScript (ECMAScript) Úvodní studie Sou asný stav Deklarace zám ru Odborný lánek Hlavní funkce systému Názorný pr b h schvalování ºádosti Akté i Funk ní poºadavky Nefunk ní poºadavky Analýza rizik Slovník pojm xi

10 4 Analýza a návrh e²ení Stavový diagram ºádostí Akté i P ípady uºití Klí ová slova Správa ºádostí UCZ01 Prohlíºet seznam ºádostí pod ízených uºivatel UCZ02 Prohlíºet seznam v²ech ºádostí UCZ03 Prohlíºet seznam ºádostí zam stnance UCZ04 Tisknout seznamy ºádostí UCZ05 Prohlíºet detail ºádosti UCZ06 Tisknout detail ºádosti UCZ07 Zobrazit volby UCZ08 Zvolit a vyplnit ºádost UCZ09 Vytvo it ºádost UCZ10 Podat ºádost UCZ11 Zru²it ºádost UCZ12 Schválit ºádost UCZ13 Zamítnout ºádost UCZ14 Zaevidovat ºádost UCZ15 Poslat zprávu Správa uºivatel UCU01 P ihlásit UCU02 Odhlásit UCU03 Prohlíºet seznam pod ízených uºivatel UCU04 Prohlíºet seznam nad ízených uºivatel UCU05 Prohlíºet seznam v²ech uºivatel UCU06 Tisknout seznamy uºivatel UCU07 Prohlíºet detail uºivatele UCU08 Tisknout detail uºivatele UCU09 Upravit heslo UCU10 Nastavit zástupce UCU11 Vloºit uºivatele UCU12 Upravit uºivatele UCU13 P e adit uºivatele UCU14 Smazat uºivatele UCU15 Zm nit N-RLZ UCU16 Vytvo it zprávu UCU17 Poslat zprávu Správa formulá (²ablon formulá ) UCF01 Prohlíºet seznam formulá UCF02 Prohlíºet detail formulá e UCF03 Vloºit formulá UCF04 Smazat formulá Matice pokrytí funk ních poºadavk ER konceptuální model Popis entit Popis vztah Popis atribut state a role xii

11 5 Implementace Implementace p ípad uºití Tvorba formulá (²ablon formulá ) Vytvo ení ²ablony formulá e uºivatelem Zavedení ²ablony formulá e do systému Propojení ²ablony formulá e se ºádostí Aplikace zaloºená na vrstvách Fyzická vrstva Datový slovník Vztahy mezi tabulkami Integritní omezení Persistentní vrstva Business vrstva Primitivní datové typy Vztahy mezi t ídami - datové typy jako t ídy Business metody T ída User / tabulka users T ída Petition / tabulka petitions T ída Conrm / tabulka conrms T ída Form / tabulka forms T ídy Position, Workplace a Department Zm na integritního omezení ve fyzickém modelu Integra ní vrstva Nutnost pouºití nativního SQL v aplikaci - p ípad Nutnost pouºití nativního SQL v aplikaci - p ípad P ístupový objekt UserDAO Stromy a hierarchie v SQL pomocí Nested Set Model of Hierarchies Metoda deletesubtree Metoda deletemanager Metoda transfersubtree Metoda transfermanager Ostatní metody P ístupový objekt PetitionDAO P ístupový objekt FormDAO Aplika ní vrstva Backing bean Visit Backing bean AuthenticationBean Ostatní Backing beany Rekurzivní konstrukce hierarchické tabulky uºivatel Prezenta ní vrstva Bezpe nost pomocí autoriza ního ltru Lokalizace Testování pouºitelnosti (Usability test) Cíl testování Výb r uºivatel - testujících P edpoklady a poºadavky P edtestový dotazník Kone ný výb r xiii

12 6.3 Usability test Nastavení testu (setup) Úkoly Výsledky testu Problémy, e²ení a potestový dotazník Ostatní problémy Zhodnocení Záv r 77 8 Literatura 79 A Seznam pouºitých zkratek 81 B Seznam pojm 83 C Instala ní p íru ka pro OS Windows XP 85 C.1 Instalace prost edí Java SE Runtime Environment (JRE) 6 Update 11 (leden 2009) 85 C.2 Instalace kontejneru Apache Tomcat (leden 2009) C.3 Instalace databáze MySQL (leden 2009) C.4 Vytvo ení databáze s tabulkami C.5 Nahrání aplikace do kontejneru C.6 Spu²t ní aplikace D Uºivatelská p íru ka 87 D.1 P ihlá²ení uºivatele D.2 Navigace v aplikaci - hlavi ka aplikace D.3 Odhlá²ení uºivatele D.4 Role uºivatel D.5 Seznamy a detaily ºádostí D.5.1 Filtrování seznam ºádostí podle kritérií D.6 Seznamy a detaily uºivatel D.7 Role zam stnanec D.8 Role manaºer D.9 Role nám stek pro lidské zdroje D.10 Role referent D.10.1 Správa hierarchie uºivatel D.11 Role administrátor D.11.1 Správa formulá D.11.2 Syntaxe formulá e (XML Schema) D.11.3 Tvorba formulá e D.11.4 P íklad formulá e D.11.5 Jazyk formulá e D.11.6 Nahrání formulá e D.11.7 Pokro ilá správa formulá E Testové dotazníky 99 E.1 P edtestový dotazník E.2 Úkoly E.3 Potestový dotazník F Obsah p iloºeného CD 101 xiv

13 Seznam obrázk 2.1 MVC model 2 v prost edí JSP a Servlet, vyp j eno z [7] Strom komponent. Komponenty jsou zobrazeny do výsledného HTML pohledu Porovnání fyzického rela ního a doménového objektového modelu Schéma schvalování personální ºádosti v podniku Stavový diagram ºádosti Akté i Správa ºádostí. Referent a N-RLZ je zárove zam stnancem nebo manaºerem Sekven ní diagram pro UCZ01 Prohlíºet seznam ºádostí pod ízených uºivatel Návrh uºivatelského rozhraní - v horní ásti hlavi ka aplikace, v dolní ásti Seznam ºádostí pod ízených UCZ Sekven ní diagram pro UCZ05 Prohlíºet detail ºádosti Návrh uºivatelského rozhraní - Detail ºádosti UCZ05 a zakomponování formulá e v ºádosti Sekven ní diagram pro UCZ07 Zobrazit volby Sekven ní diagram pro UCZ08 Zvolit a vyplnit ºádost Návrh uºivatelského rozhraní - Nová ºádost UCZ Sekven ní diagram pro UCZ09 Vytvo it ºádost Sekven ní diagram pro UCZ10 Podat ºádost Sekven ní diagram pro UCZ11 Zru²it ºádost Sekven ní diagram pro UCZ12 Schválit ºádost Správa uºivatel. Referent a N-RLZ je zárove zam stnancem nebo manaºerem Sekven ní diagram pro UCU01 P ihlásit Návrh uºivatelského rozhraní - UCU03 Seznam nad ízených a pod ízených uºivatel uºivatele Jelínka Návrh uºivatelského rozhraní - Detail uºivatele UCU Sekven ní diagram pro UCU11 Vloºit uºivatele Návrh uºivatelského rozhraní - Vloºit nového uºivatele UCU Návrh uºivatelského rozhraní - UCU14 Smazat uºivatele, pokud je uºivatel manaºerem, je pot eba zvolit jednu z moºností Správa formulá Návrh uºivatelského rozhraní - vkládání formulá UCF03 a seznam formulá UCF Konceptuální model Aplikace zaloºená na vrstvách Fyzický model dat Business vrstva (doménový model) a integra ní vrstva. Plná ²ipka zna í pouze jak íst vztah pro lep²í orientaci v diagramu. ipka u asociace zna í pr chodnost (navigability), tedy ºe t ída typu A je sou ástí t ídy typu B jako atribut A : a, neboli t ída typu A neví nic o t íd typu B Datová struktura strom s atributy left a right. Pravá ást: vloºení nového listu Metoda transfersubtree p esune list nebo celý podstrom pod nový uzel Hierarchická tabulka bez css úprav Stejná hierarchická tabulka jako na obr. 5.6, ale s jednoduchými css úpravami D.1 Úvodní stránka aplikace s p ihla²ovacím formulá em D.2 Hlavi ka aplikace spolu s volbami xv

14 D.3 P íklad seznamu ºádostí spolu s ltrováním a stránkováním seznamu D.4 P íklad detailu ºádosti D.5 P íklad seznamu uºivatel spolu s hierarchickým seznamem uºivatel D.6 P íklad detailu uºivatele D.7 Volby pro odstran ní manaºera z hierarchie uºivatel D.8 Uºivatelské rozhraní formulá e podle zdrojového kódu z kap. D F.1 Adresá ová struktura prezenta ní vrstvy v adresá i /src/jsps. Uºivatel m ºe p istoupit pouze ke stránkám, které jsou v adresá ích, do kterých má p ístup podle p i azených rolí. Za p ístup odpovídá autoriza ní ltr popsaný v kap na str xvi

15 Seznam tabulek 3.1 Analýza rizik Slovník pojm Matice pokrytí funk ních poºadavk Tabulka ºádostí a jejich zam stnanc Výb r testujících na základ p edtestového dotazníku, viz p íloha E Setup testu F.1 Obsah p iloºeného CD xvii

16 xviii

17 KAPITOLA 1. ÚVOD 1 1 Úvod I p es vysoké uºívání informa ních technologií se neustále v mnohých rmách vyskytují oblasti, kde se postupuje jako p ed p l stoletím. Nemocnice v ƒeské Líp je moderní pracovi²t, kde se pouºívá mnoho vysp lých informa ních systém. V t²ina zam stnanc v tomto za ízení pracuje s po íta em a internetem. P esto i dnes, pokud chce zam stnanec nap íklad zvý²it plat svému pod ízenému, musí vzít tuºku, vyplnit p íslu²nou ºádost, kterou si bu vytiskne nebo získá od vedení a nakonec tuto ºádost odevzdat ke schválení svému nad ízenému. Tato innost nejenºe zabírá drahocenný as v²ech zam stnanc v etn doktor, ale je také velmi neexibilní. Nemocnice má n kolik set zam stnanc. Odd lení pro rozvoj lidských zdroj, které má na starosti personální otázky, se potýká s astým chybným vypln ním formulá. Není výjimkou, ºe od podání ºádosti k jejímu zaevidování uplyne n kolik dn. M ºe se stát, ºe se ºádost v hromadách papír ztratí a následuje koloto telefonát a dal²í asová ztráta. Cílem aplikace je automatizovat podávání a schvalování personálních zm n. Je pot eba vytvo it jednoduchou, ale schopnou aplikaci, která pln nahradí manuální podávání ºádostí. Automatizace vy e²í v t²inu problém. Schvalování ºádosti se zpracovává pomocí stavového diagramu, to zamezí jakýmkoli spekulacím a nejasnostem. Filtrování a azení seznam ºádostí zvy²uje p ehlednost. Uºivatel má moºnost prohlíºet detaily a kdykoli kontrolovat stav svých ºádostí a ºádostí pod ízených. A pokud se d je n co neobvyklého nebo se ned je nic, m ºe promptn zareagovat. Pro odd lení lidských zdroj aplikace nabízí celou sadu uºite ných nástroj. Je to vedle správy a evidence v²ech ºádostí také nemén d leºitý p ehled vztah zam stnanc ve rm a s tím spojená manipulace v zam stnanecké hierarchii. T etím d leºitým bodem je moºnost vytvá et a p idávat do systému nové formulá e pro ºádosti. Diplomová práce popisuje vývoj aplikace. Po této úvodní kapitole následuje druhá kapitola popisující technologii Java EE pouºitou v aplikaci. Dále jsou zde detailn ji rozebrány dva frameworky na nichº celá aplikace b ºí. Prvním je MVC framework JavaServer Faces, který slouºí pro funkcionalitu a vzhled, druhým pak ORM framework Hibernate pro persistenci dat mezi databází a aplikací. Nakonec je popsána technologie XML pouºitá pro tvorbu nových formulá. T etí kapitola Úvodní studie popisuje zadání zákazníka. Vedle aktér a odborného lánku jsou nejd leºit j²í ástí tzv. funk ní poºadavky. Tedy to, co má systém poskytovat. Dále jsou zde rozebrána rizika, která mohou p i vývoji nastat a jejich moºná e²ení. Nakonec je sepsán slovník pojm, který slouºí jako spojka mezi po íta ovým sv tem programátora a normálním sv tem zákazníka. Analýza a návrh jsou p edm tem tvrté kapitoly. Je postupováno podle metodiky UP a pro vizualizaci vývoje je pouºit jazyk UML. V této kapitole jsou popsáni akté i a vztahy mezi nimi. St ºejní ástí je popis a modelování p ípad uºití. Pokud je n který p ípad uºití sloºit j²í, je u n j uveden sekven ní diagram. Pro lep²í pochopení je n kdy je²t p idán návrh uºivatelského rozhraní. Na konci kapitoly je zaveden konceptuální model systému. Pátá kapitola, která pojednává o implementaci, je rozd lena do podkapitol podle jednotlivých implementa ních vrstev. Vrstvy jsou na sob nezávislé, to znamená, ºe jakoukoli z nich je moºné vyvíjet samostatn. V kaºdé podkapitole jsou popsány nestandardní ásti e²ení. Za zmínku stojí nap íklad algoritmy na modikaci hierarchie uºivatel v rela ní databázi (viz kapitola ). Jedním z indikátor úsp ²nosti e²ení problému je test pouºitelnosti. Ten je uveden v kapitole ²esté. Výsledná aplikace byla testována na relevantním vzorku uºivatel, kte í by mohli aplikaci pouºívat. V kapitole jsou uvedeny testové úkoly, výb r testujících, rozebrány výsledky testování

18 2 KAPITOLA 1. ÚVOD spolu s popisem a moºným e²ením problém. Nedílnou sou ástí implementa ní práce je uºivatelská p íru ka, která je v p íloze. Nakonec, jako dal²í p íloha, je p ipojen slovník pojm, kde jsou vysv tleny nejd leºit j²í termíny ze zna n rozsáhlého sv ta Java EE. Tento slovník pomohl m a m ºe být dobrým pomocníkem i tená i k pochopení javovské problematiky.

19 KAPITOLA 2. POUšITÉ TECHNOLOGIE 3 2 Pouºité technologie 2.1 Technologie pro návrh a analýzu UML a Visual Paradigm for UML 6.3 Jazyk UML (Unied Modeling Language) je univerzální jazyk pro vizuální modelování systém. Nej ast ji se pouºívá pro modelování objektov orientovaných informa ních systém, není to v²ak podmínkou. Jazyk se snaºí spojit existující postupy modelovacích technik a softwarové inºenýrství a je navrºen tak, aby jej mohly implementovat v²echny nástroje CASE (computeraided software engineering). V sou asnosti je jazyk UML ve verzi 2 1. Jazyk UML nenabízí ºádný druh metodiky, tedy ne íká, jak postupovat. UML pouze poskytuje syntaxi nebo spí²e mnoºinu technik grackých notací, jako nap. sekven ní diagramy, diagramy aktivit, komunika ní nebo stavové diagramy. Metodikou je aº Unied Process. Jedním z kvalitních UML CASE nástroj je Visual Paradigm for UML. Jeho výhodou je, ºe je poskytován pro ƒvut FEL ve ²kolní licenci Unied Process Metodika Unied Process (UP) popisuje postup, jak vytvá et softwarové systémy. Ur uje, jaké innosti je pot eba vykonat a jaké produkty vyrobit, aby vznikl model funk ního systému. Jinak e eno, metodika popisuje zp sob, jak p evézt zákazníkovy poºadavky na software. Modelovací jazyk UML je dobrým nástrojem pro tuto abstraktní tvorbu. Metodika je zaloºena na postupném vývoji systému, probíhá v cyklech (iterativní) a je p ír stková (inkrementa ní) a systém tvo í po dávkách. Umoº uje tedy p idávat do systému nové v ci nebo v ci m nit, aniº by se muselo za ít znovu. Pracovní postupy iterace jsou poºadavky, analýza, návrh, implementace a testování. Kaºdá iterace pak obsahuje fáze zahájení, rozpracování, konstrukce a zavedení. Celá problematika je popsána v [1]. 2.2 Java Enterprise Edition Platforma Java a JDK Programovací jazyk Java od rmy Sun Microsystems je objektov orientovaný a platformov nezávislý jazyk. Syntaxe vychází z jazyka C. Celá platforma Java obsahuje mj. samotný programovací jazyk (pro rozli²ení nazýván Java Standard Edition) a nadstavbu pro vývoj podnikových aplikací a informa ních systém (Java Enterprise Edition). JDK (Java Development Kit) je soubor základních nástroj pro vývoj aplikací pro platformu Java. JDK je ²í eno pod licencí GPL, tedy jako open-source. Mezi hlavní sou ásti pat í prost edí pro vývoj aplikací, jejich spou²t ní (kompilátor), testování (debugger), tvorba dokumentace (javadoc) a vytvá ení archiv. Platformu Java jsem zvolil, protoºe: jiº mám s Javou ur itou zku²enost, je to programovací (ne skriptovací) jazyk vhodný pro rozsáhlé podnikové (enterprise) aplikace, po mnoho let jiº vysp lý a rychlý jazyk, má ²irokou základnu vývojá, existuje nevy erpatelné mnoºství literatury, je voln k pouºití a v t²ina knihoven a dal²ích aplikací t etích stran také. 1 Specikace jazyka UML verze 2:

20 4 KAPITOLA 2. POUšITÉ TECHNOLOGIE Java EE Java EE (Enterprise Edition) je vlastn nadstavbou Java Standard Edition. Tato platforma je ur ena pro vývoj a provoz podnikových aplikací a informa ních systém. Její sou ástí jsou p edev²ím specikace pro vývoj sdílené business logiky (EJB, Spring) a pro vývoj webových aplikací (servlety, JSP, framework JSF,... ) Servlety a JSP První javovskou technologií pro tvorbu dynamického obsahu byly tzv. servlety, javovské t ídy, které p ijímaly poºadavky klienta a nazp t mu posílaly vygenerovaný HTML kód. Dal²ím krokem se staly JavaServer Pages (JSP). Hlavní rozdíl od servlet je v tom, ºe JSP se pí²e podobn jako PHP, tedy do HTML stránky JSP p íkazy. To mohou být jak segmenty Java kódu, tak speciální tagy knihovny JSTL. Výhodou JSP je, ºe prochází pouze jednou validací a proto není tak náro né na hardware. Vºdy se v²ak p evedou na servlety Apache Tomcat Kontejner Apache Tomcat od Apache Software Foundation je jedním z nejroz²í en j²ích aplika ních server pro Java EE, ur ený pro b h webových aplikací (JSP, servlety). Je poskytován jako open source. Jedná se vlastn o http server, který je schopen spou²t t Java kód IDE NetBeans Vyuºití vývojového prost edí (IDE) NetBeans rmy Sun Microsystems podléhá licenci CDDL, tedy open source licenci a je moºné jej bezplatn pouºít pro komer ní i nekomer ní prost edí. Mezi hlavní p ednosti pat í vysp lá podpora vývoje webových aplikací s integrovanou podporou JSP a JSF a jejich lad ní. Dále obsahuje kontejnery Apache Tomcat a GlassFish (spolu s databází). Sou ástí jsou také web services, konektory na databáze, EBJ. 2.3 MVC Webové Java frameworky Dynamicky generovaný obsah na stran serveru podle poºadavku klienta se za al roz²i ovat v polovin devadesátých let. Jednou z prvních technologií byla technologie CGI. Jak se v²ak webové aplikace stávaly v t²í, komplexn j²í a reprezentativn j²í, nastal nový problém, a to vysoká náro nost jak tvorby, tak úpravy takových aplikací. Webové aplikace se vyzna ují vysokým provázáním prezenta ní a aplika ní logiky. Dal²í vývoj tedy sm oval k odd lení t chto oblastí. Postup, jak toho docílit, je n kolik. Zpo átku to fungovalo tak, ºe gracký tým p edal hotové HTML s grakou programátor m a ti dotvo ili funkcionalitu dynamického obsahu. Problém nastal, pokud bylo pot eba n co p ed lat. Postupn si týmy vytvo ily ²ablony a návrhové vzory, které byly v jednotlivých spole nostech pouºívány Návrhové vzory Za vzor lze povaºovat znovupouºitelný obecný návod k e²ení problému, který se asto opakuje. Vzor je abstraktní, tzn. nepopisuje konkrétní e²ení situace, ale zobec uje v²echny obdobné situace. My²lenka návrhových vzor spolu s technoligií JSP (nebo podobných tagových jazyk ) vedly ke vzniku webových Java framework.

21 KAPITOLA 2. POUšITÉ TECHNOLOGIE Model-View-Controller Návrhový vzor, který odd luje prezenta ní a aplika ní logiky, se nazývá Model-View-Controller (MVC). MVC d lí aplikaci na t i ásti a denuje vztahy mezi nimi. Model uchovává informace, je zodpov dný za data a pravidla v systému. Koordinuje aplika ní logiku, p ístup k dat m a dal²í nevizuální ásti aplikace. View zobrazuje obsah Modelu. Specikuje, jak reprezentovat data poskytovaná Modelem. Controller je mostem mezi Modelem a View. Má dv funkce, získává data z Modelu a poskytuje je View k zobrazení a zp tn p edává uºivatelem zadaná data p es View do Modelu. Obrázek 2.1: MVC model 2 v prost edí JSP a Servlet, vyp j eno z [7] Model 1 První implementace MVC u webových aplikací se nazývá Model 1. V Jav jsou Modelem tzv. Java Beans, jednoduché objekty, které obsahují v t²inou getter a setter metody pro získávání a ukládání dat. Uºivatelské rozhraní View je tvo eno pomocí JSP. Zadávání údaj probíhá p es formulá e. Akce jsou p edávány ur itým JSP jako HTTP poºadavky. Controller je také JSP ve form scriplet (bloky zdrojového kódu Javy vloºené do JSP). Zpracuje poºadavek a vrací odpov ve form JSP. Jak View tak Controller musí pouºívat stejná JSP, která musí být p eloºena ve stejný as. To ale odporuje ideji o odtrºení aplika ní a reprezenta ní logiky Model 2 e²ením se stal tzv. Model 2, jehoº interpretace je následující: Model je shodn reprezentován Java Beany. View pomocí JSP. Funkci Controlleru p evezmou servlety, které jsou ur eny k vykonávání javovského kódu. Funk nost Modelu 2 je následující: Klient p es sv j internetový prohlíºe p edá HTTP poºadavek servletu (Controller). Servlet zavolá aplika ní logiku, ze které získá Model a ten zaregistruje do scope viditelného z JSP nap. request attribute. Následn provede p esm rování na JSP, které si ze scope vyzvedne Model (data) a ten zobrazí pomocí HTTP odpov di (HTML). Oproti Modelu 1 se JSP nikterak nezabývá aplika ní logikou, funguje jako View a zaobírá se pouze prezenta ní logikou. Viz obr Rozd lení webových Java framework Framework znamená v p ekladu aplika ní rámec. Podle Wikipedia.cs jej lze denovat takto: Framework je softwarová struktura, která slouºí jako podpora p i vývoji a organizaci jiných

22 6 KAPITOLA 2. POUšITÉ TECHNOLOGIE softwarových projekt. M ºe obsahovat podp rné programy, knihovny nebo sadu doporu ení ov ených postup a návrhových vzor.... Cílem frameworku je p evzetí pro danou oblast typických problém a tím usnadn ní vývoje tak, aby se návrhá i a vývojá i mohli zam it pouze na problematiku dané aplika ní domény. 2 Framework vychází z návrhových vzor a v t²inou jich n kolik implementuje. Podle zdroje [7] lze frameworky rozd lit podle návrhových vzor na Front Controller a Dispatcher view. Oba typy vycházejí z MVC Modelu 2. Ve Front Controller se aplika ní logika volá p ed p edáním zpracování do View. P íkladem jsou frameworky Struts, Struts2 nebo Spring MVC. V p ípad Dispatcher view volání aplika ní logiky probíhá zprost edkovan uvnit View. P íklady takových framework jsou v²echny implementace standardu JSF a jeho nadstaveb jako Shale i Seam. Dále lze frameworky rozd lit na poºadavkem ízené (Action-Based) a komponentov orientované (Component-Based). Rozdíl je v tom, ºe komponentov orientované nabízejí vy²²í míru abstrakce a to v oblasti tvorby komponent uºivatelského rozhraní a modelu událostí. Lze si je p edstavit jako kombinaci poºadavkem ízených framework a Swingu (b ºné prost edí pro vytvá ení uºivatelského rozhraní). Jako u poºadavkem ízených, komponentov orientovaný framework zaji² uje ízení ºivotního cyklu aplikací pomocí kontrolního servletu, a jako u Swingu poskytuje bohatý komponentní model, sadu standardních poloºek uºivatelského rozhraní (r zné typy tla ítek, textové pole, za²krtávací poloºky) a model pro vytvá ení vlastních prvk UI, spolu s ízením událostí. Tvorba webové aplikace pomocí t chto framework se podobá tvorb klasické GUI aplikace. P íkladem jsou robustní frameworky Tapestry a JSF. Poºadavkem ízené frameworky jsou nap íklad Struts, WebWork, Struts2. Mezi nejúsp ²n j²í voln pouºitelné Java frameworky lze za adit Struts, WebWork, Tapestry, Java Server Faces a Struts2. Kaºdý má své p ednosti a je ur en na jinou t ídu aplikací, v souhrnu v²ak lze íci, ºe vykonávají svou práci obdobn. Na frameworky lze pohlíºet ze dvou rozdílných úhl. Za prvé podle etnosti pouºívání a tedy velikosti komunity, podpory frameworku a dostupných materiál, jako je literatura a za druhé podle jejich technologických p edností, jako je rychlost, sloºitost, robustnost, bezpe nost, dodrºování standard. 2.4 MVC framework JavaServer Fages Framework JavaServer Faces (JSF) je vyvinutý rmou Sun a je dodáván standardn s platformou Java EE. Od ostatních Model 2 MVC Java web framework se odli²uje zejména v pouºití komponent a událostí, které tyto komponenty vyvolávají. Aktuální verze frameworku JSF je 1.2 (leden 2009). Komponenty jsou Java Beans s vlastnostmi, metodami s událostmi. Jsou organizovány do výsledného pohledu, který je tvo en stromem t chto komponent, které se zobrazí do výsledné stránky. Viz obrázek 2.2. Druhým d leºitým termínem jsou tzv. Backing beans. To jsou specializované Java Beans objekty, které mají za úkol sbírat a poskytovat data komponentám. Dále implementují metody - poslucha e a ak ní metody, které se spustí, vydá-li p íslu²ná komponenta událost. Backing beany mohou také spravovat odkazy na komponenty (tzv. binding). Vedle komponent a Backing beans se v JSF setkáváme s renderery (p eklada e mezi klientským a serverovým sv tem), s validátory (kontrolující hodnoty vloºené uºivatelem), s konvertory (transformující r zné typy dat na znakové et zce a obrácen ) a s událostmi a poslucha i 2

23 KAPITOLA 2. POUšITÉ TECHNOLOGIE 7 Obrázek 2.2: Strom komponent. Komponenty jsou zobrazeny do výsledného HTML pohledu. událostí. Popí²eme-li framework pomocí modelu 2, tak Model neboli aplika ní logiku tvo í Backing beans a View neboli prezenta ní logika se ídí knihovnou tag (Tag Library Description - TLD). Sun specikoval základní knihovnu tag, dále existuje plno jiných knihoven, které se ne ídí p esnou specikací. Jejich spole né pouºití ve View je moºné pomocí rozdílných p edpon tag. Jednou z takových knihoven je Apache MyFaces Tomahawk (viz dal²í kapitola, 2.4.2). Dal²í charakteristické rysy JSF v bodech: kongurace JSF se provádí pomocí XML soubor, p echod z jednoho pohledu na druhý se ídí jednoduchým systémem navigace, denicí naviga ních pravidel (trochu p ekvapivé je, ºe pravidlo p estupu na následující pohled - tag to-view-id - nelze generovat dynamicky), Managed beans, speciální Backing beany, které jsou nastaveny v kongura ním souboru a m ºe k nim p istupovat prezenta ní vrstva, jazyk EL (Unied Expression Language) odvozený od jazyku JSTL pro vkládání výraz a manipulaci s Managed beans v prezenta ní logice, jednoduchá lokalizace pomocí soubor vlastností (.properties), tvorba nových komponent. Pro vyvíjenou aplikaci jsem zvolil tento framework, protoºe: je standardn dodáván s Java EE, má ²irokou vývojá skou podporu, která se neustále velmi rychle rozr stá 3, existuje mnoho literatury, tutoriál, má kvalitní dokumentaci, s IDE NetBeans lze JSF jednodu²e ladit (debugovat) P íklad Funkci frameworku JSF p edvedeme na p íkladu p ihlá²ení uºivatele. P íklad je upraveným fragmentem z vyvíjené aplikace. Nejd íve uvedeme JSP soubor se vstupním formulá em. Pojmenujeme ho login.jsp: 3 JSF fórum Web Tier APIs - JavaServer Faces:

24 8 KAPITOLA 2. POUšITÉ TECHNOLOGIE taglib prefix="f" uri=" %> taglib prefix="h" uri=" %> <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <title>prosím, p ihla²te se</title> </head> <body> <h1>prosím, p ihla²te se</h1> <f:view> <h:form> <p><h:messages globalonly="true"/></p> <p> Uºivatelské jméno: <h:inputtext value="#{userbean.name}" id="name" required="true"/> <h:message for="name" style="color: red;"/> </p> <p> Heslo: <h:inputsecret value="#{userbean.password}" id="password" size="30"/> <h:message for="password" style="color: red;"/> </p> <h:commandbutton value="potvrdit" action="#{userbean.login}"/> </h:form> </f:view> </body> </html> Na za átku nesmíme zapomenout denovat knihovny tag. Poté m ºeme pouºívat tagy s prexy pro konstruování komponent. Následuje klasický HTML kód, který bude v nezm n né form zobrazen v prohlíºe i. Tag f:view musí uzavírat v²echny ostatní JSF tagy. Tag h:form je kontejner pro ostatní komponenty a pouºije se pro odeslání informací zp t na server. Tag h:messages se pouºije pro v²echny zprávy, které nám chce aplikace sd lit. V tomto p ípad to m ºe být varování, ºe uºivatel zadal ²patné jméno nebo heslo. Tag h:inputtext je komponenta pro textový vstup. Vlastnost value obsahuje hodnotu #{userbean.name}, coº je výraz v jazyce EL a odkazuje na atribut name v Backing bean jménem userbean. Vlastnost value v tomto tagu je datového typu String, tedy textový et zec. Jinými slovy, po potvrzení formulá e se textový et zec vloºený do HTML input tagu uloºí do atributu name v beanu userbean. Vlastnost size="30" ur uje, ºe pole m ºe obsahovat nejvý²e 30 znak a vlastnost required="true" zna í, ºe pole je povinné. Pokud by nebyla jedna z t chto vlastností spln na, server o tom informuje uºivatele prost ednictvím tagu h:message, který je spojen s komponentou inputtext pomocí vlastností id a for. Zpráva, která by se zobrazila, je p eddenována systémem. Lze ji zm nit. Tag h:inputsecret má podobné vlastnosti jako tag h:inputtext, jen je zobrazovaný text skryt pomocí te ek. Tag h:commandbutton se v HTML zobrazí jako tla ítko. Pokud uºivatel stiskne tla ítko, komponenta po²le aplikaci událost. Hodnota vlastnosti action je #{userbean.login}, coº je op t EL výraz a odkazuje na speciální poslucha - metodu navigace jménem login() v Backing bean userbean. Událost tuto metodu spustí a její návratová hodnota se pouºije pro dal²í navigaci. Backing bean UserBean je následující: public class UserBean implements Serializable { private String name;

25 KAPITOLA 2. POUšITÉ TECHNOLOGIE 9 private String password; private Date rightnow; // Akce public String login() { if (password.equals("t@jnehesl0") { rightnow = new Date(); return "success"; } else { FacesContext.getCurrentInstance().addMessage(null, new FacesMessage( FacesMessage.SEVERITY_ERROR, "Neplatné jméno nebo heslo!", null)); return "failure"; } } // Gettery a settery public Date getrightnow() { return rightnow; } public void setrightnow(date rightnow) { this.rightnow = rightnow; } public String getname() { return name; } public void setname(string name) { this.name = name; } public String getpassword() { return password; } } public void setpassword(string password) { this.password = password; } Backing bean je speciální Java Bean, jak bylo zmín no vý²e. Tento obsahuje t i privátní atributy a jejich gettery a settery. Dále obsahuje metodu navigace login, která se spustí, kdyº uºivatel stiskne tla ítko, které na ni odkazuje. Po stisku tla ítka server nejd íve zkontroluje, zda jsou údaje validní (kontrola povinnosti pole, délky et zce, atd... ). Pokud ne, nahlásí chybu uºivateli v p ipravených komponentách h:message. Poté se na tou (aktualizují) privátní atributy podle hodnot ve vstupních polích formulá e. Následuje spu²t ní naviga ní metody, která s t mito atributy m ºe pracovat (nap íklad je uloºit do databáze). V na²em p ípad metoda zkontroluje, jestli vloºený et zec v poli Heslo je roven et zci t@jnehesl0. Pokud ano, nastaví se atribut rightnow na aktuální as a metoda vrátí textovou hodnotu success. Pokud se et zce nerovnají, provede se rutina na výpis chybové hlá²ky o ²patném jménu nebo heslu a vrátí se hodnota failure. Návratová hodnota metody ur uje dal²í navigaci. Je²t uve me výslednou JSP stránku secret.jsp: <%@ taglib prefix="f" uri=" %> <%@ taglib prefix="h" uri=" %> <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <title>vítejte na zabezpe ené stránce</title> </head> <body> <h1>vítejte na zabezpe ené stránce</h1> <f:view> Va²e jméno je: <h:outputtext value="#{userbean.name}"/> <br> P ihlásil jste se v: <h:outputtext value="#{userbean.rightnow}"> <f:convertdatetime pattern="eeee, H:mm, d.mmmm yyyy" /> </h:outputtext> </f:view> </body> </html>

26 10 KAPITOLA 2. POUšITÉ TECHNOLOGIE Tag h:outputtext zobrazí hodnotu atributu uvedeného ve vlastnosti value jako normální HTML text. V tomto p ípad tedy zobrazí hodnotu atributu name z Backing bean userbean. Zajímav j²í situace je u druhého tagu h:outputtext, který te hodnotu atributu rightnow z userbean. Ta je typu Date (datum) a m ºe na ní být aplikován konvertor convertdatetime, který zobrazí datum ve formátu uvedeném ve vlastnosti pattern. V tomto p ípad je to nap. Pond lí, 9:31, 5.prosinec Navigace a kongurace JSF se provádí v souboru faces-config.xml, který v na²em p ípad vypadá takto: <faces-config> <navigation-rule> <from-view-id>/login.jsp</from-view-id> <navigation-case> <from-action>#{userbean.login}</from-action> <from-outcome>success</from-outcome> <to-view-id>/secret.jsp</to-view-id> </navigation-case> <navigation-case> <from-action>#{userbean.login}</from-action> <from-outcome>failure</from-outcome> <to-view-id>/login.jsp</to-view-id> </navigation-case> </navigation-rule> <managed-bean> <managed-bean-name>userbean</managed-bean-name> <managed-bean-class>mypackage.userbean</managed-bean-class> <managed-bean-scope>request</managed-bean-scope> </managed-bean> </faces-config> Tag navigation-rule denuje pravidlo navigace ze stránky uvedené v tagu from-view-id, zde login.jsp. Tagy navigation-case uvád jí v²echny moºnosti, co se m ºe zobrazit po této stránce. Pokud naviga ní metoda login v Backing bean userbean vrátila hodnotu success, bude následující stránkou secret.jsp. Pokud hodnotu failure, tak znovu login.jsp. Managed bean je Backing bean, který je nastaven v kongura ním souboru a m ºe k n mu p istupovat prezenta ní vrstva, v tomto p ípad to je na²e UserBean t ída Knihovna Apache MyFaces Tomahawk Knihovna tag Apache MyFaces Tomahawk roz²i uje v t²inu standardních JSF tag a p idává n které nové [13]. V aplikaci je pouºita knihovna verze a je distribuována pod licencí Apache License, tedy je k dispozici zdarma. P íklady tag pouºité v aplikaci: inputdate - pro vstup datumu, který obsahuje i malý JavaScriptový kalendá, ten vyºaduje zapnutý JavaScript datatable - roz²i ující tag standardního datatablepro zobrazení tabulky, umoº uje mj. lep²í správu t íd ní tabulky jscookmenu - vykreslí JavaScriptové menu. Komponenta zaloºená na skv lém JSCook- Menu od Heng Yuana 4, vyºaduje zapnutý JavaScript inputfileupload - pro nahrání soubor na server, zobrazí okno, které umoºní vybrat uºivateli soubor 4 JSCookMenu homepage:

27 KAPITOLA 2. POUšITÉ TECHNOLOGIE ORM framework Hibernate Velkým problémem p i vývoji aplikací je persistence dat. Dv techniky, rela ní databáze a objektov orientované programovací jazyky, které se v podnikových aplikacích dnes pouºívají v drtivé v t²in, jsou dva sv ty, které nemají mnoho spole ného. A koli existují objektov orientované databáze, jejich masové roz²í ení zatím nenastalo a v oblasti databází vévodí po ád databáze rela ní. Ke slovu p icházejí tzv. ORM (Object-relational mapping) frameworky, tedy frameworky, které mapují objektov orientovaný model dat na tradi ní rela ní data. V Java sv t je z ejm nejroz²í en j²í ORM framework knihovna Hibernate od rmy Red Hat. Knihovna Hibernate je distribuována zdarma jako open source software pod licencí GNU Lesser General Public License (LGPL). V aplikaci je pouºita verze 3. Pro velký úsp ch frameworku vznikla i verze pro platformu.net. Vedle Hibernate je moºné je²t zmínit framework ibatis, který vývojá i umoº uje v t²í kontrolu pomocí SQL jazyka, nebo Java Persistence API (JPA), coº je standardní ORM a persistentní správa pro platformu Java EE 5. Hibernate m ºe být s JPA pln integrován. Základní rysy Hibernate: objektové postupy jako asociace, d di nost, polymorsmus, kompozice a kolekce, lazy získávání dat na úrovni tabulek i sloupc, kdy jsou data z databáze získány aº tehdy, kdyº toto pole bude poprvé vyºádáno, snadná denice mapování pomocí XML a automatická konverze datových typ db a Javy, pokro ilé cachování, pln objektov orientovaný dotazovací jazyk HQL, podpora uloºených procedur a nativního SQL, kurzor a trigger, criteria query API pro podporu pr nik /sjednocení a subselekt, pouºití jak v samostatných aplikacích, tak v aplikacích Java EE se servlety, automatický commit a rollback nad databází, podpora conversation scope rozsahu platnosti, který je del²í neº request scope, ale krat²í, neº session scope, pouºití v r zných wizardech. Volba padla na Hibernate, protoºe: snad v²ichni pouºívají Hibernate, proto jsem se ho cht l nau it, existuje dostatek literatury, tutoriál a kvalitní dokumentace P íklad Framework Hibernate pracuje následovn. P íklad je zjednodu²eným fragmentem z vyvíjené aplikace. Máme rela ní model dat skládající se z tabulek v rela ní databázi (levá ást obr. 2.3). Tabulka ºádosti vypadá nap íklad takto: CREATE TABLE zadosti ( id INTEGER NOT NULL AUTO_INCREMENT, id_zamestnanec INTEGER NOT NULL, data VARCHAR(200) NOT NULL, CONSTRAINT zadosti_pk PRIMARY KEY (id) );

28 12 KAPITOLA 2. POUšITÉ TECHNOLOGIE Obrázek 2.3: Porovnání fyzického rela ního a doménového objektového modelu. Dále vytvo íme objektový (doménový) model dat pomocí DTO objekt (Data Transfer Object), coº jsou Java Bean objekty s privátními atributy a s gettery a settery pro p ístup k t mto atribut m (pravá ást obrázku 2.3). DTO objekt šádost pro tabulku ºádosti má dva atributy id a data, které jsou standardními datovými typy (int a String). Dále v²ak má atribut zam stnanec, který je typu Uºivatel. Tedy objekt zam stnanec je instance t ídy Uºivatel, coº je zase DTO objekt. A nakonec má atribut schválení, který je polem-seznamem (Java util.list) instancí t ídy Schválení (op t DTO objekt) a obsahuje v²echna schválení ºádosti: public class Zadost implements Serializable { private Integer id; private Uzivatel zamestnanec; private List<Schvaleni> schvaleni = new ArrayList()<Schvaleni>; private String data; // gettery a settery public Integer getid() { return id; } public void setid(integer id) { this.id = id; } public List<Schvaleni> getschvaleni() { return schvaleni; } public void setschvaleni(list<schvaleni> schvaleni) { this.schvaleni = schvaleni; } public Uzivatel getzamestnanec() { return zamestnanec; } public void setzamestnanec(uzivatel zamestnanec) { this.zamestnanec = zamestnanec; } public String getdata() { return data; } } public void setdata(string data) { this.data = data; } Máme-li tyto dva modely, musíme je namapovat do sebe. Oba modely totiº popisují stejnou reálnou situaci, jsou ekvivalentní. Jeden je v²ak rela ní a druhý objektový. Mapovací soubor pro Hibernate má p íponu.hbm.xml a pro t ídu šádost v na²em p ípad vypadá takto. Soubor se jmenuje Zadost.hbm.xml: 1) <hibernate-mapping> 2) <class name="zadost" table="zadosti"> 3) <id column="id" name="id"> 4) <generator class="increment"/> 5) </id>

29 KAPITOLA 2. POUšITÉ TECHNOLOGIE 13 6) <many-to-one class="uzivatel" column="id_zamestnanec" name="zamestnanec"/> 7) <list cascade="all" name="schvaleni"> 8) <key column="id_zadost"/> 9) <one-to-many class="schvaleni"/> 10) </list> 11) <property column="data" name="data"/> 12) </class> 13)</hibernate-mapping> Druhý ádek zna í, ºe DTO objekt šádost se bude mapovat na tabulku ºádosti. Na t etím aº pátém ádku denujeme primární klí. Jeho název je stejný jak v tabulce tak v objektu. Tag generator ur uje, ºe Hibernate pouºije p i vkládání nové ºádosti do databáze následující nejvy²²í íslo ve sloupci id. ádek. 6 denuje atribut zam stnanec pomocí vztahu mezi tabulkou uºivatelé a sloupcem id_zam stnanec v tabulce ºádosti (tag many-to-one). Naopak na ádcích 7. aº 10. denujeme atribut schválení, který bude seznamem (util.list) v²ech schválení z tabulky schválení, které mají ve sloupci id_ºádost uvedenou na²i ºádost (tag one-to-many). Jedenáctý ádek denuje jednoduchou vlastnost namapování sloupce data na atribut data. Konverze mezi datovými typy VARCHAR a String je automatická. Podobn se vytvo í ostatní tabulky a DTO objekty systému a namapují se na sebe. Máme-li nakongurovány v²echny tabulky, v²echny DTO objekty i mapovací soubory, m ºeme s daty manipulovat velmi jednodu²e a elegantn. Nejd íve si je²t vytvo íme jeden DAO (Data Access Object) objekt pro na²e ºádosti. DAO objekt je prvkem integra ní vrstvy aplikace a umoº uje p ístup k dat m: public class ZadostDAO { private Session session; public ZadostDAO(Session session) { this.session = session; } // metoda na získání ºádosti podle ID, lep²í je pouºít metodu session.get(zadost.class, id) nebo // session.load(zadost.class, id), zde je uveden tento postup na ukázku jazyka HQL public Zadost getzadost(integer id) { // získání ºádosti pomocí jazyka HQL return ((Zadost) session.createquery("from Zadost where id like :id").setinteger("id", id).uniqueresult()); } } Instance t ídy šádostdao se p ipojí k aktivní session Hibernate, která je napojena na databázi a metoda getšádost nám umoºní z databáze získat ºádost podle jejího id. V tomto p ípad získáme ºádost HQL dotazem from Zadost where id like :id. Jeho syntaxe je velmi podobná jazyku SQL, ale je pln objektov orientovaný. Místo tabulek se uºívají p íslu²né DTO objekty a místo sloupc atributy. Následuje krátký p íklad s komentá i: ZadostDAO zadostdao = new ZadostDAO(session); // DAO obsahující metody pro práci se ºádostmi Zadost mojezadost = zadostdao.getzadost(43); // na tení ºádosti s id = 43 Schvaleni prvnischvaleni = new Schvaleni(); // vytvo ení nového schválení Uzivatel schvalovatel = new Uzivatel(); // nový uºivatel jménem "Jan Novák" schvalovatel.setjmeno("jan Novák"); prvnischvaleni.setschvalovatel(schvalovatel); // p idání uºivatele ke schválení prvnischvaleni.setstav(0); // nastavení stavu mojezadost.getschvaleni().add(prvnischvaleni); // p idání schválení k ºádosti, normální práce se seznamem Schvaleni druheschvaleni = new Schvaleni(); // druhé schválení

30 14 KAPITOLA 2. POUšITÉ TECHNOLOGIE Uzivatel dalsischvalovatel = new Uzivatel(); dalsischvalovatel.setjmeno("petr Marek"); druheschvaleni.setschvalovatel(dalsischvalovatel); druheschvaleni.setstav(1); mojezadost.getschvaleni().add(druheschvaleni); // p idání druhého schválení k ºádosti session.commit(); // potvrzení zm n, Hibernate nastaví správní ID a vytvo í v²echny p íslu²né SQL dotazy Komentá e jsou dostate né k pochopení kódu. Co v²ak stojí za zd razn ní, je p idání vytvo eného schválení prvnischvaleni k ºádosti ( ádek 8). Není to nic jiného, neº klasické p idání nového prvku do seznamu pomocí metody add(). Tedy jednoduchý objektový p ístup. Zbytek práce ud lá Hibernate. Aº se posledním p íkazem potvrdí v²echny zm ny, Hibernate automaticky vytvo í p íslu²né SQL p íkazy a aktualizuje databázi. P íkazy by vypadaly p ibliºn takto (otazníky zna í frameworkem vygenerované identikátory): SELECT * FROM zadosti WHERE id = 43; INSERT INTO uzivatele (id, jmeno) VALUES (?, 'Jan Novák'); INSERT INTO schvaleni (id, id_zadost, id_schvalovatel, stav) VALUES (?, 43,?, 0); INSERT INTO uzivatele (id, jmeno) VALUES (?, 'Petr Marek'); INSERT INTO schvaleni (id, id_zadost, id_schvalovatel, stav) VALUES (?, 43,?, 1); Druhý p íklad znázor uje tení z databáze: Zadost mojezadost = zadostdao.getzadost(43); // na tení ºádosti s id = 43 for (Schvaleni schvaleni : mojezadost.getschvaleni()) { // výpis jmen schvalovatel v²ech schválení ºádosti } System.out.println(schvaleni.getSchvalovatel().getJmeno()); Tomu odpovídající SQL dotazy mohou vypadat takto: SELECT * FROM zadosti WHERE id = 43; SELECT * FROM schvaleni WHERE id_zadost = 43; SELECT * FROM uzivatele WHERE id =?; SELECT * FROM uzivatele WHERE id =?; Pokud bychom m li v mapovacím souboru povoleno lazy na ítání dat, poslední dva SQL dotazy by se vykonaly aº ve chvíli, kdy to program pot ebuje, a to je výpis jména schvalovatel na ádku Rela ní databáze MySQL Rela ní databáze od rmy MySQL AB (nyní dce inná spole nost Sun Microsystems) je poskytována zdarma pod licencí GPL nebo v placené verzi pro výd le né ú ely pod licencí EULA. Jedná se o jednu z nejroz²í en j²ích databází a aº na malé výjimky dodrºuje standard ANSI- SQL. Server je nezávislý na platform. Mezi d leºité rysy pat í podpora trigger, procedur, kurzor, cachování SQL dotaz. Fulltextové indexování a vyhledávání podporuje zpracovatel tabulek typu MyISAM. Naopak pro velká úloºi²t dat, podporu cizích klí, inteligentní rollback se hodí spí²e zpracovatel tabulky InnoDB.

31 KAPITOLA 2. POUšITÉ TECHNOLOGIE 15 Vývoj aplikace byl provád n za podpory MySQL Server verze 5 se zpracovatelem tabulek InnoDB v kódování Unicode UTF-8. Nic v²ak nebrání tomu pouºít jinou verzi MySQL nebo dokonce úpln jiný SQL rela ní databázový stroj, který v²ak podporuje cizí klí e a poddotazy. Komunikace mezi databází a aplikací je výhradn v reºii knihovny Hibernate. Kongurace p ipojení je jednoduchá a provádí se v XML kongura ních souborech Hibernate. Hibernate podporuje v t²inu SQL databází XML technologie XML (Extensible Markup Language) je zna kovací jazyk, standardizován konsorciem W3C, který m ºe být pouºit pro velmi rozmanité ú ely. Pro svou jednoduchost se pouºívá pro kon- gurátory (lehce editovatelný), pro vým nu dat mezi aplikacemi, pro publikování dokument i pro samotné uloºení dat (XML databáze). Syntaxe je zaloºena na stromové struktu e párových tag (zna ek) - element. Celý XML dokument musí být uloºen v ko enovém elementu. Kaºdý element m ºe obsahovat dal²í elementy a také atributy nebo textové informace. Tvo í se tak hierarchická struktura. Na za átku dokumentu je umíst na hlavi ka udávající verzi a kódování. P íklad p ibliºn kopíruje postup tvorby ²ablony formulá e ve vyvíjené aplikaci: <?xml version="1.0" encoding="utf-8"?> <group title="p íplatek osobní"> <inputtext size="50"> <label>p vodní</label> </inputtext> <inputtext> <label>navrhovaný</label> </inputtext> </group> Element <group> je ko enovým elementem, má navíc atribut title. Následují dva elementy <inputtext>, které mají volitelný atribut size a povinný element <label>. Ten obsahuje textovou informaci. V programovacím jazyce Java jsou pro práci s XML dokumentem k dispozici rozhraní SAX (Simple API for XML) nebo model DOM (Document Object Model). Model DOM na ítá celý dokument do pam ti, kde je dokument udrºován jako hierarchicky uspo ádaná kolekce objekt. Naopak rozhraní SAX dokument pouze te, na druhou stranu ov²em sekven n. To se hodí pro rozsáhlé dokumenty Knihovna DOM4J V aplikaci je pouºita externí knihovna DOM4J verze od rmy MetaStu Ltd., jejíº ovládání je intuitivn j²í, neº standardní prost edky. Pracuje s XML Schema, XSLT i XPath a podporuje DOM i SAX. Její vyuºití je podmín no souhlasem s licencí BSD, tedy voln k vyuºití s uvedením autora XML Schema XML Schema nebo také XSD (XML Schema Denition) je pokro ilej²í alternativa DTD (Document Type Denition) na popis struktury XML dokumentu. XML Schema slouºí k denici 5 Seznam podporovaných databází:

32 16 KAPITOLA 2. POUšITÉ TECHNOLOGIE element a atribut, které se mohou vyskytnout v dokumentu. Popisuje hierarchický vztah mezi elementy, po adí a po et potomk v rodi ovském elementu. Dále, zda m ºe element obsahovat data, specikaci, jakého typu mohou být data, a výchozí a konstantní hodnoty t chto dat. Na rozdíl od DTD je XSD napsán v XML, podporuje jmenné prostory a datové typy. A to textové (string), datumové, íselné a ostatní jako boolean, bit, URI. Je moºné denovat vlastní datové typy. S datovými typy je propojena jejich validace, datové formáty a jednoduchý p evod na datové typy databází i mezi datovými typy samotnými. XML Schema obsahuje jednoduché a komplexní elementy a indikátory, které slouºí ke kontrole, jak budou tyto elementy pouºity. Existují adící indikátory, indikátory ur ující po et výskyt elementu, skupinové indikátory na denování mnoºin element nebo atribut. Facety slouºí k omezení p ípustných hodnot (nap. rozsah), mnoºin hodnot (povolené hodnoty) nebo skupin hodnot (nap. povolené znaky, íslice, slova, prázdné znaky, také délky textu nebo datový typ). Více informací v [5]. Funkci XSD p edvedeme na XML dokumentu uvedeném vý²e: <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" elementformdefault="qualified"> <xs:element name="group"> <xs:complextype> <xs:choice minoccurs="1" maxoccurs="6"> <xs:element ref="inputdate"/> <xs:element ref="inputtext"/> </xs:choice> <xs:attribute name="title" type="xs:string"/> </xs:complextype> </xs:element> <!-- konec ukázky, ukázka není celá --> </xs:schema> Ko enový element group je komplexním typem a m ºe obsahovat v libovolném po adí, nejmén v²ak jeden, nejvíce pak ²est element inputdate nebo inputtext. Dále m ºe obsahovat volitelný atribut title, který musí být typu string XSL - XSLT a XPath XSL (Extensible Stylesheet Language) je transforma ní jazyk, který popisuje, jak transformovat a zformátovat soubory obsahující data podle XML standardu. XSL vznikalo jako snaha o zlep²ení CSS, pozd ji bylo rozd leno do t í samostatných jazyk. Jazyky k transformaci dokument (XSLT) a k jejich formátování (XSL-FO) a pomocný jazyk XPath, který v²ak na²el uplatn ní i v jiných technologiích. Jednotlivé jazyky mohou být pouºity samostatn. Jazyk XPath (XML Path Language) slouºí k vyhledávání informací v XML dokumentech procházením element a atribut. Výrazy XPath jsou sou ástí mnoha XML technologií, jako je XSLT, Xquery, Xpointer nebo XForms. XPath pouºívá výrazy popisující cestu (path expressions) k procházení XML dokumentu, k vybírání uzl nebo mnoºin uzl. Cesta je dána posloupností p echod mezi jednotlivými mnoºinami uzl. Kaºdý p echod je od dal²ího odd len lomítkem a sám je charakterizován t emi sloºkami. Jsou to: osa (axis), test (node test) a predikát (predicate). Sm r pohybu ve stromové reprezentaci XML je dán specikací osy. XPath výrazy tedy p ipomínají výrazy pouºívané v tradi ním systému soubor.

33 KAPITOLA 2. POUšITÉ TECHNOLOGIE 17 Dále XPath vyuºívá kolem sta zabudovaných funkcí na práci s textovými, íselnými, logickými, i datumovými nebo asovými typy, také se pouºívají k manipulaci s uzly a sekvencemi. Do rodiny XSL pat í vedle jazyka XPath také jazyk XSLT (XSL Transformations). Je to jazyk pouºívaný k transformaci jednoho XML souboru na jiný ve formátu XML, HTML nebo na prostý text. S vyuºitím jazyka XSL-FO lze vytvo it i soubor ve formátu PDF nebo RTF. XSLT sám je napsán v XML. Jazyk zpracovává vstupní dokument jako strom a výsledkem je nový dokument. Podporuje cykly, rekurze, podmínky i prom nné. Jejich vyuºití je v²ak velmi omezené, nelze m nit jejich hodnoty. Je to dáno tím, ºe zpracování XML není sekven ní. V t²ina pot eb prom nných lze vy e²it pouºitím XPath. Standardní knihovny platformy Java XSL podporují. Podpora je dosta ující i ve webových prohlíºe ích. Problematika XSLT je detailn popsána v [4]. Na jednoduchém p íklad si ukáºeme jednu ²ablonu transforma ního souboru XSLT spolu s vyuºitím XPath (kurzívou vyzna ené výrazy): <xsl:template match="/ "> <table> <xsl:if test="string(@title) "> <tfoot> <tr><td colspan="2">{@title }</td></tr> </tfoot> </xsl:if> <tbody> <xsl:for-each select="/group/inputtext "> <tr> </tr> </tbody> </table> </xsl:template> <xsl:variable name="size"> <xsl:if test="string(@size )"> <xsl:value-of select="@size "/> </xsl:if> <xsl:if test="not(string(@size)) "> <xsl:value-of select="60"/> </xsl:if> </xsl:variable> <td><label for="id{position() }">{label/text() }</label></td> <td><input id="id{position() }" size="{$size }" type="text"></td> ablona je ozna ena XPath výrazem "/", coº znamená, ºe je pro ko enový element a spustí se jako první. Kurzívou vyzna ené jsou XPath výrazy. V²echny tagy, které mají prex xsl, jsou ídicí tagy pro XSLT procesor. V²echny ostatní tagy (v tomto p ípad standardní HTML tagy) budou p epsány do výsledného souboru. Výsledkem bude tabulka, která bude mít hlavi ku v p ípad, ºe ko enový element group obsahuje atribut title. Dále se vygeneruje tolik ádk, kolik je element inputtext v elementu group. V kaºdém cyklu si zavedeme prom nnou size, do které se na te hodnota atributu size elementu inputtext. Pokud atribut není p ítomný, do prom nné uloºíme výchozí hodnotu, v tomto p ípad íslo 60. Zde si m ºeme pov²imnout zvlá²tnosti XSLT, kde prom nná obklopuje podmínky. Pokud bychom vytvo ili prom nnou v podmínce, ta nebude viditelná dále.

34 18 KAPITOLA 2. POUšITÉ TECHNOLOGIE Nakonec se vygenerují dv bu ky na kaºdém ádku. V první bude tag label spolu s textem získaným z elementu label zdrojového dokumentu. V druhém bude vstupní textové pole, jehoº velikost jsme si uloºili do vý²e zavedené prom nné. Atributy id a for jsme vygenerovali spojením et zce id + pozice elementu inputtext v elementu group. 2.8 Technologie na klientské stran HTML HTML (HyperText Markup Language) je dominantní zna kovací jazyk pro webové stránky. A koli pat í do rodiny GML jazyk, která denuje jasná pravidla, pro vysokou benevolenci v prohlíºe ích m ºe dokument HTML obsahovat mnoho nesrovnalostí (²patné vno ení tag, vynechání uvozovek u atribut ), a p esto jej prohlíºe e zobrazí, asto i správn. A koli se konsorcium W3C snaºí prosadit nov j²í formát XHTML, který se drºí striktn pravidel XML (neumoº uje nap. napsat tag <br>, ale vºdy pouze <br/>), nevypadá, ºe by se blíºil konec HTML. Framework JSF v aplikaci generuje klasické HTML, ne XHTML CSS CSS (Cascading Style Sheets) neboli kaskádové styly je jazyk styl pro denování vlastností, jak se má zobrazit, zformátovat, i jinak upravit dokument napsaný ve zna kovacím jazyce (HTML, XML,... ). Styly umoº ují denovat vzhled jednoho elementu, skupiny element nebo v²ech element ur itého typu v dokumentu. Výhodou CSS (pokud mluvíme o samostatném CSS souboru) je, ºe styl je odd len od samotného dokumentu, v²echny styly jsou na jednom míst a jeden styl m ºe být pouºit pro více dokument. I v dne²ní dob je v²ak pot eba dát pozor na mén obvyklé styly kv li nekompatibilit s r znými webovými prohlíºe i JavaScript (ECMAScript) ECMAScript, ast ji nazývaný JavaScript, je objektov orientovaný skriptovací jazyk od spole nosti Netscape. Je nezávislý na platform a skripty zpracovává klientský prohlíºe. Nemá nic spole ného s programovacím jazykem Java. Je vhodným dopl kem v moderních webových aplikacích, kde p ebírá n kdy nemalé mnoºství práce od serveru a tím sniºuje jeho vytíºení. Pouºívá se nap íklad pro validaci vstupních dat i pro vyvolání akce jiným zp sobem, neº stisknutím tla ítka. Dokáºe pracovat s objektovým modelem dokumentu (DOM). Framework JSF podporuje JavaScript bez problém, plno roz²i ujících knihoven, v etn Apache MyFaces Tomahawk jej dokonce asto vyuºívá. Moºnou nevýhodou m ºe v²ak být to, kdyº je JavaScript v prohlíºe i zakázán. Je na komponentách, jestli jsou dob e navrºeny a poradí si i bez n j. Samotná specikace JSF RI ke svému b hu JavaScript v bec nepot ebuje. Za zmínku stojí, ºe pro framework JSF existují knihovny tag (nap. RichFaces 6 ), které ke svému b hu pouºívají i technologii Ajax, které jsou velmi efektní a v trendy aplikacích najdou ur it své místo. Jelikoº tato aplikace je pro vnit ní ú ely rmy, v této fázi není t eba, aby obsahovala takové technologie. 6

35 KAPITOLA 3. ÚVODNÍ STUDIE 19 3 Úvodní studie 3.1 Sou asný stav V sou asné dob se procedura jakékoli personální zm ny v nemocnici v ƒeské Líp provádí ru n. Pouze zdravotnický personál ítá n kolik set zam stnanc. Personální zm na (zm na platu, dovolená, p e azení,... ) tedy není ni ím vzácným. Struktura zam stnanc je více mén hierarchická a pokud chce dnes nap íklad vrchní zdravotní sestra své pod ízené zm nit pracovní pom r, musí nejd íve získat p íslu²ný formulá (vytisknout si ho nebo ho dostat u vedení), vyplnit ho a p edat svému nad ízenému ke schválení. Tento nad ízený, nap íklad primá d tského odd lení, se k ºádosti vyjád í (schválí/zamítne) a musí jí p edat op t svému nad ízenému, nám stku. Nám stek se op t vyjád í a p i kladné odpov di p edává ºádost nám stku pro rozvoj lidských zdroj (N-RLZ). Aº po jeho odsouhlasení se ºádost dostává k referentce, která ji zaeviduje a provede p íslu²né operace. Obrázek 3.1: Schéma schvalování personální ºádosti v podniku. 3.2 Deklarace zám ru Informa ní systém pro potvrzování personálních ºádostí bude webová aplikace primárn ur ena pro nemocnici v ƒeské Líp. M ºe v²ak být pouºita v jakémkoli podniku s hierarchickou strukturou zam stnanc. Aplikace má za úkol automatizovat potvrzování personálních zm n v²emi úrovn mi managementu. Aplikace bude ur ena pro management první a vy²²ích úrovní. Personální ºádost n jakého zam stnance bude zadávat jeho p ímý nad ízený a aby byla ºádost schválena, musí být potvrzena v²emi vy²²ími úrovn mi managementu. V p ípad nemocnice m ºe vypadat hierarchie potvrzujícího managementu pro sestru takto: v²eobecná sestra, stani ní sestra, vrchní sestra, primá odd lení, nám stek, nám stek pro lidské zdroje, referent/ka evidující kompletní ºádost. 3.3 Odborný lánek Cílem projektu je automatizovat innost podávání personálních ºádostí v nemocnici v ƒeské Líp. Je pot eba vytvo it takový systém, který bude co nejjednodu²²í a nejintuitivn j²í. Systém

36 20 KAPITOLA 3. ÚVODNÍ STUDIE by m l být primárn interní, p ístupný pouze v nemocnici. M l by vyuºívat hardwarovou výbavu sou asné po íta ové sít (databázový a po²tovní server). Není v²ak podmínkou, aby aplikace byla propojena s ostatními aplikacemi v nemocnici, jako je mzdový systém nebo ú etnictví, nebo aby byla propojena s jinými databázemi. Co je v²ak d leºité, je moºnost jednoduchou cestou p idávat do systému nové formulá e. Jedná se tedy o systém, který zbaví zam stnance manuálního podávání a schvalování personální ºádosti Hlavní funkce systému V²ichni uºivatelé systému se musí identikovat. Poté mají moºnost prohlíºet detaily personálních ºádostí i se schvalovacím et zcem a stavem, ve kterém se ºádost nachází, které se týkají jejich osoby. Je-li uºivatel navíc manaºerem, m ºe ºádosti zadávat, schvalovat a zamítat. Zadávat pro své p ímé pod ízené. Schvalovat a zamítat ºádosti podané svými pod ízenými manaºery. Dále m ºe ºádosti svých pod ízených prohlíºet a tisknout. Není-li ºádost je²t nikým schválena, pouze podána, lze ji stornovat. Dále si manaºer bude volit svého zástupce, který bude mít stejné pravomoci jako on v dob jeho nep ítomnosti. Ke v²em personálním ºádostem se v p edposledním kroku vyjád í (schválí/zamítne) nám stek pro rozvoj lidských zdroj (N-RLZ). Nakonec, po jeho kladném vyjád ení, zaeviduje ºádost referent zam stnance, kterého se ºádost týká. Referent bude moci prohlíºet v²echny ºádosti, které pat í pod n j a podle pot eby zaslat zprávu zainteresovaným uºivatel m. V²echny ºádosti v jakémkoli stavu m ºe vytisknout. Dále bude referent zadávat do systému nové uºivatele. Mezi uºivateli, mezi kterými je vztah nad ízený-pod ízený, systém umoº uje prohlíºení jejich detail a posílání zpráv. Systém umoº uje vkládání nových formulá, toto zaji² uje (v etn jejich vytvo ení a validace) administrátor nebo N-RLZ Názorný pr b h schvalování ºádosti Uºivatel, který chce podat personální ºádost pro svého p ímého pod ízeného, se p ihlásí do systému. Z nabídky vybere ºádost. Poté, co ºádost vyplní a podepí²e, systém ji uloºí a poznamená u ní, ºe eká na schválení nad ízeným uºivatele. Uºivatel v nad ízený bude em upozorn n, ºe ºádost eká na jeho vyjád ení (schválení / zamítnutí). Nad ízený se p ihlásí do aplikace, kde si otev e p íslu²nou ºádost a vyjád í se k ní. Toto vyjád ení se k ºádosti p iloºí a systém poºádá stejným zp sobem jeho nad ízeného o dal²í schválení. Je-li ºádost schválena v²emi nad ízenými a nám stkem pro rozvoj lidských zdroj, referent ji zaeviduje do systému a zadavatel ºádosti bude upozorn n. Je-li ºádost n kterým nad ízeným zamítnuta, bude na tuto skute nost zadavatel op t upozorn n.

37 KAPITOLA 3. ÚVODNÍ STUDIE Akté i Kaºdý uºivatel systému má p i azenou povinnou roli Zam stnanec. Dále m ºe vystupovat v jakýchkoli ostatních volitelných rolích. Nemusí mít ºádnou volitelnou roli nebo i v²echny. Zam stnanec (angl. Employee, povinná role) - V²ichni uºivatelé pracující se systémem mají p i azenou roli Zam stnanec. Tato role umoº uje pracovat s personálními ºádostmi uºivatele, spravovat prol uºivatele a komunikovat s uºivatelovými nad ízenými - Manaºery, s Referentem a s N-RLZ. Manaºer (angl. Manager, role p id lená systémem) - Uºivatel má roli manaºera, pokud má alespo jednoho pod ízeného. Manaºer má pod sebou pod ízené Zam stnance - uºivatele. Spravuje personální ºádosti svých pod ízených (vytvá í a podává je, schvaluje/zamítá je) a komunikuje se svými pod ízenými. N-RLZ (angl. MHR, volitelná role) - Nám stek spravující lidské zdroje je role, která uºivateli umoº uje pracovat se v²emi personálními ºádostmi, se v²emi uºivateli i formulá i. N-RLZ se musí vyjád it (schválit/zamítnout) ke v²em personálním ºádostem. Zárove mu jsou povoleny funkce Referenta i Administrátora. V systému m ºe být pouze jeden N-RLZ. Referent (angl. Ocer, volitelná role) - Tato role umoº uje uºivateli evidovat v²echny personální ºádosti týkající se Zam stnanc, jejichº je Referentem. Referent také vkládá nové Zam stnance - uºivatele do systému a p i azuje jim volitelné role a komunikuje s nimi. Admin (angl. Admin, volitelná role) - Administrátor, spravuje systém a tvo í formulá e. Zástupce manaºera (angl. Substitute, volitelná role) - Zvolí si ho Manaºer, má stejné pravomoci, jako Manaºer. Ve v²ech procesech, které vykoná zástupce, bude poznámka, ºe je vykonal on. 3.5 Funk ní poºadavky Poºadavky mají r znou prioritu realizace. Priority za len ní poºadavku v aplikaci jsou: M - nezbytné, S - moºné, C - eventuální a W - chceme mít v budoucnu. Poºadavky pro roli Zam stnanec: 1. (Zam stnanec bude) p ihla²ovat se do aplikace svými identika ními údaji, M 2. prohlíºet/tisknout detail ºádosti spolu se v²emi schváleními týkající se jeho osoby, C 3. prohlíºet/tisknout seznamy ºádostí týkající se jeho osoby, C 4. prohlíºet/tisknout detail svých nad ízených, C 5. prohlíºet/tisknout seznam svých nad ízených, C 6. posílat zprávu svému p ímému nad ízenému, svému referentovi a N-RLZ, mail, W 7. prohlíºet detail své osoby a m nit své heslo, M Poºadavky pro roli Manaºer: 8. (Manaºer bude) podávat jakoukoli ºádost pro svého jakéhokoli p ímého pod ízeného, M 9. upravovat/stornovat ºádost, dokud ºádost nepodá, C

38 22 KAPITOLA 3. ÚVODNÍ STUDIE 10. schvalovat/zamítat ºádost podanou jeho pod ízeným a bude se k ní moci vyjád it. M 11. p i podání/schválení volit, zda ºádá konzultaci s N-RLZ (nebo s referentem) nebo ne, S 12. prohlíºet/tisknout seznamy ºádostí svých pod ízených (ºádosti ním podaných/schválených/zamítnutých) podle r zných kritérií, M 13. prohlíºet/tisknout detail ºádosti spolu se v²emi schváleními svých pod ízených (ºádost ním podaná/schválená/zamítnutá), M 14. prohlíºet/tisknout seznam ºádostí svých pod ízených, ke kterým se je²t nevyjád il (které je²t neschválil/nezamítnul). M 15. prohlíºet/tisknout detail ºádosti jeho pod ízených, ke kterým se je²t nevyjád il (které je²t neschválil/nezamítnul). M 16. Podaná/schválená ºádost manaºerem bude poslána jeho nad ízenému manaºerovi ke schválení, (moºné upozorn ní mailem, W), M 17. Podaná ºádost a schválená ºádost manaºerem na nejvy²²í úrovni bude poslána N-RLZ, neboli v²echna schválení ºádostí jdou k N-RLZ p es nejvy²²ího manaºera, podání ºádosti nejvy²²ím Manaºerem není systémem e²eno, M 18. Zpráva o nov p íchozí ºádosti ke schválení (výzva ke schválení ºádosti) bude poslána schvalujícímu manaºerovi, , W 19. Zpráva o zamítnutí ºádosti bude poslána zadavateli (manaºerovi) a týkajícímu se zam stnanci, , W 20. šádost bude obsahovat údaje o týkajícím se zam stnanci, samotný formulá a seznam v²ech schválení, M 21. (Manaºer bude) prohlíºet/tisknout detail svých pod ízených, C 22. prohlíºet/tisknout seznam svých pod ízených, C 23. posílat zprávu svému pod ízenému, mail, W 24. volit v systému svého zástupce, C Poºadavky pro roli Zástupce manaºera: 25. Zástupce manaºera bude mít p i absenci manaºera stejné pravomoci (prohlíºet/tisknout, podávat, schvalovat/zamítat ºádosti, posílat zprávy), C Poºadavky pro roli N-RLZ: 26. Nám stek pro rozvoj lidských zdroj (N-RLZ) bude schvalovat/zamítat v²emi schválenou ºádost, M 27. Schválená ºádost od N-RLZ bude poslána referentovi zam stnance, kterého se ºádost týká, M 28. N-RLZ bude zadávat nového N-RLZ 29. N-RLZ bude mít v²echny pravomoci jako referent, M

39 KAPITOLA 3. ÚVODNÍ STUDIE N-RLZ bude mít v²echny pravomoci jako admin, M Poºadavky pro roli Referent: 31. (Referent bude) evidovat v²emi schválenou ºádost zam stnance, jehoº je referentem, M 32. prohlíºet/tisknout detail jakékoli ºádosti spolu se v²emi schváleními, M 33. prohlíºet/tisknout seznamy ºádostí podle r zných kritérií, M 34. Zpráva o zaevidování ºádosti bude poslána zadavateli - manaºerovi a týkajícímu se zam stnanci, , W 35. (Referent bude) zadávat nové zam stnance - uºivatele, zadá mj. jeho volitelné role a id nad ízeného, tím se vytvo í cesta ºádosti, M 36. prohlíºet/tisknout detail jakéhokoli zam stnance, M 37. prohlíºet/tisknout seznamy uºivatel podle r zných kritérií, M 38. upravovat prol zam stnance, jehoº je referentem, M 39. p emis ovat v hierarchii zam stnance, jehoº je referentem, M 40. mazat zam stnance, jehoº je referentem, M 41. posílat zprávu zam stnanci, jehoº je referentem, v p ípad pot eby, W Poºadavky pro roli Administrátor: 42. (Admin bude) p idávat/uploadovat nové (validní) formulá e, M 43. aktivovat/deaktivovat nebo mazat formulá e, M 44. prohlíºet seznamy a detaily formulá, M 3.6 Nefunk ní poºadavky Implementace - Java EE (servlety, JSP, MVC framework JSF), knihovna tag Apache My- Faces Tomahawk, ORM framework Hibernate, DOM4J (XML, XSD, XSL), MySQLConnector SW Klient - standardní webový prohlíºe, podpora JavaScriptu není podmínkou SW Server - Apache Tomcat, SMTP, MySQL Server Umíst ní - vlastní HW HW Klient - standardní kancelá ský osobní po íta s p ístupem na podnikovou sí s webovým prohlíºe em HW Server - CPU 2GHz a více, opera ní pam 2GB a více, pevný disk SCSI otá ek Kapacita uºivatel Dostupnost - nonstop, z remní sít Shoda se standardy - technologie v Java EE spl ují standardy zabezpe ení a standardy protokol Zabezpe ení - MD5 na zakódování hesel v databázi, rozd lení p ístupu do adresá podle rolí, pouºití autoriza ního ltru testující p ístup

40 24 KAPITOLA 3. ÚVODNÍ STUDIE 3.7 Analýza rizik Rizika technického, projektového a obchodního charakteru uvedené v tabulce 3.1 jsou azena podle pravd podobnosti násobené dopadem v p ípad, ºe riziko nastane. riziko kategorie pravd. [%] dopad (1-4) RMMM - plán zmírn ní, monitorování a ízení rizik Nedostatky ve znalosti projektové 60 2 dostate né studium technické dokumentace ORM frameworku Hibernate a kvalitních knih Nejasná p edstava obchodní 50 2 asté konzultace b hem celého vývoje zákazníka co vlastn chce, zm ny poºadavk Nedostatky v analýze, technické 30 3 striktn dodrºovat metodiku UP a nepochopení metodiky patný odhad velikosti, sloºitosti pouºívat UML obchodní 20 2 studovat algoritmy, p ed vlastními nápady dát p ednost osv d eným metodám patné zabezpe ení aplikace projektové 10 4 MD5 na hesla, rozd lení p ístupu do adresá podle rolí, pouºití autorizaprojektové ního ltru testující p ístup Chyby v implementaci projektové 15 2 testování budoucími uºivateli, e²itelem Sloºitost aplikace, nedostatky v dokumentaci, sloºitá dokumentace Knihovny t etích stran obsahují implementa ní chyby (bugy) Nezavedení aplikace v podniku (nap. p i zm n managementu) Ztráta/nezálohování dat p i vývoji Zm na technologie v implementaci (XForms) patný odhad zatíºení aplikace p i b hu, velikosti databáze obchodní 15 2 dokumentace obsahující p íklady a postupy, testováním odhalit sloºitosti, konzultace se zákazníkem technické 25 1 pouºití knihoven s dobrou dokumentací a s vysokou pouºívaností obchodní 25 1 management podniku o aplikaci poºádal technické 5 4 zálohování funk ních ástí aplikace na samostatné nosi e dat projektové 20 1 p ed zahájením implementace prostudovat detailn technologie, slepé uli ky odhalit co nejd íve testováním jak aplikace tak kandidát na technologie projektové 5 3 pouºita Java EE pro podnikové aplikace, optimalizace dotaz do databáze Tabulka 3.1: Analýza rizik 3.8 Slovník pojm V tabulce 3.2 jsou uvedeny pojmy pouºívané p i analýze a návrhu systému. P i komunikaci se zákazníkem je t eba se vyjad ovat jednozna n, aby se maximáln eliminovala v²echna nedorozum ní. Denice pojm komunikaci zjednodu²uje. U kaºdého pojmu je popsán jeho význam a jsou uvedena synonyma.

41 KAPITOLA 3. ÚVODNÍ STUDIE 25 pojem pouºitý v projektu admin aktér detail formulá id manaºer N-RLZ (nám stek pro rozvoj lidských zdroj ) podání referent role seznam ºádostí schválení schvalovací et zec InSypoPepo uºivatel vypln ní zaevidování zam stnanec zamítnutí zástupce zpráva ºádost význam Role správce informa ního systému. Tvo í a spravuje formulá e. Je vyjád ením role p id lené k p edm tu, který bezprost edn pouºívá daný systém. P edm ty jsou nap. lidé (uºivatelé), as, jiná za ízení. ºádosti Podrobný výpis jedné ºádosti. Obsahuje popis zam stnance, vypln ný formulá a aktuální schvalovací et zec. Je ²ablonou pro konstrukci formulá e v ºádosti. Formulá je tedy sou ástí ºádosti. Specikuje, o co se v ºádosti jedná. Jedine ný identikátor v rámci celého systému. Kaºdá v c v systému je identikována mnoºinou písmen a íslic. Role, která specikuje, ºe uºivatel je vedoucím zam stnancem v podniku. Role specikující nám stka pro rozvoj lidských zdroj, tedy toho, p es kterého jdou v²echny ºádosti týkající se personálních poºadavk. Akce, kdy je ºádost podána a potvrzena manaºerem. Tím se ºádost vytvo í a dostává se ve schvalovacím et zci dále a eká na schválení. Eviduje v²echny v²emi schválené ºádosti. Po zaevidováním m ºe za ít realizace ºádosti v podniku. Role ur uje, co hraje ur itý p edm t, který pouºívá daný systém (viz aktér). P edm t m ºe mít sou asn více rolí. Výpis v²ech ºádostí, které spl ují n jaké kritérium. Na rozdíl od detailu ºádosti, je v seznamu výpis ºádosti zjednodu²ený. Akce, kdy je ºádost schválena a potvrzena manaºerem. Kdyº je potvrzena, dostává se ºádost ve schvalovacím et zci dále. et zec uchovávající celý ºivot ºádosti, od jejího podání, p es v²echna schválení, aº po její zaevidování nebo zamítnutí. Obsahuje d leºité informace, jako kdo kdy ºádost schválil. Pracovní název této aplikace, Informa ní systém potvrzování personálních poºadavk. Souhrnný název pro lov ka, který pouºívá daný systém (viz aktér, role) Akce, kdy je ºádost správn vypln na. Není v²ak zatím podána k schvalovacímu procesu. Akce, kdy je ºádost zaevidována referentem. Je to poslední lánek schvalovacího et zce. Povinná role kaºdého uºivatele systému. Kaºdý uºivatel je zam stnancem. Akce, kdy je ºádost zamítnuta manaºerem. Schvalovací proces pro ºádost je zastaven. Role, která uºivateli p i kne práva na operace se ºádostmi, jako má manaºer. Zástupce si v systému ur í manaºer. Text, který je poslán jedním uºivatelem systému druhému uºivateli formou ové sluºby. Týká se konkrétní zam stnance. Podává ji vedoucí (nad ízený) zam stnance - manaºer. Obsahuje formulá a schvalovací et zec. synonyma administrátor aktor, actor ²ablona formulá e identika ní íslo, identikátor vedoucí, manager manaºer pro lidské zdroje podání ºádosti schválení ºádosti Personální IS nemocnice v ƒ. L. klient, pracovník vypln ní ºádosti evidování, zaevidování ºádosti zamítnutí ºádosti zástupce manaºera , poºadavek Tabulka 3.2: Slovník pojm

42 26 KAPITOLA 3. ÚVODNÍ STUDIE

43 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ 27 4 Analýza a návrh e²ení Analýza a návrh jsou provedeny metodikou UP a jsou dv ma z její iterací vývoje aplikace (vedle poºadavk - úvodní studie, implementace a testování). Kaºdá iterace, tedy i analýza a návrh, se buduje cyklicky, kdy se jednotlivé procesy získávání a úpravy informací opakovan zdokonalují, do té doby, neº se nalezne nejlep²í optimální e²ení. Z úvodní studie, p eváºn z funk ních poºadavk v kap. 3.5, se ve fázi analýzy snaºíme získat aktéry, p ípady uºití a konceptuální datový model. Ve fázi návrhu se realizují pomocí sekven ních diagram ty p ípady uºití, které nejsou z ejmé na první pohled. Pro lep²í p edstavu je dopln n u n kterých p ípad uºití náhled uºivatelského rozhraní. Postup vychází z publikací [1] a [9]. Jelikoº jde o systém, kde se m ní stavy n jaké entity (v tomto p ípad šádosti), je dále pot eba uvést stavový diagram. 4.1 Stavový diagram ºádostí šádosti se p i schvalování nacházejí v r zných stavech. Stavový diagram je uveden na obrázku 4.1. P echody mezi stavy jsou dány p esnými pravidly, kde kaºdý p echod obsahuje vstupní ást (název akce a podmínka) / výstupní ást (dal²í schvalovatel). Obrázek 4.1: Stavový diagram ºádosti. Kaºdá nová ºádost je ve stavu 0 - vypln no ( eká na podání). Pokud podávající manaºer ºádost nezru²í (zobrazený stav 102, který v²ak není pouºit, protoºe ºádost je vymazána z databáze) a podá ji, následuje stav 20, 21 nebo 22. Do stavu 20 se ºádost dostane, pokud má manaºer nad ízeného a ten zárove není N-RLZ, do stavu 21, pokud nemá nad ízeného (je nejvy²²í v hierarchii) nebo je jeho nad ízeným N-RLZ a do stavu 22, pokud podal ºádost N-RLZ pro svého pod ízeného.

44 28 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ Dokud má následující schvalovatel nad ízeného, dostává se ºádost ze stavu 20 do stavu 40 nebo cyklem ze stavu 40 do stavu 40. Pokud jiº je následující schvalovatel nejvy²²ím v hierarchii (nemá nad ízeného), putuje ºádost ze stavu 20 nebo 40 do stavu 41. šádosti ve stavech 21 a 41 jsou jiº p ed posledním schválením, musí je schválit N-RLZ. Poté se dostávají do stavu 42. šádosti ve stavech 22 a 42 ekají na poslední krok a to je zaevidování referentem zam stnance, kterého se ºádost týká (stav 100). V kaºdém stavu v t²ím nebo rovno 20 a men²ím neº 100 lze ºádost zamítnout (stav 101). 4.2 Akté i Systém bude rozli²ovat p t aktér podle kapitoly 3.4. Z obrázku 4.2 je patrné, ºe kaºdý uºivatel systému vystupuje jako aktér Zam stnanec. Pokud má pod ízené, získává navíc automaticky roli Manaºera. Manaºer m ºe delegovat jakéhokoli pod ízeného jako svého zástupce. Zástupce má stejné pravomoci jako manaºer, ale nem ºe prohlíºet seznam ºádostí manaºera, nem ºe m nit manaºerovo heslo a nem ºe volit manaºerova zástupce. Dále m ºe mít uºivatel kteroukoli p ídavnou roli Referent, Administrátor nebo N-RLZ. Nemusí mít ºádnou, ale m ºe mít i v²echny. N-RLZ je pánem systému, jako poslední schvaluje/zamítá v²echny ºádosti. Dále má stejné pravomoci, jako referenti (ale neeviduje ºádosti) a administrátor a m ºe m nit N-RLZ. Obrázek 4.2: Akté i. 4.3 P ípady uºití Pro v t²í p ehlednost je celý systém rozd len na n kolik subsystém - správ. P ípady uºití jsou realizovány pomocí sekven ních diagram. Sekven ní diagramy nejsou uvedeny u v²ech p ípad uºití. ƒasto se jejich struktura opakuje pro více p ípad uºití, proto jsou uvedeny pouze jednou a je u nich poznámka, pro které p ípady jsou analogické. Pro lep²í pochopení problému jsou k n kterým p ípad m uºití vloºeny návrhy uºivatelského rozhraní. Uºivatelská interakce se systémem (p ípady uºití) je psána esky. Samotné vnit ní funkce a entity pak anglicky, aby se shodovaly s metodami a t ídami v aplikaci, jejíº funkcionalita bude psána v anglickém jazyce. Sekven ní diagramy na za átku obsahují ov ení uºivatele. Ov ení práv k vykonání p ípadu

45 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ 29 uºití lze za ídit nap. pouºitím autoriza ního ltru, který bude p edcházet samotnému vykonání p ípadu uºití Klí ová slova IF - Místo alternativních scéná je v t²inou pouºito klí ové slovo IF na v tvení p ípadu uºití. Tak vznikne men²í po et p ípad uºití, které jsou tím i p ehledn j²í. FOR - Opakování je pouºito p i zobrazení r zných seznam, kdy je pot eba zpracovat v²echny prvky n jaké mnoºiny. WHILE - Slouºí k modelování posloupností akcí po spln ní p edem stanovené podmínky. EXTEND - Relace extend udává místa roz²í ení v p ípadu uºití. Klientský p ípad uºití je tedy i bez dodavatelského úplný, m ºe fungovat samostatn. INCLUDE - Naproti tomu relací include dáváme najevo, ºe klientský p ípad uºití bez dodavatelského nem ºe samostatn existovat Správa ºádostí Obrázek 4.3: Správa ºádostí. Referent a N-RLZ je zárove zam stnancem nebo manaºerem UCZ01 Prohlíºet seznam ºádostí pod ízených uºivatel Stru ný popis: Zobrazí seznam v²ech ºádostí pat ící pod uºivatele, tedy v²echny ºádosti, které se týkají pod ízených uºivatel. U kaºdé ºádosti bude vedle d leºitých informací také aktuální stav a moºnost zobrazit detail ºádosti. Hlavní akté i: Manaºer, Zástupce manaºera Vedlej²í akté i: šádní

46 30 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ Vstupní podmínky: uºivatel je p ihlá²en a má oprávn ní Hlavní scéná : 1. P ípad uºití za íná, kdyº uºivatel zvolí "Zobrazit seznam ºádostí po ízených" 2. Systém zobrazí seznam ºádostí pod ízených 3. IF Systém najde odpovídající ºádosti, pak: 1. FOR kaºdou ºádost: 1. Systém zobrazí d leºité informace 2. Systém zobrazí aktuální stav ºádosti 3. Systém zobrazí volbu pro zobrazení "Detailu ºádosti uºivatele" 4. INCLUDE: (ZobrazitVolby) podle p íslu²né role 2. IF uºivatel zvolí tisk seznamu ºádostí 1. EXTEND: TisknoutSeznamšádostí 4. IF Systém nenalezne odpovídající ºádosti: 1. Informuje o tom uºivatele Výstupní podmínky: ºádné Alternativní scéná e: ºádné Obrázek 4.4: Sekven ní diagram pro UCZ01 Prohlíºet seznam ºádostí pod ízených uºivatel UCZ02 Prohlíºet seznam v²ech ºádostí Analogické k UCZ01 Prohlíºet seznam ºádostí pod ízených UCZ03 Prohlíºet seznam ºádostí zam stnance Analogické k UCZ01 Prohlíºet seznam ºádostí pod ízených.

47 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ 31 Obrázek 4.5: Návrh uºivatelského rozhraní - v horní ásti hlavi ka aplikace, v dolní ásti Seznam ºádostí pod ízených UCZ UCZ04 Tisknout seznamy ºádostí Analogické k UCZ01 Prohlíºet seznam ºádostí pod ízených UCZ05 Prohlíºet detail ºádosti Stru ný popis: Zobrazí detail ºádosti, kterou si uºivatel vybere v p íslu²ném seznamu. šádost obsahuje vypln ný formulá, údaje o uºivateli a celý, dosud vytvo ený, schvalovací et zec. Podle p íslu²né role dále zobrazuje volby. Hlavní akté i: Zam stnanec, Manaºer, Zástupce manaºera, N-RLZ, Referent Vedlej²í akté i: šádní Vstupní podmínky: uºivatel je p ihlá²en a má oprávn ní Hlavní scéná : 1. P ípad uºití za íná, kdyº uºivatel zvolí "Detail ºádosti uºivatele" 2. Systém zobrazí detail ºádosti s vypln ným formulá em, údaji o uºivateli 3. FOR kaºdé schválení 1. Systém zobrazí stav schválení a schvalovatele 2. Systém zobrazí poznámku schválení 4. INCLUDE: (ZobrazitVolby) podle p íslu²né role 5. IF uºivatel zvolí tisk ºádosti 1. EXTEND: TisknoutDetailšádosti Výstupní podmínky: ºádné Alternativní scéná e: ºádné UCZ06 Tisknout detail ºádosti Analogické k UCZ05 Prohlíºet detail ºádosti.

48 32 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ Obrázek 4.6: Sekven ní diagram pro UCZ05 Prohlíºet detail ºádosti UCZ07 Zobrazit volby Stru ný popis: Systém aktivuje volby podle p íslu²né role. Hlavní akté i: Zam stnanec, Manaºer, Zástupce manaºera, N-RLZ, Referent Vedlej²í akté i: šádní Vstupní podmínky: uºivatel je p ihlá²en a má oprávn ní Hlavní scéná : 1. P ípad uºití za íná, kdyº je systém o to poºádán (zahrnutý - include UC) 2. Systém zobrazí volbu tisk ºádosti 3. Systém zobrazí volby podle p íslu²né role uºivatele 4. IF uºivatel je ten, který má podat ºádost (manaºer nebo zástupce manaºera) 1. Systém zobrazí volby "Podat ºádost", "Zru²it ºádost"a "Zatím nepodávat" 5. IF uºivatel je ten, který má schválit/zamítnout ºádost (manaºer nebo zástupce manaºera) 1. Systém zobrazí volbu "Schválit ºádost"a volbu "Zamítnout ºádost" 6. IF uºivatel je ten, který má Zaevidovat ºádost 1. Systém zobrazí volbu "Zaevidovat ºádost" Výstupní podmínky: ºádné Alternativní scéná e: ºádné UCZ08 Zvolit a vyplnit ºádost Stru ný popis: Uºivatel zvolí p íslu²nou ºádost. Zobrazí se prázdná ºádost, ve které zvolí osobu, pro kterou ºádost vypl uje, dále se zobrazí formulá pro zadání údaj a nabídka na Zru²it, Zatím nepodávat a Podat. Hlavní akté i: Manaºer, Zástupce manaºera

49 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ 33 Obrázek 4.7: Návrh uºivatelského rozhraní - Detail ºádosti UCZ05 a zakomponování formulá e v ºádosti. Vedlej²í akté i: šádní Vstupní podmínky: uºivatel je p ihlá²en a má oprávn ní, existuje formulá v nabídce Hlavní scéná : 1. P ípad uºití za íná, kdyº uºivatel vybere ºádost z nabídky 2. Systém zobrazí seznam p ímých pod ízených 3. Systém zobrazí prázdný formulá zkonstruovaný podle ²ablony 4. WHILE údaje jsou neplatné 1. Uºivatel zvolí Zam stnance, kterého se ºádost týká 2. Uºivatel vyplní formulá 3. Uºivatel ºádost potvrdí 4. Systém ov í údaje 5. IF nebyl vybrán Zam stnanec 1. Systém informuje uºivatele, ºe nezvolil Zam stnance 6. IF údaje ve formulá i nebyly vypln ny 1. Systém informuje uºivatele, který údaj ve formulá i chybí Výstupní podmínky: v²echny povinné údaje v ºádosti jsou vypln né a platné Alternativní scéná e: 2a. Uºivatel zvolí "Storno"nebo opustí sekci s ºádostí 1. Systém p eru²í vypl ování ºádosti, p ípad uºití kon í

50 34 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ Obrázek 4.8: Sekven ní diagram pro UCZ07 Zobrazit volby UCZ09 Vytvo it ºádost Stru ný popis: Jakmile jsou v²echny povinné údaje v ºádosti vypln né a platné, systém vytvo í novou ºádost a první schválení, které je v tomto p ípad podáním ºádosti. Do tohoto schválení uloºí stav 0 - vypln no ( eká na podání), viz 4.1 Stavový diagram. šádost se schválením uloºí do databáze. Hlavní akté i: Systém Vedlej²í akté i: šádní Vstupní podmínky: v²echny povinné údaje v ºádosti jsou vypln né a platné Hlavní scéná : 1. P ípad uºití za íná, kdyº jsou v²echny povinné údaje v ºádosti vypln né a platné. 2. Systém vytvo í novou ºádost 3. Systém naplní tuto ºádost údaji získanými od uºivatele 4. Systém vytvo í nové schválení=podání 5. Systém nastaví schvalovatele na práv p ihlá²eného, vypl ujícího manaºera 6. Systém nastaví stav schválení na 0 7. Systém ºádost se schválením uloºí do databáze 8. Systém zobrazí detail ºádosti a zobrazí volby "Zatím nepodávat"a "Podat ºádost" Výstupní podmínky: šádost byla uloºena a má p i azený stav 0. Alternativní scéná e: ºádné

51 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ 35 Obrázek 4.9: Sekven ní diagram pro UCZ08 Zvolit a vyplnit ºádost UCZ10 Podat ºádost Stru ný popis: Uºivatel podá (podepí²e) ºádost, která je tak automaticky za azena do schvalovacího procesu. Stav ºádosti se zm ní podle stavového diagramu ze stavu 0 na 20, 21, nebo 22. Hlavní akté i: Manaºer, Zástupce manaºera Vedlej²í akté i: šádní Vstupní podmínky: uºivatel je p ihlá²en a má oprávn ní, ºádost je ve stavu 0 Hlavní scéná : 1. P ípad uºití za íná, kdyº uºivatel potvrdí podání ºádosti 2. Systém za adí ºádost do stavu 20, 21 nebo Systém informuje uºivatele o podání ºádosti Výstupní podmínky: šádost byla uloºena a má p i azený stav 20, 21 nebo 22 Alternativní scéná e: ºádné UCZ11 Zru²it ºádost Stru ný popis: Uºivatel zru²í je²t nepodanou ºádost pokud je ve stavu "0 - vypln no ( eká na podání)". Hlavní akté i: Manaºer, Zástupce manaºera

52 36 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ Obrázek 4.10: Návrh uºivatelského rozhraní - Nová ºádost UCZ08. Vedlej²í akté i: šádní Vstupní podmínky: uºivatel je p ihlá²en a má oprávn ní, ºádost je ve stavu 0 Hlavní scéná : 1. P ípad uºití za íná, kdyº uºivatel zru²í nepodanou ºádost 2. Systém vymaºe ºádost i se schválením z databáze 3. Systém informuje uºivatele o smazání ºádosti Výstupní podmínky: šádost byla odstran na z databáze Alternativní scéná e: ºádné UCZ12 Schválit ºádost Stru ný popis: Uºivatel schválí ºádost. M ºe vloºit také svou poznámku k ºádosti. Hlavní akté i: Manaºer, Zástupce manaºera, N-RLZ Vedlej²í akté i: Zam stnanec Vstupní podmínky: uºivatel je p ihlá²en a má oprávn ní, ºádost je ve stavu 20, 21, 40 nebo 41 podle stavového diagramu Hlavní scéná : 1. P ípad uºití za íná, kdyº uºivatel potvrdí schválení ºádosti 2. Systém vytvo í nové schválení a nastaví jej na stav na 40, 41 nebo Systém poºádá o vloºení poznámky 4. IF uºivatel vloºí poznámku 1. Systém p ipojí poznámku ke schválení 5. Systém p ipojí schválení k ºádosti 6. IF uºivatel není nejvy²²ím Manaºerem

53 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ 37 Obrázek 4.11: Sekven ní diagram pro UCZ09 Vytvo it ºádost. 1. EXTEND: PoslatZprávu (po²le zprávu s poºadavkem na schválení nad ízenému Mana- ºerovi) 7. IF uºivatel je nejvy²²ím Manaºerem 1. EXTEND: PoslatZprávu (po²le zprávu s poºadavkem na schválení MLZ) 8. Systém ºádost s novým schválením uloºí 9. Systém informuje uºivatele o schválení ºádosti Výstupní podmínky: šádost byla uloºena a má p i azený stav 40, 41 nebo 42 Alternativní scéná e: ºádné UCZ13 Zamítnout ºádost Analogické k UCZ12 Schválit ºádost UCZ14 Zaevidovat ºádost Analogické k UCZ12 Schválit ºádost UCZ15 Poslat zprávu Stru ný popis: Systém ode²le zprávu na zvolenou adresu. Hlavní akté i: Systém Vedlej²í akté i: šádní Vstupní podmínky: Zpráva obsahuje p edm t, text, adresy odesílatele a p íjemce. Po²tovní server je zapnutý. Systém má správné údaje o po²tovním serveru. Hlavní scéná : 1. P ípad uºití za íná, kdyº systém získá informace pro odeslání zprávy

54 38 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ Obrázek 4.12: Sekven ní diagram pro UCZ10 Podat ºádost. Obrázek 4.13: Sekven ní diagram pro UCZ11 Zru²it ºádost. 2. Systém ve správném formátu ode²le zprávu na p íslu²ný po²tovní server 3. Systém oznámí uºivateli, ºe zpráva byla odeslána Výstupní podmínky: ºádné Alternativní scéná e: ºádné Správa uºivatel UCU01 P ihlásit Stru ný popis: P ihla²ovací procedura do Systému potvrzování personálních ºádostí. Uºivatel se identikuje jménem a heslem, systém zkontroluje údaje a pokud jsou v po ádku, uloºí uºivatele do session a zobrazí opera ní menu podle role aktéra. Jestliºe údaje nejsou v po ádku, systém na to upozorní a vyzve k zadání nových údaj. Hlavní akté i: Zam stnanec Vedlej²í akté i: šádní Vstupní podmínky: Uºivatel je aktivní.

55 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ 39 Obrázek 4.14: Sekven ní diagram pro UCZ12 Schválit ºádost. Hlavní scéná : 1. P ípad uºití za íná, kdyº uºivatel zadá p ihla²ovací jméno a heslo 2. Systém zkontroluje údaje. 3. IF údaje jsou platné 1. Systém uloºí uºivatele do http session 2. Systém zobrazí menu s nabídkami a stránku pro p íslu²né aktéry 4. IF údaje neplatné 1. Systém informuje uºivatele o neplatných údajích 2. Systém zobrazí "P ihla²ovací menu" Výstupní podmínky: Uºivatel je p ihlá²en. Alternativní scéná e: ºádné UCU02 Odhlásit Stru ný popis: Odhla²ovací procedura ze Systému potvrzování personálních ºádostí. Systém po odhlá²ení odstraní p ihla²ovací údaje uºivatele ze session. Hlavní akté i: Zam stnanec Vedlej²í akté i: šádní Vstupní podmínky: Uºivatel je p ihlá²en. Hlavní scéná : 1. P ípad uºití za íná, kdyº uºivatel zvolí "Odhlásit" 2. Systém odstraní uºivatele z http session

56 40 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ Obrázek 4.15: Správa uºivatel. Referent a N-RLZ je zárove zam stnancem nebo manaºerem. 3. Systém zobrazí p ihla²ovací stránku Výstupní podmínky: ºádné Alternativní scéná e: ºádné UCU03 Prohlíºet seznam pod ízených uºivatel Stru ný popis: Zobrazí seznam v²ech (i nep ímo) pod ízených uºivatel Manaºera. U kaºdého uºivatele bude vedle d leºitých informací také moºnost poslat uºivateli zprávu a moºnost zobrazit detail uºivatele. Hlavní akté i: Manaºer, Zástupce manaºera Vedlej²í akté i: šádní Vstupní podmínky: uºivatel je p ihlá²en a má oprávn ní Hlavní scéná : 1. P ípad uºití za íná, kdyº uºivatel zvolí "Zobrazit seznam v²ech (i nep ímo) pod ízených uºivatel " 2. Systém zobrazí seznam v²ech uºivatel dle kritéria 3. IF Systém najde odpovídající uºivatele pro zvolené kritérium, pak: 1. FOR kaºdého uºivatele 1. Systém zobrazí d leºité informace o uºivateli 2. Systém zobrazí volbu pro "Poslání zprávy" 3. Systém zobrazí volbu pro zobrazení "Detailu uºivatele" 2. IF uºivatel zvolí tisk seznamu uºivatel 1. EXTEND: TisknoutSeznamUºivatel 4. IF Systém nenalezne odpovídající uºivatele 1. Informuje o tom uºivatele

57 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ 41 Obrázek 4.16: Sekven ní diagram pro UCU01 P ihlásit. Výstupní podmínky: ºádné Alternativní scéná e: ºádné Obrázek 4.17: Návrh uºivatelského rozhraní - UCU03 Seznam nad ízených a pod ízených uºivatel uºivatele Jelínka UCU04 Prohlíºet seznam nad ízených uºivatel Analogické k UCU03 Prohlíºet seznam pod ízených uºivatel UCU05 Prohlíºet seznam v²ech uºivatel Analogické k UCU03 Prohlíºet seznam pod ízených uºivatel UCU06 Tisknout seznamy uºivatel Analogické k UCU03 Prohlíºet seznam pod ízených uºivatel.

58 42 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ UCU07 Prohlíºet detail uºivatele Stru ný popis: Zobrazí detail vybraného uºivatele, jeho osobní íslo, jméno a p íjmení, p i azené role, a odkaz na jeho nad ízeného a referenta. Dále zobrazí moºnost pro "Poslání zprávy"uºivateli. Hlavní akté i: Zam stnanec, Manaºer, Zástupce manaºera, N-RLZ, Referent Vedlej²í akté i: šádní Vstupní podmínky: uºivatel je p ihlá²en a má oprávn ní Hlavní scéná : 1. P ípad uºití za íná, kdyº uºivatel u ur itého uºivatele v seznamu zvolí zobrazit "Detail uºivatele" 2. Systém zobrazí detail uºivatele s jeho identika ním íslem, jménem a p íjmením, p i azenými rolemi a em a s odkazem na jeho nad ízeného a referenta. 3. IF uºivatel neprohlíºí sebe sama 1. Systém zobrazí moºnost pro "Poslání zprávy"uºivateli. 4. IF uºivatel prohlíºí sebe sama 1. Systém zobrazí volbu zm ny hesla 5. IF uºivatel zvolí tisk detailu uºivatele 1. EXTEND: TisknoutDetailUºivatele Výstupní podmínky: ºádné Alternativní scéná e: ºádné Obrázek 4.18: Návrh uºivatelského rozhraní - Detail uºivatele UCU UCU08 Tisknout detail uºivatele Analogické k UCU07 Prohlíºet detail uºivatele.

59 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ UCU09 Upravit heslo Stru ný popis: Uºivatel zm ní své heslo. To bude v zakódované podob uloºeno k ú tu uºivatele. Hlavní akté i: Zam stnanec Vedlej²í akté i: šádní Vstupní podmínky: uºivatel je p ihlá²en Hlavní scéná : 1. P ípad uºití za íná, kdyº uºivatel zvolí "Zm nit heslo" 2. WHILE údaje jsou neplatné 1. Systém se zeptá na staré heslo, na nové heslo a na potvrzení nového hesla 2. Uºivatel vyplní údaje a potvrdí 3. IF staré heslo je neplatné 1. Systém informuje uºivatele, ºe vloºil neplatné p vodní heslo 4. IF potvrzení nového hesla není stejné jako nové heslo 1. Systém informuje uºivatele, ºe se neshoduje potvrzení nového hesla Výstupní podmínky: Uºivatelovo heslo bylo zm n no a uloºeno Alternativní scéná e: 2a. Uºivatel zru²í úpravu hesla 1. Systém opustí úpravu hesla, p ípad uºití kon í UCU10 Nastavit zástupce Stru ný popis: Manaºer zm ní zástupce. Hlavní akté i: Manaºer Vedlej²í akté i: Zam stnanec Vstupní podmínky: uºivatel je p ihlá²en Hlavní scéná : 1. P ípad uºití za íná, kdyº uºivatel vybere Zástupce ze seznamu pod ízených 2. Uºivatel potvrdí zm nu 3. Systém poznamená zm nu rolí v databázi. Roli odebere bývalému Zástupci (byl-li zvolen) a p i adí ji novému Zástupci. Systém automaticky aktivuje nového Zástupce, tím zvolenému Zástupci p i adí stejná práva, jako má Manaºer. Výstupní podmínky: ºádné Alternativní scéná e: ºádné UCU11 Vloºit uºivatele Stru ný popis: Referent nebo N-RLZ vloºí do systému nového uºivatele. Vyplní osobní íslo, jméno, p íjmení, , pracovi²t a funkci a ur í nad ízeného. Systém uºivatele uloºí do

60 44 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ databáze a ode²le na jeho ovou adresu zprávu o zaloºení ú tu spolu s vygenerovaným heslem. Hlavní akté i: Referent, N-RLZ Vedlej²í akté i: Zam stnanec Vstupní podmínky: uºivatel je p ihlá²en Hlavní scéná : 1. P ípad uºití za íná, kdyº referent zvolí "Vloºit uºivatele" 2. WHILE jsou údaje neplatné nebo nevypln né 1. Systém ºádá, aby referent vloºil osobní íslo (jedine né), jméno a p íjmení nového uºivatele, ovou adresu (jedine nou), pracovi²t a funkci a zvolí nad ízeného 2. Referent formulá potvrdí 3. Systém ov í údaje uºivatele 4. IF chybí vypln né údaje 1. Systém upozorní Referenta 5. IF osobní íslo není jedine né OR je neplatný OR není jedine ný 1. Systém informuje Referenta 3. Systém vygeneruje heslo 4. Systém uloºí uºivatele do databáze 1. EXTEND: PoslatZprávu (Systém ode²le na ovou adresu uºivatele zprávu o zaloºení ú tu spolu s vygenerovaným heslem) Výstupní podmínky: Pro uºivatele byl vytvo en ú et Alternativní scéná e: 2a. Uºivatel zru²í tvorbu ú tu 1. Systém zru²í tvorbu ú tu, ºádné zm ny nejsou zaznamenány UCU12 Upravit uºivatele Analogické k UCU11 Vloºit uºivatele UCU13 P e adit uºivatele Analogické k UCU14 Smazat uºivatele UCU14 Smazat uºivatele Stru ný popis: Referent smaºe uºivatele ze systému. Hlavní akté i: Referent, N-RLZ Vedlej²í akté i: Zam stnanec Vstupní podmínky: uºivatel je p ihlá²en Hlavní scéná : 1. P ípad uºití za íná, kdyº referent zvolí "Smazat uºivatele"

61 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ 45 Obrázek 4.19: Sekven ní diagram pro UCU11 Vloºit uºivatele. 2. IF odstra ovaný uºivatel není manaºer 1. Systém odstraní uºivatele z hierarchie 3. IF odstra ovaný uºivatel je manaºer 1. Systém poºádá referenta, co chce provést 2. IF referent zvolí, ºe chce nahradit manaºera novým uºivatelem 1. Systém poºádá referenta o vytvo ení nového uºivatele, viz UCU11 Vloºit uºivatele 2. Systém vloºí nového uºivatele, starého odstraní z hierarchie a hierarchii upraví 3. IF chce p e adit v²echny manaºerovy pod ízené pod vy²²ího manaºera 1. Systém p e adí pod ízené, upraví hierarchii 4. IF chce p e adit v²echny manaºerovy pod ízené pod jiného uºivatele 1. Systém p e adí pod ízené, upraví hierarchii 5. IF chce odstranit také v²echny pod ízené 1. Systém odstraní v²echny pod ízené, upraví hierarchii Výstupní podmínky: V²echny zásahy v hierarchii povedeny, hierarchie konzistentní. Alternativní scéná e: 2a. Uºivatel zru²í mazání uºivatele 1. Systém nezasáhne do hierarchie a hierarchie uºivatel je ve stejném stavu jako p ed mazáním 2. Návrat do výchozího seznamu, p ípad uºití kon í UCU15 Zm nit N-RLZ Stru ný popis: N-RLZ privileguje roli N-RLZ novému nejvy²²ímu manaºerovi.

62 46 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ Obrázek 4.20: Návrh uºivatelského rozhraní - Vloºit nového uºivatele UCU11. Obrázek 4.21: Návrh uºivatelského rozhraní - UCU14 Smazat uºivatele, pokud je uºivatel manaºerem, je pot eba zvolit jednu z moºností. Hlavní akté i: N-RLZ Vedlej²í akté i: Zam stnanec Vstupní podmínky: N-RLZ je p ihlá²en Hlavní scéná : 1. P ípad uºití za íná, kdyº uºivatel zvolí "Zm nit N-RLZ" 2. Systém zobrazí seznam nejvy²²ích manaºer 3. Uºivatel zvolí nového N-RLZ a potvrdí zm nu 4. Systém zavede roli N-RLZ u vybraného manaºera 5. A odstraní roli N-RLZ u sou asného N-RLZ 6. Odhlásí uºivatele ze systému Výstupní podmínky: ºádné Alternativní scéná e: ºádné

63 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ UCU16 Vytvo it zprávu Stru ný popis: Uºivatel napí²e zprávu, zvolí adresáta a zprávu ode²le. Hlavní akté i: Zam stnanec, Manaºer, Zástupce manaºera, N-RLZ, Referent Vedlej²í akté i: ºádní Vstupní podmínky: Uºivatel je p ihlá²en Hlavní scéná : 1. P ípad uºití za íná, kdyº uºivatel zvolí "Poslání zprávy" 2. WHILE jsou údaje neplatné 1. Systém ºádá, aby uºivatel vloºil adresáta zprávy, text a p edm t zprávy. Pokud byl uºivatel p esm rován ze seznamu uºivatel nebo z detailu uºivatele, m ºe systém vyplnit adresáta sám 2. Uºivatel formulá vyplní 3. Systém ov í údaje uºivatele 4. IF chybí text nebo p edm t 1. Systém informuje na tuto chybu uºivatele 5. IF ová adresa je neplatná 1. Systém informuje uºivatele, ºe zadal ²patnou ovou adresu 3. INCLUDE: (PoslatZprávu) se zvoleným textem, p edm tem, odesílatelem a adresátem Výstupní podmínky: Zpráva obsahuje p edm t, text, adresy odesílatele a p íjemce. Alternativní scéná e: 2a. Uºivatel zru²í tvorbu zprávy 1. Systém zru²í tvorbu zprávy a nic neode²le, p ípad uºití kon í UCU17 Poslat zprávu Stejné jako UCZ15 Poslat zprávu Správa formulá (²ablon formulá ) Obrázek 4.22: Správa formulá.

64 48 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ UCF01 Prohlíºet seznam formulá Stru ný popis: Zobrazí seznam v²ech formulá v systému s moºnostmi p idat nový formulá, smazat formulá a prohlédnout detail formulá e. Hlavní akté i: N-RLZ, Admin Vedlej²í akté i: ºádní Vstupní podmínky: Uºivatel je p ihlá²en Hlavní scéná : 1. P ípad uºití za íná, kdyº Administrátor zvolí "Zobrazit seznam formulá " 2. Systém zobrazí seznam v²ech formulá 3. IF Systém nalezne formulá e, pak: 1. FOR kaºdý formulá 1. Systém zobrazí d leºité informace o formulá i 2. Systém zobrazí volbu pro smazání formulá e 3. Systém zobrazí volbu pro zobrazení detailu formulá e 4. IF Systém nenalezne odpovídající uºivatele 1. Informuje o tom uºivatele Výstupní podmínky: ºádné Alternativní scéná e: ºádné Obrázek 4.23: Návrh uºivatelského rozhraní - vkládání formulá UCF03 a seznam formulá UCF UCF02 Prohlíºet detail formulá e Stru ný popis: Zobrazí detail prázdného formulá e. Hlavní akté i: N-RLZ, Admin Vedlej²í akté i: ºádní Vstupní podmínky: Uºivatel je p ihlá²en Hlavní scéná : 1. P ípad uºití za íná, kdyº Administrátor v seznamu formulá zvolí zobrazit "Detail formulá e" 2. Systém zobrazí detail prázdného formulá e, tak jak jej vloºil do systému administrátor

65 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ 49 Výstupní podmínky: ºádné Alternativní scéná e: ºádné UCF03 Vloºit formulá Stru ný popis: Administrátor vloºí do systému nový formulá nahráním souboru s validním formulá em. Obsahuje jméno formulá e, lokalizaci a ²ablonu, podle které se formulá vytvo í. Textová tvorba formulá e viz kapitola o Tvorb formulá. Hlavní akté i: N-RLZ, Admin Vedlej²í akté i: ºádní Vstupní podmínky: Uºivatel je p ihlá²en Hlavní scéná : 1. P ípad uºití za íná, kdyº Administrátor zvolí "Vloºit formulá " 2. WHILE jsou údaje neplatné 1. Systém vyzve uºivatele ke vloºení adresá ové cesty, kde se nachází soubor s formulá em 2. Uºivatel vloºí cestu a potvrdí ji 3. Systém ov í soubor s formulá em 4. IF soubor na dané adresá ové cest neexistuje 1. Systém upozorní uºivatele na neexistující soubor 5. IF soubor neobsahuje validní formulá 1. Systém upozorní uºivatele na invalidní formulá 3. Systém uloºí formulá do databáze Výstupní podmínky: ºádné Alternativní scéná e: 2a. Uºivatel zru²í vkládání formulá e 1. Systém zru²í vkládání formulá e, p ípad uºití kon í UCF04 Smazat formulá Stru ný popis: Administrátor smaºe formulá z databáze. Hlavní akté i: N-RLZ, Admin Vedlej²í akté i: ºádní Vstupní podmínky: Uºivatel je p ihlá²en Hlavní scéná : 1. P ípad uºití za íná, kdyº Administrátor zvolí "Smazat formulá " 2. IF formulá není pouºitý ºádnou ºádostí 1. Systém smaºe formulá z databáze Výstupní podmínky: Formulá byl odstran n z databáze. Alternativní scéná e: ºádné

66 50 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ 4.4 Matice pokrytí funk ních poºadavk Kaºdý funk ní poºadavek uvedený v kapitole 3.5 je pokryt jedním nebo více p ípady uºití. Viz tabulka 4.1. poºadavek p ípady uºití poºadavek p ípady uºití 1 UCU01, UCU02 23 UCU15, UCU16 2 UCZ05, UCZ06 24 UCU10 3 UCZ03, UCZ04 25 UCs jako manaºer 4 UCU07, UCU08 26 UCZ12, UCZ13 5 UCU04, UCU06 27 UCZ12 6 UCU15, UCU16 28 UCU12 7 UCU07, UCU09 29 UCs jako referent 8 UCZ08, UCZ09, UCZ10 30 UCs jako admin 9 UCZ11 31 UCZ14 10 UCZ12, UCZ13 32 UCZ05, UCZ06, UCZ07 11 UCZ08, UCZ12 33 UCZ02, UCZ04, UCZ07 12 UCZ01, UCZ04, UCZ07 34 UCZ14, UCZ15 13 UCZ05, 0CZ06, UCZ07 35 UCU11 14 UCZ01, UCZ04, UCZ07 36 UCU07, UCU08 15 UCZ05, 0CZ06, UCZ07 37 UCU05, UCU06 16 UCZ12 38 UCU12 17 UCZ12 39 UCU13 18 UCZ12, UCZ15 40 UCU14 19 UCZ13, UCZ15 41 UCU15, UCU16 20 UCZ08 42 UCF03 21 UCU07, UCU08 43 UCF04 22 UCU03, UCU06 44 UCF01, UCF02 Tabulka 4.1: Matice pokrytí funk ních poºadavk 4.5 ER konceptuální model Konceptuální model dat obsahuje v²echny entity systému a jejich základní, nejd leºit j²í atributy. Dále obsahuje vztahy mezi entitami. Viz obrázek Fyzický databázový model s integritními omezeními a se v²emi atributy bude popsán v kapitole Implementace poté, co z analýzy a návrhu vyplynou v²echny poºadavky Popis entit Entita Uºivatel (User) - Tato entita je pro v²echny uºivatele systému. Uºivatel m ºe nabývat r zných rolí. U kaºdého uºivatel se udrºuje odkaz na dva jiné uºivatele, na jeho nad ízeného (vztah je nad ízeným) a na referenta (vztah je referentem). Pokud id_nad ízený = id uºivatele, uºivatel nemá nad ízeného, je nejvy²²í. Entita Formulá (Form) - Jedním z d leºitých poºadavk na systém je moºnost tvorby nových formulá. Nebo spí²e tvorby ²ablon, které udávají vzhled a lokalizovaný název a popisky formulá e. Naopak není poºadavkem, aby data formulá e byla systémem zpracována (uloºena do

67 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ 51 Obrázek 4.24: Konceptuální model. jiných databází, pouºita jiným systémem). Entita Formulá obsahuje pouze p edpis, jak zobrazit serializovaná data uloºená v entit šádost. Podle t chto dat poté referent na konci schvalovacího et zce provede ty úkony, kterých si ºádost ºádá. Pokud by zpracování formulá ových dat bylo vyºadováno, tak by se kv li heterogennosti formulá a moºnosti p idávat nové formulá e systém stal nesmírn sloºit j²ím. Jedním z e²ení je tedy poskytnout administrátor m systému moºnost vytvo ení nového formulá e (²ablony formulá e) denovaného pravidly. Entita Formulá e bude obsahovat informace o validní ²ablon formulá e, který samotný bude uloºen na serveru. Entita šádost (Petition) - Entita šádosti obsahuje v²echny personální ºádosti. Kaºdá ºádost obsahuje mj. odkaz na uºivatele, kterého se ºádost týká, odkaz na formulá (²ablonu formulá e) a data formulá e. Entita Schválení (Conrm) - Schvalovací et zec ºádosti by ²lo za lenit také do tabulky šádosti, ne²lo by v n m v²ak jednodu²e vyhledávat. Proto je lep²í pouºít jinou tabulku Schválení, jejíº kaºdý ádek obsahuje odkaz na ºádost, které se týká. Jedna ºádost má více schválení a tím je zkonstruován schvalovací et zec. Kaºdé schválení odkazuje na uºivatele, který schválení vydal. První schválení ºádosti je její podání a odkazuje tak na uºivatele, který ºádost vyplnil. Entita Funkce (Position) - Tato entita je tzv. íselník, který nese pouze klí a hodnotu. Entita je ur ena pro uchování v²ech uºivatelských funkcí v podniku. Entita Pracovi²t (Workplace) - Tato entita je tzv. íselník, který nese pouze klí a hodnotu. Entita je ur ena pro uchování v²ech uºivatelských pracovi² v podniku. Entita Odd lení (Department) - Tato entita je tzv. íselník, který nese pouze klí a hodnotu. Entita je ur ena pro uchování v²ech uºivatelských odd lení v podniku Popis vztah Vztah Je nad ízeným (mezi User a User) - kardinalita 1:N, uºivatel je nad ízeným N uºivatel m, uºivatel má práv jednoho nad ízeného Vztah Je referentem (mezi User a User) - kardinalita 1:N, uºivatel je referentem N uºivatel m, uºivatel má práv jednoho referenta

68 52 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ Vztah Se týká (mezi Petition a User) - kardinalita 1:N, ºádost se týká práv jednoho zam stnance, zam stnanec má N ºádostí Vztah Obsahuje (mezi Petition a Form) - kardinalita 1:N, ºádost obsahuje práv jeden formulá, formulá je pouºit v N ºádostech Vztah Obsahuje (mezi Petition a Conrm) - kardinalita 1:N, ºádost obsahuje N schválení, schválení pat í jedné ºádosti Vztah Schválil/podal (mezi User a Conrm) - kardinalita 1:N, manaºer schválil/podal N schválení, schválení je schváleno/podáno jedním manaºerem Vztah Pracuje v (mezi User a íselníky) - kardinalita 1:N, uºivatel pracuje v jedné funkci/pracovi²ti/odd lení, funkce/pracovi²t /odd lení má N zam stnanc Popis atribut state a role Tyto atributy by bylo moºné také vyjád it samotnými entitami a m ly by funkci íselník. Mnoºiny stav ºádostí a rolí uºivatel jsou v²ak v systému nem nné. Stav ºádosti je ur en p echodem ve stavovém diagramu uvedeném na obr. 4.1, nikoli uºivatelovou volbou. Systém je zaloºen na pevn daných rolích, uºivateli nem ºe být p i azena neexistující role. Je tedy automaticky zabezpe ené, ºe atributy nebudou nabývat jiných, neexistujících hodnot. Framework JSF poskytuje jednoduchý p ístup k lokalizovaným soubor m vlastností (.properties), tedy nemusíme pouºívat entity a sta í pouºít atributy s malým rozsahem pevn daných hodnot. To má výhodu i v tom, ºe lze názvy rolí a stav jednodu²e lokalizovat. Pro kaºdou hodnotu pak soubor vlastností nese mnoºinu p idruºených výraz. Lze pouºít i parametry ( eská verze): Atribut state State == 0 State0=vypln no State0_long= eká na podání State0_verb=vyplnil/a State0_message=šádost. {0} byla vypln na. State == 20 State20=podáno State20_long= eká na schválení State20_verb=podal/a State20_message=šádost. {0} byla podána. A tak dále... Atribut role Role == 0 (nemá volitelnou roli) (není t eba denovat et zec) Role == 1 (N-RLZ) RoleMhrText=N-RLZ Role == 2 (referent) RoleOfficerText=referent Role == 3 (admin) RoleAdminText=admin Role == 4 (referent a admin zárove ) (z et zení text pro roli 2 a roli 3)

69 KAPITOLA 5. IMPLEMENTACE 53 5 Implementace 5.1 Implementace p ípad uºití Podle seznamu poºadavk v kapitole 3.5 byly naimplementovány v²echny p ípady uºití z kapitoly 4.3, které pokrývají funk ní poºadavky nezbytné (ozna ené písmenem M) a v t²inu ostatních poºadavk. Aplikace v této verzi neobsahuje poºadavky, které pracují s em (poºadavky. 6, 18, 19, 23, 34 a 41), ty jsou v kategorii chceme mít v budoucnu (písmeno W). Dále není v systému zavedena role zástupce (poºadavky. 24, 25). Ze zákazníkových poºadavk dále plyne, ºe pro b h systému nejsou d leºité samostatné tabulky Funkce, Odd lení a Pracovi²t. V aktuální verzi aplikace jsou tedy místo nich do asn zavedeny stejnojmenné textové atributy v tabulce Uºivatelé. Ty mohou nabývat i nulových hodnot. 5.2 Tvorba formulá (²ablon formulá ) Uºivatelská tvorba formulá je jedním ze st ºejních poºadavk. Administrátor musí mít nástroj k vytvá ení, ke vkládání, ke správ a k odstra ování formulá. Formulá by v tomto systému bylo lep²í nazvat ²ablonou formulá e. Jde o datovou strukturu, která nese vzhled nejd leºit j²í, nosné ásti ºádosti. Má jméno, p íp. alternativní jméno a obsahuje p edpisy, jak zobrazit vstupní a výstupní data. Nic víc. šádná navázání na dal²í remní aplikace se od formulá e neºádají. Samotná ºádost nese serializovaná data a odkaz na ²ablonu formulá e, podle které se tato data zp t zkonstruují, aby je vid l uºivatel (viz obrázek 4.7 na stran 33). Systém InSypoPepo má nahradit pouze manuální podávání ºádostí. Poté, co je ºádost v²emi schválena, referent ji zaeviduje a podle ºádosti vykoná úkoly (zm ny v ostatních remních aplikacích, i oby ejných kartotékách), jako tomu bylo dosud Vytvo ení ²ablony formulá e uºivatelem Podrobný popis vytvo ení formulá e, spolu s celou syntaxí i s p íkladem, je uveden v uºivatelské p íru ce administrátora (viz kap. D.11.2). Formulá se tvo í jako dokument XML podle daných pravidel. Tato pravidla jsou uvedena ve valida ním XML Schema souboru a popisují v²echna integritní omezení jako jsou povolené elementy, jejich uspo ádání, datové typy, rozsahy hodnot. Dokud formulá nesplní v²echna kritéria, server jej nep ijme Zavedení ²ablony formulá e do systému Uºivatel s povolením Správa formulá (N-RLZ, admin) m ºe vytvo enou ²ablonu formulá e nahrát na server. Následují operace v tomto po adí: validace XML dokumentu proti XML Schema, transformace XML pomocí XSL na JSP/JSF soubory a to soubory pro vstup, pro výstup a pro výstup na tisk, uloºení XML souboru i v²ech vytvo ených JSP/JSF soubor na server, vytvo ení nového objektu Form se základními informacemi, jako jsou název souboru a jméno formulá e, a uloºení tohoto DTO 1 objektu do databáze. 1 z angl. Data Transfer Object, viz kap. 5.6, viz obr. 5.3

70 54 KAPITOLA 5. IMPLEMENTACE Pokud p i n jaké operaci nastane chyba, proces vkládání ²ablony skon í a systém nahlásí chybu uºivateli (viz obrázek 4.23 na stran 48). Dokud není vytvo en záznam v databázi (coº je poslední operace), nelze formulá systémem vyuºít Propojení ²ablony formulá e se ºádostí Chce-li uºivatel vytvo it novou ºádost, systém nalezne odpovídající JSP/JSF soubor pro vstup a zobrazí jej jako sou ást ºádosti. Poté, co uºivatel vyplní vstupní pole samotného formulá e a potvrdí vytvo ení ºádosti, jsou data z t chto vstupních polí serializována a v této podob uloºena pod atribut data v DTO objektu Petition (ºádost) (viz kap. 5.6). Naopak, chce-li uºivatel prohlédnout detail ºádosti nebo tisk ºádosti, systém pouºije JSP/JSF soubor pro výstup nebo pro tisk, deserializuje data a nechá je zobrazit p íslu²ným JSP/JSF souborem. 5.3 Aplikace zaloºená na vrstvách Model vrstev pro aplikaci InSypoPepo vychází p edev²ím ze zdroj [6],[10], [2] a [11]. Zde jsou stavby jednotlivých vrstev a jejich funkce popsány. Vºdy v²ak pouze na díl ích p íkladech. Model uvedený v této kapitole tedy vychází z mé maximální snahy detailn a logicky popsat a vytvo it kompletní aplikaci zaloºenou na vrstvách. Jist je moºné problematiku vrstev popsat i jinak (jak jiné termíny, tak jiné vrstvy). Obrázek 5.1: Aplikace zaloºená na vrstvách. Základní my²lenka aplikace vytvo ené na vrstvách je taková, ºe vrstvy jsou na sob nezávislé a (v tomto konkrétním p ípad, viz obrázek 5.1) vrstva napravo neví nic o existenci vrstvy nalevo. Nap íklad, pokud se zm ní technologie prezenta ní vrstvy z JSP na XSLT, aplika ní vrstva a v²echny dal²í vrstvy napravo o této zm n nebudou nic v d t a budou fungovat dál. Nebo, pokud se pozm ní n které vlastnosti DTO objektu User, DAO 2 objekt UserDAO z integra ní vrstvy, který s ním pracuje, není pot eba m nit, protoºe ho vnit nosti DTO objektu nezajímají. Naopak nelze m nit objekt User, aniº by se nezm nila p íslu²ná tabulka v databázi (fyzická vrstva je napravo od objektu User). Do t etice, aplika ní vrstva nem ºe získat ºádný DTO objekt bez pomoci integra ní vrstvy (DAO objektu). Stejn tak, pokud n jaká Backing bean vytvo í DTO objekt, op t musí vyuºít DAO objekt, aby jej mohl Hibernate uloºit do databáze. 2 z angl. Data Access Object, viz kap. 5.7, viz obr. 5.3

71 KAPITOLA 5. IMPLEMENTACE Fyzická vrstva Fyzická vrstva je popsána fyzickým modelem dat, který vychází z konceptuálního modelu uvedeného v kapitole 4.5. Ve fyzickém modelu jsou pouºity místo entit tabulky a místo relací integritní omezení pomocí cizích klí FK 3. Na obrázku 5.2 jsou uvedeny v²echny sloupce spolu s datovými typy a integritními omezeními. Kaºdá tabulka obsahuje primární klí PK 4 identi- ka ní íslo ID. Teorie je popsána v [8] a [9]. Obrázek 5.2: Fyzický model dat Datový slovník Jelikoº je pouºit ORM framework Hibernate, který mapuje fyzickou vrstvu na business vrstvu a jedná se tedy o ekvivalentní modely (pouze nazírané bu z rela ního nebo objektového pohledu), budou v²echny atributy a jejich datové typy popsány v kapitole 5.6 o business vrstv Vztahy mezi tabulkami Konceptuální model neobsahuje ºádné vztahy M:N, proto ve fyzickém modelu nevznikly ºádné nové vztahy. Z objektového pohledu budou vztahy mezi DTO objekty popsány v kapitole 5.6 o business vrstv Integritní omezení Slouºí k tomu, aby z stal fyzický model konzistentní. Nap íklad, aby se neztratila data, která vyuºívají jiné entity, nebo aby nebyla vloºena data, která obsahují stejné unikátní atributy. 3 z angl. Foreign Key 4 z angl. Primary Key

72 56 KAPITOLA 5. IMPLEMENTACE Doménová integrita je dána datovými typy sloupc, rozsahy t chto datových typ a také povinností / volitelností hodnot (null / not null). Entitní integrita je dána primárním klí em, který je povinný. Referen ní integrita popisuje vztahy mezi tabulkami pomocí cizích klí. 5.5 Persistentní vrstva Tato vrstva je tvo ena knihovnou Hibernate. Pro správu session je pouºit ltr HibernateSessionRequestFilter, který je popsán v [12]. Filtr je standardní sloºkou API servlet a umoº uje uºivateli vykonat p ídavné operace na poºadavku (http request) p edtím a potom, neº je poºadavek zpracován tradi ními servlety. Filtr lze omezit pouze na poºadavky p icházející z ur itých URL. V tomto p ípad (viz následující segment kódu) ltr odchytí poºadavek d íve neº servlet - controller (Faces Servlet, který obsluhuje JSF), získá spojení na databázi a p enechává práci dál (ostatním ltr m a Faces Servletu). Jakmile servlet dostane slovo, aplikace má k dispozici prom nnou session, pomocí které má p ístup k dat m. Poté, co práce servletu skon í, p ebírá práci op t ltr, potvrzí zm ny v databázi a pokud nastala výjimka (n jaká chyba, cizí klí, atd.), zavolá rollback na databázi. Na záv r ukon í svou innost a eká na dal²í poºadavek. public void dofilter(servletrequest request, ServletResponse response, FilterChain chain) { try { // start databázové transakce a vytvo ení session // sf je sessionfactory vytvo ená v init metod - singleton sf.getcurrentsession().begintransaction(); // zavolá dal²í filtry (pokra ování zpracování requestu) // nyní je v aplikaci v // org.hibernate.session session = sf.getcurrentsession(); // k dispozici session na práci s databází chain.dofilter(request, response); // potvrzení sf.getcurrentsession().gettransaction().commit(); } catch (Throwable ex) { if (sf.getcurrentsession().gettransaction().isactive()) { // pokus o rollback transakce po výjimce, pokud je transakce aktivní sf.getcurrentsession().gettransaction().rollback(); } } } Dal²í p íklad ltru, tentokrát autoriza ního, je uveden v kapitole na stran Business vrstva Základními kameny vrstvy jsou tzv. DTO (Data Transfer Objects) objekty, voln p eloºeno nosi e dat. Mají mnoºinu privátních atribut a poskytující p ístup k t mto atribut m pomocí ve ejných metod getter a setter. Viz obrázek 5.3 na následující stran Primitivní datové typy U DTO objekt jsou asto vyuºity místo javovských primitivních datových typ (int, double, boolean,... ) jejich objektové ekvivalenty (Integer, Double, Boolean). To má výhodu v tom,

73 KAPITOLA 5. IMPLEMENTACE 57 Obrázek 5.3: Business vrstva (doménový model) a integra ní vrstva. Plná ²ipka zna í pouze jak íst vztah pro lep²í orientaci v diagramu. ipka u asociace zna í pr chodnost (navigability), tedy ºe t ída typu A je sou ástí t ídy typu B jako atribut A : a, neboli t ída typu A neví nic o t íd typu B.

74 58 KAPITOLA 5. IMPLEMENTACE ºe lze dob e simulovat integritní omezení null / not null tak, ºe mohou nabývat hodnot null. Hibernate konverzi mezi databázovými typy a javovskými typy za ídí sám. MySQL datový typ / Java datový typ - rozsah hodnot INTEGER / int nebo Integer - celé íslo od do TINYINT / byte nebo Byte - celé íslo od 0 do 255 VARCHAR / String - et zec znak TIMESTAMP / Date - datum s asem CHAR(1) / boolean nebo Boolean - logická hodnota pravda/nepravda (0/1, 't'/'f') Vztahy mezi t ídami - datové typy jako t ídy Rozdíl mezi rela ním modelem a objektovým modelem je nevýrazn j²í práv tady. Vztahy mezi tabulkami v rela ní databázi jsou dány primárními a cizími klí i. Naopak u objekt lze tyto vztahy vyjád it tím, ºe místo atributu, který by nesl íslo jako odkaz na jiný objekt/ ádek, pouºijeme p ímo objekt této t ídy. Správné namapování pak za ídí Hibernate podle p edpis v mapovacím souboru (viz kap na str. 11). S povolením lazy nahráváním dat pak nevadí ani výskyt instance t ídy v druhé instanci stejné t ídy (rekurze). CREATE TABLE users { id INTEGER NOT NULL AUTO_INCREMENT, id_superior INTEGER NOT NULL, id_department INTEGER NOT NULL } class User { Integer id; User superior; Department department; } I kdyº t ída User obsahuje atribut instance t ídy User, nenahrají se v²ichni nad ízení uºivatele, jak by se mohlo zdát. P íslu²ný nad ízený se nahraje aº v okamºiku, kdy program bude pot ebovat n jaký jeho atribut Business metody Vedle getter a setter m ºe DTO t ída obsahovat tzv. business metody, které pracují pouze s atributy t ídy a mohou pomáhat k ovládání objektu jiným zp sobem, neº gettery a settery T ída User / tabulka users atribut {datový typ, null nebo not null, primární klí PK, cizí klí FK} - popis atributu id {Integer, not null, A, N} - jedine ný identikátor uºivatele lft {Integer, not null, N, N} - atribut left pro algoritmus z kap rgt {Integer, not null, N, N} - atribut right pro algoritmus z kap level {Integer, not null, N, N} - úrove uºivatele v hierarchii personalnumber {String, not null, N, N, unique} - osobní íslo ve rm, p ihla²ovací údaj rstname {String, not null, N, N} - jméno uºivatele

75 KAPITOLA 5. IMPLEMENTACE 59 lastname {String, not null, N, N} - p íjmení uºivatele {String, not null, N, N, unique} - uºivatele password {String, not null, N, N} - heslo uºivatele, zakódováno pomocí MD5 comments {String, null, N, N} - poznámka k uºivateli role {Byte, not null, N, N} - volitelná role uºivatele, admin, referent, N-RLZ lastlogin {Date, not null, N, N} - as posledního p ihlá²ení createtime {Date, not null, N, N} - as vytvo ení uºivatele hits {Integer, not null, N, N} - po et p ihlá²ení uºivatele active {Boolean, not null, N, N} - uºivatel je/není aktivní superior {User, not null, N, A} - nad ízený uºivatele, kdyº this.id == superior.id, nemá nad ízeného ocer {User, not null, N, A} - referent uºivatele v otázce lidských zdroj position {Position, not null, N, A} - funkce uºivatele v podniku workplace {Workplace, null, N, A} - pracovi²t uºivatele v podniku, volitelné department {Department, not null, N, A} - odd lení uºivatele v podniku businessmetoda(parametry) {návratový datový typ} - popis metody getfullname {String} - celé jméno uºivatele, vrací slou ení et zc personalnumber + ", "+ lastname + ", "+ firstname getfullposition {String} - celé umíst ní uºivatele v podniku, vrací slou ení et zc position + ", "+ workplace + ", "+ department addhit {void} - náv²t vnost se zvý²í o 1 isadmin {boolean} - pokud role == 3 nebo 4, vrací true ismhr {boolean} - pokud role == 1, vrací true isocer {boolean} - pokud role == 2 nebo 4, vrací true setnone(boolean) {void} - nastaví role = 0, uºivatel nemá ºádnou vedlej²í roli setmhr(boolean) {void} - nastaví role = 1, uºivatel má roli N-RLZ setocer(boolean) {void} - nastaví role = 2 pokud není adminem, nastaví role = 4 pokud je adminem, uºivatel má roli referent setadmin(boolean) {void} - nastaví role = 3 pokud není referentem, nastaví role = 4 pokud je referentem, uºivatel má roli admin setoceradmin(boolean) {void} - nastaví role = 4, uºivatel je referentem a adminem zárove T ída Petition / tabulka petitions atribut {datový typ, null nebo not null, primární klí PK, cizí klí FK} - popis atributu id {Integer, not null, A, N} - jedine ný identikátor ºádosti employee {User, not null, N, A} - uºivatel, kterého se týká ºádost form {Form, not null, N, A} - formulá, který ºádost obsahuje, ²ablona pro deserializaci dat data {String, not null, N, N} - serializovaná data ºádosti createtime {Date, not null, N, N} - as vytvo ení ºádosti discusstime {Date, not null, N, N} - as projednání ºádosti se zam stnancem

76 60 KAPITOLA 5. IMPLEMENTACE conrms {List<Confirm>, not null, N, N} - seznam v²ech schválení ºádosti T ída Conrm / tabulka conrms id {Integer, not null, A, N} - jedine ný identikátor schválení idpetition {Integer, not null, N, A} - cizí klí odkazující na ºádost, zde není t eba vytvá et objekt Petition, protoºe se se schváleními pracuje prost ednictvím ºádosti employee {User, not null, N, A} - manaºer, který ºádost podal, schválil, zamítnul state {Integer, not null, N, N} - stav schválení, stav ºádosti je dán stavem posledního schválení comments {String, null, N, N} - d vod podání ºádosti nebo poznámka ke schválení/zamítnutí consult {Boolean, not null, N, N} - ºádá-li manaºer o konzultaci s odd lením lidských zdroj conrmlevel {Integer, not null, N, N} - index ur ující pozici schválení pro konstrukci indexovaného seznamu schválení v t íd Petition (ºádosti) createtime {Date, not null, N, N} - as vytvo ení schválení T ída Form / tabulka forms id {Integer, not null, A, N} - jedine ný identikátor formulá e title {String, not null, N, N} - název formulá e shorttitle {String, null, N, N} - alternativní název formulá e path {String, not null, N, N} - název souboru formulá e locale {String, not null, N, N} - lokalizace formulá e active {Boolean, not null, N, N} - formulá je/není aktivní createtime {Date, not null, N, N} - as vytvo ení schválení business metoda: getpathwithlocale {String} - vrátí jméno formulá e z et zeno s lokalizací, coº je plný název souboru T ídy Position, Workplace a Department Jde o tzv. íselníky. Obsahují pouze identika ní íslo a hodnotu, p ípadn n jakou dopl ující informaci. V²echny t i t ídy mají stejné atributy. id {Integer, not null, A, N} - jedine ný identikátor name {String, not null, N, N} - hodnota íselníku secondname {String, null, N, N} - alternativní hodnota íselníku comments {String, null, N, N} - poznámka Zm na integritního omezení ve fyzickém modelu Aby byly vyuºity maximáln schopnosti frameworku Hibernate, musela být n která referen ní a doménová integritní omezení odstran na. Nap íklad, referen ní integrita cizího klí e u atributu id_petition v tabulce confirms a doménová integrita not null u stejného atributu. D vod je ten, ºe pokud se objektovým p ístupem vytvo í objekt Confirm (schválení), který se následn vloºí jako dal²í prvek do seznamu confirms v objektu Petition (vý²e uvedený p íklad

77 KAPITOLA 5. IMPLEMENTACE 61 je vysv tlen v kapitole 2.5.1), tak po potvrzení zm n musí mít Hibernate moºnost uloºit do cizího klí e hodnotu null. V prvním kroku totiº vytvo í p íkaz INSERT pro vloºení objektu Confirm a aº v druhé kroku pomocí p íkazu UPDATE naváºe toto schválení k p íslu²né ºádosti správným vypln ním atributu id_petition. Pro tomu tak je, nevím. Domnívám se v²ak, ºe e²ení se zachováním integritních omezení existuje. Jen je pot eba více pochopit framework Hibernate. Z toho plyne, ºe v tomto stavu by m la pracovat s databází pouze tato aplikace (prost ednictvím Hibernate) a ºádná jiná. 5.7 Integra ní vrstva Vrstva obsahuje objekty, které mají metody p istupující k dat m, tzv. Data Access Objects (DAO). Pokud pot ebuje vy²²í vrstva data získat nebo data uloºit, musí pouºít tyto objekty. V aplikaci jsou t i DAO objekty, a to DAO objekt pro uºivatele, pro ºádosti spolu se schváleními a pro formulá e (²ablony formulá ). Viz obrázek 5.3 na stran 57. Pokud chce n jaký Backing bean p istoupit k dat m, zkonstruuje p íslu²ný DAO objekt a poté m ºe pouºívat jeho metody. Metody DAO objekt v t²inou vyhazují výjimky, jejichº zpracování je na Backing beanu v aplika ní vrstv. P íklad na tení uºivatele pomocí objektu DAO: User newsuperior; UserDAO uc = new UserDAO(); try { // na tu uºivatele newsuperior = uc.getuser(selectedidsuperior); } catch (ObjectNotFoundException e) { // uºivatel nenalezen return Constants.FAILURE_OUTCOME; } catch (InfrastructureException ie) { // chyba p pojení s databází return Constants.ERROR_OUTCOME; } Nutnost pouºití nativního SQL v aplikaci - p ípad 1 Kapitola 2.5 na stran 11 ukázala sílu frameworku Hibernate. Tento framework získává ím dál v t²í popularitu a to i p esto, ºe jeho u ící k ivka je velmi protáhlá. Skute n, nau it se vyuºívat v²ech schopností není na pár týdn. Existuje výborná publikace [2], jejíº spoluautor Gavin King je tv rcem frameworku, a která popisuje v t²inu princip. Ukázkou toho, jak se Hibernate úsp ²n brání proniknutí do svých taj, je situace, na kterou jsem nakonec musel pouºít nativní SQL. Netvrdím, ºe neexistuje elegantní e²ení pouze s pomocí Hibernate. Uvaºujme p íklad, kdy je pot eba zobrazit tabulku ºádostí a na kaºdém ádku zobrazit také jméno zam stnance, jehoº se ºádost týká. Je to spojení dvou tabulek. Viz tab zadost.id zadost.data uzivatel.jmeno 2 zm na úvazku Jan Novák 23 zm na doby Petr Marek 43 zm na doby Kate ina Stará Pomocí nativního SQL sta í jediný dotaz: Tabulka 5.1: Tabulka ºádostí a jejich zam stnanc SELECT z.id AS id, z.data AS data, u.jmeno AS zamestnanec FROM zadosti z, uzivatele u WHERE z.id_zamestnanec = u.id;

78 62 KAPITOLA 5. IMPLEMENTACE Pokud je v²ak pouºit d íve uvedený doménový model (viz obr. 5.3 na str. 57) a situace by t eba vypadala tak, ºe tabulka zadosti obsahuje 3 záznamy a cht li bychom dosáhnout výsledku jako v tab. 5.1: List<Zadost> zadosti = zadostdao.getvsechnyzadosti(); // vrátí v²echny ºádosti, v HQL: "from Zadost" for (Zadost zadost : zadosti) { System.out.println(zadost.getId() + " " + zadost.getdata() + " " + zadost.getzamestnanec().getjmeno()); } Potom by Hibernate vykonal 4 SQL dotazy: SELECT * FROM zadosti; SELECT * FROM uzivatele WHERE uzivatele.id =?1; SELECT * FROM uzivatele WHERE uzivatele.id =?2; SELECT * FROM uzivatele WHERE uzivatele.id =?3; Jsou zde dotazy navíc. První p íkaz na te v²echny ºádosti. Následují t i p íkazy pro na t ní kaºdého zam stnance. Pro n ºádostí by to bylo 1 + n dotaz! Je-li pouºito lazy dotazování, je pro sloºit j²í dotazy po et SQL dotaz je²t vy²²í, neº 1 + n. To je zp sobeno tím, ºe existuje-li vztah 1:N mezi dv ma tabulkami a odkazuje-li více prvk jedné tabulky na tentýº prvek druhé tabulky, Hibernate data necachuje a vykoná stejný dotaz znovu. Je v²ak pot eba zd raznit, ºe s nejv t²í pravd podobností jde v²e ud lat v Hibernate jediným dotazem. Pouºil jsem tedy jeden nativní SQL dotaz. Na²t stí Hibernate podporuje velmi dobré mapování dat do DTO objekt a není pot eba ºádné extra zpracování SQL dotazu: List zadostiauzivatele = session.createsqlquery( SELECT {z.*}, {u.*} FROM zadosti z, uzivatele u WHERE z.id_zamestnanec = u.id) // klasický SQL dotaz.addentity("z", Zadost.class) // namapování tabulek na DTO objekty.addentity("u", Uzivatel.class).list; V tomto p ípad je výsledkem seznam polí ( ádk ), z nichº kaºdé obsahuje tolik objekt, kolik jsme dotazem ºádali, zde konkrétn 2. P etypováním se získají pot ebné instance: for (int i = 0; i < zadostiauzivatel.size(); i++) { Object[] radek = (Object[]) zadostiauzivatele.get(i); Zadost zadost = (Zadost) radek[0]; Uzivatel zamestnanec = (Uzivatel) radek[1]; System.out.println(zadost.getId() + " " + zadost.getdata() + " " + zamestnanec().getjmeno()) } Nutnost pouºití nativního SQL v aplikaci - p ípad 2 Druhý p ípad, kdy jsem pouºil nativní SQL, byla manipulace se stromovou hierarchií v rela ní databázi. Tato manipulace bude popsána v kapitole P ístupový objekt UserDAO Objekt UserDAO integra ní vrstvy slouºí pro p ístup k uºivatel m - zam stnanc m. Jsou zde metody pro získání uºivatele, pro jeho vloºení, úpravu nebo vymazání z databáze. Dále také celá sada metod získávající seznam uºivatel. V²echny tyto metody vrací seznam objekt typu User podle r zných kritérií. Kaºdá z nich volá privátní metodu getusers() s jinými hodnotami parametr. Objekt je znázorn n v diagramu na obr. 5.3 na str. 57.

79 KAPITOLA 5. IMPLEMENTACE 63 Hlavní ást objektu v²ak spo ívá v mnoºin metod pro manipulaci s hierarchickou strukturou uºivatel Stromy a hierarchie v SQL pomocí Nested Set Model of Hierarchies SQL je jazyk zaloºený na mnoºinách (plochých rela ních tabulkách), z toho plyne, ºe reprezentace stromové datové struktury bude pon kud problematická. Existuje mnoho p ístup, jak hierarchii v rela ní databázi uloºit. První m ºe být zp sob naivní, kdy si kaºdý potomek pamatuje pouze odkaz na rodi e. P i výpisu v²ech d tí, vnuk, pravnuk v²ak nastává problém. Pouºijeme-li rekurzi, bude dotaz do databáze minimáln tolik, kolik je hloubka podstromu, jehoº ko enem je rodi. Podobná úskalí lze o ekávat, chceme-li vypsat v²echny nad azené uzly nebo zjistit úrove ur itého uzlu v hierarchii. Jeden ze sostikovaných postup je tzv. Nested Set Model of Hierarchies, jinde nazývaný traverzování kolem stromu (Modied Preorder Tree Traversal Algoritmus), kdy je po et dotaz do databáze vºdy konstantní. Hierarchický model je zaloºen na jednoduché my²lence. Kaºdý uzel si pamatuje dv ísla left a right. Tato ísla vzniknou procházením stromu do hloubky DFS 5 a za ínají od jedni ky, kterou má atribut left ko ene stromu. Viz obrázek 5.4. Obrázek 5.4: Datová struktura strom s atributy left a right. Pravá ást: vloºení nového listu. Nyní je získání v²ech potomk uzlu Cyril jednoduché: SELECT * FROM users WHERE left > 4 AND right < 11 ORDER BY left Nad azené uzly k uzlu Evºen: SELECT * FROM users WHERE left < 7 AND right > 8 ORDER BY left Úprava stromu je sloºit j²í, p esto z ejmá. Strom musí být po kaºdém zásahu konzistentní. Nap íklad, vloºíme-li nový uzel, je pot eba upravit hodnoty left a right celého stromu. Nemusíme v²ak volat náro ný algoritmus DFS, jak by se mohlo zdát. Sta í jednoduchými SQL p íkazy p i íst +2 k atributu left u v²ech uzl, které mají left v t²í neº rodi hodnotu right, a zárove p i íst +2 k atributu right u v²ech uzl, které mají right vet²í nebo rovno hodnot rodi ova right (tedy p i íst +2 k right i u rodi e). Nakonec vloºíme nový uzel, jehoº left = rodi.right a right = rodi.right + 1. Více viz pravá ást obrázku 5.4 a následující kód: 5 z angl. Depth-rst search

80 64 KAPITOLA 5. IMPLEMENTACE UPDATE users SET left = left + 2 WHERE left > 6 UPDATE users SET right = right + 2 WHERE right >= 6 INSERT INTO users (name, left, right) VALUES ('Gustav', 6, 7) Zevrubný popis metody v etn v t²iny myslitelných dotaz a manipulací s hierarchií lze nalézt v publikaci [3]. V následujících kapitolách je popsáno n kolik metod pracujících s hierarchií. Poznámka: Textové et zce typu String pro SQL p íkazy jsou sestrojeny jako z et zení nem nných (statických) segment SQL (pro lep²í rozli²ení v uvozovkách kurzívou) spolu s (dynamickými) Java p íkazy vracející String (mimo uvozovky, bez kurzívy) Metoda deletesubtree Metoda odstra ující bu list stromu nebo celý podstrom. V samotné aplikaci se nesmí odstranit uºivatel kompletn z databáze. Mohou na n j být navázány r zné ºádosti. Jeho identikace pomocí osobního ísla musí být uchována. Vymazaným uºivatel m je jednodu²e nastaven atribut left na nula. "update users set lft = 0 where lft between " + user.getlft() + " and " + user.getrgt() "update users set lft = lft - " + (user.getrgt() - user.getlft() + 1) + " where lft > " + user.getlft() "update users set rgt = rgt - " + (user.getrgt() - user.getlft() + 1) + " where rgt > " + user.getlft() V DTO objektu user je uloºen odstra ovaný uºivatel. Metoda getlft() vrací jeho hodnotu left a metoda getrgt() pak hodnotu right. Metoda deletesubtree nejd íve nastaví uºivateli a v²em jeho pod ízeným left na nula. Tím je odstraní z hierarchie. Druhým p íkazem v²em uºivatel m, kte í mají left v t²í neº odstra ovaný, ode te od jejich left po et atribut right a left v²ech odstra ovaných, coº je rozdíl t chto hodnot u ko ene podstromu. Podobn upraví right atribut u uºivatel, kte í mají right v t²í neº left odstra ovaného Metoda deletemanager Jde o metodu, ktará odstraní uzel uvnit stromu a v²echny jeho p ímé pod ízené p i adí jeho nad ízenému. Neboli, otec zem el, o syny se postará d da. "update users set id_superior = " + user.getsuperior().getid() + " where lft > " + user.getlft() + " and rgt < " + user.getrgt() + " and levl = " + (user.getlevel() + 1) "update users set lft = lft - 1, rgt = rgt - 1, levl = levl - 1 where lft > " + user.getlft() + " and rgt < " + user.getrgt() "update users set lft = lft - 2 where lft > " + user.getrgt() "update users set rgt = rgt - 2 where rgt > " + user.getrgt() "update users set left = 0 where id = " + user.getid() První p íkaz nastaví u p ímých pod ízených id nad ízeného na nad ízeného odstra ovaného. Dále se ode te v²em pod ízeným (i nep ímým) od atribut left a right hodnota -1, protoºe je pot eba vynechat práv jednu hodnotu left odstra ovaného. Podobn v²em uºivatel m, kte í mají left a right v t²í neº right odstra ovaného (jinak e eno, ti kte í jsou napravo od n j), se t etím a tvrtým p íkazem ode te od jejich left a

81 KAPITOLA 5. IMPLEMENTACE 65 right hodnota -2. Je to proto, ºe zde je t eba vedle hodnoty left odstra ovaného vynechat i hodnotu right. Poslední p íkaz nastaví u odstra ovaného left na nula Metoda transfersubtree Metoda p esune list nebo celý podstrom pod nový uzel. Nezabrání v²ak p esunu stromu do svého potomka, tomu je pot eba zabránit ve vy²²í vrstv. V objektu user je uloºen ko en p esouvaného podstromu, v objektu newsuperior pak uºivatel, pod kterého bude podstrom p esunut. Metoda si uloºí pot ebné hodnoty: Integer oldlft = user.getlft(); Integer oldrgt = user.getrgt(); Integer newrgt = newsuperior.getrgt(); Následuje výpo et nového right newrgt uºivatele newsuperior. Pokud je ko en p esouvaného podstromu p ed novým ko enem, bude mít nový ko en right men²í o 2*po et uzl p esouvaného stromu. Pokud je po adí obrácené, není pot eba p epo ítávat newrgt: if (newsuperior.getrgt() > oldrgt) { newrgt -= (oldrgt - oldlft + 1); } Dále postupujeme podle této my²lenky. P esouvaný podstrom do asn p esuneme úpln dozadu, zacelíme vzniklou díru u starého vedoucího, vytvo íme novou, stejn velkou díru u nového vedoucího a p esuneme podstrom zezadu pod nového vedoucího. Postup ilustruje obrázek 5.5. Programov je to takto: zjistí se maximální hodnota right v tabulce a celý p esouvaný podstrom se p esune nakonec hierarchie, za maxrgt. V tabulce uºivatel tím do asn vznikne úpln nový strom. Je²t se musí správn nastavit v²echny left, right a level atributy: Integer maxrgt = getmax("rgt "); "update users set lft = lft + " + (maxrgt - oldlft + 1) + ", rgt = rgt + " + (maxrgt - oldlft + 1) + ", levl = levl - " + oldlevel + " where lft between " + oldlft + " and " + oldrgt Dále je t eba upravit v²echny uºivatele napravo od p esouvaného stromu, stejn jako v kapitole To, ºe p íkaz upraví i do asn uloºený p esouvaný podstrom úpln napravo, je správn : "update users set lft = lft - " + (oldrgt - oldlft + 1) + " where lft > " + oldlft "update users set rgt = rgt - " + (oldrgt - oldlft + 1) + " where rgt > " + oldlft Te jsme zacelili díru, která vznikla odebráním podstromu jeho bývalému nad ízenému a nyní musíme vytvo it stejnou díru u nového nad ízeného. Jinými slovy, je t eba upravit zbytek napravo od nového vedoucího: "update users set lft = lft + " + (oldrgt - oldlft + 1) + " where lft > " + newrgt "update users set rgt = rgt + " + (oldrgt - oldlft + 1) + " where rgt >= " + newrgt Nakonec uº sta í pouze navázat ko en podstromu na nového vedoucího a vloºit do asn uchovaný podstrom zezadu hierarchie na správné místo tím, ºe pat i n upravíme atributy left, right a level: "update users set id_superior = " + newidsuperior + " where id = " + id "update users set lft = lft - " + (maxrgt - newrgt + 1) + ", rgt = rgt - " + (maxrgt - newrgt + 1) + ", levl = levl + " + (newlevel + 1) + ", id_officer = " + newidofficer + " where lft > " + maxrgt Pot ebujeme tedy 7 p íkaz UPDATE.

82 66 KAPITOLA 5. IMPLEMENTACE Obrázek 5.5: Metoda transfersubtree p esune list nebo celý podstrom pod nový uzel Metoda transfermanager Metoda transfermanager() volá metodu deletemanager(). Tím se manaºer dostává do odstran ných uºivatel (atribut left má roven nule) a jeho pod ízení jsou p e azeni k jeho nad ízenému. Poté se zavolá metoda na obnovení odstran ného uºivatele restoreuser(), která jej za adí pod nového vedoucího. deletemanager(user); restoreuser(user, superior); Ostatní metody Vý²e byly popsány základní metody. Pomocí nich lze konstruovat sloºit j²í p ípady. Nap íklad, chceme-li p esunout manaºera pod jednoho vedoucího a jeho pod ízené pod jiného vedoucího, lze to vytvo it takto: UserDAO uc = new UserDAO(); transfereduser = uc.transfersubtree(transfereduser, newsuperiorforsubordinates); uc.transfermanager(transfereduser, newsuperiorformanager); První p íkaz p esune celý podstrom i s p e azovaným pod nového vedoucího pod ízených. Následn se je²t p esune manaºer pod jeho nového vedoucího P ístupový objekt PetitionDAO Objekt je ur ený pro p ístup k ºádostem a k jejím schválením. Obsahuje podobné metody, jako UserDAO, tedy metody pro na tení, uloºení a smazání ºádosti. Dále metodu pro na tení schválení. Metody pro mazání a vkládání schválení nejsou pot eba, protoºe to zabezpe í Hibernate pomocí metod pro ºádost. Kaºdé schválení je sou ástí n jaké ºádosti. Dále jsou zde metody získávající seznamy ºádosti (spolu s jejími schváleními) podle r zných kritérií (viz diagram na obrázku 5.3 na stran 57). V²echny tyto metody pouºívají soukromou metodu getpetitions().