eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·
Bakalá°ská práce
Serverová £ást pro sytém Elektronické Volby
Petr Hlavá£ek
Vedoucí práce:
Ing. Martin Komárek
Studijní program: Softwarové technologie a management, Bakalá°ský
Obor: Softwarové inºenýrství
25. kv¥tna 2012
iv
v
Pod¥kování Cht¥l bych pod¥kovat panu Ing. Martinu Komárkovi za ochotu p°i vedení mé práce, panu Tarantíkovi za spolupráci p°i vývoji a celé mé rodin¥ za podporu p°i studiu.
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 Praze dne 24. 5. 2012
.............................................................
viii
Abstract This work deals with the concept and implementation of the server part improvement for already existing electronic voting system from Tomas Cerevka. The new server part addidng to existing application function of user import from a registration system or from .csv les, furthermore it adding communication option with a terminal part and last but not least it has reworked data model to enabled above mentioned import and adding multiple roles to single user.
Abstrakt Tato práce se zabývá návrhem a implementací vylep²ení sererové £ásti jiº existujicího systému Elektronické Volby od Tomá²e erevky. Nová serverová £ást p°idává k existující aplikaci funk£nost importu uºivatel· z Registra£ního systému £i z .csv soubor·, dále moºnost komunikace s terminálovou £ásti a v neposlední °ad¥ má p°epracovaný datový model tak aby umoº¬oval vý²e zmín¥ný import a umoº¬oval p°i°azení více rolí jednomu uºivateli.
ix
x
Obsah 1 Úvod
1
2 Popis problému, specikace cíle
3
2.1
Popis problému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
Re²er²e
3
2.2.1
2.2.2 2.3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Typologie volebních systém·
. . . . . . . . . . . . . . . . . . . . . . .
4
2.2.1.1
V¥t²inové volební systémy . . . . . . . . . . . . . . . . . . . .
4
2.2.1.2
Propor£ní volební systémy
. . . . . . . . . . . . . . . . . . .
5
2.2.1.3
Smí²ené volební systémy
. . . . . . . . . . . . . . . . . . . .
6
2.2.1.4
Dal²í volební systémy
. . . . . . . . . . . . . . . . . . . . . .
6
Poºadavky na elektronické volby
Existující prototyp Elektronické volby 2.3.1
2.3.2
2.3.3
Základní popis prototypu
. . . . . . . . . . . . . . . . . . . . .
6
. . . . . . . . . . . . . . . . . . . . . .
7
. . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3.1.1
Multijazy£nost . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3.1.2
Struktura . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
Uºivatelské role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3.2.1
Administrátor
. . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3.2.2
Komisa° . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3.2.3
Voli£ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3.2.4
Kandidát . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
Doménový model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3 Analýza a návrh °e²ení 3.1
3.2
13
Poºadavky na aplikaci
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.1.1
Funk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.1.2
Nefunk£ní poºadavky:
. . . . . . . . . . . . . . . . . . . . . . . . . . .
14
P°ípady uºití a scéná°e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.2.1
P°ípady uºití 3.2.1.1
3.2.2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
Akté°i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
Scéná°e
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2.2.1
P°ihlásit
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2.2.2
Odhlásit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2.2.3
Prohlédnout výsledky
16
3.2.2.4
Upravit vlastní ú£et . . . . . . . . . . . . . . . . . . . . . . .
16
3.2.2.5
Import uºivatel· a akcí z registra£ního systému . . . . . . . .
16
xi
. . . . . . . . . . . . . . . . . . . . . .
xii
OBSAH
3.3
3.2.2.6
Správa voleb
3.2.2.7
Správa volebních akcí
. . . . . . . . . . . . . . . . . . . . . .
17
3.2.2.8
Správa volebních komisí . . . . . . . . . . . . . . . . . . . . .
17
3.2.2.9
Správa voli£· . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.2.2.10
Správa volebních událostí . . . . . . . . . . . . . . . . . . . .
18
3.2.2.11
Správa kandidát·
. . . . . . . . . . . . . . . . . . . . . . . .
18
3.2.2.12
Zahájit hlasování . . . . . . . . . . . . . . . . . . . . . . . . .
18
Doménový model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.3.1
Entita
3.3.2
Entita
3.3.3
Entita
3.3.4
Entita
3.3.5
Entita
3.3.6
Entita
3.3.7
Entita
3.3.8
Entita
3.3.9
Entita
Admin - Administrátor . . . . . . User - Uºivatel . . . . . . . . . . Action - Akce . . . . . . . . . . . Election -Volby . . . . . . . . . ElectionEvent - Volební událost ElectionTicekt - Volební lístek Option - Moºnost . . . . . . . . . Candidate - Kandidát . . . . . . Commission - Volební komise . . Additionals - Volitelné atributy
. . . . . . . . . . . . . . . . .
19
. . . . . . . . . . . . . . . . .
19
. . . . . . . . . . . . . . . . .
19
. . . . . . . . . . . . . . . . .
19
. . . . . . . . . . . . . . . . .
20
. . . . . . . . . . . . . . . . .
20
. . . . . . . . . . . . . . . . .
20
. . . . . . . . . . . . . . . . .
20 20
. . . . . . . . . . . . . . . . .
21
Pouºité technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.4.1
Technologie Java EE 6 . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.4.2
Datová vrstva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.4.2.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.4.3
Business vrstva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Databáze
22
3.4.4
Presenta£ní a aplika£ní vrstva . . . . . . . . . . . . . . . . . . . . . . .
22
3.4.5
Aplika£ní server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4 Realizace 4.1
4.2
4.3
4.4
17
. . . . . . . . . . . . . . . . .
3.3.10 Entita 3.4
. . . . . . . . . . . . . . . . . . . . . . . . . . .
25
První iterace
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.1.1
Cíl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.1.2
Postup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.1.3
Výstup
26
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Druhá iterace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.2.1
Cíl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.2.2
Postup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.2.3
Výstup
28
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
T°etí iterace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.3.1
Cíl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.3.2
Postup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.3.3
Výstup
28
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tvrtá iterace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.4.1
29
4.4.2
4.4.3
Cíl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Postup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.4.2.1
S£ítácí algoritmus
29
4.4.2.2
Propojení serverové £ásti s terminálovou . . . . . . . . . . . .
29
Výstup
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
. . . . . . . . . . . . . . . . . . . . . . . .
xiii
OBSAH
5 Testování 5.1
35
Testování algoritmu pro s£ítání hlas· . . . . . . . . . . . . . . . . . . . . . . .
35
5.1.1
36
Testování uºivatelem . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Záv¥r
37
A Seznam pouºitých zkratek
41
B UML diagramy
43
C Instala£ní a uºivatelská p°íru£ka
47
C.1
Pot°ebné programy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
C.2
Instalace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
C.3
C.2.1
Glasssh Server Edition 3.1.2
. . . . . . . . . . . . . . . . . . . . . . .
C.2.2
47
MySQL Server
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
C.2.3
Netbeans 7.1.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
Nastavení C.3.1
MySQL Server
C.3.2
Glasssh Server Open Source Edition 3.1.2
48
. . . . . . . . . . . . . . .
48
Security Realm . . . . . . . . . . . . . . . . . . . . . . . . . .
48
Spu²t¥ní . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
C.3.2.1 C.4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D Obsah p°iloºeného CD
51
xiv
OBSAH
Seznam obrázk· 2.1
Princip dvou obálek (pouºito ze droje [19]) . . . . . . . . . . . . . . . . . . . .
8
2.2
Doménový model prototypu . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.1
Rozloºení vrstvev v enterprise aplikaci (zdroj [2])
. . . . . . . . . . . . . . . .
23
4.1
Upravená £ást doménového modelu . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2
Pohled na upravenou £ást doménového modelu, po vy°e²ení problému s ukládáním mapy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.3
Diagram aktivit p°i s£ítání hlas· pomocí STV . . . . . . . . . . . . . . . . . .
32
4.4
Detail p°enosu hlas· zdola . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.5
Detail p°enosu hlas· shora . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
B.1
P°ípady uºití pro serverou £ást aplikace
. . . . . . . . . . . . . . . . . . . . .
44
B.2
P°ípady uºití pro terminálovou £ást aplikace . . . . . . . . . . . . . . . . . . .
45
B.3
Doménový model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
xv
xvi
SEZNAM OBRÁZK
Seznam tabulek 5.1
Rozloºení preferencí v jednolivých kolech s£ítání . . . . . . . . . . . . . . . . .
xvii
36
xviii
SEZNAM TABULEK
Kapitola 1
Úvod Volení £i hlasování provází £lov¥ka v mnoha podobách od nepam¥ti. A´ ²lo o volení v·dce sme£ky v prav¥ku, £i hlasování zákonodárc· ve sn¥movn¥ v sou£asnosti. Princip voleb je stále stejný, moºnost (£i kandidát) s nejvy²²ím po£tem hlas· v¥t²inou vyhrává, ale zp·sob, jakým se o vít¥zi hlasuje, se vyvíjí. A tak v dne²ní dob¥, dob¥ kdy v²ichni pospíchají a kaºdá u²et°ená vte°ina je drahocenná, a v dob¥, kdy nám vládnou po£íta£e ruku v ruce s internetem, se nabízí moºnost hlasovat £i volit elektronicky. Tato moºnost je velice lákavá, protoºe lidem umoº¬uje u²et°it jejich £as, usnad¬uje evidenci voli£·, umoº¬uje p°esné odhady pr·b¥ºných výsledk· a poskytuje výsledky tak°ka ihned po ukon£ení voleb. Jako kaºdá v¥c na sv¥t¥ má ov²em elektronické hlasování i mnoho nevýhod. Prakticky v²echny pokusy o implementaci elektronických voleb a jejich nasazení v reálném ºivot¥ se potýkají s mnoha problémy a ned·v¥rou uºivatel·. M·ºe být velmi t¥ºké p°esv¥d£it konzervativní voli£e o tom, ºe systém, p°es který odesílají hlasy, je skute£n¥ naprosto tajný, £i se v·bec rozhodnout o tom, jaký zp·sob voleb je ten správný. Mnozí odborníci se také domnívají, ºe elektronické volby (zejména pokud máme na mysli volby nap°íklad do parlamentu) mohou ovlivnit výsledky voleb v tom smyslu, ºe se do voleb více zapojí mladá generace lidí. Ta je jiº pln¥ sºita s moderní dobou a tak, protoºe se s ní setkává od narození, má v moderní techniku naprostou d·v¥ru [1]. Tato generace totiº k volbám v klasické podob¥ dnes p°íli² nechodí a její názory by mohly velmi výrazn¥ promluvit do kone£ných výsledk·. Proto se také mnoho politik· m·ºe elektronického zp·sobu voleb obávat. Pokusy implementovat elektronické volby byly prozatím provedeny v n¥kolika zemí (nap°íklad v Americe je moºnost volit elektronicky i prezidenta), v Evrop¥ dám za p°íklad Estonsko. V roce 2005 tam po dlouhých p°ípravách lidé poprvé volili v komunálních volbách pomocí internetu [19]. Estonsko, které je men²í neº eská republika, pochází z postsov¥tského bloku stejn¥ jako R a do EU vstoupilo ve stejném roce jako na²e zem¥, je p°íklad, ºe pokud se p°ípravy nepodcení, elektronické hlasování a volby jsou reálné. I v eské republice se o tomto zp·sobu voleb za£íná mluvit (viz. [1] nebo [9]), ov²em v na²em prost°edí a p°i sou£asné legislativ¥ je to zatím b¥h na dlouhou tra´.
1
2
KAPITOLA 1.
ÚVOD
Tato práce ov²em není zam¥°ena na tak komplexní problematiku jako jsou celostátní volby do parlamentu, senátu, £i volby komunální, ale v¥nuje se problematice n¥jakého lokálního, men²ího subjektu, který £as od £asu po°ádá sjezd £i mítink, v rámci n¥hoº se o n¥£em hlasuje. V takovéto podob¥ je prosazení elektronických voleb £i elektronického hlasování o n¥co snaz²í, a´ uº proto, ºe je pot°eba p°esv¥d£it men²í po£et lidí, nebo proto, ºe p°ípadná rizika nemají tak katastrofální dopad, jako zneuºití nap°íklad parlamentních voleb (coº ov²em neznamená, ºe tyto rizika mohou být podcen¥na). Toto téma není nové a v minulých ro£nících se na n¥m intenzivn¥ pracovalo. Moje práce p°ímo vychází z bakalá°ské práce Tomá²e erevky [18] a je zam¥°ena na napojení systému implementovaného panem erevkou na registra£ní £ást [16], která umoº¬uje vytvá°ení volebních akcí a ú£astník· pro samotný volební systém, který tyto vytvo°ené entity bude schopen importovat. Dále pak odstra¬uje chyby z p°edchozí verze (viz. kapitola Záv¥r [18]) a zejména pak p°idává schopnost komunikace s volebními terminály zpracovanými v rámci práce [20], coº je hlavní její hlavní cíl. Kapitola 2 obsahuje re²er²ní £ást, kde se teoreticky v¥nuji r·zným zp·sob·m hlasování a podobám voleb. Dále se v¥nuji nap°íklad moºnostem, jak zajistit tajnost hlasování a rozebírám r·zné podoby jiº existujících podob elektronických voleb. V dal²ích kapitolách se jiº v¥nuji samotné implementaci systému, od analýzy chyb p·vodního systému, p°es analýzu, návrh a implementaci vylep²ení aº po testování. Nakonec v záv¥ru hodnotím, jestli byly spln¥ny ve²keré poºadavky a rozebírám podn¥ty pro dal²í práci na systému.
Kapitola 2
Popis problému, specikace cíle 2.1
Popis problému
Jak uº bylo zmín¥no v úvodu práce, volby a hlasování je nedílná sou£ást na²í spole£nosti. M·ºeme se s nimi setkat v mnoha podobách prakticky kdekoliv a proto má smysl se touto tématikou zabývat. V dne²ní dob¥ je nejvíce roz²í°ený klasický typ voleb, kdy se hlasovací lístky vhazují do urny. Pro zaji²t¥ní tajnosti voleb se lístky vypl¬ují za plentou. Pokud jde o hlasování, tak to probíhá tak, ºe voli£i zvednou ruku a ty pak pov¥°ený £lov¥k se£te. Tyto zp·soby by mohly být nahrazeny elektronickou verzí hlasování a to je náplní mé práce. Aplikace Elektronické Volby je zam¥°ena na volby, které se konají v rámci n¥jaké akce a na kterou se sjedou ú£astníci. Nap°íklad valná hromada n¥jakého sportovního svazu, £i sjezd politické akce. To znamená, ºe volby nebudou probíhat z domova nap°íklad p°es internet, ale voli£i budou muset být na akci p°ítomni. V rámci jedné akce se pak m·ºe konat mnoho r·zných voleb £i hlasování. Kaºdé volby, které jsou spravovány ur£enou volební komisí, pak mohou mít více volebních událostí, coº mohou být nap°íklad jednotlivá kola voleb. Volby také mají, krom¥ komise, p°i°azeny oprávn¥né voli£e, kte°í mohou v rámci voleb hlasovat a moºnosti, kterým voli£i mohou dát hlas. Serverová £ást systému Elektronické volby má na starosti spojení s hlasovacími terminály [20], jejichº prost°ednictvím mohou voli£i hlasovat, import p°edvytvo°ených akcí z Registra£ního systému[16] a zaji²´uje ve²kerou administraci voleb. To znamená, ºe do systému pro serverovou £ást budou mít p°ístup komisa°i a administráto°i voleb, kdeºto voli£i budou mít p°ístup pouze do systému volebních terminál·.
2.2
Re²er²e
V re²er²ní £ásti práce se v¥nuji popisu r·zných zp·sob· voleb, které se na sv¥t¥ vyskytují, rozebírám r·zné pokusy o implementování elektronických voleb u nás £i ve sv¥t¥ a popisuju zp·soby jak zajistit tajnost hlasování. Dále je v této kapitole také popis prototypu systému, ze kterého jsem vycházel.
3
4
KAPITOLA 2.
POPIS PROBLÉMU, SPECIFIKACE CÍLE
2.2.1 Typologie volebních systém· Volební systémy (volební systém m·ºeme chápat jako soubor pravidel, podle kterých se volby konají), m·ºeme rozd¥lit na následující t°i základní typy: v¥t²inové volební systémy, propor£ní volební systémy a smí²ené volební systémy. Tyto typy se pak samoz°ejm¥ d¥lí je²t¥ na dal²í podkategorie. V následujícím textu budou tyto typy a podkategorie podrobn¥ rozebrány a pokud není uvedeno jinak, zdrojem je internetový £lánek [15]. Sám autor v £lánku uvádí, ºe neexistuje ºádné jasn¥ dané rozd¥lení topologií, proto tyty popsané kategorie nejsou jediné správné a je moºné, ºe se £tená° v jiné literatu°e m·ºe setkat s jiným rozd¥lením. Dal²ími d·leºitými faktory pro výsledky voleb jsou krom¥ vý²e zmín¥ného rozd¥lení i nap°íklad zp·sob jakým se s£ítají hlasy (jestli se hlasy nap°íklad p°epo£ítávají podle mandát·), velikost volebního obvodu nebo existence kompenza£ních mandát· [8].
2.2.1.1 V¥t²inové volební systémy V¥t²inové volební systémy se dále d¥lí na dal²í 3 podtypy podle toho, jak je daná v¥t²ina brána. V prvním podtypu, v
systému prosté v¥t²iny (plurality
system ), se vít¥zem voleb
stává kandidát, který získal více hlas· neº jakýkoliv jiný kandidát. Tento systém je historicky nejstar²í, ale dnes uº není tak roz²í°en (pouºívá se hlavn¥ v zemích bývalého britského impéria). V p°ípad¥, ºe se konají volby tohoto typu, je to nej£ast¥ji v jednomandátových obvodech. Pokud se kombinují s vícemandátovými obvody, d¥lí se na dal²í podtypy podle toho, kolik má voli£ hlas· (nap°. blokové hlasování, kdy voli£ má tolik hlas·, kolik je mandát·). Více viz [15]. Dal²ím typem spadajícím do v¥t²inových volebních systém·, je
²iny
systém absolutní v¥t-
(majority system ). V tomto systému se vít¥zem stane kandidát, který získá absolutní
v¥t²inu hlas·, tedy 50 % + 1 hlas. Tento systém je nej£ast¥ji pouºíván u jednomandátových obvod· a je kombinován s tzv. dvoukolovým hlasováním (pokud v prvním kole ºádný kandidát nezíská poºadovanou absolutní v¥t²inu, p°ichází na °adu kolo druhé). Druhé kolo voleb je pak bu¤ otev°ené, nebo uzav°ené. Pokud je uzav°ené tak do n¥j postupují pouze první dva kandidáti z prvního kola. Poté je zaru£eno, ºe alespo¬ jeden kandidát získá absolutní v¥t²inu. Pokud je kolo otev°ené, pak kandidát·m k vít¥zství sta£í pouze prostá v¥t²ina (viz vý²e). Tento volební systém se v praxi nej£ast¥ji vyskytuje v souvislosti s prezidentskými volbami. Posledním podtypem v¥t²inových volebních systém· je tzv.
alternativní hlasování (al-
ternative vote ). Systém je zna£n¥ sloºitý a je zaloºen na ozna£ování kandidát· £ísly podle preferencí voli£e. Voli£ m·ºe ud¥lit bu¤ jednu preferenci (nejpodporovan¥j²í kandidát), nebo tolik preferencí kolik je kandidát· (u t°í kandidát· dá voli£ £íslo 1 nejpreferovan¥j²ímu kandidátovi, 2 prost°ednímu a 3 nejmén¥ sympatickému kandidátovi). Vít¥zem se stane kandidát, který v daném volebním obvodu získá absolutní v¥t²inu hlas·. S£ítání probíhá tak, ºe se nejprve se£tou první reference. Pokud ºádný kandidát nemá absolutní v¥t²inu, vy°adí se poslední a jeho hlasy jsou p°erozd¥leny ostatním kandidát·m podle po£tu druhých preferencí (tedy nejvíce prvních preferencí od vy°azeného kandidáta získá kandidát, kterému voli£i dali nejvíce druhých preferencí) a op¥t se hlasy se£tou. Takto se pokra£uje, dokud n¥jaký kandidát nezíská poºadovanou absolutní v¥t²inu.
2.2.
5
REERE
Tento systém pom¥rn¥ solidn¥ zohled¬uje politické názory voli£· a £asto se proto stává, ºe nezvít¥zí kandidát, který m¥l nejvíce prvních preferencí v prvním kole s£ítání. Je to dáno tím, ºe takový to kandidát bývá totiº velmi kontroverzní (pro jednu £ást voli£· je to jasná
jedni£ka , ale pro dal²í, v¥t²inou pro ty z opa£ného politického spektra, je to nesch·dná trojka . Zvít¥zí tak kandidát, který je sch·dný pro v²echny politické názory. Tento zp·sob voleb bývá ozna£ován jako australský volební systém (více o n¥m v [3]).
2.2.1.2 Propor£ní volební systémy Propor£ní systémy (proprotional system ) jsou mlad²í neº v¥t²inové volební systémy a dnes jsou z°ejm¥ nejpouºívan¥j²í. Základní rys t¥chto systému je, ºe získané mandáty jsou p°erozd¥lovány podle po£tu hlas·. Propor£ní systémy tedy mají za cíl zajistit jakousi rovnováhu mezi hlasy a mandáty, tedy aby po£et obdrºených hlas· procentuáln¥ odpovídal po£tu získaných mandát·. V praxi se ov²em tento cíl nedá zcela dokonale realizovat. Propor£ní volební systémy se vyzna£ují n¥kolika charakteristickými vlastnostmi. Nap°íklad jsou vºdy pouºity v rámci vícemandátových voleb (do voleného subjektu se dostane více kandidát·), pro získání výsledk· se pouºívají matematické metody pro p°epo£et hlas· na mandáty, a ºe pro získání mandátu je zapot°ebí p°ekonat ur£itou procentuální hranici obdrºených hlas· (tzv. práh, nap°íklad ve volbách do Poslanecké sn¥movny eské Republiky musí strana získat minimáln¥ 5% hlas·). Propor£ní systémy mají více varianty, které se od sebe li²í zp·sobem p°epo£tu hlas· na mandáty. První variantou je
metoda volebního d¥litele,
jejíº princip spo£ívá v d¥lení po£tu
získaných hlas· (jejichº po£et p°ekra£uje práh) °adou d¥litel· aº do doby, kdy lze ze získaných výsledk· uspo°ádat tolik nejv¥t²ích £ísel, kolik lze získat mandát·. Mandáty jsou tedy p°id¥lovány podle velikosti podíl· získaných z d¥lení a to tak, ºe ºádná strana nem·ºe získat mandát d°íve neºli strana, která má více obdrºených hlas·. Tato metoda má n¥kolik druh·, které se li²í £íselnou °adou d¥litel·. V eské Republice je od roku 1990 pouºívána d'Hondtova metoda, která pouºívá d¥litele 1, 2, 3 a 4 [7]. Dal²í variantou je
metoda volebních kvót,
která je je²t¥ sloºit¥j²í neºli metoda vo-
lebních d¥litel·. Pro výpo£et se nejprve zjistí tzv. volební £íslo, které odpovídá po£tu hlas· nutných k získání mandát· (na výpo£et volebních £ísel se pouºívá n¥kolik metod). Dále je toto £íslo d¥leno po£tem odevzdaných hlas· v daném obvod¥, £ímº je získán po£et mandát· p°ipadající jednotlivým stranám. Pokud se nepoda°í takto rozd¥lit v²echny mandáty, je nutno na zbylých mandátech opakovat tento postup znovu. Pro toto dorozd¥lení se pak pouºívá bu¤ metoda nejv¥t²ího pr·m¥ru nebo metoda nejv¥t²ího zbytku. Tyto zp·soby pat°í do tzv.
klasických propor£ních volebních systém·. systém jednoho p°enosného hlasu,
por£ních volebních systém· ale je²t¥ pat°í
Do prokterý se
pouºívá ve vícemandátových obvodech, kde voli£i hlasují pro jednotlivé kandidáty, kte°í jsou uvedeny na volebním lístku v abecedním po°adí. Tyto kandidáty pak voli£ ozna£uje £ísly podle preference (1 nejoblíben¥j²í, dal²í má 2 atd.). Voli£ nemá ur£eno, kolik £ísel m·ºe pouºít, ale kaºdé musí být uvedeno pouze jednou. Po odevzdání hlas· se ur£í kvóta, která je nutná pro zvolení (tzv. Droopova kvóta ). Ta se spo£ítá jako podíl po£tu odevzdaných hlas· k po£tu volených mandát· plus jedna. Tento výsledek je pak zbaven desetinné £ásti a je k n¥mu p°i£tena jedna.
6
KAPITOLA 2.
POPIS PROBLÉMU, SPECIFIKACE CÍLE
P°i s£ítání hlas· se nejprve se£tou nejvy²²í preference (tedy 1) a ti kandidáti, kte°í p°esáhnou kvótu, jsou zvoleni, ale podle toho o kolik kandidát p°esáhl kvótu, jsou jeho hlasy je²t¥ rozd¥leny podle po£tu druhých preferencí. V dal²ím s£ítání je pak vy°azen poslední kandidát (m·ºe být vy°azen i kandidát na p°edposledním míst¥, pokud má v¥t²í ztrátu neº kolik má poslední kandidát preferencí) a jeho hlasy jsou op¥t p°erozd¥leny podle po£tu druhých preferencí a tyto hlasy jsou po£ítány jako první preference. Poté se op¥t hlasy se£tou a zjistí se, jestli n¥kdo nep°esáhl kvótu pro zvolení.
2.2.1.3 Smí²ené volební systémy Tyto volební systémy kombinují p°ede²lé dva zp·soby voleb, tedy v¥t²inový a propor£ní systém. Podle druhu vzájemné vazby mezi t¥mito dv¥ma sloºkami se smí²ené volební systémy d¥lí na
systémy závislé kombinace nebo nezávislé kombinace. V kaºdých volbách kona-
ných tímto zp·sobem musí být dop°edu ur£en po£et mandát· volených propor£ním zp·sobem a po£et mandát· volených v¥t²inovým zp·sobem. Tento pom¥r, nap°íklad 75% - 25%., by se m¥l li²it alespo¬ o 5%
1 . P°edem také musí být dáno, zda m·ºe kandidát gurovat v obou
sloºkách sou£asn¥. Voli£ zde má v¥t²inou 2 hlasy pro kaºdou sloºku zvlá²´ (ale ne vºdy). Smí²ené volební systémy jak závislé kombinace, tak nezávislé kombinace se dále d¥lí na n¥kolik podtyp· a ani p°es jejich velké roz²i°ování na konci 20. století, nepat°í mezi nejpouºívan¥j²í systémy. Jsou pom¥rn¥ sloºité na vysv¥tlení a pochopení, proto £tená°i doporu£uji spí²e £erpat z odborné literatury £i £lánku (nap°. [10]).
2.2.1.4 Dal²í volební systémy Vzhledem k tomu, ºe v kaºdé zemi jsou na volby kladeny £asto zcela zásadn¥ odli²né poºadavky, postupn¥ se na sv¥t¥ vyvinulo mnoho r·zných volebních systém·. Mezi n¥ na-
binominální volební systém pouºívaný v Chille nebo systém sdruºených kandidátních listin pouºívaný ve Francii v letech 1951 a 1956. To jsou ale pouze p°íklady,
p°íklad pat°í
protoºe specických volebních systém· existuje daleko více.
2.2.2 Poºadavky na elektronické volby Jelikoº je tajnost hlasování v mnoha p°ípadech velmi d·leºitá a pro mnoho lidí je to záruka demokrati£nosti voleb, jsou na elektronické volby kladeny ur£ité poºadavky, které, pokud budou spln¥ny, zaru£í, ºe volby prob¥hnou korektn¥, tajn¥ a ºe nebudou ovlivnitelné. Tyto poºadavky budou v této kapitole shrnuty. Podle [6], je d·v¥ryhodnost tajných voleb zaloºena na následujících p°edpokladech:
1
•
v²ichni oprávn¥ní voli£i mají moºnost uplatnit sv·j hlas
•
v²echny hlasy budou zapo£teny tak jak je uplatnili voli£i,
•
není moºné vloºit dodate£né hlasy nebo hlasovat vícekrát,
Toto £íslo není pevn¥ stanoveno, jedná se pouze o n¥jakou v²eobecn¥ dodrºovanou dohodu
2.3.
7
EXISTUJÍCÍ PROTOTYP ELEKTRONICKÉ VOLBY
•
volba je tajná a není moºné efektivn¥ dohledat, jak který voli£ hlasoval. (nap°. kv·li vydírání £i kupování hlas·)
V praxi by se tyto poºadavky mohli realizovat zejména pomocí kryptograe. Pro spln¥ní prvního a t°etího bodu by kaºdý voli£ obdrºel od organizátora voleb klí£ (token), který by reprezentoval volební oprávn¥ní. Token musí být jedine£ný a musí být distribuován n¥kým nezávislým, ale n¥kým kdo má p°íslu²né oprávn¥ní. Token pak musí umoº¬ovat ov¥°ení, ºe jej vystavila práv¥ ona kvalikovaná certika£ní autorita. Distribuce token· by m¥la probíhat tak, aby nebylo moºné zjistit, komu daný token náleºí. Certika£ní autorita by m¥la informaci o tom, ºe si daný voli£ jiº vyzvedl token, ale vzhledem k tomu, ºe nekontroluje pr·b¥h voleb, nemá ºádnou informaci o tom, jestli jiº byl token pouºit (navíc nemá záznam komu, byl token vydán). Volební komise pak má zase pouze záznam o tom jaký token byl pouºit (protoºe, kaºdý hlas musí obsahovat token, kterým se potvrdí, ºe voli£ je oprávn¥ný volit). Tyto poºadavky se ov²em li²í zdroj od zdroje a také se r·zní v závislosti na tom, jaké volby chceme elektronickým systémem realizovat. Nap°íklad elektronické volby v Estonsku [19] nespl¬ují poºadavek obsahující nemoºnost vícenásobného hlasování
2 . To aby mohl ú£astník
voleb sv·j hlas opravit, v Estonsku prosadily ze dvou d·vod·. Prvním je eliminace kup£ení s hlasy. Pokud existuje moºnost, ºe voli£ m·ºe do ukon£ení hlasování sv·j hlas zm¥nit, nese moºnost úplatku riziko, ºe voli£ poté co pod dohledem ode²le
zaplacený hlas , m·ºe poté kdykoliv sv·j hlas zm¥nit. Dal²ím d·vodem (velmi podobným) je omezení hlasování pod nátlakem. Pokud ov²em voli£ m·ºe zm¥nit sv·j hlas, nastává problém se zaji²t¥ním tajnosti hlasování, protoºe hlas musí být n¥jak svázán s voli£em, aby se zapo£ítal pouze jeho poslední hlas. V Estonsku je to realizováno pomocí systému tzv. dvou obálek. Tento princip spo£ívá v tom, ºe voli£ sv·j hlas za²ifruje ve°ejným klí£em voleb. P°i odesílání pak je²t¥ systém vyºaduje potvrzení podepsáním elektronickým podpisem voli£e. Tím se zabalí za²ifrovaný hlas do vn¥j²í obálky. P°i s£ítání hlas· se pak vezme pouze obálka , která byla odeslána jako poslední, vyjme se z ní vnit°ní obálka , která obsahuje za²ifrovaný a hlas a zahodí se. Hlasy se s£ítají aº poté co jsou v²echny obálky rozbaleny. Gracké znázorn¥ní obráku m·ºeme vid¥t na obrázku 2.1. Zp·sob umoº¬ující opakované hlasování by m¥l být pouºíván, pokud se hlasuje mimo místa k tomu ur£ené (nap°íklad pokud se m·ºe hlasovat z domu), protoºe zde existuje riziko hlasování pod nátlakem. V p°ípad¥ kdy se hlasuje pouze z ur£ených míst (nap°íklad z volebních terminál· jako v p°ípad¥ aplikace o které pojednává tato práce) toto riziko p°íli² nehrozí, proto zde moºnost opakovaného hlasování není tak podstatná.
2.3
Existující prototyp Elektronické volby
Jak jiº bylo °e£eno v úvodu, moje práce navazuje na projekt Elektronické volby, které zpracoval Tomá² erevka v rámci své bakalá°ské práce [18]. V této £ásti bude tento prototyp re²er²n¥ zpracován.
P°i prosazování zákona o elektronických volbách, práv¥ kv·li tomu, ºe voli£ m·ºe sv·j hlas opakovan¥ m¥nit, zákon vetoval estonský prezident, protoºe to podle n¥j poru²uje princip rovných voleb 2
8
KAPITOLA 2.
POPIS PROBLÉMU, SPECIFIKACE CÍLE
Obrázek 2.1: Princip dvou obálek (pouºito ze droje [19])
2.3.1 Základní popis prototypu Aplikace je kompletn¥ napsaná v Java EE a b¥ºí na serveru GlassFish v3. I kdyº autor v práci popisuje, ºe hlasovat se bude pomocí volebních terminál·, tato £ást nakonec nebyla implementována. Aplikace umoº¬uje vykonání tajného hlasování u personálních £i nepersonálních voleb a to i vícekolových. Autor nikde neuvádí jaký volební systém je implementován, ale z testování odhaduji, ºe to je systém prosté v¥t²iny. Samotné volby probíhají tak, ºe nejprve se musí vytvo°it seznam osob, které jsou oprávn¥ny se do systému zaregistrovat. Poté se voli£i, kte°í jsou v seznamu osob, dostaví k terminálu, kde jim bude sejmut otisk prstu a následn¥ se jim vygeneruje p°ístupový PIN kód, který má slouºit jako druhotné ov¥°ení voli£e, £ímº se eliminuje chyba £te£ky prst·. Poté co je vytvo°en seznam osob, musí administrátor zaloºit volby. K n¥mu pak je²t¥ administrátor deleguje volební komisi, která bude volby spravovat. Volební komise je sloºena z komisa°·, kte°í musí být zaregistrování v systému, protoºe se budou do aplikace p°ihla²ovat. Komisa° m·ºe být, ale nemusí, zaregistrován také jako voli£. Pokud je volební komise sloºená z více komisa°· (volební komisi totiº m·ºe tvo°it pouze jeden komisa°), p°íkaz k zahajování £i ukon£ování jednotlivých fází voleb musí dát nadpolovi£ní v¥t²ina komisa°·. Po vytvo°ení voleb jiº nad volbami p°ebírá kontrolu práv¥ volební komise. Ta musí pro zahájení voleb nejprve zaloºit volební událost. Ty mají reprezentovat jednotlivá kola voleb. Následuje bu¤ nominace kandidát· voli£i (pokud jsou volby personální) nebo u nepersonálních voleb komisa° nadenuje seznam moºností. Poté komise zahájí hlasování. Pokud probíhá nominace, tak voli£ m·ºe nominovat kandidáta z °ad zaregistrovaných voli£·, £i z ru£n¥ vytvo°ených kandidát· komisa°em. Kandidát má kandidátní listinu, kde má sv·j volební program a fotograi. Kandidát m·ºe v systému tuto listinu upravovat £i svoji kandidaturu zru²it. Zru²it kandidaturu m·ºe také komisa°. Poslední fází voleb je hlasování a zve°ej¬ování výsledk·. K hlasování by m¥li voli£i pouºívat volební terminál (ale ten nebyl implementován, takºe se k hlasování pouºívá serverová
2.3.
9
EXISTUJÍCÍ PROTOTYP ELEKTRONICKÉ VOLBY
£ást), kde by se m¥li autentizovat pomocí otisku prstu a zadání PINu. Tam pak m·ºe voli£ editovat a odeslat sv·j hlasovací lístek. Po ukon£ení fáze hlasování komisí se se£tou výsledky.
2.3.1.1 Multijazy£nost V aplikace fungují v sou£asné dob¥ dv¥ jazykové mutace: e²tina a Angli£tina. Vzhledem k dobrému návrhu této funkce, kdy ve²keré popisky jsou od odd¥leny do zdrojového kódu a jsou uloºeny samostatn¥ v souboru
.properties,
není problém vytvo°it novou jazykovou
mutaci, protoºe sta£í p°eloºit pouze tento soubor do jiné °e£i.
2.3.1.2 Struktura Aplikace je v sou£asné dob¥ rozd¥lena do t°í EJB
3 modul· a jedné webové aplikace.
V²echny tyto £ásti jsou zabaliny do jedné enterprise aplikace, která se pak nasazuje na server. EJB moduly si mezi sebou odesílají POJO objekty, které jsou obsaºeny v externí knihovn¥
eVotingLibrary. Tyto objekty jsou CandidateDTO, která obsahuje entitu
nazývány jako data transfer object. Jsou zde t°ídy kandidát,
ElectionEventResultDTO,
která obsahuje
volební výsledy (je zde seznam kandidát· a k n¥mu odpovídající seznam s po£tem hlas·), dále t°ídu
VoteDTO,
která reprezentuje seznam volených kandidát·, t°ídu
reprezentuje seznam voleb k dané volební události a jako poslední je t°ída
VotesDTO, která VotingCardDTO
která reprezentuje volební lístek kandidáta se za²krtnutými kandidáty.
2.3.2 Uºivatelské role V prototypu se vyskytují £ty°i uºivatelské role: administrátor, kandidát, voli£, a komisa°. Tyto role mají p°ístup do systému, coº znamená, ºe mají své vlastní uºivatelské jméno a heslo, kterým se p°ihla²ují do aplikace. Tyto role také mají na volby vliv.
2.3.2.1 Administrátor Administrátor je nejvy²²í role v systému. Má právo vytvá°et voli£e a jejich seznamy, vytvá°et a editovat volby a také spravuje volební komisi a komisa°e, nejen voleb, které vytvo°il, ale v²eobecn¥ v celém systému. Tato role má tedy spí²e administra£ní práva a na samotný pr·b¥h jiº po zaloºení voleb nemá p°ímý vliv.
2.3.2.2 Komisa° Uºivatelská role komisa° má právo kompletn¥ spravovat jednotlivé volby. Komisa°i jsou vytvá°ení administrátory a jsou v rámci volebních komisí p°i°azovány k jednotlivým volbám. Pokud se komisa° k n¥jakým volbám p°i°azen má právo v rámci t¥chto voleb vytvá°et volební události, které reprezentují jednotlivá kola hlasování a zahajovat r·zné fáze voleb. 3
Je to modul Validator, Controller a Counter
10
KAPITOLA 2.
POPIS PROBLÉMU, SPECIFIKACE CÍLE
Komisa° má dále právo editovat seznam moºností £i kandidát·, o kterých budou voli£i hlasovat. To znamená, ºe komisa° m·ºe vytvá°et a mazat kandidáty, upravovat jejich kandidátní listiny a m·ºe kandidáta i nominovat. Komisa° má také právo být zárove¬ voli£, a tedy m·ºe p°ímo hlasovat ve volbách, které spravuje.
2.3.2.3 Voli£ Voli£ je vytvá°en administrátorem, p°i vytvá°ení seznamu oprávn¥ných osob. Pokud by byl implementován systém pro hlasovací terminály, nem¥l by voli£ moºnost se do serverové £ásti aplikace v·bec p°ihlásit, ale jelikoº je implementována práv¥ pouze £ást serverová, voli£ musí volit p°es webové rozhraní. Pokud je voli£ komisa°em p°i°azen k volební události, má moºnost po zahájení daných fází bu¤ nominovat kandidáta (pokud probíhají nominace) nebo odeslat hlas (pokud probíhá fáze hlasování). Voli£ má moºnost odeslat sv·j hlas pouze jednou, není tedy moºné pozd¥ji sv·j hlas upravit.
2.3.2.4 Kandidát Poslední uºivatelskou rolí je role kandidát. Kandidát je bu¤ vytvo°en komisa°em, nebo vzejde z oby£ejného voli£e, který je na daných volbách zaregistrován, nominací od jiného voli£e. V systému má kandidát moºnost upravit kandidátku nebo kandidaturu stáhnout, doku probíhá fáze nominování. Poté jiº m·ºe být kandidát pouze zvolen.
2.3.3 Doménový model Na obrázku 2.2 je doménový model prototypu. Myslím si, ºe je tento model zna£n¥ zejdnodu²ený, ale z toho d·vodu obsahuje nedostatky, kv·li kterým nemohly být spln¥ny n¥které poºadavky na aplikaci, ale které se pak v aplikaci pravd¥podobn¥ nevyskytují, protoºe skute£ný doménový model je mnohem obsáhlej²í. Zejména není moºné realizovat, aby m¥l jeden uºivatel více rolí. Na obrázku diagramu m·ºeme vid¥t, ºe entita atribut
Role.
V modelu je také není entita
Person
má práv¥ jeden
Person svázána s jinou entitou, tudíº to vypadá jako kdyby
tato entita, která podle autora reprezentuje uºivatelský ú£et nebyla pouºita v souvislosti s
Voter, Candidate a Commissioner. Tyto entity mají reprezentovat jednolivé role a vztahy k volbám - entita Election a k volebním událostem - entita ElectionEvent.
entitami jejich
Navíc zde podle m¥ chybí entita, která by reprezentovala uºivatelskou roli Administrator. Dále mi zde chybí n¥jaká entita, která by reprezentovala volební lístek a volební poloºku, kterou bude moci voli£ zvolit. Je zde sice kandidát
Candidate,
ale pokud autor tvrdí, ºe
volby budou moci být i nepersonální, tak to pouze pomocí role kandidáta nelze realizovat. Entita
Voter je zde asociována s entitou ElectionEvent, coº by znamenalo, ºe na kaºdou
volební událost se bude muset vytvá°et nový seznam voli£· a to i p°esto, ºe autor tvrdí, ºe seznam voli£· se vytvá°í pouze p°i zakládání voleb. Pro pokra£ování v práci na této aplikaci je tento datový model zna£n¥ nevhodný a je nutné jej zcela p°ed¥lat.
2.3.
EXISTUJÍCÍ PROTOTYP ELEKTRONICKÉ VOLBY
Obrázek 2.2: Doménový model prototypu
11
12
KAPITOLA 2.
POPIS PROBLÉMU, SPECIFIKACE CÍLE
Kapitola 3
Analýza a návrh °e²ení V této £ásti práce jsou popsány zm¥ny v p·vodních poºadavcích a p°ípadech uºitítí. Je zde také rozebírána zm¥na doménového modelu, který musel být kompletn¥ p°ed¥lán a jsou zde nastít¥ny návrhy °e²ení pro integraci aplikace s registra£ní £ástí a s terminálem.
3.1
Poºadavky na aplikaci
Základní poºadavky na aplikaci z·stávají v podstat¥ stejné jako v p°ípad¥ prototypu. Nefunk£ní poºadavky se nem¥nily v·bec, protoºe aplikace bude vyvíjena stejným programovacím jazyk a bude b¥ºet na stejných aplika£ních i databázových serverech. K funk£ním poºadavk·m je pot°eba p°idat poºadavek na komunikaci s terminálovým klientem a s registra£ní £ástí.
3.1.1 Funk£ní poºadavky 1
Níºe jsou vypsány poºadavky na to co by m¥la aplikace uºivatel·m umoº¬ovat . Systém bude umoº¬ovat: 1.
import uºivatel· a akcí z registra£ní £ásti,
2.
komunikaci s volebními terminály
3.
zakládání volebních akcí a vytvá°ení uºivatel· ru£n¥,
4.
zaloºení vzorové komise pro kaºdou akci,
5. zaloºení voleb a volebních akcích, 6. konání personálních i nepersonálních voleb 7.
vloºení kandidatury ve formátu .pdf £i .doc,
8. nominování kandidát· komisí, 1
tu£n¥ jsou vyzna£eny ty poºadavky, které jsou p°idány nov¥
13
14
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
9. tajnou volbu nominovaných kandidát·, 10. zve°ejn¥ní výsledk· voleb, 11.
p°i°azení více rolí jednomu uºivateli.
Oproti p·vodním poºadavk·m vypadla moºnost nominování kandidát· z °ad voli£·. Kandidáta nyní bude moci vytvo°it a nominovat pouze komisa°. Dále je zde p°idán poºadavek na vzorovou komisi, která se bude vytvá°et vºdy p°i zaloºení volební akce a v²echny ostatní
2
komise budou od této vzorové odvozeny . Poºadavek na komunikaci s volebními terminály p°es zabezpe£ené spojení jiº byl zmín¥n, stejn¥ jako import z registra£ní £ásti. Z té se budou importovat volební akce a uºivatelé, ale obojí se také bude dát vytvá°et i ru£n¥ p°ímo v aplikaci (poºadavek 3). Poºadavek 7 umoº¬uje p°idat ke kaºdému kandidátovi soubor, ve kterém bude nap°íklad jeho ºivotopis, volební program nebo fotograe.
3.1.2 Nefunk£ní poºadavky: Systém bude: 1. v lokálních volbách nasazen na jednom serveru, 2. umoº¬ovat jednoduché a rychlé nasazení, 3. komunikovat s volebními terminály p°es HTTPS, 4. fungovat pouze na lokální síti. Tyto poºadavky jsou prakticky stejné jako v prototypu. První poºadavek znamená, ºe p°i volbách bude v²echno centralizované jen na jednom serveru. V²echny hlasy budou chodit práv¥ na n¥j, tudíº se minimalizuje riziko ovlivn¥ní voleb. Poºadavek na komunikaci s volebními terminály p°es HTTPS je vzne²en kv·li bezpe£nosti, stejn¥ tak poslední poºadavek, který zaru£uje, ºe se do systému nebude moci nikdo nabourat z ven£í.
3.2
P°ípady uºití a scéná°e
3.2.1 P°ípady uºití P°ípady uºití
3 (obrázek B.1) jsou op¥t v zásad¥ stejné jako v prototypu, jen byly upra-
veny tak, aby umoºnily spln¥ní v²ech poºadavk·. Ze systému byla odstran¥na role kandidát, protoºe ten nebude mít do systému p°ístup. V²echny akce spojené s kandidátem te¤ p°ebírá komisa° (vytvo°ení kandidáta, nominace, upravení popisu kandidatury a zru²ení kandidatury). Vzhledem k tomu, ºe se tato práce zabývá pouze serverou £ástí systém·, tak z p°ípad· uºití vypadla i role voli£e, protoºe ta se systémem komunikuje výhradn¥ p°es volební terminály. P°ípady uºití pro voli£e m·ºete vid¥t na obrázku
?? v p°íloze B
P°i vytvá°ení nové komise se nejprve p°i°adí komisa°i, kte°í jsou ve vzorové komisi a poté se budou moci p°idávat a ubírat jiní, takºe to neznamená, ºe v²echny komise budou stejné. 3 P°ípad uºití neboli use case. Use case model je primárn¥ ur£en k denici chování systému, aniº by odhaloval jeho vnit°ní strukturu [5] 2
3.2.
PÍPADY UITÍ A SCÉNÁE
15
3.2.1.1 Akté°i V této sekci budou vysv¥tleny v²ichni akté°i, kte°í se vyskytují na diagramu B.1. Aktér
Uºivatel
je zobecn¥ním pro role administrátor a komisa°, coº znamená, ºe v²echny funkce
které má uºivatel, mají i odvozené role. Uºivatel také reprezentuje nep°ihlá²eného uºivatele. Ú£astník
adatel o registraci
reprezentuje uºivatele, který chce poºádat o registraci
na n¥jaké volební akci. Na úvodní stránce aplikace m·ºe poºádat o registraci, kterou administrátor bu¤ schválí nebo ne. Tento postup je nutný absolvovat v p°ípad¥, ºe voli£ nebude importován p°es registra£ní systém. Dal²í akté°i
Administrátor a Kandidát se p°íli² nezm¥nily od p·vodních use cas·. Ad-
ministrátor je role, která spravuje volební akce, volby, uºivatle a volební komise, na samotný pr·b¥h voleb nemá vliv. Aktér komisa° spravuje pr·b¥h samotných voleb tím, ºe mu p°íslu²í evidence volebních událostí a správa kandidát·. Posledním aktérem je
as, který má jako moºnost ukon£ení a zahájení hlasování v rámci
volební akce.
3.2.2 Scéná°e V této kapitole budou vysv¥tleny n¥které podstatné p°ípady uºití, které jsou na obrázku B.1. Ke kaºdému popisovanému p°ípadu zde bude krátké vyv¥tlení co je jím my²leno a zárove¬ k n¥mu bude uveden scéná°.
3.2.2.1 P°ihlásit • Aktér: Uºivatel. • Popis:
Tento use case je ur£en pro nep°ihlá²eného uºivatele, který se chce dostat do
systému. Pokud je uºivatel p°ihlá²en není tato moºnost k dispozici.
• Scéná°: 1. Uºivatel spustí aplikaci. 2. Uºivatel klikne na úvodní stránce aplikace na tla£ítko p°ihlásit se. 3. Systém zobrazí p°ihla²ovací stránku pro zadání p°ihla²ovacího jména a hesla. 4. Uºivatel vyplní p°ihla²ovací údaje a poºádá systém o p°ihlá²ení. 5. Systém ov¥°í zadané údaje s údaji s databází a pokud se shodují p°ihlásí uºivatele. Pokud má uºivatel více rolí, dá mu na výb¥r jakou roli chce pouºít. 6.
ALTERNATIVA:
Pokud jsou údaje ²patn¥ zadané, systém zahlásí chybu a vrátí se
na krok 3.
3.2.2.2 Odhlásit • Aktér: Uºivatel. • Popis:
Use case se vyuºívá p°ihlá²eným uºivatelem v p°ípad¥, ºe se chce ze systému
odhlásti.
16
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
• Scéná°: 1. Uºivatel vybere z menu aplikace poloºku Odhlásit. 2. Systém poºádá uºivatele o potvrzení akce. 3. Pokud uºivatel akci potvrdí, systém uºivatele odhlásí. 4.
ALTERNATIVA:
Pokud uºivatel akci nepotvrdí tak systém neprovede nic.
3.2.2.3 Prohlédnout výsledky • Aktér: Uºivatel. • Popis:
Tuto moºnost bude mít kaºdý uºivatel, který se dostane na úvodní stránku
aplikace.
• Scéná°: 1. Uºivatel vybere z nabídky úvodní stránky poloºku výsledky voleb. 2. Systém zobrazí seznam akcí a voleb, ze kterých si bude moc uºivatel vybrat. 3. Uºivatel vybere dané volby a poºádá systém o zobrazení volebních výsledk·. 4. Systém zobrazí volební výsledky k vybraným volbám, pokud nejsou ºádné výsledky k dispozici, systém o tom uºivatele informuje hlá²kou.
3.2.2.4 Upravit vlastní ú£et • Aktér: Uºivatel. • Popis: Tuto moºnost bude mít kaºdý p°ihlá²ený uºivatel, který bude chtít upravit sv·j ú£et (zm¥nit heslo, login, jméno, adresu atd.).
• Scéná°: 1. Uºivatel vybere z menu upravit vlastní ú£et. 2. Systém zobrazí formulá° pro editaci vlastních údaj·. 3. Uºivatel provede editaci a poºdádá systém o uloºení zm¥n. 4. Systém provede validaci zm¥n a pokud je v²e v po°ádku uloºí zm¥ny. 5.
ALTERNATIVA:
Pokud systém p°i validaci zjistí chyby, vypí²e hlá²ku uºivateli,
neuloºí zm¥ny a vrátí se na krok 2.
3.2.2.5 Import uºivatel· a akcí z registra£ního systému • Aktér: Administrátor. • Popis:
Use case umoº¬uje administrátor·m importovat uºivatele a akce, jenº byly
vytvo°eny v rámci registra£ního systému.
• Scéná°:
3.2.
PÍPADY UITÍ A SCÉNÁE
17
1. Administrátor vybere z menu poloºku Import z registra£ního systému. 2. Systém se zjistí jestli je p°ipojen k n¥jakému registra£nímu systému a pokusí se zobrazi entity z databáze registra£ního systému. 3. Uºivatel si vybere jednu osobu pro schválení a poºádá systém o zobrazení detailu ºádosti. 4. Uºivatel si projde ºádost a podle svého uváºení ºádost schválí nebo ne. O své akci informuje systém stisknutím odpovídajícího tla£ítka. 5. Pokud uºivatel ºádost schválil, systém vytvo°í ºadateli ú£et a vygeneruje login a heslo. 6.
ALTERNATIVA:
Pokud uºivatel ºádost nechválil systém pokra£uje na krok
7. Systém ozna£í ºádost jako vy°ízenou a informuje ºadatele emailem o výsledku (pokud usp¥l ode²le mu i login s heslem).
3.2.2.6 Správa voleb • Aktér: Administrátor. • Popis:
Use case umoº¬uje administrátor·m evidenci voleb. K tomu se vzahují akce
jako vytvá°ení, mazání a editace voleb.
• Scéná°:
Není uveden.
3.2.2.7 Správa volebních akcí • Aktér: Administrátor. • Popis: Use case umoº¬uje administrátor·m evidenci volebních akcí. K tomu se vzahují akce jako vytvá°ení, mazání a editace akcí. V rámci akcí pak také administrátor m·ºe upravovat volby a uºivatele, kte°í se akcí ú£astní.
• Scéná°:
Není uveden.
3.2.2.8 Správa volebních komisí • Aktér: Administrátor. • Popis: Use case umoº¬uje administrátor·m evidenci volebních komisí. K tomu se vzahují akce jako vytvá°ení, mazání a editace akcí. V rámci akcí pak také administrátor m·ºe upravovat volby a uºivatele, kte°í se akcí ú£astní.
• Scéná°:
Není uveden.
18
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
3.2.2.9 Správa voli£· • Aktér: Administrátor, Komisa°. • Popis: Use case umoº¬uje administrátor·m evidenci voli£·, kte°í jsou zaregistrování v rámci akce, na kterou má admin práva. Komisa°·m tento use case umoº¬uje evidenci voli£·, kte°í se ú£astní voleb, které komisa° spravuje v rámci n¥jaké komise.
• Scéná°:
Není uveden.
3.2.2.10 Správa volebních událostí • Aktér: Komisa°. • Popis: Komisa° bude moci vytvá°et, mazat a upravovat volební události v rámci voleb, které spravuje v rámci n¥jaké komise.
• Scéná°: 1. Komisa° vybere z nabídky Zobrazit volby. 2. Systém komisa°i zobrazí volby, které má právo editovat. 3. Komisa° vybere poºadované volby a poºdádá systém o zobrazení detailu voleb. 4. Systém zobrazí detail voleb a umoºní uºivateli editaci volebních událostí, které se k volbám vztahují.
3.2.2.11 Správa kandidát· • Aktér: Komisa°. • Popis:
Komisa° bude moci vytvá°et, mazat a nominovat kandidáty na volby, které
spravuje v rámci n¥jaké komise.
• Scéná°:
Není uveden.
3.2.2.12 Zahájit hlasování • Aktér: Komisa°, as. • Popis:
Zahajovat hlasování bude primárn¥ provád¥t aktér
as.
P°i zakládání volební
události komisa° nastaví datum a £as zahájení hlasování. Pokud tento £as nastane, aktér
as
zahájí hlasování. Zahájit hlasování ale bude také moci provést nadpolovi£ní
v¥t²ina komisa°· z dané komise.
• Scéná°:
Není uveden.
3.3.
19
DOMÉNOVÝ MODEL
3.3
Doménový model
Doménový model B.3 pro²el zna£nými úpravami a to jak uº kv·li zmi¬ovaným chybám v doménovém modelu prototypu, tak kv·li p°idání dal²ích entit. V této kapitole bude vysv¥tlen význam v²echny entit a jejich asociace mezi nimi.
3.3.1 Entita Admin - Administrátor Entita reprezentuje administrátora, který má právo vytvá°et volební akce
Election(3.3.4)v User(3.3.2).
vytvá°et a ukon£ovat volby m·ºe vytvá°et uºivatele
Action (3.3.3),
rámci akce na kterou má práva a který také
3.3.2 Entita User - Uºivatel Entita
User
reprezentuje uºivatele, který se m·ºe p°ihlásit do systému a podle své role
s ním pracovat. V systému se pro uºivatele vyskytují dv¥ role. Bu¤ m·ºe být uºivatel voli£ nebo m·ºe být komisa° (nebo také oboje). Uºivatel je vytvá°en dv¥ma zp·soby. Bu¤ je vytvo°en administrátorem
Action(3.3.3) nebo je naimportován z databáze registra£ního sys-
tému, taktéº adminem. Entita se v systému nem·ºe vyskytovat samostatn¥, vºdy musí být asociována s akcí, v rámci níº byla vytvo°ena. Uºivatel m·ºe pat°it do jedné nebo více akcí. Dále jsou pak asociace uºivatele závislé na jeho roli. Pokud je komisa° m·ºe být asociován s volební komisí
Election
Commision
(3.3.9), pokud je voli£ tak m·ºe být p°i°azen n¥jakým volbám
(3.3.4), v rámci kterých bude mít právo hlasovat a také m·ºe být asociován s vo-
lební událostí
ElectionEvent (3.3.5). Tato asociace znamená, ºe v rámci události jiº uºivatel
volil. Vzhledem k tomu, ºe uºivatel m·ºe být jak voli£, tak komisa°, m·ºe mít p°i°azeny ob¥ role najednou.
3.3.3 Entita Action - Akce Entita reprezentuje akci, která je bu¤ naimportována z registra£ního systému, nebo vy-
Admin (3.3.1) a která je jakýsi balík pro n¥jaký volební sjezd apod. Election(3.3.4), které jsou spravovány volební komisí dané akce Commission(3.3.9). Uºivatelé User(3.3.2) jsou p°i°azení
tvo°ena administrátorem
V rámci jedné (volební) akce se m·ºe vytvá°et n¥kolik voleb
k dané akci a vytvá°ené volby pak mohou delegovat uºivatele pouze z uºivatel· pat°ící pod danou akci.
3.3.4 Entita Election -Volby Action(3.3.3) ElectionEvent(3.3.5), ke kterým se pak vztahuje samotné hlasování. Volby jsou spravovány volební komisí Commission(3.3.9), která je delegována p°i vytvá°ení voleb a mají k sob¥ p°i°azené voli£e (tedy uºivatele User(3.3.2) s rolí VOTER), kte°í budou moci volit ve volebních událostech. Entita volby reprezetuje volby, jenº jsou vytvo°eny v rámci n¥jaké akce
a které umoº¬ují vytvá°ení jednotlivých volebních událostí
20
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
3.3.5 Entita ElectionEvent - Volební událost Entita reprezentuje volební událost, která je vytvo°ena v rámci voleb. Volební událost m·ºe nap°íklad reprezentovat jednotlivé kolo voleb. Událost je tady asociována s volbami
Election
(3.3.4), vºdy být vytvo°ena v rámci práv¥ jedn¥ch voleb. Dále pak má událost
n¥jaký seznam volebních moºností lístku
ElectionTicket(3.3.6).
Option (3.3.7), které se mohou vyskytnout na hlasovacím
Jak lístk·, tak moºností m·ºe být libovoln¥ mnoho. Událost
je také asociována s voli£em (tedy s uºivatelem
User,
který má roli
VOTER)
a to ve smyslu,
ºe událost má list voli£·, kte°í jiº hlasovali (ale nemá záznam o tom, jak hlasoval).
3.3.6 Entita ElectionTicekt - Volební lístek Entita reprezentuje hlasovací lístek, na kterém voli£ za²krtl moºnost a odeslal ho. Entita je tedy asociována s moºností
Option
(3.3.7). Podle druhu voleb pak m·ºe lístek obsahovat
jednu nebo více moºností (to je indikováno p°íznakem
multipleOptions). Lístek bez za²krt-
nuté moºnosti nem·ºe být odeslán. Lístek se pak také logicky vztahuje k volební události (3.3.5), v rámci níº se volí, ale z d·vodu zaji²t¥ní tajnosti hlasování, není lístek napojen na voli£e (3.3.2).
3.3.7 Entita Option - Moºnost Entita
Option reprezentuje moºnost, kterou m·ºe voli£ zvolit. Moºnost se vztahuje k vo-
lební události (3.3.5) ve smyslu, ºe volební událost má n¥jaké moºnosti o kterých se hlasuje, dále je asociována s volebním lístkem (3.3.6), který danou moºnost za²krtl a také m·ºe být asociována s kandidátem
Candidate
(3.3.8) a to v p°ípad¥, ºe se jedná o personální volby
a moºnosti obsahují kandidáty.
3.3.8 Entita Candidate - Kandidát Entita reprezentuje kandidáta, kterého nominoval komisa° a který má moºnost být zvolena ve volbách. Kaºdý komisa°, m·ºe být vytvo°en ru£n¥ nebo mohou být jeho údaje o
User (3.3.2). Kandidát je asociován s volbami Election (3.3.4) v rámci nichº kandidát kandiduje a také m·ºe být asociován s entitou Option (3.3.7) pokud se objeví jako jedna z moºností pro hlasování. Entita má atribut candidacy, který reprezentuje popis kandidatury kandidáta, photography, který obsahuje fotograi kandidáta a entita také obsahuje atribut description, coº soubor (.pdf nebo .doc), který obsahuje
jménu a p°íjmení odvozeny od entity
ºivotopis, fotograi, kandidaturu a v²echny ostatní v¥ci, které si bude kandidát p°át o sob¥ zve°ejnit.
3.3.9 Entita Commission - Volební komise Volební komise je vytvo°ena na za£átku zakládání nových voleb administrátorem (3.3.1). Do volební komise se delegují uºivatelé
Use
(3.3.2) s rolí
COMMISSIONER.
Admin
Volební
komise pak má právo editovat volby, v rámci nichº je vytvo°ena, nominovat a vytvá°et kandidáty a zahajovat £i ukon£ovat jednotlivé fáze voleb. K n¥kterým akcím je zapot°ebí nadpolovi£ní souhlas komisa°· z dané komise. Komise je svázána s akcí, v rámci níº byla vytvo°ena
3.4.
21
POUITÉ TECHNOLOGIE
a s volbami (3.3.4), které bude komise spravovat. Entita obsahuje p°íznak který, pokud je
true,
mainCommission,
indikuje, ºe komise je nastavena pro danou akci jako hlavní. V tom
p°ípad¥ komise není asociována s ºádnými volbami, ale v²echny komise, které se vytvá°ejí v rámci dané akce, se od této vzorové odvozují. Vzorová komise se vytvá°í p°i zakládání volební akce 3.3.3.
3.3.10 Entita Additionals - Volitelné atributy Entita reprezentuje seznam nepovinných údaj· o uºivateli. M·ºe být importována z registra£ního systému nebo m·ºe být vytvo°ena zárove¬ s uºivatelem. Entita obsahuje pouze seznam pár· Název - Hodnota, který je uloºen v map¥. Název je název údaje a hodnota samotný údaj. Kaºdá entita
3.4
Additionals
pat°í práv¥ jednomu uºivateli (3.3.2).
Pouºité technologie
P°i výb¥ru technologií pro aplikaci jsem musel brát ohled na jiº existující protyp, aby bylo moºné ho modikovat.
3.4.1 Technologie Java EE 6 Základem mé aplikace je platforma Java Enterprise Edition (Java EE) 6, ktera je ur£ená pro vývoj a provoz webových a podnikových aplikací £i informa£ních systém·. B¥hovým prost°edím pro takovéto aplikace £i systémy je aplika£ní server (nap°íklad GlassFish server, JBoss a dal²í). Java EE obsahuje specikace pro tvorbu webových stránek (Java Server Pages, Java Server Faces), vývoj sdílené business logiky (Enterprise Java Beans, Spring) nebo p°ístup ke zprávovému middlewaru (Java Messaging Service). Základem platformy EE je platforma Java Standard Edition, takºe Java EE je kompatibilní se v²emi prvky ze standartní
4
edice. Jako p°íklad uvedu Java Persistence API pro podporu objektov¥ rela£ního mapování .
3.4.2 Datová vrstva Proimplementaci entit z doménového modelu jsem zvolil technologii Java Persistence API 2.0. Java Persistence API 1.0 bylo vytvo°eno spole£n¥ s Java EE 5.0, za ú£elem vy°e²it problémy s persistencí dat. JPA poprvé spojilo dohromady objektove orientovaný p°ístup pouºíváný p°i psaní entit a rela£ní schéma, které se pouºívá pro modelování vztah· mezi tabulkami v databázi. Takovému p°ístupu se °íká objektov¥ rela£ní mapování a jeho princip spo£ívá v delegování p°ístupu do rela£ních databází externím nástroj·m nebo framework·m (Hibernate, TopLink), které vracejí objektov¥ orientovaný pohled na rela£ní data a naopak [14]. JPA 2.0 vy²la spole£n¥ s novou verzí enterprise javy Java EE 6 a p°iná²í pár vylep²ení oproti p°edchozí verzi JPA 1.0, zejména pak odpadá nutnost kongurace pomocí XML, ve²keré 4
Více o plaform¥ EE na (
html>).
22
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
nastavení mapování lze zapsat p°ímo do entit pomocí anotací, které se nacházejí v balí£ku
javax.persistence.
5
3.4.2.1 Databáze Jako databázoví stroj jsem vyuºil MySQL, ale aplikace je vyzkou²ena i pro pouºití vestav¥né databáeze JavaDB, která má snaº²í pouºití.
3.4.3 Business vrstva Pro komunikaci mezi view a datovými prvky aplikace slouºí tzv. business vrstva 3.1. Její primární ú£el je odd¥lení business logiky aplikace od persistentní vstvy £i od entit, které by v sob¥ nem¥ly obsahovat ºádné komplexní operace. O ty by se práv¥ mela starat business vrstva. Tato vrstva je v mé aplikaci implementována pomocí Enterprse Java Bean (EJB) 3.0, coº jsou serverové komponenty (na aplika£ním serveru jsou nasazeny do EJB kontejneru), které zapouzd°ují onu business logiku aplikace. Zárove¬ jsou metody EJB vhodné k aplikování kontroly transakcí a bezpe£nosti a stejn¥ tak mají integrovanou podporu vzdálený p°ístup,
6
zasílání zpráv, webové sluºby apod. (viz [2]) .
3.4.4 Presenta£ní a aplika£ní vrstva Presenta£ní vrstva v aplikacích slouºí k zobrazení dat uºivateli a aplika£ní vrstva p°ijímá podm¥ty od uºivatele (od presenta£ní vrstvy) a interpretuje je vhodným zp·sobem do niº²í vrstvy a naopak. Pro ob¥ tyto vrstvy se v Java EE nachází technologie Java Server Faces. Technologie JSF vyuºívá návrhový vzor Model View Controller (viz. nap°íklad
7 nebo
[11]). View, £ili samotné uºivatelské rozhraní, je zde reprezentováno stromem JSF komponent, které se pak za pomocí reder· vykreslují. Pokud pouºijeme defaultní Render Kit tak se JSF komponenty vykreslí ve form¥ HTML, ale je moºné vytvo°it vlastní Render Kit, který bude vstup a výstup aplikace reprezentovat podle poºadvk· klienta t°eba ve form¥ XML. Pro aplika£ní logiku JSF vyuºívá takzvané backing beans neboli JSF Managed Beans. Backing beany jsou oby£ejné t°ídy, které mají anotaci @ManagedBean a jsou serializovatelné. Kaºdá JSF UI komponenta je pak asociována s takovouto t°ídou a pouºívá ji pro komunikaci s niº²ímy vrstvami (je to její kontroler). ManagedBeans mohou pomocí dependency injection (viz. [11]) provedené pomocí anotace
@EJB
pracovat s enterprise beanami v business vrstv¥
nebo komunikovat s jinými ManagedBeans.
Více o JPA na
, dokumentace k javax.persistence na . 6 Více o technologii EJB 3.0 nap°íklad na http://www.oracle.com/technetwork/java/javaee/ejb/index.html. 7 5
3.4.
POUITÉ TECHNOLOGIE
23
3.4.5 Aplika£ní server Pro aplika£ní server, tedy server na který se nasazují enterprise aplikce, jsem zvolil server GlassFish 3.1. Tento server jsou pouºil zejména proto, ºe to je pouºit v prototypu Elektronické volby, ºe se dá snadno integrovat do vývojového prost°edí NetBeans 7.1.1 a ºe má snadou konguraci. Glasssh je ozna£ován jako referen£ní implementace, to znamená, ºe není primárn¥ ur£en pro provoz aplikací, ale slouºí p°edev²ím jako ukázka implementace nových rys· v poslední specikaci platformy JAVA EE. Sou£asná verze serveru GlassFish je 3.1.2 a slouºí jako referen£ní implementace proj Javu EE6. Existuje rovn¥º komer£ní verze, která nese ozna£ení Oracle GlassFish Server 3.1.2. Ob¥ verze se ve funkcionalit¥ tém¥° neli²í, hlavní rozdíl je p°edev²ím v podpo°e a automatickém stahování aktualizací[17].
Obrázek 3.1: Rozloºení vrstvev v enterprise aplikaci (zdroj [2])
24
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
Kapitola 4
Realizace V této kapitole se zam¥°ím na postup implementace projektu. Vývoj probíhal iterativn¥, a proto zde budu popisovat jednotlivé iterace vývoje a zam¥°ím se na jejich nejd·leºit¥j²í fáze a problémy, které se vyskytly. Iterace nem¥ly dop°edu pevn¥ stanovený £asový úsek po který budou probíhat. P°ibliºná výsledná doba, po kterou daná iterace probíhala, je vºdy uvedena v popisu itrace. P·vodní zám¥r jak realizovat systém, bylo modikovat jiº existující prototyp. Bohuºel v²ak naplánované zm¥ny byly natolik veliké, ºe jsem musel psát celou aplikaci úpln¥ od znovu. Hlavním d·vodem, pro£ jsem nemohl vyuºít stávající systém, byla naprostá zm¥na doménového modelu. Uº ze samotné podstaty doménového modelu vyplývá, ºe ho pouºívá celá aplikace. Proto rozsáhla zm¥na tohoto modelu zp·sobila, ºe v¥t²ina sluºeb a JSF stránek z presenta£ní vrstvy prototypu nemohla být pouºita bez rozsáhlých zm¥n. B¥hem realizace práce, se vyskytly problémy, které vyºadovaly zm¥ny v návrhovém diagramu t°íd oproti doménovému modelu, zpracovaném b¥hem fáze analýzy. Jelikoº to v²ak v²echno byly problémy, které jsou závislé na zvolených platformách, rozhodl jsem se ponechat doménový model bezezm¥n. V této kapitole tedy bude jiº zmi¬ován pouze model návrhový.
4.1
První iterace
4.1.1 Cíl Cílem první itrace bylo p°enést entity z doménového modelu, který jsem zpracoval v analýze (viz. 3.3) do datové vrstvy a k nim navrhnout pot°ebné sluºby, které budou tvo°it business vrstvu.
4.1.2 Postup P·vodním zám¥r bylo, jak jsem jiº psal v úvodu této kapitoly, pouze upravit existující doménový model, ale v pr·b¥hu iterace jsem zjistil, ºe zm¥na je velmi rozsáhlá a proto jsem se rozhodl za£ít psát aplikaci celou znovu. Jak jsem zmínil v kapitole 3.4 na realizaci datové vrstvy jsem pouºil technologii JPA 2.0.
25
26
KAPITOLA 4.
Entity z datové vrstvy se nacházejí v balí£ku
REALIZACE
model v EJB modulu ElektronickoVolby-ejb,
který je sou£ástí enterprise aplikace a nasazuje se spole£n¥ s ní na aplika£ní server. Jsou
POJO1 , javax.persistence,
to vlastn¥ oby£ejné t°ídy, tzv.
jenº jsou poºadovaným zp·sobem dopln¥ny anota-
cemi z balí£ku v
které se postarají o namapování t¥chto t°íd a jejich
vztah· do databáze. Asi nejv¥t²í d·raz p°i psaní entit, jsem kladl na správné pouºití tzv. kaskád. Kaskády jsou parametr anotací, které se starají o mapování relací (takºe nap°íklad
@ManyToMany, @OneToMany,
atd.) a slouºí ke správnému "probublání"ur£itých operací
s entitou do entit, které jsou s ní ve vztahu. Mezi tyto operace pat°í vytvo°ení, editace, odstran¥ní, £i aktualizace entity. Správné pochopení toho jak kaskády fungují, byla asi jediná men²í p°ekáºka, která se p°i psaní datové vrstvy aplikace vyskytla. Pro business vrstvu jsou v aplikaci pouºity Enterprise Java Beans verze 3.0, pomocí kterých jsem implementoval v²echny podstatné sluºby, které v aplikaci vyºaduje vy²²í, presenta£ní, vrstva pro práci s daty. V této iteraci se jednalo o vytvo°ení hlavních sluºeb, které byly z°ejmé uº v této fázi implementace. Mezi tyto sluºby pat°ily zejména CRUD operace
2.
Tato fáze obsahovala také vytvá°ení primitvních SQL dotaz·, které byly vyºadovány implementovanými sluºbami. Poslední fází v této iteraci bylo vytvo°it
PersistenceUnit,
coº je XML kongura£ní
soubor, který má na starosti propojení EJB modulu se zvolenou databází. Nakonec jsem celý enteprise modul nasadil na aplika£ní server, zkontroloval správné vygenerování tabulek a otestoval jsem jesti jsou entity správn¥ nakongurovány a jestli fungují sluºby k nim navrºené.
4.1.3 Výstup Po skon£ení této iterace jsem m¥l k dispozici hotovou datovou vrstvu vytvo°enou podle doménového modelu, databázi s vygenerovanými tabulkami (o to se postará JPA p°i nasazení aplikace) a nasazený enteprise modul, který obsahoval entity a business sluºby. Celá iterace trvala p°ibliºn¥ 40 dní.
4.2
Druhá iterace
4.2.1 Cíl Cílem druhé iterace bylo implementovat uºivatelské rozhraní pro administrátorskou £ást a pop°ípadn¥ doplnit business vrstvu o sluºby, které nebyly implementovány v první iteraci, protoºe je²t¥ nebyla odhelena nutnost je vytvo°it.
4.2.2 Postup První fází v této iteraci bylo zprovoznit security realm na aplika£ním serveru, který slouºí k nastavení zapezpe£ení aplikace a vytvo°ení p°ihla²ovacího formulá°e. Zárove¬ bylo
POJO - Plain Old Java Object CRUD je zkratka pro nej£ast¥j²í operace nad databází. Je odvozena z anglických slov Create, Read, Update a Delete, tedy vytvo°it, £íst, aktualizovat a vymazat. 1 2
4.2.
27
DRUHÁ ITERACE
také nutné nastavit p°ihla²ování a omezení pro uºivatelské role v kongura£ním souboru pro JSF
web.xml.
P°ihla²ovací formulá° a nastavení zabezpe£ení jsem mohl pouºít z prototypu aplikace, ale práv¥ p°i zkoumání nastavení zabezpe£ní v security realmu na serveru se objevil problém v návrhovém modelu t°íd. Problém spo£íval v tom, ºe security realm vyºaduje jméno tabulky, kde se vyskytuje p°ihla²ovací jméno, heslo a uºivatelská role. Tato tabulka v²ak m·ºe být pouze jedna. P°i pohledu na doménový model B.3 vytvo°ený p°i analýze je ov²em z°ejmé, ºe p°ihla²ovací údaje jsou rozst°í²t¥né do tabulek
User
a
Admin,
která navíc nemá denovanou
uºivatelskou roli. Pro vy°e²ení problému jsem tedy musel datovou vrstvu a návrhový model refaktoro-
3 tak, abych vytvo°il spole£ného p°edka (AbstractUser) pro vý²e zmín¥nné entity, který
vat
bude obsahovat spole£né prvky pro p°ihlá²ení (p°ihla²ovací jméno a heslo), uºivatelskou roli a email. Zárove¬ jsem p°idal uºivatelskou roli
COMMISSIONER.
ADMIN
a pro zjednodu²ení i roli
VOTER AND
Upravená £ást doménového modelu je na obrázku 4.1.
Obrázek 4.1: Upravená £ást doménového modelu
Po zprovnozn¥ní p°ihla²ování jsem mohl pokra£ovat v implementaci administra£ní £ásti.
Refactoring je proces upravování jiº existujícho softwaru takovým zp·sobem, ºe se nezm¥ní jeho chování sm¥rem ven, ale pouze jeho vnit°ní struktura (z p°ekladu anglického textu [12]) 3
28
KAPITOLA 4.
REALIZACE
Pro nastavení vzhledu generovaného kódu HTML z JSF komponent jsem pouºil css styly z prototypu a jen mírn¥ je upravil. Jinak tato fáze jiº prob¥hla bez v¥t²ích problém·.
4.2.3 Výstup Po skon£ení druhé iterace jsem m¥l k dispozici funk£ní p°ihla²ování do systému a presenta£ní vrstvu pro administrátorskou £ást, která umoº¬uje uºivateli s rolí
ADMIN
vytvá°et
volební akce, uºivatele, komise £i volby (interakce admina se systémem viz B.1). K view byl hotový kontroler, který komunikoval s business £ástí, do které byly dopln¥ny chyb¥jící funkce, které byly v této fázi obejeveny. Tato fáze trvala p°ibliºn¥ m¥síc.
4.3
T°etí iterace
4.3.1 Cíl Cílem t°etí iterace bylo implementovat uºivatelské rozhraní pro roli komisa°e a stejn¥ jako v p°ípad¥ p°edchozí iterace, pop°ípadn¥ doplnit business vrstvu o chyb¥jící sluºby, pokud se n¥jaké objeví.
4.3.2 Postup Tato fáze probíhala bez v¥t²ích problém·, dokud jsem se nedostal k problému spou²t¥ní a ukon£ování voleb. V analýze je uvedeno, ºe volby £i volební události bude muset zahájit £i uko£it pouze nadpolovi£ní v¥t²ina komisa°·, ale nakonec po dohod¥ s vedoucím práce, jsem tuto fázi implementoval jinak. D·vod pro zm¥nu byl takový, ºe na zp·sob, který je uveden v analýze, nebylo my²leno p°i návrhu doménového modelu. Zm¥na by byla celkem komplikovaná a vyºadovala by p°epracovat návrhový model a datovou vrstvu a tak jsem pro nedostatek £asu zvolil jednodu²í zp·sob, kdy pro provedení poºadované akce (ukon£ení/spu²t¥ní voleb/události), bude sta£it ov¥°ení od jednoho dal²ího komisa°e. Potvrzení prob¥hne tím, ºe se zobrazí dv¥ vstupní polí£ka pro zadání komisa°ova p°ihla²ovacího jména a hesla. Po zadání potvrzení systém komisa°e vyhledá, zkontroluje jestli je v komisi daných voleb a pokud ano tak provede danou akci.
4.3.3 Výstup Po dokon£ení této fáze jsem získal dokon£enou aplikaci, která dokáºe pln¥ spravovat ve²keré záleºitosti s administrací i °ízením voleb, ale je²t¥ neumí komunikovat s hlasovacím terminálem a neumí vyhodnocovat výsledky hlasování. Tato fáze op¥t tvrvala p°ibliºn¥ m¥síc.
4.4.
29
TVRTÁ ITERACE
4.4
tvrtá iterace
4.4.1 Cíl Cílem poslední iterace ve vývoji aplikace Elektronické volby, byla implementace s£ítacího algoritmu odeslaných lístk·, implementace zobrazení výsledk· a propojení celé aplikace s terminálovou £ástí pro samotné hlasování[20].
4.4.2 Postup 4.4.2.1 S£ítácí algoritmus Po dohod¥ s vedoucím práce byl jako s£ítací algoritmus zvolen tzv. systém jednoho p°enosného hlasu (Single Trasferable Vote - STV). Algoritmus jsem spole£n¥ s ostatnímy propor£nímy volebnímy systémy (kam STV pat°í také) popisoval v kapitole 2.2.1.2.Vzorem pro vývoj mi byly p°íklady, které jsem vyhledal na iternetu (zejména pak [13] a [21]). Podle ukázek ve zmín¥nných zdrojích jsem modul pro s£ítání také testoval. Více o testování v kapitole 5. Podrobný slovní popis algoritmu by byl p°íli² rozsáhlý a pravd¥podobn¥ by jeho p°ínos byl velmi malý, proto je vysv¥tlen formou aktivity diagram·. V diagramu 4.3 je znázorn¥n diagram aktivit celého algoritmu a v diagramech 4.4 (p°enos hlas· zdola) a 4.5 (p°enos hlas· shora) jsou podrobn¥ znázorn¥ny pr·b¥hy aktivit, které jsou na diagramu 4.3 ozna£eny leºatou osmi£kou. Jelikoº je algoritmus extrémn¥ netriviální tak pro správné pochopení doporu£uji projít zárove¬ s aktivity diagramy i v²echny zdroje uvedené jak v této kapitole, tak v kapitole 2.2.1.2. Níºe jsou posány pouze nejd·leºit¥j²í £ásti impelementace algoritmu. T°ída pro implementaci algoritmu implementuje rozhraní obsahující metody, které slouºí pro inicializaci a spu²t¥ní algoritmu. Tím je serverová £ást p°ip°avena s£ítat hlasy i jiným zp·sobem, neºli systémem jedoho p°enosného hlasu. Pro správnou realizaci funkce algoritmu STV jsem si musel vytvo°it je²t¥ pomocnou t°ídu, která obaluje hlasovací lístek z datové vrstvy (vytvo°en podle doménového modelu B.3) a má v sob¥ ukazatel na následující preferenci, který se inkrementuje p°i kaºdém p°e£tení preference z lístku. V diagramech je £asto pouºívaný pojem "poslední kolo s£ítání". Nové kolo s£ítání preferencí nastane pokud n¥jaký kandidát £i volená moºnost p°esáhne droopovu kvótu a nebo pokud se skon£í vyhodnocování výsledk· p°enosu hlas· od moºnosti s nejmén¥ obdrºenými hlasy (p°enos hlas· zdola).
4.4.2.2 Propojení serverové £ásti s terminálovou Hlavní £ást kongurace propojení s terminálovou £ásti musela být provedena panem Tarantíkem na jeho hlasovacím terminálu. Moje úloha obsahovala pouze nasadit na Glasssh EJB modul
ClientModul-ejb, který obsahoval Enterprise Java Beanu implementující sluºby
pouºíváné terminálovou £ástí a vzdálené (Remote) rozhraní. Tento modul se pak pomocí vzdáleného volání metod 4
RMI4
volá z klientské £ásti.
RMI - Remote Method Invocation
30
KAPITOLA 4.
REALIZACE
P°i této fázi jsme v práci narazili na problém s persistencí entit, které obsahovaly ko-
5
lekci typu java.util.Map . JPA totiº neumí napamovat tento typ kolekcí do databáze pokud
6
klí£ mapy není zárove¬ primárním klí£em entity, kterou mapa obsahuje jako hodnotu . Vy-
ElectionEvent (3.3.5) a entit ElectionTicket (3.3.6). V t¥chto entitách se totiº nachází mapa, která obashuje moºnost (entita Option 3.3.7 jako klí£ a Integer jako po£et obdrºených hlas· po s£ítání (u entity ElectionEvent) nebo Integer jako klí£ a moºnost jako hodnotu (u ElectionTicket a klí£
°e²ení tohoto problému znamenalo zm¥nit strukturu entit
zna£í £íslo preference). Pro vy°e²ení tohoto problému jsem vytvo°il dv¥ pomocné entity
TicketItem a ResultsItem.
První entita (TicketItem) je v relaci s volebním lístek a reprezentuje dvojici Preference Volená moºnost (tedy entita
Optiion),
druhá (ResultsItem) je ve vztahu s
ElectionEvent
a reprezentuje dvojici Zvolná moºnost - Po£et hlas· po s£ítání. Po této zm¥n¥ pak jsem v entitách
ElectionEvent a ElectionTicket jiº nem¥l problematickou mapu, ale pouze list,
který uº nebyl problém uloºit do databáze (respektive JPA si listem bez problému poradí). Pro lep²í p°edstavu, obrázek 4.2 zobrazuje p°ed¥lanou problematickou £ást doménového modelu. Po p°ed¥lání £ásti entit, se p°i pokusu o spojení s klientem na mé strán¥ nevyskytl a tím pádem tato iterace pro m¥ skon£ila.
4.4.3 Výstup Po skon£ení této iterace, jsem m¥l k dispozici funk£ní aplikaci s£ítající hlasy zvoleným algoritmem (STV), zobrazující výsledky voleb a komunikující s terminálovou £ástí pro hlasování. Aplikace byla p°ip°evena na zku²ební nasazení do provozu a na °ádné otestování spole£en¥ s klientskou £ástí aplikace.
5 6
viz odkaz na literaturu [4] strana 13, kapitola 2.7
4.4.
TVRTÁ ITERACE
31
Obrázek 4.2: Pohled na upravenou £ást doménového modelu, po vy°e²ení problému s ukládáním mapy
32
KAPITOLA 4.
Obrázek 4.3: Diagram aktivit p°i s£ítání hlas· pomocí STV
REALIZACE
4.4.
TVRTÁ ITERACE
Obrázek 4.4: Detail p°enosu hlas· zdola
33
34
KAPITOLA 4.
Obrázek 4.5: Detail p°enosu hlas· shora
REALIZACE
Kapitola 5
Testování 5.1
Testování algoritmu pro s£ítání hlas·
Nejd·leºit¥j²í v aplikace pro Elektronické volby je zajisté algoritmus pro s£ítání odevzdaných lístk·. Jak algoritmus funguje jsem popisoval v p°edchoích kapitolách v této £ásti se zam¥°ím na popis zp·sobu jak byl algoritmus testován. Testování algoritmu STV probíhalo je²t¥ b¥hem vývoje a podle výsledk·, které jsem po kaºdém spu²t¥ní test· získal, byl algoritmus upravován. Abych mohl ov¥°it korektnost algoritmu, musel jsem vyhledat praktickou ukázku s£ítání, kde by bylo ukáno jak byly na lístcích za²krtány preference. Úpln¥ p°esnou ukázku pr·b¥hu voleb jsem bohuºel nesehnal, podle zdroje [13] jsem v²ak mohl z popisu obrºených hlas· odvodit kolik hlas· kdo obdrºel aº do 3. preferencí. Vytvo°il jsem si podle popisu 4000 lístk· a 7 kandidát· (A, B, C, E, F, M, N). T¥mto kandidát·m jsem jedoduchým zp·sobem, kdy jsem pro²el v²echny lístky, p°i°adil první preference tak aby odpovídaly rozloºení prvních preferencí v tabulce 5.1. V této fázi jsem mohl otestovat korektnost vypo£tení droopovi kvóty. Podle popisu dal²ích kol s£ítání ve zdroji [13] se mi poda°ilo vypozorovat rozloºení dal²ích preferencí tak, ºe jsem je mohl p°i°adit jednolivých lístk·m aby se °ádn¥ p°ená²ely. Ov²em maximáln¥ do fáze odpovídající sloupe£ku "Po vy°azení kandidáta C", poté jiº je pak velmi sloºité, aº tak°ka nemoºné, vypozorovat obsah jednolivých lístk· aby mohl být algoritmus testován i po této fázi. Nicmén¥ rozloºení preferencí na p°ená²ených lístcích v posledních fázi se mi povedlo pom¥rn¥ dob°e odhadnout a po dokon£ení testování algoritmus vrátí správné vít¥ze. V jednolivých krocích p°i debugování testovací t°ídy, odpovídaly v²echny p°ená²ené i nep°ená²ené lístky údaj·m v tabulce, aº tedy na zmi¬ovaný poslední krok, kdy je po£et lístk· u kandidáta M mí°n¥ odli²ný, ale ne natolik aby se zm¥nil výsledek voleb. Po£et krok·, které jsem byl schopen p°i testování nasimulovat (a které prob¥hly správ¥), je podle m¥ dostate£ný k tomu, aby se algoritmus dal povaºovat za funk£ní. I p°esto si myslím, ºe by bylo vhodné algoritmus je²t¥ dále testovat, podle p°esn¥ rozepsepsaného p°íkladu z n¥jakých reálných voleb a bylo korektnost s£ítání stoprocentní. Bohuºel takvý p°íklad se mi, jak jsem jiº zmínil, nepovedlo vyhledat. Asi nejv¥t²í problém, u kterého mám nejvíce nejasností, je p°i jakých podmínách uº se hlasy dále nep°ená²í a zbytek neobsazených mandát· se obsadí kandidáty, kte°í mají nejvíce hlas· v dob¥ ukon£ení, i kdyº
35
36
KAPITOLA 5.
Kandidát
1. rence
prefe-
TESTOVÁNÍ
Po p°esnosu
Po vy°azení
Po vy°azení
Po vy°azení
Po
shora
kandidáta
kandidáta F
kandidáta
(
(2.
4.
fáze)
N
C
stav)
A
1500
1001
1001
1001
1001
1001
B
600
814
814
814
1114
1001
C
200
378
430
480
-
-
E
800
800
800
890
890
920
F
350
350
350
-
-
-
M
400
400
580
730
870
953
N
150
257
-
-
-
-
Nep°enosné
-
-
25
85
125
125
Tabulka 5.1: Rozloºení preferencí v jednolivých kolech s£ítání
nep°esáhli kvótu. Dále by pak mohl být algoritmus urychlen, protoºe existují metody, kdy lze p°i p°enosu hlas· zdola (viz diagram 4.4 vy°adit více jak jednoho kandidáta. K tomu m·ºe dojít za ur£itých ukolností, které ov²em nejsou nikde p°íli² dob°e popsány, proto jsem je neimplementoval.
5.1.1 Testování uºivatelem Dal²í fáze testování spo£ívala v testování uºivatelského rozhraní fyzickým uºivatelem, který se posadil k mé aplikaci a plnil mnou zadané úkoly. Ty se týkaly nej£ast¥j²ích akcí, které bude uºivatel se systémem provád¥t, takºe nap°íklad zobrazení výsledk· voleb, administrace akcí, uºivatel·, spou²t¥ní událostí, vytvá°ení kadidát· a podobn¥. P°i tom jak testující uºivatel plní zadané úlohy jsem ho pozoroval a zji²´oval jak se dokáºe v aplikaci orientovat. Jako záv¥r jsem si z testování odnesl, ºe aplikace vyºaduje p°íli² mnoho klikání, ºe by bylo vhodné vylep²it uºivatelské menu, které by zjednodu²ilo pohyb po systému. Z d·vodu nedostatku £asu jiº tento problém nebyl °e²en.
fázi
kone£ný
Kapitola 6
Záv¥r Cílém práce bylo analyzovat, navrhnout, implementovat, otestovat a zku²ebn¥ ov¥°it vylep²ení serverové £ásti systému Elektronické volby[18]. Systém m¥l být roz²í°en o hlasování s terminálovou £ástí, kterou implementoval pan Tarantík[20] a o moºnost importovat uºivatele z aplikace pro registra£ní £ást[16]. Prvním cílem p°i práci bylo analyzovat zm¥ny, které jsou nutné provést na existujícím systému, aby mohlo být spln¥no zadání. To vedlo k velmi rozsáhlé zm¥n¥, p·vodn¥ nedostat£n¥ navrºeného, doménového modelu, coº zp·sobilo, ºe se v podstat¥ neejednalo o vylep²ování prototypu, ale o úpln¥ celý vývoj nové aplikace. Z p·vodní práce byl pouºit pouze dob°e navrºený zp·sob p°ihla²ování a kaskádové styly pro design výsledných webových stránek. Tato skute£nost vedla ke zna£nému zdrºení coº zp·sobilo, ºe zadání bylo spln¥no pouze £áste£n¥. Sou£asný stav aplikace je takový, ºe systém je schopen existovat samostatn¥, ale není p°ipraven importovat data z registra£ní £ásti, coº ho ov²em nijak nelimituje. Aplikace je schopná plnit v¥t²inu p°ípad· uºití vytvo°ený analýze (viz. 3.2.1) aº na £ást se ºádostmi o registraci a práv¥ import z registra£ní £ásti. Mírn¥ upraven je ve výsledku také oproti analýze zp·sob spou²t¥ní a ukon£ování voleb a událostí. as a datum zahájení je spí²e informativní, ve²keré akce provádí pouze komisa°, který je oprávn¥n volby spravovat. K zahájení také není pot°eba nadpolovo£ní v¥t²ina v²ech komisa°· z volební komise, ale pouze zadání hesla a loginu od potvrzujícího komisa°e. Dále pak chybí jiº zmín¥ný import z registra£ní £ásti. Práv¥ dopln¥ní importu je vhodným bodem pro pokra£ování ve vývoji aplikace. Pro spln¥ní tohoto bodu, bych ale je²t¥ doporu£oval p°epracovat datovou £ást registra£ního systému tak, aby pouºívala JPA, coº by zna£n¥ uleh£ilo p°enos entit mezi jednolivými systémy. V sou£asné podobn¥ je persistence entit dost zmate£ná a pro budoucí vývoj by automatické generování tabulek velmi uleh£ilo práci. V dob¥ kdy byla registra£ní £ást vyvýjena, jsme je²t¥ s JPA nem¥l dostatek zku²eností a proto je pouºita p°ímá páce s JDBC. Pomalý vývoj také zp·sobil, ºe oproti p·vodní aplikaci není systém zcela multijazy£ný. P°ekládá se pouze menu se záhlavím a zápatím stránky. Naopak úspe²n¥ bylo spln¥no roz²í°ení o hlasování s terminálovou £ástí. P°ipojit terminál k serverové £ásti je moºné jak lokáln¥ tak i p°es sí´ a ob¥ aplikace jsou p°ipraveny k nasazení na dotykový hlasovací terminál. Asi nejsloºit¥j²í £ástí práce se mi zdálo implementování s£ítacího algorimu pro systém jenoho p°enosného hlasu. Problémem p°i vývoji algoritmu byl
37
38
KAPITOLA 6.
ZÁV
R
nedostatek praktických ukázek s£ítání (detailn¥ rozepsané jak vypadají lístky a jak probíhá s£ítání p°i dané podob¥ lístk·) a také to, ºe teoretické popisy algoritmu se mnohdy v men²ích detailech li²ily zdroj od zdroje. Do budoucna není problém roz²í°it aplikaci o dal²í typ voleb, jediná podmínka je aby implementovalo rozhraní jednotné pro s£ítací algoritmy. Posledním bodem zadání bylo otestování aplikace. Z d·vodu nedostatku £asu je v²ak otestován pouze algoritmus pro s£ítání hlas·. Proto bych rád v budoucnu k aplikaci je²t¥ doplnil JUnit testy pro °ádné otestování datové vrstvy (entity) a EJB t°íd v business vrstv¥. Dále bych cht¥l provést zát¥ºové testy pomocí n¥jakého benchmarku (nap°íklad Apache) a provést testování pr·chodu uºivatele skrz webové stránky pomocí testovacího nástroje Selenium.
Literatura [1] Adam
Elektronické
Pospí²il.
line].
5.5.2008.
[cit.
volby
28. 12. 2011].
by
zm¥nily
Dostupné
z:
politickou
scénu
[on-
elektronicke-volby-by-zmenily-politickou-scenu-ft4-/mob_tech.aspx?c= A080421_205854_mob_tech_apo>.
[2] Antonio Goncalves. Beginning Java EE 6 Platform with GlassFish 3. Apress, 2010. [3] Bc.
David
kladu
Volební
Zrostlík.
parlamentních
[cit.
voleb
2. 1. 2012].
v
systém
roce
Dostupné
2007
Austrálie
na
[online].
p°í-
27.10.2008.
z:
317-volebni-system-australie-na-prikladu-parlamentnich-voleb-v-roce-2007. html>. JPA Objects Users Guide [online]. 2009. [cit. 21. 5. 2012].
[4] Dan Haywood. stupné
Do-
z:
docbkx/pdf/user-guide.pdf>. [5] Helena Ku£erová.
Use Case model [online]. 3.11.2011. [cit. 5. 1. 2012].
Dostupné z:
. [6] Ing.
Karel
8.6.2011.
Elektronické
Zvára.
[cit.
2. 1. 2012].
volby
Dostupné
z:
elektronicke-volby-bezpecnost/>. [7] Ing. Pavel Kuklík, Mgr. Josef Baxa. 31.3.2005. [cit. 2. 1. 2012].
-
mohou
být
bezpe£né?
[online].
Metody pro p°epo£et hlas· na mandáty [online].
Dostupné z:
metody_pro_prepocet_hlasu_na_mandaty>.
[8] Jan Morkes. Vliv kompenza£ních mandát· na proporcionalitu výstup· volební sout¥ºe [online]. 2008. [cit. 29. 12. 2011].
EVS/006/EVS_3_2_2.pdf>. [9] Ji°í
Peterka.
Stalo
se:
Dostupné z:
p°ipravují
se
elektronické
volby
[online].
14.4.2008.
[cit. 29. 12. 2011]. Dostupné z: . [10] Josef Mlejnek. Smí²ené volební systémy. Karolinium, 2010. [11] Martin Fowler. Patterns of Enterprise Application Architecture. Addison Wesley, 2003.
39
40
LITERATURA
[12] Martin Fowler. Refactoring: Improving the Design of Existing Code. Addison Wesley, 1999. [13] Masarykova Univerzita. Systém jednoho p°enosného hlasu a systém politických stran [online]. [cit. 18. 5. 2012]. Dostupné z: . [14] Mike Keith, Merrick Schincariol. Pro EJB, Java Persistence API. Apress, 2006. [15] Neuveden.
Typologie Volebních Systém· [online]. 2010. [cit. 2. 1. 2012].
Dostupné z:
. [16] P. Hlavá£ek, V. Tarantík, , korpil, O. Kulatý. Registra£ní £ást pro systém Elektronické
Volby a Mobilní hlasování [online]. 29.12.2011. [cit. 29. 12. 2011]. Dostupné z:
//code.google.com/p/volebni-system>.
[17] P°isp¥vatelé Wikipedie. GlassFish [online]. 2012. [cit. 21. 5. 2012]. Dostupné z:
//cs.wikipedia.org/wiki/GlassFish>.
[18] Tomá²
Elektronické
erevka.
volby
[online].
25.5.2010.
[cit.
23. 12. 2011].
z: . Dostupné
[19] Václav Rada. Internet v praxi: Komunální volby v Estonsku, do£káme se i u nás? [online]. 23.12.2011. [cit. 28. 12. 2011]. Dostupné z:
cz/internet-v-praxi-komunalni-volby-v-estonsku-dockame-se-i-u-nas/>.
[20] Václav Tarantík.
Volební terminály pro systém elektronické volby.
Bakalá°ská práce
VUT FEL. 2012. [21] Veronika Hamºová. Komparace volebního systému Malty a Irska s d·razem na jeho psychologické ú£inky. Bakalá°ská práce Masarykova Univerzita, Fakulta sociálních studií. 2007.
P°íloha A
Seznam pouºitých zkratek R
eská republika
EU
Evropská komise
SE
Jedná se o Java Standart Edition - tedy o Javu, která se pouºívá pro programování desktopových aplikací.
EE
Jedná se o Java Enterprise Edition - tedy o Javu, která se pouºívá pro programování podnikových a webových apliací.
JPA
Java Persistence API - nástroj pro automatickou persistenci dat
HTML CSS
- Cascading Style Sheets
XML RMI
- HyperText Markup Language
- Extensible Markup Language - Remote Method Invocation
41
42
PÍLOHA A.
SEZNAM POUITÝCH ZKRATEK
P°íloha B
UML diagramy
43
44
PÍLOHA B.
UML DIAGRAMY
Obrázek B.1: P°ípady uºití pro serverou £ást aplikace
45
Obrázek B.2: P°ípady uºití pro terminálovou £ást aplikace
46
PÍLOHA B.
Obrázek B.3: Doménový model
UML DIAGRAMY
P°íloha C
Instala£ní a uºivatelská p°íru£ka Zde je popsán postup, jak je správn¥ aplikaci nainstalovat a jak nastavit aplika£ní server Glasssh 3.1, aby aplikace fungovala.
C.1
•
Pot°ebné programy Java JRE a JDK (
index.html>)
•
Glasssh Server Open Source Edition 3.1.2 (funguje i na verzi 3.1
java.net/downloads/3.1.2-final.html>). •
MySQL Server ()
•
Netbeans 7.0 a vy²²í () s pluginy:
•
Java SE Java Web and EE JUnit JSF Selenium Plugin for Ant Projects
Internetový prohlíºe£ - je jedno jaký, doporu£uji Mozilla Firefox (
mozilla.cz/>)
C.2
verze 10 a vy²²í, protoºe na n¥m byla aplikace testována.
Instalace
C.2.1 Glasssh Server Edition 3.1.2 1. Stáhnout a instalovat podle pokyn· instalátoru. 2. Dle vlastního uváºení zvolit heslo pro administraci, není nutné.
47
48
PÍLOHA C.
INSTALANÍ A UIVATELSKÁ PÍRUKA
C.2.2 MySQL Server 1. Stáhnout a instalovat podle pokyn· instalátoru. 2. Dle vlastního uváºení zvolit heslo pro administraci, není nutné.
C.2.3 Netbeans 7.1.1 1. Stáhnout a instalovat podle pokyn· instalátoru. 2. Instalovat pot°ebné pluginy p°es Tools -> Plugins -> Available Plugins -> Ozna£it vybrané -> Install. 3. Restartovat Netbeans.
C.3
Nastavení
C.3.1 MySQL Server 1. V Netbeans záloºka sevices -> Database -> Pravé tla£ítko -> Register MySQL server 2. User name
root
a bez hesla
3. Vytvo°it databáti se jménem
eVolby
4. V obou EJB modulech (tedy
ClientModule-ejb
a
ElektronickeVolby-ejb)
-> Con-
guration Files -> persistence.xml (New Data Source ):
jdbc/eVolbySQL
•
JNDI name:
•
Database Connection:
Schema]
jdbc:mysql://localhost:3306/evolby [root on Default
C.3.2 Glasssh Server Open Source Edition 3.1.2 K nastavení aplika£ního serveru Glasssh 3.1.2 je t°eba zapnout administra£ní konzoli. Pokud má £tená° zku²enosti s kongurací, m·ºe pouºít konguraci pomocí p°íkazové °ádky (v instala£ní sloºce Glasssh ->
asadmin).
Jinak doporu£uji pouºít administra£ní konzoli
zobrazenou v prohlíºe£i, která je defaultn¥ dostupná na adrese nebo lze spustit p°es NetBeans: services -> Servers -> GlassFish 3.1.2 -> pravé tla£ítko -> View Domain Admin Console.
C.3.2.1 Security Realm 1. Congurations -> server-cong -> Security Realms -> New...
eVolbyRealm
•
Name:
•
Class Name:
com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm
C.4.
C.4
49
SPUT
NÍ
jdbcRealm
•
JAAS Context:
•
JNDI:
•
User Table:
•
User Name Column:
•
Password Column:
•
Group Table:
•
Group Name Column:
•
Digest Algorithm:
jdbc/eVolbySQL abstractuser login
password
abstractuser userrole
none
Spu²t¥ní
1. Spustit aplika£ní server Glasssh 2. Na projektu
Elektronické volby
zvolit v kontextovém menu Deploy v Netbeans.
3. Zkontrolovat nasazení v²ech EJB modol· na server. 4. Do databázové tabulky
ADMIN.
AbstractUser
p°idat uºivatele dle libosti a p°i°adit mu roli
Je také pot°eba p°idat jeho ID do tabulky
Admin.
(a) Nebo lze spustit tento SQL skript: (b)
(c)
INSERT INTO ABSTRACTUSER (DTYPE, COMPLETEREG, EMAIL, LOGIN, PASSWORD, USERROLE) VALUES ('Admin', 1, '[email protected]', Admin', 'admin', 'ADMIN'); INSERT INTO ADMIN_TABLE (USERID) VALUES (1)
5. Pravým tla£ítkem na projektu zvolit zoli.
Deploy
nebo spustit p°es administrátorsou kon-
50
PÍLOHA C.
INSTALANÍ A UIVATELSKÁ PÍRUKA
P°íloha D
Obsah p°iloºeného CD \---Projekt | readme.txt | +---Docs | | Elektronické Volby Serverová £ást.pdf | | | +---AbstractCZ | | AbstractCZ.txt | | | +---AbstractEN | | AbstractEN.txt | | | +---EA | | ElektronickeVolby.eap | | | \---k336_thesis | +---Javadoc | +---ClientModule-ejb | | | +---ElektronickeVolby-ejb | | | \---ElektronickeVolby-war | +---src | \---ElektronickeVolby | | | +---ClientModule-ejb | | | +---dist | | ElektronickeVolby.ear | |
51
52
| +---ElektronickeVolby-ejb | | | +---ElektronickeVolby-war | | | \---TerminalPart |+---Text | BP
PÍLOHA D.
OBSAH PILOENÉHO CD