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

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

iv

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.

vi

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 11. 5. 2010

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

viii

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

x

Obsah 1 Úvod

1

2 Úvodní studie

3

1.1 2.1

2.2 2.3 2.4

2.5 2.6

2.7

Struktura práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Re²er²e informa£ních systém· . . . 2.1.1 Poºadavky na systém . . . 2.1.2 Achievo . . . . . . . . . . . 2.1.3 JIRA . . . . . . . . . . . . . 2.1.4 Bugzilla . . . . . . . . . . . 2.1.5 Dovico . . . . . . . . . . . . 2.1.6 Ontime . . . . . . . . . . . 2.1.7 Trac . . . . . . . . . . . . . 2.1.8 Srovnání . . . . . . . . . . . Pro£ vlastní °e²ení . . . . . . . . . Sou£asný stav . . . . . . . . . . . . Poºadovaný stav . . . . . . . . . . 2.4.1 Funk£ní poºadavky . . . . . 2.4.2 Nefunk£ní poºadavky . . . . 2.4.2.1 Multiplatformnost 2.4.2.2 Internacionalizace 2.4.2.3 Modularita . . . . 2.4.2.4 Zab¥zpe£ení . . . 2.4.2.5 Podpora HTTPS . 2.4.2.6 Vysoce dostupný . Odhadovaný £as tvorby aplikace . . Analýza rizik . . . . . . . . . . . . 2.6.1 Technologická rizika . . . . 2.6.2 Vysoká dostupnost . . . . . 2.6.3 Dodate£ná funk£nost . . . . 2.6.4 Bezpe£nostní rizika . . . . . 2.6.5 Chybná volba technologií . 2.6.6 as dokon£ení . . . . . . . Komponenty systému . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2

3 3 4 4 4 4 5 5 5 5 6 6 6 7 7 7 7 7 7 7 7 8 8 8 8 8 8 9 9

xii

OBSAH

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

3.2

3.3

Poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Poºadavky na modulární aplikaci . . . . . . . . . . 3.1.2 Poºadavky na aplika£ní framework . . . . . . . . . 3.1.2.1 Spole£né vlastnosti . . . . . . . . . . . . . 3.1.2.2 Spole£né vlastnosti Seam a Spring . . . . 3.1.2.3 JEE . . . . . . . . . . . . . . . . . . . . . 3.1.2.4 Spring . . . . . . . . . . . . . . . . . . . . 3.1.2.5 Seam . . . . . . . . . . . . . . . . . . . . 3.1.2.6 Volba . . . . . . . . . . . . . . . . . . . . 3.1.3 Poºadavky na framework pro perzistenci dat . . . 3.1.4 Poºadavky na framework(y) pro prezenta£ní vrstvu 3.1.5 Poºadavky na vysokou dostupnost . . . . . . . . . 3.1.5.1 Vysoká dostupnost aplika£ního serveru . . 3.1.5.2 Vysoká dostupnost databáze . . . . . . . 3.1.6 Poºadavky na web . . . . . . . . . . . . . . . . . . Návrh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Deployment diagram . . . . . . . . . . . . . . . . . 3.2.2 Actors . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 P°ípady uºití . . . . . . . . . . . . . . . . . . . . . 3.2.4 Entity . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.5 Diá° . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.6 Automatizace . . . . . . . . . . . . . . . . . . . . . 3.2.6.1 O co se jedná . . . . . . . . . . . . . . . . 3.2.6.2 Funk£nost . . . . . . . . . . . . . . . . . . 3.2.7 Faktura£ní proces . . . . . . . . . . . . . . . . . . . 3.2.8 Faktura£ní vzory . . . . . . . . . . . . . . . . . . . 3.2.9 Internacionalizace . . . . . . . . . . . . . . . . . . . 3.2.10 Mapa stránek . . . . . . . . . . . . . . . . . . . . . 3.2.11 Návrh vzhledu webové aplikace . . . . . . . . . . . P°ípady uºití podrobn¥ji . . . . . . . . . . . . . . . . . . . 3.3.1 P°ípady uºití uºivatele . . . . . . . . . . . . . . . . 3.3.1.1 P°ihlá²ení . . . . . . . . . . . . . . . . . . 3.3.1.2 Odhlá²ení . . . . . . . . . . . . . . . . . . 3.3.1.3 P°idání nového uºivatele . . . . . . . . . . 3.3.1.4 Prohlíºení a správa uºivatel· . . . . . . . 3.3.1.5 Zm¥na odd¥lení uºivatele . . . . . . . . . 3.3.1.6 Správa uºivatele . . . . . . . . . . . . . . 3.3.2 P°ípad uºití diá° . . . . . . . . . . . . . . . . . . . 3.3.2.1 Prohlíºení obsahu diá°e . . . . . . . . . . 3.3.2.2 Správa diá°e . . . . . . . . . . . . . . . . 3.3.2.3 Správa diá°e uºivatel· . . . . . . . . . . . 3.3.3 P°ípad uºití odd¥lení . . . . . . . . . . . . . . . . . 3.3.3.1 Prohlíºení odd¥lení . . . . . . . . . . . . . 3.3.3.2 Vytvo°ení odd¥lení . . . . . . . . . . . . . 3.3.3.3 Správa odd¥lení . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

11

11 11 12 13 13 13 13 14 14 14 15 16 16 16 17 17 18 18 18 18 27 27 27 28 28 28 30 30 30 34 34 34 34 34 35 35 35 38 38 38 39 40 40 41 41

xiii

OBSAH

3.3.4

3.3.5

3.3.6

3.3.7 3.3.8

4 Realizace 4.1 4.2

4.3

P°ípad uºití rma . . . . . . . . . . . . . . . . . . 3.3.4.1 Generování faktur . . . . . . . . . . . . . 3.3.4.2 Vytvo°ení rmy . . . . . . . . . . . . . . 3.3.4.3 P°i°azení projektu k rm¥ . . . . . . . . . 3.3.4.4 Odebrání projektu od rmy . . . . . . . . 3.3.4.5 Pokro£ilá správa rmy . . . . . . . . . . . 3.3.4.6 Správa rmy . . . . . . . . . . . . . . . . P°ípady uºití projektu . . . . . . . . . . . . . . . . 3.3.5.1 Vytvo° projekt . . . . . . . . . . . . . . . 3.3.5.2 Prohlíºení obsahu projektového diá°e . . 3.3.5.3 Správa projektového diá°e . . . . . . . . . 3.3.5.4 Správa fází projektu . . . . . . . . . . . . 3.3.5.5 Správa automatizace projektu . . . . . . P°ípad uºití faktury . . . . . . . . . . . . . . . . . 3.3.6.1 Nastavení faktura£ního vzoru pro fakturu 3.3.6.2 Vygenerování faktury . . . . . . . . . . . 3.3.6.3 P°edání k fakturaci . . . . . . . . . . . . 3.3.6.4 Potvrzení faktury . . . . . . . . . . . . . 3.3.6.5 P°edání faktury zp¥t . . . . . . . . . . . . 3.3.6.6 Prohledávání faktur . . . . . . . . . . . . 3.3.6.7 Správa faktur uºivatel· . . . . . . . . . . 3.3.6.8 Správa £asových záznam· . . . . . . . . . 3.3.6.9 Správa faktura£ních vzor· . . . . . . . . . P°ípad uºití vícejazy£nost . . . . . . . . . . . . . . 3.3.7.1 Prohledávání internacionalizace . . . . . . 3.3.7.2 Úprava internacionalizace . . . . . . . . . P°ípad uºití prom¥nné . . . . . . . . . . . . . . . . 3.3.8.1 Prohledávání prom¥nných . . . . . . . . . 3.3.8.2 Úprava prom¥nné . . . . . . . . . . . . . 3.3.8.3 P°idání prom¥nné . . . . . . . . . . . . . 3.3.8.4 Odstran¥ní prom¥nné . . . . . . . . . . .

Pouºité knihovny a software . . . . . . . . . . . . . Seam . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Bijekce . . . . . . . . . . . . . . . . . . . . . 4.2.2 Podpora vytvá°ení a ukon£ení komponent . 4.2.3 Scope komponent . . . . . . . . . . . . . . . 4.2.4 Správa transakcí a na£ítání z databáze . . . 4.2.5 Testování . . . . . . . . . . . . . . . . . . . 4.2.6 Seam Expression Language . . . . . . . . . 4.2.7 Ukázka propojení webové a aplika£ní vrstvy 4.2.8 Dal²í uºite£ná funk£nost . . . . . . . . . . . 4.2.9 Struktura Seam aplikace . . . . . . . . . . . JARClassLoader p°i na£ítání automatizéru . . . . . 4.3.1 Popis problém· a cíle . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

44 44 45 45 45 46 47 49 49 50 50 52 53 55 55 56 56 56 57 57 57 58 59 61 61 61 61 61 62 62 62

63

64 64 65 65 65 66 66 66 66 67 67 67 67

xiv

OBSAH

4.4 4.5 4.6 4.7 4.8 4.9

4.10 4.11 4.12 4.13 4.14 4.15

4.16

4.3.1.1 Class Loading . . . . . . 4.3.1.2 CustomJARClassLoader . 4.3.2 e²ení . . . . . . . . . . . . . . . . Automatizované na£ítání projektu . . . . 4.4.1 Popis problém· a cíle . . . . . . . 4.4.2 e²ení . . . . . . . . . . . . . . . . Standardizace vzhledu aplikace zaloºeného 4.5.1 Popis problém· a cíle . . . . . . . 4.5.2 e²ení . . . . . . . . . . . . . . . . Validace vstupních dat . . . . . . . . . . . 4.6.1 Popis problém· a cíle . . . . . . . 4.6.2 e²ení . . . . . . . . . . . . . . . . Na£ítání webového obsahu z databáze . . 4.7.1 Popis problém· a cíle . . . . . . . 4.7.2 e²ení . . . . . . . . . . . . . . . . Clustrování frameworku Seam . . . . . . . Clustrování aplika£ního serveru . . . . . . 4.9.1 Popis problém· a cíle . . . . . . . 4.9.2 e²ení . . . . . . . . . . . . . . . . 4.9.2.1 Spu²t¥ní Clusteru . . . . 4.9.2.2 LoadBalancing server· . . 4.9.2.3 Replikace HTTP Session 4.9.2.4 Replikace SFSB a SLSB . 4.9.2.5 Replikace Entity - Cache Clustrování databáze . . . . . . . . . . . . 4.10.1 Popis problém· a cíle . . . . . . . 4.10.2 e²ení . . . . . . . . . . . . . . . . Diá° zaloºený na kalendá°i RichFaces . . . 4.11.1 Popis problém· a cíle . . . . . . . 4.11.2 e²ení . . . . . . . . . . . . . . . . FileUpload problém . . . . . . . . . . . . . 4.12.1 Popis problém· a cíle . . . . . . . 4.12.2 e²ení . . . . . . . . . . . . . . . . Realizace zabezpe£ení pomocí HTTPS . . 4.13.1 Popis problém· a cíle . . . . . . . 4.13.2 e²ení . . . . . . . . . . . . . . . . QueryBuilder . . . . . . . . . . . . . . . . 4.14.1 Popis problém· a cíle . . . . . . . 4.14.2 e²ení . . . . . . . . . . . . . . . . Test Driven Development . . . . . . . . . 4.15.1 Popis problém· a cíle . . . . . . . 4.15.2 Co to vlastn¥ je . . . . . . . . . . . 4.15.3 Výsledky . . . . . . . . . . . . . . Pojmenovávání Seam komponent . . . . . 4.16.1 Popis problém· a cíle . . . . . . . 4.16.2 e²ení . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . na vzhledu RichFaces komponent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

68 68 69 70 70 70 71 71 71 72 72 72 72 72 73 75 75 75 75 75 76 76 77 77 78 78 78 79 79 80 81 81 81 81 81 81 82 82 82 82 82 82 83 83 83 83

xv

OBSAH

4.17 Vytvo°ení nového faktura£ního vzoru . . . . . . . . . . . . . . . . . . . . . . . 84 4.17.1 Popis problém· a cíle . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 4.17.2 e²ení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5 Testování 5.1

5.2

5.3 5.4

85

Integra£ní a Unit testy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.1.1 Nastavení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.1.2 Vloºení inicializa£ních dat . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.1.3 Co bylo testováno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.1.4 Výsledky test· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Usability testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.2.1 Papírový prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.2.2 Usability testing aplikace . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.2.3 Hypotézy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.2.4 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.2.5 Vyhodnocení hypotéz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.2.5.1 Informa£ní tooltipy výrazn¥ pomáhají k orientaci na stránce 88 5.2.5.2 Moºnost volby vzhledu vede k zp°ehledn¥ní stránky . . . . . 88 5.2.5.3 Kulaté ráme£ky ( nifty ) pomáhají k rozli²ení dat - tabulky versus výpisy . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.2.5.4 Validace pomocí podbarvení a informa£ního tooltipu nad vyk°i£níkem je dostaten¥ upozor¬ující na chybu p°i validaci . . . . . . . . 89 5.2.6 Dal²í informace z diskuze po POST-TESTu . . . . . . . . . . . . . . . 89 Black box testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Testování funk£nosti clusteru aplika£ního serveru . . . . . . . . . . . . . . . . 89

6 Záv¥r

91

Literatura

93

A Seznam pouºitých zkratek

97

B Instala£ní a uºivatelská p°íru£ka

99

6.1 6.2

B.1 B.2 B.3 B.4 B.5 B.6

Zhodnocení výsledk· práce vzhledem k zadání . . . . . . . . . . . . . . . . . . 91 Diskuse dal²ího moºného pokra£ování práce . . . . . . . . . . . . . . . . . . . 92

Prom¥nné pro Apache . . . . JBoss AS 5.1. MySQL . . . HTTPS . . . Dodatek . . .

faktura£ní . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C Obsah p°iloºeného CD

vzor . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

99 101 103 103 104 104

105

xvi

OBSAH

Seznam obrázk· 2.1

Diagram komponent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 3.22 3.23 3.24 3.25 3.26 3.27 3.28 3.29 3.30 3.31 3.32 3.33

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 1 . . . . . . . . . . . . Návrh vzhledu £íslo 2 . . . . . . . . . . . . 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

12 19 20 20 21 21 22 22 23 23 24 24 24 25 25 25 26 26 27 29 29 30 31 32 33 36 38 40 41 46 47 50 52

xviii

SEZNAM OBRÁZK

3.34 P°ípad uºití správa automatizace projektu . . . . . . . . . . . . . . . . . . . . 54 3.35 P°ípad uºití správa £asových záznam· . . . . . . . . . . . . . . . . . . . . . . 58 3.36 P°ípad uºití správa faktura£ních vzor· . . . . . . . . . . . . . . . . . . . . . . 59 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10

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]

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

67 68 69 70 71 73 74 78 80 83

5.1 5.2

Test Struktura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Papírový prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Seznam tabulek 2.1

Srovnání stávajících aplikací . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1

Srovnání aplika£ních framework· . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1 4.2

Pouºité knihovny a software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 RichFaces a FileUpload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.1 5.2 5.3

Vzory rozvrºení plochy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 PRE-TEST dotazník . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 POST-TEST dotazník . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

xix

5

xx

SEZNAM TABULEK

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°i2 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 Informa£ní systém je systém pro sb¥r, udrºování, zpracování a poskytování informací a dat http://cs.wikipedia.org/wiki/Informa%C4%8Dn%C3%AD_syst%C3%A9m 2 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

1

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.

Nadstavba síóvé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 443 - z http://cs.wikipedia.org/wiki/HTTPS 5 Open source je voln¥ ²í°itelný kód, který je moºné bez poplatk· pouºívat. 4

Kapitola 2

Úvodní studie 2.1

Re²er²e informa£ních systém·

2.1.1 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

4

KAPITOLA 2.

ÚVODNÍ STUDIE

2.1.2 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 31.12. 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á.

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

2.1.4 Bugzilla Bugzilla (viz [10]) je p°edev²ím bugtracking3 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.

2.1.5 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·. Systém pro správu projekt·, v¥t²inou se dá pouºít i pro správu bug· Systém pro správu chyb 4 Systém pro správu £asových moºností 5 Umoº¬uje spolupráci s 2 3

2.2.

5

PRO VLASTNÍ EENÍ

Kritérium

Rozd¥lení rolí Záznam £as· Vysoká dostupnost Generování faktur Modikovatelnost faktur Automatizace na£ítání projekt· Plánování £asových moºností Open Source

Achievo JIRA ano ano ne ne ne

ano ano ne ne ne

Bugzilla Dovico ano ano ne ne ne

ano ano ne ne ne

Ontime Trac ano ano ne ano ano

ano ano ne ne ne

ne

£áste£n¥

£áste£n¥

£áste£n¥

£áste£n¥

£áste£n¥

ne

ne

ne

ne

ano

ano

ano

ne

ano

ne

ne

ano

Tabulka 2.1: Srovnání stávajících aplikací

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

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

2.1.8 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

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

2.4.1 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í. Automatizované na£ítání projekt· slouºí k na£ítání pot°ebných projektových dat z pouºívaného project management systému 6

2.5.

ODHADOVANÝ AS TVORBY APLIKACE

7

2.4.2 Nefunk£ní poºadavky 2.4.2.1 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.

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

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

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

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

2.4.2.6 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

8

KAPITOLA 2.

ÚVODNÍ STUDIE

N arocnost = 2, 94 ∗ KLOC 0.91 Cas = 3, 97 ∗ N arocnost0.28 Po dosazení je £as roven 10,11 £lov¥kom¥síce . 2.6

Analýza rizik

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

2.6.2 Vysoká dostupnost B¥hem vývoje aplikace jsou pouºívány nejmodern¥j²í technologie a vyuºití clusteru8 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

2.6.3 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

2.6.4 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

2.6.5 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 8

Cluster je skupina po£íta£·,aplika£ních server·,databází,... , které spolu spolupracují Cluster slouºí mimo jiné k zaji²t¥ní vysoké dostupnosti

2.7.

KOMPONENTY SYSTÉMU

Riziko : Nízké e²itel problému :

9

Tv·rce aplikace

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

10

KAPITOLA 2.

Obrázek 2.1: Diagram komponent

ÚVODNÍ STUDIE

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

3.1.1 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. 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 http://cs.wikipedia.org/wiki/Framework 2 Perzistentní = uloºený v databázi 1

11

12

KAPITOLA 3.

ANALÝZA A NÁVRH EENÍ

Obrázek 3.1: T°ívrstvá architektura

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

3.1.

POADAVKY

13

• Integrace framework· ( persistence dat, pdf, email, ... ). • Dal²í uºite£né vlastnosti. Nyní postupn¥ proberu spole£né vlastnosti ,poté jednotlivé frameworky a standard JEE .

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

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

3.1.2.3 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é API5 , 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í.

3.1.2.4 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é Template6 , 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. Anotace - dodate£ná informace vkládaná do zdrojového textu ,nap°íklad @Override 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 4 5

14

KAPITOLA 3.


3.1.2.5 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 emaily, pdf, perzistenci (kapitola 3.1.3) dat, ... . Navíc jde s integrací tak daleko, ºe do sebe integruje i samotný Spring (kapitola 3.1.2.4). 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 LazyInitializationException8 , která je bezesporu nejv¥t²ím problém p°i práci s ORM9 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 language10 frameworku JSF . Umoº¬uje nám vytvá°et nap°íklad takovéto konstrukty :

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á anotace @In a @Out. 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.

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

3.1.3 Poºadavky na framework pro perzistenci dat Poºadavky na tento framework jsou tyto: 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 8

3.1.

15

POADAVKY

Volba

Podpora vysoké dostupnosti Podpora internacionalizace Podpora HTTPS a security Integrace framework· ( persistence dat, pdf, email, ... ) Dal²í uºite£né vlastnosti

JEE Spring ano ano ano ne ne

ano ano ano £áste£n¥ ano

Seam ano ano ano 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 3.1.2.5). 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ý.

3.1.4 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

16

KAPITOLA 3.


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

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

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

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

• 99.999 % dostupnost. • Automatické zotavení z chyb. 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· 13

3.2.

NÁVRH

17

• Výborná ²kálovatelnost15 . 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]).

3.1.6 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 tooltip16 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 16

Ideáln¥ ²kálovatelný systém zvy²uje výkon p°ibliºn¥ lineárn¥ s p°idáváním zdroj· Tooltip - informa£ní hlá²ka dynamicky se zobrazující nad zvolenou oblastí

18

KAPITOLA 3.


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

3.2.2 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 3.2.3 .

3.2.3 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 3.3.1 . 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, 3.11

3.2.4 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 6.7.1 (viz [43]) .

3.2.

19

NÁVRH

Obrázek 3.2: Diagram nasazení

20

KAPITOLA 3.


Obrázek 3.3: Role v systému

Obrázek 3.4: P°ípad uºití odd¥lení

3.2.

21

NÁVRH

Obrázek 3.5: P°ípad uºití diá°

Obrázek 3.6: P°ípad uºití faktura

22

KAPITOLA 3.


Obrázek 3.7: P°ípad uºití rma

Obrázek 3.8: P°ípad uºití vícejazy£nost

3.2.

23

NÁVRH

Obrázek 3.9: P°ípad uºití projekt

Obrázek 3.10: P°ípad uºití prom¥nná

24

KAPITOLA 3.


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

3.2.

25

NÁVRH

Obrázek 3.14: Domain model - odd¥lení

Obrázek 3.15: Domain model - faktura

Obrázek 3.16: Domain model - rma

26

KAPITOLA 3.


Obrázek 3.17: Domain model - projekt

Obrázek 3.18: Domain model - uºivatel

3.2.

27

NÁVRH

3.2.5 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á°

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

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

28

KAPITOLA 3.


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

3.2.6.2 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, ... .

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

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

3.2.

29

NÁVRH

Obrázek 3.20: Class diagram - Automatizace

Obrázek 3.21: Stavový diagram - fakturace

30

KAPITOLA 3.


3.2.9 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

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

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

3.2.

31

NÁVRH

Obrázek 3.23: Mapa stránek

32

KAPITOLA 3.


Obrázek 3.24: Návrh vzhledu £íslo 1

3.2.

33

NÁVRH

Obrázek 3.25: Návrh vzhledu £íslo 2

34

KAPITOLA 3.

3.3


P°ípady uºití podrobn¥ji

V této sekci si probereme podrobn¥ji jednotlivé p°ípady uºití.

3.3.1 P°ípady uºití uºivatele 3.3.1.1 P°ihlá²ení Primární aktér : Pozorovatel Hlavní úsp¥²ný scéná° 1. Uºivatel se pokusí p°ihlásit do aplikace. 2. Zadá své p°ihla²ovací údaje. 3. Pokusí se p°ihlásit.

Roz²í°ení

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

3.3.1.2 Odhlá²ení Primární aktér : Pozorovatel Hlavní úsp¥²ný scéná° 1. Uºivatel je p°ihlá²en. 2. Pokusí se odhlásit z aplikace.

Roz²í°ení Garance úsp¥chu :

Úsp¥²n¥ se odhla²uje a je vypsáno informa£ní hlá²ení.

3.3.1.3 P°idání nového uºivatele Primární aktér : Manager Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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

3.3.

PÍPADY UITÍ PODROBNJI

35

3.3.1.4 Prohlíºení a správa uºivatel· Primární aktér : Manager Hlavní úsp¥²ný scéná° 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 3.3.1.6).

Roz²í°ení

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.

3.3.1.5 Zm¥na odd¥lení uºivatele Primární aktér : Manager Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví sv·j prol. 2. Rozhodne se zm¥nit svoje odd¥lení. 3. Pokusí se zm¥nu provést.

Roz²í°ení

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

3.3.1.6 Správa uºivatele Editace uºivatele Primární aktér : Zam¥stnanec Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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

36

KAPITOLA 3.


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 Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví sv·j prol. 2. Napí²e poznámku. 3. Pokusí se ji odeslat.

Roz²í°ení

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 Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví zm¥nu rolí. 2. Vybere poºadovanou roli. 3. Pokusí se o zm¥nu rolí.

Roz²í°ení

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

3.3.


P°idání zku²eností uºivatele Primární aktér : Zam¥stnanec Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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 Hlavní úsp¥²ný scéná° 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í.

Roz²í°ení

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 Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví správu zku²eností. 2. Najde zku²enost, kterou chce odstranit. 3. Pokusí se o odstran¥ní.


Odstran¥ní záznamu a výpis informa£ního hlá²ení.

37

38

KAPITOLA 3.


3.3.2 P°ípad uºití diá° 3.3.2.1 Prohlíºení obsahu diá°e Primární aktér : Zam¥stnanec Hlavní úsp¥²ný scéná° 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).


Získání záznam· k volenému období s rozli²ením podle d·leºitosti.

3.3.2.2 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 Hlavní úsp¥²ný scéná° 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.

3.3.


Roz²í°ení

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 Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví sv·j diá°. 2. Zvolí den záznamu. 3. Pokusí se odstranit záznam z diá°e.

Roz²í°ení

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 Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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

3.3.2.3 Správa diá°e uºivatel· Primární aktér : Manager Hlavní úsp¥²ný scéná° 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 3.3.2.2).

Roz²í°ení

1b) Uºivatel nemá dostate£ná oprávn¥ní k prohlíºení diá°e. Garance úsp¥chu : Provedení správy diá°e uºivatel·.

39

40

KAPITOLA 3.


Obrázek 3.28: P°ípad uºití prohlíºení odd¥lení

3.3.3 P°ípad uºití odd¥lení 3.3.3.1 Prohlíºení odd¥lení Prohlíºení zam¥stnanc· odd¥lení Primární aktér : Zam¥stnanec Hlavní úsp¥²ný scéná° 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.


Uºivatel najde zkoumaná data o zam¥stnancích odd¥lení.

Prohlíºení pododd¥lení odd¥lení Primární aktér : Zam¥stnanec Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví vybrané odd¥lení. 2. Zvolí prohlíºení struktury odd¥lení. 3. Prohlíºí odd¥lení a jejich pododd¥lení.


Uºivatel najde data o struktu°e odd¥lení.

3.3.


3.3.3.2 Vytvo°ení odd¥lení Primární aktér : Manaºer Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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

3.3.3.3 Správa odd¥lení

Obrázek 3.29: P°ípad uºití správa odd¥lení

41

42

KAPITOLA 3.


P°idání zam¥stnance k odd¥lení Primární aktér : Manaºer Hlavní úsp¥²ný scéná° 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í.


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 Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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 Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

4b) Zm¥na neprojde validací, pokra£uje bodem 4. Garance úsp¥chu : Funkce upravena, je vypsáno informa£ní hlá²ení.

3.3.


Ozna£ení uºivatele jako vedoucího odd¥lení Primární aktér : Manaºer Hlavní úsp¥²ný scéná° 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.


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 Hlavní úsp¥²ný scéná° 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í.


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 Hlavní úsp¥²ný scéná° 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í.


Pododd¥lení odebráno, je vypsáno informa£ní hlá²ení.

43

44

KAPITOLA 3.


Úprava odd¥lení Primární aktér : Manaºer Hlavní úsp¥²ný scéná° 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í.

Roz²í°ení

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 Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví vybrané odd¥lení. 2. Pokusí se odstranit dané odd¥lení.

Roz²í°ení

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 Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví vybrané odd¥lení. 2. Pokusí se odstranit vedoucího odd¥lení.


Je odstran¥n vedoucí odd¥lení, je vypsáno informa£ní hlá²ení.

3.3.4 P°ípad uºití rma 3.3.4.1 Generování faktur Primární aktér : Manaºer Hlavní úsp¥²ný scéná° 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.


Uºivateli je vygenerována pdf faktura.

3.3.


3.3.4.2 Vytvo°ení rmy Primární aktér : Manaºer Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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

3.3.4.3 P°i°azení projektu k rm¥ Primární aktér : Manaºer Hlavní úsp¥²ný scéná° 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.


Projekt je p°i°azen, je vypsáno informa£ní hlá²ení.

3.3.4.4 Odebrání projektu od rmy Primární aktér : Manaºer Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví konkrétní rmu. 2. Zvolí projekt, který chce odebrat. 3. Pokusí se odebrat projekt.

Roz²í°ení

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

45

46

KAPITOLA 3.


Obrázek 3.30: P°ípad uºití pokro£ilá správa rmy

3.3.4.5 Pokro£ilá správa rmy Úprava rmy Primární aktér : Manager Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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 Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví vybrané odd¥lení. 2. Najde konkrétní kontakt. 3. Rozhodne se ho odstranit. 4. Pokusí se ho odstranit.


Kontakt byl odstran¥n, je vypsáno informa£ní hlá²ení.

3.3.


Obrázek 3.31: P°ípad uºití správa rmy

3.3.4.6 Správa rmy P°idání záznamu k rm¥ Primární aktér : Zam¥stnanec Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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 Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví konkrétní rmu. 2. Rozhodne se p°idat kontakt k rm¥.

47

48

KAPITOLA 3.


3. Vyplní data kontaktu. 4. Pokusí se vloºit kontakt.

Roz²í°ení

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 Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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 Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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

3.3.


Prohlíºení informací o rm¥ Primární aktér : Zam¥stnanec Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví konkrétní rmu. 2. Prohlíºí dostupná data. 3. Listuje v tabulkách.


Uºivatel najde zkoumaná data o rm¥.

Prohlíºení kontaktu Primární aktér : Zam¥stnanec Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví konkrétní rmu. 2. Uºivatel zvolí kontakt. 3. Prohlíºí dostupná data. 4. Listuje v tabulkách.


Uºivatel najde zkoumaná data o kontaktech ve rm¥.

3.3.5 P°ípady uºití projektu 3.3.5.1 Vytvo° projekt Primární aktér : Manaºer Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví stránku pro vytvo°ení projektu. 2. Zadává poºadovaná data. 3. Pokusí se p°idat projekt.

Roz²í°ení

3b) Data neprojdou validací, pokra£uje bodem 2. Garance úsp¥chu : Vytvo°ení projektu, je vypsáno informa£ní hlá²ení.

49

50

KAPITOLA 3.


3.3.5.2 Prohlíºení obsahu projektového diá°e Primární aktér : Zam¥stnanec Hlavní úsp¥²ný scéná° 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).


podle d·leºitosti.

Získání komentá°e,milestone, todo k volenému období s rozli²ením

3.3.5.3 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 Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví poºadovaný projekt.

3.3.


51

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

Roz²í°ení

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 Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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 Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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

52

KAPITOLA 3.


Obrázek 3.33: P°ípad uºití správa fází projektu

3.3.5.4 Správa fází projektu P°idání fáze projektu Primární aktér : Manager Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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 Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví poºadovaný projekt. 2. Nav²tíví fáze projektu. 3. Rozhodne se pro zm¥nu dat.

3.3.


53

4. Zm¥nu provede. 5. Pokusí se uloºit zm¥nu.

Roz²í°ení

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 Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

4b) Zm¥na neprojde validací, pokra£uje bodem 3. Garance úsp¥chu : Úprava provedena, je vypsáno informa£ní hlá²ení.

3.3.5.5 Správa automatizace projektu Volba automatizéru projekt Primární aktér : Administrátor Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví automatizaci projekt·. 2. Zvolí konkrétní projekt. 3. Zvolí automatizér. 4. Pokusí se provést zm¥nu.


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 Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví automatizaci projekt·. 2. Zvolí konkrétní projekt. 3. Provede odstran¥ní automatizéru.


Automatizér je odstran¥n, je vypsáno informa£ní hlá²ení.

54

KAPITOLA 3.


Obrázek 3.34: P°ípad uºití správa automatizace projektu

Spu²t¥ní automatizéru projektu Primární aktér : Administrátor Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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 Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví automatizaci projekt·. 2. Najde automatizér. 3. Pokusí se ho odstranit.

3.3.


55

Roz²í°ení

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 Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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

3.3.6 P°ípad uºití faktury 3.3.6.1 Nastavení faktura£ního vzoru pro fakturu Primární aktér : Zam¥stnanec Hlavní úsp¥²ný scéná° 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.


Zm¥na provedena, je vypsáno informa£ní hlá²ení.

56

KAPITOLA 3.


3.3.6.2 Vygenerování faktury Primární aktér : Zam¥stnanec Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví fakturaci. 2. Zvolí fakturu. 3. Rozhodne se vygenerovat pdf fakturu. 4. Vygeneruje fakturu.


Vygenerování faktury.

3.3.6.3 P°edání k fakturaci Primární aktér : Zam¥stnanec Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví fakturaci. 2. Zvolí fakturu. 3. Rozhodne se poslat ji k fakturaci. 4. Pokusí se provést akci.


Fakturace odeslána ke zpracování, je vypsáno informa£ní hlá²ení.

3.3.6.4 Potvrzení faktury Primární aktér : Manager Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví faktury v²ech. 2. Zvolí fakturu. 3. Rozhodne se ji potvrdit. 4. Pokusí se provést zm¥nu.


Fakturace potvrzena, je vypsáno informa£ní hlá²ení.

3.3.


57

3.3.6.5 P°edání faktury zp¥t Primární aktér : Manager Hlavní úsp¥²ný scéná° 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.


Fakturace vrácena k p°epracování, je vypsáno informa£ní hlá²ení.

3.3.6.6 Prohledávání faktur Primární aktér : Zam¥stnanec Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví fakturaci. 2. Zadá parametry, podle kterých chce hledat fakturu. 3. Provede vyhledávání.


Nalezení poºadovaných faktur.

3.3.6.7 Správa faktur uºivatel· Primární aktér : Manaºer Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví faktury v²ech. 2. Provádí operace podle p°ípad· uºití Prohledávání faktur (kapitola 3.3.6.6), Odstran¥ní £asového záznamu (kapitola 3.3.6.8), Zm¥na £asového záznamu (kapitola 3.3.6.8).


Provedení operací

58

KAPITOLA 3.


Obrázek 3.35: P°ípad uºití správa £asových záznam·

3.3.6.8 Správa £asových záznam· P°idání £asového záznamu Primární aktér : Zam¥stnanec Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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 Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví fakturaci. 2. Rozhodne se odstranit £asový záznam. 3. Zvolí £asový záznam. 4. Pokusí se ho odebrat.

3.3.


Roz²í°ení

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 Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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

3.3.6.9 Správa faktura£ních vzor·

Obrázek 3.36: P°ípad uºití správa faktura£ních vzor·

59

60

KAPITOLA 3.


P°idání faktura£ního vzoru Primární aktér : Administrátor Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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 Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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 Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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

3.3.


3.3.7 P°ípad uºití vícejazy£nost 3.3.7.1 Prohledávání internacionalizace Primární aktér : Manager Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví internacionalizaci. 2. Zadá klí£. 3. Zvolí vyhledávání.


Nalezeny odpovídající záznamy.

3.3.7.2 Úprava internacionalizace Primární aktér : Manager Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví internacionalizaci. 2. Zvolí konkrétní slovo. 3. Provede zm¥nu. 4. Pokusí se uloºit zm¥nu.



3.3.8 P°ípad uºití prom¥nné 3.3.8.1 Prohledávání prom¥nných Primární aktér : Manager Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví prom¥nné. 2. Zadá klí£. 3. Zvolí vyhledávání.


Nalezeny odpovídající záznamy.

61

62

KAPITOLA 3.


3.3.8.2 Úprava prom¥nné Primární aktér : Manager Hlavní úsp¥²ný scéná° 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.



3.3.8.3 P°idání prom¥nné Primární aktér : Manager Hlavní úsp¥²ný scéná° 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.

Roz²í°ení

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

3.3.8.4 Odstran¥ní prom¥nné Primární aktér : Manager Hlavní úsp¥²ný scéná° 1. Uºivatel nav²tíví prom¥nné. 2. Zvolí konkrétní prom¥nnou. 3. Pokusí se odstranit prom¥nnou.


Odstran¥ní provedeno, je vypsáno informa£ní hlá²ení.

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

64

KAPITOLA 4.

Knihovna Seam Hibernate EJB JSF RichFaces Facelets Hibernate Validator Drools Testng MySQL Driver Software JBoss Embeded JBoss Application Server MySQL

REALIZACE

Verze 2.2.0.GA 3.4.0.GA 3.0 1.2_12 3.3.1.GA 1.1.15.B1 3.1.0.GA 5.0.1 5.9 5.1.11 Verze beta3.SP12 5.1 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 Session2 , 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í. 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í. 1

4.2.

SEAM

65

4.2.1 Bijekce @Name("component") public class MyComponent{ @In EntityManager entityManager; @Out 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.

4.2.2 Podpora vytvá°ení a ukon£ení komponent @Name("component") public class MyComponent{ @Create public void init(){} @Destroy 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¥.

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

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.

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

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

4.2.6 Seam Expression Language Seam umoº¬uje volání funkcí s parametry. To není pomocí JSF moºné.

4.2.7 Ukázka propojení webové a aplika£ní vrstvy @Stateless @Name("manager") public class ManagerAction implements Manager { public String sayHello(){ return "Hello"; } }

4.3.

JARCLASSLOADER PI NAÍTÁNÍ AUTOMATIZÉRU

67

4.2.8 Dal²í uºite£ná funk£nost • Správa práv pomocí drools. • Validace dat pomocí Hibernate Validators. • Podpora Bussines Process - jBPM. • Podpora tvorby PDF, email·. • Podpora Quartz Scheduleru. • Vlastní tagy ,nap°íklad pro validaci.

4.2.9 Struktura Seam aplikace

Obrázek 4.1: Struktura Seam aplikace , p°ebrané z [3]

4.3

JARClassLoader p°i na£ítání automatizéru

4.3.1 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í ClassLoader· (viz [32] [13]).

68

KAPITOLA 4.

REALIZACE

4.3.1.1 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!

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

4.3.

JARCLASSLOADER PI 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

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

70 4.4

KAPITOLA 4.

REALIZACE

Automatizované na£ítání projektu

4.4.1 Popis problém· a cíle Tato £ást navazuje na kapitoly 4.3 a 3.2.6 . 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

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

4.5. STANDARDIZACE VZHLEDU APLIKACE ZALOENÉHO NA VZHLEDU RICHFACES KOMPO

Obrázek 4.5: Project Facade

4.5

Standardizace vzhledu aplikace zaloºeného na vzhledu RichFaces komponent

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

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

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

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

4.6.2 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

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

4.7.

NAÍTÁNÍ WEBOVÉHO OBSAHU Z DATABÁZE

73

Obrázek 4.6: Na£ítání faktury z databáze

4.7.2 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 <param-name>facelets.RESOURCE_RESOLVER <param-value>mypackage.TemplateResolver vytvo°it t°ídu mypackage.TemplateResolver public class TemplateResolver extends DefaultResourceResolver implements ResourceResolver{...}

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

4.8.

4.8

CLUSTROVÁNÍ FRAMEWORKU SEAM

75

Clustrování frameworku Seam

Pro nastavení Seamu do clustrovaného reºimu je t°eba n¥kolik nastavení.

v components.xml 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

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

4.9.2 e²ení e²ení bylo realizováno na základ¥ dokumentace k JBoss AS 5.1 (viz [30]) .

4.9.2.1 Spu²t¥ní Clusteru ./run.sh -c all -g DocsPartition -u 239.255.100.100 \ -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1 ./run.sh -c all -g DocsPartition -u 239.255.100.100 \ -b 192.168.0.102 -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í JMS5 musí být nastaveno ServerPeerID specické pro kaºdý server v clusteru. Replikované - p°ená²ené z jednoho serveru na druhý 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¥ 3 4

76

KAPITOLA 4.

REALIZACE

4.9.2.2 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 Robin6 , 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">

4.9.2.3 Replikace HTTP Session Abychom umoºnili replikaci HTTP Session ,je nutné upravit web.xml takto :

<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. Round Robin v Apache funguje tak, ºe pravideln¥ st°ídá pouºívaný aplika£ní server pro nov¥ p°íchozí uºivatele. 6

4.9.

CLUSTROVÁNÍ APLIKANÍHO SERVERU

77

4.9.2.4 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 true Krom¥ tohoto je zde moºné nastavit i zp·sob loadbalancování, cacheování.

4.9.2.5 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"/> <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 :

@Cache(usage=CacheConCurrencyStrategy.TRANSACTIONAL) 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.

78

KAPITOLA 4.

4.10

REALIZACE

Clustrování databáze

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

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

4.11.

DIÁ ZALOENÝ 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` ( ìd` bigint(20) NOT NULL AUTO_INCREMENT, `myNumber` bigint(20) NOT NULL, PRIMARY KEY (ìd`) ) 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] .

4.11

Diá° zaloºený na kalendá°i RichFaces

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

80

KAPITOLA 4.

REALIZACE

Obrázek 4.9: Sekven£ní diagram - Diá°

4.11.2 e²ení Pro °e²ení tohoto problému je t°eba komplexn¥ pochopit fungování celého kalendá°e RichFaces. Nakonec je v²ak °e²ení pom¥rn¥ jednoduché. Sta£í provést následující kroky :

toto je v *.xhtml -------------------------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

4.12.

81

FILEUPLOAD PROBLÉM

Zkou²ená verze RichFaces 3.2.0.GA 3.3.0.GA 3.3.1.GA 3.3.2.GA 3.3.3.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. 4.12

FileUpload problém

4.12.1 Popis problém· a cíle V aplikaci je nutné nahrávat soubory automatizéru. Jak jsem zjistil, s frameworkem RichFaces to není jednoduchý úkol. Problémem bylo, ºe p°es správné nastavení nahrávání souboru neza£alo.

4.12.2 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 3.3.1.GA nahrávání soubor· funguje. Toto je d·vod, pro£ nebyla pouºita verze 3.3.2.GA . 4.13

Realizace zabezpe£ení pomocí HTTPS

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

4.13.2 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"/>

82

KAPITOLA 4.

REALIZACE

Tímto nastavení °íkám, ºe pro HTTPS se má pouºívat port 8443. 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.5 4.14

QueryBuilder

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

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

Test Driven Development

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

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

4.16.

POJMENOVÁVÁNÍ SEAM KOMPONENT

83

Obrázek 4.10: Test Driven Development, p°ebrané z [51]

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

Pojmenovávání Seam komponent

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

4.16.2 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

84

KAPITOLA 4.

REALIZACE

T°ídy @Name("myComponent") public class CustomComponent{ } @Name("userComponent") public class UserComponent{ @In(create=true) CustomComponent myComponent; @In 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 pouºít @In(value = "nazev_komponenty") . 4.17

Vytvo°ení nového faktura£ního vzoru

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

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

zde jiº fakturu vytvá°ím podle html tag· 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.

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

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

86

KAPITOLA 5.

TESTOVÁNÍ

Obrázek 5.1: Test Struktura

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

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

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

5.2.

87

USABILITY TESTING

Vzor 1.vzor 2.vzor 3.vzor

Hlas· 3,5 1,5 0

Tabulka 5.1: Vzory rozvrºení plochy

5.2.1 Papírový prototyp 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 1.

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

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

88

KAPITOLA 5.

Participant

Pouºívá internet

Zku²ený ºivatel PC

Zku²enosti RIA1

1.participant 2.participant 3.participant 4.participant 5.participant

1 1 1 1 1

1 3 4 1 1

5 5 4 1 1

s

TESTOVÁNÍ

Zná systémy pro správu £asu nebo projekt· 1 5 5 1 5

Zvyklý na obrázkové action buttony 3 1 4 1 3

Tabulka 5.2: PRE-TEST dotazník Dotaz Pomáhaly informa£ní tooltipy k orientaci? Je moºnost volby vzhledu p°ínosem? Pomáhaly ti kulaté ráme£ky k odli²ení b¥ºných dat od tabulkových? Bylo zvýrazn¥ní validace dostate£né?

1.participant 1

2.participant 1

3.participant 1

4.participant 2

5.participant 2

3

1

1

2

1

4

4

5

5

4

3

1

3

1

1

Tabulka 5.3: POST-TEST dotazník

5.2.4 Data Podmínkou pro ú£ast v testu byla zku²enost s pouºíváním internetu. B¥hem testu museli ú£astníci vykonat scéná°, p°i£emº smyslem toho scéná°e bylo p°edev²ím seznámení se se zkoumanými jevy, aby na n¥ mohli být v POST-TESTu dotázáni.

5.2.5 Vyhodnocení hypotéz 5.2.5.1 Informa£ní tooltipy výrazn¥ pomáhají k orientaci na stránce V návaznosti na výsledky POST-TESTu mohu °íci, ºe m¥ výsledky pom¥rn¥ zna£n¥ p°ekvapily tím, ºe byly tak jednozna£né. Jediné p°ipomínky byly pouze k z°etelnosti obsahu, který bude na základ¥ t¥chto údaj· zvýrazn¥n. Výsledkem je tedy jednozna£n¥ - Hypotéza potvrzena .

5.2.5.2 Moºnost volby vzhledu vede k zp°ehledn¥ní stránky Podstatou moºnosti volby barevného vzhledu je to, ºe kaºdý má rád jiné barvy a jiné kontrasty, aby se mohl na stránce kvalitn¥ orientovat. Pr·m¥rný výsledek byl 1.6, coº je

5.3.

BLACK BOX TESTING

89

pom¥rn¥ nízké £íslo. Dv¥ vy²²í hodnoty byly z toho d·vodu, ºe participant·m obecn¥ zm¥ny barevných kombinací orientaci v stránkách nezvy²ují. I p°es toto je výsledkem ur£it¥ - Hypotéza potvrzena .

5.2.5.3 Kulaté ráme£ky ( nifty ) pomáhají k rozli²ení dat - tabulky versus výpisy Zde do²lo k p°ekvapivému výsledku. Uºivatelé si kulatých ráme£k· na stránce prakticky ani nev²imli. Nezaregistrovali je a podle výstupního rozhovoru jsou pro n¥ obtíºn¥ rozeznatelné, zakulacení je pod jejich rozli²ovací schopnosti. Na základ¥ t¥chto výsledk· je výsledkem jednozna£n¥ - Hypotéza vyvrácena . Myslím si, ºe zde byl myln¥ nastaven p°edpoklad, ºe budou uºivatelé pouºívat kulaté ráme£ky k rozli²ení mezi daty a výpisy. Je moºné, ºe by si toho podv¥dom¥ za£ali v²ímat po ur£ité del²í dob¥, kdy by aplikaci pouºívali. Toto bude d·vod, pro£ budou v aplikaci ponechány. Dal²ím d·vodem je estetické hledisko.

5.2.5.4 Validace pomocí podbarvení a informa£ního tooltipu nad vyk°i£níkem je dostaten¥ upozor¬ující na chybu p°i validaci Zde bylo testováno, jestli je pro uºivatele dostate£né zobrazení chyby p°i vkládání dat podbarvením chybné poloºky a vykreslením vyk°i£níku, který má nad sebou zobrazovatelný tooltip s popiskem chyby. Pr·m¥rný výsledek byl 1.8 , coº zna£í, ºe uºivatelé byli s informací o chyb¥ spokojeni. Dv¥ vy²²í hodnoty byly zp·sobeny tím, ºe uºivatelé byli zvyklí na klasický textový výpis vedle textového pole. P°es toto v²echno si myslím, ºe je - Hypotéza potvrzena .

5.2.6 Dal²í informace z diskuze po POST-TESTu Participanti si st¥ºovali na zarovnání textu doprava. Tento fakt zmínili 4 z 5 participant·. Sniºuje to prý £itelnost a navíc jsou zvyklí hledat za£átek textu se za£átkem °ádky. Tato p°ipomínka bude brána v potaz a toto zobrazení bude zm¥n¥no. 5.3

Black box testing

Aplikace byla samoz°ejm¥ testována i samotným pouºíváním, kdy nevidíme, co se d¥je v rámci aplikace. Je pro nás Black Boxem. Takto byla celá aplikace n¥kolikrát prozkou²ena a byly provád¥ny r·zné varianty vkládání a práce s daty. B¥hem tohoto druhu testování nebyly objeveny ºádné problémy. 5.4

Testování funk£nosti clusteru aplika£ního serveru

Po nasazení aplikace na cluster aplika£ního serveru byla aplikace testována, zda p°i pádu aplika£ního serveru, na kterém aplikace b¥ºí, nedojde k nedostupnosti na stran¥ uºivatele. Testování se skládalo z t¥chto krok· : 1. Na£tení stránky s clusterovaným obsahem.

90

KAPITOLA 5.

TESTOVÁNÍ

2. Rozpracování události ( vynucení clusterování ). 3. Zastavení serveru, ze kterého byl obsah na£ítán. 4. Návrat do prohlíºe£e. 5. Dokon£ení rozpracované události. 6. Po£kání na dokon£ení akce. Dle dokumentace m¥lo sta£it k replikaci Session Bean dodání anotace Clustered. Toto bohuºel nefungovalo a replikace za£ala fungovat aº poté, co byla dodána tato denice v jboss.xml .

<jboss> <enterprise-beans> <session> <ejb-name>myPackage.StatelessSession true B¥hem tohoto testování byl objeven problém s Facelets. Ty, pokud jsou nastaveny tak, aby se znovu na£ítaly, vedou k tomu, ºe aplikace p°estane reagovat, aniº by do²lo k chyb¥. Proto byla nutnost tohoto nastavení.

ve web.xml <param-name>facelets.REFRESH_PERIOD <param-value>-1 Tímto zakáºeme znovuna£ítání Facelets. Kone£ným výsledkem t¥chto test· byla po opravení chyb bezproblémová funk£nost aplikace i p°i pádu jednoho ze server·.

Kapitola 6

Záv¥r 6.1

Zhodnocení výsledk· práce vzhledem k zadání

Aplikaci vysoce dostupného informa£ního systému pro £asové výkaznictví se mi poda°ilo úsp¥²n¥ implementovat ve v²ech bodech zadání. Vytvo°ený systém pln¥ nahrazuje stávající systém Achievo. P°ínosem této práce je realizace aplikace pro správu £asového výkaznictví. Ta by m¥la zvý²it efektivitu jednotlivých £inností ve rm¥ BPSolutions s.r.o. . Krom¥ toho si myslím, ºe práce je velkým informa£ním zdrojem pro kaºdého, kdo chce vytvo°it clusterovanou aplikaci na MySQL nebo JBoss AS 5.1. . Stejn¥ tak co se tý£e clusterování Seamových aplikací. V této oblasti je dostupné velmi malé mnoºství kvalitních materiál·, o £emº sv¥d£í i to, ºe £ást dokumentace (viz [48]) , zabývající se vývojem cluterovaných aplikací v Seamu, je stále ve vývoji. Na základ¥ analýzy bylo vytvo°eno mnoºství p°ípad· uºití, které byly následn¥ realizovány. Bylo umoºn¥no vkládat £asové záznamy s £len¥ním p°es projekty a jejich fáze . V systému byly vytvo°eny £ty°i základní role - administrátor, manaºer, zam¥stnanec a pozorovatel. Aplikaci jsem vyvíjel v programovacím jazyku Java na aplika£ním serveru JBoss AS 5.1. . Její vysoká dostupnost je zaji²t¥na pomocí clustrování databáze a aplika£ního serveru. B¥hem tvorby projektu jsem rovn¥º vytvo°il komplexní UML dokumentaci k projektu. Bylo provedeno pot°ebné testování aplikace. Aplikace byla vytvá°ena s d·razem na vyuºití existujících framework·, p°i£emº u t¥ch klí£ových byl vºdy provád¥n výb¥r toho nejvhodn¥j²ího. Celá aplikace je £len¥na do vrstev - prezenta£ní, aplika£ní a datová. Aplika£ní vrstva je dále £len¥na na jednotlivé komponenty, které jsou navzájem maximáln¥ nezávislé. Toto v²echno bylo realizováno za ú£elem zjednodu²ení budoucích úprav aplikace. B¥hem vývoje aplikace se vyskytovaly r·zné problémy, z nichº ty nejzávaºn¥j²í v n¥kolika odstavcích shrnu. Realizoval jsem na£ítání stránek z databáze. To bylo pot°ebné pro moºnost generování r·zných faktura£ních vzor·. Tato funk£nost vyºadovala komplexní analýzu a pochopení frameworku Facelets, vytvo°ení nadstandardní funk£nosti, jeº na internetu nebyla dosud popsána. Dále vytvo°ení specializovaného servletu. Pro realizaci automatizovaného na£ítání projekt· jsem musel vytvo°it speciální class loader, který by umoº¬oval dynamické na£ítání denic t°íd a i jejich p°ípadné zm¥ny za 91

92

KAPITOLA 6.

ZÁVR

b¥hu. Tento p°ístup by mohl být pouºit v budoucnu k rychlej²ímu vývoji web aplikací díky odstran¥ní nutnosti znovunahrání aplikace na server. Aplikace byla vytvo°ena tak, ºe je moºné m¥nit vzhledy jednotlivých stránek. Základem byly vzhledy knihovny RichFaces, p°i£emº v aplikaci byl realizován zp·sob, jak obarvit komponenty, které do RichFaces nepat°í. V aplikaci byl realizován zp·sob validace dat, který je pln¥ automatický a do budoucna by mohl být s úsp¥chem pouºit v mnohých projektech. Výsledkem by byla zna£ná úspora £asu. B¥hem realizace jsem °e²il problémy, které p°iná²elo pouºití knihovny RichFaces - p°edev²ím nekompatibility verzí, které jsou zobrazeny v tabulce 4.2. Dále také roz²í°ení funk£nosti kalendá°e, který je po mnou vytvo°ených úpravách moºné pouºívat jako pln¥ funk£ní diá°. U aplikace bylo jedním z poºadavk·, aby byla vysoce dostupná. To jsem zajistil clustrováním databáze MySQL a aplika£ního serveru JBoss AS 5.1. . Oba tyto clustery byly také load balancovány. Aplikace byla vytvo°ena tak, ºe uºivatel p°i pádu jakéhokoliv serveru nic nepozná, ani kdyby na n¥m zrovna pracoval. Tato práce m·ºe slouºit i k osvojení funk£nosti integra£ního frameworku Seam. 6.2

Diskuse dal²ího moºného pokra£ování práce

Aplikace v sou£asném stavu je pln¥ funk£ní. Myslím si v²ak, ºe i do budoucna je moºné aplikaci rozvíjet. Jednou z moºností je vytvo°ení faktur nejen jako pdf, ale i jako xls nebo klasické html. Dal²ím bodem rozvoje je moºnost napsání automatizér· pro r·zné project management systémy. Dal²í moºností by mohla být v¥t²í podpora pro zam¥stnance. Moºností rozvoje do budoucna by bylo také vytvo°ení graf· vypovídajících o aktivit¥ práce na jednotlivých projektech,... .Myslím si, ºe b¥hem plného provozu budou vznikat nové poºadavky na funk£nosti, které mohou být bez problém· pr·b¥ºn¥ dopl¬ovány. Stejn¥ tak se mohou objevit i n¥které chyby, které se b¥hem vývoje a testování neprojevily.

Literatura [1] B. Aranda and Z. Wadia.

Facelets Essentials. APress, 1st edition, 2008. In English.

[2] H. Kanisová and M. Müller. Czech.

UML srozumiteln¥. Computer Press, 2st edition, 2006. In

[3] L. Kubásek. P°edstavení aplika£ního frameworku JBoss Seam. http://www.kubasek.cz/blog/2008/02/17/predstaveni-aplikacniho-framewor%kujboss-seam/|, stav k 7. 5. 2010. [4] M. K. Richfaces.

Practical Richfaces. APress, 1st edition, 2008. In English.

[5] B. Schwartz, P. Zaitsev, V. Tkachenko, J. D. Zavodny, A. Lentz, and D. J. Balling. MySQL profesionáln¥. Zoner Press, 2st edition, 2009. In Czech. [6] Achievo. http://www.achievo.org/, stav k 7. 5. 2010. [7] Apache Server. http://httpd.apache.org/, stav k 7. 5. 2010. [8] Apache server installer. http://ubuntuforums.org/showthread.php?t=971517, stav k 7. 5. 2010. [9] BPSolutions s.r.o. http://www.bpsolutions.cz/, stav k 7. 5. 2010. [10] Bugzilla. http://www.bugzilla.org/, stav k 7. 5. 2010. [11] Builder - diskuzní fórum. http://forum.builder.cz/list.php?14, stav k 7. 5. 2010. [12] Cocomo. michal.myserver.cz/cvut-fel/SIN/YD36SIN-Tema-1-Podklady.pdf, 7. 5. 2010. [13] Custom class loader. http://www.javalobby.org/java/forums/t18345.html, stav k 7. 5. 2010. 93

stav

k

94

LITERATURA

[14] Custom resource resolver. http://seamframework.org/Documentation/HowDoILoadAFaceletsViewTemplate%FromASharedJAR|, stav k 7. 5. 2010. [15] Stránky CZJUG. http://www.java.cz, stav k 7. 5. 2010. [16] Datový sklad. http://service.felk.cvut.cz/courses/X36DB2/slides/dw_cesky.pdf, 7. 5. 2010.

stav

k

stav

k

[17] DbUnit. http://www.dbunit.org/, stav k 7. 5. 2010. [18] Dovico. http://www.dovico.com/, stav k 7. 5. 2010. [19] Drools dokumentace. http://www.jboss.org/drools, stav k 7. 5. 2010. [20] Ejb dokumentace. http://java.sun.com/products/ejb/, stav k 7. 5. 2010. [21] Entity dokumentace. http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts4.html, 7. 5. 2010. [22] Google Web Toolikt dokumentace. http://code.google.com/webtoolkit/, stav k 7. 5. 2010. [23] Hibernate dokumentace. http://www.hibernate.org, stav k 7. 5. 2010. [24] Hibernate Shards. http://www.hibernate.org/subprojects/shards.html, stav k 7. 5. 2010. [25] Hibernate Validator dokumentace. http://www.hibernate.org/subprojects/validator.html, stav k 7. 5. 2010. [26] HTTPS certicate. http://i-proving.ca/space/Technologies/JBoss/Configuring+JBoss+SSL, stav k 7. 5. 2010. [27] IceFaces dokumentace. http://www.icefaces.org/, stav k 7. 5. 2010. [28] JEE dokumentace. http://java.sun.com/javaee/, stav k 7. 5. 2010. [29] Java. http://java.sun.com/, stav k 7. 5. 2010.

LITERATURA

95

[30] JBoss cluster guide. http://www.jboss.org/file-access/default/members/jbossclustering/freez%one/docs/cluste [31] JIRA. http://www.atlassian.com/software/jira/, stav k 7. 5. 2010. [32] Java language specication. http://java.sun.com/docs/books/jls/second_edition/html/execution.doc.h%tml stav k 7. 5. 2010. [33] Java Persistence API dokumentace. http://java.sun.com/javaee/technologies/persistence.jsp, stav k 7. 5. 2010. [34] jQery. http://jquery.com/, stav k 7. 5. 2010. [35] JSF dokumentace. http://java.sun.com/javaee/javaserverfaces/, stav k 7. 5. 2010. [36] Mod Cluster. http://www.jboss.org/mod_cluster, stav k 7. 5. 2010. [37] Mod JK. http://tomcat.apache.org/tomcat-3.3-doc/mod_jk-howto.html, stav k 7. 5. 2010. [38] MySQL Cluster dokumentace. http://dev.mysql.com/doc/refman/5.0/en/mysql-cluster.html, stav k 7. 5. 2010. [39] MySQL cluster guide. http://www.mysql.com/products/database/cluster/, stav k 7. 5. 2010. [40] MySQL JDBC Connector atributes. http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-confgurat%ionproperties.html|, stav k 7. 5. 2010. [41] MySQL cluster installer. http://www.severalnines.com/sandbox/, stav k 7. 5. 2010. [42] Náklady. http://quercus.kin.tul.cz/~helena.zukova/multiedu/EKR/6cviceni-09-Vyno%synaklady HV.doc|, stav k 7. 5. 2010. [43] Netbeans. http://www.netbeans.org/, stav k 7. 5. 2010. [44] OnTime. http://www.axosoft.com/, stav k 7. 5. 2010. [45] Postgresql. http://www.postgresql.org/, stav k 7. 5. 2010.

|,

96

LITERATURA

[46] RichFaces Calendar. http://livedemo.exadel.com/richfaces-demo/richfaces/calendar.jsf, 7. 5. 2010.

stav

k

[47] RichFaces skins dokumentace. http://docs.jboss.org/richfaces/latest_3_3_X/en/devguide/html/Architec%tureOverview.html|, stav k 7. 5. 2010. [48] Seam cluster. http://docs.jboss.org/seam/2.2.0.GA/en-US/html/ClusteringAndEJBPassiva%tion.html|, stav k 7. 5. 2010. [49] Seam embedded. http://docs.jboss.org/seam/2.2.0.GA/en-US/html/configuration.html#d0e2%5013|, stav k 7. 5. 2010. [50] Spring Web Flow dokumentace. http://www.springsource.org/webflow, stav k 7. 5. 2010. [51] Test Driven Development. http://www.agiledata.org/essays/tdd.html, stav k 7. 5. 2010. [52] Template p°edloha. http://www.euroekonom.cz/podnikani/faktura.png, stav k 7. 5. 2010. [53] TestNG dokumentace. http://testng.org/doc/documentation-main.html, stav k 7. 5. 2010. [54] Trac. http://trac.edgewall.org/,stav k 7. 5. 2010. [55] UML. http://www.uml.org/, stav k 7. 5. 2010. [56] Web Beans. http://seamframework.org/WebBeans, stav k 7. 5. 2010. [57] Wicket dokumentace. http://http://wicket.apache.org/, stav k 7. 5. 2010.

Spring in Action. Manning, 2st edition, 2008. In English. JBoss Seam Simplicity and Pover Beyond Java EE. Prentice

[58] C. Wels and R. Breidenbach.

[59] M. J. Yuan and T. Heute. Hall, 1st edition, 2007. In English.

Dodatek A

Seznam pouºitých zkratek SFSB

Stateful Session Bean.

Automatizér SLSB RIA

JAR soubor, který obsahuje implementaci ProjectInterface.

Stateless Session Bean.

Rich Internet Application.

AJAX UML

Asynchronous JavaScript and XML.

Unied Modeling Language.

KLOC

Kilo Lines Of Code.

HTTPS

Hypertext Transfer Protocol Secure.

.. .

97

98

DODATEK A.

SEZNAM POUITÝCH ZKRATEK

Dodatek B

Instala£ní a uºivatelská p°íru£ka B.1

Prom¥nné pro faktura£ní vzor

Uºivatelská faktura :

• #{userFaktura.number()} - £íslo faktury, • #{userFaktura.actualUser.rstName} - jméno uºivatele, • #{userFaktura.actualUser.secondName} - p°íjmení uºivatele, • #{userFaktura.actualUser.address.street} - ulice uºivatele, • #{userFaktura.actualUser.address.houseNumber} - £íslo domu uºivatele, • #{userFaktura.actualUser.address.town} - m¥sto uºivatele, • #{userFaktura.actualUser.address.postalCode} - PS uºivatele, • #{userFaktura.fakturaFirma} - rma majitele , • #{userFaktura.fakturaAdresa} - adresa majitele, • #{userFaktura.actualUser.ICO} - ICO uºivatele, • #{userFaktura.fakturaMesto} - m¥sto majitele, • #{userFaktura.actualUser.townIndex} - kde je zapsán uºivatel, • #{userFaktura.ICO} - ICO majitele, • #{userFaktura.DIC} - ICO majitele, • #{userFaktura.vystaveni()} - datum vystavení, • #{userFaktura.actualUser.footageForm} - zp·sob p°evodu, • #{userFaktura.zdanitelnePlneni()} - zdanitelné pln¥ní, 99

100

DODATEK B.

INSTALANÍ A UIVATELSKÁ PÍRUKA

• #{userFaktura.actualUser.bankName} - jméno banky uºivatele, • #{userFaktura.actualUser.accountNumber.bankNumber} - £íslo banky uºivatele, • #{userFaktura.actualUser.accountNumber.accountNumber} - £íslo ú£tu uºivatele, • #{userFaktura.splatnost()} - splatnost faktury, • #{userFaktura.faktura.fakturaRow} zde je d·leºite var="row" kde row dále pouºíváme - co je fakturováno, • #{userFaktura.description(row)} - výpis popisku °ádky faktury, • #{userFaktura.money(row)} - fakturováno za tento °ádek, • #{userFaktura.fakturaMena} - m¥na fakturace, • #{userFaktura.money()} - fakturováno celkem, • #{userFaktura.fakturaJmeno} - vy°izuje jméno, • #{userFaktura.fakturaTel} - vy°izuje telefon, • #{userFaktura.fakturaEmail} - vy°izuje email. Firemní faktura :

• #{rmaFakturaAction.number()} - £íslo faktury, • #{rmaFakturaAction.fakturaJmeno} - jméno majitele, • #{rmaFakturaAction.fakturaAdresa} - adresa majitele, • #{rmaFakturaAction.fakturaMesto} - m¥sto majitele, • #{rmaFakturaAction.kf.rma.obchodniFirma} - jméno kontraktní rmy, • #{rmaFakturaAction.kf.rma.address.street} - ulice kontraktní rmy, • #{rmaFakturaAction.kf.rma.address.houseNumber} -£íslo domu kontraktní rmy, • #{rmaFakturaAction.ICO} - ICO majitele, • #{rmaFakturaAction.kf.rma.address.town} - m¥sto kontraktní rmy, • #{rmaFakturaAction.kf.rma.address.postalCode} - PS kontraktní rmy, • #{rmaFakturaAction.fakturaZapsan} - majitele zapsán, • #{rmaFakturaAction.kf.rma.ICO} - ICO kontraktní rmy, • #{rmaFakturaAction.kf.rma.DIC} - DIC kontraktní rmy, • #{rmaFakturaAction.vystaveni()} - datum vystavení,

B.2.

APACHE

101

• #{rmaFakturaAction.fakturaFormaUhrady} - forma úhrady, • #{rmaFakturaAction.zdanitelnePlneni()} - zdanitelné pln¥ní, • #{rmaFakturaAction.fakturaBanka} - banka majitele, • #{rmaFakturaAction.fakturaCisloUctu} - £íslo ú£tu majitele, • #{rmaFakturaAction.splatnost()} - splatnost, • #{rmaFakturaAction.recordList} zde je d·leºite var="row" kde row dále pouºíváme - co je fakturováno, • #{rmaFakturaAction.description(row)} - výpis popisku °ádky faktury, • #{rmaFakturaAction.money(row)} - fakturováno za tento °ádek, • #{rmaFakturaAction.fakturaMena} - m¥na fakturace, • #{rmaFakturaAction.money()} - fakturováno celkem, • #{rmaFakturaAction.fakturaJmeno} - vy°izuje jméno, • #{rmaFakturaAction.fakturaTel} - vy°izuje telefon, • #{rmaFakturaAction.fakturaEmail} - vy°izuje email. B.2

Apache

Za£neme instalací. Pro tu bych doporu£il postupovat podle tohoto návodu - [8] Pokud chceme,aby Apache pracoval na jiném neº defaultním portu, coº je 80, p°idáme toto do souboru /etc/apache2ports.conf NameVirtualHost *:81 Listen 81 mod_jk.conf

# Load mod_jk module # Specify the filename of the mod_jk lib LoadModule jk_module modules/mod_jk.so # Where to find workers.properties JkWorkersFile conf/workers.properties # Where to put jk logs JkLogFile logs/mod_jk.log # Set the jk log level [debug/error/info] JkLogLevel info

102

DODATEK B.


# Select the log format JkLogStampFormat "[%a %b %d %H:%M:%S %Y]" # JkOptions indicates to send SSK KEY SIZE JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories # JkRequestLogFormat JkRequestLogFormat "%w %V %T" # Mount your applications JkMount /application/* loadbalancer # You can use external file for mount points. # It will be checked for updates each 60 seconds. # The format of the file is: /url=worker # /examples/*=loadbalancer JkMountFile conf/uriworkermap.properties # Add shared memory. # This directive is present with 1.2.10 and # later versions of mod_jk, and is needed for # for load balancing to work properly JkShmFile logs/jk.shm # Add jkstatus for managing runtime data JkMount status Order deny,allow Deny from all Allow from 127.0.0.1

Vytvo°te soubor APACHE_HOME\conf\uriworkermap.properties a vloºte do n¥j následující obsah. # Simple worker configuration file # Mount the Servlet context to the ajp13 worker /jmx-console=loadbalancer /jmx-console/*=loadbalancer /web-console=loadbalancer /web-console/*=loadbalancer

B.3.

JBOSS AS 5.1.

103

/test/*=loadbalancer /test=loadbalancer workers.properties

# Define list of workers that will be used # for mapping requests worker.list=loadbalancer,status # Define Node1 # modify the host as your host IP or DNS name. worker.node1.port=8109 worker.node1.host=localhost worker.node1.type=ajp13 worker.node1.lbfactor=1 worker.node1.cachesize=10 # Define Node2 # modify the host as your host IP or DNS name. worker.node2.port=8209 worker.node2.host=localhost worker.node2.type=ajp13 worker.node2.lbfactor=1 worker.node2.cachesize=10 # Load-balancing behaviour worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=node1,node2 worker.loadbalancer.sticky_session=1 #worker.list=loadbalancer # Status worker for managing load balancer worker.status.type=status B.3

JBoss AS 5.1.

Na p°iloºeném CD naleznete nastavený aplika£ní server, který jiº obsahuje v²e pro spu²t¥ní aplikace. Je pouze nutné spustit cluster a pokud jste postupovali podle krok· vý²e, bude loadbalancovaný pomocí apache. K jednoduchému spu²t¥ní sta£í dostat se do adresá°e bin v aplika£ním serveru a spustit node1.sh a node2.sh . B.4

MySQL

Upozornil bych, ºe clustrované databáze jsou vytvá°eny primárn¥ pro opera£ní systém LINUX . Stejn¥ tak je tomu i u MySQL. Vhledem k tomu, ºe jsem objevil velmi dobrý installer, který

104

DODATEK B.


naleznete zde [41] , p°i£emº je zde popsán postup, jak instalovat. Tento návod je podle mého názoru naprosto dosta£ující. Jediné zm¥ny, které bych doporu£oval provést jsou tyto.

V databázi vytvo°te databázové schéma diplomka takto CREATE DATABASE diplomka CHARACTER SET utf8 COLLATE utf8_general_ci; Dále do spou²t¥£e clusteru dopl¬t¥ v £ásti, která obsauhuje [MYSQLD DEFAULT] tento text default-character-set=utf8 default-collation=utf8_general_ci Nakonec je t°eba vytvo°it tabulky, které jsou p°iloºeny v tables.sql B.5

HTTPS

Pro zprovoznení HTTPS pot°ebujeme vytvo°it certikát, který následn¥ zavedeme do aplika£ního serveru JBoss 5.1. . Toto nastavení najdete kompletn¥ popsané na stránkách [26] .

B.6

Dodatek

Vzhledem k tomu, ºe se jedná o zprovoznení velmi pokro£ilých aplikací, které jsou spolu úzce provázány, mohou se b¥hem spo²t¥ní objevit chyby. Ty je nutné °e²it za pomoci internetu, p°ípadn¥ m¥ m·ºete kontaktovat.

Dodatek C

Obsah p°iloºeného CD . |-- aplika£ní server

- obsahuje aplika£ní server nastavený pro clusterování a loadbalancování - obsahuje návod k instalaci - obsahuje ve²keré knihovny pot°ebné pro kompilaci zdrojových kód·

|-- instalace |-- lib

|-- spustitelné soubory | |-- TM_bez_https_bez_clustrovani.ear - aplikace zkompilovaná bez podpory clustrování a bez HTTPS | |-- TM_bez_https_s_clustrovanim.ear - aplikace zkompilovaná pro podporu clustrování a bez HTTPS | |-- TM_s_https_bez_clustrovani.ear - aplikace zkompilovaná bez podpory clustrování a HTTPS | `-- TM_s_https_s_clustrovanim.ear - aplikace zkompilovaná pro podporu clustrování a HTTPS |-- text | |-- figures - obrázky pouºité v textu diplomové práce | |-- janurpe1.pdf - text diplomové práce ve formátu pdf | |-- janurpe1.tex - text diplomové práce v nekompilované podob¥ psané pro program latex | |-- reference.bib - reference pouºité v textu `-- zdrojové kódy |-- Diplomka | |-- ejbs - aplika£ní vrstva aplikace | |-- tests - testovací £ást aplikace | |-- packaging - podaplikace slouºící k tvorb¥ zkompilované verze aplikace | `-- web - webová vrstva aplikace |-- Diplomka-entity - balí£ek, obsahující entity a obecné prvky |-- JarClassLoader - balí£ek slouºící k na£ítání t°íd za b¥hu |-- JarImpl - ukázková implementace automatizéru `-- sql.sql - dávkový p°íkaz pro napln¥ní databáze 105

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

Recommend Documents