Vytvo ení informa ního systému s vysokou dostupností pro správu asového výkaznictví. Bc. Petr Janura

Transkript

1 ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta Diplomová práce Vytvo ení informa ního systému s vysokou dostupností pro správu asového výkaznictví Bc. Petr Janura Vedoucí práce: Ing. Josef Semrád Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpo etní technika 10. kv tna 2010

2 iv

3 v Pod kování Na úvod bych cht l pod kovat svému vedoucímu diplomové práce panu Ing. Josefu Semrádovi a panu Ing. Miloslavu Vlachovi za poskytnuté konzultace jak k tvorb textu, tak k implementaci projektu.

4 vi

5 vii Prohlá²ení Prohla²uji, ºe jsem 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 Radenín dne

6 viii

7 Abstract The thesis aims to implement a highly available information system of the time-reporting. Information system serves to increase the eciency of processes in the company BPSolutions Ltd. and should be designed to be applicable in companies in general. At present, companies are often decentralized, so it is necessary that an information system designed to be highly available. The thesis is an analysis, the choice of appropriate frameworks, implementation in Java and testing. During the implementation of the use of various frameworks - Seam, Hibernate, Drools, RichFaces, Facelets,.... To realize the high availability cluster was used, both database and application. Testing were used for these tests - Unit, Integration, Usability. Abstrakt Cílem diplomové práce je implementace vysoce dostupného informa ního systému asového výkaznictví. Informa ní systém slouºí ke zvý²ení efektivity jednotlivých proces ve rm BPSolutions s.r.o. a m l by být navrºen tak, aby byl pouºitelný ve rmách obecn. V sou asnosti jsou rmy asto decentralizované, proto je nutné, aby byl informa ní systém navrºen tak, aby byl vysoce dostupný. Obsahem práce je analýza, volba vhodných framework, implementace v programovacím jazyku Java a testování. V pr b hu implementace bylo vyuºito mnoho r zných framework - Seam, Hibernate, Drools, RichFaces, Facelets,.... Pro realizaci vysoké dostupnosti byl pouºit cluster, a to jak databázový, tak aplika ní. Pro testování byly pouºity tyto testy - Unit, Integra ní, Usability. ix

8 x

9 Obsah 1 Úvod Struktura práce Úvodní studie Re²er²e informa ních systém Poºadavky na systém Achievo JIRA Bugzilla Dovico Ontime Trac Srovnání Pro vlastní e²ení Sou asný stav Poºadovaný stav Funk ní poºadavky Nefunk ní poºadavky Multiplatformnost Internacionalizace Modularita Zab zpe ení Podpora HTTPS Vysoce dostupný Odhadovaný as tvorby aplikace Analýza rizik Technologická rizika Vysoká dostupnost Dodate ná funk nost Bezpe nostní rizika Chybná volba technologií ƒas dokon ení Komponenty systému xi

10 xii OBSAH 3 Analýza a návrh e²ení Poºadavky Poºadavky na modulární aplikaci Poºadavky na aplika ní framework Spole né vlastnosti Spole né vlastnosti Seam a Spring JEE Spring Seam Volba Poºadavky na framework pro perzistenci dat Poºadavky na framework(y) pro prezenta ní vrstvu Poºadavky na vysokou dostupnost Vysoká dostupnost aplika ního serveru Vysoká dostupnost databáze Poºadavky na web Návrh Deployment diagram Actors P ípady uºití Entity Diá Automatizace O co se jedná Funk nost Faktura ní proces Faktura ní vzory Internacionalizace Mapa stránek Návrh vzhledu webové aplikace P ípady uºití podrobn ji P ípady uºití uºivatele P ihlá²ení Odhlá²ení P idání nového uºivatele Prohlíºení a správa uºivatel Zm na odd lení uºivatele Správa uºivatele P ípad uºití diá Prohlíºení obsahu diá e Správa diá e Správa diá e uºivatel P ípad uºití odd lení Prohlíºení odd lení Vytvo ení odd lení Správa odd lení

11 OBSAH xiii P ípad uºití rma Generování faktur Vytvo ení rmy P i azení projektu k rm Odebrání projektu od rmy Pokro ilá správa rmy Správa rmy P ípady uºití projektu Vytvo projekt Prohlíºení obsahu projektového diá e Správa projektového diá e Správa fází projektu Správa automatizace projektu P ípad uºití faktury Nastavení faktura ního vzoru pro fakturu Vygenerování faktury P edání k fakturaci Potvrzení faktury P edání faktury zp t Prohledávání faktur Správa faktur uºivatel Správa asových záznam Správa faktura ních vzor P ípad uºití vícejazy nost Prohledávání internacionalizace Úprava internacionalizace P ípad uºití prom nné Prohledávání prom nných Úprava prom nné P idání prom nné Odstran ní prom nné Realizace Pouºité knihovny a software Seam Bijekce Podpora vytvá ení a ukon ení komponent Scope komponent Správa transakcí a na ítání z databáze Testování Seam Expression Language Ukázka propojení webové a aplika ní vrstvy Dal²í uºite ná funk nost Struktura Seam aplikace JARClassLoader p i na ítání automatizéru Popis problém a cíle

12 xiv OBSAH Class Loading CustomJARClassLoader e²ení Automatizované na ítání projektu Popis problém a cíle e²ení Standardizace vzhledu aplikace zaloºeného na vzhledu RichFaces komponent Popis problém a cíle e²ení Validace vstupních dat Popis problém a cíle e²ení Na ítání webového obsahu z databáze Popis problém a cíle e²ení Clustrování frameworku Seam Clustrování aplika ního serveru Popis problém a cíle e²ení Spu²t ní Clusteru LoadBalancing server Replikace HTTP Session Replikace SFSB a SLSB Replikace Entity - Cache Clustrování databáze Popis problém a cíle e²ení Diá zaloºený na kalendá i RichFaces Popis problém a cíle e²ení FileUpload problém Popis problém a cíle e²ení Realizace zabezpe ení pomocí HTTPS Popis problém a cíle e²ení QueryBuilder Popis problém a cíle e²ení Test Driven Development Popis problém a cíle Co to vlastn je Výsledky Pojmenovávání Seam komponent Popis problém a cíle e²ení

13 OBSAH xv 4.17 Vytvo ení nového faktura ního vzoru Popis problém a cíle e²ení Testování Integra ní a Unit testy Nastavení Vloºení inicializa ních dat Co bylo testováno Výsledky test Usability testing Papírový prototyp Usability testing aplikace Hypotézy Data Vyhodnocení hypotéz Informa ní tooltipy výrazn pomáhají k orientaci na stránce Moºnost volby vzhledu vede k zp ehledn ní stránky Kulaté ráme ky ( nifty ) pomáhají k rozli²ení dat - tabulky versus výpisy Validace pomocí podbarvení a informa ního tooltipu nad vyk i níkem je dostaten upozor ující na chybu p i validaci Dal²í informace z diskuze po POST-TESTu Black box testing Testování funk nosti clusteru aplika ního serveru Záv r Zhodnocení výsledk práce vzhledem k zadání Diskuse dal²ího moºného pokra ování práce Literatura 93 A Seznam pouºitých zkratek 97 B Instala ní a uºivatelská p íru ka 99 B.1 Prom nné pro faktura ní vzor B.2 Apache B.3 JBoss AS B.4 MySQL B.5 HTTPS B.6 Dodatek C Obsah p iloºeného CD 105

14 xvi OBSAH

15 Seznam obrázk 2.1 Diagram komponent T ívrstvá architektura Diagram nasazení Role v systému P ípad uºití odd lení P ípad uºití diá P ípad uºití faktura P ípad uºití rma P ípad uºití vícejazy nost P ípad uºití projekt P ípad uºití prom nná P ípad uºití uºivatel Domain model - prom nné a vícejazy nost Domain model - diá Domain model - odd lení Domain model - faktura Domain model - rma Domain model - projekt Domain model - uºivatel Sekven ní diagram - Diá Class diagram - Automatizace Stavový diagram - fakturace Sekven ní diagram - zprávy Mapa stránek Návrh vzhledu íslo Návrh vzhledu íslo P ípad uºití správa uºivatele P ípad uºití správa diá e P ípad uºití prohlíºení odd lení P ípad uºití správa odd lení P ípad uºití pokro ilá správa rmy P ípad uºití správa rmy P ípad uºití správa projektového diá e P ípad uºití správa fází projektu xvii

16 xviii SEZNAM OBRÁZK 3.34 P ípad uºití správa automatizace projektu P ípad uºití správa asových záznam P ípad uºití správa faktura ních vzor Struktura Seam aplikace, p ebrané z [3] Na tení implementace Na tení implementace Na tení implementace Project Facade Na ítání faktury z databáze Faktura vzor Clustrování databáze, p ebrané z [39] Sekven ní diagram - Diá Test Driven Development, p ebrané z [51] Test Struktura Papírový prototyp

17 Seznam tabulek 2.1 Srovnání stávajících aplikací Srovnání aplika ních framework Pouºité knihovny a software RichFaces a FileUpload Vzory rozvrºení plochy PRE-TEST dotazník POST-TEST dotazník xix

18 xx SEZNAM TABULEK

19 Kapitola 1 Úvod Hlavním cílem tohoto projektu je vytvo ení vysoce dostupného informa ního systému 1 pro asové výkaznictví. Podn tem pro vznik aplikace byla nutnost sniºovat náklady na platy ve rm. Aplikace má zefektivnit vnitroremní procesy,a to automatizováním správy asového výkaznictví. Konkrétn má být moºné zaznamenávat as k jednotlivým fázím projektu a k odd lením, aby poté bylo moºné provád t fakturaci naprosto automatizovan. Faktury by m li mít moºnost vystavovat kontrakto i 2 a manaºe i rmám, které projekt zadaly k vypracování. M lo by být moºné volit si faktury a modikovat jejich vzhled pro kaºdého klienta nebo kontraktora v rámci pot eb. M la by se odstranit nutnost ru ního zadávání projekt a umoºnit vkládání projekt automatizovan. Protoºe je ve rm více osob s rozli nými rolemi, je nutné, aby toto bylo zohledn no i r znými p ístupovými právy v rámci systému. Budou tato : Administrátor. Manaºer. Zam stnanec. Pozorovatel. V kaºdé práci se plánují dny, kdy zam stnanci pracují a kdy mají dovolenou. Toto je nutné udrºovat v diá i, aby podle toho mohli manaºe i plánovat práce na projektech. Dále je nutné, aby existoval zp sob, jak oznámit zam stnanc m, ºe budou nap íklad probíhat projektové sch zky. Manaºe i by m li mít moºnost vyhledávat mezi zam stnanci podle jejich zku²eností, aby je mohli co moºná nejlépe a nejefektivn ji distribuovat pro práci. P i práci bude kladen d raz na rychlost pouºití aplikace a bezchybnost práce s ní. Poºadavkem je, aby aplikace byla dostupná bez nutnosti instalovat jakýkoliv nadbyte ný software, z ehoº vyplývá, ºe se bude jednat o aplikaci webovou. Protoºe se do budoucna po ítá s moºností pouºití aplikace i mimo ƒeskou republiku, je nutností vytvá et jazykové mutace aplikace. Poºadavkem je, aby byla aplikace vytvo ena s podporou vysoké dostupnosti 3. Vzhledem k tomu, ºe aplikace bude pracovat s interními daty rmy, je nutné umoºnit ji 1 Informa ní systém je systém pro sb r, udrºování, zpracování a poskytování informací a dat Kontraktorem je my²lena osoba pracující na ºivnostenský list. 3 Vysokou dostupností systému je my²lena prakticky 100% dostupnost aplikace v pr b hu roku. 1

20 2 KAPITOLA 1. ÚVOD provozovat zabezpe en - pouºívat protokol HTTPS 4. Aplikace bude dostupná aº po p ihlá²ení, p i emº bude vytvo en speciální ú et pro administrátora. P i implementaci by m l být kladen d raz na pouºívání open source 5 zdroj, aby nebyl vývoj zbyte n prodraºován. Aplikace musí být testována, aby byla i tímto zp sobem zaru ena její funk nost. D raz bude kladen i na uºivatelskou p ív tivost aplikace, p edev²ím s ohledem na b ºné uºivatele po íta e. K aplikaci bude vytvo ena UML (viz [55] [2]) dokumentace projektu. Aplikace bude napsána v programovacím jazyku Java (viz [29]). 1.1 Struktura práce Úvodní studie - re²er²e stávajících informa ních systém a vytvo ení úvodní studie k projektu. Analýza a návrh e²ení - rozbor poºadavk na aplikaci a vytvo ení UML dokumentace k projektu. Realizace - implementace projektu s d razem na problémové ásti. Testování - testování aplikace pomocí integra ních,unit a usability test. Záv r - zhodnocení práce a zamy²lení se nad moºnými body dal²ího rozvoje aplikace. P ílohy - seznam zdroj, návod k instalaci, vysv tlený seznam zkratek a obsah p iloºeného CD. 4 Nadstavba sí ového protokolu HTTP, která umoº uje zabezpe it spojení mezi webovým prohlíºe em a webovým serverem p ed odposloucháváním, podvrºením dat a umoº uje téº ov it identitu protistrany. HTTPS pouºívá protokol HTTP, p i emº p ená²ená data jsou ²ifrována pomocí SSL nebo TLS a standardní port na stran serveru je z 5 Open source je voln ²í itelný kód, který je moºné bez poplatk pouºívat.

21 Kapitola 2 Úvodní studie 2.1 Re²er²e informa ních systém Poºadavky na systém Z úvodu 1 vyplývá, ºe má být vytvo en vysoce dostupný informa ní systém pro asové výkaznictví. Tento systém má za úkol provád t správu asových záznam, které p i azuje k jednotlivým projekt m. Na základ t chto vstupních dat bude umoºn no generovat faktury. Nyní si probereme poºadavky na hledaný informa ní systém. Jsou tyto : Rozd lení rolí. Záznam as. Vysoká dostupnost. Generování faktur jak pro kontraktory, tak pro zákazníky. Modikovatelnost faktura ních vzor 1. Automatizace na ítání projekt. Plánování asových moºností. Open source. Na základ t chto parametr budu nyní posuzovat vybrané projekty, p i emº v²em bod m budu p isuzovat p ibliºn stejnou váhu, s výjimkou open source,který povaºuji za velmi d leºitý. Nyní si probereme informa ní systémy, které do této oblasti zasahují. 1 Faktura ním vzorem je my²len vzhled faktury. 3

22 4 KAPITOLA 2. ÚVODNÍ STUDIE Achievo Jedná se o systém (viz [6]), který je v sou asnosti pouºíván rmou BPSolutions s.r.o. (viz [9]). Myslím, ºe se dá íci, ºe má dostate n propracované rozd lení rolí. Co se v²ak správy as tý e, nastávají první problémy. Zadávání as je pom rn rychlé, problém je v²ak se s ítáním as nap í faktura ním obdobím. Tento sou et nemá achievo zabudován. Navíc p i p echodu mezi roky, p ípadn p i p iblíºení se k datu nebo 1.1. vzniká chyba, která nás p esune do roku 1970, coº povaºuji za výrazný nedostatek. Výhodou tohoto projektu je, ºe se jedná o open source. Ostatní z vý²e jmenovaných vlastností v²ak postrádá JIRA JIRA (viz [31]) je ve svém základu p edev²ím project management systém 2. Je v²ak velmi kvalitn navrºena a umoº uje do ur ité míry i správu as v rámci ur itého období. Naprosto bez problém spl uje podmínku pro rozd lení rolí a zaznamenávání as. Nespl uje podmínku na vysokou dostupnost, neumoº uje jakoukouliv fakturaci a plánování asových moºností. Projekty jako takové není nutné v ní na ítat, protoºe je p ímo pro to ur ena. Nevýhodou je, ºe se nejedná o open source, ale dá se íci, ºe její cena je pom rn p ijatelná. Nakonec musím z vlastních zku²eností íci, ºe se jedná o aplikaci, která je velmi dob e pouºitelná a ve které se rychle orientuje Bugzilla Bugzilla (viz [10]) je p edev²ím bugtracking 3 systém, který je v²ak pouºitelný i jako project management systém. Myslím si, ºe JIRA je ale do ur ité míry kvalitn j²í. Znovu mohu íci, ºe má kvalitní rozd lení rolí, je moºné ji pouºívat i pro záznam as k projekt m. Podmínku na vysokou dostupnost nespl uje, stejn tak neumoº uje generování faktur. Pro správu projekt je navrºena, automatizaci na ítání v²ak neobsahuje. Plánování asových moºností neumoº uje. Nakonec podmínku na open source spl uje Dovico Dovico (viz [18]) je dle mého vyhledávání jeden z nejkvalitn j²ích time managment systém 4 sou asnosti, proto jsem se na n j také zam il. Tento produkt naprosto spl uje poºadavky na rozd lení rolí. Umoº uje bezproblémové zaznamenávání as. Dle dostupných materiál ho není moºné pouºívat s vysokou dostupností. Nepodporuje generování faktur, ale umoº uje provád t s ítání as v rámci ur itých období. Dovico samotné je integrované 5 s produkty rmy Microsoft, nap íklad Microsoft Project nebo QuickBooks. Bohuºel tato integrace není zdaleka obecná. V p ípad, ºe pouºíváte n jaký sv j zavedený software pro bugtracking, nap íklad JIRU nebo Bugzillu, museli byste v²e p evést do Dovica. Nakonec musím upozornit, ºe se nejedná o open source a neumoº uje plánování as z hlediska zam stnanc. 2 Systém pro správu projekt, v t²inou se dá pouºít i pro správu bug 3 Systém pro správu chyb 4 Systém pro správu asových moºností 5 Umoº uje spolupráci s

23 2.2. PROƒ VLASTNÍ E ENÍ 5 Kritérium Achievo JIRA Bugzilla Dovico Ontime Trac Rozd lení rolí ano ano ano ano ano ano Záznam as ano ano ano ano ano ano Vysoká dostupnost ne ne ne ne ne ne Generování faktur ne ne ne ne ano ne Modikovatelnost ne ne ne ne ano ne faktur Automatizace ne áste n áste n áste n áste n áste n na ítání projekt Plánování asových ne ne ne ne ano ano moºností Open Source ano ne ano ne ne ano Ontime Tabulka 2.1: Srovnání stávajících aplikací Ontime (viz [44]) je software, který není open source, coº je v tomto výb ru jeho velkou nevýhodou. Podporuje správu rolí, zaznamenávání asových moºností. Není v²ak vysoce dostupný. Podporuje generování výkaz hodin i tvorbu faktur a faktura ních vzor. Zaznamenávání as v n m bez problém funguje. Protoºe je navrºený také pro správu projekt, není t eba automatizované na ítání projekt Trac Trac (viz [54]) je project management software, který podporuje správu rolí, asových záznam. Ty si m ºeme i plánovat a Trac jako takový je ur en pro správu projekt. Jedná se o open source projekt Srovnání Jak je vid t ze srovnavací tabulky 2.1, ºádný z vý²e zmi ovaných systém nespl uje ani zdaleka v²echny podmínky, které jsou na výsledný produkt kladené. Je to dáno tím, ºe poºadovaný systém pro asové výkaznictví stojí na pomezí mezi time managment a projekt managment software. Ty bohuºel v sou asné dob na trhu nejsou nebo nebyly nalezeny. 2.2 Pro vlastní e²ení Pouºívaný systém Achievo obsahoval chyby, které zpomalovaly práci s ním. Navíc nespl oval poºadavky, které na n j byly kladeny. Jak je v p edchozí sekci ukázáno, v sou asnosti není na trhu produkt, který by spl oval v²echny poºadavky. Po re²er²ní práci nabyl vznik projektu je²t dal²ího rozm ru. Protoºe ºádná aplikace podobného typu nebyla nalezena, je moºné, ºe by to mohla být do budoucna velmi dob e pouºitelná aplikace jako produkt rmy

24 6 KAPITOLA 2. ÚVODNÍ STUDIE BPSolutions, s.r.o.. Dal²ím podn tem pro vznik aplikace byla nutnost sniºovat náklady. Náklady (viz [42]) se skládají z t chto poloºek. Provozní. Finan ní. Mimo ádné. Výsledem této práce by m lo být u²et ení provozních náklad, a to p edev²ím sniºováním osobních náklad. Aplikace se má starat o to, aby nebylo nutné vypl ovat soub ºn time managment a projekt managment systémy. M l by sta it pouze klasický project managment systém, jako nap íklad JIRA nebo Bugzilla, p ípadn jakýkoliv jiný a následn pouºívat tuto aplikaci. Její výhodou by byl fakt, ºe si pot ebná data z project managment systému na te sama. Dále umoºní p idávat asové záznamy ke konkrétním projekt m a následn provád t zadavatel m projekt fakturaci. Fakturace by m la být stejn tak umoºn na kontraktor m. U²et í se tak velké mnoºství asu, které by bylo jinak spot ebováno udrºováním konzistence mezi projekty vedenými v project management systému a time managment systému a vytvá ením faktur. Navíc bude kladen d raz na co nejrychlej²í moºnost zadávání asových záznam. 2.3 Sou asný stav V sou asnosti je pouºíván systém pro asové výkaznictví Achievo. Ten je ale v následujících aspektech nevyhovující. Nepodporuje generování faktur. Nemá faktura ní vzory. Chybí automatizované na ítání projekt. 6 Obsahuje chyby ( p echod mezi roky,... ). Není vysoce dostupný. Neobsahuje plánování asových moºností. 2.4 Poºadovaný stav Funk ní poºadavky Funk ní poºadavky vycházejí z funk nosti systému Achievo. M l by obsahovat v²echny pouºívané rysy a p idávat rysy, které v Achievo chybí. 6 Automatizované na ítání projekt slouºí k na ítání pot ebných projektových dat z pouºívaného project management systému

25 2.5. ODHADOVANÝ ƒas TVORBY APLIKACE Nefunk ní poºadavky Multiplatformnost Poºadavkem na aplikaci je, aby byla napsána tak, ºe ji bude moºné provozovat na jakémkoliv opera ním systému. Tento poºadavek vychází z toho, ºe nevíme, jaký opera ní systém bude zrovna na zvoleném serveru k dispozici Internacionalizace Do budoucna se po ítá s moºností pouºití aplikace i mimo rámec ƒeské republiky, proto je nutné, aby byla aplikace napsána tak, aby bylo nutné p eloºit pouze klí ová slova a následn ji pouºít ve zvolené lokalit Modularita Úpravy aplikace se v budoucnosti nedají vylou it, jsou dokonce velmi pravd podobné. Proto musí být aplikace navrºena modulárn, aby byla pokud moºno co nejjednodu²eji upravitelná Zab zpe ení Aplikace podporuje 4 role uºivatel. Administrátor, manaºer, zam stnanec a pozorovatel. V rámci aplikace musí být omezeno, co m ºe daný uºivatel provád t za operace. Podrobn ji se touto problematikou bude zabývat sekce s p ípady uºití Podpora HTTPS Protoºe aplikace pob ºí na clusteru aplika ních server, musí zde být moºnost pouºívat ²ifrovaný komunika ní protokol. D vodem je zabezp ení dat, která klient odesílá na server, aby nedo²lo k úniku klí ových informací Vysoce dostupný Aplikace musí být navrºena tak, aby byla vysoce dostupná pro své uºivatele. Je to poºadavek, který vychází z toho, ºe v p ípad výpadku jednoho serveru m ºe dojít k velké ztrát asu, a tedy i pen z, pokud v²ak nefunk ní server nahradí jiný, problém se ztrácí. Do budoucna by toto m la být jedna z klí ových výhod této aplikace v porovnání s alternativními aplikacemi tohoto druhu. 2.5 Odhadovaný as tvorby aplikace Pro výpo et bude pouºita metoda COCOMO (viz [12]). Prom nná KLOC - po et tisíc ádek kódu je zvolena jako 12. Dále jde jen o dosazování do vzorce. KLOC = 12

26 8 KAPITOLA 2. ÚVODNÍ STUDIE Narocnost = 2, 94 KLOC 0.91 Cas = 3, 97 Narocnost 0.28 Po dosazení je as roven 10,11 lov kom síce. 2.6 Analýza rizik Technologická rizika Aplikace je p ipravována tak, ºe je schopna b ºet na clusteru aplika ních server 7. Tyto servery musí b ºet na dostate n výkonných za ízeních, jinak m ºe docházet k jejich výpadk m z d vodu p ekro ení jejich kapacity. Riziko : Nízké e²itel problému : Provozovatel aplikace, poskytovatel server Vysoká dostupnost B hem vývoje aplikace jsou pouºívány nejmodern j²í technologie a vyuºití clusteru 8 se dá po ítat mezi n. Problémy s nimi mohou vznikat z d vod neo ekávaných chyb, které nebyly b hem vývoje odhaleny. Riziko : Nízké e²itel problému : Tv rce aplikace Dodate ná funk nost Kaºdá aplikace se pr b ºn vyvíjí, je tedy velmi pravd podobné, ºe tento p edpoklad bude platit i pro tuto aplikaci. Zm nové poºadavky budou provád ny dodate n. M lo by se tomu do zna né míry p edejít astými konzultacemi. Riziko : Velmi vysoké e²itel problému : Tv rce aplikace Bezpe nostní rizika Potenciál vzniku je v chybném kódu, p ípadn v nedostate ném zabezpe ení databáze i aplika ního serveru. Dal²í moºné riziko se skrývá v komunikaci mezi klientem a aplika ním serverem. Riziko : Nízké e²itel problému : Tv rce aplikace Chybná volba technologií V p ípad chybné volby technologií m ºe dojít k problém m s vývojem aplikace. Problémy by se týkaly jak rychlosti vývoje, tak kvality výsledného software a jeho budoucí modikovatelnosti. 7 Cluster je skupina po íta,aplika ních server,databází,..., které spolu spolupracují 8 Cluster slouºí mimo jiné k zaji²t ní vysoké dostupnosti

27 2.7. KOMPONENTY SYSTÉMU 9 Riziko : Nízké e²itel problému : Tv rce aplikace ƒas dokon ení K odhadu asu pot ebného k dokon ení aplikace byla pouºita prov ená metoda COCOMO. Výsledkem je as, který odpovídá p íbliºn 10 lov kom síc m. To by m l být as dosta ující k tvorb aplikace. Riziko : Nízké e²itel problému : Tv rce aplikace 2.7 Komponenty systému Systém by m l být modulární, je proto od základu navrºen tak, aby jeho jednotlivé ásti byly co moºná nejvíce odd lené. Na obrázku 2.1 m ºete vid t diagram komponent systému. Project - správa projekt, jejich dynamická úprava nebo úprava v rámci aplikace. Account - úkolem je správa as a vytvá ení faktur. Internacionalization - správa jazykových mutací, p edev²ím dynamické p idávání za b hu. Firm - správa rem a p i azení k projekt m a odd lením. Property - prom nné aplikace. Department - správa odd lení a vytvá ení jejich struktury. User - správa dat o uºivateli. Diary - úkolem je plánování uºivatelova asu.

28 10 KAPITOLA 2. ÚVODNÍ STUDIE Obrázek 2.1: Diagram komponent

29 Kapitola 3 Analýza a návrh e²ení V této ásti se budu zabývat analýzou poºadavk na aplikaci vycházejících ze zadání a volbou framework 1. Konkrétn se bude jednat o volbu aplika ního frameworku, frameworku pro perzistenci dat 2 a prezenta ní vrstvu. Dal²í volbou bude zp sob, jakým budu realizovat vysokou dostupnost aplikace. Výstupem celé této kapitoly by m lo být ujasn ní, co bude v aplikaci pouºito za frameworky, a zkonkretizování poºadavk na aplikaci. 3.1 Poºadavky V této ásti se budu zabývat striktními poºadavky na aplikaci a provedu volbu vhodných e²ení na základ výb ru Poºadavky na modulární aplikaci Ze zadání vyplývá, ºe celá aplikace má být navrºena modulárn. V tomto p ípad se bude jednat o osv d enou variantu pro webové aplikace - o t ívrstvou aplikaci s následujícími vrstvami : Prezenta ní. Aplika ní. Datová. Díky tomuto rozd lení získáváme do budoucna výhodu, která nám umoºní provést zm nu pouze v jedné vrstv bez nutnosti zásahu do vrstvy jiné. Díky tomuto d lení je moºné, aby kaºdou vrstvu spravoval specializovaný pracovník. 1 Framework je softwarová struktura, která slouºí jako podpora p i programování a vývoji a organizaci jiných softwarových projekt. M ºe obsahovat podp rné programy, knihovnu API, návrhové vzory nebo doporu ené postupy p i vývoji. Zdroj 2 Perzistentní = uloºený v databázi 11

30 12 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Obrázek 3.1: T ívrstvá architektura Poºadavky na aplika ní framework V této ásti budu volit aplika ní framework pro pot eby na²í aplikace. Hned ze za átku bych volbu omezil na frameworky Seam (viz [59]) a Spring (viz [58]) a standard JEE (viz [28]). Toto omezení je provedeno na základ osobních zku²eností erpaných z realizace projekt a sledování r zných diskuzních fór o programování v Java. Navíc mi ani není znám ºádný jiný takto komplexní standard nebo framework. Volba bude probíhat na základ t chto poºadavk. Podpora vysoké dostupnosti. Podpora internacionalizace. Podpora HTTPS a security 3. 3 V tomto p ípad znamená podpora security, ºe framework umoº uje zabezpe ení aplikace.

31 3.1. POšADAVKY 13 Integrace framework ( persistence dat, pdf, ,... ). Dal²í uºite né vlastnosti. Nyní postupn proberu spole né vlastnosti,poté jednotlivé frameworky a standard JEE Spole né vlastnosti V²echny tyto aplika ní frameworky podporují tvorbu entit (viz [21]) a ejb (viz [20]). Ty jsou samy o sob standardem a podporují clustrování. Mohu proto íci, ºe podporu vysoké dostupnosti spl ují v²ichni participanti výb ru. V aplikaci budu pouºívat framework postavený na standardu JSF (viz [35]), který je navrºen tak, aby podporoval internacionalizaci aplikací. HTTPS podporují v²echny tyto aplika ní frameworky, p ípadn se dá pouºít zp sob, jakým je vyuºíván v JEE. V²echny jeho vlastnosti je totiº moºné vyuºít i ve Springu nebo Seamu Spole né vlastnosti Seam a Spring Oba frameworky podporují a jsou zaloºeny na DependencyInjection. Jedná se o vkládání závislostí na základ anotací 4 nebo xml kongurace JEE JEE je specikací od tv rc Javy. Má slouºit k vytvá ení r zných aplikací od webových informa ních systém aº po desktopové aplikace. Obsahuje pom rn rozsáhlé API 5, jehoº ásti jsou asto samy o sob standardem. Mezi takovéto ásti pat í nap íklad správa zabezpe ení. Ta v²ak není p ili² komplexní, tudíº lze povaºovat pouze za základ v této oblasti. Stejn tak do sebe neintegruje ºádný framework, který není sou ástí specikace. Funk nost poskytovanou JEE budu povaºovat za základ p i porovnávání. Frameworky Seam a Spring jsou totiº vystav ny nad touto specikací Spring Spring vyuºívá pro security framework Spring Security. Jedná se o framework, který pro zabezpe ení aplikace, dle r zných post eh internetových diskuzí (viz [15] [11]), pln dosta uje. Spring do sebe integruje do ur ité míry adu framework, vytvá í na n r zné Template 6, nap íklad HibernateTemplate 7 (viz [23]),.... Bohuºel p i integraci vzniká ada problém. Myslím si, ºe velmi kladným rysem tohoto frameworku je to, ºe je ºivý - neustále vznikají nové verze, stojí za ním velká komunita vývojá. Velkým kladem je, ºe Spring Web Flow (viz [50]) podporuje konverza ní scope pro komponenty pouºívané webovou vrstvou. 4 Anotace - dodate ná informace vkládaná do zdrojového textu,nap 5 API - programové rozhraní pro tvorbu aplikace 6 Vzory, které automatizují jeho pouºití 7 Vzor, který zjednodu²uje práci s frameworkem Hibernate3.1.3

32 14 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Seam Seam (kapitola 4.2) pro security pouºívá Drools (viz [19]), které pro zabezpe ení aplikace naprosto posta ují. Myslím si, ºe co se tý e integrace framework je naprosto jedine ný, protoºe p ímo zabudovává podporu pro y, pdf, perzistenci (kapitola 3.1.3) dat,.... Navíc jde s integrací tak daleko, ºe do sebe integruje i samotný Spring (kapitola ). Co ho odli²uje ale naprosto vyjíme n je to, ºe se jedná o stateful aplika ní framework. Co to znamená. Jedná se o framework, který si udrºuje stav aplikace. Vyuºívá toho p i práci s frameworky pro perzistenci dat ( p ednostn Hibernate ). Tam spravuje ºivotnost komunikace s databází a poté nedochází k LazyInitializationException 8, která je bezesporu nejv t²ím problém p i práci s ORM 9 nástroji. Dal²í z výhod Seamu je, ºe umoº uje lep²í vazbu na EJB, p edev²ím odstran ním nutnosti vytá et BackingBeany. Zajímavou vlastností Seamu je také to, ºe p idává ºivotnost objektu typu Conversation. Ten svou ºivotností dokáºe spravovat n kolik poºadavk odeslaných za sebou na server. Dále roz²i uje expression language 10 frameworku JSF. Umoº uje nám vytvá et nap íklad takovéto konstrukty : <h:commandbutton value="#{foo.bar(value)}"/> Tímto zavoláme objekt foo a jeho metodu bar, které dáme jako parametr hodnotu value. Ur it bych m l zmínit bijekci. Seam vyuºívá Ty nám umoº ují do kterékoliv komponenty vloºit komponentu, kterou máme v Seam kontextu pomocí anotace In a do tohoto kontextu m ºeme vloºit jinou komponentu pomocí anotace Out a následn ji v n jaké jiné pouºít. V Seamu je tém v²e kongurováno pomocí anotací. N kterým programátor m velké mnoºství anotací vadí z d vodu men²í p ehlednosti kódu. Mn osobn to nevadí, ale myslím si, ºe tento fakt ur it stojí za zmínku. Nakonec musím p ipojit informaci, ºe Seam se má dostat skrze standard Web Beans (viz [56]) do nové specikace JEE a tím by m l být zaji²t n jeho dal²í rozvoj Volba V tabulce jsou znázorn ny jednotlivé body, které jsem uvedl v poºadavcích, a jejich výsledek pro jednotlivé participanty volby. P í emº výsledkem bude vºdy rozli²ení ano / áste n / ne. Z vý²e uvedené tabulky 3.1 na první pohled odstraním z volby JEE. Ve výb ru tedy z stávají Spring a Seam. Myslím si, ºe Spring má výhodu oproti Seamu v tom, ºe je pouºívaný del²í dobu,a je proto prov en j²í. Seam má oproti Springu velkou výhodu v tom, ºe je stateful 11. Seam do sebe navíc Spring integruje, takºe ho m ºeme dle pot eby vyuºít a navíc se skrze WebBeans dostane do nové specikace JEE. Dále do volby zahrnu sv j zájem o prozkoumání této technologie, a proto se rozhoduji pro pouºití frameworku Seam Poºadavky na framework pro perzistenci dat Poºadavky na tento framework jsou tyto: 8 LazyInitializationException je výjimka vznikající kombinací pouºití pozdního na ítání dat a ²patné správy na ítání dat. 9 ORM - Object Relational Mapping, jedná se o nástroje pro perzistenci dat 10 Seam Expression Language roz²i uje vyjad ovací prost edky pro psaní webové vrstvy 11 Stateful framework - uchovává si stav aplikace v pr b hu asu

33 3.1. POšADAVKY 15 Volba JEE Spring Seam Podpora vysoké dostupnosti ano ano ano Podpora internacionalizace ano ano ano Podpora HTTPS a security ano ano ano Integrace framework ( persistence dat, pdf, ,... ) ne áste n ano Dal²í uºite né vlastnosti ne ano ano Tabulka 3.1: Srovnání aplika ních framework Mapování základních datových typ. Mapování asociací. Mapování kolekcí. Mapování d di nosti. Optimalizace výkonu. Validace dat. V p edchozí sekci jsme jako aplika ní framework zvolili Seam (kapitola ). Ten do sebe integruje framework Hibernate, který pln spl uje vý²e zmi ované poºadavky, krom jednoho - validace dat. Tento problém je ale vy e²en pomocí frameworku Hibernate Validator (viz [25]). Myslím si tedy, ºe není nutné provád t v tomto p ípad volbu. Navíc si myslím, ºe Hibernate je v sou asné dob prakticky standardem mezi ORM nástroji. Jedná se o framework, který má velmi ²irokou vývojá skou komunitu, navíc na fórech je velmi asto diskutovaný, tudíº i pouºívaný Poºadavky na framework(y) pro prezenta ní vrstvu V této sekci se zam ím na volbu frameworku pro prezentaci dat. Existuje velké mnoºství k tomu pouºitelných open source framework : Facelets (viz [1]). GWT (viz [22]). Richfaces (viz [4]). Icefaces (viz [27]). Wicket (viz [57]). Existuje samoz ejm velké mnoºství dal²ích web framework 12, ale znovu bych vy²el z aplika ního frameworku Seam. V tom je konkrétn doporu ováno pouºití frameworku Facelets. Myslím si, ºe jeho velkou výhodou je jednoduchost, p esto poskytuje v²e, co pot ebujeme, 12 Frameworky pro tvorbu webové vrsty

34 16 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ a p edev²ím umoº uje tvorbu template. Umoº uje bezproblémové pouºívání JSF. K tomuto je moºné pouºívat n jaký AJAX 13 framework, Zde bych na základ vlastních dobrých zku²eností vybral framework Richfaces, který poskytuje obrovské mnoºství r zných komponent s ²irokým spektrem vyuºití. Navíc v sob zahrnuje integraci JQuery (viz [34]), která se mi také velmi osv d ila. Jedná se o JavaScriptovou knihovnu s velmi rozsáhlou funk ností, která ideáln dopl uje Richfaces Poºadavky na vysokou dostupnost Nakonec se v rámci poºadavk dostávám k volb aplika ního serveru a databáze, pomocí které budu realizovat vysokou dostupnost na²í aplikace Vysoká dostupnost aplika ního serveru Zde bych op t vycházel z aplika ního frameworku Seam. Ten je vyvíjen rmou RedHat, která spolu s tím vyvíjí i aplika ní server JBoss. Ten je primárn ur en pro vývoj webových aplikací v Seamu. Proto zde volba padá práv na aplika ní server JBoss, konkrétn ve verzi 5.1. Vysoká dostupnost je realizována pomocí clustru aplika ního serveru. V rámci tohoto clustru by se m ly replikovat session a dále ve²keré EJB a Cache EntityManageru. Nakonec by m l být tento aplika ní server LoadBalancovatelný 14. Toho bude docíleno pomocí Apache (viz [7]) a modulu mod_jk (viz [37]). Nabízelo se je²t pouºití modulu mod_cluster (viz [36]), to jsem ale zavrh kv li dobrým zku²enostem s pouºitím modulu mod_jk. Dal²ím d vodem je, ºe mod_cluster je pom rn novým modulem apache a tudíº není tak prov ený v praxi Vysoká dostupnost databáze K dispozici máme dle mého názoru dv kvalitní, roz²í ené open source databáze: MySQL (viz [5]). PostgreSQL (viz [45]). Ob databáze umí v²e, co se dá od moderních databází poºadovat. Na základ dokumentace, která se mi k MySQL zdála kvalitn j²í, jsem se rozhodl pro pouºití MySQL. Nyní zbývá vy e²it otázku, jak bude vysoká dostupnost realizována. Myslím si, ºe ideální moºností je vyuºití MySQL Clusteru (viz [38]). Je sice moºné pouºít MySQL replikace, ale zde by mohl být jiº problém s výpadky Master uzlu. Výrobcem MySQL jsou udávány tyto vlastnosti MySQL Clusteru % dostupnost. Automatické zotavení z chyb. 13 AJAX = Asynchronous Java Script - umoº uje provád ní asynchronních volání na server a jejich následné zpracování na webové stránce 14 Load Balancing - slouºí k rovnom rnému vyuºití server a p esouvání zát ºe, nap íklad p i výpadku jednoho ze server

35 3.2. NÁVRH 17 Výborná ²kálovatelnost 15. K tomuto bych doplnil, ºe výborná ²kálovatelnost znamená ²kálovatelnost na dotazy typu read. kálovatelnost typu write je jiº ²patná, protoºe data musí být z jednotlivých uzl replikována na ostatní a tím se spot ebovává celkový výkon clusteru p ímo úm rn s po tem write p íkaz. V²echny servery musí vykonat v²echny write p íkazy. Toto by m lo jediné e²ení, vytvo it datový sklad (viz [16]). A nap íklad v rámci n j cluster. To je sice nad rámec aplikace, je to v²ak potencionální moºnost dal²ího rozvoje, proto ji zmi uji. Pro toto je moºné pouºít framework Hibernate Shards (viz [24]) Poºadavky na web Poºadavkem na webovou vrstvu je, aby byla pokud moºno co nejvíce dynamická. Jinými slovy to znamená, ºe by m la do zna né míry pouºívat AJAX. Ten nám zaru í rychlou odezvu aplikace, nevýhodou v²ak m ºe být v t²í zatíºení serveru. Naopak se tím ²et í datové p enosy. Výhodou AJAXu je, ºe reakce aplikace je rychlej²í, a m ºeme tudíº efektivn ji pracovat. Pokud je aplikace dostate n rychlá a srozumitelná na pouºívání, uºivatelé ji poté i rad ji pouºívají. Navíc by m l být vzhled dostate n reprezentativní, aby je²t více lákala k pouºívání. Bude toho dosaºeno pomocí RichFaces. Základem v tomto bude usability testing aplikace (kapitola 5.2.2), který se bude zabývat t mito body: Volba barevného vzhledu aplikace. Upoutání pozornosti pomocí kruhových ráme k. Rozloºení aplikace. Info tooltip 16 na kaºdé stránce. Zvýraz ování validace. 3.2 Návrh V této sekci se budu zabývat návrhem jednotlivých ástí projektu. Za nu projektem jako celkem, podívám se, jak budou rozmíst ny softwarové komponenty. Dále se budu zabývat p ípady uºití, rolemi uºivatel v systému, ukládáním dat a jejich vzájemnými vazbami. Podívám se, jak bude fungovat diá, a to jak projektový, tak uºivatelský, jakým zp sobem bude fungovat automatizace na ítání projekt, jak bude probíhat faktura ní proces, jakým zp sobem se budou pouºívat faktura ní vzory. Vzhledem k tomu, ºe v aplikaci budou za b hu p ibývat vícejazy ná slova, je t eba vytvo it n jaký zp sob jejich na ítání. Na záv r si ukáºeme,jak by m la vypadat mapa stránek. 15 Ideáln ²kálovatelný systém zvy²uje výkon p ibliºn lineárn s p idáváním zdroj 16 Tooltip - informa ní hlá²ka dynamicky se zobrazující nad zvolenou oblastí

36 18 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Deployment diagram Celá aplikace bude vytvo ena tak, aby bylo moºné ji nasadit na cluster aplika ních server. Jak je z obrázku vid t, bude nutné, aby byly tyto servery loadbalancované. Toho dosáhneme pomocí serveru Apache. Dále je nutné mít clustrovaný nejen aplika ní server, ale také databázi. Toto v²e dohromady nám vytvo í vysoce dostupný systém, do kterého lze nasadit na aplika ní server vysoce dostupnou aplikaci Actors Na obrázku vý²e jsou vid t v²echny role, které se budou vyskytovat v projektu. Na tyto role bude zam eno zabezpe ení projektu a bude vycházet z p ípad uºití, které budou ukázány v ásti P ípady uºití V této ásti se zam ím na p ípady uºití aplikace. Budou zde prozatím vytvo eny p edev²ím základní diagramy a detailní rozbor bude proveden aº v sekci P ípady uºití nám budou slouºit do budoucna i jako vzor pro zabezpe ení systému. Na p ípadech uºití je totiº jednozna n vid t, co m ºe uºivatel s danou rolí v systému provád t. P ípady uºití jsou zobrazeny na t chto diagramech 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10, Entity V této sekci si ukáºeme, jaká data budeme ukládat a vztahy mezi nimi. V na²í aplikaci bude pro ukládání dat pouºit framework Hibernate, pro namapování dat do databáze standard JPA (viz [33]). Níºe se m ºeme podívat na diagram t íd, který v²ak neobsahuje prom nné ani operace kv li zvý²ení itelnosti. Diagramy byly vytvo eny pomocí Netbeans IDE (viz [43]).

37 3.2. NÁVRH 19 Obrázek 3.2: Diagram nasazení

38 20 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Obrázek 3.3: Role v systému Obrázek 3.4: P ípad uºití odd lení

39 3.2. NÁVRH 21 Obrázek 3.5: P ípad uºití diá Obrázek 3.6: P ípad uºití faktura

40 22 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Obrázek 3.7: P ípad uºití rma Obrázek 3.8: P ípad uºití vícejazy nost

41 3.2. NÁVRH 23 Obrázek 3.9: P ípad uºití projekt Obrázek 3.10: P ípad uºití prom nná

42 24 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Obrázek 3.11: P ípad uºití uºivatel Obrázek 3.12: Domain model - prom nné a vícejazy nost Obrázek 3.13: Domain model - diá

43 3.2. NÁVRH 25 Obrázek 3.14: Domain model - odd lení Obrázek 3.15: Domain model - faktura Obrázek 3.16: Domain model - rma

44 26 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Obrázek 3.17: Domain model - projekt Obrázek 3.18: Domain model - uºivatel

45 3.2. NÁVRH Diá V této ásti si ukáºeme, jakým zp sobem by m l fungovat diá, který budu pouºívat v aplikaci. M lo by se jednat o modikaci kalendá e, který je pouºíván v RichFaces. M l by v²ak naopak od kalendá e - organizéru, který je nabízen od RichFaces, um t p echázet mezi m síci, p ípadn roky. To v sou asnosti tento kalendá nenabízí, proto bude t eba daný problém vy e²it. Na níºe p iloºeném sekven ním diagramu je znázorn no, jak by m la práce s diá em vypadat. Operace changemonth m ºe nastávat opakovan. Obrázek 3.19: Sekven ní diagram - Diá Automatizace V této sekci se budeme zabývat tím, co to je a jak by m la vypadat automatizace na ítání projektu v rámci aplikace O co se jedná Myslím si, ºe nejlep²í pro vysv tlení bude ukázat si automatizaci na ítání projektu na jednoduchém p íkladu.

46 28 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Firma pouºívá systém pro správu projekt X. Rozhodne se pouºívat tento systém pro asové výkaznictví, dále Y. V Y je moºné p i azovat asové záznamy k jednotlivým projekt m, aby poté bylo moºné provád t jednodu²e fakturaci. Jinými slovy, projektová data, která jsou pr b ºn p idávána do systému pro správu projekt X, je t eba p idávat v omezené mí e i do Y, aby se podle toho mohlo fakturovat nebo plánovat. O toto p idávání projektových dat se v²ak bude starat Y sám. Pomocí automatizovaného na ítání projekt. P i emº vykonavatelem na ítání z X bude automatizér X. Nyní si ukaºme scéná. 1. Do X je p idána fáze projektu Z 2. Na této fázi za ínají d lat zam stnanci 3. Pot ebují vkládat asové záznamy k p idané fázi 4. Uºivatel s rolí vy²²í neº zam stnanec má za úkol provést p idání fáze 5. Spustí automatizér nad projektem Z 6. Tento automatizér na te chyb jící data z X a p idá je do Y 7. Zam stnanec nyní jiº m ºe vkládat asové záznamy k nové fázi Funk nost Poºadavkem na tuto ást je, aby fungovala stejn na v²ech aplika ních serverech. M lo by být moºné p idávat automatizace za b hu bez nutnosti zastavení aplikace. Automatizace bude fungovat na základ rozhraní ProjectInterface. 17 To bude voláno p i kaºdém automatizovaném update aplikace. Bude zde pouºit Interpreter Pattern. Dále je nutné z d vodu bezpe nosti dat nedávat k dispozici p ímo objekt Project. Pro tyto pot eby bude pln dosta ovat Facade Pattern. Pomocí n ho budou zprost edkovan provád ny operace, jako p idej fázi projektu, Faktura ní proces Kaºdá faktura má sv j proces vývoje od svého vzniku aº k jejímu p edání k proplacení. Nejd íve je nutné fakturu vytvo it, tuto akci provádí kaºdý uºivatel s právy v t²ími nebo rovnými zam stnanci. Poté si m ºe p idávat k faktu e dal²í poloºky. Tuto fakturu následn ode²le ke zpracování. Manaºer jí bu schválí, nebo vrátí k p epracování Faktura ní vzory V rámci aplikace bude moºné pouºívat zvolený faktura ní vzor s moºností modikace podle pot eb rmy. M lo by se jednat o vzory, které by m ly být vytvo itelné pomocí html a následn do nich budou dosazena data. Bude vytvo en základní dle p edlohy z [52]. 17 JAR soubor, který bude obsahovat implementaci tohoto rozhraní, bude nazýván v dal²ím textu Automatizér. JAR - archiva ní soubor pouºívaný programovacím jazykem Java.

47 3.2. NÁVRH 29 Obrázek 3.20: Class diagram - Automatizace Obrázek 3.21: Stavový diagram - fakturace

48 30 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Internacionalizace Protoºe faktura ní vzory budou vícejazy né, vyvstává nutnost mít moºnost p idávat vícejazy ná slova za b hu. Tato slova budou p idána aº poté, pokud nebudou v aplikaci objevena. V p ípad, ºe je slovo objeveno podle klí e, vrací se jeho hodnota. Obrázek 3.22: Sekven ní diagram - zprávy Mapa stránek Na níºe p iloºeném obrázku vidíme mapu stránek, jeº bude pokrývat celý chod aplikace. Na kaºdou stránku bude kumulováno pomocí AJAXu více operací, aby innost uºivatele mohla být co nejrychlej²í a nejefektivn j²í Návrh vzhledu webové aplikace Na základ hodnocení od uºivatel p i usability testingu do²lo k výb ru základní template. Po ur ité fázi vývoje do²lo i k potvrzení dal²ích testovaných p edpoklad s výjimkou zakulacených ráme k, které v²ak byly z estetických d vod zachovány.

49 3.2. NÁVRH 31 Obrázek 3.23: Mapa stránek

50 32 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Obrázek 3.24: Návrh vzhledu íslo 1

51 3.2. NÁVRH 33 Obrázek 3.25: Návrh vzhledu íslo 2

52 34 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ 3.3 P ípady uºití podrobn ji V této sekci si probereme podrobn ji jednotlivé p ípady uºití P ípady uºití uºivatele P ihlá²ení Primární aktér : Pozorovatel 1. Uºivatel se pokusí p ihlásit do aplikace. 2. Zadá své p ihla²ovací údaje. 3. Pokusí se p ihlásit. 3b) P ihlá²ení se nezda í, pokra ování bodem 2. Garance úsp chu : P ihlá²ení do aplikace a vypsání informa ního hlá²ení Odhlá²ení Primární aktér : Pozorovatel 1. Uºivatel je p ihlá²en. 2. Pokusí se odhlásit z aplikace. Garance úsp chu : Úsp ²n se odhla²uje a je vypsáno informa ní hlá²ení P idání nového uºivatele Primární aktér : Manager 1. Uºivatel nav²tíví stránku pro p idávání uºivatel. 2. Zadá data nového uºivatele. 3. Pokusí se p idat nového uºivatele. 3b) Chyba p i validaci dat nového uºivatele, pokra uje bodem 2. Garance úsp chu : P idání nového uºivatele a vypsání informa ního hlá²ení o úsp ²ném p idání.

53 3.3. P ÍPADY UšITÍ PODROBN JI Prohlíºení a správa uºivatel Primární aktér : Manager 1. Uºivatel nav²tíví stránku pro prohlíºení uºivatel. 2. Zadá parametry, podle kterých se má vyhledávat. 3. Vybere daného uºivatele. 4. Dále jiº v²e postupuje podle p ípadu uºití Správa uºivatele (kapitola ). 2b) Tento krok je moºné p esko it a vyhledávat mezi v²emi uºivateli. Garance úsp chu : Nalezení hledaného uºivatele Zm na odd lení uºivatele Primární aktér : Manager 1. Uºivatel nav²tíví sv j prol. 2. Rozhodne se zm nit svoje odd lení. 3. Pokusí se zm nu provést. 3b) Zm na se nezda í, protoºe se jedná o vedoucího daného odd lení. Garance úsp chu : Zm na odd lení a výpis informa ního hlá²ení Správa uºivatele Editace uºivatele Primární aktér : Zam stnanec 1. Uºivatel nav²tíví sv j prol. 2. Rozhodne se pro editaci prolu. 3. Provede zm nu dat. 4. Pokusí se uloºit zm nu. 4b) Data neprojdou validací, pokra uje bodem 3. Garance úsp chu : Provedení zm ny osobních informací a vypsání informa ního hlá²ení.

54 36 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Obrázek 3.26: P ípad uºití správa uºivatele P idání poznámky k uºivateli Primární aktér : Zam stnanec 1. Uºivatel nav²tíví sv j prol. 2. Napí²e poznámku. 3. Pokusí se ji odeslat. 3b) Poznámka neprojde validací,pokra uje bodem 2. Garance úsp chu : P idání poznámky a vypsání informa ního hlá²ení. Úprava role uºivatele Primární aktér : Zam stnanec 1. Uºivatel nav²tíví zm nu rolí. 2. Vybere poºadovanou roli. 3. Pokusí se o zm nu rolí. 3b) Zm na není umoºn na, protoºe uºivatel nemá dostate ná oprávn ní. Garance úsp chu : Zm na role a vypsání informa ního hlá²ení.

55 3.3. P ÍPADY UšITÍ PODROBN JI 37 P idání zku²eností uºivatele Primární aktér : Zam stnanec 1. Uºivatel nav²tíví správu zku²eností. 2. Zadá zku²enost. 3. Zadá klí ová slova zku²enosti. 4. Pokusí se p idat zku²enost. 4b) Chyba p i validaci dat, pokra uje bodem 2. Garance úsp chu : P idání zku²enosti a výpsání informa ního hlá²ení. Editace zku²eností uºivatele Primární aktér : Zam stnanec 1. Uºivatel nav²tíví správu zku²eností. 2. Najde zku²enost, kterou chce zm nit. 3. Provede zm nu. 4. Zm nu potvrdí. 4b) Chyba p i validaci dat, pokra uje bodem 3. Garance úsp chu : Zm na zku²enosti a výpis informa ního hlá²ení. Smazání zku²eností uºivatele Primární aktér : Zam stnanec 1. Uºivatel nav²tíví správu zku²eností. 2. Najde zku²enost, kterou chce odstranit. 3. Pokusí se o odstran ní. Garance úsp chu : Odstran ní záznamu a výpis informa ního hlá²ení.

56 38 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ P ípad uºití diá Prohlíºení obsahu diá e Primární aktér : Zam stnanec 1. Uºivatel nav²tíví sv j diá. 2. M ní m síce nebo roky, které chce prohlíºet. 3. P esouvá se na zvolený m síc (rok). Garance úsp chu : Získání záznam k volenému období s rozli²ením podle d leºitosti Správa diá e Obrázek 3.27: P ípad uºití správa diá e P idání záznamu do diá e Primární aktér : Zam stnanec 1. Uºivatel nav²tíví sv j diá. 2. Zvolí den záznamu. 3. Zadá záznam. 4. Pokusí se p idat záznam.

57 3.3. P ÍPADY UšITÍ PODROBN JI 39 3b) Bude se jednat o opakovaný záznam, p ibývají poloºky. 4b) Záznam neprojde validací, pokra uje bodem 3. Garance úsp chu : Záznam je p idán, je vypsáno informa ní hlá²ení. Odstran ní záznamu z diá e Primární aktér : Zam stnanec 1. Uºivatel nav²tíví sv j diá. 2. Zvolí den záznamu. 3. Pokusí se odstranit záznam z diá e. 3b) Pokusí se odstranit opakovaný záznam z diá e. Garance úsp chu : Záznam je odebrán, je vypsáno informa ní hlá²ení. Zm na záznamu v diá i Primární aktér : Zam stnanec 1. Uºivatel nav²tíví sv j diá. 2. Zvolí den záznamu. 3. Upraví záznam v diá i. 4. Pokusí se zm nu uloºit. 4b) Záznam neprojde validací, pokra uje budem 3. Garance úsp chu : Zm na záznamu v diá i, je vypsáno informa ní hlá²ení Správa diá e uºivatel Primární aktér : Manager 1. Uºivatel najde hledaného uºivatele a nav²tíví jeho diá. 2. V dal²ích bodech jiº odpovídá p ípadu uºití Správa diá e (kapitola ). 1b) Uºivatel nemá dostate ná oprávn ní k prohlíºení diá e. Garance úsp chu : Provedení správy diá e uºivatel.

58 40 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Obrázek 3.28: P ípad uºití prohlíºení odd lení P ípad uºití odd lení Prohlíºení odd lení Prohlíºení zam stnanc odd lení Primární aktér : Zam stnanec 1. Uºivatel nav²tíví vybrané odd lení. 2. Zvolí prohlíºení zam stnanc daného odd lení. 3. Prohlíºí zam stnance a jejich funkce. Garance úsp chu : Uºivatel najde zkoumaná data o zam stnancích odd lení. Prohlíºení pododd lení odd lení Primární aktér : Zam stnanec 1. Uºivatel nav²tíví vybrané odd lení. 2. Zvolí prohlíºení struktury odd lení. 3. Prohlíºí odd lení a jejich pododd lení. Garance úsp chu : Uºivatel najde data o struktu e odd lení.

59 3.3. P ÍPADY UšITÍ PODROBN JI Vytvo ení odd lení Primární aktér : Manaºer 1. Uºivatel nav²tíví stránku pro vytvo ení nového odd lení. 2. Zadá data pot ebná k vytvo ení nového odd lení. 3. Zadá p íkaz k vytvo ení nového odd lení. 4. ƒeká na dokon ení operace. 4b) Data neprojdou validací a je nutné je opravit,pokra uje bodem 3. Garance úsp chu : Nové odd lení je vytvo eno, je vypsáno informa ní hlá²ení Správa odd lení Obrázek 3.29: P ípad uºití správa odd lení

60 42 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ P idání zam stnance k odd lení Primární aktér : Manaºer 1. Uºivatel nav²tíví vybrané odd lení. 2. Rozhodne se k n mu p idat volného zam stnance. 3. Provede volbu zam stnance. 4. Pokusí se ho vloºit do odd lení. Garance úsp chu : hlá²ení. Úsp ²né p idání zam stnance do odd lení, je vypsáno informa ní Odebrání zam stnance z odd lení Primární aktér : Manaºer 1. Uºivatel nav²tíví vybrané odd lení. 2. Podívá se na zam stnance odd lení. 3. Zvolí zam stnance k odebrání. 4. Pokusí se ho odebrat. 4b) Zadaný zam stnanec je vedoucím odd lení, a proto nejde odebrat. Garance úsp chu : Úsp ²né odebrání zam stnance, je vypsáno informa ní hlá²ení. Úprava funkce zam stnance v odd lení Primární aktér : Manaºer 1. Uºivatel nav²tíví vybrané odd lení. 2. Podívá se na zam stnance odd lení. 3. U vybraného zam stnance provede zm nu. 4. Pokusí se uloºit zm nu. 4b) Zm na neprojde validací, pokra uje bodem 4. Garance úsp chu : Funkce upravena, je vypsáno informa ní hlá²ení.

61 3.3. P ÍPADY UšITÍ PODROBN JI 43 Ozna ení uºivatele jako vedoucího odd lení Primární aktér : Manaºer 1. Uºivatel nav²tíví vybrané odd lení. 2. Podívá se na zam stnance odd lení. 3. Provede volbu nového vedoucího. Garance úsp chu : Vedoucí odd lení nastaven, je vypsáno informa ní hlá²ení. P idání pododd lení k odd lení Primární aktér : Manaºer 1. Uºivatel nav²tíví vybrané odd lení. 2. Podívá se do jeho pododd lení. 3. Z volných odd lení provede výb r nového pododd lení. 4. Pokusí se p idat nové pododd lení. Garance úsp chu : Pododd lení p idáno, je vypsáno informa ní hlá²ení. Odebrání pododd lení od odd lení Primární aktér : Manaºer 1. Uºivatel nav²tíví vybrané odd lení. 2. Podívá se do jeho pododd lení. 3. Z aktuálních pododd lení zvolí to, které chce odebrat. 4. Pokusí se odebrat pododd lení. Garance úsp chu : Pododd lení odebráno, je vypsáno informa ní hlá²ení.

62 44 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Úprava odd lení Primární aktér : Manaºer 1. Uºivatel nav²tíví vybrané odd lení. 2. Zadá, ºe chce provád t úpravy na odd lení. 3. Provede zm ny. 4. Pokusí se upravit odd lení. 4b) Úprava neprojde validací, pokra uje bodem 3. Garance úsp chu : Odd lení upraveno, je vypsáno informa ní hlá²ení. Odstran ní odd lení Primární aktér : Manaºer 1. Uºivatel nav²tíví vybrané odd lení. 2. Pokusí se odstranit dané odd lení. 2b) Odstran ní se nezda í, protoºe odd lení obsahuje uºivatele nebo pododd lení. Garance úsp chu : Odd lení odstran no, je vypsáno informa ní hlá²ení. Odstran ní vedoucího odd lení Primární aktér : Manaºer 1. Uºivatel nav²tíví vybrané odd lení. 2. Pokusí se odstranit vedoucího odd lení. Garance úsp chu : Je odstran n vedoucí odd lení, je vypsáno informa ní hlá²ení P ípad uºití rma Generování faktur Primární aktér : Manaºer 1. Uºivatel nav²tíví vybrané odd lení. 2. Zvolý m síc, pro který chce vytvo it fakturu. 3. Nav²tíví odkaz pro zobrazení faktury. Garance úsp chu : Uºivateli je vygenerována pdf faktura.

63 3.3. P ÍPADY UšITÍ PODROBN JI Vytvo ení rmy Primární aktér : Manaºer 1. Uºivatel nav²tíví stránku pro vytvá ení rmy. 2. Zadá data pot ebná pro zavedení rmy do systému. 3. Pokusí se vloºit rmu. 3b) Data nepro²la validací, pokra uje bodem 2. Garance úsp chu : Firma je úsp ²n vytvo ena, je vypsáno informa ní hlá²ení P i azení projektu k rm Primární aktér : Manaºer 1. Uºivatel nav²tíví konkrétní rmu. 2. Rozhodne se p i adit volný projekt k rm. 3. Vybere projekt. 4. Pokusí se ho p i adit. Garance úsp chu : Projekt je p i azen, je vypsáno informa ní hlá²ení Odebrání projektu od rmy Primární aktér : Manaºer 1. Uºivatel nav²tíví konkrétní rmu. 2. Zvolí projekt, který chce odebrat. 3. Pokusí se odebrat projekt. 3b) Odebrání se nepovedlo, k projektu jsou jiº vytvo eny faktury a asové záznamy. Garance úsp chu : Projekt je odebrán, je vypsáno informa ní hlá²ení.

64 46 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Obrázek 3.30: P ípad uºití pokro ilá správa rmy Pokro ilá správa rmy Úprava rmy Primární aktér : Manager 1. Uºivatel nav²tíví konkrétní rmu. 2. Rozhodne se pro zm nu dat. 3. Provede zm nu. 4. Pokusí se zm nu uloºit. 4b) Zm na neprojde validací, pokra uje bodem 3. Garance úsp chu : Úprava rmy provedena, je vypsáno informa ní hlá²ení. Odstran ní kontaktu rmy Primární aktér : Manager 1. Uºivatel nav²tíví vybrané odd lení. 2. Najde konkrétní kontakt. 3. Rozhodne se ho odstranit. 4. Pokusí se ho odstranit. Garance úsp chu : Kontakt byl odstran n, je vypsáno informa ní hlá²ení.

65 3.3. P ÍPADY UšITÍ PODROBN JI 47 Obrázek 3.31: P ípad uºití správa rmy Správa rmy P idání záznamu k rm Primární aktér : Zam stnanec 1. Uºivatel nav²tíví konkrétní rmu. 2. Rozhodne se p idat záznam k rm. 3. Vyplní data záznamu. 4. Pokusí se vloºit záznam. 4b) Data nepro²la validací, pokra uje bodem 3. Garance úsp chu : Záznam byl p idán, je vypsáno informa ní hlá²ení. P idání kontaktu k rm Primární aktér : Zam stnanec 1. Uºivatel nav²tíví konkrétní rmu. 2. Rozhodne se p idat kontakt k rm.

66 48 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ 3. Vyplní data kontaktu. 4. Pokusí se vloºit kontakt. 4b) Data nepro²la validací, pokra uje bodem 3. Garance úsp chu : Kontakt byl p idán, je vypsáno informa ní hlá²ení. Úprava kontaktu rmy Primární aktér : Zam stnanec 1. Uºivatel nav²tíví konkrétní rmu. 2. Najde konkrétní kontakt. 3. Rozhodne se pro zm nu kontaktu. 4. Provede zm nu. 5. Pokusí se uloºit zm nu. 5b) Data nepro²la validací, pokra uje bodem 4. Garance úsp chu : Kontakt byl upraven, je vypsáno informa ní hlá²ení. P idání záznamu ke kontaktu Primární aktér : Zam stnanec 1. Uºivatel nav²tíví konkrétní rmu. 2. Najde konkrétní kontakt. 3. Rozhodne se k n mu p idat záznam. 4. Vyplní data. 5. Pokusí se p idat záznam. 5b) Data nepro²la validací, pokra uje bodem 4. Garance úsp chu : Záznam byl p idán ke kontaktu, je vypsáno informa ní hlá²ení.

67 3.3. P ÍPADY UšITÍ PODROBN JI 49 Prohlíºení informací o rm Primární aktér : Zam stnanec 1. Uºivatel nav²tíví konkrétní rmu. 2. Prohlíºí dostupná data. 3. Listuje v tabulkách. Garance úsp chu : Uºivatel najde zkoumaná data o rm. Prohlíºení kontaktu Primární aktér : Zam stnanec 1. Uºivatel nav²tíví konkrétní rmu. 2. Uºivatel zvolí kontakt. 3. Prohlíºí dostupná data. 4. Listuje v tabulkách. Garance úsp chu : Uºivatel najde zkoumaná data o kontaktech ve rm P ípady uºití projektu Vytvo projekt Primární aktér : Manaºer 1. Uºivatel nav²tíví stránku pro vytvo ení projektu. 2. Zadává poºadovaná data. 3. Pokusí se p idat projekt. 3b) Data neprojdou validací, pokra uje bodem 2. Garance úsp chu : Vytvo ení projektu, je vypsáno informa ní hlá²ení.

68 50 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Prohlíºení obsahu projektového diá e Primární aktér : Zam stnanec 1. Uºivatel nav²tíví poºadovaný projekt. 2. Vstoupí do projektového diá e. 3. M ní m síce nebo roky, které chce prohlíºet. 4. P esouvá se na zvolený m síc (rok). Garance úsp chu : podle d leºitosti. Získání komentá e,milestone, todo k volenému období s rozli²ením Správa projektového diá e Obrázek 3.32: P ípad uºití správa projektového diá e P idání komentá e,milestone, todo do diá e Primární aktér : Zam stnanec 1. Uºivatel nav²tíví poºadovaný projekt.

69 3.3. P ÍPADY UšITÍ PODROBN JI Nav²tíví projektový diá. 3. Zvolí komentá e,milestone,todo. 4. Zadá pot ebná data. 5. Pokusí se p idat komentá e,milestone,todo. 4b) Bude se jednat o opakovaný komentá e,milestone, todo, p ibývají poloºky. 5b) Komentá e,milestone, todo neprojdou validací, pokra uje bodem 3. Garance úsp chu : Komentá e,milestone, todo jsou p idány, je vypsáno informa ní hlá²ení. Odstran ní komentá e,milestone, todo z diá e Primární aktér : Zam stnanec 1. Uºivatel nav²tíví poºadovaný projekt. 2. Nav²tíví projektový diá. 3. Zvolí komentá e,milestone,todo. 4. Pokusí se ho odstranit. 4b) Odstraní opakované komentá e,milestone, todo z projektového diá e. Garance úsp chu : Komentá e,milestone, todo jsou odebrány, je vypsáno informa ní hlá²ení. Zm na komentá e,milestone, todo v diá i Primární aktér : Zam stnanec 1. Uºivatel nav²tíví poºadovaný projekt. 2. Nav²tíví projektový diá. 3. Zvolí komentá e,milestone,todo. 4. Upraví komentá e,milestone,todo v projektovém diá. 5. Pokusí se uloºit zm nu. 5b) Komentá e,milestone, todo neprojdou validací, pokra uje bodem 3. Garance úsp chu : Zm na komentá e,milestone, todo v projektovém diá i, je vypsáno informa ní hlá²ení.

70 52 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Obrázek 3.33: P ípad uºití správa fází projektu Správa fází projektu P idání fáze projektu Primární aktér : Manager 1. Uºivatel nav²tíví poºadovaný projekt. 2. Nav²tíví fáze projektu. 3. Rozhodne se p idat fázi. 4. Zadá pot ebná data. 5. Pokusí se p idat fázi. 5b) Zm na neprojde validací, pokra uje bodem 4. Garance úsp chu : Fáze byla p idána, je vypsáno informa ní hlá²ení. Odstran ní fáze projektu Primární aktér : Manager 1. Uºivatel nav²tíví poºadovaný projekt. 2. Nav²tíví fáze projektu. 3. Rozhodne se pro zm nu dat.

71 3.3. P ÍPADY UšITÍ PODROBN JI Zm nu provede. 5. Pokusí se uloºit zm nu. 4b) Zm na neprojde validací, pokra uje bodem 3. Garance úsp chu : Úprava provedena, je vypsáno informa ní hlá²ení. Editace fáze projektu Primární aktér : Manager 1. Uºivatel nav²tíví poºadovaný projekt. 2. Nav²tíví fáze projektu. 3. Rozhodne se pro zm nu dat. 4. Zm nu provede. 5. Pokusí se uloºit zm nu. 4b) Zm na neprojde validací, pokra uje bodem 3. Garance úsp chu : Úprava provedena, je vypsáno informa ní hlá²ení Správa automatizace projektu Volba automatizéru projekt Primární aktér : Administrátor 1. Uºivatel nav²tíví automatizaci projekt. 2. Zvolí konkrétní projekt. 3. Zvolí automatizér. 4. Pokusí se provést zm nu. Garance úsp chu : Automatizér byl p idán k projektu, je vypsáno informa ní hlá²ení. Odstran ní automatizéru projektu Primární aktér : Administrátor 1. Uºivatel nav²tíví automatizaci projekt. 2. Zvolí konkrétní projekt. 3. Provede odstran ní automatizéru. Garance úsp chu : Automatizér je odstran n, je vypsáno informa ní hlá²ení.

72 54 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Obrázek 3.34: P ípad uºití správa automatizace projektu Spu²t ní automatizéru projektu Primární aktér : Administrátor 1. Uºivatel nav²tíví automatizaci projekt. 2. Zvolí konkrétní projekt. 3. Rozhodne se pro spu²t ní automatizovaného na tení projektu pomocí automatizéru. 4. Pokusí se provést automatizaci. 5. Zm na dokon ena. 4b) P i b hu dojde k chyb, je vypsána chybová hlá²ka. Garance úsp chu : Úprava projektu, je vypsáno informa ní hlá²ení. Odstran ní automatizéru Primární aktér : Administrátor 1. Uºivatel nav²tíví automatizaci projekt. 2. Najde automatizér. 3. Pokusí se ho odstranit.

73 3.3. P ÍPADY UšITÍ PODROBN JI 55 3b) Odstran ní není umoºn no, automatizér je pouºíván, pokra uje bodem 2. Garance úsp chu : Odstran ní automatizéru je provedeno, je vypsáno informa ní hlá²ení. Nahrání automatizéru Primární aktér : Administrátor 1. Uºivatel nav²tíví automatizaci projekt. 2. Rozhodne se nahrát nový automatizér. 3. Najde odpovídající automatizér ve svém souborovém systému. 4. Potvrdí volbu automatizéru. 5. Pokusí se nahrát nový automatizér. 5b) Nový automatizér není moºné nahrát, protoºe se nejedná o JAR soubor nebo neobsahuje poºadovanou implementaci. Garance úsp chu : Automatizér je nahrán, je vypsáno informa ní hlá²ení P ípad uºití faktury Nastavení faktura ního vzoru pro fakturu Primární aktér : Zam stnanec 1. Uºivatel nav²tíví fakturaci. 2. Zvolí fakturu. 3. Rozhodne se zm nit faktura ní vzor. 4. Zvolí faktura ní vzor. 5. Pokusí se provést zm nu. Garance úsp chu : Zm na provedena, je vypsáno informa ní hlá²ení.

74 56 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Vygenerování faktury Primární aktér : Zam stnanec 1. Uºivatel nav²tíví fakturaci. 2. Zvolí fakturu. 3. Rozhodne se vygenerovat pdf fakturu. 4. Vygeneruje fakturu. Garance úsp chu : Vygenerování faktury P edání k fakturaci Primární aktér : Zam stnanec 1. Uºivatel nav²tíví fakturaci. 2. Zvolí fakturu. 3. Rozhodne se poslat ji k fakturaci. 4. Pokusí se provést akci. Garance úsp chu : Fakturace odeslána ke zpracování, je vypsáno informa ní hlá²ení Potvrzení faktury Primární aktér : Manager 1. Uºivatel nav²tíví faktury v²ech. 2. Zvolí fakturu. 3. Rozhodne se ji potvrdit. 4. Pokusí se provést zm nu. Garance úsp chu : Fakturace potvrzena, je vypsáno informa ní hlá²ení.

75 3.3. P ÍPADY UšITÍ PODROBN JI P edání faktury zp t Primární aktér : Manager 1. Uºivatel nav²tíví faktury v²ech. 2. Zvolí fakturu. 3. Rozhodne se ji vrátit k p epracování. 4. Pokusí se provést zm nu. Garance úsp chu : Fakturace vrácena k p epracování, je vypsáno informa ní hlá²ení Prohledávání faktur Primární aktér : Zam stnanec 1. Uºivatel nav²tíví fakturaci. 2. Zadá parametry, podle kterých chce hledat fakturu. 3. Provede vyhledávání. Garance úsp chu : Nalezení poºadovaných faktur Správa faktur uºivatel Primární aktér : Manaºer 1. Uºivatel nav²tíví faktury v²ech. 2. Provádí operace podle p ípad uºití Prohledávání faktur (kapitola ), Odstran ní asového záznamu (kapitola ), Zm na asového záznamu (kapitola ). Garance úsp chu : Provedení operací

76 58 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Obrázek 3.35: P ípad uºití správa asových záznam Správa asových záznam P idání asového záznamu Primární aktér : Zam stnanec 1. Uºivatel nav²tíví fakturaci. 2. Rozhodne se p idat asový záznam. 3. Zadá pot ebná data. 4. Pokusí se p idat asový záznam. 4b) ƒasový záznam neprojde validací, pokra uje bodem 3. Garance úsp chu : ƒasový záznam je p idán, je vypsáno informa ní hlá²ení. Odstran ní asového záznamu Primární aktér : Zam stnanec 1. Uºivatel nav²tíví fakturaci. 2. Rozhodne se odstranit asový záznam. 3. Zvolí asový záznam. 4. Pokusí se ho odebrat.

77 3.3. P ÍPADY UšITÍ PODROBN JI 59 3b) ƒasový záznam není moºné odebrat, protoºe jiº pro²el fakturací. Garance úsp chu : ƒasový záznam je odebrán, je vypsáno informa ní hlá²ení. Zm na asového záznamu Primární aktér : Zam stnanec 1. Uºivatel nav²tíví fakturaci. 2. Rozhodne se zm nit asový záznam. 3. Zvolí asový záznam. 4. Zadá pot ebná data. 5. Pokusí se zm nit asový záznam. 5b) ƒasový záznam neprojde validací, pokra uje bodem 4. Garance úsp chu : ƒasový záznam je zm n n, je vypsáno informa ní hlá²ení Správa faktura ních vzor Obrázek 3.36: P ípad uºití správa faktura ních vzor

78 60 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ P idání faktura ního vzoru Primární aktér : Administrátor 1. Uºivatel nav²tíví faktura ní vzory. 2. Rozhodne se p idat faktura ní vzor. 3. Zadá pot ebná data. 4. Pokusí se p idat faktura ní vzor. 4b) Faktura ní vzor neprojde validací, pokra uje se bodem 3. Garance úsp chu : Faktura ní vzor je p idán, je vypsáno informa ní hlá²ení. Odstran ní faktura ního vzoru Primární aktér : Administrátor 1. Uºivatel nav²tíví faktura ní vzory. 2. Rozhodne se odstranit faktura ní vzor. 3. Zvolí faktura ní vzor. 4. Pokusí se ho odebrat. 3b) Faktura ní vzor není moºné odebrat, protoºe je pouºíván. Garance úsp chu : Faktura ní vzor je odebrán, je vypsáno informa ní hlá²ení. Zm na faktura ního vzoru Primární aktér : Administrátor 1. Uºivatel nav²tíví faktura ní vzory. 2. Rozhodne se zm nit faktura ní vzor. 3. Zvolí faktura ní vzor. 4. Zadá pot ebná data. 5. Pokusí se zm nit faktura ní vzor. 5b) Faktura ní vzor neprojde validací, pokra uje bodem 4. Garance úsp chu : Faktura ní vzor je zm n n, je vypsáno informa ní hlá²ení.

79 3.3. P ÍPADY UšITÍ PODROBN JI P ípad uºití vícejazy nost Prohledávání internacionalizace Primární aktér : Manager 1. Uºivatel nav²tíví internacionalizaci. 2. Zadá klí. 3. Zvolí vyhledávání. Garance úsp chu : Nalezeny odpovídající záznamy Úprava internacionalizace Primární aktér : Manager 1. Uºivatel nav²tíví internacionalizaci. 2. Zvolí konkrétní slovo. 3. Provede zm nu. 4. Pokusí se uloºit zm nu. Garance úsp chu : Zm na provedena, je vypsáno informa ní hlá²ení P ípad uºití prom nné Prohledávání prom nných Primární aktér : Manager 1. Uºivatel nav²tíví prom nné. 2. Zadá klí. 3. Zvolí vyhledávání. Garance úsp chu : Nalezeny odpovídající záznamy.

80 62 KAPITOLA 3. ANALÝZA A NÁVRH E ENÍ Úprava prom nné Primární aktér : Manager 1. Uºivatel nav²tíví prom nné. 2. Zvolí konkrétní prom nnou. 3. Provede zm nu. 4. Pokusí se uloºit prom nnou. Garance úsp chu : Zm na provedena, je vypsáno informa ní hlá²ení P idání prom nné Primární aktér : Manager 1. Uºivatel nav²tíví prom nné. 2. Rozhodne se p idat prom nnou. 3. Zadá data prom nné. 4. Pokusí se vloºit prom nnou. 4b) Prom nná neprojde validací, pokra uje se bodem 3. Garance úsp chu : Prom nná p idána, je vypsáno informa ní hlá²ení Odstran ní prom nné Primární aktér : Manager 1. Uºivatel nav²tíví prom nné. 2. Zvolí konkrétní prom nnou. 3. Pokusí se odstranit prom nnou. Garance úsp chu : Odstran ní provedeno, je vypsáno informa ní hlá²ení.

81 Kapitola 4 Realizace V této kapitole se budu zabývat zajímavými ástmi implementace aplikace. Postupn proberu následující body: JARClassLoader p i na ítání automatizéru. Automatizované na ítání projektu. Standardizace vzhledu aplikace zaloºeného na vzhledu RichFaces komponent. Validace vstupních dat. Na ítání webového obsahu z databáze. Clustrování aplika ního serveru. Clustrování databáze. Diá zaloºený na kalendá i RichFaces. FileUpload problém. QueryBuilder. Test Driven Development. U kaºdé ásti budu sledovat toto: Popis problém a cíle. e²ení. Neº se v²ak dostanu k jednotlivým ástem, myslím, ºe je nutné uvést verze klí ových knihoven a software, které byly pouºity. Poté provedu základní seznámení s frameworkem Seam, na kterém je celá aplikace zaloºena. 63

82 64 KAPITOLA 4. REALIZACE Knihovna Verze Seam GA Hibernate GA EJB 3.0 JSF 1.2_12 RichFaces GA Facelets B1 Hibernate Validator GA Drools Testng 5.9 MySQL Driver Software Verze JBoss Embeded beta3.sp12 JBoss Application Server 5.1 MySQL 7.0 Tabulka 4.1: Pouºité knihovny a software 4.1 Pouºité knihovny a software Pouºity byly tyto knihovny a software (kapitola 4.1). 4.2 Seam Seam (tato kapitola erpá z [3] a vlastních zku²eností )je p edev²ím vynikající integra ní framework. Výborn do sebe integruje adu standardizovaných technologií - Servlet, JSF, EJB, Web Services,... ale také frameworky, které nejsou sou ástí ºádného standardu - Spring, Hibernate,.... Je navrºen tak, ºe je doporu en k pouºití spolu s frameworkem Facelets. Je stavovým frameworkem. Umoº uje nám p ímý p ístup k entitám a na obsluhu událostí m ºe být pouºita p ímo Session beana 1. Samoz ejm také e²í problém s ukládáním dat do Session 2, p i emº toto ukládání minimalizuje a udrºuje data v rámci svého kontextu - Seam Contextu na aplika ním serveru. Toto je umoºn no práv díky tomu, ºe se jedná o stavový framework. Tento kontext je poté svázán p es konverza ní identikátor. Nevýhodou Seamu je zprovozn ní první funk ní aplikace, které je podle mého názoru velmi náro né. Musím ale uznat, ºe od dob, kdy jsem se s tímto frameworkem za ínal seznamovat, se objevilo velké mnoºství návod, které tento start se Seamem výrazn usnad ují. Nyní se seznámíme se zajímavými vlastnostmi Seamu, p i emº vºdy uvedu p íklad a následn k n mu vyuºití. 1 Session beana - Stateful Session Bean (SFSB) nebo Stateless Session Bean(SLSB), slouºí ke komunikaci mezi webovou a aplika ní vrstvou 2 Session - prost edek k uchování dat pouºívaných b hem komunikace mezi uºivatelem a servrem. Tato data z stávají dostupná od za átku komunikace se serverem, aº po jeho opu²tení.

83 4.2. SEAM public class EntityManager LoggedUser loggeduser; } Bijekce se skládá z injekce a outjekce. Injekce p edstavuje vloºení závislosti do komponenty p i jejím vytvo ení.v na²em p ípad vloºení EntityManageru ze Seam Contextu. Outjekce se pouºívá k uloºení, v na²em p íklad LoggedUser, do Seam Contextu. Odtud si ho samoz ejm m ºeme pozd ji na íst z jiné komponenty. Ob tyto anotace mají dva velmi d leºité parametry : create - pokud objekt není v Seam Contextu, je automaticky vytvo en, v p ípad, ºe create=true, required - nastavením required=true oznamujeme, ºe objekt musí být dostupný v Seam Contexu v ase vytvá ení komponenty Podpora vytvá ení a ukon ení public class public void public void finish(){} } Takto oanotované metody jsou volané p i vytvo ení (create) nebo zániku (destroy) komponenty. Dají se velmi dob e vyuºít, nap íklad k inicializaci dat v komponent Scope komponent Stateless bezestavové komponenty. Event komponenta zodpovídá za jeden JSF poºadavek. Page komponenta je vztaºená ke stránce, je p ístupná b hem v²ech JSF poºadavk z jedné stránky.

84 66 KAPITOLA 4. REALIZACE Conversation komponenta, která není vztaºená ke stránce, vy izuje sérii JSF poºadavk, má sv j za átek a konec. Session platnost po dobu celé konverzace mezi uºivatelem a aplikací (servrem). Business process kontext slouºící pro dlouhotrvající business procesy spravované pomocí JBoss jbmp frameworku. Application kontext platný po celou dobu b hu aplikace, není vztaºen ke konkrétnímu uºivateli Správa transakcí a na ítání z databáze Seam díky svému EntityManageru a díky tomu, ºe se jedná o stavový framework, umoº uje provád t na ítání objekt lazy bez obav, ºe dojde ke vzniku LazyInitializationException. Navíc automatizuje správu transakcí, o které se také nemusíme starat. Naopak ale umoº uje vynucení této správy Testování Seam je od základ navrºen tak, aby umoº oval testování. Integruje do sebe testovací framework testng (viz [53]). Ten je pouºíván na Unit testy. Dále umoº uje po nastavení provád t integra ní testy za pouºití jboss embedded serveru Seam Expression Language <h:commandbutton value="#{foo.bar(value)}"/> Seam umoº uje volání funkcí s parametry. To není pomocí JSF moºné Ukázka propojení webové a aplika ní vrstvy public class ManagerAction implements Manager { public String sayhello(){ return "Hello"; } }

85 4.3. JARCLASSLOADER P I NAƒÍTÁNÍ AUTOMATIZÉRU Dal²í uºite ná funk nost Správa práv pomocí drools. Validace dat pomocí Hibernate Validators. Podpora Bussines Process - jbpm. Podpora tvorby PDF, . Podpora Quartz Scheduleru. Vlastní tagy,nap íklad pro validaci Struktura Seam aplikace Obrázek 4.1: Struktura Seam aplikace, p ebrané z [3] 4.3 JARClassLoader p i na ítání automatizéru Popis problém a cíle V aplikaci bude moºné p idávat takzvané automatizéry. Díky t m lze na ítat aktuální stav projekt, nap íklad z JIRY, pomocí vlastní implementace. P idávání t chto automatizér musí probíhat za b hu aplikace bez nutnosti restartu, protoºe aplikace je od základu navrhovaná jako vysoce dostupná, tudíº by se nem la zastavovat. Na ítání se provádí pomocí Class- Loader (viz [32] [13]).

86 68 KAPITOLA 4. REALIZACE Class Loading Java poskytuje stromovou strukturu Class Loader. Kaºdý z t chto Class Loader slouºí k na ítání a správ jiného druhu t íd. Nyní si osv tlíme to, s ím který konkrétní Class Loader Obrázek 4.2: Na tení implementace pracuje. Bootstrap Class Loader je zodpov dný za nahrání t íd z jádra Javy, jedná se o t ídy z balí ku java.* a javax.*. Extension Class Loader je zodpov dný za nahrání t íd z Java Runtime Environments, konkrétn z adresá e extension. System Class Loader je zodpov dný za nahrání t íd ze systému. Nyní na jednoduchém p íkladu vysv tlím, jak se v Jav vyhledávájí t ídy v systému Class Loader. Za íná se od System Class Loaderu, pokud se t ída najde, vrátí se a vytvo í se její instance. Pokud ne, deleguje se vyhledávání na Extension Class Loader a zde probíhá p esn to samé. Toto delegování funguje ve sm ru ²ipek. Velmi d leºité v²ak je, ºe to, co je nahráno do t chto 3 Class Loader, jiº nikdy nezm níme ani neodebereme! CustomJARClassLoader Jak jiº bylo zmín no, v aplikaci bude pot eba p ídávat automatizéry. V minulé sekci jsem uvedl, ºe pokud na teme t ídu do jednoho ze základních Class Loader Javy, uº ji nem ºeme zm nit ani odstranit. Ale to mi pot ebujeme, protoºe co kdyº byl nahrán JAR soubor, který neobsahuje ani v jednom p ípad poºadované rozhraní ProjectInterface? Nebo pokud se rozhodneme, ºe pot ebujeme zm nit implementaci? Nebo se rozhodneme, ºe nechceme, aby t ídy byly systémem na teny a nezabíraly zbyte né systémové prost edky. Toho je moºné dosáhnout jedin vytvo ením svého vlastního Class Loaderu, odte CustomJarClassLoader.

87 4.3. JARCLASSLOADER P I NAƒÍTÁNÍ AUTOMATIZÉRU 69 V aplikaci toho budu vyuºívat p i nahrávání automatizéru do systému a dále p i pouºití automatizéru, který bude na ítán z databáze. Obrázek 4.3: Na tení implementace e²ení Pot ebujeme vytvo it CustomJarClassLoader, který je na diagramu odd len p eru²ovanou arou. Protoºe tento class loader jiº není sou ástí základních t íd Javy, je moºné ho odstranit. Nyní zjednodu²en popí²u, jak to celé funguje. CustomJarClassLoader test = new CustomJarClassLoader(); test.definejar("/path/reloadingproject.jar", ProjectInterface.class); Class clazz = test.loadclass("mypackage.projectimpl", false); System.out.println(((ProjectInterface) clazz.newinstance()).sayhello()); test = new CustomJarClassLoader(); test.definejar("/otherpath/reloadingproject.jar", ProjectInterface.class); clazz = test.loadclass("mypackage.projectimpl", false); System.out.println(((ProjectInterface) clazz.newinstance()).sayhello()); A se jedná o stejnou t ídu ( t ída je identikována svým jménem a package ), v obou p ípadech dostáváme jiný výpis. Implementaci CustomJarClassLoader je moºné najít ve zdrojových kódech k projektu. D leºité na tomto je, ºe p vodní denice je odstran na spolu s nahrazením prom nné test novou instancí t ídy CustomJarClassLoader.

88 70 KAPITOLA 4. REALIZACE 4.4 Automatizované na ítání projektu Popis problém a cíle Tato ást navazuje na kapitoly 4.3 a V té je e²ena jen první ást problému. V této ásti se zam ím na to, jakým zp sobem budu realizovat ást druhou, a to pouºitím tohoto automatizéru. Základem pro popis e²ení bude aktivity diagram 4.4. Obrázek 4.4: Na tení implementace e²ení Jak je na obrázku vid t, je t eba na íst implementaci z databáze. Pro tomu tak je. Aplikace je navrºena tak, aby fungovala na clusteru aplika ních server. Nyní si p edstavme tuto situaci. Pokud bychom automatizér nahráli na jeden server a následn ho nevloºili do databáze pro budoucí pouºití, museli bychom zajistit to, ºe se daná implementace Project- Interface nahraje na v²echny servery, i ty, které se p ipojí aº v budoucnu. To bohuºel není reálné. Proto bylo zvoleno e²ení, p i kterém je celá implementace nahrána do databáze a p i kaºdém pouºití na ítána pomocí CustomJarClassLoader. Tím zajistíme, ºe je k dispozici na kterémkoliv serveru. K aktualizaci dat samotného projektu se pouºije zvolená t ída, která implementuje ProjectInterface. Poté se jiº provede aktualizace. Ta samotná obsahuje potencionální bezpe nostní problém. Automatizér nesmí aktualizovat jiná neº projektová data. e²ení se ukázalo být pouºití návrhového vzoru Facade na t ídu Projekt. Tou bylo umoºn no provád t pouze tyto operace 4.5. Funk nost automatizéru byla ov ena testovací implementací.

89 4.5. STANDARDIZACE VZHLEDU APLIKACE ZALOšENÉHO NA VZHLEDU RICHFACES KOMPO Obrázek 4.5: Project Facade 4.5 Standardizace vzhledu aplikace zaloºeného na vzhledu Rich- Faces komponent Popis problém a cíle V aplikaci jsou pouºívány RichFaces komponenty. Ty mají svoji p eddenovanou barvu pozadí, okraj atd. Existuje velké mnoºství t chto barevných kombinací, které jsou pom rn zda ilé. Problémem v²ak je, ºe ne v²e se dá sloºit z komponent RichFaces. Ob as je t eba vytvá et obsah tradi n pomocí vlastních html tag, ale ty by nem ly nap íklad pozadí, které je pouºíváné skrze RichFaces, a tím by vznikla barevná nekonzistence ve vzhledu stránky. e²ením by bylo pouºití stejné barvy jako u RichFaces. Toto by v²ak m lo omezení. Nemohli bychom m nit barevné vzhledy, protoºe bychom m li napevno denované barvy na²eho html obsahu. Proto je t eba e²it zbarvení dynamicky e²ení e²ení se skládá ze dvou bod. Nejprve je t eba vybrat vhodnou barvu z barevné palety RichFaces (viz [47]). Tyto barvy najdeme v souboru *.skin.properties. Za hv zdi ku je moºné si dosadit nap íklad emeraldtown, ale i mnohé jiné. Poté,co tuto barvu najdeme, je nutné ji zabudovat do stránky. P idat barvu pozadí pro dané html tagy. Protoºe toto p idávání pot ebujeme provád t dynamicky, nahrává to pouºití JavaScriptu. Díky zku²enostem, které mám s pouºíváním jquery, m napadlo, ºe by tuto funk nost mohlo podporovat. Výsledkem je kód, který propojuje barvení vlastních komponent se skiny RichFaces. <rich:jquery selector="#wrapper" query="css('background-color','#{a4jskin.headergradientcolor}')" /> <rich:jquery selector="b.rtop" query="css('background-color','#{a4jskin.headergradientcolor}')" />

90 72 KAPITOLA 4. REALIZACE První je kód, který v²em id=wrapper p i adí barvu, která je v konkrétním RichFaces skinu denována jako headergradientcolor. Druhý p ípad je funk ní pro t ídu s názvem tag b s t ídou rtop. 4.6 Validace vstupních dat Popis problém a cíle Validace vstupních dat není triviálním problémem. Poºadavkem je, aby byla tato validace co moºná nejvíce automatická a výsledek pro uºivatele musí být z eteln viditelný. Vhodné by bylo vytvo ení svého vlastního validárotu pro kontrolu primárního klí e e²ení Pro validaci byl pouºit framework Hibernate Validator. Jeho výhodou je podpora frameworkem RichFaces. Díky n mu je moºné provád t validace hned poté, co slovo dopí²eme, aniº by musela být stránka znovuna tena. Validátor pro kontrolu primárního klí e byl vytvo en. Buhuºel má pom rn zásadní problémy p i pouºívání, které nyní popí²u. P i úprav existujícího objektu ob as docházelo k ValidationException. Nyní vysv tlím, pro k tomu docházelo. V p ípad vytvo ení nového objektu problém není. Ten za íná, pokud chci modikovat stávající, p i emº klí ový atribut nem ním. P i validaci si nemám jak dodat informaci o tom, jaký byl p vodní (ne)modikovaný atribut klí e,a proto mi validátor oznámí, ºe mnou m n ný objekt má duplikátní klí ový atribut. e²ení je v²ak vcelku jednoduché. Neprovád t validaci nad entitou, ale mít speciální atribut v seamové komponent, který validuji a následn ho p i vytvá ení a vkládání objektu do databáze objektu nastavím. Dále by jiº tento klí ový atribut m l být nem nný. B hem implementace byl s validátory zji²t n je²t jeden problém. Ten nastává v p ípad, ºe datum musí být v budoucnosti - anotace Future. Problém s tímto druhem validace se m ºe bohuºel velmi umn skrývat. P edpokládejme stromovou strukturu t íd. Jeden z list má nastaveno, ºe jeden z atribut musí být v budoucnosti. Postupem asu se dostane do sou asnosti, coº nám nemusí vadit, ale pokud modikujeme vrchol stromové struktury, objeví se nám ValidationException. V tuto chvíli bohuºel s velkou pravd podobností nevím, kde se v aplikaci stala chyba. 4.7 Na ítání webového obsahu z databáze Popis problém a cíle V aplikaci je poºadavkem, aby bylo moºné vytvá et faktury. Tyto faktury v²ak musí být vzhledov modikovatelné, aniº by bylo nutné restartovat aplikaci. Jinými slovy, je nutné, aby byly modikovatelné za b hu aplikace.

91 4.7. NAƒÍTÁNÍ WEBOVÉHO OBSAHU Z DATABÁZE 73 Obrázek 4.6: Na ítání faktury z databáze e²ení Celý tento cyklus 4.6 bude vypadat takto. Východiskem zde bylo, ºe pouºíváme frameworky Seam a Facelets. Díky nim je moºné generovat faktury automatizovan v poºadovaném formátu pdf. Bohuºel jiº neumoº ují jakoukoliv zm nu vzhledu za b hu. V následujícím textu budu vycházet z toho, ºe vzhled faktury je uloºen v databázi, a budu to tedy p edpokládat. Za nu tím, ºe se pokusím vysv tlit, jak Facelets (viz [14]) fungují. Chci, aby mi nap íklad jeden servlet mohl generovat více druh faktur. Problémem v²ak je, ºe Facelets si vytvo í svou implementaci, do které se nahraje obsah vygenerovaný servletem. Následn si uloºí adresu, na které tuto implementaci na²el. Já poté m ºu m nit atribut nap íklad fakturaservlet?fakturatemplate=zakladni na fakturaservlet?fakturatemplate=novy, ale atributy jiº Facelets nerozli²ují. Tím se dostávám ke kroku - P esm rování poºadavku na zdroj v Servletu. Co se v tomto kroku d je. Aby mohl jeden servlet generovat více druh pdf faktur, musí být poºadavky sm rovány na r zné adresy, které budou na základ n jakého pravidla obsluhovány servletem. V tomto p ípad to bude klí ové slovo print_my_facture_now, p i emº za ním se nachází n jaký naprosto náhodný string. Tím je zaji²t no, ºe bude vytvo en pro kaºdou fakturu speciální facelets, který bude vracet poºadovaný obsah. Toto sm rování v²ak není triviální záleºitost. Je t eba vytvo it pro Facelets speciální ResourceResolver a navíc nastavit, ºe má být pouºíván. ve web.xml <context-param> <param-name>facelets.resource_resolver</param-name> <param-value>mypackage.templateresolver</param-value> </context-param> vytvo it t ídu mypackage.templateresolver public class TemplateResolver extends DefaultResourceResolver implements ResourceResolver{...}

92 74 KAPITOLA 4. REALIZACE V t íd TemplateResolver p epí²i metodu resolveurl a budu p esm rovávat v²echny poºadavky, které budou p icházet s klí ovým slovem print_my_facture_now na servlet. V dal²ím bod na tu faktura ní vzor z databáze. D leºité je, aby byla p ípona výsledného souboru shodná se soubory, které jsou mapovány Seamem. Díky tomu je mu poté dodán Seam Context. Z toho následn na erpáme data, která je pot eba vyplnit do faktury. Seam následn na základ xhtml vygeneruje poºadovanou pdf fakturu 4.7. Obrázek 4.7: Faktura vzor

93 4.8. CLUSTROVÁNÍ FRAMEWORKU SEAM Clustrování frameworku Seam Pro nastavení Seamu do clustrovaného reºimu je t eba n kolik nastavení. v components.xml <core:init distributable="true"/> Dal²í podmínkou je, ºe v²e, co je replikované 3, musí být i serializovatelné 4. To je totiº zp sob, jakým jsou data mezi servery p ená²ena. 4.9 Clustrování aplika ního serveru Popis problém a cíle Ze zadání vyplývá, ºe aplikace má být schopna b ºet na clusteru aplika ních server (viz [30]). Poºadavky jsou takovéto : LoadBalancing server. Replikace HTTP Session. Replikace SFSB a SLSB. Replikace Entity - Cache e²ení e²ení bylo realizováno na základ dokumentace k JBoss AS 5.1 (viz [30]) Spu²t ní Clusteru./run.sh -c all -g DocsPartition -u \ -b Djboss.messaging.ServerPeerID=1./run.sh -c all -g DocsPartition -u \ -b Djboss.messaging.ServerPeerID=2 Pro zprovozn ní pot ebujeme mít staºený aplika ní server s variantou pro pouºití v clusteru - ALL. Ta je zvolena atributem c, dále atribut g nám ur uje název cluster, u ur uje multicast adresu, p es kterou komunikují, b je adresa, na kterou se server p ipojuje a je na ní vystaven. Nakonec kv li pouºití JMS 5 musí být nastaveno ServerPeerID specické pro kaºdý server v clusteru. 3 Replikované - p ená²ené z jednoho serveru na druhý 4 Serializace - p evod instance t ídy do byte podoby 5 JMS - Java Message Service je specikace, která slouºí k zasílání zpráv a to jak synchronn, tak asynchronn

94 76 KAPITOLA 4. REALIZACE LoadBalancing server K loadbalancování server byl pouºit Apache za pouºití pluginu mod_jk. Loadbalancer v aplikaci slouºí k rozd lování zát ºe mezi jednotlivé servery v clusteru. Defaultn je nastavené rozd lování Round Robin 6, ale je moºné nastavit jiné, p ípadn implementovat sv j vlastní zp sob rozd lování. Krom vlastní instalace, která je popsána zde B.2,je t eba provést toto nastavení pro aplika ní server, aby podporoval load balancing pomocí pluginu mod_jk. v server1/.../deploy/jbossweb.sar/server.xml <Engine name="jboss.web" defaulthost="localhost" jvmroute="node1"> v server2/.../deploy/jbossweb.sar/server.xml <Engine name="jboss.web" defaulthost="localhost" jvmroute="node2"> Replikace HTTP Session Abychom umoºnili replikaci HTTP Session,je nutné upravit web.xml takto : <web-app> <distributable /> <!-- Toto je nutné p idat --> </web-app> Dále je moºné nastavit, p i jaké akci se bude session replikovat. SET - p i kaºdém nastavení session. SET_AND_GET - p i kaºdém nastavení session nebo získávání informací z ní. SET_AND_NON_PRIMITIVE_GET - p i kaºdém nastavení session nebo získávání neprimitivních dat z ní, t mi jsou nap íklad int, string,.... ACCESS - p i kaºdém p ístupu k session. Kaºdé z t chto nastavení jinak zat ºuje servery nutnou replikací. Defaultn je nastaveno SET, který minimalizuje zatíºení serveru, pokud chceme nastavit jinak, musíme zm ny provést v server/all/deploy/cluster/jboss-cache-manager.sar/ META-INF/jboss-cache-congs.xml. server/all/deploy/cluster/jboss-cache-manager.sar/ META-INF/jboss-cache-managerjboss-beans.xml. jboss-web.xml. 6 Round Robin v Apache funguje tak, ºe pravideln st ídá pouºívaný aplika ní server pro nov p íchozí uºivatele.

95 4.9. CLUSTROVÁNÍ APLIKAƒNÍHO SERVERU Replikace SFSB a SLSB V tomto p ípad jsou nabízeny dv moºnosti. Jedna pomocí anotací a druhá pomocí denice v jboss.xml. Jak jsem zjistil, kongurace pomocí anotací mi nefungovala. Replikace v bec neprobíhala. Za ala fungovat aº poté, co jsem nastavil soubor jboss.xml,a to takto : <jboss> <enterprise-beans> <session> <ejb-name>mypackage.statelesssession</ejb-name> <clustered>true</clustered> </session> </enterprise-beans> </jboss> Krom tohoto je zde moºné nastavit i zp sob loadbalancování, cacheování Replikace Entity - Cache V této sekci si vysv tlím, jak nastavit, aby bylo moºné replikovat EntityManager cache. Toho dosáhnu tím, ºe nastavím soubor persistence.xml takto : <property name="hibernate.cache.use_second_level_cache" value="true"/> <property name="hibernate.cache.use_query_cache" value="true"/> <property name="hibernate.cache.region.factory_class" value="org.hibernate.cache.jbc2.jndimultiplexedjboss CacheRegionFactory"/> <!-- region factory specific properties --> <property name="hibernate.cache.region.jbc2.cachefactory" value="java:cachemanager"/> <property name="hibernate.cache.region.jbc2.cfg.entity" value="mvcc-entity"/> <property name="hibernate.cache.region.jbc2.cfg.collection" value="mvcc-entity"/> <property name="hibernate.cache.region_prefix" value="tempdb"/> Tato kongurace lze samoz ejm m nit a je svázána se souborem jboss-cache-manager-jbossbeans.xml v adresá i server/all/deploy/cluster/jboss-cache-manger.sar/meta-inf/. Je zde moºné nastavit nap íklad zp sob cacheování, zamykání uzl p i replikaci cache atd. Nakonec je t eba nastavit u kaºdé entity zp sob cachování, a to se d lá takto Je moºné nastavit i jiné, ale JBoss podporuje pouze módy TRANSACTIONAL a READ_ONLY. Rozdíl je v tom, ºe o READ_ONLY se p edpokládá, ºe jsou data po vytvo ení jiº nem nná, zatímco TRANSACTIONAL je uzp sobeno pro zm ny obsahu.

96 78 KAPITOLA 4. REALIZACE 4.10 Clustrování databáze Popis problém a cíle Ze zadání vyplývá, ºe aplikace musí být vysoce dostupná. Protoºe v tomto p ípad nesta í jen vysoká dostupnost aplika ního serveru, musí být vytvo ena vysoce dostupná i databáze (viz [39]) Ta by m la být op t loadbalancovaná. K tomu mi poslouºí MySQL Cluster, který poºadované vlastnosti spl uje e²ení Obrázek 4.8: Clustrování databáze, p ebrané z [39] B hem e²ení jsem se seznámil i s n kterými dal²ími vlastnostmi MySQL Clusteru : Automatická podpora Load Balancingu. 99,999% dostupnost. Zotavení z chyb. kálovatelný. Zde bych v²ak m l výtku ke ²kálovatelnosti. MySQL Cluster je ²kálovatelný, ale pouze co se tý e p íkaz typu READ, na WRITE p íkazy se ²kálovatelnost nevztahuje. e²ením je realizace aplikace za pomoci datových sklad. To by mohla být cesta, kterou by se aplikace mohla do budoucna ubírat. Výhodou by bylo, ºe pro datové sklady je jiº vyvíjena podpora frameworkem Hibernate Shards, který by byl pro stávající aplikaci ideální, protoºe samotná jiº Hibernate jako takový pouºívá. Nyní se dostaneme k specik m, která bychom m li o MySQL Clusteru znát.

97 4.11. DIÁ ZALOšENÝ NA KALENDÁ I RICHFACES 79 Pokud chceme, aby byla zaji²t na vysoká dostupnost databáze, je nutné nastavit po et replik minimáln na 2. Zárove je v²ak doporu ováno nastavit práv 2. Zajistíme tím redundanci dat. NumberOfReplicas = 2; Nutností je vytvá ení tabulek se speciálním typem uloºi²t, které jsou poté replikovatelné v rámci tohoto clusteru. To za ídíme tím, ºe budeme vytvá et tabulky s úloºi²t m typu NDB nebo NDBCLUSTER. CREATE TABLE `mytable` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `mynumber` bigint(20) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=ndbcluster AUTO_INCREMENT=2 DEFAULT CHARSET=utf8; Nakonec je t eba upravit jdbc pro datový zdroj a p idat dal²í kongura ní parametry. To se provádí v souboru persistence.xml. jdbc:mysql:loadbalance://host:port[,hostn:portn]/db_name?storage_engine=ndbcluster D leºité je, aby se aplikace p ipojovala na MySQL Cluster Application Nodes 4.8. Dal²ími parametry jsou : loadbalanceblacklisttimeout=x - spojení jsou v poolu, ale ve chvíli, kdy je n jaké po dobu x nefunk ní, je z n ho odstran no, failoverreadonly=false/true - nastavení na read only v p ípad ºe do²lo k pádu jednoho ze server a aplikace je v autoreconect módu, loadbalancestrategy=(random/bestresponsetime) - náhodn nebo podle nejkrat²ího asu p edchozí transakce zvolíme uzel. Detailní informace naleznete na [40] Diá zaloºený na kalendá i RichFaces Popis problém a cíle Poºadavkem na aplikaci je, aby obsahovala funk ní diá pro zaznamenávání pot ebných informací. Framework RichFaces poskytuje kalendá, který jde pouºít jako organizér. Pro pot eby aplikace je v²ak nedosta ující. Pot ebuji, aby bylo moºné m nit m síce nebo roky. To bohuºel stávájící implementace neumoº uje. Proto je t eba najít e²ení.budu vycházet z diagramu. Richfaces nemají podporu pro change month, tuto funk nost je t eba dod lat.

98 80 KAPITOLA 4. REALIZACE Obrázek 4.9: Sekven ní diagram - Diá e²ení Pro e²ení tohoto problému je t eba komplexn pochopit fungování celého kalendá e Rich- Faces. Nakonec je v²ak e²ení pom rn jednoduché. Sta í provést následující kroky : toto je v *.xhtml <a4j:form> <a4j:jsfunction name="change" rerender="organizer"/> </a4j:form> <rich:calendar id="organizer"... > <a4j:support event="oncurrentdateselected" action="#{calendardatamodel.updateselecteddate}" oncomplete="change()"/> </rich:calendar> komponenta calendardatamodel public void updateselecteddate(){ items = null; } kde items je : private CalendarDataModelItem[] items; Nyní si v²e vysv tlíme. Mám kalendá, nastavením pro organizér se nebudu zabývat, je moºné ho najít na [46], kde je jednozna n identikován jako organizer. P idám mu obsluhu události oncurrentdateselected. To je událost, která vznikne, pokud je zm n n m síc nebo

99 4.12. FILEUPLOAD PROBLÉM 81 Zkou²ená verze RichFaces GA GA GA GA CR1 Fungující FileUpload komponenta ne ne ano ne ne Tabulka 4.2: RichFaces a FileUpload rok kalendá e. Na základ této události jsou vynulovány v²echna data v kalendá i pomocí metody updateselecteddate. Poté co je celá akce dokon ena, je zavolána metoda change, která vyvolá p ekreslení organizer, tedy mého kalendá e. Pokud kalendá nemá data, coº jsou v tomto p ípad items v calendardatamodel, vydá p íkaz k jejich znovuna tení. Tím je zaru eno, ºe se na tou data z poºadovaného m síce FileUpload problém Popis problém a cíle V aplikaci je nutné nahrávat soubory automatizéru. Jak jsem zjistil, s frameworkem Rich- Faces to není jednoduchý úkol. Problémem bylo, ºe p es správné nastavení nahrávání souboru neza alo e²ení Po nastavení v²ech moºných kongurací mi nahrávání soubor stále nefungovalo. Byl jsem si jistý, ºe kongurace je správn, proto jsem se rozhodl zm nit knihovnu RichFaces. Aº po dlouhém zkou²ení a hledání jsem zjistil, ºe pouze s knihovnou verze GA nahrávání soubor funguje. Toto je d vod, pro nebyla pouºita verze GA Realizace zabezpe ení pomocí HTTPS Popis problém a cíle P i vývoji aplikace byl od základu kladen d raz na zabezpe ení a rozd lení rolí. Z toho vychází i poºadavek na zabezpe ení datových p enos pomocí protokolu HTTPS e²ení Pro realizaci op t existuje podpora v Seamu, ale je t eba provést n kolik nastavení. Nastavení v pages.xml <pages... login-view-id="/login.xhtml" http-port="8080" https-port="8443"> <page view-id="/*" login-required="true" scheme="https"/>

100 82 KAPITOLA 4. REALIZACE Tímto nastavení íkám, ºe pro HTTPS se má pouºívat port V dal²ím ádku je nastaveno, ºe protokol HTTPS bude pouºíván v celé aplikaci. Dal²ím krokem nutným k zprovozn ní HTTPS je získání certikátu a jeho pouºití v aplikaci. Návod k realizaci naleznete v sekci B QueryBuilder Popis problém a cíle P i vyhledávání na základ n kolika parametr, jejichº po et se m ºe m nit, je sloºité vytvá et vºdy za pomoci soustavy podmínek výsledný dotaz na databázi - dále dotaz. Proto bylo vhodné vytvo it n jaký univerzální dotazova, kterému bych pouze p edával parametry a nakonec by mi vyrobil poºadovaný dotaz e²ení Byl vytvo en QueryBuilder, který musí být nejd íve inicializován vstupními parametry. Mezi ty pat í vloºení entitymanageru, t ídy, která bude vyhledávána, a nakonec identikátor, který bude ke t íd pouºíván pro vyhledávání. Tento QueryBuilder umoº uje vkládání parametr, které m hou být zadávány pro operace =, >=, <= a zdali je paramatr obsaºen v kolekci. Zde bych upozornil, ºe Hibernate neumoº uje prohledávání kolekcí pomocí HQL. Nejd íve je nutné vytvo it kolekci, nap íklad String s klí ovým slovem, p i emº poté m ºeme pomocí klí ového slova in testovat, zda je daný parametr v kolekci. Funk nost QueryBuilderu je samoz ejm moºné roz²í it, ale pro stávající implementaci to nebylo t eba. Celé toto funguje na základ vkládání parametr do map a jejich následném prohledávání a vkládání do dotazu. Do n j jiº p icházejí parametry pat i n modikované, aby byl dotaz korektní Test Driven Development Popis problém a cíle Na za átku vývoje jsem uvaºoval, jakým zp sobem chci vlastn projekt vyvíjet. Nakonec jsem se rozhodl pro techniku, kterou jsem je²t nikdy p edtím nepouºíval. Rozhodl jsem se pro progamování íºené testy. Rozhodl jsem se, ºe tento p ístup k programování budu pouºívat v²ude tam, kde se provád jí n jaké sloºit j²í operace Co to vlastn je Dle [51] je smyslem Test Driven Development vyvíjet aplikaci po malých ástech, p i emº pro kaºdou takovou ást je t eba nejd íve napsat test a teprve poté implementaci samotnou. Zaru uje nám to, ºe je aplikace poté do zna né míry pokrytá testy a navíc chyby rychle odhalím. Na vý²e p iloºeném activity diagramu4.10 je vid t, ºe Test Driven Development je iterativní proces. Napí²emi test, poté implementaci. Spustím test. Pokud projde, pí²u dal²í test. Pokud ne, ud lám úpravu a spustím test znovu. Pokud projde, pí²u dal²í test, jinak znovu upravuji kód implementace.

101 4.16. POJMENOVÁVÁNÍ SEAM KOMPONENT 83 Obrázek 4.10: Test Driven Development, p ebrané z [51] Výsledky S pouºitím Test Driven Development p i vývoji aplikace jsem spokojen. Myslím, ºe se mi díky tomuto p ístupu poda ilo najít spoustu chyb jiº p i psaní implementace. Jinak bych tyto chyby musel sloºit dohledávat. Nevýhodou tohoto p ístupu je, ºe je náro ný na dodrºování disciplíny p i psaní test Pojmenovávání Seam komponent Popis problém a cíle U Seamu se asto stává, ºe v komponent ²patn vyhledáváme komponentu v daném Seam Contextu. S tímto problémem jsem se zpo átku asto setkával, proto si myslím, ºe stojí za to ho vysv tlit e²ení ekl bych, ºe problém je pom rn komplexní a dá se rozd lit do dvou ástí. Obojí p edvedu na p íkladech. v components.xml <persistence:managed-persistence-context name="entitymanager" auto-create="true" persistence-unit-jndi-name="java:/unitfactory"/>

102 84 KAPITOLA 4. REALIZACE T public class CustomComponent{ public class CustomComponent EntityManager entitymanager; } Prvním p ípadem je vkládání komponenty denované v components.xml do vlastní komponenty. V tomto p ípad se musí rovnat hodnota atributu name, v tomto p ípad entitymanager názvu prom nné, kterou chceme injektovat. V p ípad t ídy, v na²em p ípad CustomComponent, která má jméno komponenty mycomponent je nutné,aby poté název prom nné v UserComponent byl také mycomponent. Alternativou je = "nazev_komponenty") Vytvo ení nového faktura ního vzoru Popis problém a cíle V této sekci se chci zam it na vysv tlení, jakým zp sobem musí být vytvo ené faktura ní vzory, co v nich je umoºn né pouºívat. D raz byl kladen na jednoduchost jejich vytvá ení e²ení Jsou dv moºnosti, jak faktury vytvá et. První, nau it se jak se se Seamem vytvá í pdf soubory. Druhý zp sob je výrazn jednodu²²í. <p:html> zde jiº fakturu vytvá ím podle html tag </p:html> Nyní si je²t musíme popsat, co v²e m ºeme pouºívat za prom nné. #{messages['id_zpravy']}. #{propertyservice.getproperty('id_property')}. Ostatní prom nné, které jsou k nalezení zde B.1.

103 Kapitola 5 Testování Kaºdá kvalitní aplikace musí mít ve svém vývoji i fázi testování. Samoz ejm ji m la i tato aplikace. Tuto ást rozd lím na ty i kapitoly. 1. Integra ní a Unit testy. 2. Usability testing. 3. Black box testing. 4. Testování funk nosti clusteru aplika ního serveru. 5.1 Integra ní a Unit testy V této ásti se budu zabývat nastavením nutným pro b h test, p edm tem testování a výsledky test Nastavení Pro integra ní testy v Seamu je t eba provést dodate ná nastavení. Tato nastavení se skládají ze dvou ástí. Rozb hnutí embedded JBoss aplika ního serveru. Vloºení inicializa ních dat. Pro rozb hnutí embedded JBoss aplika ního serveru byla pouºita jeho verze beta3.sp12. Byla vytvo ena testovací struktura, dle [49]. Dále je v²ak t eba nastavit data pouºívaná k testování seamové aplikace. Na obrázku5.1 je vid t v²e, co pot ebujeme k rozb hnutí testování. Upozornil bych v²ak, ºe jndi pro vyhledávání komponent je v embedded JBoss pon kud odli²ná neº na klasickém serveru. components.xml <core:init jndi-pattern="/#{ejbname}/local" distributable="true"/> Dále v data-source nesmí být obsaºeny ºádné meta-informace. V opa ném p ípad dojde k pádu aplikace p i testování. 85

104 86 KAPITOLA 5. TESTOVÁNÍ Obrázek 5.1: Test Struktura Vloºení inicializa ních dat Jako p i kaºdém testu je t eba, aby byla vloºena inicializa ní data. K tomuto ú elu bude pouºit framework dbunit (viz [17]), který umoº uje na tení stávajících dat z databáze. Ta si uloºíme do n jakého souboru a následn je m ºeme pouºívat v testech. Pro pot eby aplikace byla vytvo ena základní data a poté vyexportována pro pot eby test Co bylo testováno Jak jiº bylo zmín no, aplikace byla vytvá ena metodou Test Driven Development. Nyní bych probral, co bylo tímto zp sobem testováno : Ve²kerá komunikace s databází. Ve²keré netriviální operace, tedy operace, které nebyly typu get, set Výsledky test Výsledky test bych popsal pon kud ob²írn ji. Testy samotné m ly p ínos dokonce z n kolika d vod. Prvním bylo to, ºe díky test m bylo objeveno velké mnoºství chyb, které by se jinak pracn dohledávaly. Druhou nespornou výhodou je jistá záruka funk nosti jednotlivých komponent a ástí systému. Kone ným výsledkem testování je stoprocentní úsp ²nost test. 5.2 Usability testing Testování pouºitelnosti m ºeme rozd lit do dvou ástí.

105 5.2. USABILITY TESTING Papírový prototyp Vzor Hlas 1.vzor 3,5 2.vzor 1,5 3.vzor 0 Tabulka 5.1: Vzory rozvrºení plochy V první ásti se budu zabývat volbou vzhledu aplikace. K tomu jsem provedl debatu s 5 participanty, kte í m li za úkol pomoci mi vybrat vhodné rozvrºení pracovní plochy aplikace. Poºadavkem pro výb r bylo, aby participanti rozmístili t i základní ásti pracovní plochy : Obrázek 5.2: Papírový prototyp Menu. Obsah. Patu stránky. V dal²ím textu budu vzory íslovat zleva doprava od jedni ky. Na základ t chto výsledk 5.1 byl vybrán vzor íslo Usability testing aplikace Cílem testování je ud lat aplikaci co moºná nep ív tiv j²í uºivatel m. Výsledkem by m lo být zjednodu²ení a zrychlení práce s aplikací Hypotézy Informa ní tooltipy výrazn pomáhají k orientaci na stránce. Moºnost volby vzhledu vede k zp ehledn ní stránky. Kulaté ráme ky ( nifty ) pomáhají k rozli²ení dat - tabulky versus výpisy. Validace pomocí podbarvení a informa ního tooltipu nad vyk i níkem je dostaten upozor ující na chybu p i validaci.