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

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

iv

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

vi

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 12. 1. 2009

.............................................................

vii

viii

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 applications 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

x

Obsah Seznam obrázk·

xvi

Seznam tabulek

xvii

1

Úvod

1

2

Pouºité technologie

3

2.1 2.2

2.3

2.4 2.5 2.6 2.7

2.8

3

Technologie pro návrh a analýzu . . . . . . . 2.1.1 UML a Visual Paradigm for UML 6.3 2.1.2 Unied Process . . . . . . . . . . . . . Java Enterprise Edition . . . . . . . . . . . . 2.2.1 Platforma Java a JDK . . . . . . . . . 2.2.2 Java EE . . . . . . . . . . . . . . . . . 2.2.3 Servlety a JSP . . . . . . . . . . . . . 2.2.4 Apache Tomcat . . . . . . . . . . . . . 2.2.5 IDE NetBeans . . . . . . . . . . . . . MVC Webové Java frameworky . . . . . . . . 2.3.1 Návrhové vzory . . . . . . . . . . . . . 2.3.2 Model-View-Controller . . . . . . . . . 2.3.2.1 Model 1 . . . . . . . . . . . . 2.3.2.2 Model 2 . . . . . . . . . . . . 2.3.3 Rozd¥lení webových Java framework· MVC framework JavaServer Fages . . . . . . 2.4.1 P°íklad . . . . . . . . . . . . . . . . . 2.4.2 Knihovna Apache MyFaces Tomahawk ORM framework Hibernate . . . . . . . . . . 2.5.1 P°íklad . . . . . . . . . . . . . . . . . Rela£ní databáze MySQL . . . . . . . . . . . XML technologie . . . . . . . . . . . . . . . . 2.7.1 Knihovna DOM4J . . . . . . . . . . . 2.7.2 XML Schema . . . . . . . . . . . . . . 2.7.3 XSL - XSLT a XPath . . . . . . . . . Technologie na klientské stran¥ . . . . . . . . 2.8.1 HTML . . . . . . . . . . . . . . . . . . 2.8.2 CSS . . . . . . . . . . . . . . . . . . . 2.8.3 JavaScript (ECMAScript) . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

Úvodní studie

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8

Sou£asný stav . . . . . . . . . . . . Deklarace zám¥ru . . . . . . . . . . Odborný £lánek . . . . . . . . . . . 3.3.1 Hlavní funkce systému . . . 3.3.2 Názorný pr·b¥h schvalování Akté°i . . . . . . . . . . . . . . . . Funk£ní poºadavky . . . . . . . . . Nefunk£ní poºadavky . . . . . . . . Analýza rizik . . . . . . . . . . . . Slovník pojm· . . . . . . . . . . . .

3 3 3 3 3 4 4 4 4 4 4 5 5 5 5 6 7 10 11 11 14 15 15 15 16 18 18 18 18 19

. . . . . . . . . . . . . . . . . . . . ºádosti . . . . . . . . . . . . . . . . . . . . . . . . . xi

. . . . . . . . . .

19 19 19 20 20 21 21 23 24 24

4

Analýza a návrh °e²ení

4.1 4.2 4.3

4.4 4.5

27

Stavový diagram ºádostí . . . . . . . . . . . . . . . . . . . . . . . . . . . Akté°i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . P°ípady uºití . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Klí£ová slova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Správa ºádostí . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2.1 UCZ01 Prohlíºet seznam ºádostí pod°ízených uºivatel· 4.3.2.2 UCZ02 Prohlíºet seznam v²ech ºádostí . . . . . . . . . . 4.3.2.3 UCZ03 Prohlíºet seznam ºádostí zam¥stnance . . . . . . 4.3.2.4 UCZ04 Tisknout seznamy ºádostí . . . . . . . . . . . . 4.3.2.5 UCZ05 Prohlíºet detail ºádosti . . . . . . . . . . . . . . 4.3.2.6 UCZ06 Tisknout detail ºádosti . . . . . . . . . . . . . . 4.3.2.7 UCZ07 Zobrazit volby . . . . . . . . . . . . . . . . . . . 4.3.2.8 UCZ08 Zvolit a vyplnit ºádost . . . . . . . . . . . . . . 4.3.2.9 UCZ09 Vytvo°it ºádost . . . . . . . . . . . . . . . . . . 4.3.2.10 UCZ10 Podat ºádost . . . . . . . . . . . . . . . . . . . . 4.3.2.11 UCZ11 Zru²it ºádost . . . . . . . . . . . . . . . . . . . . 4.3.2.12 UCZ12 Schválit ºádost . . . . . . . . . . . . . . . . . . . 4.3.2.13 UCZ13 Zamítnout ºádost . . . . . . . . . . . . . . . . . 4.3.2.14 UCZ14 Zaevidovat ºádost . . . . . . . . . . . . . . . . . 4.3.2.15 UCZ15 Poslat zprávu . . . . . . . . . . . . . . . . . . . 4.3.3 Správa uºivatel· . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3.1 UCU01 P°ihlásit . . . . . . . . . . . . . . . . . . . . . . 4.3.3.2 UCU02 Odhlásit . . . . . . . . . . . . . . . . . . . . . . 4.3.3.3 UCU03 Prohlíºet seznam pod°ízených uºivatel· . . . . . 4.3.3.4 UCU04 Prohlíºet seznam nad°ízených uºivatel· . . . . . 4.3.3.5 UCU05 Prohlíºet seznam v²ech uºivatel· . . . . . . . . 4.3.3.6 UCU06 Tisknout seznamy uºivatel· . . . . . . . . . . . 4.3.3.7 UCU07 Prohlíºet detail uºivatele . . . . . . . . . . . . . 4.3.3.8 UCU08 Tisknout detail uºivatele . . . . . . . . . . . . . 4.3.3.9 UCU09 Upravit heslo . . . . . . . . . . . . . . . . . . . 4.3.3.10 UCU10 Nastavit zástupce . . . . . . . . . . . . . . . . . 4.3.3.11 UCU11 Vloºit uºivatele . . . . . . . . . . . . . . . . . . 4.3.3.12 UCU12 Upravit uºivatele . . . . . . . . . . . . . . . . . 4.3.3.13 UCU13 P°e°adit uºivatele . . . . . . . . . . . . . . . . . 4.3.3.14 UCU14 Smazat uºivatele . . . . . . . . . . . . . . . . . 4.3.3.15 UCU15 Zm¥nit N-RLZ . . . . . . . . . . . . . . . . . . 4.3.3.16 UCU16 Vytvo°it zprávu . . . . . . . . . . . . . . . . . . 4.3.3.17 UCU17 Poslat zprávu . . . . . . . . . . . . . . . . . . . 4.3.4 Správa formulá°· (²ablon formulá°·) . . . . . . . . . . . . . . . . 4.3.4.1 UCF01 Prohlíºet seznam formulá°· . . . . . . . . . . . 4.3.4.2 UCF02 Prohlíºet detail formulá°e . . . . . . . . . . . . 4.3.4.3 UCF03 Vloºit formulá° . . . . . . . . . . . . . . . . . . 4.3.4.4 UCF04 Smazat formulá° . . . . . . . . . . . . . . . . . . Matice pokrytí funk£ních poºadavk· . . . . . . . . . . . . . . . . . . . . ER konceptuální model . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 Popis entit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.2 Popis vztah· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.3 Popis atribut· state a role . . . . . . . . . . . . . . . . . . . . xii

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27 28 28 29 29 29 30 30 31 31 31 32 32 34 35 35 36 37 37 37 38 38 39 40 41 41 41 42 42 43 43 43 44 44 44 45 47 47 47 48 48 49 49 50 50 50 51 52

5

Implementace

5.1 5.2

5.3 5.4

5.5 5.6

5.7

5.8

5.9

6

53

Implementace p°ípad· uºití . . . . . . . . . . . . . . . . . . Tvorba formulá°· (²ablon formulá°·) . . . . . . . . . . . . . 5.2.1 Vytvo°ení ²ablony formulá°e uºivatelem . . . . . . . 5.2.2 Zavedení ²ablony formulá°e do systému . . . . . . . 5.2.3 Propojení ²ablony formulá°e se ºádostí . . . . . . . . Aplikace zaloºená na vrstvách . . . . . . . . . . . . . . . . . Fyzická vrstva . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Datový slovník . . . . . . . . . . . . . . . . . . . . . 5.4.2 Vztahy mezi tabulkami . . . . . . . . . . . . . . . . . 5.4.3 Integritní omezení . . . . . . . . . . . . . . . . . . . Persistentní vrstva . . . . . . . . . . . . . . . . . . . . . . . Business vrstva . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.1 Primitivní datové typy . . . . . . . . . . . . . . . . . 5.6.2 Vztahy mezi t°ídami - datové typy jako t°ídy . . . . 5.6.3 Business metody . . . . . . . . . . . . . . . . . . . . 5.6.4 T°ída User / tabulka users . . . . . . . . . . . . . . . 5.6.5 T°ída Petition / tabulka petitions . . . . . . . . . . . 5.6.6 T°ída Conrm / tabulka conrms . . . . . . . . . . . 5.6.7 T°ída Form / tabulka forms . . . . . . . . . . . . . . 5.6.8 T°ídy Position, Workplace a Department . . . . . . . 5.6.9 Zm¥na integritního omezení ve fyzickém modelu . . . Integra£ní vrstva . . . . . . . . . . . . . . . . . . . . . . . . 5.7.1 Nutnost pouºití nativního SQL v aplikaci - p°ípad 1 5.7.2 Nutnost pouºití nativního SQL v aplikaci - p°ípad 2 5.7.3 P°ístupový objekt UserDAO . . . . . . . . . . . . . . 5.7.3.1 Stromy a hierarchie v SQL pomocí Nested archies . . . . . . . . . . . . . . . . . . . . 5.7.3.2 Metoda deleteSubtree . . . . . . . . . . . . 5.7.3.3 Metoda deleteManager . . . . . . . . . . . 5.7.3.4 Metoda transferSubtree . . . . . . . . . . . 5.7.3.5 Metoda transferManager . . . . . . . . . . 5.7.3.6 Ostatní metody . . . . . . . . . . . . . . . 5.7.4 P°ístupový objekt PetitionDAO . . . . . . . . . . . . 5.7.5 P°ístupový objekt FormDAO . . . . . . . . . . . . . Aplika£ní vrstva . . . . . . . . . . . . . . . . . . . . . . . . . 5.8.1 Backing bean Visit . . . . . . . . . . . . . . . . . . . 5.8.2 Backing bean AuthenticationBean . . . . . . . . . . 5.8.3 Ostatní Backing beany . . . . . . . . . . . . . . . . . 5.8.4 Rekurzivní konstrukce hierarchické tabulky uºivatel· Prezenta£ní vrstva . . . . . . . . . . . . . . . . . . . . . . . 5.9.1 Bezpe£nost pomocí autoriza£ního ltru . . . . . . . . 5.9.2 Lokalizace . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Set Model of Hier. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

53 53 53 53 54 54 55 55 55 55 56 56 56 58 58 58 59 60 60 60 60 61 61 62 62

. . . . . . . . . . . . . . . .

63 64 64 65 66 66 66 67 67 67 67 68 68 69 70 70

Testování pouºitelnosti (Usability test)

6.1 6.2

Cíl testování . . . . . . . . . . . . Výb¥r uºivatel· - testujících . . . 6.2.1 P°edpoklady a poºadavky 6.2.2 P°edtestový dotazník . . . 6.2.3 Kone£ný výb¥r . . . . . .

. . . . .

. . . . .

. . . . .

71

. . . . .

xiii

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

71 71 71 71 71

6.3

6.4 6.5

Usability test . . . . . . . . . . . . . . 6.3.1 Nastavení testu (setup) . . . . 6.3.2 Úkoly . . . . . . . . . . . . . . 6.3.3 Výsledky testu . . . . . . . . . Problémy, °e²ení a potestový dotazník 6.4.1 Ostatní problémy . . . . . . . . Zhodnocení . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

72 72 72 73 74 75 76

7

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 C.2 C.3 C.4 C.5 C.6

Instalace prost°edí Java SE Runtime Environment (JRE) 6 Update 11 (leden 2009) Instalace kontejneru Apache Tomcat 6.0.18 (leden 2009) . . . . . . . . . . . . . . Instalace databáze MySQL 5.1.3 (leden 2009) . . . . . . . . . . . . . . . . . . . . Vytvo°ení databáze s tabulkami . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nahrání aplikace do kontejneru . . . . . . . . . . . . . . . . . . . . . . . . . . . . Spu²t¥ní aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

D Uºivatelská p°íru£ka

85 85 85 86 86 86 87

D.1 D.2 D.3 D.4 D.5

P°ihlá²ení uºivatele . . . . . . . . . . . . . . . . Navigace v aplikaci - hlavi£ka aplikace . . . . . Odhlá²ení uºivatele . . . . . . . . . . . . . . . . Role uºivatel· . . . . . . . . . . . . . . . . . . . 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

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

87 87 87 88 88 88 89 89 90 91 91 92 93 94 94 96 96 97 98 98 99

E.1 P°edtestový dotazník . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 E.2 Úkoly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 E.3 Potestový dotazník . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 F Obsah p°iloºeného CD

101

xiv

Seznam obrázk· 2.1 2.2 2.3

MVC model 2 v prost°edí JSP a Servlet·, vyp·j£eno z [7]. . . . . . . . . . . . . . 5 Strom komponent. Komponenty jsou zobrazeny do výsledného HTML pohledu. . 7 Porovnání fyzického rela£ního a doménového objektového modelu. . . . . . . . . . 12

3.1

Schéma schvalování personální ºádosti v podniku. . . . . . . . . . . . . . . . . . . 19

4.1 4.2 4.3 4.4 4.5

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 UCZ01. . . . . . . . . . . . . . . . . . . . . . . . . . . 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 UCZ08. . . . . . . . . . . . . . . . . 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 UCU07. . . . . . . . . . . . . . Sekven£ní diagram pro UCU11 Vloºit uºivatele. . . . . . . . . . . . . . . . . . . Návrh uºivatelského rozhraní - Vloºit nového uºivatele UCU11. . . . . . . . . . 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á°· UCF01. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. .

. 54 . 55

4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.23 4.24 5.1 5.2 5.3

5.4 5.5 5.6 5.7

27 28 29 30

. 31 . 32 . . . . . . . . . .

33 34 35 36 37 38 38 39 40 41

. . . .

41 42 45 46

. 46 . 47 . 48 . 51

. . . . .

57 63 66 69 69

D.1 Úvodní stránka aplikace s p°ihla²ovacím formulá°em. . . . . . . . . . . . . . . . . 87 D.2 Hlavi£ka aplikace spolu s volbami. . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 xv

D.3 D.4 D.5 D.6 D.7 D.8

P°íklad seznamu ºádostí spolu s ltrováním a stránkováním seznamu. . P°íklad detailu ºádosti. . . . . . . . . . . . . . . . . . . . . . . . . . . . P°íklad seznamu uºivatel· spolu s hierarchickým seznamem uºivatel·. P°íklad detailu uºivatele. . . . . . . . . . . . . . . . . . . . . . . . . . . Volby pro odstran¥ní manaºera z hierarchie uºivatel·. . . . . . . . . . Uºivatelské rozhraní formulá°e podle zdrojového kódu z kap. D.11.4. .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

88 89 90 90 92 97

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. 5.9.1 na str. 70. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

xvi

Seznam tabulek 3.1 3.2

Analýza rizik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Slovník pojm· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1

Matice pokrytí funk£ních poºadavk· . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.1

Tabulka ºádostí a jejich zam¥stnanc· . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.1 6.2

Výb¥r testujících na základ¥ p°edtestového dotazníku, viz p°íloha E.1. . . . . . . 72 Setup testu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

F.1 Obsah p°iloºeného CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

xvii

xviii

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 5.7.3.1). 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í

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.

KAPITOLA 2. POUITÉ TECHNOLOGIE

3

2 Pouºité technologie 2.1 2.1.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 21 . 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. 2.1.2

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 2.2.1

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: http://www.omg.org/technology/documents/formal/uml.htm

4 2.2.2


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, . . . ). 2.2.3

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. 2.2.4

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. 2.2.5

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. 2.3.1

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·.


2.3.2

5

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].

2.3.2.1

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. 2.3.2.2

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. 2.1. 2.3.3

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

6


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²úje °í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

http://cs.wikipedia.org/wiki/Framework


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). 2.4.1

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: http://forums.sun.com/forum.jspa?forumID=427

8


<%@ taglib prefix="f" uri="http://java.sun.com/jsf/core" %> <%@ taglib prefix="h" uri="http://java.sun.com/jsf/html" %> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> Prosím, p°ihla²te se
Prosím, p°ihla²te se

Uºivatelské jméno:

Heslo:

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;


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="http://java.sun.com/jsf/core" %> <%@ taglib prefix="h" uri="http://java.sun.com/jsf/html" %> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> Vítejte na zabezpe£ené stránce
Vítejte na zabezpe£ené stránce
Va²e jméno je:
P°ihlásil jste se v:

10


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 2008. Navigace a kongurace JSF se provádí v souboru faces-config.xml, který v na²em p°ípad¥ vypadá takto: /login.jsp #{userBean.login} success /secret.jsp #{userBean.login} failure /login.jsp <managed-bean> <managed-bean-name>userBean <managed-bean-class>myPackage.UserBean <managed-bean-scope>request

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. 2.4.2

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 1.1.8 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 JSCookMenu 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: http://jscook.yuanheng.org/JSCookMenu/


2.5

11

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. 2.5.1

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) );

12


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 private private private

Integer id; Uzivatel zamestnanec; List<Schvaleni> schvaleni = new ArrayList()<Schvaleni>; 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) 2) 3) 4) 5)


13

6) <many-to-one class="Uzivatel" column="id_zamestnanec" name="zamestnanec"/> 7) <list cascade="all" name="schvaleni"> 8) 9) 10) 11) <property column="data" name="data"/> 12) 13)

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í

14


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 £. 3. 2.6

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 ANSISQL. 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.


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í5 . 2.7

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 kongurá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: p·vodní navrhovaný

Element je ko°enovým elementem, má navíc atribut title. Následují dva elementy , které mají volitelný atribut size a povinný element . 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. 2.7.1

Knihovna DOM4J

V aplikaci je pouºita externí knihovna DOM4J verze 1.6.1 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. 2.7.2

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í: http://www.hibernate.org/80.html

16


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: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:element name="group"> <xs:complexType> <xs:choice minOccurs="1" maxOccurs="6"> <xs:element ref="inputDate"/> <xs:element ref="inputText"/> <xs:attribute name="title" type="xs:string"/>

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. 2.7.3

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·.


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="/ "> <xsl:if test="string(@title) "> <xsl:for-each select="/group/inputText "> <xsl:variable name="size"> <xsl:if test="string(@size )"> <xsl:value-of select="@size "/> <xsl:if test="not(string(@size)) "> <xsl:value-of select="60"/>

{@title }

{label/text() }

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.

18


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 2.8.1

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
, ale vºdy pouze
), nevypadá, ºe by se blíºil konec HTML. Framework JSF v aplikaci generuje klasické HTML, ne XHTML. 2.8.2

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. 2.8.3

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°. RichFaces6 ), 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

http://www.jboss.org/jbossrichfaces/

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

20


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.

3.3.1

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²úje (v£etn¥ jejich vytvo°ení a validace) administrátor nebo N-RLZ.

3.3.2

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 emailem 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.


3.4

21

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. (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. Zam¥stnanec

(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. Manaºer

(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. N-RLZ

(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. Referent

Admin

(angl. Admin, volitelná role) - Administrátor, spravuje systém a tvo°í formulá°e.

(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.

Zástupce manaºera

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

22


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, email, W 19. Zpráva o zamítnutí ºádosti bude poslána zadavateli (manaºerovi) a týkajícímu se zam¥stnanci, email, 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


23

30. 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, email, 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óvat 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

- Java EE (servlety, JSP, MVC framework JSF), knihovna tag· Apache MyFaces Tomahawk, ORM framework Hibernate, DOM4J (XML, XSD, XSL), MySQLConnector Implementace 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

prohlíºe£em HW Server Kapacita

- standardní kancelá°ský osobní po£íta£ s p°ístupem na podnikovou sí´ s webovým - CPU 2GHz a více, opera£ní pam¥´ 2GB a více, pevný disk SCSI 10000 otá£ek

- 1000 - 5000 uºivatel·

Dostupnost

- nonstop, z remní sít¥

Shoda se standardy

protokol·

- technologie v Java EE spl¬ují standardy zabezpe£ení a standardy

- 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 Zabezpe£ení

24 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 Nedostatky

ve

znalosti

kategorie

pravd. [%]

dopad (1-4)

RMMM - plán zmírn¥ní, monitorování a °ízení rizik

projektové

60

2

dostate£né

ORM frameworku Hiber-

studium

technické

doku-

mentace a kvalitních knih

nate Nejasná

p°edstava

obchodní

50

2

£asté konzultace b¥hem celého vývoje

technické

30

3

striktn¥

zákazníka co vlastn¥ chce, zm¥ny poºadavk· Nedostatky

v

analýze,

nepochopení metodiky patný

odhad

dodrºovat

metodiku

UP

a

pouºívat UML

velikosti,

obchodní

20

2

sloºitosti

studovat nápady

algoritmy, dát

p°ed

p°ednost

vlastními

osv¥d£eným

metodám patné

zabezpe£ení

ap-

projektové

10

4

likace

MD5 na hesla, rozd¥lení p°ístupu do adresá°· podle rolí, pouºití autoriza£ního ltru testující p°ístup

Chyby v implementaci Sloºitost

aplikace,

ne-

projektové

15

2

testování budoucími uºivateli, °e²itelem

obchodní

15

2

dokumentace

obsahující

p°íklady

a

dostatky v dokumentaci,

postupy, testováním odhalit sloºitosti,

sloºitá dokumentace

konzultace se zákazníkem

Knihovny obsahují

t°etích

stran

technické

25

1

implementa£ní

pouºití knihoven s dobrou dokumentací a s vysokou pouºívaností

chyby (bugy) Nezavedení

aplikace

v

obchodní

25

1

podniku (nap°. p°i zm¥n¥

management podniku o aplikaci poºádal

managementu) Ztráta/nezálohování

dat

technické

5

4

projektové

20

1

p°i vývoji Zm¥na technologie v im-

zálohování funk£ních £ástí aplikace na samostatné nosi£e dat

plementaci (XForms)

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

patný odhad zatíºení ap-

projektové

5

3

likace p°i b¥hu, velikosti

pouºita Java EE pro podnikové aplikace, optimalizace dotaz· do databáze

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.

25


pojem pouºitý v projektu

význam

synonyma

admin

Role správce informa£ního systému. Tvo°í a spravuje for-

administrátor

mulá°e. aktér

Je vyjád°ením role p°id¥lené k p°edm¥tu, který bezprost°edn¥

aktor, actor

pouºívá daný systém. P°edm¥ty jsou nap°. lidé (uºivatelé), £as, jiná za°ízení. detail

ºádosti Podrobný výpis jedné ºádosti. Obsahuje popis zam¥stnance, vypln¥ný formulá° a aktuální schvalovací °et¥zec.

formulá°

Je ²ablonou pro konstrukci formulá°e v ºádosti. Formulá° je

²ablona formulá°e

tedy sou£ástí ºádosti. Specikuje, o co se v ºádosti jedná. id

manaºer

Jedine£ný identikátor v rámci celého systému. Kaºdá v¥c v

identika£ní

systému je identikována mnoºinou písmen a £íslic.

identikátor

£íslo,

Role, která specikuje, ºe uºivatel je vedoucím zam¥stnancem

vedoucí, manager

v podniku. N-RLZ

(nám¥stek

Role specikující nám¥stka pro rozvoj lidských zdroj·, tedy

manaºer pro lidské

pro rozvoj lidských

toho, p°es kterého jdou v²echny ºádosti týkající se personálních

zdroje

zdroj·)

poºadavk·.

podání

Akce, kdy je ºádost podána a potvrzena manaºerem. Tím se

podání ºádosti

ºádost vytvo°í a dostává se ve schvalovacím °et¥zci dále a £eká na schválení. referent

Eviduje v²echny v²emi schválené ºádosti. Po zaevidováním m·ºe za£ít realizace ºádosti v podniku.

role

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í.

seznam ºádostí

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ý.

schválení

Akce, kdy je ºádost schválena a potvrzena manaºerem. Kdyº

schválení ºádosti

je potvrzena, dostává se ºádost ve schvalovacím °et¥zci dále. schvalovací °et¥zec

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.

InSypoPepo

uºivatel

Pracovní název této aplikace, Informa£ní systém potvrzování

Personální

personálních poºadavk·.

nemocnice v . L.

IS

Souhrnný název pro £lov¥ka, který pouºívá daný systém (viz

klient, pracovník

aktér, role) vypln¥ní

Akce, kdy je ºádost správn¥ vypln¥na. Není v²ak zatím podána

vypln¥ní ºádosti

k schvalovacímu procesu. zaevidování

zam¥stnanec

Akce, kdy je ºádost zaevidována referentem. Je to poslední

evidování,

£lánek schvalovacího °et¥zce.

dování ºádosti

zaevi-

Povinná role kaºdého uºivatele systému. Kaºdý uºivatel je zam¥stnancem.

zamítnutí

Akce, kdy je ºádost zamítnuta manaºerem. Schvalovací proces

zamítnutí ºádosti

pro ºádost je zastaven. zástupce

Role, která uºivateli p°i°kne práva na operace se ºádostmi, jako

zástupce manaºera

má manaºer. Zástupce si v systému ur£í manaºer. zpráva

Text, který je poslán jedním uºivatelem systému druhému uºi-

e-mail, email

vateli formou e-mailové sluºby. ºádost

Týká se konkrétní zam¥stnance. Podává ji vedoucí (nad°ízený) zam¥stnance

-

manaºer.

Obsahuje

formulá°

°et¥zec.

Tabulka 3.2: Slovník pojm·

a

schvalovací

poºadavek

26


KAPITOLA 4. ANALÝZA A NÁVRH EENÍ

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.

28


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


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í. 4.3.1

Klí£ová slova

- 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²í. IF

- Opakování je pouºito p°i zobrazení r·zných seznam·, kdy je pot°eba zpracovat v²echny prvky n¥jaké mnoºiny. FOR

WHILE

- Slouºí k modelování posloupností akcí po spln¥ní p°edem stanovené podmínky.

- 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¥. EXTEND

- Naproti tomu relací include dáváme najevo, ºe klientský p°ípad uºití bez dodavatelského nem·ºe samostatn¥ existovat. INCLUDE

4.3.2

Správa ºádostí

Obrázek 4.3: Správa ºádostí. Referent a N-RLZ je zárove¬ zam¥stnancem nebo manaºerem.

4.3.2.1

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í

30


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·.

4.3.2.2

UCZ02 Prohlíºet seznam v²ech ºádostí

Analogické k 4.3.2.1 UCZ01 Prohlíºet seznam ºádostí pod°ízených. 4.3.2.3

UCZ03 Prohlíºet seznam ºádostí zam¥stnance

Analogické k 4.3.2.1 UCZ01 Prohlíºet seznam ºádostí pod°ízených.


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 UCZ01.

4.3.2.4

UCZ04 Tisknout seznamy ºádostí

Analogické k 4.3.2.1 UCZ01 Prohlíºet seznam ºádostí pod°ízených. 4.3.2.5

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


ádní

Vstupní podmínky:


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


ºádné


ºádné

4.3.2.6

UCZ06 Tisknout detail ºádosti

Analogické k 4.3.2.5 UCZ05 Prohlíºet detail ºádosti.

32


Obrázek 4.6: Sekven£ní diagram pro UCZ05 Prohlíºet detail ºádosti.

4.3.2.7

UCZ07 Zobrazit volby

Stru£ný popis: Hlavní akté°i:

Systém aktivuje volby podle p°íslu²né role.



ádní

Vstupní podmínky:


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"


ºádné


ºádné

4.3.2.8

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:



33

Obrázek 4.7: Návrh uºivatelského rozhraní - Detail ºádosti UCZ05 a zakomponování formulá°e v ºádosti.


á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²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£í

34


Obrázek 4.8: Sekven£ní diagram pro UCZ07 Zobrazit volby.

4.3.2.9

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


á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"


ádost byla uloºena a má p°i°azený stav 0.


ºádné


35

Obrázek 4.9: Sekven£ní diagram pro UCZ08 Zvolit a vyplnit ºádost.

4.3.2.10

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:



á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 22 3. Systém informuje uºivatele o podání ºádosti


ádost byla uloºena a má p°i°azený stav 20, 21 nebo 22


ºádné

4.3.2.11

UCZ11 Zru²it ºádost

Stru£ný popis:

na podání)".

Hlavní akté°i:

Uºivatel zru²í je²t¥ nepodanou ºádost pokud je ve stavu "0 - vypln¥no (£eká


36


Obrázek 4.10: Návrh uºivatelského rozhraní - Nová ºádost UCZ08.


á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


ádost byla odstran¥na z databáze


ºádné

4.3.2.12

UCZ12 Schválit ºádost


Uºivatel schválí ºádost. M·ºe vloºit také svou poznámku k ºádosti.

Manaºer, Zástupce manaºera, N-RLZ


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 42 3. 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


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


ádost byla uloºena a má p°i°azený stav 40, 41 nebo 42


ºádné

4.3.2.13

UCZ13 Zamítnout ºádost

Analogické k 4.3.2.12 UCZ12 Schválit ºádost. 4.3.2.14

UCZ14 Zaevidovat ºádost

Analogické k 4.3.2.12 UCZ12 Schválit ºádost. 4.3.2.15

UCZ15 Poslat zprávu


Systém ode²le zprávu na zvolenou adresu.

Systém


á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

38


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


ºádné


ºádné

4.3.3 4.3.3.1

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


ádní

Vstupní podmínky:

Uºivatel je aktivní.


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"


Uºivatel je p°ihlá²en.


ºádné

4.3.3.2

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


á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

40


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


ºádné


ºádné

4.3.3.3

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:



ádní

Vstupní podmínky:


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


41

Obrázek 4.16: Sekven£ní diagram pro UCU01 P°ihlásit.


ºádné


ºá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.

4.3.3.4

UCU04 Prohlíºet seznam nad°ízených uºivatel·

Analogické k 4.3.3.3 UCU03 Prohlíºet seznam pod°ízených uºivatel·. 4.3.3.5

UCU05 Prohlíºet seznam v²ech uºivatel·

Analogické k 4.3.3.3 UCU03 Prohlíºet seznam pod°ízených uºivatel·. 4.3.3.6

UCU06 Tisknout seznamy uºivatel·

Analogické k 4.3.3.3 UCU03 Prohlíºet seznam pod°ízených uºivatel·.

42 4.3.3.7


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, e-mail a odkaz na jeho nad°ízeného a referenta. Dále zobrazí moºnost pro "Poslání zprávy"uºivateli. Hlavní akté°i:



ádní

Vstupní podmínky:


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 e-mailem 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


ºádné


ºádné

Obrázek 4.18: Návrh uºivatelského rozhraní - Detail uºivatele UCU07.

4.3.3.8

UCU08 Tisknout detail uºivatele

Analogické k 4.3.3.7 UCU07 Prohlíºet detail uºivatele.


4.3.3.9

43

UCU09 Upravit heslo

Stru£ný popis:

vatele.

Hlavní akté°i:

Uºivatel zm¥ní své heslo. To bude v zakódované podob¥ uloºeno k ú£tu uºi-

Zam¥stnanec


á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


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£í

4.3.3.10

UCU10 Nastavit zástupce


Manaºer zm¥ní zástupce.

Manaºer


Zam¥stnanec

Vstupní podmínky:


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.


ºádné


ºádné

4.3.3.11

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í, email, pracovi²t¥ a funkci a ur£í nad°ízeného. Systém uºivatele uloºí do

44


databáze a ode²le na jeho emailovou adresu zprávu o zaloºení ú£tu spolu s vygenerovaným heslem. Hlavní akté°i:

Referent, N-RLZ


Zam¥stnanec

Vstupní podmínky:


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, emailovou 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 email je neplatný OR email 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 emailovou adresu uºivatele zprávu o zaloºení ú£tu spolu s vygenerovaným heslem)


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

4.3.3.12

UCU12 Upravit uºivatele

Analogické k 4.3.3.11 UCU11 Vloºit uºivatele. 4.3.3.13

UCU13 P°e°adit uºivatele

Analogické k 4.3.3.14 UCU14 Smazat uºivatele. 4.3.3.14

UCU14 Smazat uºivatele


Referent smaºe uºivatele ze systému.

Referent, N-RLZ


Zam¥stnanec

Vstupní podmínky:


Hlavní scéná°: 1. P°ípad uºití za£íná, kdyº referent zvolí "Smazat uºivatele"


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²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£í

4.3.3.15

UCU15 Zm¥nit N-RLZ

Stru£ný popis:

N-RLZ privileguje roli N-RLZ novému nejvy²²ímu manaºerovi.

46


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


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


ºádné


ºádné


4.3.3.16

47

UCU16 Vytvo°it zprávu


Uºivatel napí²e zprávu, zvolí adresáta a zprávu ode²le.



ºá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 e-mailová adresa je neplatná 1. Systém informuje uºivatele, ºe zadal ²patnou e-mailovou adresu 3. INCLUDE: (PoslatZprávu) se zvoleným textem, p°edm¥tem, odesílatelem a adresátem


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£í

4.3.3.17

UCU17 Poslat zprávu

Stejné jako 4.3.2.15 UCZ15 Poslat zprávu. 4.3.4

Správa formulá°· (²ablon formulá°·)

Obrázek 4.22: Správa formulá°·.

48 4.3.4.1


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


ºádní

Vstupní podmínky:


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


ºádné


ºádné

Obrázek 4.23: Návrh uºivatelského rozhraní - vkládání formulá°· UCF03 a seznam formulá°· UCF01.

4.3.4.2

UCF02 Prohlíºet detail formulá°e


Zobrazí detail prázdného formulá°e.

N-RLZ, Admin


ºádní

Vstupní podmínky:


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



ºádné


ºádné

4.3.4.3

49

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


ºádní

Vstupní podmínky:


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


ºá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£í

4.3.4.4

UCF04 Smazat formulá°


Administrátor smaºe formulá° z databáze.

N-RLZ, Admin


ºádní

Vstupní podmínky:


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


Formulá° byl odstran¥n z databáze.


ºádné

50 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 4.24. 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. 4.5.1

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²²í.

- 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 Entita Formulá° (Form)


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 á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 ádost (Petition)

- 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 Schválení (Conrm)

- 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 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 pracovi²´ 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 odd¥lení v podniku. Entita Odd¥lení (Department)

4.5.2

Popis vztah·

- kardinalita 1:N, uºivatel je nad°ízeným N uºivatel·m, uºivatel má práv¥ jednoho nad°ízeného Vztah Je nad°ízeným (mezi User a User) Vztah Je referentem (mezi User a User)

vatel·m, uºivatel má práv¥ jednoho referenta

- kardinalita 1:N, uºivatel je referentem N uºi-

52


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)

formulá°, formulá° je pouºit v N ºádostech

- kardinalita 1:N, ºádost obsahuje práv¥ jeden

Vztah Obsahuje (mezi Petition a Conrm)

schválení pat°í jedné ºádosti

- kardinalita 1:N, ºádost obsahuje N schválení,

- kardinalita 1:N, manaºer schválil/podal N schválení, schválení je schváleno/podáno jedním manaºerem Vztah Schválil/podal (mezi User a Conrm)

- kardinalita 1:N, uºivatel pracuje v jedné funkci/pracovi²ti/odd¥lení, funkce/pracovi²t¥/odd¥lení má N zam¥stnanc·

Vztah Pracuje v (mezi User a £íselníky)

4.5.3

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

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)

podána.

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 e-mailem (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. 5.2.1

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. 5.2.2

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

54


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. 5.2.3

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, DAO2 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


5.4

55

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í£· FK3 . 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í£ PK4 identika£ní £íslo ID. Teorie je popsána v [8] a [9].

Obrázek 5.2: Fyzický model dat.

5.4.1

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¥. 5.4.2

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¥. 5.4.3

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 4

z angl. Foreign Key z angl. Primary Key

56


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 5.9.1 na stran¥ 70. 5.6

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¥. 5.6.1

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,


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.

58


º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 -2147483648 do 2147483647 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') 5.6.2

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. 2.5.1 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. 5.6.3

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. 5.6.4

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. 5.7.3.1.

rgt {Integer,

not null,

level {Integer,

N, N} - atribut right pro algoritmus z kap. 5.7.3.1.

not null,

N, N} - úrove¬ uºivatele v hierarchii

personalNumber {String, rstName {String,

not null,

not null,

N, N, unique} - osobní £íslo ve rm¥, p°ihla²ovací údaj

N, N} - jméno uºivatele

59


lastName {String, email {String,

not null,

not null,

password {String, role {Byte,

null,

not null,

lastLogin {Date,

N, N} - £as posledního p°ihlá²ení

not null,

N, N} - £as vytvo°ení uºivatele

N, N} - po£et p°ihlá²ení uºivatele

not null,

superior {User, not ocer {User,

N, N} - volitelná role uºivatele, admin, referent, N-RLZ

not null,

active {Boolean,

N, N} - heslo uºivatele, zakódováno pomocí MD5

N, N} - poznámka k uºivateli

not null,

createTime {Date, hits {Integer,

N, N, unique} - email uºivatele

not null,

comments {String,

N, N} - p°íjmení uºivatele

N, N} - uºivatel je/není aktivní

null, N, A} - nad°ízený uºivatele, kdyº this.id == superior.id, nemá nad°ízeného

not null,

position {Position,

N, A} - referent uºivatele v otázce lidských zdroj·

not null,

workplace {Workplace,

null,

department {Department,

N, A} - funkce uºivatele v podniku

N, A} - pracovi²t¥ uºivatele v podniku, volitelné

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

+ ", "+ firstName

+ ", "+ lastName

getFullPosition {String} - celé umíst¥ní uºivatele v podniku, vrací slou£ení °et¥zc·

"+ workplace + ", "+ department

position + ",

addHit {void} - náv²t¥vnost se zvý²í o 1 isAdmin {boolean} - pokud isMhr {boolean} - pokud

role

role

isOcer {boolean} - pokud

== 3 nebo 4, vrací

true

== 1, vrací

role

== 2 nebo 4, vrací

setNone(boolean) {void} - nastaví setMhr(boolean) {void} - nastaví

role

role

setOcer(boolean) {void} - nastaví

true true

= 0, uºivatel nemá ºádnou vedlej²í roli

= 1, uºivatel má roli N-RLZ

role

= 2 pokud není adminem, nastaví

role

= 4 pokud je

role

= 3 pokud není referentem, nastaví

role

= 4 pokud je

adminem , uºivatel má roli referent

setAdmin(boolean) {void} - nastaví referentem , uºivatel má roli admin

setOcerAdmin(boolean) {void} - nastaví

5.6.5

role

= 4, uºivatel je referentem a adminem zárove¬

T°ída Petition / tabulka petitions

atribut {datový id {Integer,

not null,

employee {User, form {Form,

typ, null

data {String,

N, A} - uºivatel, kterého se týká ºádost

N, N} - serializovaná data ºádosti

not null,

discussTime {Date,

primární klí£ PK, cizí klí£ FK} - popis atributu

N, A} - formulá°, který ºádost obsahuje, ²ablona pro deserializaci dat

not null,

createTime {Date,

not null,

A, N} - jedine£ný identikátor ºádosti

not null,

not null,

nebo

N, N} - £as vytvo°ení ºádosti

not null,

N, N} - £as projednání ºádosti se zam¥stnancem

60


conrms {List,

5.6.6

not null,

N, N} - seznam v²ech schválení ºádosti

T°ída Conrm / tabulka conrms

id {Integer,

not null,

idPetition {Integer,

A, N} - jedine£ný identikátor schválení

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, state {Integer,

not null,

not null,

comments {String, consult {Boolean,

null,

N, N} - stav schválení, stav ºádosti je dán stavem posledního schválení N, N} - d·vod podání ºádosti nebo poznámka ke schválení/zamítnutí

not null,

conrmLevel {Integer, seznamu schválení v t°íd¥

createTime {Date,

5.6.7

N, A} - manaºer, který ºádost podal, schválil, zamítnul

N, N} - ºádá-li manaºer o konzultaci s odd¥lením lidských zdroj·

not null, N, N} - index ur£ující pozici schválení pro konstrukci indexovaného Petition (ºádosti)

not null,

N, N} - £as vytvo°ení schválení

T°ída Form / tabulka forms

id {Integer,

not null,

title {String,

not null,

shortTitle {String, path {String,

A, N} - jedine£ný identikátor formulá°e

null,

not null,

locale {String,

N, N} - název formulá°e

N, N} - název souboru formulá°e

not null,

active {Boolean,

N, N} - alternativní název formulá°e

N, N} - lokalizace formulá°e

not null,

createTime {Date,

N, N} - formulá° je/není aktivní

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

5.6.8

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,

name {String,

not null,

secondName {String, comments {String,

5.6.9

A, N} - jedine£ný identikátor N, N} - hodnota £íselníku

null,

null,

N, N} - alternativní hodnota £íselníku

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

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; }

5.7.1

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. 5.1. 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á

Tabulka 5.1: Tabulka ºádostí a jejich zam¥stnanc· Pomocí nativního SQL sta£í jediný dotaz: SELECT z.id AS id, z.data AS data, u.jmeno AS zamestnanec FROM zadosti z, uzivatele u WHERE z.id_zamestnanec = u.id;

62


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 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 SELECT SELECT SELECT

* * * *

FROM FROM FROM FROM

zadosti; uzivatele WHERE uzivatele.id = ?1; uzivatele WHERE uzivatele.id = ?2; uzivatele WHERE uzivatele.id = ?3;

Jsou zde 1 + 3 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()) }

5.7.2

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 5.7.3.1. 5.7.3

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.


63

Hlavní £ást objektu v²ak spo£ívá v mnoºin¥ metod pro manipulaci s hierarchickou strukturou uºivatel·. 5.7.3.1

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 DFS5 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

64


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¥n-

ný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). 5.7.3.2

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. 5.7.3.3

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


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. 5.7.3.4

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 5.7.3.2. 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.

66


Obrázek 5.5: Metoda transferSubtree p°esune list nebo celý podstrom pod nový uzel.

5.7.3.5

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);

5.7.3.6

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.

5.7.4

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().


5.7.5

67

P°ístupový objekt FormDAO

Poslední z p°ístupových objekt· má op¥t podobné metody. Metody manipulující s jednotlivým formulá°em a metody získávající seznamy formulá°·. Více viz diagram na obr. 5.3 na str. 57. 5.8

Aplika£ní vrstva

Aplika£ní vrstva frameworku JSF je tvo°ena tzv. Backing beany, coº jsou Java bean objekty obsahující navíc akce a obsluhu událostí. Tyto objekty obsahují logiku celé aplikace a pomocí integra£ní vrstvy k tomu pouºívají data z business vrstvy. Základní schéma Backing bean· je £erpáno z publikace [6]. 5.8.1

Backing bean Visit

Jde o jediný objekt, který je uchován b¥hem celého p°ihlá²ení uºivatele (tzv. session scope). Ostatní Backing beany jsou konstruovány kaºdým poºadavkem (tzv. request scope). Objekt Visit je zkonstruován po p°ihlá²ení uºivatele a je do n¥j vloºen objekt uºivatele. Následn¥ je Visit uloºen do session, a to aº do té doby, neº se uºivatel odhlásí. K tomuto objektu mají p°ístup kdykoli v²echny ostatní beany. Tato pravidla jsou dána v kongura£ním souboru facescong.xml: <managed-bean> <managed-bean-name>createUserBean <managed-bean-class>insypopepo.web.user.CreateUserBean <managed-bean-scope>request <managed-property> <property-name>visit #{sessionScope.visit}

Poté m·ºe bean (v tomto p°ípad¥ createUserBean) p°istoupit k objektu Visit pomocí jeho getteru getVisit() a k p°ihlá²enému uºivateli pomocí getVisit().getUser(). Objekt Visit je také výhodné vyuºít na del²í skladování r·zných objekt· nap°. p°i r·zných wizardech, kdy se t°eba p°esouvá uºivatel v hierarchii, nebo pro uloºení aktuální ºádosti, jejíº detail bude v následujícím kroku zobrazen. Je ale nezbytné d·kladné mazání t¥chto do£asných objekt· z Visitu, kdyº uº nejsou pot°eba. 5.8.2

Backing bean AuthenticationBean

Tento bean obsahuje dv¥ metody, login() pro p°ihlá²ení uºivatele a logout() pro odhlá²ení. Vyplní-li uºivatel p°ihla²ovací údaje v p°ihla²ovacím formulá°i, spustí se metoda login(), která zavolá metody z integra£ní vrstvy pro validaci uºivatele. Pokud je validace úsp¥²ná, AuthenticationBean vytvo°í objekt Visit, uloºí do n¥j p°ihla²ovaného uºivatele a objekt uloºí do http session. Poté, podle rolí, které uºivatel má, jej p°esm¥ruje na dal²í stránku: UserDAO uc = new UserDAO(); try { // validace uºivatele newUser = uc.validateUser(loginName, password); } catch (ObjectNotFoundException e) {

68


// neplatné jméno nebo heslo return Constants.FAILURE_OUTCOME; } catch (InfrastructureException ie) { // chyba v databázi return Constants.ERROR_OUTCOME; } // vytvo°ení Visitu Visit visit = new Visit(); visit.setUser(newUser); setVisit(visit); // uloºení Visitu do session getApplication().createValueBinding("#{" + Constants.VISIT_KEY_SCOPE + Constants.VISIT_KEY + "}") .setValue(facesContext, visit);

5.8.3

Ostatní Backing beany

Chceme-li, aby k vlastnostem a akcím Backing bean m¥la p°ístup prezenta£ní vrstva, musíme je denovat ve faces-cong.xml jako tzv. Managed bean. P°íklad kódu je v kapitole 5.8.1. Poté záleºí na poºadavcích, co má bean d¥lat a zavést p°íslu²né atributy a naimplementovat akce. 5.8.4

Rekurzivní konstrukce hierarchické tabulky uºivatel·

Seznam uºivatel· se°azený podle sloupce left (viz kapitola 5.7.3.1) je stejn¥ se°azený jako p°i pr·chodu stromu do hloubky DFS. Poté je moºné rekurzivn¥ vytvo°it vno°ené tabulky, které zobrazí p°esnou hierarchii uºivatel·. Pro kaºdého uºivatele se vytvo°í samostatná tabulka o dvou °ádcích. Celý první °ádek je hlavi£ka tabulky (colspan = po£et sloupc·), kde jsou informace o uºivateli (jeho jméno, atd.). Druhý °ádek má tolik sloupc·, kolik má uºivatel p°ímých pod°ízených. V kaºdém tomto sloupci je pak nová tabulka pro pod°ízeného uºivatele. Nemá-li uºivatel pod°ízeného, druhý °ádek tabulky není t°eba. Konstrukce je rekurzivní. Framework JSF umoº¬uje pracovat s komponentami prezenta£ní vrstvy ve vrstv¥ aplika£ní (v Backing beans). Komponenta se prováºe pomocí atributu binding s objektem komponenty v aplika£ní vrstv¥. Objekt poté nabízí stejné metody, jako komponenta nabízí atributy, a lze tedy komponenty vytvá°et, upravovat a pracovat s jejich potomky. Komponenta panelGrid v souboru JSP prezenta£ní vrstvy je pomocí atributu binding propojena s objektem hierarchyGrid t°ídy HtmlPanelGrid (objektová reprezentace komponenty panelGrid) v beanu myUsersBean. Tam, kde je uveden tento °ádek, se zobrazí výsledná tabulka:

Rekurzivní konstrukce hierarchické tabulky je následující: // Rekurzivne volana metoda, ktera vraci podstrom. Pokud uzivatel nema potomky, vrati // list (tabulku o jednom prvku). Vysledkem je cela hierarchicka tabulka - jeden strom. protected HtmlPanelGrid getHierarchyGrid() { // Ze seznamu uzivatelu serazenych podle sloupce left (DFS) // ziskam dalsiho uzivatele, to je potomek toho, ktery tuto metodu zavolal. User user = (User) hierarchyList.get(index); // Pro tohoto uzivatele vytvorim novou tabulku. HtmlPanelGrid grid = (HtmlPanelGrid) getApplication().createComponent(HtmlPanelGrid.COMPONENT_TYPE); // Metoda createLink vytvori komponentu HtmlCommandLink reprezentujici odkaz v html, kde jmeno // uzivatele bude slouzit jako link na jeho detail. Link bude jako hlavicka tabulky.


69

HtmlCommandLink headerLink = createLink(user); grid.getFacets().put("header", headerLink); if (user.getManager()) { // nejsem list, mam podrizene List childrenGrid = grid.getChildren(); int mySons = 0; do { // pro vsechny podrizene if (index == hierarchyList.size() - 1) { break; //uplny konec } // Pokud je dalsi uzivatel muj primy podrizeny ... if (hierarchyList.get(index + 1).getSuperior().getId().equals(user.getId())) { index++; mySons++; // ... rekurze, vytvarim opet novou bunku. childrenGrid.add(getHierarchyGrid()); } else { break; } } while (true); // Pocet sloupcu je tolik, kolik ma uzivatel primych podrizenych. grid.setColumns(mySons);

}

} return grid;

Metodu createLink() lze vyuºít pro vytvo°ení i dal²ích odkaz·, jako rychlé vymazání uºivatele, p°e°azení, editace, atd. Odkaz nemusí být textový, ale t°eba ikonkový. Jak bude vypadat hierarchická tabulka v prohlíºe£i je na obrázcích 5.6 a 5.7.

Obrázek 5.6: Hierarchická tabulka bez css úprav.

Obrázek 5.7: Stejná hierarchická tabulka jako na obr. 5.6, ale s jednoduchými css úpravami.

5.9

Prezenta£ní vrstva

Pro zobrazování výsledných stránek je zvolena standardní technologie JSP spolu se standardními JSF tagy a s tagy z knihovny Apache MyFaces Tomahawk. Lze pouºít i jiné zobrazovací technologie, jako nap°íklad XML/XSLT nebo samostatné frameworky Velocity £i WebMacro.

70


5.9.1

Bezpe£nost pomocí autoriza£ního ltru

Aplikace musí spl¬ovat základní bezpe£nostní prvky proti pokus·m dostat se na stránky, na které nemá uºivatel právo podle p°i°azených rolích. Je pouºita my²lenka popsaná v [6] zaloºená na odep°ení p°ístupu do adresá°· pomocí autoriza£ního ltru. Co je to ltr v servlet API je vysv¥tleno v kapitole 5.5. Autoriza£ní ltr, d°íve, neº p°edá http poºadavek dál, na£te ze session scope uloºený objekt visit a p°íslu²ného p°ihlá²eného uºivatele. Pokud není ºádný klient p°ihlá²en, p°esm¥ruje uºivatele na p°ihla²ovací stránku. Pokud je klient p°ihlá²en, zkontroluje, zda má právo na zobrazení stránky. Pokud nemá, objeví se http chyba £. 404. Visit visit = (Visit) session.getAttribute(Constants.VISIT_KEY); // pokud neni visit ulozen v session scope // redirect na prihlasovaci stranku if (visit == null) { session.setAttribute(Constants.ORIGINAL_VIEW_KEY, httpRequest.getPathInfo()); httpResponse.sendRedirect(httpRequest.getContextPath() + Constants.LOGIN_VIEW); // jinak z visitu ziskam uzivatele } else { session.removeAttribute(Constants.ORIGINAL_VIEW_KEY); User user = visit.getUser(); // // // // if

nikdo krome n-rlz nebo admina nemuze do adresare "admin" nikdo krome n-rlz nebo referenta nemuze do adresare "officer" nikdo krome n-rlz nemuze do adresare "mhr" nikdo krome manazera nemuze do adresare "manager" ((!user.getMhr() && !user.getAdmin() && requestPath.indexOf(Constants.ADMIN_DIR) > 0) || ((!user.getMhr() && !user.getOfficer()) && requestPath.indexOf(Constants.OFFICER_DIR) > 0) || (!user.getMhr() && requestPath.indexOf(Constants.MHR_DIR) > 0) || (!user.getManager() && requestPath.indexOf(Constants.MANAGER_DIR) > 0)) { // zakaz vstupu, zobrazi se http chyba 404 httpResponse.sendError(HttpServletResponse.SC_NOT_FOUND, "Path Not Found");

} else {

}

// vsechno v poradku, pokracujeme chain.doFilter(request, response);

V adresá°i employee jsou uloºeny JSP stránky, ke kterým mají p°ístup v²ichni uºivatelé, protoºe mají roli zam¥stnance. Adresá° manager je ur£en pro JSP stránky role manaºer. NRLZ (nám¥stek pro lidské zdroje) m·ºe navíc do adresá°e admin, který je ur£ený pro správce formulá°· - admina, a do adresá°e ocer, coº je adresá° se stránkami pro referenty. Adresá°ová struktura prezenta£ní vrstvy je v p°íloze na obrázku F.1 na stran¥ 102. 5.9.2

Lokalizace

Aplikace podporuje tolik jazyk·, kolik obsahuje lokaliza£ních soubor· a kolik lokalizací je povoleno ve faces-cong.xml. Lokaliza£ní soubor má p°íponu .properties a na kaºdém °ádku obsahuje dvojici klí£hodnota. Poté je pot°eba ve v²ech JSP pohledech zam¥nit statický text za klí£ a ve vygenerovaném HTML bude tento klí£ nahrazen hodnotou. Více viz [6].

KAPITOLA 6. TESTOVÁNÍ POUITELNOSTI (USABILITY TEST)

71

6 Testování pouºitelnosti (Usability test) 6.1

Cíl testování

Je pot°eba otestovat v²echny komponenty grackého rozhraní manaºerské sekce aplikace. Usability test lze pojmout p°eváºn¥ jako hledání chyb a dolad¥ní uºivatelského rozhraní v£etn¥ zvý²ení pohodlí p°i ovládání. Jelikoº je aplikace ur£ena pro lidi s r·zným pracovním zam¥°ením, jejichº hlavní nápl¬ nemusí být spojena s prací na po£íta£i, je vyºadována vysoká p°ehlednost a jednoduchost. Nemén¥ d·leºitým faktorem pro úsp¥ch aplikace je u²et°ení £asu uºivatele. Na druhou stranu p°edpokládejme, ºe uºivatelé, jakoºto manaºe°i na ur£itých úrovních, ovládají základy práce na po£íta£i. Sekce pro správu aplikace testována nebude. Naprostá v¥t²ina £asu stráveného v aplikaci bude v manaºerské sekci p°i podávání, schvalování a prohlíºení ºádostí. Se správou systému, do které lze za°adit správu uºivatel·, ºádostí a formulá°·, bude pracovat pouze pár lidí, jako jsou referenti, admini a N-RLZ. Práce s po£íta£em je jejich hlavní pracovní náplní a ve správcovské sekci aplikace budou trávit hodn¥ £asu. Proto je pravd¥podobné, ºe se s aplikací sºijí jednodu²eji, neº oby£ejní zam¥stnanci. Testování správcovské sekce tedy není tak d·leºité jako sekce manaºerské a je moºné provést jej pozd¥ji.

6.2 6.2.1

Výb¥r uºivatel· - testujících P°edpoklady a poºadavky

P°edpokládejme, ºe uºivatelé na manaºerských postech uºívají ke své práci po£íta£, a´ primárn¥, pokud jejich práce spo£ívá v práci na po£íta£i, nebo sekundárn¥, pokud jejich hlavní náplní práce není práce na po£íta£i (nap°. léka°i). Pro vypovídající Usability test je nejlépe otestovat aplikaci na rizikových skupinách budoucích uºivatel·. Vybereme tedy lidi, kte°í nemají vysoké znalosti po£íta£·. To, ºe na po£íta£i pracovat neumí, neuvaºujme (viz P°edpoklady, první odstavec). Pro test to nemusí být lidé na vedoucích pozicích. Výsledky budou ur£it¥ také ovlivn¥ny, zda testující pouºívá po£íta£ doma, zda pouºívá internet, atd.

6.2.2

P°edtestový dotazník

Na základ¥ p°edpoklad· a poºadavk· byl vytvo°en p°edtestový dotazník pro výb¥r vhodných testujících. Viz p°íloha E.1.

6.2.3

Kone£ný výb¥r

Výb¥r a testování se uskute£nilo v nemocnici v Liberci a na Ministerstvu ºivotního prost°edí v Liberci. Dle p°edpoklad· um¥jí v²ichni testující alespo¬ v základech pracovat na po£íta£i. Podle poºadavk· (rizikové skupiny) bylo po vypln¥ní p°edtestového dotazníku vybráno osm testujících. Výsledky viz tab. 6.1.

72


Testující £.

1

Po£et p°ímých pod°ízených

2

3

4

5

6

7

8

1

8

4

3

0

1

0

0

for-

E

E

P

P

P

P

N

N

Zku²enosti s prací na PC - ()ádné, (Z)ákladní,

Z

P

Z

P

Z

P

V

P

K

K

K

N

K,I,IS

K,IS

K,I,IS

K,IS

N

I,P

N

I

N

I,P

I,P,J

I,Z

Pouºití

(P)apírových

/

(E)lektronických

mulá°· / (N)epouºívá

(P)r·m¥rné, (V)ysoké, (E)xtrémní Pot°eba internetu v práci - (N)e, (K)orespondence, (I)nternet, (I)nforma£ní (S)ystém Pouºití

po£íta£e

doma

-

(N)e,

(I)nternet,

(Z)ábava, (P)saní, (J)iné

Tabulka 6.1: Výb¥r testujících na základ¥ p°edtestového dotazníku, viz p°íloha E.1. 6.3 6.3.1

Usability test Nastavení testu (setup)

Testování bude probíhat na pracovi²tích testujících. Budou pracovat na svých po£íta£ích. Známé prost°edí a vlastní po£íta£ pomohou testujícím uvolnit se a soust°edit se na test. Spojení testování s pracovním prost°edím by také mohlo pomoci v tom, ºe testující budou brát test váºn¥, jako sou£ást pracovního úkonu. Pouºité rozli²ení monitoru je r·zné, aplikace musí spl¬ovat cíle na jakémkoli po£íta£i. P°ipojení k internetu je také r·zné. Testující m·ºe pouºívat v²echny po£íta£ové pom·cky (my², klávesnici, . . . ). Celé nastavení testu viz tab. 6.2. Testovací prost°edí

Pracovi²t¥ testujícího

Testovací po£íta£

Pracovní po£íta£ testujícího

Rozli²ení obrazovky

R·zné

Rychlost internetu

R·zná

Pouºití po£íta£. pom·cek

V²echny povoleny

Za£átek testování

Úvodní stránka P°ihlá²ení ve spu²t¥ném web.prohlíºe£i

Tabulka 6.2: Setup testu. 6.3.2

Úkoly

Testující má p°ed sebou papír s p°ihla²ovacími údaji a s úkoly a za£íná testovat aplikaci na úvodní stránce P°ihlá²ení ve spu²t¥ném webovém prohlíºe£i. Úkol £.1:

Dejte výpov¥¤ sest°e R·ºi£kové Jan¥ z d·vodu výpov¥¤ na vlastní ºádost, platnost od 1.2.2009, poºadujte konzultaci s personálním odd¥lením. Se sestrou R·ºi£kovou jste to projednala dnes. Pomocí aplikace vypl¬te, podepi²te a ode²lete p°íslu²ný elektronický formulá°. Správný postup

(testující jej nezná):

P°ihlaste se do systému pomocí p°ihla²ovacích údaj·. V hlavním menu zvolte Nová ºádost. Na zobrazené stránce pomocí rozbalovacího menu (Option) Vyberte formulá°: zvolte Výpov¥¤ z pracovního pom¥ru. V ádosti o výpov¥¤ z pracovního pom¥ru zvolte zam¥stnance R·ºi£kovou Janu v rozbalovacím menu Zvolte zam¥stnance. Zvolte Platnost od


73

datum 1.2.2009. Do velkého vstupního pole (TextArea) Zd·vodn¥ní ºádosti napi²te jako d·vod výpov¥¤ na vlastní ºádost. Za²krtn¥te checkbox poºadující konzultaci s personálním odd¥lením. V rozbalovacích menu Se zam¥stnancem projednáno dne zvolte dne²ní datum. Potvr¤te ºádost tla£ítkem Pokra£ovat. Zkontrolujte správnost ºádosti a ode²lete ji stiskem tla£ítka Podat. Úkol £.2:

Zjist¥te, které Va²e d°íve podané ºádosti byly zamítnuty. Zjist¥te, kdo je zamítl a d·vod zamítnutí. Správný postup


V hlavním menu klikn¥te na odkaz Seznam ºádostí pod°ízených. Na následující stránce se objeví tabulka v²ech ºádostí, které podali va²i pod°ízení nebo vy. ádosti m·ºete °adit podle sloupc· a ltrovat podle stav·. Ve sloupci aktuální stav nalezn¥te ºádost, která je ve stavu zamítnuto a zárove¬ má ve sloupci podal va²e jméno. U této ºádosti klikn¥te na odkaz detail. Posu¬te se ve formulá°i úpln¥ dol·, kde je tabulka poslední zm¥ny. Zde naleznete poºadované informace. Odhlaste se od systému odkazem v pravém horním rohu. Úkol £.3:

Zkontrolujte Va²e nov¥ p°íchozí ádosti na schválení. ádosti o personální náhradu zamítn¥te z d·vodu nedostatku nancí. Ostatní schvalte. Správný postup


V hlavním menu je pod nadpisem ádosti ke schválení/podání tabulka s novými ºádostmi pro Va²i osobu. Ve sloupci ºádost nalezn¥te Personální náhrada. U této ºádosti klikn¥te na odkaz detail. Posu¬te se ve formulá°i úpln¥ dol·, kde je velké vstupní pole (TextArea) Va²e vyjád°ení, zde napi²te nedostatek nancí. Zamítn¥te ºádost stiskem tla£ítka Zamítnout. Úkol £.4:

Zjist¥te, která Va²e schválení ºádostí jsou ve stavu £ekání. Správný postup


V hlavním menu klikn¥te na odkaz Seznam ºádostí pod°ízených. Na následující stránce se objeví tabulka v²ech ºádostí, které podali va²i pod°ízení nebo vy. Ve sloupci aktuální stav nalezn¥te ºádost, která je ve stavu £ekání na . . . a zárove¬ má ve sloupci podal va²e jméno. Ve sloupci id naleznete poºadovanou informaci. Odhlaste se od systému odkazem v pravém horním rohu. 6.3.3

Výsledky testu

Úkol £.1:

a) V²ichni testující se bez problému p°ihlásili do systému. b) V²ichni testující vybrali správný formulá°. c) P°i vypl¬ování formulá°e m¥l testující £.5 men²í rozli²ení a nevid¥l celý formulá°. Zvolil pouze zam¥stnance a Platnost od. Poté dlouho tápal. Více na obrazovce nevid¥l a snaºil se objevit, jak poslat formulá°. Poradil jsem, ºe formulá° je del²í. Poté vyplnil a odeslal v po°ádku. Testující £.7 m¥l velké rozli²ení, kde vid¥l celý formulá° a vyplnil jej nejrychleji. Testující £.3 nerozumí, co napsat jako d·vod, myslí si, ºe má odpov¥d¥t na otázku pro£?. Ostatní vyplnili formulá° v po°ádku.

74


d) Testující £.5 se snaºil navrátit do menu tla£ítkem Zp¥t. Upozornil jsem na to, poté v po°ádku. Ostatní bez problému. Úkol £.2:

e) Testující £.2, 3 a 7 nejd°íve klikají na rozbalovací menu ºádostí. Poté si uv¥domují, ºe se po nich chce n¥co jiného. Následn¥ v²ichni bez problému vstoupili na Seznam ºádostí pod°ízených. f) Testující £.2, 5 a 7 klikají na detaily v²ech ºádostí. Po upozorn¥ní správn¥ naleznou zamítnuté ºádosti a jako ostatní klikají na jejich detail. g) V detailu formulá°e se v²ichni testující krom¥ 4. a 7. velmi dlouho snaºí pochopit formulá°. Dlouho ho pro£ítají a hledají, kdo jej zamítl a pro£. Problém je, ºe aktuální stav formulá°e je poznamenán aº dole a v¥t²ina jej neodscrollovala. Testující jsou zmateni, pro£ je v °et¥zci schvalování tolik osob. Testující £.3 a 4 nejd°íve uvád¥jí jako osobu, která ºádost zamítla, tu první v °et¥zci schvalování. Po upozorn¥ní provedou úkon správn¥ a uvedou osobu poslední. Úkol £.3:

h) V²ichni po rychlém prostudování stránky nalezli odkaz ádosti ke schválení/podání. Testující £.2, 5 a 7 op¥t chybn¥ nav²t¥vují detaily v²ech ºádostí. Pou£eni z minula nakonec klikají na detail pouze u poºadovaných ºádostí. Z°ejm¥ nepozornost p°i £tení zadání. i) Op¥t nastává problém, ºe d·vod zamítnutí ºádosti se vkládá v detailu formulá°e aº dole. Po del²í dob¥ se v²ichni testující dostávají na správnou lokaci. Dále v²ak testující plete, ºe d·vod zamítnutí se pí²e do textového pole Va²e vyjád°ení. Testující £.7 na to doplácí nejvíce, protoºe neví, zda má nejd°íve stisknout Zamítnout a aº poté se objeví kolonka na vepsání d·vodu nebo to je jinak. j) U ostatních ºádostí £ekajících na schválení pak v²ichni správn¥ ºádosti schválí. Úkol £.4:

k) V²ichni se úsp¥²n¥ dostávají do sekce Seznam ºádostí pod°ízených. l) Testující £.7 je zmatený, protoºe a£koli je v Seznamu ºádostí pod°ízených, tak ve sloupci aktuální stav nevidí nikde stav schváleno, diví se tedy divnému pojmenování. Nakonec v²ak v²ichni nacházejí poºadované ºádosti ve stavu £ekání na. . . . m) Odhlá²ení od systému prob¥hne bez problému. 6.4

Problémy, °e²ení a potestový dotazník

Po kaºdém úkolu byl testující dotázán na intuitivnost ovládání, na nejmén¥ p°ehledné £ásti, na design a na absenci n¥jaké d·leºité funkce (viz Potestový dotazník v p°íloze E.3). Nyní lze pomocí Usability testu a potestového dotazníku vyjmenovat problémy a navrhnout jejich °e²ení. asto °e²ení navrhli p°ímo testující v dotazníku. Mnoho problém· vzniklo nepozorností, kdy si testující po°ádn¥ nep°e£etl, co má d¥lat. Dále jsou popsány pouze oblasti, kde se vyskytly problémy technického rázu.


ad c)

75

Splývající formulá°:

Ve formulá°ích splývají r·zné sekce. To by ²lo vy°e²it výrazn¥j²ím odd¥lením sekce výb¥ru zam¥stnance, sekce vypl¬ování a sekce s ostatními informacemi. Návrh na se°azení formulá°e je následující: sekce výb¥ru zam¥stnance, sekce vypl¬ování, sekce projednání se zam¥stnancem, sekce zd·vodn¥ní ºádosti a sekce o ºádost konzultace. ad c)

Velikost (délka) formulá°e:

Jde o problém na obrazovkách s malým rozli²ením. Formulá° v¥t²inou bývá del²í a nevejde se na celou obrazovku. Testující sd¥lili, ºe to byl pouze prvotní problém. ad g)

Zpracování a umíst¥ní °et¥zce souhlas· / zamítnutí / zaevidování v detailu ºádosti:

lo z°ejm¥ o nejv¥t²í problém. Struktura detailu formulá°e je následující. Nejd°íve je samotný formulá°, poté sekce kdo jej podal, poté sekce obsahující °et¥zec v²ech schválení a nakonec (byl-li zaevidován) sekce zaevidování. Detail formulá°e se tak stává dlouhým a tím pádem nep°ehledným. Nabízí se n¥kolik °e²ení: (i) v¥t²í odsazení nebo barevné °e²ení t¥chto £ty° sekcí detailu, to v²ak ne°e²í délku (ii) °et¥zec schvalování p°ed¥lat místo do °ádk· do sloupc·, problém v²ak nastává pokud je °et¥zec moc dlouhý (iii) uºivatele vícemén¥ nezajímá, kdo ºádost podal, schvaloval, zaevidoval, zajímá ho pouze poslední aktuální stav ºádosti, od toho je to v²ak detail, aby obsahoval v²e (iv) uvaºovat podobn¥, jako u bodu c), ale s tím, ºe v²echny stavy budou minimali-zované a maximalizovaný bude pouze ten nejd·leºit¥j²í, tedy aktuální. ad i)

Zadávání schválení / zamítnutí ºádosti v detailu ºádosti:

Nastává podobný problém, jako u bodu ad g). Detail formulá°e je dlouhý, protoºe obsahuje v²echna p°ede²lá schválení. e²ení lze pojmout podobn¥, jako v ad g), (iv). ad i)

Vyjád°ení a po°adí vyjád°ení a schválení ºádosti:

D·vod neboli vyjád°ení k ºádosti není vhodn¥ pojmenováno a odli²eno. Vy°e²it to lze: (i) jiným pojmenováním, to v²ak ne°e²í d·leºitost tohoto pole (ii) umíst¥ním kolonky na vyjád°ení na za£átek detailu, to v²ak rozhodí zavedenou strukturu formulá°· a jejich detail· (iii) tak, ºe uºivatel nejd°íve stiskne tla£ítko schválit / zamítnout a aº poté se zobrazí výzva k zadání svého vyjád°ení, toto °e²í oba problémy i po°adí provád¥ní 6.4.1

Ostatní problémy

Velikost fontu:

Polovina testujících m¥lo p°ipomínku k velikosti fontu celé aplikace. Problém se vy°e²í zv¥t²ením fontu. Intuitivnost:

Testující se shodli, ºe aplikace je intuitivní a jednoduchá na pouºití a ºe problémy nastaly p°eváºn¥ z d·vodu prvního pouºití aplikace. N¥kte°í testující sd¥lili, ºe nepot°ebovali ani nápov¥du v podbodech. Nepozornost:

76


Mnoho problém· vzniklo nepozorností, kdy si testující po°ádn¥ nep°e£etl, co má d¥lat. 6.5

Zhodnocení

Test pouºitelnosti odhalil n¥které nedostatky jako velikost formulá°· a splývání d·leºitých £ástí formulá°·. Velký problém nastal u reprezentace schvalovacího °et¥zce pro jeho robustnost. e²ení jsou nastín¥na vý²e. Dal²ími nedostatky bylo schvalování a zadávání svého vyjád°ení. Nabízí se elegantní °e²ení navrºené jedním testujícím (viz 6.4, ad i), (iii)) Jinak byla aplikace p°ijata pozitivn¥, testující vyzdvihovali jednoduchost i design. Kosmetické úpravy, jako velikost fontu, jsou minimální.

KAPITOLA 7. ZÁVR

77

7 Záv¥r Výsledkem práce je funk£ní webová aplikace, která m·ºe být zavedena v nemocnici v eské Líp¥. Není v²ak podmínkou pouze pouºití v této nemocnici. Mírn¥ modikovanou aplikaci je moºné zavést v jakémkoli podniku, který má hierarchickou strukturu zam¥stnanc·. Aplikace umoº¬uje podávání, schvalování, zamítání a evidování personálních ºádostí. D°íve nap°íklad vrchní sestra, cht¥la-li zvý²it plat své pod°ízené, musela ºádost ru£n¥ vyplnit a p°edloºit ji ke schválení své nad°ízené - stani£ní sest°e. Ta se musela k ºádosti vyjád°it a nechat ji schválit svým nad°ízeným - primá°em. A tak dále. D°ív¥j²í manuální podávání ºádosti je nahrazeno pln¥ automatizovaným, rychlým a p°ehledným zp·sobem. Dále aplikace poskytuje nástroje pro správu ºádostí a správu uºivatel· spolu s manipulací se zam¥stnaneckou hierarchií. Nedílnou sou£ástí je moºnost p°idávat nové formulá°e ºádostí. Aplikace má uºivatelsky p°ív¥tivý design. N¥které zákazníkovy poºadavky nebyly naimplementovány (viz kapitola 5.1). Jsou to v²ak poºadavky, které nejsou nezbytnou £ástí systému a mohou být jednodu²e dotvo°eny pozd¥ji. V dne²ní dob¥ se nejen v Java sv¥t¥ vyuºívají ke tvorb¥ aplikací frameworky. Pro prezenta£ní £ást byl zvolen framework JSF z dílny rmy Sun Microsystems a pro persistenci dat pak velmi roz²í°ený framework Hibernate. Díky t¥mto framework·m byla dána aplikaci základní struktura, která je zaloºena na nezávislých vrstvách. Frameworky jsou velmi mocnou zbraní a toto moje první setkání s nimi mi velmi dob°e ukázalo jejich moºnosti. P°esto se ukázalo, ºe (hlavn¥ u frameworku Hibernate) k detailnímu pochopení problematiky je zapot°ebí výrazn¥ více £asu. A£koli se jedná o práci, kde by se mohlo p°edpokládat pouze na£ítání a zobrazování nebo ukládání a modikace dat v databázi, obsahuje aplikace i velmi zajímavé algoritmy. Reprezentace hierarchické struktury zam¥stnanc· v rela£ních tabulkách je °e²ena kv·li optimalizaci pomocí tzv. Nested Set Model of Hierarchies. Lze °íci, ºe to bylo p°íjemné oºivení nejen systémového programování ale i teorie graf·.

78

KAPITOLA 7. ZÁVR

KAPITOLA 8. LITERATURA

79

8 Literatura [1] ARLOW, J.; NEUSTADT, I.: UML2 a unikovaný proces vývoje aplikací. Brno: Computer Press, a.s., druhé vydání, 2007, ISBN 978-80-251-1503-9. [2] BAUER, C.; KING, G.: Java Persistence with Hibernate. Greenwich, CT, U.S.A.: Manning Publications Co., první vydání, 2007, ISBN 1-932394-88-5. [3] CELKO, J.: Trees and Hierarchies in SQL for Smarties. San Francisco, CA, U.S.A.: Elsevier Inc., Morgan Kaufmann Publishers, první vydání, 2004, ISBN 1-55860-920-2. [4] KOSEK, J.: XSLT v p°íkladech. 2004, [Online], Revize 0.2, [rev. 26.4.2004]. URL http://www.kosek.cz/xml/xslt/. [5] KOSEK, J.: XML schémata. 2005, [Online], [rev. 18.8.2005]. URL http://www.kosek.cz/xml/schema/. [6] MANN, K. D.: JavaServer Faces in Action. Greenwich, CT, U.S.A.: Manning Publications Co., první vydání, 2005, ISBN 1-932394-12-5. [7] PICHLÍK, R.: DagBlog - blog nejen pro kodery: Web frameworky v Jav¥. 2006, [Online], [rev. 12.10.2006]. URL http://www.sweb.cz/pichlik/archive/2006_12_10_archive.html. [8] POKORNÝ, J.; HALAKA, I.: Databázové systémy. Praha: Vydavatelství VUT, druhé vydání, 2003, ISBN 80-01-02789-9. [9] RICHTA, K.: Softwarové inºenýrství, 2005, materiály k p°edná²kám z p°edm¥tu 36SI. [10] SCHOLTZ, B. L.: The BalusC Code: Code depot of a Java EE / JSF developer. 2008, [Online]. URL http://balusc.blogspot.com/. [11] Hibernate.org: Relational Persistence for Java and .NET. 2006, [Online]. URL http://www.hibernate.org. [12] Hibernate.org: Open Session in View. 2006, [Online]. URL http://www.hibernate.org/43.html. [13] MyFaces Tomahawk for JSF 1.2 - Tag library documentation. 2008, [Online], Verze 1.2, [rev. 16.10.2008]. URL http://myfaces.apache.org/tomahawk-project/tomahawk12/tagdoc.html.

80

KAPITOLA 8. LITERATURA

PÍLOHA A. SEZNAM POUITÝCH ZKRATEK

A Seznam pouºitých zkratek API Application Programming Interface CSS Cascading Style Sheets DAO Data Access Object DFS Depth-First Search DOM Document Object Model DTO Data Transfer Object EL Unied Expression Language GML Generalized Markup Language HQL Hibernate Query Language HTML HyperText Markup Language HTTP Hypertext Transfer Protocol IDE Integrated Development Environment Java EE Java Enterprise Edition JDBC Java Database Connectivity JDK Java Development Kit JPA Java Persistence API JRE Java Runtime Environment JSF JavaServer Faces JSP JavaServer Pages JSTL JavaServer Pages Standard Tag Library MVC Model-View-Controller ORM Object-Relational Mapping PDF Portable Document Format RMMM Risk Mittigation, Monitoring and Management RTF Rich Text Format SQL Structured Query Language UI User Interface UML Unied Modeling Language UP Unied Process W3C World Wide Web Consortium XHTML eXtensible HyperText Markup Language XML eXtensible Markup Language XSD XML Schema Denition XSL eXtensible Stylesheet Language XSL-FO eXtensible Stylesheet Language Formatting Objects XSLT eXtensible Stylesheet Language Transformations

81

82

PÍLOHA A. SEZNAM POUITÝCH ZKRATEK

PÍLOHA B. SEZNAM POJM

83

B Seznam pojm· Aplika£ní vrstva (Application layer) základ aplikace spojující prezenta£ní vrstvu s integra£ní a business vrstvou. V JSF jsou objekty vrstvy tzv. Backing Beans, které jsou navrºeny pro obsluhu JSF formulá°· a obsahují metody jako poslucha£e (listenery) a metody provád¥jí akce s daty podle pokyn· prezenta£ní vrstvy, tedy uºivatele.

Backing Bean objekt Java Bean ur£ený pro framework JSF a navrºený pro aplika£ní vrstvu, kde navíc obsahuje obsluhu událostí. Backing Bean, jako sou£ást aplika£ní logiky, poskytuje, získává a manipuluje s daty (gettery a settery) ur£enými pro prezenta£ní vrstvu aplikace. Pro p°ístup k dat·m vyuºívá integra£ní vrstvu.

Business vrstva (Business layer) obsahuje objekty doménového modelu, tzv. DAO objekty. T°ídy a jejich instance (objekty) nev¥dí nic o vy²²ích vrstvách, o frameworcích, o webu.

DAO (Data Access Object) objekt, který p°istupuje k dat·m, provádí manipulace s úloºi²t¥m dat. Obsahuje metody, které z databáze získávají data - v na²em p°ípad¥ objekty DTO, seznamy t¥chto objekt· (List) nebo hash tabulky. Dále obsahuje metody, které data do databáze vkládají £i upravují. DAO objekty m·ºou p°istupovat p°ímo k databázi (nap°. pomocí JDBC, zde je v²ak pot°eba vlastní persistentní podpora) nebo mohou vyuºívat ORM framework, který rela£ní data na objekty namapuje sám. Viz Hibernate, ORM.

Doménový model (Domain model) p°i pouºití ORM (Hibernate, JTA, . . . ) se implementuje doménový model pomocí business objekt· DTO (POJO). V UML se k jeho reprezentaci pouºívá diagram t°íd. Je objektovým ekvivalentem k rela£nímu fyzickému modelu. Taktéº se nazývá diagramem t°íd, objektovým modelem.

DTO (Data Transfer Object) je Java Bean objekt pro business vrstvu. Navíc m·ºe objekt obsahovat pro výpo£et dal²ích vlastností, tzv. business metody.

EJB3 (Enterprise JavaBean) architektura zaloºená na komponentech (modulech) pro vývoj a nasazování objektov¥ orientovaných, distribuovaných, podnikových aplikací. Od verze 3 je pro persistenci dat jeho sou£ástí JPA.

EL (Unied Expression Language) jazyk odvozený od jazyku JSTL pouºívaný ve frameworku JSF pro vkládání výraz· a manipulaci s Managed Beans v prezen£ní logice.

Fyzický model popisuje data, datové typy, vztahy mezi daty a integritní omezení v datovém úloºi²ti. Vychází z konceptuálního modelu.

Getter ve°ejná metoda, která ned¥lá nic jiného, neº ºe vrátí hodnotu vnit°ního - soukromého atributu objektu. Tato technologie se pouºívá v celé problematice Java EE (MVC, ORM, . . . ). Nap°íklad, pro atribut se jménem "ºádost"se metoda jmenuje "getádost". Synonymum: accessor.

Hibernate z°ejm¥ nejpouºívan¥j²í ORM framework pro platformu Java. Lze jej pouºít jak v samostatných aplikacích, tak v Java EE aplikacích se servlety. Obsahuje vlastní dotazovací jazyk HQL, lze v²ak pouºít i nativní SQL. S databází komunikuje p°ímo pomocí SQL dotaz· bez pot°eby správy JDBC objekt·.

HQL (Hibernate Query Language) dotazovací jazyk syntakticky podobný SQL, ale je pln¥ objektov¥ orientovaný.

Integra£ní vrstva objekty v této vrstv¥ jsou zodpov¥dné za získávání dat z datového úloºi²t¥ nebo z persistentní vrstvy (v na²em p°ípad¥). Tyto objekty jsou DAO objekty a jsou to v¥t²inou tzv. singletony, coº znamená, ºe v aplikaci je pouze jediná jejich instance. Integra£ní vrstva vlastn¥ spojuje persistentní vrstvu s business vrstvou tak, ºe pomocí svých metod plní objekty business vrstvy daty z persistentní vrstvy. Synonyma: Data layer (datová vrstva).

Java EE (Java 2 Platform, Java Enterprise Edition, J2EE) serverová platforma pro vývoj aplikací v programovacím jazyce Java. Pouºívá servlety, jsp.

Java Bean objekt nesoucí data a poskytující p°ístup k t¥mto dat·m. Samotná data (atributy) jsou privátní a k jejich p°ístupu se pouºívají ve°ejné (public) gettery a settery. N¥kdy se pro Java Bean pouºívají termíny POJO (Plain Old Java Object), VO (Value Object) nebo DTO.

84

PÍLOHA B. SEZNAM POJM

JDBC (Java Database Connectivity) rozhraní pro programovací jazyk Java, které specikuje, jak má klient (aplikace) p°istupovat k rela£ní databázi. Obsahuje metody pro dotazy a úpravu dat v databázi.

JDO (Java Data Object) specikace objektové persistence a pr·chodnosti dat, na rozdíl od JPA, nejen pro rela£ní databáze.

JPA (Java Persistence API) standardní rozhraní v programovacím jazyce Java pro persistenci rela£ních dat. Je jednou ze sou£ástí specikace EJB3. P°ebírá plno nápad· z Hibernate. Hibernate implementuje JPA.

JSF (JavaServer Faces) MVC Java webový framework zaloºený na komponentech - hierarchii komponent· a událostech. Pro prezenta£ní logiku se m·ºe pouºít nap°íklad JSP, pro vkládání výraz· a manipulaci s daty v prezen£ní logice vyuºívá jazyk EL. Aplika£ní logika je °ízena tzv. Managed Beans. Standardn¥ dodáván v Java EE.

JSP (JavaServer Pages) Java technologie pro tvorbu dynamických stránek. Kaºdá JSP stránka se p°evádí na servlet, má tedy v²echny schopnosti, jako servlet. M·ºe obsahovat p°ímo Java kód nebo pouºít jazyk JSTL. JSP lze p°irovnat ke skriptovacímu jazyku PHP.

JSTL (JavaServer Pages Standard Tag Library) komponenta Java EE webové vývojové platformy. Roz²i°uje specikaci JSP p°idáním knihovny tag· pro b¥ºné úlohy, jako jsou podmínky, cykly, vícejazy£ná podpora, p°ístup k databázi.

Konceptuální model (Conceptual model) popisuje entity systému a relace - vztahy mezi entitami z pohledu v¥t²í abstrakce, bez detail·. V rela£ním fyzickém modelu jsou entity tabulkami. V objektov¥ orientovaném pohledu se z entit stávají t°ídy. Pouºívá se v analýze.

Managed Bean je objekt Backing Bean, který je nastaven v kongura£ním souboru a m·ºe k n¥mu p°ímo p°istupovat prezenta£ní vrstva. Slouºí k integraci s UI komponenty.

MVC (Model-view-controller) framework. Vzor architektury po£íta£ových systém· zaloºený na odd¥lení aplikací a prezenta£ní logiky. Frameworky MVC pro Javu nap°. JSF, Struts, String.

ORM (Object-relational mapping) framework, který mapuje objektov¥ orientovaný model dat na tradi£ní rela£ní data pouºívaná v rela£ních databázích. Více viz Hibernate.

Persistentní vrstva (Persistence layer) odpovídá za správné namapování business objekt· DTO s tabulkami v rela£ní databázi. Tuto vrstvu m·ºe zastupovat ORM framework Hibernate.

Prezenta£ní vrstva (UI layer) spojení, ale zárove¬ vývojová nezávislost s aplika£ní vrstvou jsou dány frameworky MVC (v na²em p°ípad¥ JSF). Obsahují design aplikace, pracují s komponenty, spou²t¥jí události, které jsou obsluhovány aplika£ní vrstvou.

Servlet je objekt, který umoº¬uje vytvá°et dynamický obsah webové aplikace. M·ºe generovat b¥ºný HTML nebo XML kód.

Setter ve°ejná metoda, která nastaví hodnotu vnit°ního - soukromého atributu. Nap°íklad, pro atribut se jménem "ºádost"se metoda jmenuje "setádost". Synonymum: mutator.

SQL (Structured Query Language) strukturovaný dotazovací jazyk pouºívaný v rela£ních databázích.

PÍLOHA C. INSTALANÍ PÍRUKA PRO OS WINDOWS XP

85

C Instala£ní p°íru£ka pro OS Windows XP Aplikace je vytvo°ena pomocí programovacího jazyka Java EE 5 SDK, testována na servletovém kontejneru Apache Tomcat 6 a propojena s rela£ní databází MySQL 5. Na stanici, kde má aplikace b¥ºet, musí být nainstalováno prost°edí Java. Posta£uje bu¤ Java SE Runtime Environment (JRE) verze 5 a vy²²í nebo je moºné pouºít celý balík Java SE Development Kit (JDK). Dále je pot°eba spu²t¥ný Java servletový kontejner. Administrátor p°ístup k databázovému stroji. Aplikace pouºívá pro p°ístup k databázi knihovnu Hibernate, která umí spolupracovat s r·znými rela£ními databázemi1 . Následuje popis instalací uvedených open-source softwar· na opera£ním systému Windows XP.

C.1

Instalace prost°edí Java SE Runtime Environment (JRE) 6 Update 11 (leden 2009)

Z adresy http://java.sun.com/javase/downloads/ stáhnout aktuální verzi JRE pro OS Windows. Nainstalovat JRE podle instrukcí. Ponechat výchozí nastavení. Vytvo°it novou systémovou prom¥nnou JRE_HOME a nastavit její hodnotu na c:\Program Files\Java\jre6. Systémové prom¥nné: Start > Ovládací panely > Systém > Up°esnit > Prom¥nné prost°edí > Systémové prom¥nné > Nová.

C.2

Instalace kontejneru Apache Tomcat 6.0.18 (leden 2009)

Z domovských stránek projektu http://tomcat.apache.org/download-60.cgi stáhnout nejnov¥j²í verzi pro OS Windows. Nainstalovat Apache Tomcat podle instrukcí. Ponechat výchozí nastavení. Pouºitý port je 8080. V systray (pravý dolní roh) je ikona Apache Tomcat. Dvojklikem otev°ít okno Apache Tomcat Properties. V záloºce General ve spodní £ásti kliknout na tla£ítko Start. Kontejner se spustí. Je-li kontejner správn¥ spu²t¥n, zobrazí se po zadání adresy http://localhost:8080 do webového prohlíºe£e úvodní stránka se symbolem kocoura a s textem Congratulations!. V záloºce General ve spodní £ásti kliknout na tla£ítko Stop. Kontejner se zastaví.

C.3

Instalace databáze MySQL 5.1.3 (leden 2009)

Z domovských stránek stáhnout nejnov¥j²í verzi pro OS Windows: http://dev.mysql.com/downloads/. Spustit instalaci, zvolit typ instalace Typical installation. Po instalaci nechat za²krtnuté Congure the MySQL Server now. Potvrdit. Zvolit Standard conguration. Port bude nastaven na 3306. Vyplnit administrátorské heslo root. Potvrdit. Server se spustí. 1

Seznam podporovaných databází: http://www.hibernate.org/80.html

86

PÍLOHA C. INSTALANÍ PÍRUKA PRO OS WINDOWS XP

C.4

Vytvo°ení databáze s tabulkami

Spustit MySQL Command Line Client. P°i standardní instalaci se nachází v Start > V²echny programy > MySQL > MySQL Server 5.0 > MySQL Command Line Client. Zadat heslo: root. P°íkazem vytvo°it databázi, pokud je pod d: CD mechanika s vloºeným CD aplikace:

\. d:\database\create.sql Naplnit databázi zku²ebními daty:

\. d:\database\insert_into_forms.sql \. d:\database\insert_into_users.sql

Poznámka :

Je t°eba zvolit kódování souboru takové, jaké podporuje správce databáze. Je moºné pouºít jiného správce databáze, neº MySQL Command Line Client. Vhodnou alternativou je nap°. phpMyAdmin2 . C.5

Nahrání aplikace do kontejneru

Do adresá°e $CATALINA_HOME/webapps (kde $CATALINA_HOME/ je ve výchozím nastavení c:\Program Files\Apache Software Foundation\Tomcat 6.0\) vloºit soubor d:\webapps\insypopepo.war, pokud je pod d: CD mechanika s vloºeným CD aplikace. Spustit kontejner Apache Tomcat. Kontejner sám extrahuje aplikaci z archivu war do nového adresá°e insypopepo, který umístí do adresá°e $CATALINA_HOME/webapps. Zkontrolovat údaje pro p°ipojení k databázi v souboru $CATALINA_HOME/webapps/insypopepo/ WEB-INF/classes/hibernate.cfg.xml. Je-li pouºit server MySQL a databáze je na adrese localhost:3306/insypopepo a p°ístup k ní pomocí root/root, pak kongura£ní soubor musí obsahovat následující °ádky: <property <property <property <property <property

name="hibernate.dialect">org.hibernate.dialect.MySQLDialect name="hibernate.connection.driver_class">com.mysql.jdbc.Driver name="hibernate.connection.url">jdbc:mysql://localhost:3306/insypopepo name="hibernate.connection.username">root name="hibernate.connection.password">root

Pokud byl soubor hibernate.cfg.xml zm¥n¥n, je pot°eba restartovat aplikaci nebo restartovat kontejner Apache Tomcat. C.6

Spu²t¥ní aplikace

Aplikace se spustí zadáním následující adresy ve webovém prohlíºe£i:

http://localhost:8080/insypopepo 2

http://www.phpmyadmin.net

87

PÍLOHA D. UIVATELSKÁ PÍRUKA

D Uºivatelská p°íru£ka Uºivatelská p°íru£ka webové aplikace je ur£ena v²em uºivatel·m, kte°í budou s aplikací pracovat. Nejd°íve jsou uvedeny obecné informace. Následuje popis funkcí pro jednotlivé uºivatelské role.

D.1

P°ihlá²ení uºivatele

Pro p°ístup k aplikaci je pot°eba standardní webový prohlíºe£, nejlépe s podporou technologie Javascript.

1

Není to v²ak podmínkou. Po zadání webové adresy , ur£ující umíst¥ní aplikace, se zobrazí p°ihla²ovací

2

stránka. Zde je pot°eba vyplnit správné p°ihla²ovací jméno a heslo . Viz obr. D.1.

Obrázek D.1: Úvodní stránka aplikace s p°ihla²ovacím formulá°em.

D.2

Navigace v aplikaci - hlavi£ka aplikace

Po úsp¥²ném p°ihlá²ení se zobrazí stránka taková, jakou má uºivatel roli. V²echny stránky pro v²echny uºivatele v²ak mají stejnou hlavi£ku, pouze s odli²nými volbami pro dal²í práci. Viz obr. D.2.

Obrázek D.2: Hlavi£ka aplikace spolu s volbami.

D.3

Odhlá²ení uºivatele

Je doporu£eno se po ukon£ení práce odhlásit z aplikace. Tím se zabrání zneuºití p°ihlá²eného uºivatele k jiným £innostem, neº provedl uºivatel. Odhlá²ení prob¥hne stiskem posledního tla£ítka vpravo v menu aplikace (viz obr. D.2). 1 2

pokud adresu neznáte, obra´te se na p°íslu²né odd¥lení va²í spole£nosti pokud n¥který z údaj· neznáte, obra´te se na p°íslu²né odd¥lení va²í spole£nosti

88


D.4

Role uºivatel·

Kaºdý uºivatel systému m·ºe nabývat následujících rolí. N¥které jsou p°id¥lené systémem, jiné p°i°azuje správce aplikace (odd¥lení po rozvoj lidských zdroj·). V hlavi£ce u p°ihlá²eného uºivatele jsou role zobrazeny (viz obr. D.2). Následuje seznam t¥chto rolí, podrobný popis následuje dále.

Zam¥stnanec kaºdý uºivatel systému má roli zam¥stnance. Více viz kap. D.7. Manaºer má-li zam¥stnanec pod°ízené, je manaºerem, má roli manaºer. Více viz kap. D.8. Nám¥stek pro lidské zdroje (manaºer pro lidské zdroje, mlz, N-RLZ, angl. mhr) je jeden v systému, kaºdou ºádost musí nakonec schválit on. Je zárove¬ adminem a referentem, neeviduje v²ak ºádosti. Volí adminy a referenty, m¥ní N-RLZ. Více viz kap. D.9.

Referent Kaºdý uºivatel systému má referenta spravujícího jeho personální ºádosti. Referent eviduje ºádosti, spravuje uºivatele, tvo°í/maºe/upravuje uºivatele. Více viz kap. D.10.

Admin Spravuje formulá°e, vkládá nové formulá°e. Více viz kap. D.11.

D.5

Seznamy a detaily ºádostí

Seznamy ºádostí / Tisk seznam· jsou tabulky s ºádostmi, které jsou v n¥jakém vztahu k uºivateli. Podle role uºivatele jsou povoleny p°íslu²né operace s ºádostmi. Seznam ºádostí lze t°ídit, stránkovat a ltrovat a také tisknout. Viz obr. D.3.

Detail ºádosti / Tisk ºádosti kaºdý uºivatel systému m·ºe ºádosti, ke kterým má p°ístup, prohlíºet a tisknout. Viz obr. D.4.

Obrázek D.3: P°íklad seznamu ºádostí spolu s ltrováním a stránkováním seznamu.

D.5.1

Filtrování seznam· ºádostí podle kritérií

Seznam ºádostí lze ltrovat pomocí následujících kritérií (viz horní £ást obr. D.3):

Stav ºádosti Lze vybrat jakoukoli podmnoºinu stav·, ve kterých ze ºádosti vyskytují. Jsou to stavy £eká na podání, £eká na schválení, £eká na schválení N-RLZ, £eká na zaevidování, zaevidováno a zamítnuto.

ádosti uºivatel· v£etn¥ Ur£uje zda se zobrazí i ºádosti, které se týkají odstran¥ných zam¥stnanc· a ºádosti, které podali odstran¥ní podávající (manaºe°i).

ádosti podané oddo - asové vymezení, kdy ºádost byla podána. Omezení lze potla£it na obou stranách.

ádosti posledn¥ zm¥n¥né oddo - asové vymezení, kdy ºádost byla naposledy zm¥n¥na. Omezení lze potla£it na obou stranách.

Formulá° ºádosti - Lze vybrat podmnoºinu ºádostí podle typ· formulá°·. Dle referenta - Lze vybrat podmnoºinu ºádostí podle referenta, kterého má zam¥stnanec, kterého se ºádost týká.


89

Obrázek D.4: P°íklad detailu ºádosti.

D.6

Seznamy a detaily uºivatel·

Seznamy uºivatel· / Tisk seznam· - jsou tabulky s uºivateli, které jsou v n¥jakém vztahu k uºivateli. Podle role uºivatele jsou povoleny p°íslu²né operace s uºivateli. Seznam uºivatel· lze t°ídit, stránkovat a ltrovat a také tisknout.

Hierarchické seznamy uºivatel· - jsou speciální tabulky, které p°ehledn¥ znázor¬ují vztahy nad°ízenýpod°ízený mezi uºivateli. Tabulky obsahují odkazy, které vedou na detaily p°íslu²ného uºivatele. Viz obr.

Detail uºivatele/Tisk uºivatele kaºdý uºivatel systému m·ºe uºivatele, ke kterým má n¥jaký vztah (nad°ízený/pod°ízený), prohlíºet a tisknout.

D.7

Role zam¥stnanec

Kaºdý uºivatel systému má roli zam¥stnanec. Zam¥stnanec má následující volby:

Moje ºádosti - Seznam v²ech ºádostí (viz D.5), které se týkají zam¥stnance, tedy t¥ch, které pro n¥j podal jeho nad°ízený (neplatí pro nejvy²²í management, viz Poznámka)

Uºivatelé > Seznam uºivatel· Seznam v²ech uºivatel· (viz D.6), ke kterým má zam¥stnanec n¥jaký vztah. Vedle v²ech jeho nad°ízených a pod°ízených jsou zde uvedeni jeho referent a nám¥stek v otázce personální (. . . pro lidské zdroje).

Uºivatelé > M·j prol (úpravy) - Detail p°ihlá²eného uºivatele, kde si m·ºe mj. zm¥nit své heslo. Zm¥na hesla - V Uºivatelé > M·j prol (úpravy) m·ºe uºivatel zm¥nit své p°ístupové heslo. Detail ºádosti - viz D.5 Detail uºivatele - viz D.6

90


Obrázek D.5: P°íklad seznamu uºivatel· spolu s hierarchickým seznamem uºivatel·.

Obrázek D.6: P°íklad detailu uºivatele.

Poznámka : Pokud je uºivatel nejvy²²ím manaºerem, neboli nemá nad°ízeného z pohledu schvalování personální ºádosti (v¥t²inou nám¥stci), nem·ºe pro n¥j nikdo ºádost vyplnit (nemá totiº nad°ízeného). Personálními ºádostmi nejvy²²ího managementu se aplikace nezabývá.

D.8

Role manaºer

Uºivatel, který má alespo¬ jednoho pod°ízeného, má roli manaºer. Vedle voleb pro zam¥stnance (kaºdý uºivatel systému má roli zam¥stnance) má manaºer dal²í volby:

Nová ºádost - Po zvolení p°íslu²né ºádosti manaºer pro svého pod°ízeného vyplní ºádost, p°ipojí zd·vodn¥ní ºádosti, ºádá-li o konzultaci s personálním odd¥lení a nepovinné datum projednání se zam¥stnancem. Vypln¥nou ºádost m·ºe zru²it, zatím nepodávat nebo podat (viz dále).

ádosti > ádosti ke schválení/podání Seznam ºádostí (viz D.5), které bu¤ £ekají na manaºerovo podání (vlastních ºádostí) nebo schválení (ºádostí podaných jeho pod°ízenými). Dále nabídka obsahuje volbu Vyberte formulá° pro volbu nové ºádosti (stejná jako volba Nová ºádost, viz vý²e).


91

ádosti > ádosti pod°ízených - Seznam v²ech ºádostí (viz D.6), které podali manaºerovy pod°ízení a on sám pro své p°ímé pod°ízené.

Podat / zru²it ºádost - Manaºer m·ºe vytvo°enou ºádost bu¤ zru²it (bude smazána bez náhrady, objevil-li nap°íklad chybu) nebo podat. Po podání ºádosti jiº na ni manaºer nebude mít ºádný vliv, ºádost £eká na schválení/zamítnutí dal²ím uºivatelem (nad°ízeným manaºera; nám¥stka pro lidské zdroje, pokud uº je ºádost schválena nejvy²²ím managementem; referentem, pokud je ºádost schválena nám¥stkem pro lidské zdroje).

Schválit / zamítnout ºádost - Doputovala-li ºádost, kterou podal manaºer·v pod°ízený, k n¥mu, manaºer ºádost zamítne nebo schválí. V obou p°ípadech m·ºe p°ipojit svou poznámku. Pokud ºádost zamítne, ta p°estane putovat dále a dostává se do stavu zamítnuto. Pokud ji schválí, ºádost pokra£uje a £eká na schválení/zamítnutí dal²ím uºivatelem (nad°ízeným manaºera; nám¥stka pro lidské zdroje, pokud uº je ºádost schválena nejvy²²ím managementem; referentem, pokud je ºádost schválena nám¥stkem pro lidské zdroje).

D.9

Role nám¥stek pro lidské zdroje

Nám¥stek pro lidské zdroje (dále jen N-RLZ) je v systému vºdy a pouze jeden. Ovládá celou aplikaci a je zárove¬ referentem a administrátorem. Vedle voleb pro referenta (viz. D.10) a voleb pro administrátora (viz. D.11) má navíc následující volby:

Správa ºádostí > ádosti ke schválení N-RLZ - Seznam ºádostí (viz D.5), které £ekají na schválení nám¥stkem pro lidské zdroje N-RLZ. V²echny ºádosti ve spole£nosti musejí být p°ed zaevidováním odsouhlaseny N-RLZ. Jeho schválení je tedy p°edposeldním krokem k uplatn¥ní ºádosti.

Správa uºivatel· > Zm¥nit N-RLZ - Nám¥stek pro lidské zdroje N-RLZ m·ºe delegovat touto funkcí jiného nejvy²²ího uºivatele. Po potvrzení volby v²ak nyn¥j²í uºivatel ztrácí roli N-RLZ a s tím spojené v²echny pravomoci (tedy i pravomoc na zm¥nu N-RLZ) a bude odhlá²en od systému. Je to tedy volba nevratná pro p°ihlá²eného uºivatele. Pokud není v seznamu nejvy²²ích manaºer· osoba, kterou chce uºivatel zvolit, je pot°eba tuto osobu nejd°íve zaloºit pomocí volby Správa uºivatel· > Nový uºivatel (nový vedoucí).

Schválit / zamítnout ºádost N-RLZ - Doputovala-li ºádost k N-RLZ, ten ºádost zamítne nebo schválí. V obou p°ípadech m·ºe p°ipojit svou poznámku. Pokud ºádost zamítne, ta p°estane putovat dále a dostává se do stavu zamítnuto. Pokud ji schválí, ºádost pokra£uje k zaevidování k referentovi zam¥stnance, kterého se ºádost týká.

P°id¥lit / odebrat roli referent - V úprav¥ uºivatele (Správa uºivatel· > Správa uºivatel· volba upravit u konkrétního uºivatele - viz D.10.1) m·ºe za²krtnutím p°íslu²ného pole delegovat uºivatele rolí referent. Doty£ný uºivatel po novém p°ihlá²ení získává roli referenta.

P°id¥lit / odebrat roli admin - V úprav¥ uºivatele (Správa uºivatel· > Správa uºivatel· - volba upravit u konkrétního uºivatele - viz D.10.1) m·ºe za²krtnutím p°íslu²ného pole delegovat uºivatele rolí administrátor. Doty£ný uºivatel po novém p°ihlá²ení získává roli administrátora.

Zm¥nit referenta - N-RLZ m·ºe kaºdému uºivateli ve správ¥ uºivatel· Správa uºivatel· > Správa uºivatel· zm¥nit referenta. Uºivateli m·ºe p°i°adit jakéhokoli aktivního referenta. M·ºe také zvolit, zda jej p°i°adí pouze uºivateli nebo i jeho pod°ízeným (pokud n¥jaké má).

D.10

Role referent

V systému m·ºe být n¥kolik uºivatel· s rolí referent. Kaºdý uºivatel systému má svého referenta (... pro lidské zdroje). Ten eviduje uºivatelovy ºádosti. Dále upravuje v²echny uºivatele, kte°í pod n¥j pat°í a spravuje jejich umíst¥ní v uºivatelské hierarchii. Nakonec spravuje v²echny ºádosti. M·ºe ltrovat jejich seznamy a tisknout v²echny detaily.

Správa ºádostí > Správa ºádostí - Seznam v²ech ºádostí (viz D.5). Je moºné ltrovat ºádosti podle r·zných kritérií a tisknout tyto seznamy.

Správa ºádostí > ádosti k zaevodvání - Seznam ºádostí (viz D.5), které £ekají na zaevidování referentem. Referent eviduje v²echny ºádosti, které se týkají zam¥stnanc·, kte°í ho mají uvedeného jako referenta.

92


Správa uºivatel· > Správa uºivatel· - Seznam v²ech uºivatel· spolu s hierarchickými tabulkami uºivatel· pro zobrazení vztah· nad°ízený-pod°ízený ve spole£nosti. Ve správ¥ uºivatel· lze uºivatele upravovat a dále manipulovat s ním v rámci hierarchie uºivatel·. Podrobn¥ popsáno v kap. D.10.1 - Správa hierarchie uºivatel·.

Správa uºivatel· > Nový uºivatel (nový vedoucí) - Volba pro vytvo°ení nového vedoucího. Tedy takového uºivatele, který nemá ºádného nad°ízeného. Proto nelze pouºít volbu pro vytvo°ení pod°ízeného (Správa uºivatel· > Správa uºivatel· - volba vytvo°it pod°ízeného u konkrétního uºivatele - viz D.10.1). Uºivatel bude ko°enem nového stromu.

Zaevidovat ºádost - Doputovala-li ºádost k referentovi, ten ºádost zaeviduje. Evidence ºádosti je posledním krokem p°ed realizací p°íslu²né personální zm¥ny.

Upravit uºivatele V Správa uºivatel· > Správa uºivatel· m·ºe referent u kaºdého uºivatele (jehoº je referentem) upravit prol uºivatele pomocí volby upravit.

Detail ºádosti - viz D.5 Detail uºivatele - viz D.6

D.10.1

Správa hierarchie uºivatel·

Kaºdý uºivatel je v hierarchii vázán na ostatní uºivatele. Systém umoº¬uje m¥nit tuto hierarchii, aby vºdy odpovídala aktuální situaci ve spole£nosti. Seznam voleb pro manipulaci uºivatel· v hierarchii je popsán v této kapitole. Konkrétní volby jsou u kaºdého uºivatele v seznamu v²ech uºivatel· Správa uºivatel· > Správa uºivatel·. V¥t²inou následuje soubor propojených stránek (wizard), ve kterém se referent m·ºe pohybovat dop°edu a dozadu nebo zru²it kompletn¥ provád¥nou £innost:

Zam¥nit s uºivatelem - Zobrazí se nabídka pro volbu druhého uºivatele, se kterým bude vybraný uºivatel zam¥n¥n. Pozice uºivatel· bude kompletn¥ zam¥n¥na. Tedy, pod°ízení bývalého uºivatele budou nyní pod°ízenými nového uºivatele, a naopak. Nad°ízený bývalého uºivatele bude nyní nad°ízeným nového uºivatele, a naopak.

Vytvo°it pod°ízeného - První stránka zobrazí nabídku, zda zaloºit úpln¥ nového pod°ízeného nebo obnovit uºivatele, který jiº d°íve v systému byl. Po této volb¥ následuje formulá° pro vypln¥ní nového / potvrzení údaj· u starého uºivatele. Po potvrzení bude uºivatel za°azen pod svého vedoucího vpravo od ostatních p°ímých pod°ízených. Referent uºivatele bude nastaven na referenta nad°ízeného.

Odstranit Uºivatele lze z hierarchie odstranit. Nebude v²ak odstran¥n ze systému, pouze nebude za°azen v hierarchii a nebude se moci p°ihlásit. Pokud uºivatel není manaºerem (není vedoucím ºádným jiným uºivatel·m), uºivatel se odstraní jednodu²e. Pokud je uºivatel manaºerem, je pot°eba zvolit, co se provede s jeho pod°ízenými (viz obr. D.7):

Obrázek D.7: Volby pro odstran¥ní manaºera z hierarchie uºivatel·. nahradit manaºera novým uºivatelem - zobrazí se formulá° pro vytvo°ení nového uºivatele podobn¥ jako v kroku Vytvo°it pod°ízeného,

93


nahradit manaºera obnovením odstran¥ného uºivatele - na£t¥ se zvolený odstran¥ný uºivatel a zobrazí se formulá° pro potvrzení údaj· uºivatele podobn¥ jako v kroku Vytvo°it pod°ízeného,

p°e°adit v²echny pod°ízené pod vy²²ího manaºera - novým vedoucím pro p°ímé pod°ízené p°e°azovaného manaºera bude bývalý vedoucí tohoto manaºera. Neboli, otec zem°el, syny vychová d¥da,

p°e°adit v²echny pod°ízené pod jiného uºivatele - manaºer bude p°e°azen pod zvoleného uºivatele a v²ichni jeho pod°ízení budou p°e°azeni pod jiného (v dal²í nabídce) zvoleného uºivatele,

odstranit v²echny pod°ízené - v²ichni pod°ízení budou odstran¥ni z hierarchie. Nebudou v²ak odstran¥ni ze systému, pouze nebudou za°azeni a nebudou se moci p°ihlásit,

nahradit manaºera pod°ízeným uºivatelem

- tato volba není do systému zaimplementována.

Pokud chcete nahradit manaºera pod°ízeným, pouºijte moºnost zam¥nit s uºivatelem. Zam¥¬te manaºera s pod°ízeným. Pokud má pod°ízený je²te pod°ízené, opakujte zám¥nu aº do té doby, neº se manaºer, kterého chcete odstranit, dostane na úrove¬, ºe uº nemá ºadné pod°ízené.

P°e°adit Uºivatele v hierarchii lze p°e°adit pod nového vedoucího. Pokud uºivatel není manaºerem (není vedoucím ºádných jiných uºivatel·), uºivatel se jednodu²e p°esune od starého vedoucího pod vedoucího nového, který byl zvolen v objev²íse nabídce. Pokud je uºivatel manaºerem, je pot°eba zvolit, jak bude p°e°azen, co se provede s jeho pod°ízenými (podobn¥ jako na obr. D.7 pro odstran¥ní uºivatele):

nahradit manaºera novým uºivatelem - zobrazí se formulá° pro vytvo°ení nového uºivatele podobn¥ jako v kroku Vytvo°it pod°ízeného,

nahradit manaºera obnovením odstran¥ného uºivatele - na£t¥ se zvolený odstran¥ný uºivatel a zobrazí se formulá° pro potvrzení údaj· uºivatele podobn¥ jako v kroku Vytvo°it pod°ízeného,

p°e°adit také v²echny pod°ízené - pod nového vedoucího se p°e°adí vedle manaºera paté v²ichni jeho pod°ízené tak, ºe podstrom tvo°ený tímto manaºerem se nezm¥ní,

p°e°adit v²echny pod°ízené pod vy²²ího manaºera - novým vedoucím pro p°ímé pod°ízené p°e°azovaného manaºera bude bývalý vedoucí tohoto manaºera. Neboli, otec zem°el, syny vychová d¥da,

p°e°adit v²echny pod°ízené pod jiného uºivatele - manaºer bude p°e°azen pod zvoleného uºivatele a v²ichni jeho pod°ízení budou p°e°azeni pod jiného (v dal²í nabídce) zvoleného uºivatele,

odstranit v²echny pod°ízené - v²ichni pod°ízení budou odstran¥ni z hierarchie. Nebudou v²ak odstran¥ni ze systému, pouze nebudou za°azeni a nebudou se moci p°ihlásit,

nahradit manaºera pod°ízeným uºivatelem

- tato volba není do systému zaimplementována.

Pokud chcete nahradit manaºera pod°ízeným, pouºijte moºnost zam¥nit s uºivatelem. Zam¥¬te manaºera s pod°ízeným. Pokud má pod°ízený je²te pod°ízené, opakujte zám¥nu aº do té doby, neº se manaºer, kterého chcete odstranit, dostane na úrove¬, ºe uº nemá ºadné pod°ízené.

D.11

Role administrátor

Roli admininstrátor p°id¥luje nám¥stek pro lidské zdroje jakémukoli uºivateli. Admin má k dispozici následující operace:

Správa formulá°· > Správa formulá°· - Seznam v²ech formulá°· p°ítomných v systému. Uºivatel m·ºe kaºdý formulá° aktivovat/deaktivovat, prohlíºet jeho detail, smazat ho, uloºit jeho XML kód na lokální disk.

Správa formulá°· > Vloºit formulá° Systém umoº¬uje vkládání nových formulá°· ºádostí. Formulá° vytvo°í uºivatel lokáln¥ na svém po£íta£i a nahraje jej na server. Systém zkontroluje (validace), zda je formulá° napsán správn¥ syntakticky a na p°ípadnou chybu upozorní. Poté vygeneruje podle ²ablon výsledný kód a uloºí formulá° na server.

94


D.11.1

Správa formulá°·

Seznam v²ech formulá°· p°ítomných v systému. Uºivatel m·ºe kaºdý formulá° aktivovat/deaktivovat, prohlíºet jeho detail, smazat ho, uloºit jeho XML kód na lokální disk. Formulá°e nesou informaci o své lokalizaci (viz kap. D.11.5). Správa obsahuje také vstupní pole pro vloºení nového formulá°e (viz kap. D.11.1). Volby u kaºdého formulá°e jsou následující:

jazyk formulá°e uºivateli, který chce vytvo°it novou ºádost, se zobrazí na výb¥r pouze formulá°e v jazyce, ve kterém zrovna b¥ºí aplikace

aktivovat/deaktivovat pokud je formulá° deaktivovaný, nelze jej pouºít pro vytvo°ení nové ºádosti detail zobrazí formulá°, jak bude vypadat v ºádosti smazat formulá° lze smazat pouze v p°ípad¥, neexistuje-li ºádost, která tento formulá° obsahuje. Tato funkce se tedy z pravidla vyuºije, pokud admin zjistí, ºe v novém formulá°i ud¥lal chybu

stáhnout na disk - je moºné XML kód formulá°e stáhnout na disk

Obrázek D.8: Správa formulá°·.

D.11.2

Syntaxe formulá°e (XML Schema)

Formulá° je standardní XML soubor. Na za£átku tedy musí obsahovat hlavi£ku s kódováním (nejlépe unicode UTF-8):

Samotná syntaxe je následující:

(name{1} = string(5,100), short-name{1} = string(5,100), group{1,10})
Ko°enový element a

. • • • •

je komplexní datový typ, který obsahuje elementy

, <short-name>

Integritní omezení:

Po°adí element· je pevn¥ dáno element· element· element·

Element omezení:

je jeden <short-name> je jeden je 1 aº 10

je datového typu

string

(znakový °et¥zec) a obsahuje název formulá°e. Integritní

95


•

po£et znak· 5 aº 100

Element

<short-name>

je datového typu

string

a obsahuje alternativní název formulá°e. Integritní

omezení:

•


(inputDate | inputText | inputBool){1,6} je komplexní datový typ, který má volitelný atribut title a který obsahuje elementy , a . Integritní omezení:

Element

• • • •

Atribut je volitelný Po°adí element· není dáno Po£et výskyt· jednotlivých element· není dáno Po£et v²ech element· je 1 aº 6

Atribut

•

title

je datového typu

string

a ur£uje nadpis skupiny. Integritní omezení:


label{0,1} = string(1,100) Element

je komplexní datový typ, který má volitelné atributy

obsahuje volitelný element

.

Element

required

a

size

a který

ur£uje textové vstupní pole formulá°e. In-

tegritní omezení:

• •

Atributy jsou volitelné Po£et element·

Atribut

required

je 0 aº 1

je datového typu

boolean,

nabývá dvou hodnot

true

/

false

(logická pravda /

nepravda) a ur£uje, zdali je textový vstup formulá°e povinný. Integritní omezení:

• •

Atribut je volitelný, výchozí hodnota je Povolené hodnoty

Atribut

size

true

nebo

je datového typu

false

integer

false

(textový vstup formulá°e není povinný)

(celo£íselné £íslo) a ur£uje délku vstupního pole. Integritní

omezení:

• •

Atribut je volitelný, výchozí hodnota je "60"(²í°ka vstupního pole je 60) Povolený rozsah je 10 aº 100

Element je datového typu string a obsahuje název vstupního pole. Je spole£ný pro elementy , a . Integritní omezení:

• •

Element je volitelný Po£et znak· 1 aº 100

label{0,1} = string(1,20)

96


Element

je komplexní datový typ, který má volitelné atributy required a noTime a který . Element ur£uje vstupní pole formulá°e pro datum.

obsahuje volitelný element Integritní omezení:

• •

Atributy jsou volitelné Po£et element·

Atribut

required

Atribut

noTime

je 0 aº 1

je datového typu

je datového typu

boolean

boolean

a má stejnou roli jako u elementu

.

a ur£uje, zdali se má zobrazit volba £asu v datumovém

vstupním poli. Integritní omezení:

• •

Atribut je volitelný, výchozí hodnota je Povolené hodnoty

Element

true

nebo

false

true

(volba £asu se nezobrazí)

viz vý²e.

label{0,1} = string(1,20) je komplexní datový typ, který nemá ºádné atributy a který obsahuje volitelný . Element ur£uje vstupní pole formulá°e pro tzv. checkbox. Integritní

Element element

omezení:

•

Po£et element· je 0 aº 1

Element

viz vý²e.

Poznámka : syntaxe formulá°e vychází ze syntaxe Java webového frameworku JavaServer Faces (JSF). Správc·m znalým JSF bude zápis pov¥domý.

D.11.3

Tvorba formulá°e

XML soubor lze vytvo°it v jakémkoli jednoduchém textovém editoru, který neformátuje text (tedy nap°íklad ne MS Word). V opera£ním systému MS Windows m·ºeme pouºít program Poznámkový blok. Výbornou alternativou je freeware PSPad. Soubor musí být validní XML, obsahuje po£áte£ní a koncové tagy a spl¬uje syntaxi uvedenou vý²e. Validitu souboru zkontroluje systém, viz kapitola D.11.6 Nahrání formulá°e. Soubor by m¥l mít p°íponu .xml.

D.11.4

P°íklad formulá°e

Uve¤me p°íklad formulá°e pro ºádost o zm¥nu platového vým¥ru. XML soubor pojmenujeme form_zmena_platoveho_vymeru.xml. Formulá° by mohl vypadat takto (výsledek na obr. D.8):

ádost o zm¥nu platového vým¥ru <short-name>Zm¥na platového vým¥ru p·vodní navrhovaná


97

p·vodní navrhovaný Platnost od neur£eno

Obrázek D.9: Uºivatelské rozhraní formulá°e podle zdrojového kódu z kap. D.11.4.

D.11.5

Jazyk formulá°e

Formulá° m·ºe obsahovat texty v jakémkoli jazyce. Aby se v²ak zobrazovaly uºivateli formulá°e pouze pro jazyk, ve kterém zrovna b¥ºí aplikace, lze u formulá°e jazykovou mutaci zvolit. Systém automaticky rozpozná jazyk formulá°e podle poslední p°ípony odd¥lené podtrºítkem v názvu xml souboru. Jsou podporovány v²echny jazyky, jejichº jazykové kódy jsou specikovány mezinárodní normou ISO 639-1. Pokud není p°ítomna rozpoznatelná p°ípona, bude formulá° za°azen do skupiny formulá°· výchozího jazyka uºivatelova systému (v tomto p°ípad¥ je to £e²tina, ta má kód cs). Máme nap°íklad tyto názvy soubor·:

form_zmena_platoveho_vymeru.xml form_zmena_platoveho_vymeru_cs.xml form_zmena_platoveho_vymeru_en.xml form_zmena_platoveho_vymeru_ru.xml První název nemá platnou jazykovou p°íponu, bude u n¥j ozna£eno default a bude ho moºné volit ve výchozím jazykovém nastavení aplikace. Formulá° s druhým názvem bude nabízen v p°ípad¥, ºe jazykové nastavení aplikace bude £e²tina. T°etí je pro English, £tvrtý pro ru²tinu. Soubor, který nebude mít zvolenou platnou p°íponu, bude automaticky zobrazován v nabídce pro výchozí jazyk opera£ního systému uºivatele. Je tedy lep²í uvád¥t u názv· formulá°· jazykovou mutaci.

98


Vezmeme-li

název

formulá°e,

který

jsme

vytvo°ili

v

p°edchozí

kapitole

form_zmena_platoveho_vymeru.xml, vidíme, ºe poslední p°ípona vymeru neodpovídá ºádnému

kódu dle ISO 639-1. Formulá°i bude p°i°azena lokalizace default a bude se zobrazovat spolu s formulá°i, které mají lokalizaci cs (v R v¥t²inou) nebo default. Prvních pár °ádk· anglické mutace p°edchozího p°íkladu je následujících: název souboru: form_zmena_platoveho_vymeru_en.xml

Petition for change of salary scope <short-name>Change of salary scope actual ...konec ukázky

D.11.6

Nahrání formulá°e

Poté, co admin vytvo°í XML formulá°, pokusí se jej nahrát na server pomocí vstupního pole. Po potvrzení systém zkontroluje syntaxi (zdali je formulá° správn¥ napsaný validní). Pokud se n¥kde ve formulá°i objeví chyba (nepovolený tag, poru²ení integritního omezení), proces nahrávání formulá°e se zastaví a systém sd¥lí, na jakém °ádku se jaká chyba vyskytla. Zobrazí se vºdy pouze první nalezená chyba. P°ed dal²ím pokusem o nahrání formulá°e je pot°eba chybu odstranit nebo se °ídit kapitolou Pokro£ilá správa formulá°·. Je-li validace úsp¥²ná, následuje vytvo°ení výsledných JSP formulá°· (pro vstup, výstup a výstup pro tisk) pomocí transforma£ních soubor· (viz kap. D.11.7 Pokro£ilá správa formulá°·). Nakonec se formulá°e XML i JSP nahrají na server a do databáze se vloºí údaje o novém formulá°i.

D.11.7

Pokro£ilá správa formulá°·

Upozorn¥ní : Je vyºadováno, aby správce dokonale ovládal jak technologii XML Schema tak technologii XSL! Správce systému m·ºe upravit v¥t²inu integritních omezení pro formulá°e. Je pot°eba editovat valida£ní XML Schema soubor form.xsd, kde je schéma s integritními omezeními popsáno.

Dále jsou moºné i úpravy transforma£ních soubor· XSL, které p°evád¥jí XML soubor na soubory JSP pouºívané samotným systémem. Jsou to soubory pro vstupní JSP form_input.xsl, pro výstupní JSP form_output.xsl a pro výstupní na tisk form_output_print.xsl.

P·vodní ²ablona XML a vygenerované JSP formulá°e se nahrávají do adresá°e forms, kde je tedy pot°eba povolit zápis. Pokud se p°ece jen kv·li chybným valida£ním a transforma£ním soubor·m vygeneruje i p°es záv¥re£nou programovou kontrolu nesprávný JSP soubor, je pot°eba jej ihned odstranit ve správci formulá°· nebo vymazat ru£n¥ z aplikace a následn¥ valida£ní a transforma£ní soubory opravit nebo pouºít záloºní soubory v adresá°i WEB-INF/backup.

PÍLOHA E. TESTOVÉ DOTAZNÍKY

99

E Testové dotazníky E.1

P°edtestový dotazník

1. Kolik máte pod sebou p°ímých pod°ízených? (za²krtn¥te jednu odpov¥¤) o 15 o 610 o 1050 o >50 2. P°i personálním poºadavku pouºíváte papírové formulá°e? (ano/ne) 3. Jaké máte zku²enosti s prací na PC a na internetu: o ádné o Základní (chápu adresá°ovou strukturu) o Pr·m¥rné (ovládám kancelá°ské programy jako textový procesor) o Vysoké (práce na PC je m·j denní chléb) o Extrémní (jsem programátor) 4. Pot°ebujete pro svou práci internet? (moºno za²krtnout více odpov¥dí) o Ne o Korespondence (e-mail) o Internet vyuºívám na vyhledávání informací pot°ebných pro svou práci o V podniku zaveden informa£ní systém, se kterým kaºdý zam¥stnanec musí pracovat 5. Pouºíváte doma po£íta£? (moºno za²krtnout více odpov¥dí) o Ne o Internet o Zábava o Psaní o Jiné E.2

Úkoly

Jste Dosed¥l Filip, primá° chirurgického odd¥lení, který má pod sebou 8 p°ímých pod°ízených. InSypoPepo je webová aplikace na správu personálních poºadavk· ve Va²í nemocnici. Va²e p°ihla²ovací údaje: Uºivatelské jméno: lip.dosedel_mail.cz Heslo: desod Úkol £.1:

Dejte výpov¥¤ sest°e R·ºi£kové Jan¥ z d·vodu výpov¥¤ na vlastní ºádost, platnost od 1.2.2009, poºadujte konzultaci s personálním odd¥lením. Se sestrou R·ºi£kovou jste to projednala dnes. Pomocí aplikace vypl¬te, podepi²te a ode²lete p°íslu²ný elektronický formulá°: a) P°ihlaste se do systému, b) vyberte p°íslu²nou ºádost, c) vypl¬te ºádost a ode²lete ji. Úkol £.2:

100

PÍLOHA E. TESTOVÉ DOTAZNÍKY

Zjist¥te, které Va²e d°íve podané ºádosti byly zamítnuty. Zjist¥te, kdo je zamítl a d·vod zamítnutí: a) V Seznamu ºádostí pod°ízených nalezn¥te poºadované ºádosti, b) v detailu t¥chto ºádostí zjist¥te poºadované v¥ci a poznamenejte je na tento papír. Úkol £.3:

Zkontrolujte Va²e nov¥ p°íchozí ádosti na schválení. ádosti o personální náhradu zamítn¥te z d·vodu nedostatku nancí. Ostatní schvalte : a) U ºádostí, které chcete zamítnout, musíte prohlédnout jejich detail ; zde vypl¬te p°íslu²ný d·vod zamítnutí a zamítn¥te je, b) u ºádostí, které chcete schválit, musíte prohlédnout op¥t jejich detail. Úkol £.4:

Zjist¥te, která Va²e schválení ºádostí jsou ve stavu £ekání : a) V Seznamu ºádostí pod°ízených nalezn¥te poºadované ºádosti a jejich id poznamenejte na tento papír, b) odhlaste se od systému. E.3

Potestový dotazník

1. P°ipadá Vám práce s aplikací intuitivní?

2. Jaká £ást aplikace Vám p°i²la nejmén¥ p°ehledná nebo zmatená?

3. Je aplikace dob°e barevn¥ slad¥na (ano/ne)? - pokud ne, specikujte blíºe, jakou kombinaci barev preferujete.

4. Postrádáte v aplikaci n¥jakou d·leºitou funkci (ano/ne)? - pokud ano, specikujte jakou.

PÍLOHA F. OBSAH PILOENÉHO CD

101

F Obsah p°iloºeného CD Adresá° / soubor

Obsah

/database /javadoc /src/classes /src/configs

SQL skriptové soubory pro vytvo°ení a napln¥ní databáze. Vygenerovaná dokumentace aplikace - javadoc. Zdrojové kódy v²ech javovských t°íd aplikace. Kongura£ní, valida£ní a transforma£ní soubory aplikace. Soubory vlastností s lokalizovanými texty pro aplikaci v £e²tin¥ a angli£tin¥. V²echny JSP stránky tvo°ící prezenta£ní £ást aplikace. Viz obrázek F.1. Knihovny t°etích stran pouºité v aplikací. IDE NetBeans 6.1 projekt se zdrojovými kódy aplikace. Lze jej v NetBeans otev°ít jako samostatný projekt. Adresá° obsahující tento text diplomové práce a dále pak uºivatelskou p°íru£ku aplikace v html i pdf. Zkompilovaná aplikace v archiva£ním balí£ku war. Abstrakt v £e²tin¥. Viz strana ix. Abstrakt v angli£tin¥. Viz strana ix. Postup instalace programu. Viz kapitola C. Popis obsahu tohoto CD. Viz tato kapitola.

/src/jsps /src/libs /src/nbproject /text /webapps/insypopepo.war /abstract_cz.txt /abstract_en.txt /install.txt /readme.txt

Tabulka F.1: Obsah p°iloºeného CD

102

PÍLOHA F. OBSAH PILOENÉHO CD

Obrázek 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. 5.9.1 na str. 70.

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

Recommend Documents

Prosím, p°ihla²te se

Vítejte na zabezpe£ené stránce