Protikorupční databáze a aplikace. Šárka Buranská

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Bakalářská práce

Protikorupční databáze a aplikace Šárka Buranská

Vedoucí práce: Mgr. Nečaský Martin, Ph.D.

Studijní program: Softwarové technologie a management, Bakalářský Obor: Softwarové inženýrství 17. května 2012

iv

v

Poděkování Ráda bych poděkovala konzultantovi práce Mgr. Martinovi Nečaskému, Ph.D., za rady při tvorbě práce i za možnost se podílet na vývoji a návrhu této alikace. Poděkování patří také Bc. Michalu Filipovi za doporučení a cenné rady při tvorbě textu práce i aplikace, a také Bc. Martinovi Vachatovi za kontrolu práce po gramatické stránce. Také bych ráda poděkovala za konzultaci Ing. Tomáši Černému při vývoji aplikace, jeho brzké odpovědi napomohly dokončení aplikace a Romanu Smetanovi za trpělivost a odpovědi na mnohdy nejasné otázky.

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 Mnichovicích dne 6. 5. 2012

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

viii

Abstract This bachelor’s thesis contains design, solution and implementation of anti-corruption database and application. The objectiv of the thesis is to create an instrument for Foundation Against Corruption (NFPK), which could replace the vast (existing) archive. The application allows to input information and relationships in corruption enviroment. The solution is adapted to the requirements of the client to simplify data input and search. Rescription of used technologies for implementation is also a part of this thesis. Description of implementation is focused on solving nontrivial problems.

Abstrakt Tato bakalářská práce je návrh a implementace protikorupční databáze a aplikace. Cílem práce je vytvořit prostředek pro Nadaci proti korupci, jež nahradí rozsáhlý (existující) archiv. Aplikace umožňuje zaznamenávání informací a vztahů v korupčním prostředí. Návrh je přizpůsoben požadavkům klienta na zjednodušení zaznamenávání a vyhledávání ve shromážděných datech. Součástí práce je popis technologií využitých k implementaci. V části popisu implementace se věnuji řešením netriviálních problémů.

ix

x

Obsah 1 Úvod

1

2 Analýza řešení 2.1 Specifikace požadavků . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Souhrn požadavků . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Popis objektů v aplikaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Popis vztahů a vazeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Případy užití . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Správa uživatelů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Správa dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Scénáře vybraných aktivit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Zápis informace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Stahování dat o společnosti z obchodního rejstříku . . . . . . . . . . . 2.4.3 Vytvoření vztahu mezi objekty typu Informace, Osoba, Společnost, Adresa, E-mail, Automobil, Telefon . . . . . . . . . . . . . . . . . . . . 2.4.4 Vytvoření vazeb mezi objekty typu Informace, Událost a Zpráva . . . .

3 3 3 4 5 7 7 8 12 12 12

3 Návrh řešení 3.1 Návrh datového modelu . . . . . . . . . . . . . 3.1.1 Převedení reálných objektů do systému . 3.1.2 Popis menších objektů datového modelu 3.2 Třívrstvá architektura aplikace . . . . . . . . . 3.3 Balíčky aplikace . . . . . . . . . . . . . . . . . . 3.3.1 Balíček classes . . . . . . . . . . . . . . 3.3.2 Balíček controller . . . . . . . . . . . . . 3.3.3 Balíček dao . . . . . . . . . . . . . . . . 3.3.4 Balíček editor . . . . . . . . . . . . . . . 3.4 Využité technologie . . . . . . . . . . . . . . . . 3.4.1 Spring Framework . . . . . . . . . . . . 3.4.2 Hibernate . . . . . . . . . . . . . . . . . 3.4.3 Java Server Pages . . . . . . . . . . . . 3.4.4 Apache Maven . . . . . . . . . . . . . . 3.4.5 Vývojové prostředí . . . . . . . . . . . . 3.5 Návrh řešení hlavních požadavků . . . . . . . . 3.5.1 Zápis informací do databáze . . . . . .

17 17 17 19 19 19 19 20 20 20 21 21 21 21 22 22 22 22

xi

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

13 14

xii

OBSAH

3.5.2

Vytváření vztahů mezi objekty . . . . . . . . . . . . . . . . . . . . . . 23

4 Implementace 4.1 Využítí Hibernate v aplikaci . . . . . . . . . . . . . . 4.1.1 Hibernate anotace příklady . . . . . . . . . . 4.2 Realizace vztahů mezi objekty . . . . . . . . . . . . . 4.2.1 Propojení tříd Information,Report a Event . . 4.2.2 Vytváření vztahu . . . . . . . . . . . . . . . . 4.3 Opakující se textové hodnoty . . . . . . . . . . . . . 4.3.1 Možnosti řešení . . . . . . . . . . . . . . . . . 4.3.2 Editovatelný select . . . . . . . . . . . . . . . 4.3.3 Příklad třídy z balíčku Editor . . . . . . . . . 4.4 Vyhledávání Společností podle IČ z externích zdrojů 4.4.1 Realizace vyhledávání . . . . . . . . . . . . . 4.4.2 Aktualizace společnosti . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

25 25 25 26 26 27 28 28 28 28 29 29 30

5 Testování 5.1 Kontrola splnění požadavků . . . . . . . . . . . . . . . . . . . 5.1.1 Technické požadavky na aplikaci a databázi . . . . . . 5.2 Zátěžové testy aplikace . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Testovací prostředí . . . . . . . . . . . . . . . . . . . . 5.2.2 Test vyhledávání . . . . . . . . . . . . . . . . . . . . . 5.2.3 Test vkládání informací různého druhu . . . . . . . . . 5.2.4 Výsledky testování . . . . . . . . . . . . . . . . . . . . 5.2.5 Zátěžový test vyhledávání podle počtu uživatelů . . . 5.2.6 Zátěžový test ukládání informací podle počtu uživatelů

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

33 33 33 34 34 34 35 37 38 38

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

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

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

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

6 Závěr 41 6.1 Zhodnocení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 6.2 Pokračování práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 A Seznam použitých zkratek

45

B UML diagramy

47

C Instalační a uživatelská příručka 49 C.1 Instalační příručka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 D Obsah přiloženého CD

51

Seznam obrázků 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12

Diagram požadavků . . . . . . . . . . . . . . . . . . . . . Doménový model aplikace . . . . . . . . . . . . . . . . . . Případy užití souhrn . . . . . . . . . . . . . . . . . . . . . Případy užití - správá uživatelů . . . . . . . . . . . . . . . Případy užití - správa informace . . . . . . . . . . . . . . . Případy užití - správa události . . . . . . . . . . . . . . . . Případy užití - správa společnosti . . . . . . . . . . . . . . Případy užití - správa osoby . . . . . . . . . . . . . . . . . Diagram aktivity - Zápis dat . . . . . . . . . . . . . . . . Diagram aktivity - Stahování dat z cizích zdrojů . . . . . Diagram aktivity - Vytváření vztahu mezi dvěma objekty Diagram aktivity - Vytváření vazby mezi dvěma objekty .

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

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

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

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

3.1 3.2

Datový model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Obsah balíčku com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8

Entita Information . . . . . . . . . . . . . . . . . . . . . . . . . . . Metoda připojovaného objektu pro třídy Information,Report,Event Metoda připojení objektu . . . . . . . . . . . . . . . . . . . . . . . Implementace selectu v JSP stránce . . . . . . . . . . . . . . . . . Třída vytvářející objekty z textových hodnot . . . . . . . . . . . . Metoda pro vytvoření dotazu na informační systém ARES . . . . . Metoda pro vyhledání společnosti . . . . . . . . . . . . . . . . . . . Příchozí xml soubor z informačního systému ARES . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

26 27 27 28 29 30 31 32

5.1 5.2 5.3 5.4 5.5 5.6

Graf Graf Graf Graf Graf Graf

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

35 36 37 37 38 39

průměrných hodnot pro test vyhledávání jedním uživatelem průměrné odezvy systému pro ukládání 3 uživatelů zároveň průměrné odezvy při ukládání deseti uživateli . . . . . . . . průměrné odezvy při ukládání 1200 položek třemi uživateli . průměrné odezvy při vyhledávání existující informace . . . . průměrné odezvy při ukládání e-mailu . . . . . . . . . . . .

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

. . . . . .

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

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

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

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

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

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

4 6 7 8 9 10 10 11 13 14 15 16

B.1 Seznamy tříd balíčků classes, controller,dao a editor . . . . . . . . . . . . . . . 47 C.1 Obsah souboru data-config.xml . . . . . . . . . . . . . . . . . . . . . . . . . . 49 D.1 Seznam přiloženého CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

xiii

xiv

SEZNAM OBRÁZKŮ

Seznam tabulek 5.1 5.2 5.3 5.4 5.5

Tabulka Tabulka Tabulka Tabulka Tabulka

testu vyhledávání pro jednoho uživatele . . . . . . . . . . . naměřených hodnot vyhledávání pro patnáct uživatelů . . naměřených hodnot ukládání pro 3 uživatele . . . . . . . . naměřených hodnot ukládání pro 10 uživatelů . . . . . . . naměřených hodnot ukládání 1200 položek pro 3 uživatele

xv

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

34 35 35 36 36

xvi

SEZNAM TABULEK

Kapitola 1

Úvod Bakalářská práce pojednává o vývoji aplikace a databáze pro Nadační fond proti korupci. Databáze by měla nahradit běžný archiv informací, které NFPK nashromaždila a stále získává. Aplikace bude sloužit jako rozhraní pro práci s databází. Aplikace bude nasazena na webovém serveru, uživatel tedy k ní bude mít přístup odkudkoliv přes svůj webový prohlížeč. Přístup do aplikace je zabezpečen autentizací a autorizací uživatelů. Požadavky na vzhled a funkčnost aplikace a databáze pocházejí od zadavatele(pověřené osoby NFPK). Aplikace byla vytvářena v rámci bakalářské práce z důvodů šetření prostředky(jedná se o neziskovou organizaci) a důvodu neexistence podobného řešení na trhu. Jedná se tudíž o aplikaci navrženou pouze pro tuto organizaci, bez předpokladů využití třetí stranou. Pro implementaci byl zvolen jazyk Java, v konkrétní podobě Frameworku Spring. Důvodem byla má dobrá zkušenost s tímto frameworkem, velká tvárnost systému a existence množství knihoven a dalších frameworků. Pro zabezpečení aplikace byl použit framework SpringSecurity. Zobrazovací rozhraní aplikace je interpretováno jako HTML, je tedy jednoduše upravitelné i bez znalosti frameworků.

1

2

KAPITOLA 1. ÚVOD

Kapitola 2

Analýza řešení Aplikace byla navržena podle požadavků zadavatele (klienta). Žádný obdobný software splňující požadavky zadavatele na trhu není, kvůli svému specifickému přístupu k datům a jejich zpracování. Zadavatel má specifické požadavky na průběh jednotlivých procesů např. před zadáváním jakýchkoliv dat do databáze, musí být ověřeno zda podobná informace již v systému nefiguruje. Dalšími specifickými požadavky bylo vytváření viditelných spojení mezi informacemi vloženými do systému. Aby pracovníci NFPK po vyhledání jednotlivých subjektů měli přehled jaké další subjekty s ním mají souvislost.

2.1

Specifikace požadavků

Uživateli aplikace budou pracovníci Nadačního fondu proti korupci, kteří budou aplikaci využívat při shromažďování informací o korupčním prostředí v ČR. Informace budou pocházet z předem nespecifikovaných zdrojů, aplikace bude umožňovat zadávání objektů pouze manuálně, s výjimkou obchodního rejstříku firem v ČR. V této fázi bude implementováno pouze pro vytváření záznamů o společnosti evidovaných obchodním rejstříkem. V dalších fázích vývojem by měla aplikace po rozšíření být schopna příjmat data i z dalších zdrojů automaticky. Například tiskové výstupy a zprávy, nebo novinové články.

2.1.1

Souhrn požadavků

Aplikace bude dostupná na webovém serveru s přístupem pro registrované uživatele. Uživatele budou registrovat pracovníci NFPK, uživatelé mají tři různé úrovně oprávnění. Nejnižší úroveň oprávnění byla navržena pro pracovníky, kteřý mají za úkol v datech číst nebo data analyzovat pro další účely. Střední úrověň oprávnění je pro pracovníky, jejichž úkolem je data zaznamenávat do systému nebo v nich také číst. Poslední úrovní je úrověň pro správce systému. Správce má možnosti mazání dat a uživatelů, a také správa uživatelských účtů. Informace budou prostřednictvím aplikace zaznamenávány do databáze. Aplikace umožní uživateli zadávat různé typy informací, editovat informace nebo je mazat z databáze. Aplikace bude omezovat vkládání stejných dat vícekrát. Uživatel bude mít možnost fulltextového vyhledávání v databázi a prohlížení nalezených informací prostřednictvím aplikace.

3

4

KAPITOLA 2. ANALÝZA ŘEŠENÍ

Obrázek 2.1: Diagram požadavků

Informace budou zaznamenávány manuálně přes rozhraní aplikace, výjimkou jsou ekonomické subjekty. Informace o ekonomických subjektech registrovaných státní správou ČR bude možné vyhledávat v obchodním rejstříku automaticky. Při znalosti Identifikačního čísla ekonomického subjektu bude mít uživatel možnost jej evidovat v aplikaci a dalé jej upravovat nebo s ním pracovat v rámci aplikace jako s objektem společnost. Společnost bude na požádání uživatele aktualizována v databázi stažením aktuálních údajů z obchodního rejstříku. Mezi zaznamenanými informacemi budou moci vznikat vztahy a vazby. Uživatel bude moci vytvářet tyto vztahy, upravovat je a mazat. Vztahy a vazby budou prezentovat souvislosti mezi dvěma objekty. Tyto souvislosti budou pro přehlednost vypisovány u souvisejících objektů. Aplikace by měla býl pro uživatele snadno ovladatelná a pochopitelná. Pro snadnější osvojení bude dodána uživatelská dokumentace.

2.2

Popis objektů v aplikaci

Aplikace bude pracovat s objekty, které si můžeme prohlédnout na obrázku 2.2. Objekty nesoucí hlavní informace budou informace, událost, zpráva, osoba a společnost. Informace bude obsahovat konkrétní představu o jaké koliv získané informaci uživatelem. Bude se zde jednat o konkrétní popis jedné informace, jako je například „Úplatek pro pracovníka městského úřadu“. Pro detailní zdokumentování informace slouží pomocné objekty zdroj informace, stav informace a její důvěrihodnost. Událost bude obsahovat popis události která nastane nebo již nastala a je pro nás z nějakého důvodu důležitou. Událost má podobně jako informaci, mimo textové hodnoty také pomocné objekty stav události, například zda událost již proběhla, specializaci události, která nám přiblíží okruh zájmu, a region, kterého se událost týká. Objekt zpráva může být například tisková zpráva ze zasedání společnosti nebo také novinový článek. Pomocné objekty zprávy jsou stav zprávy a druh zprávy, kde specifikujeme o jakou zprávu se jedná. Osoba bude obsahovat osobní údaje o člověku, kterého v databázi evidujeme. Objekt společnost bude reprezentovat firmu nebo společnost. Společnost má pomocný objekt typ společnosti.

2.2. POPIS OBJEKTŮ V APLIKACI

5

Dalšími objekty které nám budou napomáhat ke konkrétnímu určení reálných věcí v aplikaci jsou adresa,e-mail, telefon a automobil. Adresa nám konkretizuje například osobu, pokud bude aplikace obsahovat více osob se stejnými údaji, nebo také společnost. Bude možné jí uvést i pro informaci, pokud je to vhodné. E-mail bude reprezentovat e-mailovou adresu, protože dnes je již zvykem že jako osoby tak společnosti mají nejen fyzickou adresu ale i e-mailovou. Objekt telefon bude konkrétní telefonní číslo. Automobil bude obsahovat konkrétní informace o vozidle, což nám zaručí evidované číslo SPZ, které je nutně unikátní a nemůžeme nalézt dva vozi stejné poznávací značky.

2.2.1

Popis vztahů a vazeb

Mezi objekty můžme vidět naznačené vazby, tyto vazby nám ukazují, že nějaký objekt má něco společného s jiným objektem. Tyto vazby budou rozděleny na dvě skupiny na „vztah“ a „vazbu“. Vazba je jednodušší forma než vztah, proto začnu popisem vazby. Vazba bude říkat „tento objekt souvisí s tímto objektem“. Tato vazba nemá možnost definovat jaká je souvislost mezi objekty, pouze že nějaká souvislost existuje. Tato vazba bude moci vznikat mezi objekty informace, událost a zpráva. Příkladem, uvádíme zprávu, která se přimo týká konané události. Společnosti vydala prohlášení o průběhu a výsledcích valné hormady. Vztah je oproti vazbě více vypovídající. Vztah může vzniknout mezi objekty informace, osoba, společnost, adresa, e-mail, telefon a automobil. Ve vztahu můžeme zapsat o jaký vztah se jedná a od jaké do jaké doby trval. Například vztah osoby ke společnosti. Osoba může být vlastníkem, investorem nebo majitelem. Právě proto že existuje velké množství možností vztahů byt vytvořen objekt vztah s možností tuto hodnotu zapsat přesně jak uživatel uzná za vhodné.

6


Obrázek 2.2: Doménový model aplikace

2.3. PŘÍPADY UŽITÍ

2.3

7

Případy užití

Případy užití byly rozděleny do dvou logických celků – Správa dat a Správa uživatelů. Jedním z požadavků byla víceúrovňová přístupová oprávnění. Byly navrženy tři úrovně oprávnění přístupů do systému. Nejvyšší oprávnění má uživatel s rolí Administrátor. Administrátor smí jako jediný do spravovat přístupnost systému pro další uživatele a mazat evidované záznamy. Další uživatelskou rolí je Master, který smí na rozdíl od běžného uživatele data měnit a vytvářet. Poslední rolí je uživatel, je to nejnižší úroveň oprávnění. Uživatel smí pouze data číst a vyhledávát v nich. Není mu povolena žádná změna v datech.

Obrázek 2.3: Případy užití souhrn

2.3.1

Správa uživatelů

Správa uživatelů obsahuje požadované možnosti pro práci s uživatelským účtem. Uživatel sám má možnost pouze změnit své heslo a své osobní údaje uvedené v systému. Master má v tomto případě stejné možnosti jako uživatel. Administrátor je správcem uživatelských účtů. Administrátorem jsou také přidělovány oprávnění přístupu uživatelům. Jsou označeny: ROLE ADMIN,ROLE MASTER a ROLE USER. Administrátor nemá možnost vytvářet nové úrovně oprávnění.

8


Obrázek 2.4: Případy užití - správá uživatelů

2.3.2

Správa dat

Balíček, který jsem nazvala správa dat, obsahuje možností práce s daty v různých podobách. Informace vkládané do systému mají různé podoby. Máme tři primární objekty reprezentující Informaci, Událost a Zprávu. Dalšími doplňujícími objekty jsou Osoba, Společnost, Adresa, E-mail, Telefon a Automobil. Vytvářením těchto objektů a možnosti jejich popisu realizujeme požadavek na zápis dat do databáze. Mezi objekty Informace, Událost a Zpráva mohou vznikat vazby ze kterých bude vyplývat souvislost objektů. Například vydání tiskové zprávy týkající se nějaké informace. Vztahy budou v systému zaznamenávány uživatelem jako související objekty. Další druh vztahu vzniká mezi objekty Informace, Osoba, Společnost, Adresa, E-mail, Telefon a Automobil. Zde bylo požadavkem vztah popsat nebo definovat a zmapovat dobu trvání vztahu. Vytváření vztahu a výpis objektu ve vztahu by měly být přehledné. Případy užití znázorňují možnosti práce s těmito objekty. Informace (obrázek 2.5) se liší od objektů Událost a Zpráva v možnosti vytvářet vztahy druhého typu s doplňkovými objekty. Proto uvedu diagram případu užití pro Informaci a Událost, diagram pro Zprávu bude přiložen na doplňkovém CD. Případ užití pro Událost obrázek 2.6 je totožný s případem užití pro Zprávu. Máme všechny možnosti jako u objektu Informace. Jen u Události a Zprávy nebyl potřebný vztah s doplňkovými objekty. Další případy užití se týkají objektů Osoba, Společnost, Adresa, E-mail, Telefon a Automobil. Případ užití pro Společnost je rozšířen o stahování údajů o ekonomických subjektech a jejich aktualizaci, obrázek 2.7. Všechny ostatní případy užití pro Osobu, Adresu, E-mail, Automobil a Telefon (máme na mysli telefonní číslo)jsou totožné, proto uvádím jen obrázek případu užití pro Osobu 2.8. Osoby v aplikaci odpovídají konkrétním osobám, které byly z nějakého důvodu evidovány NFPK. Případ užití správa osoby 2.8 je příkladem možností


9

pro zbylé objekty Adresu, E-mail, Automobil a Telefon. Jejich případy užití naleznete na přiloženém CD ve složce UML modely.

Obrázek 2.5: Případy užití - správa informace

10


Obrázek 2.6: Případy užití - správa události

Obrázek 2.7: Případy užití - správa společnosti


11

Obrázek 2.8: Případy užití - správa osoby

12


2.4

Scénáře vybraných aktivit

Pro vybrané aktivity naznačím scénář provedení uživatele.

2.4.1

Zápis informace

Scénář a diagram aktivit na obrázku 2.9 pro zápis informace je ukázkou zápisu všech ostatních objektů v aplikaci. Vytváření, editace a mazání objeků probíhá u všech objektů totožně, proto zde uvádím jen příklad pro Informaci. Diagramy aktivit pro editaci a mazání budou přiloženy na CD. 1. Přihlášený uživatel s právy pro zápis, ve vyhledávání nenalezl existující Informaci vypovídající o daném tématu. Proto se rozhodl Informaci do aplikace zapsat. 2. Uživatel klikne na Nová informace. 3. Zobrazí se formulář pro vyplnění. 4. Uživatel vyplní požadované údaje a klikne na uložit. 5. Aplikace zkontroluje vyplnění povinných údajů. 6. Aplikace zobrazí detailní pohled na novou informaci.

2.4.2

Stahování dat o společnosti z obchodního rejstříku

V aplikaci máme možnost stažení údajů o ekonomických subjektech registrovaných v ČR, ze zdrojů poskytovaný správními úřady. Informace o registrovaných společnostech uchovává obchodní rejstřík, tyto informace jsou volně dostupné na internetu. Pro jednoznačnou identifikaci společnosti je využíváno ČÍSLO IČ, které je přiděleno všem ekonomickým subjektům při registraci. Evidování společnosti v aplikaci je názorněji zobrazeno diagramem aktivit na obrázku 2.10 1. Přihlášený uživatel s právy pro zápis, nenalezl ekonomický subjekt v námi registrovaných společnostech. 2. Uživatel klikne na Najít společnost. 3. Aplikace zobrazí formulář pro vyplnění identifikačního čísla ekonomického subjektu a klikne na Doplnit podle IČ. 4. Při úspěšném vyhledání firmy v rejstříku aplikace zobrazí detail společnosti i s připojeným objektem. Adresa, která je se společností ve vztahu „sídlo firmy“. Adresa je doplněna podle údajů z rejstříku e.s.

2.4. SCÉNÁŘE VYBRANÝCH AKTIVIT

13

Obrázek 2.9: Diagram aktivity - Zápis dat

2.4.3

Vytvoření vztahu mezi objekty typu Informace, Osoba, Společnost, Adresa, E-mail, Automobil, Telefon

Vytváření vazeb mezi objekty bylo jedním z požadavků zadavatele. Přesněji jde o to zobrazit vztahy mezi jednotlivými objekty v aplikaci. Jako příklad bude uveden vztah Osoby a Adresy kde má osoba trvalé bydliště. Scénář je zobrazen modelem aktivit, obrázek 2.11 1. Uživatel je oprávněn k vytváření vztahu mezi objekty, má zobrazený detail vybraného osoby. 2. Uživatel v detailu vybrané entity klikne na ikonku Připojit . 3. Aplikace zobrazí vyhledávací stránku. 4. Uživatel vyhledá adresu, kterou chce připojit, v horní části vyhledávání vidí název objektu, ke kterému připojení probíhá 5. Pokud ve vyhledávání uživatel nalezne hledanou adresu, na konci jeho výpisu klikne na Vytvořit vztah. 6. Po kliknutí na Vytvořit vztah se zobrazí formulář pro zápis vztahu. 7. Uživatel vyplní informace o vztahu a klikne na Uložit.

14


Obrázek 2.10: Diagram aktivity - Stahování dat z cizích zdrojů

8. Aplikace zobrazí detail osoby ke které byla připojována adresa, i s zobrazeným vztahem který právě vznikl.

2.4.4

Vytvoření vazeb mezi objekty typu Informace, Událost a Zpráva

Vytvoření vazby je podobné jako u vytváření vztahu, avšak jde o vazby mezi jinými objekty. Vazba je pouze znázorněním souvislostí mezi objekty. Vztvoření vazby znázorňuje obrázek 2.12 1. Uživatel je oprávněn k vytváření vztahu mezi objekty, má zobrazený detail vybraného objektu. 2. Uživatel v detailu vybrané entity klikne na ikonku Připojit . 3. Aplikace zobrazí vyhledávací stránku. 4. Uživatel vyhledá objekt, který chce připojit, v horní části vyhledávání vidí název objektu, ke které připojení probíhá. 5. Pokud ve vyhledávání uživatel nalezne hledaný objekt, na konci jeho výpisu klikne na možnost Připojit.

2.4. SCÉNÁŘE VYBRANÝCH AKTIVIT

15

Obrázek 2.11: Diagram aktivity - Vytváření vztahu mezi dvěma objekty

6. Aplikace zobrazí detail objektu, ke kterému se připojoval druhý objekt, i se zobrazenou vazbou, která právě vznikla.

16


Obrázek 2.12: Diagram aktivity - Vytváření vazby mezi dvěma objekty

Kapitola 3

Návrh řešení 3.1

Návrh datového modelu

Vytvořená aplikace byla navržena nejen aby splňovala všechny požadavky zadavatele, ale aby značně zjednodušila jeho práci a zkvalitnila přístup k informacím. Při návrhu jsem upřednostňovala přátelský přístup aplikace a její přehlednost i za cenu zvýšení doby potřebného k její implementaci. Při návrhu aplikace bylo těžké si představit například jak by mělo fungovat vytváření souvislostí mezi objekty, nebo vytváření vztahů. Zadavatel předpokládal jasně předdefinované vztahy mezi objekty. Ze života víme, že ne všechny vztahy se dají jasně vymezit. Aplikace proto neříká, „definuj vztah“ ale naopak uživatel může takový vztah popsat podle reality. V analytické části práce jsme pro tento vztah vytvořili obejkt Vztah, kterým jasně uvedeme o jaký vztah se jedná a jak dlouho vztah trval nebo od kdy, pokud ještě trvá. Příkladem může být vztah dvou osob mezi sebou. Můžou být manželé, partneři, kolegové, kamarádi, spolužáci nebo sourozenci. Možností je opravdu mnoho, proto uživatel takový vztah popíše, nemá omezený výběr možností. Z informací o uživateli jsem došla k názoru, že bude chtít znát přesné informace o subjektu který zkoumá, a v aplikaci budou figurovat i vztahy a vazby které nejsou veřejně známé, tedy nejsou jednoduše ověřitelné. Proto chci nabídnou aplikaci, která zpracuje získané informace a nic z jejich konkrétnosti se neztratí.

3.1.1

Převedení reálných objektů do systému

Na obrázku 3.1 vídíme s jakými třídami aplikace pracuje. Jak jsme reálné objekty přetavili na třídy, se kterými budeme v aplikaci pracovat. V modelu je vynechána třída BaseEntity, která je předkem všech tříd modelu. Je to z důvodu lepší čitelnosti modelu. Třída BaseEntity obsahuje atribut Long id, které slouží jako identifikační číslo a metody getId a setId. Z analýzy vyplynuly jako hlavní objekty Informace, Událost a Zpráva. V modelu jsou reprezentovány třídami Information, Event a Report. Další objekty, které jsem považovala za důležité, byly již zmíněné Osoba a Společnost, pak jsou tu tzv. doplňkové objekty, které nám upřesňují informace o osobě, informaci či společnosti. Jedná se o Adresu, E-mail, Telefonní

17

18

KAPITOLA 3. NÁVRH ŘEŠENÍ

číslo a Automobil. Tyto třídy jsou samostatné, i když je víceméně jasné, že v reálném světě mají vazbu na osobu či společnost. Může se však stát, že informace přijde z nějaké adresy či telefonního čísla a nevíme, ke komu patří. Proto jsem ustoupili od běžného vnoření těchto informací do objektů osoba nebo společnost.

V modelu najdeme třídu Entita, která je předkem tříd Person, Company, Address,Email,Telefon a Vehicle. Třída Entita obsahuje atribut bindings, jedná se o list vztahů, které třída vlastní. Třída předka byla navržena z důvodu jednodušší implementace propojování objektů.

Obrázek 3.1: Datový model

3.2. TŘÍVRSTVÁ ARCHITEKTURA APLIKACE

3.1.2

19

Popis menších objektů datového modelu

Již jsem popsala hlavní třídy pro práci aplikace, teď bych ještě ráda upřesnila některé zvláštní aspekty datového modelu, obrázek 3.1. V datovém modelu můžeme najít více objektů, jejichž jediným atributem je hodnota, tyto objekty byly navrženy pro textové hodnoty, které tvoří atributy složitějších objektů. Protože se dalo předpokládat, že se tyto textové hodnoty budou opakovat, vytvořila jsem pro ně tabulky v databázi. Uživatel tedy má možnost vybírá tyto hodnoty již z některých zadaných nebo si vytvořit vlastní novou hodnotu. Více k tomuto tématu v kapitole \ref{edit_select} .

3.2

Třívrstvá architektura aplikace

Aplikace je rozdělena do vrstev podle architektonického vzoru MVC (model-view-controller). Datový model, řídící logika a uživatelské rozhraní aplikace jsou separovány. Snažíme se o co nejmenší provázání těchto komponent, aby přepsání nebo záměna jedné vrstvy neovlivnila další komponenty. Zvolila jsem architektonický vzor MVC pro jeho jednodušší implementaci a přehlednost.

3.3

Balíčky aplikace

Základní balíček com na obrázku 3.2 obsahuje balíčky modelu aplikace. Model je rozdělen do čtyř podbalíčků podle logických celků, obsah podbalíčku v obrázku B.1. Zobrazovací rozhraní obsahuje složka views, která je součástí hierarchie, ale nenáleží balíčku com. Balíčky bychom mohli rozdělit do vrstev aplikace následovně: balíček classes a dao jsou modelem aplikace, balíček controller je vrstva controller, balíček editor obsahuje třídy, které napomávají vrstvě controller při přebírání některých hodnot z vrstvy view.

Obrázek 3.2: Obsah balíčku com

3.3.1

Balíček classes

Balíček classes obsahuje entitní třídy reprezentující objekty reálného světa, s Hibernate anotacemi, díky nímž je jednoduše vytvořena databáze. Jak tyto třídy vypadají, jaké mají atributy a metody, najdeme v kapitole ??. Na obrázku B.1 najdeme seznam tříd, které tento balíček obsahuje.

20


3.3.2

Balíček controller

Balíček controller obsahuje třídy starající se o business logiku aplikace, najdeme je na obrázku B.1. Rozhodují, jaký dotaz spustí jakou metodu kterého kontroleru a také co uživateli bude zobrazeno. Mají na starosti také přebírání vstupu od uživatele a případnou komunikaci se třídami balíčku dao. Starají se o veškerou komunikaci mezi vrstvou view a modelem.

3.3.3

Balíček dao

Dao balíček obsahuje třídy reprezentující komunikaci s databází. Tyto třídy jsou prostředníkem mezi databází a kontrolery, které vydávají přikazy. Nemusíme se tedy zabývat na kterou databázi je aplikace nasazena. Údaje o připojované databázi obsahuje data-config.xml, který patří mezi konfigurační soubory Frameworku Spring. Třídy vrstvy dao komunikují s databází zjednodušeným způsobem. Ne přes klasické dotazy ale instancí třídy EntityManager, která pro dotaze jednotlivých typů nabízí zjednodušené metody. Tyto metody jsou čtyři - persist(): pro operaci INSERT, remove(): pro operaci DELETE, merge(): pro operaci UPDATE, find(): pro operaci SELECT, pro složitější dotazy se však nevyhneme tvoření dotazů manuálně.

3.3.4

Balíček editor

Balíček editor obsahuje třídy konstruující jednotlivé objekty z jejich textové podoby. Jedná se o objekty, které jsou do formulářových polí select vypisovány textově. Po odeslání formuláře je nutné je znovu převést na objekt. Proto pro každý takový objekt je v tomto balíčku třída Editor. Třídy controller nemusí o využití tříd editor žádat, framework si tyto překlady vyžádá sám pokud pro danou hodnotu existuje třída editor a controller ji registruje v metodě initBinder jejíž implementaci vidíme na obrázku 3.3.4. @InitBinder public void initBinder(WebDataBinder binder, WebRequest request)\{ binder.registerCustomEditor(Credibility.class, new CredibilityEditor(this.cDao)); binder.registerCustomEditor(Source.class, new SourceEditor(this.sDao)); binder.registerCustomEditor(StateInformation.class, new StateInformationEditor(this.siDao)); \} \caption{Metoda pro převod textových hodnota na objekty}

3.4. VYUŽITÉ TECHNOLOGIE

3.4

21

Využité technologie

Již dříve jsem popsala třívrstvou architekturu aplikace a proč jsem ji zvolila. Nyní bych ráda uvedla technologie, které jsem ve své práci využila. Jedná se pouze o nástin jejich možností, ukazky toho jak byly využity pro vývoj aplikace uvedu v kapitole 4.

3.4.1

Spring Framework

Spring je jedním z opensource Frameworků pro vývoj J2EE aplikací. Tento framework vývoj aplikací značně usnadňuje, i pro svou jednodušší strukturu konfiguračních souborů. Konfigurační soubory jsou většinou v xml formátu, v nich je konfigurován například přístup k databázi, prvky zabezpečení nebo informace o mapování požadavků na systém. „ Spring je populární a široce používaný open source framework, který pomáhá programátorum vyvýjet rychle kvalitní aplikace.“ [5] Spring jsem si vybrala pro vývoj této aplikace z důvodů jeho šíroké podpory vývojářskou komunitou, existence spolupracujících frameworků a také proto že se jedná o větší aplikaci, pro které se mi zdá Java jako vhodnější. Spring je postaven na využití návrhového vzoru Inversion of Control, který zajišťuje vytváření bean. Díky tomuto návrhovému vzoru a vzoru Dependency Injection, který se stará o závislosti mezi objekty, jsou objekty mnohem méně provázány. Díky tomu jsou například lépe testovatelné unit testy. Je více způsobů konfigurace jak frameworku říct které třídy má kde vytvořit. Jedním ze způsobů jsou konfigurační soubory xml, kde zapisujeme do jaké třídy potřebujeme potřebujeme vložit dané objekty. Druhý způsob je definovat potřebné objekty rovnou ve třídě. Objektům s kterými potřebujeme pracovat vytvoříme instance ale neinicializujeme je, pouze dam zápis proměné napíšem anotaci @Autowired. Toto nám dovolí právě Dependency Injection.

3.4.2

Hibernate

Hibernate [3] je framework podporující ORM [2], což znamená, že mapuje entitní objekty aplikace na relační tabulky databáze. Znamená to tedy, zachování výhod OOP a jednoduchost relačních databází. Hlavní výhodou Hibernate je již zmíněné mapování na objekty aplikace. Mapování lze realizovat dvěma způsoby, xml soubory s informacemi o mapování objektů nebo anotacemi, které jsou součástí entitních objektů. Zvolila jsem mapování anotacemi ze dvou důvodů. Nemusíme již vytvářet nové soubory a hned po otevření entitní třídy vidíme, jak budou atributy třídy vypadat v relační databázi. Jako databázový systém jsem zvolila MySQL [4] verze 5.5.16, protože je multiplatformní. Samotná komunikace databáze a aplikace pak probíhá v jazyce HQL (The Hibernate Query Language), který je velmi podobný jazyku SQL. Konfigurace databázového připojení najdeme v data-config.xml.

3.4.3

Java Server Pages

Zkráceně JSP je rozšíření HTML o tagy obsahující Java kód. Již jsem mluvila o třívrstvosti této aplikace. JSP je technologie, kterou jsem vybrala pro view. Tedy to, co uživatel uvidí ve svém prohlížeči, vypadá jako běžné HTML. Není to však úplně pravda. JSP tagy, které

22


můžeme včlenit mezi HTML a v nichž je Java kód, se překládají na kontrolerech naší aplikace, uživateli jsou reprezentovány již přeložené. Uživatel tedy nevidí žádnou část Java kódu. Java kód můžeme vkládat buď ve formě scriptletů, mezi značky <% ... %> podobně jako PHP, nebo lze využít připravených tagů z některé knihovny ke kterým přistupujeme přes předem definovaný namespace. Máme však ještě možnost vytvořit si vlastní knihovnu tagů. V aplikaci jsem využila hlavně výpis proměnných, se kterými lze pracovat jako s objekty, podmínkové bloky if nebo forEach cykly pro výpisy seznamů a kolekcí objektů. Práce s formuláři je díky JSP jednodušší, formulář ví, jaký objekt bude plnit, pro každou vlastnost objektu musí obsahovat vstupní políčko a hodnotu tohoto políčka automaticky (pro jednoduché datové typy) konvertuje na vlastnost objektu. Pro složitější datové typy, jako jsou námi vytvořené objekty, musíme konvertor napsat sami 3.3.4.

3.4.4

Apache Maven

„Apache maven je nástroj pro správu, řízení a automatizaci buildů aplikací. Ačkoliv je možné použít tento nástroj pro projekty psané v různých programovacích jazycích, podporován je převážně jazyk Java.“ V kořenové struktuře projektu najdeme soubor pom.xml (Project Object Model), který popisuje strukturu projektu a závislosti na externích knihovnách. Důvod proč považuji Maven za užitečný nástroj je právě správa externích knihoven, pokud v projektu chybí nějaká knihovna. Vyhledám si její Artifacts a vložím ho to sekce Dependencies v pom.xml. Maven se při spuštění postará o natažení potřebných knihoven do projektu.

3.4.5

Vývojové prostředí

Aplikace byla vyvýjena v prostředí , což je Eclipse upravený pro framework Spring. Je to jediné prostředí s přímou podporou tohoto frameworku. Testování a vývoj probíhal na aplikačním serveru Tomcat 7. Tomcat je opensource software vyvýjený pod Apache Licencí verze 2.

3.5 3.5.1

Návrh řešení hlavních požadavků Zápis informací do databáze

Vytváření záznamů do databáze bude probíhat přes klasické vyplnění formuláře. Každý objekt má vlastní formulář, proklik na formuláře najdeme v levém menu. Výpis registrovaných uživatelů a vytváření nových najdeme v horním menu.

3.5. NÁVRH ŘEŠENÍ HLAVNÍCH POŽADAVKŮ

3.5.2

23

Vytváření vztahů mezi objekty

Požadavek na aplikaci byla možnost vytváření vztahů mezi objekty. Po vytvoření datového modelu jsem získala hrubou představu o dvou typech propojení. Prvním typem je “vazba” mezi objekty Information,Report a Event, ve které se jedná jen o informaci, že spolu mají objekty něco společeného. Není možné ji nijak definovat, čímž je výpis i vznik vazby zjednodušený Druhý typ je “vztah”, ten může vznikat mezi objekty Information,Person, Company, Address,Email,Telefon a Vehicle. Tento vztah můžeme definovat. Tento vztah je specifický ještě proto, že může vznikat mezi objekty stejného typu. Vztah je reprezentován třídou Binding. Seznami těchto vztahů obsahuje každá ze tříd nebo její předek, které jsem uvedla výše.

24


Kapitola 4

Implementace 4.1

Využítí Hibernate v aplikaci

Framework Hibernate je využíván hlavně z důvodu nezatěžovat programátora psaním SQL dotazů a usnadnění vytváření databáze. Technika objektově relačního mapování (ORM) nám usnadňuje synchronizaci mezi objekty v aplikaci a jejich databázouvou podobou. V aplikaci jsou objekty napodobující ty reálné v balíčku classes. Těmto objektům říkáme Entity, entitu poznáme podle Hibernate anotace nad názvem třídy @Entity. Tato anotace Hibernatu říká, že objekt bude mít svou podobu v datbázové tabulce. Jsou i další anotace, kterými upřesníme například jméno třídy předka, který nebude mapován do databáze atd. Aby entita byla správně vytvořena, musí mít metodu hashCode a equals a každý její atribut musí mít metodu get a set.

4.1.1

Hibernate anotace příklady

Vlastnosti objektu, tedy atributy třídy mohou mít anotace buď nad sebou nebo nad metodou get. Využívanými anotacemi nad atributy jsou např. anotace @Id,@GeneratedValue nebo @ManyToOne,@OneToOne,@OneToMany. Anotaci @Id najdeme u atributů, které chceme aby databáze považovala za vlastní klíč tabulky,@GeneratedValue je v datbázi známý Auto Increment, tedy hodnota bude generována, většinou řadou čísel. Zajímavými a užitečnými anotacemi jsou @ManyToOne,@OneToOne,@OneToMany. Tyto anotace najdeme u atributů neprimitivních datových typů. Na obrázku 4.1 je třída Infromation.java, která je entitou naší aplikace. nad atributem source najdeme anotaci @ManyToOne. Typ Source je třída reprezentující zdroj informace. Anotace @ManyToOne říká Hibernatu, že mezi tabulkou zdrojů a informací je vztah, kdy zdroj může být stejný ve více informacích, ale v informaci je uveden pouze jeden zdroj. Tento příklad se v databázi projeví sloupcem source_id v tabulce Information, ve sloupci bude index zdroje, který jsme uvedli při zápisu nové informace. Anotace @ManyToMany nad atributem private List reports nám říká, že informace si bude držet seznam instancí třídy Zpráva (Report). V reálném světě chceme vědět jaké všechny zprávy jsou ve vztahu k dané informaci. V databázi se pro tento případ vytvoří propojovací tabulka pro Report a Information.

25

26

KAPITOLA 4. IMPLEMENTACE

Obrázek 4.1: Entita Information package com.classes; @Entity @UniqueConstraint(columnNames={"number","title"}) public class Information extends BaseEntity implements Serializable { private private private private private

long number; String title; String anotation; String text; String key_word;

private java.util.Date date_paste; private Date date_create; private Date date_obtain; @ManyToOne private Source source; @ManyToOne private Credibility credibility; private boolean publish; private String comment; @ManyToOne private StateInformation stateInformation; @ManyToMany private List reports; @ManyToMany private List<Event> events; @OneToMany private List publications; @ManyToMany//(fetch=FetchType.EAGER) private List bindings;

Za pozornost jistě stojí i jediná nepopsaná anotace této třídy, @UniqueConstraint (columnNames={"number","title"}). Již z názvu anotace lze vytušit, že se jedná o vlastnost unikátnosti a to konkrétně pro atributy number a title. Anotace mohou slouží také k validaci vkládaných informací. Chceme zabránit více Informacím mít stejné číslo a titulek.

4.2

Realizace vztahů mezi objekty

Vztahy mezi objekty jsou dvojího typu podle toho, jaké objekty propojuji. Propojení mezi Informací,Zprávou a Událostí je založeno na seznamech objektů v entitě. U objektů typu Osoba, Společnost ,Adresa, Telefon, E-mail, Automobil se jedná v propojení vztahem. Popis tvorby vztahu z pohledu uživatel jsem popsala v kapitole 3.5.2.

4.2.1

Propojení tříd Information,Report a Event

Jejich připojení je pouze přidání požadovaného objektu do seznamu druhého objektu. V kontrolerech těchto objektů najdeme metodu z ukázky 4.2, kde chceme neznámý objekt připojit k informaci. Instanci informace, ke které připojujeme, uložíme do session jako connectEntities a do entita její typ.

4.2. REALIZACE VZTAHŮ MEZI OBJEKTY

27

Obrázek 4.2: Metoda připojovaného objektu pro třídy Information,Report,Event @RequestMapping(value="connectToInformation/{id}") public String connecToInformation(@PathVariable("id")Long id,Model model,HttpServletRequest request){ Information i=iDao.find(id); request.getSession().setAttribute("connectEntities", i); model.addAttribute("page","read/search.jsp"); request.getSession().setAttribute("entita","Information"); return "main/main_template"; }

Po vyhledání připojovaného objektu se přesměruje požadavek zpět na kontroler do metody podle typu připojované entity. Pro náš příklad je připojovaná entita Událost, metodu vidíme na obrázku 4.3. Je vyhledána instance připojované události a vložena do seznamu informace, pokud již tuto událost neobsahuje. Pokud je událost připojena k informaci je tomu i naopak, informace je přidána do seznamu informací v události.

Obrázek 4.3: Metoda připojení objektu @RequestMapping(value="connectEventToInformation/{id}") public String connectEventToInformation(@PathVariable("id")Long id,Model model,HttpServletRequest request){ Information main=(Information)request.getSession().getAttribute("connectEntities"); List<Event> e=iDao.find(main.getId()).getEvents(); //pokud jiz v listu neni if(!e.contains(eDao.find(id))){ e.add(eDao.find(id)); main.setEvents(e); iDao.addInformation(main); }

return "redirect:../viewInformation/"+main.getId(); }

4.2.2

Vytváření vztahu

Vztah, kterým propojujeme objekty typu Osoba, Společnost ,Adresa, Telefon, E-mail, Automobil je reprezentován entitou Binding. Abychom si zjednodušili vývoj vytváření vztahů, výše zmíněné entity mají společného předka a to Entita, jehož atributem je seznam vztahů. Vztah vytváříme tím, že objekt, se kterým chceme vztah vytvořit, si uložíme do session jako proměnou typu Entita, po vyhledání druhého objektu se vytvoří instance obejktu Binding, který je uživatel nucen vyplnit. Po uložení proběhne přidání tohoto Bindingu do seznamu obou objektů. Díky společnému předkovi s děděním typu joined nemusíme vědět, o jaký typ objektu se jedná, a propojování je tím velmi jednoduché.

28

4.3


Opakující se textové hodnoty

V návrhové části jsem uváděla problém s často se opakujícími textovými hodnotami pro některé vlastnosti objektů. Určité vlastnosti se stejným významem se vyskytují ve více objektech. Proto jsem se rozhodla často opakující hodnoty uchovávat v databázi, ale protože neznám všechny hodnoty, kterých by dané vlastnosti mohly nabývat, rozhodla jsem se dát uživateli možnost naplnit si tabulku hodnoty sám.

4.3.1

Možnosti řešení

Jednou možností, uživatelsky nepříjemnou a z pohledu implementace složitější, bylo nabídnout uživateli přidávání těchto hodnot jednotlivě. Pomocí formulářů, pro každou takto definovanou vlastnost. Pro vývoj by to znamenalo vytvořit dalších přibližně 10 nových formulářů,výpisů a rozšíření menu o 10 položek. Pro uživatele je toto řešení nevhodné z čistě praktických důvodů. Uživatel by vyplňoval formulář například pro Informaci a během vyplňování by zjistil, že potřebuje do výběrového vstupu novou hodnotu, nezbývalo by mu nic jiného než si přepnout na přidání hodnoty.

4.3.2

Editovatelný select

Zvolila jsem tedy řešení, které není možné tolik ošetřit pro případné zadání “špatných hodnot”. A však je pro uživatele velmi jednoduché. Mám běžné výběrové políčko s výpisem již zadaných hodnot, ale uživatel má možnost do prázného řádku hodnoty zapsat novou hodnotu. Tato nová hodnota se díky třídám z balíčku editor stane objektem. V dalším zadávání stejné vlastnosti bude již na výběr. Třídy Editor zajišťují, aby nevznikaly kopie hodnot. Editovatelný select je realizován JavaScriptem který jsem převzala.[1] Obrázek 4.4: Implementace selectu v JSP stránce

4.3.3

Příklad třídy z balíčku Editor

Příkladem uvádím třídu ColorEditor.java. Barva je jistě opakující se hodnota, vlastnost barva je prvkem objektu Automobil, slouží ke snazšímu identifikování vozu spolu s SPZ a výrobcem vozu. Všechny třídy balíčku Editor mají předka PropertyEditorSupport. V konstruktoru třídy inicializujeme proměnnou ColorDao, což je třída sloužící pro komunikaci s databází třídy Color. V metodě setAsText přebíráme jako parametr textovou hodnotu vyplněné barvy. Ověřujeme, zda barva již je v databázi uložena či ne a následuje buď uložení nové barvy nebo jen její identifikace. Vracíme instanci třídy Color, která je vložena do instance třídy automobil.

4.4. VYHLEDÁVÁNÍ SPOLEČNOSTÍ PODLE IČ Z EXTERNÍCH ZDROJŮ

29

Obrázek 4.5: Třída vytvářející objekty z textových hodnot package com.editor; public class ColorEditor extends PropertyEditorSupport{ private ColorDao cDao; public ColorEditor(ColorDao cDao) { this.cDao=cDao; } @Override public void setAsText(String text) throws IllegalArgumentException { Color s; if (!cDao.find(text)) { s = new Color(); text= text.toUpperCase(); s.setValue(text); cDao.addColor(s); } else { s = cDao.findValue(text); } setValue(s); } }

4.4

Vyhledávání Společností podle IČ z externích zdrojů

Jedním z požadavků bylo vyhledávání dat o společnostech z obchodního rejstříku. Ares je „Administrativní registr ekonomických subjektů je informační systém, který umožňuje vyhledávání nad ekonomickými subjekty registrovanými v České republice. Zprostředkovává zobrazení údajů vedených v jednotlivých registrech státní správy, ze kterých čerpá data (tzv. zdrojové registry).“ [7] Ares poskytuje informace v podobě xml na základě vyhledávání podle IČ.

4.4.1

Realizace vyhledávání

Při zakládání nové společnosti v systému můžeme vyplnit údaje manuálně nebo vyhledat společnost podle IČ. Při vyhledávání zadáme IČ, na které pošleme přes HttpClient dotaz. Url dotazu vypadá takto http://wwwinfo.mfcr.cz/cgi-bin/ares/darv_std.cgi?ico="+ic+"&jazyk=cz&czk=utf na tento požadavek Ares odpoví xml s údaji o společnosti nebo null, pokud nemá o tomto IČ žádné údaje. Na obrázku 4.6 uvádím metodu zasálání dotazu a zpracování odpovědi od informačního systému ARES. Najdeme zde příkazy pro vytvoření HTTP klienta, dotaz v proměnné url je doplněn metodou o příslučné IČ a odeslán metodou get, k této metodě přidávám ještě hlavičku dotazu. V následujícím bloku try ... catch ... zpracovávám výsledek dotazu. Zpracování probíhá tak že, z odpovědi od ARES vytvořím xml soubor.

30


Obrázek 4.6: Metoda pro vytvoření dotazu na informační systém ARES

public Document getXMLFile(String ic) throws ParserConfigurationException, FactoryConfigurationError, SAXException, IOExcept String url ="http://wwwinfo.mfcr.cz/cgi-bin/ares/darv_std.cgi?ico="+ic+"&jazyk=cz&czk=utf"; HttpClient client = new HttpClient(); HttpMethod method = new GetMethod(url); method.addRequestHeader("Content-Type", "Content-Type: text/xml; charset=UTF-8"); client.executeMethod(method); try{ InputStream in=method.getResponseBodyAsStream(); DocumentBuilder db = DocumentBuilderFactory.newInstance().newDocumentBuilder(); Document doc = db.parse(in); in.close(); method.releaseConnection(); }catch(Exception e){ System.err.println(e); method.releaseConnection(); return null; } }

Obrázek 4.7 obsahuje metodu, na kterou je přesměrován původní požadavek klienta na vyhledání společnosti. Metoda příjmá jako parametr IČ z uživatelem vyplněného formuláře a předává jej výšše zmíněné metodě, která zašle dotaz na ARES a vytvoří xml soubor. Odpověď ve formě xml souboru je uložen v proměnné doc, která pokuď soubor obsahuje je další metodou parseXML zpracována na seznam pouze pro nás užitečných údajů. Metoda parseXML vyhledá v xml potřebné uzly a jejich data převede na námi požadovaný tvar. Seznam prvků je následně metodou newCompanyByRegistre zpracován do podoby objektů Company a Address mezi kterými je vztah popsaný jako „sídlo společnosti“. Z metody se nám vrací id nově evidované společnosti, na jejíž detailní zobrazení je následně uživatel přesměrován. Uživatel by měl v této fázi zkontrolovat zda byla společnost vztvořena správně, případně podlnit údaje, které obchodní rejstřík neeviduje. Neuvedené zdrojové kódy ke zpracování a vytváření Společnosti budou na přiloženém cd, třída CompanyController. Na obrázku 4.8 jsem uvedla příklad příchozího souboru ve formátu xml ze informačního systému ARES. Soubor byl pro ukázku zkrácen na uzly a hodnoty které jsem využila pro vytvoření společnosti a její adresy v aplikaci.

4.4.2

Aktualizace společnosti

Protože Ares omezuje počet dotazů na den pro jeden zdroj, nepřišlo my vhodné aktualizovat všechny společnoti v systému s časovou pravidelností. Údaje o společnostech budou aktualizovány na požádání uživatelem. V detailu společnosti bude možnost aktualizace, při které se současné hodnoty porovnají s hodnotami obchodního rejstříku a podle potřeby změní na aktuální.

4.4. VYHLEDÁVÁNÍ SPOLEČNOSTÍ PODLE IČ Z EXTERNÍCH ZDROJŮ

Obrázek 4.7: Metoda pro vyhledání společnosti @RequestMapping(value = "findCompany", method = RequestMethod.GET) public String companyFind(String ic, Model model, HttpServletResponse response, HttpServletRequest request) throws IOException, ParserConfigurationException, SAXException, FactoryConfigurationError, ServletException { try { Document doc = getXMLFile(ic); if (doc != null) { HashMap<String, String> list = parseXML(doc); list.put("ic", ic); Long id = newCompanyByRegistre(list); if (id == null) { model.addAttribute("title", "Najít společnost"); model.addAttribute("page", "add/pastCompany.jsp"); model.addAttribute("nosave", "Nenalezeno IČ"); model.addAttribute("ic", ic); return "main/main_template"; } else { return "redirect:viewCompany/"+id; } } else { model.addAttribute("title", "Najít společnost"); model.addAttribute("page", "add/pastCompany.jsp"); model.addAttribute("nosave", "Nenalezeno IČ"); model.addAttribute("ic", ic); return "main/main_template"; } } catch (UnknownHostException e) { model.addAttribute("title", "Najít společnost"); model.addAttribute("page", "add/pastCompany.jsp"); model.addAttribute( "nosave", "Pravděpodobně nejste připojen k internetu, aplikace nemohla stáhnout požadované údaje."); model.addAttribute("ic", ic); return "main/main_template"; } }

31

32


Obrázek 4.8: Příchozí xml soubor z informačního systému ARES

<are:Ares_odpovedi odpoved_datum_cas="2012-05-15T20:27:58" odpoved_pocet="1" odpoved_typ="Standard" vystup_format="XML" xslt <are:Odpoved> <are:Pocet_zaznamu>1 <are:Typ_vyhledani>FREE <are:Zaznam> <are:Datum_vzniku>2002-08-19 <are:Datum_platnosti>2012-05-15 <are:Pravni_forma> 117 <are:Obchodni_firma>NADACE SAZKA v likvidaci <are:ICO>26706989 <are:Identifikace> <are:Adresa_ARES> 201490564 Praha Vysočany Praha 9 K Žižkovu 851 4 19000 <are:Kod_FU>9

Kapitola 5

Testování Na výsledné aplikaci lze provést více druhů testů. Položila jsem si základní otázku, co vše by mělo být otestováno a proč. Samozřejmostí je kontrola požadavků. Splňuje výsledná aplikace všechny požadavky klienta? Funkční požadavky aplikace splňuje. Můžeme tedy zkontrolovat požadavky obecné.

5.1

Kontrola splnění požadavků

Kontrola obecných požadavků by měla následující podobu. Třem osobám z cílové skupiny uživatelů by byly rozdány uživatelské dokumentace k aplikaci a seznam s přidělenými úkoly. Každý uživatel by měl založený účet s jinými přístupovými právy, seznam úkolů by tomu byl přizpůsoben. Uživatel by plnil úkoly a zaznamenával své dojmy z aplikace, zda bylo plnění úkolu v neznámém prostředí obtížné či naopak. Tímto bychom mohli zhodnotit intuitivnost uživatelského rozhraní. Při plnění testovacího scénáře lze také ověřit požadavek na ošetření redundance dat. Bohužel není v dohledné době dokončení práce možné kontaktovat cílovou skupinu uživatelů, testování je tedy v zmíněno pouze v teoretické rovině. Myslím si že aplikace i databáze je velmi specifická, proto jsem nepovažovala za přínosné test provádět s jinou než cílovou skupinou uživatelů. Došla jsem k názoru že by tento test, provedený s běžným uživatelm ač zasvěceným do problematiky aplikace, pozbýval užitečnosti. Protože zadavatelem nebyla dodána ani ukázková data, která bude aplikace zpracovávat, nedovedu si ani já přesně představit rozsah potřeb uživatele.

5.1.1

Technické požadavky na aplikaci a databázi

V dnešní době je jistě jedním z nejdůležitějších požadavků na webovou aplikaci rychlost odezvy. Rychlost odezvy lze ovlivnit více faktory, vhodným návrhem aplikace, vhodnou implementací a kvalitou hardwaru (serveru), na kterém je aplikace nasazena. Návrh již v průběhu implementace nelze drasticky měnit, musíme tedy myslet na optimalizaci již při návrhu. Při návrhu databáze jsem měla na mysli minimalizaci počtu dotazů, při zobrazování jednotlivých view tzv. „co bude chtít uživatel vidět hned a co jsou pro něj podružné informace”. V tomto nám pomáhá Lazy Loading - návrhový vzor, jehož principem je vytažení dat z databáze až v té chvíli, kdy jsou potřeba. Pokud tedy použijeme jen jeden seznam objektů dané informace, databáze se nebude obtěžovat s posíláním dalších seznamů.

33

34

5.2

KAPITOLA 5. TESTOVÁNÍ

Zátěžové testy aplikace

Jednou z metod testování jsou zátěžové testy. K tomuto účelu jsem využila JMeter, opensource program, který je součástí projektu jakarta od Apache. [6] V tomto programu jsem vytvořila specifické testy, které simulují reálnou zátěž. Posíláním HTTP dotazů na aplikaci v nějakém cyklu větším počtem uživatelů v daném časovém rozmezí. Tímto způsobem lze otestovat rychlost odezvy aplikace na konkrétní dotazy, tedy akci uživatele. V programu JMeter se vytváří testovací plány, můžeme zde nastavit počet opakování plánu, kolik uživatelů zároveň bude aplikaci využívat a v jakém časovém rozmezí budou dotazy na aplikaci přicházet. Aplikaci testována na osobním počítači, tedy lokálním serveru, což může výsledky testování ovlivnit.

5.2.1

Testovací prostředí

Testovacím prostředím byl můj laptop, aplikační server Tomcat 7 pro nějž poskytuje rozhraní vývojové prostředí Eclipse. Spuštění aplikace probáhalo na lokálním serveru Apache s databází MySQL verze 5.5.16

5.2.2

Test vyhledávání

Prvním testovacím plánem jsem chtěla získat informace, jak velký vliv bude mít přístup více uživatelů na vyhledávání dat. Protože u aplikace se předpokládá nejvyšší počet dotazů na vyhledávání informací uložených v databázi, změřila jsem výkon vyhledávání. Test začíná úspěšným přihlášením uživatele a dále jsou na vyhledávač kladeny dotazy na existující i neexistující data v databázi. Na obrázku 5.1 vidíme graf průměrných hodnot odezvy při přihlášení a dvaceti opakovaných vyhledáváních s existujícími i neexistujícími hodnotami. V tabulce 5.1 vidíme všechny naměřené hodnoty v tomto testu Tabulka 5.1: Tabulka testu vyhledávání pro jednoho uživatele Název přihlášení vyhledávání existující informace vyhledávání neexistující informace celkem

Počet dotazů 1 20 20 41

Průměr 40 372 347 352

Střed 40 352 336 349

90% 40 417 390 417

Min 40 297 284 40

Max 40 518 461 518

Procento chybovosti 0.0 0.0 0.0 0.0

Budeme tedy zvyšovat počet uživatelů při stejném počtu vyhledávaných hodnot. Protože aplikace byla vyvíjena pro úzký okruh uživatelů, předpokládejme maximum deseti osob. Další test provedeme pro deset uživatelů, s počtem dvaceti dotazů na existující i neexistující data. Jelikož je vyhledávání fulltextové a vyhledáváme v devíti různých tabulkách, můžeme očekávat nárůst doby oproti jednomu uživateli. Výsledky tohoto testu najdeme v tabulce 5.2, která nám ukazuje, že průměrná odezva se nám zvedla na dvě sekundy z původních 372 milisekund u jednoho uživatele. Ve sloupci procenta chybovosti už nemáme jen nulové hodnoty, vidíme chybovost okolo 0,77%. Chybovost do 1% se většinou vývojářské komunity považuje za dobrou.

5.2. ZÁTĚŽOVÉ TESTY APLIKACE

35

Obrázek 5.1: Graf průměrných hodnot pro test vyhledávání jedním uživatelem

Tabulka 5.2: Tabulka naměřených hodnot vyhledávání pro patnáct uživatelů Název přihlášení vyhledávání existující informace vyhledávání neexistující informace celkem

Počet dotazů 10 200 200 410

Průměr 139 2153 2230 2141

Střed 126 2146 2160 2134

90% 189 3796 4009 3976

Min 22 255 172 22

Max 497 6086 6630 6630

Procento chybovosti 0.0 0.79 0.79 0.77

Z těchto testů tedy vyplývá, že doba odezvy se zvedá úměrně počtu uživatelů a počtu dotazů. Chybovost není závažně vysoká, můžeme tedy test zhodnotit v celku kladně. Procento chybovosti i doby odezvy může být ovlivněno prostředím, na kterém byla aplikace testována.

5.2.3

Test vkládání informací různého druhu

Při tomto testu se zaměříme na manuální vkládání informací uživatelem. Průběh testu bude následující. Uživatel se přihlásí, založí novou e-mailovou adresu a jednu místní adresu. Test je nastaven na tři uživatele, protože vypisování informací zabere nějaký čas. Aby byl test co nejvíce autentický, nastavila jsem dobu opakování po jedné minut. Test proběhne ve třech cyklech (třikrát se uživatel přihlásí), s pěti opakovanými vloženími jednoho emailu a jedné adresy. Výsledkem je tabulka 5.3, na které mě zaujala maximální odezva uložení adresy sedum sekund. To je nestandardní vzhledem k průmětu 459 milisekund. Z dalších testů bychom se mohli dozvědět, zda jde o unikátní průběh testu. Tabulka 5.3: Tabulka naměřených hodnot ukládání pro 3 uživatele Název přihlášení nový email uložení emailu nová adresa uložení adresy

Počet dotazů 9 45 45 45 45

Průměr 31 37 295 34 459

Střed 29 36 286 32 280

90% 34 50 345 44 390

Min 19 25 235 23 231

Max 73 66 412 67 7550

Procento chybovosti 0.0 0.0 0.0 0.0 0.0

36


Obrázek 5.2: Graf průměrné odezvy systému pro ukládání 3 uživatelů zároveň

Druhým průběhem testu se pokusíme zjistit, co aplikaci vytěžuje více, jestli více uživatelů přistupujících do aplikace nebo počet zápisů. V tabulce 5.4 vidíme výsledky testu s jedinou změnou oproti původnímu a to je deset uživatelů s přístupem po dvaceti sekundách. Ukládání informací se nám protáhlo v průměru až na celou jednu sekundu, ale díky tomuto testu můžeme zhodnotit nestandardní maximální dobu ukládání z prvního testu, šlo tedy pouze o náhodu. V tomto testu má maximální odezva ukládání jen dvě sekundy.

Tabulka 5.4: Tabulka naměřených hodnot ukládání pro 10 uživatelů Název přihlášení nový email uložení emailu nová adresa uložení adresy

Počet dotazů 30 150 150 150 150

Průměr 123 128 1057 124 1109

Střed 75 104 1018 100 1117

90% 266 234 1586 271 1664

Min 32 25 293 25 281

Max 532 462 2911 539 2559

Procento chybovosti 0.0 0.0 0.0 0.0 0.0

Abychom mohli odpovědět na původní otázku, co bude aplikaci zpomalovat více, jestli větší počet uživatelů nebo počet opakujících se akcí, spustíme další test. Počet uživatelů jsme opět snížili na tři, celý testovací plán se bude opakovat desetkrát a provedeme dvacet ukládacích cyklů. Výsledky tohoto testu vidíme v tabulce 5.5, celkový počet dotazů.

Tabulka 5.5: Tabulka naměřených hodnot ukládání 1200 položek pro 3 uživatele Název přihlášení nový email uložit email nová adresa uložit adresu Celkem

Počet dotazů 30 600 600 600 600 2430

Průměr 43 65 509 64 516 286

Střed 40 60 492 60 490 137

90% 70 97 632 97 650 573

Min 17 24 210 23 210 17

Max 88 574 1849 182 1806 1849

Procento chybovosti 0.0 0.0 0.0 0.0 0.0 0.0


37

Obrázek 5.3: Graf průměrné odezvy při ukládání deseti uživateli

Obrázek 5.4: Graf průměrné odezvy při ukládání 1200 položek třemi uživateli

5.2.4

Výsledky testování

Výsledná čísla v tabulkách byla zaokrouhlena na dvě desetinná místa. Zhodnocení této skupiny testů nám odpoví na původní otázku: nárůst odezvy hlavně při ukládání se zvýšil skoro o polovinu při nárůstu uživatelů. Aplikace tedy nabízí lepší prostředí pro více zápisů s menším počtem uživatelů. Ze sloupce s hodnotami chybovosti lze usoudit, že zadávání dat je 100% bezchybné.

38

5.2.5


Zátěžový test vyhledávání podle počtu uživatelů

Další zátěžové testy aplikace nám názorněji ukážou vliv využívání aplikace více uživateli najednou. Z testů programu JMeter dostanu výstupy v podobě výše uvedených tabulek. Tyto výsledky následně zanesu do spojnicového grafu, ze kterého lze snadno vyčíst vliv více uživatelů na rychlost odezvy aplikace. První graf znázorňuje vliv počtu uživatelů na odezvu systému v úloze fulltextového vyhledávání v databázi záznamů. Databáze byla pro tento účel naplněna testovacími daty. Úloha testu je přihlášení uživatele a vyhledání existujících a neexistujících hodnot. Do grafu na obrázku 5.5 byly zahrnuty pouze časy odezvy na vyhledávání existující hodnoty, tedy jak dlouho aplikaci trvalo nalézt existující informaci v databázi a prezentovat ji uživateli. V grafu je znázorněna minimální, průměrná a maximální hodnota odezvy pro různé počty uživatelů.

Obrázek 5.5: Graf průměrné odezvy při vyhledávání existující informace

Z grafu vyplývá, že vyhledávání aplikace je navrženo pro maximálně deset uživatelů, kde dosahuje maximum odezvy do 2,5 sekundy, avšak při zatížení více uživateli posílajícími dotazy po jedné sekundě se odezva rychle zvyšuje. Pro zrychlení vyhledávání při větším počtu uživatel by bylo nutné nad tabulkami, ve kterých probíhá vyhledávání, vytvořit pohled a v tomto pohledu poté vyhledávat data.

5.2.6

Zátěžový test ukládání informací podle počtu uživatelů

Provedla jsem ještě jeden podobný test zátěže, ale tentokrát pro počet uživatelů přidávajících data do aplikace. Počty uživatelů jsem zvýšila na maximum dvaceti učivatelů, doba posílání dotazů byla pět sekund, a cyklus přidávání e-mailu a adresy se opakoval dva krát. Graf v obrázku 5.6 nám znázorňuje nárust času odezvy při zvyšování počtu uživatelů, při ukládání e-mailové adresy. Z grafu jasně vyplývá že nárust uživatelů bude zvyšovat i dobu odezvy, avšak průměrná a minimální hodnota odezvy je optimální. Pokládám tedy test za úspěšný, jelikož z testu vyplývá, že aplikace zvládne práci dvojnásobného počtu uživatelů než na kolik byla dimenzována.


Obrázek 5.6: Graf průměrné odezvy při ukládání e-mailu

39

40


Kapitola 6

Závěr 6.1

Zhodnocení

Mohu jen doufat že má práce, tedy aplikace, kterou jsem navrhla a vypracovala, bude přínosem nejen pro NFPK a její pracovníky, ale i pro obecnou veřejnost a možná odhalení neférového jednání v této republice. Aplikace nejen nahradí archiv organizace, ale snad díky zrychlení činosti, jako jsou vyhledávání či zápis nově získaných údajů, přinese pracovníků zjednodušení jejich každodenní práce.

6.2

Pokračování práce

Pokračování a možnosti rozšíření práce budou pravděpodobně úprava systému podle připomínek zadavetele. Zatím není stanoveno datum nasazení do testovacího provozu, poté ale očekávám úpravy vzhledu a některých výpisů. Možné je i rozšíření vyhledávání na více položek a změna jejich výpisů. Současným omezením programu je to, že je nadimenzován pro nižší počet současně přihlášených uživatelů. Pro práci s větším množstvím uživatelů by byly nutné modifikace na úrovni databáze a konkrétních databázových dotazů. Rozšíření by mohlo mít například podobu zpracování elektronicky psaných článků, například z novin a jiných webových serverů. Tyto články by byly pracovníky NFPK vyhledány a do systému zadána jejich adresa. Díky předdefinovaným klíčovým slovům bychom mohly nalézt potřebné údaje a vytvořit z nich data pro uložení v naší databázi. Jako další změny bych navrhla převod informací z textové podoby do elektronické. Například pokud jsou dokumenty tištěné psané ručně, existují metody pro nascanování dokumentu a separování jednotlivých částí na příslušné objekty. To by mohlo být zdrojem pro vytváření objektů automaticky.

41

42

KAPITOLA 6. ZÁVĚR

Literatura [1] Teo Cerovski. Editable html select box script. [2] web:http://www.agiledata.org/. Mapping objects to relational databases. [3] web:http://www.hibernate.org/. Hibernate. [4] web:http://www.mysql.com/. Mysql. The world’s most popular open source database Contact a MySQL Representative. [5] web:http://www.springsource.com/developer/spring. The standard for enterprise java development. Enterprise Java Development Tools. [6] web:jmeter.apache.org/. Jmeter. [7] web:wwwinfo.mfcr.cz/. Administrativni registr ekonomickych subjektu.

43

44

LITERATURA

Příloha A

Seznam použitých zkratek NFPK Nadační fonr proti korupci ORM Objektově relační mapování OOP objektově orientované programování HQL hibernate query language SQL structured query language MySQL my structured query language JSP java server pages HTML hyper text markup language SPZ státní poznávací značka IČ identifikační číslo CD compact disk .. .

45

46

PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

Příloha B

UML diagramy

Obrázek B.1: Seznamy tříd balíčků classes, controller,dao a editor

47

48

PŘÍLOHA B. UML DIAGRAMY

Příloha C

Instalační a uživatelská příručka C.1

Instalační příručka

Před nasazením souboru s příponou .war na aplikační server musíme modifikovat soubory s nastavením. Vytvoříme si databázi s libovolným názvem, tento název a přístupové údaje vepíšeme do souboru data-config.xml Property s názvem driverClassName jejíž hodnota bude obsahovat cestu k balíčku driveru podle typu naší databáze. Property username a password bude odpovídat našemu přístupu do databaze. Url databáze bude obsahovat název databáze „protikorupcnidb“ lze zaměnit za název databáze. V další sekci bean v souboru dokomentujeme řádek <prop key="hibernate.hbm2ddl.auto»create pro vytvoření databázových tabulek. Po prvním spuštění je nutné řádek zakomentovat nebo smazat, aby se databáze nevytvářela opakovaně. <property name="driverClassName" value="com.mysql.jdbc.Driver" /> <property name="username" value="root" /> <property name="password" value="" /> <property name="url" value="jdbc:mysql://localhost:3306/protikorupcnidb?characterEncoding=UTF-8" /> <property name="dataSource" ref="dataSource" /> <property name="jpaVendorAdapter" ref="jpaVendorAdapter" /> <property name="jpaProperties"> <props> <prop key="hibernate.hbm2ddl.auto">create <prop key="hibernate.max\_fetch\_depth">2

Obrázek C.1: Obsah souboru data-config.xml

49

50

PŘÍLOHA C. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA

Poté již nasadíme vytvořený soubor war na aplikační server s cestou ProtikorupcniDB.

Příloha D

Obsah přiloženého CD

Obrázek D.1: Seznam přiloženého CD

51

Protikorupční databáze a aplikace. Šárka Buranská

Recommend Documents