}w
!"#$%&'()+,-./012345<yA|
M ASARYKOVA UNIVERZITA
FAKULTA INFORMATIKY
Systém pro správu webových
formuláˇru˚
D IPLOMOVÁ PRÁCE
Bc. Ondˇrej Božek
Brno, podzim 2011
Prohlášení
Prohlašuji, že tato diplomová práce je mým puvodním
˚
autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.
Vedoucí práce: RNDr. Radek Ošlejšek, Ph.D.
ii
Podˇekování
Na tomto místˇe bych rád podˇekoval panu RNDr. Radku Ošlejškovi, Ph.D. za odborné vedení, cenné rady a vstˇrícný pˇrístup bˇehem zpracování této práce.
Dále dˇekuji své matce MUDr. Jarmile Božkové a sestˇre Karolínˇe Božkové za pohotovou
pomoc s korekturou. V neposlední rˇ adˇe dˇekuji své pˇrítelkyni Bc. Evˇe Pláteníkové za její
neúnavnou trpˇelivost a podporu v prubˇ
˚ ehu psaní práce.
iii
Shrnutí
Cílem práce je navrhnout webovou aplikaci pro vytváˇrení dynamických formuláˇru˚ pro sbˇer
a vyhodnocování dat. Aplikace umožnuje
ˇ
jednoduchým a intuitivním zpusobem
˚
vytváˇret
nové webové formuláˇre a integrovat je do vlastního webu. Prostˇrednictvím administrativní
sekce aplikace nabízí sledování statistik vyplnených
ˇ
formuláˇru,
˚ procházení vyplnených
ˇ
formuláˇru˚ cˇ i automatické pˇreposílání vyplnˇených formuláˇru˚ e-mailem.
Textová cˇ ást práce obsahuje popis problematiky, popis a srovnání podobných existujících
systému˚ a UML modely zachycující požadavky na systém a statické modely dekompozice
a nasazení systému. Dále obsahuje popis použitých návrhových vzoru˚ a významných technologií. Pro implementaci byly použity pokroˇcilé Javové rámce (JavaEE, ICEfaces, Spring a
další). Souˇcástí práce je rovnˇež volba technologií, jejich popis a zkušenosti s jejich použitím.
iv
Klíˇcová slova
formuláˇre, HTML5, Spring, JSF, ORM, JPA, EclipseLink, AJAX, ICEfaces, DND, DTO, JavaEE, Scoped proxy, backing bean, RIA, Java, MVC, Dependency Injection, Inversion of
Control
v
Obsah
1
2
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Webové nástroje pro tvorbu a publikování formuláˇru˚ .
2.1 Software jako služba . . . . . . . . . . . . . . . . . .
2.2 Formuláˇrové aplikace k lokálnímu nasazení . . . . .
3 Analýza požadavku˚ . . . . . . . . . . . . . . . . . . . . .
3.1 Funkˇcní požadavky . . . . . . . . . . . . . . . . . . .
3.2 Nefunkˇcní požadavky . . . . . . . . . . . . . . . . .
3.3 Pˇrípady užití . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Aktéˇri vystupující v systému . . . . . . . . .
3.3.2 Scénáˇre pˇrípadu˚ užití . . . . . . . . . . . . .
3.4 Iterativní a inkrementální vývoj . . . . . . . . . . . .
4 Analýza a návrh . . . . . . . . . . . . . . . . . . . . . . . .
4.1 Aplikaˇcní rámec Spring a Dependency injection . .
4.2 Model problémové domény . . . . . . . . . . . . . .
4.3 Model tˇríd . . . . . . . . . . . . . . . . . . . . . . . .
4.4 Objektovˇe relaˇcní mapování . . . . . . . . . . . . . .
4.4.1 Java Persistence API . . . . . . . . . . . . . .
4.4.2 Návrh perzistentní vrstvy . . . . . . . . . . .
4.4.3 Mapování hierarchie dˇediˇcnosti . . . . . . .
5 Architektura a Implementace . . . . . . . . . . . . . . . .
5.1 JavaServer Faces . . . . . . . . . . . . . . . . . . . . .
5.1.1 Dynamické vytváˇrení stromu komponent . .
5.1.2 Vazba komponent a Backing bean koncept .
5.1.3 Problémy s JSF 2.0 . . . . . . . . . . . . . . .
5.2 Aplikaˇcní rámec ICEfaces . . . . . . . . . . . . . . .
5.3 HTML5 táhni a pust’ . . . . . . . . . . . . . . . . . .
5.4 Diagram nasazení . . . . . . . . . . . . . . . . . . . .
6 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A Zdrojové kódy aplikace pro torbu webových formuláˇru˚
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
2
4
7
7
8
10
10
11
18
23
23
26
27
28
29
30
31
38
38
40
42
44
45
46
50
53
57
58
vi
Kapitola 1
Úvod
Se vzrustajícím
˚
významem internetu a pˇresunem funkcí a služeb do webového rozhraní
vzrustá
˚
i potˇreba obousmˇerné komunikace. Primárním prvkem pro obousmˇernou komunikaci na webu jsou webové formuláˇre. Bohužel, vytváˇrení a správa kvalitních formuláˇru˚ není
zdaleka triviální záležitostí. Vyžaduje to velmi dobrou znalost jazyka HTML, JavaScriptu a
pravdˇepodobnˇe i mnoha dalších technologií na serverové stranˇe. I pro zkušeného webového
vývojáˇre není vytvoˇrení kvalitního webového formuláˇre samozˇrejmostí. Zvláštˇe, pokud má
být integrován s dalšími aplikacemi a technologiemi.
Tématem této práce je vytvoˇrit systém pro tvorbu a správu webových formuláˇru.
˚ Aby
byl systém pˇrínosný a progresivní, pokusím se pˇri jeho tvorbˇe použít moderní postupy a
technologie. Klíˇcová a charakteristická služba systému, tedy dynamické vytváˇrení a uchovávání struktury formuláˇru,
˚ je sama o sobˇe netriviální funkcionalitou. Pro její implementaci
použiji moderní webový rámec JavaServer Faces verze 2.1 (zkrácenˇe JSF). Tuto technologii
prezentaˇcní vrstvy využiji až na hranici jejich možností. Budu muset nalézt a popsat spolehlivý postup, jak realizovat tento obtížný avšak užiteˇcný zpusob
˚
užití JSF.
V úvodní cˇ ásti se budu zabývat prostˇredím existujících aplikací pro tvorbu webových
formuláˇru.
˚ Popíši dostupné nástroje a jejich vlastnosti. Na tomto základˇe ozˇrejmím duvody
˚
pro tvorbu nové aplikace.
Následující kapitola ujasnuje
ˇ
požadavky kladené na novˇe vznikající nástroj. Popíši základní pˇrípady užití, nˇekteré z nich podrobnˇeji rozpracuji. Zmíním také iterativní a inkrementální metodologii vývoje, jež bude provázet celý proces tvorby webové aplikace.
V další cˇ ásti práce se vˇenuji poˇcáteˇcní analýze a návrhu vyvíjené aplikace. Souˇcasnˇe
popíši principy a technologie, které ovlivnují
ˇ základní strukturu a formu aplikace.
V závˇereˇcné cˇ ásti se již vˇenuji specifikum
˚ samotné implementace, duležitým
˚
technologiím a aplikaˇcním rámcum,
˚
zejména prezentaˇcní vrstvy. Vyzdvihnu zajímavé momenty a
nové postupy, jež by mohly být pro cˇ tenáˇre používajícího zvolené technologie pˇrínosné a
obohacující. Zmíním nˇekteré problémy, se kterými jsem se setkal.
1
Kapitola 2
Webové nástroje pro tvorbu a publikování formuláˇru˚
V prostˇredí Internetu lze nalézt množství rozmanitých nástroju˚ pro vytváˇrení a správu
webových formuláˇru.
˚ Mnoho z nich se specializuje na tvorbu pruzkum
˚
u,
˚ dotazníku˚ nebo
anket, což do znaˇcné míry omezuje rozsah jejich použití. Jiné zustávají
˚
obecnˇe použitelné
pro tvorbu formuláˇrových vstupu˚ všech druhu˚ (napˇríklad nástroj WuFoo 1 ). Tyto aplikace
lze rozdˇelit do dvou základních skupin: aplikace poskytované pouze jako služba (více v kapitole 2.1) a aplikace jež jsou k dispozici pro lokální nasazení. Nutno poznamenat, že software, jenž je dostupný pro klasické nasazení, je ve vˇetšinˇe pˇrípadu˚ možné provozovat v jistém smyslu i jako centralizovanou službu, at’ už privátní, cˇ i veˇrejnou. Existují i výjimky,
jež jsou poskytovány obˇema zpusoby
˚
(napˇríklad níže zmínˇený Journey Survey). Avšak vˇetšina aplikací je poskytována pouze formou služby. Tyto aplikace jsou cˇ asto také mnohem
propracovanˇejší. Lze nalézt velmi kvalitní nástroje, jako je napˇríklad výše zmínˇený WuFoo.
Bohužel jsou cˇ asto zpoplatnˇeny. Výjimkou jsou formuláˇre v rámci kanceláˇrského balíku Google Docs 2 . Jde o pomˇernˇe povedený systém s širokými možnostmi, který je zcela zdarma
a bez omezení. Jeho hlavní nevýhodou je to, že je k dispozici pouze jako služba.
2.1
Software jako služba
Software jako služba, dále jen SaaS , je zpusob
˚
distribuce software, kde jsou data a aplikace samotná uchovávány centrálnˇe. Uživatelé k software pˇristupují po síti prostˇrednictvím
tenkých klientu.
˚ Tento princip byl užíván již v dˇrevních dobách digitální výpoˇcetní techniky. Již v 60. letech spoleˇcnosti jako IBM vzdálenˇe pronajímaly výkon svých mainframu,
˚
nebo poskytovaly pˇrístup k centrálním databázím pro velké spoleˇcnosti [23]. V 90. letech
se tento koncept vyvinul v takzvané poskytování aplikaˇcních služeb, zkrácenˇe ASP 3 . Tato
služba umožnovala
ˇ
relativnˇe bezstarostný pronájem software. Do znaˇcné míry odpadla starost o infrastrukturu a údržbu aplikací. I malé spoleˇcnosti si mohly dovolit používat jinak
velmi nákladné aplikace a pohodlnˇe rozložit jejich cenu v cˇ ase. ASP bylo architektonicky
postaveno jako multiinstanˇcní , každý uživatel mˇel vzdálenˇe k dispozici vyhrazenu jednu
instanci aplikace. ASP se dále pˇriblížilo SaaS, tak jak je chápán dnes.
V posledních letech výraznˇe roste obliba i úspˇech SaaS [28] jež se podstatnˇe odlišuje od
ASP jak jej známe z 90. let. Hlavní díl na tom nejspíše nese technický a technologický po1. Dostupný na URL: <http://www.wufoo.com> (listopad 2011).
2. Dostupný na URL: <http://docs.google.com> (listopad 2011).
3. ASP – Application Service Providing
2
2.1. SOFTWARE JAKO SLUŽBA
krok. Výraznˇe se zvýšila kvalita i hustota Internetového pokrytí. Rozšíˇrení nových postupu˚
vývoje webových technologií, souhrnnˇe oznaˇcovaných pojmem Web 2.0, charakteristických
snadnou a pˇríjemnou obousmˇernou komunikací. Technologie AJAX 4 , která rozšíˇrila použitelnost webu a podstatnˇe zpˇríjemnila jeho rozhraní. Díky tomu mohl být centralizovaný
software plnohodnotnˇe implementován jako webová aplikace, což významnˇe podpoˇrilo pˇrístupnost a zjednodušilo nasazení. Témˇerˇ odpadají problémy se specifiky klientských zaˇrízení, potˇreba je pouze webový prohlížeˇc. Na rozdíl od multiinstanˇcního pˇrístupu ASP jsou
webové aplikace takzvanˇe multitenantní . To znamená, že jedna instance aplikace obsluhuje více klientu˚ zároven.
ˇ Tento princip dále snižuje náklady, protože snižuje nároky na
hardware a také usnadnuje
ˇ
údržbu, správu a nasazení. Aplikace jsou sice v jistém smyslu
komplikovanˇejší, nicménˇe tato architektura je již pomˇernˇe dobˇre zvládnuta. Dnes je SaaS
spoleˇcnˇe s PaaS a IaaS 5 oznaˇcován pojmem Cloud computing 6 . Cloud je v souˇcasnosti
velmi populární, až módní trend.
Mimo nesporných výhod má SaaS a Cloud obecnˇe i své nevýhody a úskalí. SaaS a multitenantní architektura nejsou pˇríliš pˇrívˇetivé k individuálním potˇrebám klientu.
˚ I když kvalitní moderní služby vˇetšinou jistou míru kustomizace nabízejí, nemohou dosáhnout úrovnˇe
klasických aplikací, u kterých je možné v pˇrípadˇe potˇreby prostˇe upravit zdrojový kód.
U multitenantního software, kde množství klientu˚ používá stejnou aplikaci, by byl stejný
pˇrístup stˇeží realizovatelný, nebo by jednoduše bylo rentabilnˇejší nasadit zvlášt’ pro konkrétního klienta upravenou verzi software. Proto muže
˚ být integrace SaaS rˇ ešení do stávajícího prostˇredí klienta, at’ už procesního cˇ i softwarového pomˇernˇe obtížná.
Aplikace jsou umístˇeny v Cloudu, který se nachází potenciálnˇe velmi daleko od klienta.
S tím je nevyhnutelnˇe spojena jistá latence, proto SaaS není vhodný pro pˇrípady vyžadující
nízké reakˇcní doby. Nˇekdy je potˇreba vzdálenou aplikaci propojit s existujícími daty klienta,
pokud se ale jedná o data citlivá nebo velkého objemu, muže
˚ to být problém. Pˇrenos takových dat po veˇrejné síti nemusí být jednoduchý. Potenciálnˇe citlivá klientská data jsou
uložena na serveru poskytovatele, jde o to jak moc jsme ochotni mu duvˇ
˚ erˇ ovat. Muže
˚ se
jednat o privátní informace, které mohou být chránˇeny smlouvami nebo zákony. Napˇríklad
muže
˚ být nepˇrípustné tyto data poskytovat tˇretím stranám, tedy provozovateli SaaS.
V neposlední rˇ adˇe SaaS znamená velmi vysokou závislost na jeho poskytovateli, což je
ˇ
z filozofického hlediska významná slabina. Casto
není dostupná zkompilovaná aplikace,
natož pak její zdrojový kód. I pro pˇrípad, že provozovatel SaaS náhle pˇrestane fungovat,
napˇríklad zkrachuje. Richard Stallman7 se vuˇ
˚ ci SaaS staví velmi negativnˇe. Srovnává jej se
spyware a varuje pˇred libovulí
˚ jeho poskytovatelu˚ [21]. V míˇre nesvobody a závislosti tento
4. Asynchronous Javascript and XML – oznaˇcuje metody vývoje asynchronních webových aplikací, jež umožnují
ˇ ze stávající stránky zasílat a pˇrijímat data bez nutnosti opˇetovného naˇctení.
5. PaaS – Platform as a Service, jde napˇríklad hostování pˇredinstalovaného operaˇcního systému vˇcetnˇe potˇrebného software
IaaS – Infrastructure as a Service, napˇríklad o hostování reálných cˇ i, virtuálních serverových stroju˚ se specifikovanými parametry
6. Cloud – volnˇe pˇreloženo jako oblak
7. Zakladatel hnutí svobodného softwaru, projektu GNU a Free Software Foundation. Je také spoluzakladatelem League for Programming Freedom.
3
ˇ
2.2. FORMULÁ ROVÉ
APLIKACE K LOKÁLNÍMU NASAZENÍ
koncept posunuje hranice a pˇrekonává klasický proprietární software. Pro snížení rizik je
tedy potˇreba zajistit spolehlivý postup pro pˇrípadné opuštˇení služby. Také je vhodné, kriticky duležitá
˚
data pravidelnˇe zálohovat na lokální úložištˇe.
Samozˇrejmˇe, pokud nemáme pˇrístup k Internetu, nemáme pˇrístup ke svému software a
vˇetšinou ani k aktuálním datum.
˚
2.2
Formuláˇrové aplikace k lokálnímu nasazení
V této cˇ ásti struˇcnˇe popíši nástroje pro tvorbu a správu webových formuláˇru,
˚ jež se mi podaˇrilo nalézt. Uvádím pouze software, jenž je k dispozici k lokálnímu nasazení. Existuje
nemalé množství online aplikací, z nichž nˇekteré jsou velmi povedené. Pro konkrétní pˇrípady to mohou být ideální nástroje. Jak jsem však uvedl v pˇredcházející kapitole 2.1, mají
významné nedostatky. Nelze tedy rˇ íci, že by byly univerzálnˇe použitelné. Aplikace jež jsou
dostupné k lokálnímu nasazení, netrpí filozofickými ani praktickými nedostatky, specifickými pro SaaS. Pˇritom je možné tyto aplikace provozovat napˇríklad pomocí PaaS a tím získat znaˇcnou cˇ ást pozitiv SaaS. Pozitiva klasických aplikací dále rostou, pokud je dostupný
jejich zdrojový kód a je možné jej modifikovat dle vlastních potˇreb (OpenSource). To jsou
duvody,
˚
proˇc v této práci porovnávám pouze služby, jež jsou dostupné asponˇ v binární podobˇe, v lepším pˇrípadˇe jsou OpenSource.
VTSurvey Nástroj vyvinutý na Virginia Polytechnic Institute and State University (VirginiaTech). Bohužel, poslední verze je z roku 2005, i pˇresto je nástroj na této univerzitˇe
stále používán. Rozhraní a možnosti nástroje odpovídají dobˇe vzniku. GUI je velmi
strohé, nepodporuje AJAX, ani jiné prvky moderního webu. Zarážející je fakt, že nástroj nevyužívá žádný databázový systém. Veškerá persistence je rˇ ešena serializací
souboru˚ ve formátu XML.
Dostupný na URL: <http://vtsurvey.sourceforge.net/> (listopad 2011).
Journey Sourveys Webová aplikace je implementována pomocí moderního webového frameworku Ruby on Rails (*Odkaz, vysvˇetlení). Z webu projektu je patrné, že Journey
je na rozdíl od VTSurvey pomˇernˇe aktivnˇe vyvíjen. Bohužel, tato aplikace je úzce specializována na provádˇení pruzkum
˚
u.
˚ Produktem je webová stránka s dosti rigidní
strukturou. Existuje pomˇernˇe omezené množství elementu,
˚ jež lze na této stránce
použít. Tyto elementy jsou navíc výraznˇe specializovány pro tvorbu pruzkum
˚
u.
˚ Ke
všemu tato aplikace nijak neusnadnuje
ˇ
integraci výsledných dotazníku˚ do stávajících
webových stránek.
Dostupný na URL: <http://www.journeysurveys.com/> (listopad 2011).
Opina Opina je webová aplikace postavená na platformˇe Java. Ze screenshotu˚ vypadá nadˇejnˇe, bohužel je vše lokalizováno do španˇelštiny, vˇcetnˇe dokumentace a zdrojových
4
ˇ
2.2. FORMULÁ ROVÉ
APLIKACE K LOKÁLNÍMU NASAZENÍ
kódu.
˚ K demu aplikace se mi ani po nˇekolika pokusech nepodaˇrilo pˇrihlásit. Stáhl
jsem tedy zdrojové kódy a pokusil se zprovoznit aplikaci lokálnˇe, ale ani po nˇekolika
hodinách jsem nebyl úspˇešný. Svuj
˚ díl na tom nejspíše nesla i dokumentace, dostupná
pouze ve španˇelštinˇe. Uvedené obtíže, v kombinaci s mizivým množstvím zmínek
o této aplikaci na webu, mˇe nutí oznaˇcit tento nástroj jako nepoužitelný.
Dostupný na URL: <http://clinker.klicap.es/projects/opina> (listopad
2011).
LimeSurvey LimeSurvey je opravdu mocný nástroj pro správu a vytváˇrení mnoha ruzných
˚
typu˚ formuláˇru˚ a pruzkum
˚
u.
˚ Projekt se muže
˚ chlubit nejrozsáhlejší uživatelskou základnou ze všech zmínˇených. Administrátorské rozhraní umožnuje
ˇ
podrobnou kustomizaci vytváˇrených formuláˇru˚ a nabízí opravdu mnoho funkcí na pokroˇcilé úrovni.
Bohužel pˇrednost tohoto nástroje je do urˇcité míry i jeho slabinou. Uživatelské rozhraní je pomˇernˇe komplikované a na první pohled nepˇrehledné. To vyplývá z primárního zamˇerˇ ení tohoto nástroje, tedy vytváˇrení a správa dotazníku˚ na profesionální
úrovni, a z potˇreby nabídnout rozsáhlou funkcionalitu. Nástroj se také do znaˇcné
míry specializuje na vytváˇrení komplexních dotazníku.
˚ Pro oblast jednoduchých formuláˇru˚ a vstupních polí není pˇríliš vhodný.
Dostupný na URL: <http://www.limesurvey.org> (listopad 2011).
MachForms Jedná se o velmi pˇeknou aplikaci, vhodnou pro tvorbu formuláˇru˚ všeho druhu.
Není tedy specializovaná na dotazníky jako vˇetšina pˇredešlých, které jsem výše zmínil. Je implementována v jazyce PHP. Zatím chybí pokroˇcilé funkce pro manipulaci
se sesbíranými daty a pro jejich grafickou vizualizaci. Nejsou zatím implementovány
podmínˇená vstupní pole. Validace vstupu˚ je na základní úrovni (vstup lze vynutit
pouze jako povinný, nebo unikátní). Také zatím neexistuje žádné univerzální API pro
navázání dalšího software. Chybí i cˇ asové omezení vyplnování
ˇ
formuláˇre. To všechno
jsou ale pomˇernˇe pokroˇcilé funkce, jejich absence rozhodnˇe není ostudou. Jinak aplikace nabízí vˇetšinu základní funkcionality, jež je dostaˇcující pro bˇežné použití. Mimo
jiné je k dispozici ochrana formuláˇru˚ heslem, nebo omezení vyplnˇení jednoho formuláˇre pro IP adresu. Nejvˇetší nevýhodou tohoto rˇ ešení je, že se jedná o klasický
proprietární software. Je distribuován za ne pˇríliš vysokou úplatu.
Dostupný na URL: <http://www.appnitro.com/machform> (listopad 2011).
To jsou nejperspektivnˇejší nástroje, ze spektra software pro tvorbu formuláˇru,
˚ které se mi
podaˇrilo nalézt. Pˇrekvapivˇe, kvalitních nástroju,
˚ jež by byly k dispozici jinak než online, je
pomˇernˇe málo. Pokud už takový najdu, vˇetšinou se nejedná o systém, který by byl vhodný
pro jednoduchou tvorbu širokého spektra formuláˇru.
˚ Nástroje jsou vˇetšinou specializovány
pro tvorbu pruzkum
˚
u˚ a jejich funkcionalita je tomu podˇrízena. Od toho se odvíjí i rozvržení
a design jejich uživatelského rozhraní. Tyto rozhraní cˇ asto lépe cˇ i huˇ
˚ re plní svuj
˚ primární
5
ˇ
2.2. FORMULÁ ROVÉ
APLIKACE K LOKÁLNÍMU NASAZENÍ
úˇcel rozhraní pro tvurce
˚
profesionálních elektronických pruzkum
˚
u.
˚ Pokud uživatel nástroji
vˇenuje cˇ as, dobˇre se s ním seznámí a prozkoumá ho, pak se mu s ním pracuje dobˇre. Zvláštˇe
pokud pruzkumy
˚
tvoˇrí cˇ asto. Pokud se ovšem jedná o laika, který potˇrebuje na svuj
˚ web
umístit formuláˇr, uživatelské prostˇredí na nˇej bude pravdˇepodobnˇe pusobit
˚
neintuitivnˇe až
odpudivˇe. Pokud zrovna nechce vytvoˇrit dotazník pro elektronický pruzkum,
˚
bude nejspíš
se systémem trochu bojovat aby jej „ohnul“ pro své potˇreby. Výjimkou je poslednˇe zmínˇený
systém MachForms. Ten je bohužel zpoplatnˇený a nejsou k dispozici jeho zdrojové kódy
(OSS).
Rozhodl jsem se tedy vytvoˇrit webovou aplikaci, která by tuto mezeru zaplnila.
6
Kapitola 3
Analýza požadavku˚
V této kapitole se pokusím specifikovat funkˇcní a nefunkˇcní požadavky na aplikaci, kterou
vytvoˇrím jako souˇcást této práce. Požadavky pojmu pomˇernˇe velkoryse s vˇedomím, že se
mi je nejspíše nepodaˇrí všechny splnit. Také se muže
˚ stát, že se nˇekteré z nich bˇehem implementace ukážou jako velmi obtížnˇe realizovatelné. Nicménˇe, stále mohou sloužit pro lepší
vystižení smˇeru, kterým by se aplikace mˇela ubírat. Lze je použít pro naplánování pˇrípadných dalších milníku˚ vývoje.
Požadavky byly vytyˇceny na základˇe zkušeností z mé osobní praxe pˇri vývoji webových
aplikací. Dalším zdrojem inspirace byly požadavky bˇežných uživatelu˚ webových aplikací a
Internetu obecnˇe. Pˇri specifikaci jsem se také rˇ ídil funkcemi, jež mˇe zaujaly na dostupných
nástrojích, nebo mi u nich naopak chybˇely. Uživatelská fóra se ukázaly jako bohatý zdroj
nápadu˚ a požadavku.
˚
Pˇri specifikaci jsem kladl duraz
˚
na univerzálnost výsledného produktu. Požadavky rozdˇeluji na funkˇcní a nefunkˇcní, pˇriˇcemž zvláštˇe pro nefunkˇcní požadavky se mi nepodaˇrilo
1 . Následnˇ
najít žádný nástroj, který by je ve vˇetší míˇre naplnoval
ˇ
e prezentuji diagram pˇrípadu˚ užití, který by mˇel dále osvˇetlit požadované funkce systému. Popíši vnˇejší aktéry interagující se systémem a jednotlivé pˇrípady užití, které v rámci systému vykonávají.
3.1
Funkˇcní požadavky
Funkˇcní požadavky popisují funkce jež má software vykonávat. Obvykle rˇ íkají co má systém dˇelat, jak konkrétnˇe se má chovat.
Dostupnost velkého množství formuláˇrových prvku˚ Pro stavbu formuláˇru˚ bude k dispozici široká škála vstupních polí vˇcetnˇe nových prvku˚ standardu HTML5. Elementy
standardu HTML5 budou využívat záložní mechanizmus emulace pomocí JavaScriptu
v pˇrípadˇe, že nebudou podporovány prohlížeˇcem. Bude možné také využít pˇredpˇripravené specializované prvky, skládající se z jednoho, nebo více vstupních polí, pro
zjednodušení cˇ asto se opakujících pˇrípadu,
˚ jako jsou: Zadání adresy, vyplnˇení data
narození, vstup e-mailu a podobnˇe. Do aplikace bude možné snadno nahrávat nové
implementace ruzných
˚
vstupních polí, nebo si uložit vlastní konfigurace cˇ asto pou1.
Stav platný k rˇ íjnu 2011.
7
ˇ
3.2. NEFUNK CNÍ
POŽADAVKY
žívaných vstupu.
˚ Mimo elementy pro vstup budou k dispozici také doplnkové
ˇ
elementy pro logické strukturování formuláˇre, jako je komponenta pro seskupení vstupních polí, stránkování, textový panel atd. Díky tomu bude možné vytváˇret velmi univerzální formuláˇre a jiné uživatelské vstupy, jako jsou registrace, pˇrihlášky, kontaktní
formuláˇre a podobnˇe. V budoucnu snad bude možné systém použít pro implementaci
internetových plateb.
Podmínˇené zobrazení polí V systému bude možné pomocí jednoduchých pravidel nastavit oblasti formuláˇre, které se budou zobrazovat v závislosti na hodnotˇe, zvolené v nˇekterém z pˇredešlých vstupních polí. Jde o pokroˇcilou funkci, jež bývá cˇ asto vyžadována nároˇcnˇejšími uživateli, kteˇrí se zabývají hlavnˇe tvorbou sociologických a jiných
pruzkum
˚
u.
˚
Práce s e-mailem, pˇreposílání vyplnˇených formuláˇru˚ Další z možností bude komunikace
prostˇrednictvím e-mailu. Bude možné nechat si uživatelská data pˇreposílat do své
schránky, automaticky zasílat e-mail pro ovˇerˇ ení vyplnˇených údaju,
˚ nebo jen automatizovanˇe zasílat zprávu, potvrzující vyplnˇení formuláˇre. Díky tomu, budou autoˇri
formuláˇru˚ moci rychle reagovat na každý novˇe vyplnˇený formuláˇr. Zasílání potvrzovacího odkazu znemožní zadávaní smyšlených e-mailových adres, což lze také využít
pro detekci automatizovaných robotu,
˚ kteˇrí by mohli být pro vyplnování
ˇ
zneužiti.
Správa formuláˇru˚ a vyplnˇených dat Uživatel samozˇrejmˇe potˇrebuje svá data nˇejakým zpu˚
sobem spravovat a mít o nich pˇrehled. Proto aplikace poskytne pˇríjemné administrátorské rozhraní pro správu existujících formuláˇru.
˚ Toto rozhraní také umožní pˇrehledné zobrazení sesbíraných dat. Data bude možné vizualizovat pˇrehlednými grafy,
nebo exportovat do formátu CVS a XML.
Uživatelské úˇcty Systém bude samozˇrejmˇe podporovat vytváˇrení zabezpeˇcených nezávislých uživatelských úˇctu.
˚ V rámci tˇechto úˇctu,
˚ budou uživatelé moci vytváˇret své formuláˇre a spravovat sesbíraná data.
3.2
Nefunkˇcní požadavky
Nefunkˇcní požadavky specifikují kritéria jež má systém dodržovat. Vˇetšinou neˇríkají, jak se
má systém chovat, spíše kladou omezení na to jaký má být, jaké podmínky má splnovat.
ˇ
Nefunkˇcní požadavky vlastnˇe doplnují
ˇ požadavky funkˇcní.
8
ˇ
3.2. NEFUNK CNÍ
POŽADAVKY
Intuitivní a pˇritažlivé GUI Systém v první rˇ adˇe poskytne pˇríjemné a intuitivní rozhraní
pro snadnou tvorbu webových formuláˇru.
˚ Pomocí „táhni a pust’“ (anglicky Drag
And drop, nebo jen DND) bude možné pohodlnˇe skládat formuláˇre z jednotlivých
vstupních polí nejruznˇ
˚ ejších druhu.
˚ V tomto prostˇredí by se mˇeli pomˇernˇe rychle zorientovat i naprostí laici, kteˇrí mají jen minimální, nebo žádné zkušenosti s tvorbou
webových stránek. Díky tomu bude moci aplikaci využít široké spektrum uživatelu˚
laiku,
˚ pro které by mˇela tato aplikace být nejvˇetším pˇrínosem. Mimo jiné, mi v tomto
jako zdroje inspirace slouží podaˇrený online formuláˇrový systém WuFoo a perspektivní aplikace Google forms.
Pˇrístupné a pˇrehledné formuláˇre Formuláˇre systémem vytvoˇrené budou v co nejvyšší míˇre
splnovat
ˇ
požadavky na pˇrístupnost a uživatelskou pˇrívˇetivost. Uživatel získá s vynaložením pomˇernˇe malého úsilí kvalitní a pˇríjemný webový formuláˇr. Vhodný design
se muže
˚
projevit zvýšením množství úspˇešnˇe vyplnˇených formuláˇru˚ až o cˇ tyˇricet
procent[20]. Tento prvek by mohl být lákavý i pro zkušené webové vývojáˇre, protože vytvoˇrit pˇríjemný a srozumitelný formuláˇr není úplnˇe jednoduché. Rozhodnˇe
je to obtížnˇejší než pár kliku˚ a tahu˚ myši. V tomto ohledu budu cˇ erpat, mimo svých
zkušeností, z výborné knihy Web Forms Design[20]. V této knize je mnoho ovˇerˇ ených postupu˚ a rad, jak vystavˇet kvalitní webový formuláˇr. Poznatky jsou cˇ erpány
z mnohaleté praxe spoleˇcností jako jsou Yahoo, nebo eBay.
Systém s otevˇreným kódem a svobodnou licencí Systém bude v souladu s principy OpenSource. To znamená, že zdrojový kód bude volnˇe ke stažení a licence bude umožnoˇ
vat jeho modifikaci a volné šíˇrení. Zdrojový kód bude možné zahrnout do jakékoliv
jiné aplikace, nebo softwarového systému, jež bude šíˇren pod stejnou licencí. Díky
tomu bude rozšíˇrena použitelnost systému. Pokud nˇekomu bude chybˇet funkcionalita, nebo nebude vyhovovat nˇekterá z vlastností, nic mu nebrání upravit systém pro
své potˇreby, pokud na oplátku své úpravy poskytne zpˇet.
Interoperabilita Integrace s ostatním software bude usnadnˇena zveˇrejnˇením webového API
postaveného na architektuˇre REST. Díky tomu, bude možné jednoduše a efektivnˇe
pˇristupovat k datum
˚ získaným prostˇrednictvím formuláˇru.
˚ Pˇrípadnˇe bude možné
stavˇet nové a konfigurovat stávající formuláˇre. Tím se podstatnˇe zvýší použitelnost
celého systému. V budoucnu muže
˚ být pˇristoupeno k vývoji komponent pro snadnou integraci formuláˇrové aplikace s konkrétními softwarovými systémy. K tomu je
ale potˇreba nejdˇríve získat informace a zkušenosti s praktickým využitím tohoto nástroje.
Škálovatelnost a udržovatelnost Systém bude napsán tak, aby umožnoval
ˇ
škálování zátˇeže a podporoval snadnou rozšiˇritelnost a udržovatelnost zdrojového kódu v bu9
ˇ
3.3. P RÍPADY
UŽITÍ
doucnu. Tyto dvˇe vlastnosti spolu cˇ asto bývají provázány. Zejména pˇri vývoji webových aplikací platí, že pro dobrou škálovatelnost a udržovatelnost musí být systém
vhodnˇe dekomponován na jednotlivé, co nejménˇe závislé, ale pˇritom vnitˇrnˇe kohezní
komponenty.
3.3
Pˇrípady užití
V této cˇ ásti práce uvedu diagram pˇrípadu užití. V diagramu je systém a jeho rozsah vymezen modrým obdélníkem. V rámci systému se nacházejí jednotlivé pˇrípady užití. Každý
pˇrípad užití je spojen bud’ pˇrímo, nebo prostˇrednictvím jiného pˇrípadu užití, s jedním nebo
více aktéry. Aktéˇri leží mimo hranice systému, se systémem však interagují prostˇrednictvím
pˇrípadu˚ užití.
3.3.1 Aktéˇri vystupující v systému
Se systémem mohou interagovat cˇ tyˇri ruzní
˚
aktéˇri. Pˇrihlášený uživatel a administrátor jsou
specializacemi nepˇrihlášeného uživatele. To znamená, že kromˇe asociovaných pˇrípadu˚ užití
mohou interagovat se systémem i prostˇrednictvím pˇrípadu˚ užití spojených s nepˇrihlášeným
uživatelem, i když to v systému není explicitnˇe vyznaˇceno.
Nepˇrihlášený uživatel Jakýkoliv uživatel, který nemusí být pˇrihlášen, mít úˇcet v systému,
nebo povˇedomí o systému. Tento uživatel pˇrichází do kontaktu se systémem, když
vyplnuje
ˇ
formuláˇre v systému vytvoˇrené. Pˇrihlášením se z tohoto uživatele stává Pˇrihlášený uživatel, nebo Administrátor.
Pˇrihlášený uživatel Hlavní aktér interagující se v systému. Tento uživatel má vytvoˇren aktivní úˇcet v systému a používá ho pro vytváˇrení a publikování formuláˇru.
˚ Pˇrihlášený
uživatel je vlastníkem tohoto úˇctu. Pˇrihlášený uživatel také prohlíží a manipuluje
s daty sesbíranými jeho formuláˇri.
Klient webových služeb systému Jde o jakoukoliv jinou entitu komunikující se systémem
prostˇrednictvím jeho rozhraní webových služeb. Primárnˇe by se mˇelo jednat o jiné
aplikace integrované s tímto systémem.
Administrátor Speciální typ uživatele, který má pravomoc manipulovat s úˇcty jiných uživatelu.
˚ A pˇrihlašovat se místo jiných uživatelu.
˚
10
ˇ
3.3. P RÍPADY
UŽITÍ
3.3.2 Scénáˇre pˇrípadu˚ užití
Protože bude systém budován iterativním inkrementálním zpusobem
˚
(viz 3.4), v rámci
prvních iterací naleznu a popíši pˇrípady užití pomocí takzvaných scénáˇru.
˚ Scénáˇre zachycují pomˇernˇe hrubé nestrukturované informaci. Tato forma mi pˇripadla pro prvotní popis
vhodná také vzhledem ke komplikovanosti nˇekterých pˇrípadu˚ (napˇríklad pˇrípad užití „Vytvoˇrit formuláˇr“). V následujících iteracích dojde k podrobnˇejšímu popisu vybraných pˇrípadu˚ užítí pomocí takzvaných toku˚ událostí.
Pro pˇrehlednost u každého pˇrípadu užití uvádím jeho prioritu a hlavního aktéra. Priorita
do znaˇcné míry urˇcuje poˇradí, ve kterém budou jednotlivé pˇrípady dále rozpracovávány a
vyvíjeny. Pˇrípady s nižší prioritou budou zaˇrazeny do dˇrívˇejších iterací. Priorita také urcˇ uje duležitost
˚
pˇrípadu˚ užití, ty s nízkou prioritou pravdˇepodobnˇe nebudou v rámci této
práce implementovány. V diagramu pˇrípadu˚ užití je priorita 1 vyznaˇcena zelenou, priorita
2 žlutou a priorita 3 cˇ ervenou barvou.
1. Autentizovat nebo autorizovat se k formuláˇri
Hlavní aktéˇri: Nepˇrihlášený uživatel
Scénáˇr: Nepˇrihlášený uživatel je na stránce s formuláˇrem, který vyžaduje nˇejakou
formu autentizace nebo autorizace. Pokud je formuláˇr chránˇen proti vícenásobnému vyplnˇení ze stejné IP adresy a formuláˇr již byl z uživatelovi IP adresy
vyplnˇen, zobrazí se informativní text a uživatel není k formuláˇri pˇripuštˇen.
V opaˇcném pˇrípadˇe uživatel pokraˇcuje k další autentizaci cˇ i autorizaci. Pokud
je formuláˇr chránˇen heslem, uživatel vyplní heslo. Pokud bylo heslo správné,
muže
˚ vyplnovat
ˇ
formuláˇr, v opaˇcném pˇrípadˇe je vyzván k opˇetovnému zadání.
Pokud formuláˇr vyžaduje autentizaci, uživatel zvolí z nabízených možností autentizace a pokusí se autentizovat. Pokud je autentizace úspˇešná, a uživatel je
pod danou identitou také autorizován, muže
˚ vyplnovat
ˇ
formuláˇr. V opaˇcném
pˇrípadˇe se uživatel vrací na zaˇcátek a je vyzván k opˇetovné autentizaci.
Priorita: 2
2. Vyplnit formuláˇr
Hlavní aktéˇri: Nepˇrihlášený uživatel
Scénáˇr: Nepˇrihlášený uživatel je na stránce obsahující formuláˇr a v pˇrípadˇe nutnosti
se k nˇemu úspˇešnˇe autorizoval, nebo autentizoval. Uživatel vyplnuje
ˇ
vstupní
pole formuláˇre. Jakmile je hotov, pokusí se odeslat formuláˇr. Pokud jsou všechny
údaje vyplnˇeny v souladu s požadavky formuláˇre, uživateli je zobrazen potvrzovací text, pˇrípadnˇe zaslán potvrzovací e-mail. Uživatel muže
˚ být také pˇresmˇerován na pˇredem urˇcenou stránku. Vyplnˇené údaje jsou uloženy do databáze,
11
ˇ
3.3. P RÍPADY
UŽITÍ
pˇrípadnˇe pˇreposlány na pˇredvolenou e-mailovou adresu. Pokud vyplnˇené údaje
nejsou v souladu s požadavky formuláˇre a uživatel se pokusí formuláˇr odeslat, je
zobrazen upozornující
ˇ
text, dokud nejsou opraveny všechny nekorektní vstupy.
Takový pokus o odeslání formuláˇre je také v systému zaznamenán, vˇcetnˇe údaju˚
ze všech vstupních polí.
Nepˇrihlášený uživatel muže
˚ kdykoliv bˇehem vyplnování
ˇ
formuláˇr opustit stisknutím tlaˇcítka storno. V tom pˇrípadˇe je uživateli zobrazen potvrzovací text, nebo
je pˇresmˇerován na pˇredem urˇcenou stránku. Tento pˇrípad je také v systému zaznamenán vˇcetnˇe obsahu všech vstupních polí. (Pokud se uživatel k formuláˇri
autentizoval, muže
˚ se k nˇemu vrátit pozdˇeji a dokonˇcit jej.)
Priorita: 1
3. Upravit vyplnˇený formuláˇr
Hlavní aktéˇri: Nepˇrihlášený uživatel
Scénáˇr: Nepˇrihlášený uživatel se autentizoval k formuláˇri, který již dˇríve cˇ ásteˇcnˇe
nebo úplnˇe vyplnil. Pˇritom bylo na tomto formuláˇri umožnˇeno mˇenit vyplnˇené
údaje po odeslání, nebo navázat na nedokonˇcené vyplnování.
ˇ
Uživateli je zobrazen formuláˇr s dˇríve vyplnˇenými údaji. Muže
˚ dále pokraˇcovat ve vyplnování
ˇ
stejnˇe jako ve scénáˇri „Vytvoˇrit formuláˇr“.
Priorita: 3
4. Potvrdit e-mailovou adresu
Hlavní aktéˇri: Nepˇrihlášený uživatel
Scénáˇr: Nepˇrihlášený uživatel vyplnil a odeslal formuláˇr, ve kterém bylo vstupní
pole pro e-mail s ovˇerˇ ením. Uživateli se zobrazí text upozornující
ˇ
na nutnost
ovˇerˇ it e-mailovou adresu prostˇrednictvím odkazu na ni zaslaným. Uživatel navštívením pˇríslušného odkazu úspˇešnˇe dokonˇcí vyplnování
ˇ
formuláˇre. Pokud
uživatel v cˇ asovém limitu odkaz nenavštíví, vyplnˇený dotazník je považován za
nedokonˇcený.
Priorita: 2
5. Vytvoˇrit úˇcet v systému
Hlavní aktéˇri: Nepˇrihlášený uživatel
12
ˇ
3.3. P RÍPADY
UŽITÍ
Scénáˇr: Nepˇrihlášený uživatel navštíví webové rozhraní systému a vybere volbu pro
založení nového úˇctu. Uživatel vyplní nutné pˇrihlašovací údaje jako je heslo a email. Uživatel potvrdí e-mailovou adresu navštívením odkazu na ni zaslaným.
Uživatel je nyní pˇrihlášen ke svému novému uživatelskému úˇctu.
Priorita: 1
6. Pˇrihlásit se do systému
Hlavní aktéˇri: Nepˇrihlášený uživatel
Scénáˇr: Nepˇrihlášený uživatel vyplní pˇrihlašovací údaje: e-mail a heslo. Pokud jsou
vyplnˇené údaje správné uživatel je pˇresmˇerován do privátní cˇ ásti systému. Z Nepˇrihlášeného uživatele se stává Pˇrihlášeným uživatelem, nebo Administrátorem, podle toho jaké pˇrihlašovací údaje zadal. Pokud pˇrihlašovací údaje nebyly
správné, uživatel je vyzván k opˇetovnému zadání.
Priorita: 1
7. Vytvoˇrit formuláˇr
Hlavní aktéˇri: Pˇrihlášený uživatel
Scénáˇr: Pˇrihlášený uživatel zvolí volbu pro vytvoˇrení nového formuláˇre. Uživatel je
pˇresmˇerován do prostˇredí pro tvorbu a úpravu formuláˇru.
˚ Chycením a tažením
uživatel umístí vhodné prvky na zvolená místa ve formuláˇri. Uživatel nakonfiguruje prvky pˇridané do formuláˇre a nastaví jejich atributy, jako jsou: Popisek,
nápovˇeda, omezení vstupu, CSS tˇrída atd. Uživatel nastaví jméno formuláˇre a
pˇrípadnˇe upraví nˇekteré z jeho nastavení, jako jsou: Layout popisku˚ formuláˇrových prvku,
˚ CSS tˇrídu, atd. Kdykoliv bˇehem tohoto procesu muže
˚ uživatel formuláˇr uložit. Formuláˇr je prubˇ
˚ ežnˇe ukládán a proto o provedené zmˇeny nepˇrijde, ani když z jakéhokoliv duvodu
˚
nedokonˇcí tvorbu formuláˇre. Uživatel muže
˚
v menu vybrat volbu pro úpravu textu, jenž má být uživateli vyplnujícímu
ˇ
formuláˇr zobrazen po úspˇešném odeslání formuláˇre a po opuštˇení formuláˇre bez
uložení. Uživatel zde také muže
˚ nastavit pˇresmˇerování pro obˇe tyto akce.
Priorita: 1
8. Editovat formuláˇr
Hlavní aktéˇri: Pˇrihlášený uživatel
13
ˇ
3.3. P RÍPADY
UŽITÍ
Scénáˇr: Pˇrihlášený uživatel vyhledá formuláˇr ze seznamu svých formuláˇru.
˚ Vybere
formuláˇr ze seznamu a tím je pˇresmˇerován do prostˇredí pro tvorbu a úpravu
formuláˇru.
˚ Uživatel dále upravuje formuláˇr stejnˇe jako v pˇrípadˇe užití „Vytvoˇrit
formuláˇr“.
Priorita: 2
9. Nastavit autentizaci a autorizaci k formuláˇri
Hlavní aktéˇri: Pˇrihlášený uživatel
Scénáˇr: Pˇrihlášený uživatel vyhledá formuláˇr ze seznamu svých formuláˇru˚ a zvolí
volbu pro úpravu autentizace formuláˇre, cˇ ímž je pˇresmˇerován na stránku pro
nastavení autentizace a autorizace. Uživatel muže
˚ vybrat jeden nebo více typu˚
autentizace, které chce pro formuláˇr nastavit. Uživatel pˇrípadnˇe nastaví adresu
webové služby, která autentizuje a autorizuje uživatelem zadaná data. Pokud
uživatel nastavil alesponˇ jeden zpusob
˚
autentizace, muže
˚ nyní zvolit, zda muže
˚
Nepˇrihlášený uživatel upravovat již odeslaný formuláˇr a zda se muže
˚
vracet
k cˇ ásteˇcnˇe vyplnˇenému formuláˇri.
Uživatel pˇrípadnˇe zvolí heslo pro autorizaci k formuláˇri a vybere, zda muže
˚ být
formuláˇr vyplnˇen vícekrát z jedné IP adresy.
Nakonec muže
˚
uživatel provedené zmˇeny uložit, nebo operaci stornovat bez
uložení.
Priorita: 2
10. Nastavit e-mailovou komunikaci existujících formuláˇru˚
Hlavní aktéˇri: Pˇrihlášený uživatel
Scénáˇr: Pˇrihlášený uživatel vyhledá formuláˇr ze seznamu svých formuláˇru˚ a zvolí
volbu pro nastavení e-mailové komunikace formuláˇre, tím je pˇresmˇerován na
stránku pro nastavení e-mailové komunikace. Uživatel nastaví e-mailovou adresu pro notifikace spojené s tímto formuláˇrem. Vybere zda mají být vyplnˇené
formuláˇre pˇreposílány na e-mail. Pokud byla pro formuláˇr nastavena autentizace, nebo formuláˇr obsahuje pole pro vstup e-mailové adresy. Pˇrihlášený uživatel muže
˚ zvolit, zda má být na adresu uživatele vyplnujícího
ˇ
formuláˇr zaslán
mail potvrzující vyplnˇení formuláˇre. Uživatel nastaví obsah mailu potvrzujícího
vyplnˇení formuláˇre.
Priorita: 1
14
ˇ
3.3. P RÍPADY
UŽITÍ
11. Nastavit dostupnost formuláˇre
Hlavní aktéˇri: Pˇrihlášený uživatel
Scénáˇr: Pˇrihlášený uživatel vyhledá formuláˇr ze seznamu svých formuláˇru.
˚ Uživatel
zvolí volbu pro nastavení dostupnosti formuláˇre a vybere jeden nebo více zpu˚
sobu,
˚ kterými má být formuláˇr zpˇrístupnˇen. Pokud vybere vložení do stránky,
zobrazí se text, který je tˇreba zkopírovat a vložit do pˇríslušné stránky. Pokud vybere zpˇrístupnˇení formuláˇre pod URL adresou zobrazí se fixní cˇ ást URL pˇridˇelená systémem spolu s variabilní cˇ ástí, kterou muže
˚ pˇrihlášený uživatel upravit.
Dále muže
˚ uživatel nastavit interval pˇrístupnosti/publikování formuláˇre. Interval vejde v platnost, jakmile uživatel uloží zmˇeny provedené v tomto pˇrípadu
užití. Pokud uživatel interval nenastaví, formuláˇr je publikován bez cˇ asového
omezení, jakmile uživatel zvolí volbu pro okamžité publikování, pokud již nebyl dˇríve publikován. Pokud formuláˇr již publikován byl, volba pro okamžité
publikování není dostupná. Místo toho je dostupná volba pro okamžité znepˇrístupnˇení/zastavení formuláˇre.
Priorita: 1
12. Prohlížet sesbíraná data
Hlavní aktéˇri: Pˇrihlášený uživatel
Scénáˇr: Pˇrihlášený uživatel vyhledá formuláˇr ze seznamu svých formuláˇru.
˚ Uživatel
zvolí prohlížení sesbíraných dat. Je mu zobrazena tabulka se sloupci pro každé
ze vstupních polí, navíc je zobrazen sloupec s cˇ asem vyplnˇení a délkou vyplnoˇ
vání formuláˇre. Každý rˇ ádek reprezentuje jedno vyplnˇení formuláˇre. Uživatel
muže
˚ vybrat konkrétní rˇ ádek pro detailní zobrazení vyplnˇených údaju.
˚ V detailu uživatel také vidí doplnující
ˇ
údaje jako jsou napˇríklad informace o klientovi jež vyplnil formuláˇr (verze operaˇcního systému, verze prohlížeˇce, IP adresa
atd.). Pokud formuláˇr vyžadoval autentizaci, uživatel v detailu vidí také podrobnosti o identitˇe uživatele jenž formuláˇr vyplnil.
Priorita: 1
13. Exportovat sesbíraná data
Hlavní aktéˇri: Pˇrihlášený uživatel
Scénáˇr: Pˇrihlášený uživatel vyhledá formuláˇr ze seznamu svých formuláˇru˚ a zvolí
export sesbíraných dat. Aby bylo možné zvolit export dat, musí formuláˇr obsahovat nˇejaká sesbíraná data. Uživatel nyní muže
˚ zvolit jeden z formátu˚ exportu
15
ˇ
3.3. P RÍPADY
UŽITÍ
dat (XML, CVS). Také muže
˚ zvolit zda chce obdržet komprimovaný soubor. Uživatel vybere formát a potvrdí export dat. Vzápˇetí je odeslán soubor s daty, jež
byly vyplnˇeny do formuláˇre.
Priorita: 3
14. Prohlížení vizualizací sesbíraných dat
Hlavní aktéˇri: Pˇrihlášený uživatel
Scénáˇr: Pˇrihlášený uživatel vyhledá formuláˇr ze seznamu svých formuláˇru˚ a zvolí
prohlížení sesbíraných dat. Zde uživatel vybere sloupec, jenž chce vizualizovat.
Data ve sloupci musí být ve tvaru pˇredvyplnˇených možností (multiple choice),
nebo se musí jednat o sloupec s cˇ asem odeslání formuláˇre. Zastoupení jednotlivých možností je zobrazeno v pˇrehledném barevném grafu. Uživatel muže
˚ volit
typ grafu jimž chce data vizualizovat (sloupcový, koláˇcový atd.). Sloupec s daty
vyplnˇení muže
˚ být zobrazen jako graf, znázornující
ˇ
poˇcty vyplnˇených formuláˇru˚ v po sobˇe jdoucích intervalech.
Priorita: 2
15. Odhlásit se ze systému
Hlavní aktéˇri: Pˇrihlášený uživatel, Administrátor
Scénáˇr: Pˇrihlášený uživatel nebo Administrátor v menu systému vyberou odhlášení
ze systému. Pokud se jednalo o Pˇrihlášeného uživatele nebo Administrátora,
který nebyl pˇrihlášen za žádného pˇrihlášeného uživatele, je pˇresmˇerován na
hlavní stránku. Pokud bude následnˇe chtít pˇristoupit k nˇejaké ze zabezpeˇcených
stránek nebo funkcí systému, je vyzván k zadání pˇrihlašovacích údaju.
˚ Pokud se
jednalo o Administrátora, jenž se pˇrihlásil k úˇctu nˇekterého pˇrihlášeného uživatele, je odhlášen z tohoto úˇctu a pˇresmˇerován zpˇet do svého administrátorského
prostˇredí.
Priorita: 1
16. Pˇrihlásit se místo jiného uživatele.
Hlavní aktéˇri: Administrátor
Scénáˇr: Administrátor je pˇrihlášen do systému, ale není pˇrihlášen k úˇctu žádného
z pˇrihlášených uživatelu.
˚ V seznamu uživatelu˚ vybere úˇcet uživatele a zvolí
pˇrihlášení. Nyní je administrátor pˇrihlášen k úˇctu uživatele a muže
˚ vykonávat
všechny akce, které muže
˚ vlastník tohoto úˇctu.
Priorita: 2
16
ˇ
3.3. P RÍPADY
UŽITÍ
17. Prohlížet seznam uživatelu.
˚
Hlavní aktéˇri: Administrátor
Scénáˇr: Administrátor je pˇrihlášen do systému, ale není pˇrihlášen k úˇctu žádného
z pˇrihlášených uživatelu.
˚ Administrátor vidí tabulkový výpis všech úˇctu˚ Pˇrihlášených uživatelu,
˚ ve kterém muže
˚ listovat.
Priorita: 2
18. Vypsat formuláˇre jež jsou k dispozici
Hlavní aktéˇri: Klient webových služeb systému
Scénáˇr: Klient webových služeb systému pošle dotaz pro vypsání všech formuláˇru˚
k dispozici. V tomto dotazu pošle zárovenˇ pˇrihlašovací údaje ke konkrétnímu
úˇctu v systému a specifikuje formát vypsaných dat (CVS, XML). Pokud jsou
pˇrihlašovací údaje v poˇrádku jsou zpˇet zaslána data, tvoˇrená základními údaji
o formuláˇrích jako jsou: Unikátní identifikátor formuláˇre, název, cˇ as vytvoˇrení,
stav zpˇrístupnˇení atd. Pokud pˇrihlašovací údaje nejsou v poˇrádku, systém vrátí
pˇríslušnou chybu.
Priorita: 3
19. Vypsat data vybraného formuláˇre
Hlavní aktéˇri: Klient webových služeb systému
Scénáˇr: Klient webových služeb systému pošle dotaz pro vypsání dat vybraného formuláˇre. V tomto dotazu pošle zárovenˇ pˇrihlašovací údaje ke konkrétnímu úˇctu
v systému, unikátní identifikátor formuláˇre (ID) a specifikuje formát vypsaných
dat (CVS, XML). Pokud jsou pˇrihlašovací údaje a ID v poˇrádku, jsou zpˇet zaslána data sesbíraná formuláˇrem v pˇríslušném formátu. Ke každé skupinˇe sesbíraných dat je pˇriˇrazen unikátní identifikátor konkrétního vyplnˇení formuláˇre.
Pokud pˇrihlašovací údaje nejsou v poˇrádku, systém vrátí pˇríslušnou chybu.
Priorita: 3
20. Vypsat data konkrétního vyplnˇení formuláˇre
Hlavní aktéˇri: Klient webových služeb systému
17
3.4. ITERATIVNÍ A INKREMENTÁLNÍ VÝVOJ
Scénáˇr: Klient webových služeb systému pošle pro vypsání dat konkrétního vyplnˇení formuláˇre. V tomto dotazu pošle zárovenˇ pˇrihlašovací údaje ke konkrétnímu úˇctu v systému, unikátní identifikátor formuláˇre (ID), unikátní identifikátor konkrétního vyplnˇení formuláˇre (IDF) a specifikuje formát vypsaných dat
(CVS, XML). Pokud jsou pˇrihlašovací údaje, ID a IDF v poˇrádku jsou zpˇet zaslána data konkrétního vyplnˇení vˇcetnˇe podrobností o vyplnˇení, jako jsou: cˇ as
vyplnˇení, doba vyplnování
ˇ
atd. Pokud pˇrihlašovací údaje nejsou v poˇrádku, systém vrátí pˇríslušnou chybu.
Priorita: 3
3.4
Iterativní a inkrementální vývoj
Inkrementální[22] vývoj spoˇcívá v tom, že si práci rozdˇelíme do menších cˇ ástí. Tyto cˇ ásti
pak postupnˇe vyvíjíme a integrujeme do sebe tak, že máme již velmi brzo v nˇejakém smyslu
funkˇcní projekt, který lze testovat a pˇrípadnˇe validovat se zákazníkem (iterativní vývoj).
Opakem je takzvaný big-bang pˇrístup, kdy se veškerá integrace a validace dˇeje až na úplném konci projektu[27]. V tu dobu se vˇetšinou zjistí, že se nˇekde na zaˇcátku stala chyba.
V lepším pˇrípadˇe je zákazníkovi doruˇceno nˇeco, co vlastnˇe nechtˇel. V horším pˇrípadˇe mu
není doruˇceno nic.
Iterativní vývoj spoˇcívá ve zkoumání, revidování a upravování toho co jsme již vytvoˇrili.
Bˇehem iterativního vývoje je pro tuto cˇ innost pevnˇe naplánován cˇ as a prostˇredky. Ideálnˇe je
dosavadní dílo konzultováno pˇrímo s jeho budoucím uživatelem.
Oba tyto principy jsou zcela nezávislé a mohou být použity zvlášt’, jak se také nˇekdy
bezdˇeky dˇeje. Avšak inkrementální a iterativní vývoj do sebe velmi hladce zapadají. Projekt
je rozdˇelen do nˇekolika pomˇernˇe krátkých iterací. V každé z nich je vždy implementován
jistý inkrement, který je následnˇe iterativnˇe revidován. Jednotlivé iterace jsou vlastnˇe miniaturními vodopády se všemi jeho aktivitami. V ruzných
˚
fázích projektu muže
˚ být v jednotlivých iteracích kladen duraz
˚
na ruzné
˚
aktivity. V poˇcátku nejvíce cˇ asu vyžaduje analýza
a design, pozdˇeji pˇrevládá samotná implementace, v koneˇcné fázi se pozornost pˇresune
k testování a integraci. Duležité
˚
je, že po každé iteraci je dostupný v jistém smyslu funkˇcní,
inkrementálnˇe zvˇetšený produkt, jenž lze pˇredvést a otestovat.
Typickými zástupci inkrementálních a iterativních metodik vývoje jsou:
Rational Unified Process (RUP) Rigorózní metodologie založená na metodice Unified Process (zkrácenˇe UP). Process byl vypracován a dukladnˇ
˚
e specifikován spoleˇcností IBM.
Jedná se o rozsáhlý procesní rámec, který je tˇreba pˇrizpusobit
˚
potˇrebám vývojového
týmu a konkrétního projektu. I když se obecnˇe uvádí, že je RUP vhodný pro všechny
typy projektu,
˚ dle mého názoru je takto rozsáhlý a precizní postup vhodný spíše pro
rozsáhlé projekty a velké vývojové týmy.
18
3.4. ITERATIVNÍ A INKREMENTÁLNÍ VÝVOJ
Scrum Scrum je opakem pˇrísné metodologie RUP. Jedná se o agilní flexibilní proces. Není
potˇreba rozsáhlá a podrobná dokumentace. Metodologii lze pomˇernˇe rychle zvládnout. Vývojové týmy by mˇely být pestré, schopné se samostatnˇe organizovat. Tento
zpusob
˚
vývoje je vhodný pro menší projekty, ale mˇel by být dobˇre použitelný i pro
projekty rozsáhlé.
Vývoj projektu˚ založený na tˇechto technikách je v dnešní dobˇe jednoznaˇcnˇe preferován[35].
Snad všechny úspˇešné moderní metodologie pro vedení nejen softwarových projektu˚ jsou
založeny na iterativním a inkrementálním procesu.
Diplomová práce byla vypracována v nˇekolika iteracích. V první iteraci jsem nalezl a
na základní úrovni popsal pˇrípady užití. V dalších iteracích jsem dle priority vybíral jednotlivé scénáˇre a rozpracovával je do strukturované podoby toku˚ událostí. Tento podrobný
popis mi byl dobrým podkladem pro následnou implementaci. Pro ukázku jsou uvedeny
dva významné pˇrípady užití.
V rámci této práce byly implementovány všechny pˇrípady užití s prioritou 1 a nˇekteré
s prioritou 2. Ostatní pˇrípady bych chtˇel postupnˇe implementovat na základˇe praktických
zkušeností s aplikací po odevzdání této práce.
19
3.4. ITERATIVNÍ A INKREMENTÁLNÍ VÝVOJ
Obrázek 3.1: Diagram pˇrípadu˚ užití
20
3.4. ITERATIVNÍ A INKREMENTÁLNÍ VÝVOJ
Obrázek 3.2: Tok událostí – Vytvoˇrit formuláˇr
21
3.4. ITERATIVNÍ A INKREMENTÁLNÍ VÝVOJ
Obrázek 3.3: Tok událostí – Vyplnit formuláˇr
22
Kapitola 4
Analýza a návrh
Jak bylo zmínˇeno, aplikace je vyvíjena iterativním a inkrementálním zpusobem.
˚
Proto analýza a návrh provázejí s mˇenící se intenzitou témˇerˇ celý proces jejího vývoje. Ke koneˇcné
specifikaci, cˇ i návrhu systému nedojde bˇehem relativnˇe krátkého ohraniˇceného nepˇrerušovaného cˇ asového úseku. Prvotní jednoduchá abstraktní specifikace se postupnˇe reviduje,
formalizuje a nabývá detailnosti [31].
To platí zvláštˇe pokud je systém vyvíjen pomocí iterativní a inkrementální metodologie,
kde má každá iterace svou analytickou a návrhovou cˇ ást. V každé iteraci jsou specifikace
a návrh opravovány v reakci na zkušenosti z vývoje v pˇredešlé iteraci a na základˇe verifikace dosavadních výsledku˚ se stakeholdery 1 . Je dále formalizována a elaborována cˇ ást
specifikace, jež má být v souˇcasné iteraci implementována.
Bylo by pomˇernˇe naivní pˇredpokládat podrobné nemˇenné a úspˇešné navržení systému
jednorázovˇe na zaˇcátku vývoje. Takovýto postup je reálnˇe použit snad jen pˇri vývoji formálních verifikovatelných systému,
˚ kde je kladen duraz
˚
na jejich bezchybnost. Jedná se však
o systémy, u kterých je pˇredem známé a jednoznaˇcnˇe definované chování. Tímto zpusobem
˚
je možné vyvíjet jen software velmi omezeného rozsahu, vynaložené prostˇredky naopak
pˇríliš omezení nesnesou.
V této kapitole se pokusím blíže analyzovat a navrhnout jádro software jež má vzniknout jako souˇcást této práce. Zaˇcnu vysokoúrovnovým
ˇ
konceptuálním modelem domény
pro ujasnˇení základní pˇredstavy o struktuˇre systému. Dále budu pokraˇcovat na nižší úrovni
podrobnˇejším modelem tˇríd. Popíši objektovˇe relaˇcní mapování, jež rˇ eší pˇrechod mezi objektovým svˇetem programovacích jazyku˚ a relaˇcním svˇetem databázových systému.
˚ Výstupy
z této kapitoly mi budou sloužit jako základní podklady pro další vývoj a orientaci v systému.
4.1
Aplikaˇcní rámec Spring a Dependency injection
V aplikaci jež má vzniknout jako souˇcást této práce je pomˇernˇe intenzivnˇe využíván aplikaˇcní rámec Spring. Spring toho má velmi mnoho co nabídnou v mnoha oblastech vývoje
nejen webových aplikací. Hlavní devizou tohoto rámce, která se odráží v architektuˇre a prochází napˇríˇc celou aplikací je správa a distribuce závislostí.
1. Stakeholdeˇri jsou všechny strany nˇejak zainteresované ve výsledném produktu. Vˇetšinou se jedná o zákazníky, nebo koneˇcné uživatele.
23
ˇ
4.1. APLIKA CNÍ
RÁMEC SPRING A DEPENDENCY INJECTION
Framework Spring patˇrí do stále populárnˇejší skupiny aplikaˇcních rámcu,
˚ obvykle oznacˇ ovaných jako Inversion of Control (zkrácenˇe IoC) kontejnery. Toto oznaˇcení je však hojnˇe
rozšíˇrený pleonazmus. Je zvláštní, pokud je v souvislosti s aplikaˇcními rámci explicitnˇe zminován
ˇ
návrhový vzor IoC [29]. Je to podobné, jako bych se chlubil, že mé auto má cˇ tyˇri kola.
IoC, barvitˇeji oznaˇcován také jako Hollywoodský princip 2 , je obecná vlastnost aplikaˇcních
rámcu,
˚ tím se pojem aplikaˇcní rámec odlišuje od prosté knihovny.
Pokud v aplikaci používáme knihovnu, prostˇrednictvím API voláme v ní pˇripravené
funkce. Jakmile funkce skonˇcí, vrací zpˇet kontrolu nad bˇehem programu. Podobným zpu˚
sobem funguje jednoduchá interakce s uživatelem na pˇríkazové rˇ ádce.
Zde je bˇeh plnˇe pod kontrolou programátora, který postupnˇe diktuje co a jak se má stát.
Tento zpusob
˚
vytváˇrení programu˚ je typický pro jednoduché lineární aplikace. Není pˇríliš
vhodný pro složitˇejší rozvˇetvené pˇrípady užití.
Opakem je aplikaˇcní rámec, který tvoˇrí kostru programu a do znaˇcné míry rˇ ídí jeho
bˇeh. Programátor používající aplikaˇcní rámec píše funkce, které jsou tímto rámcem volány
a používány. Tyto funkce pak vytváˇrejí a profilují samotnou aplikaci. Existuje rˇ ada zpu˚
sobu˚ jak této inverze dosáhnout. Mužeme
˚
použít pˇrihlašování k událostem, uzávˇery, nebo
ˇ
implementovat pˇripravené rozhraní. Casto
uvádˇeným pˇríkladem IoC je práce s grafickým
okenním rozhraním. V tomto pˇrípadˇe vytvoˇríme takzvané listenery, které registrujeme pro
vybrané události na vybraných grafických komponentách. Jakmile je vyvolána událost, uživatel napˇríklad vyplní vstupní pole, je zavolána naše implementace listeneru[7].
Rámec Spring v souˇcasné verzi 3.1 je již velmi rozsáhlým projektem. Jde o jeden z nejpopulárnˇejších a technologicky nejvyspˇelejších javových rámcu.
˚ K tomuto statusu Springu
3
znaˇcnˇe pomohly nedokonalosti a slabiny platformy JavaEE , které velmi dobˇre rˇ eší. V dnešní
dobˇe je pˇri inovaci platformy JavaEE inspirace cˇ asto hledána právˇe ve Springu. To jen potvrzuje kvalitu a vhodnost konceptu˚ a návrhových vzoru˚ ve Springu použitých.
Pod pojmem Spring se skrývá velké množstvím komponent a modulu.
˚ Mimo jiné se
jedná o Spring AOP tedy podpora pro aspektovˇe orientované programování velmi podobné
rámci AspcetJ. Spring Data usnadnuje
ˇ
práci s datovými úložišti všeho druhu, podporuje
ORM, OXM, JDBC, objektové databáze a mnoho dalších. Spring data také poskytuje deklarativní rˇ ízení transakcí abstrahované od konkrétní implementace. Spring Security, jak název
napovídá, rˇ eší autentizaci, autorizaci a další problematiku zabezpeˇcení aplikace. Spring web
services usnadnuje
ˇ
práci s webovými službami.
Všechny moduly Springu však tˇesnˇeji cˇ i volnˇeji navazují na základní komponentu Spring
core. Tato komponenta poskytuje základní prostˇredí. Je zde implementován kontejner pro
charakteristickou podskupinu vzoru IoC, takzvané Dependency Injection (zkrácenˇe DI), neboli vkládání závislostí [6]. Vkládání závislostí pomáhá snižovat vzájemnou provázanost
jednotlivých komponent systému. Tím zvyšuje testovatelnost a znovupoužitelnost jednotlivých komponent. Jednotlivé komponenty tak mohou být více zamˇerˇ eny na problémovou
doménu, staˇcí když deklarují své závislosti. V ideálním pˇrípadˇe deklarují závislost pouze
2. Hollywoodský princip, cˇ ili: „Nevolejte nám, my zavoláme vám!“ [33]
3. JavaEE neboli Java Enterprise Edition, dˇríve také J2EE. Platforma pro vývoj podnikových aplikací a Informaˇcních systému.
˚
24
ˇ
4.1. APLIKA CNÍ
RÁMEC SPRING A DEPENDENCY INJECTION
na rozhraních a mohou tak být použity v ruzných
˚
aplikacích s ruznými
˚
implementacemi
tˇechto rozhraní.
Obrázek 4.1: Schéma vkládání závislostí kontejnerem
V návrhovém vzoru vkládání závislostí vystupují nejménˇe tˇri základní elementy:
•
Závislá komponenta Jde o ucelenou cˇ ást kódu závisející na jiných komponentách.
•
Deklarace závislostí Deklarace závislostí dané závislé komponenty. Ve Springu mohou být tyto závislosti deklarovány v samostatném XML souboru, nebo novˇeji pomocí anotací pˇrímo v kódu.
•
Kontejner Rámec, který se v rámci svého kontextu postará o vložení závislostí implementující správná rozhraní na správná místa. Jedná se právˇe o Spring Core.
Aby ve Springu fungovalo vkládání závislostí na správná místa, je vˇetšinou potˇreba, aby
jak závislá komponenta tak vkládaný objekt, byly pod správou Springu. Objekty ve správˇe
Springu bývají oznaˇcovány jako takzvané beany. Beanu lze nadeklarovat v samostatném
konfiguraˇcním XML souboru, nebo novˇeji pomocí anotací.
Existují tˇri zpusoby
˚
vkládání závislostí
•
Vkládání pˇre setter Kontejner vkládá závislosti pomocí settru˚ jednotlivých promˇenných. Tento zpusob
˚
je Springem preferován.
25
4.2. MODEL PROBLÉMOVÉ DOMÉNY
•
Vkládání pˇres konstruktor Kontejner vkládá závislosti prostˇrednictvím parametru˚
konstruktoru. Tento zpusob
˚
je Springem také podporován, není ovšem tak cˇ astý.
•
Vkládání pomocí rozhraní Závislá komponenta musí implementovat rozhraní pro
vložení závislosti. Spring tento zpusob
˚
DI nepodporuje. Pˇríkladem rámce podporujícího tento druh vkládání je Avalon.
Alternativnˇe lze vložení závislostí dosáhnout jejich vyhledáním v kontextu kontejneru pˇrímo
v kódu závislé komponenty. To však není doporuˇcováno, protože to s sebou nese zbyteˇcnou
závislost na kontextu kontejneru a kód, který pˇrímo nesouvisí s problematikou jíž se má
komponenta vˇenovat.
4.2
Model problémové domény
Model problémové domény je vlastnˇe velmi jednoduchý model, který zachycuje významné
pojmy z aplikaˇcní domény a vztahy mezi nimi. Popisuje klíˇcové koncepty duležité
˚
pro pocˇ áteˇcní pˇredstavu o rˇ ešeném problému.
Obrázek 4.2 zachycuje základní model problémové domény. Stˇredem celého systému
je model formuláˇre reprezentovaný entitou Formuláˇr. Formuláˇr v sobˇe uchovává globální
nastavení a vlastnosti vázané na celý formuláˇr. Jedná se napˇríklad o rˇ ízení pˇrístupu, emailovou komunikaci, autentizaci, nastavení vzhledu a tak dále.
Model formuláˇre se skládá z jednotlivých prvku.
˚ Prvky se dˇelí na dva základní druhy.
Vstupní pole slouží k zadávání dat uživatelem. Jde tedy o ruzné
˚
formuláˇrové vstupy. Pro
zaˇcátek jsou uvedeny tˇri základní typy: Klasický textový vstup, výbˇer z možností a vstup
pro nahrání souboru. Samozˇrejmˇe se nejedná o kompletní výˇcet všech možností, který by
v tomto modelu, jenž má pˇrehlednˇe znázornit strukturu systému, pusobil
˚
nepˇrehlednˇe a
rušivˇe. V budoucnu pravdˇepodobnˇe mnoho dalších typu˚ vstupních polí pˇribude. Ostatní
prvky jež neslouží k uživatelskému vstupu jsou hlavnˇe doplnkové
ˇ
formátovací a textové
vstupy. Významnˇejší postavení mezi nimi má Kontejner, který slouží ke cˇ lenˇení formuláˇre
do logických podskupin. Kontejner v sobˇe zahrnuje ostatní prvky formuláˇre, které tím logicky a vˇetšinou i vizuálnˇe oddˇeluje.
Jakmile je model formuláˇre se všemi jeho prvky zkonstruován, muže
˚ být publikován a
uživatelé jeho vyplnˇením odesílají data, která jsou v systému uchována. Pro reprezentaci
tˇechto dat slouží dva základní objekty. Prvním z nich je Vyplnˇení formuláˇre, které v sobˇe
uchovává data o konkrétním vyplnˇeném formuláˇri, jako jsou cˇ as vyplnˇení, veškeré dostupné informace o uživateli jenž formuláˇr vyplnil atd. Tento prvek také seskupuje údaje
z jednotlivých vstupních polí pomocí Vyplnˇených údaju.
˚ Dalším prvkem je vyplnˇení konkrétního vstupního pole, tedy výše zmínˇený Vyplnˇený údaj. Jedná se o data uživatelem
zadaná do konkrétního vstupního pole v rámci daného Vyplnˇení formuláˇre. Data v tˇechto
vyplnˇených polích nabývají typu dle vstupního pole pro nˇež uchovávají zadané vstupní
hodnoty. Mimo to mohou být paralelnˇe uchována v textových rˇ etˇezcích, díky cˇ emuž mohou
také zaznamenat nevalidní data, neúspˇešnˇe vyplnˇených formuláˇru.
˚ To umožnuje
ˇ
tvurci
˚ for26
ˇ
4.3. MODEL T RÍD
Obrázek 4.2: Konceptuální model domény systému pro tvorbu formuláˇru˚
muláˇre vyhodnotit formuláˇr a pˇrípadnˇe ho upravit, nebo okomentovat, tak aby byli uživatelé vstupní pole schopni snadno a správnˇe vyplnit.
Všechny formuláˇre jsou navázány na nˇejaký uživatelský úˇcet. Díky tomu muže
˚ systém
paralelnˇe využívat více uživatelu,
˚ každý se svou vlastní sadou formuláˇru˚ a dat.
4.3
Model tˇríd
Diagram tˇríd zachycuje vnitˇrní strukturu aplikace, popisuje jednotlivé tˇrídy, zachycuje chování systému. Pˇri konstrukci toho modelu jsem vycházel z funkˇcních požadavku˚ a pˇrípadu˚
užití. Díky nim jsem urˇcil základní objekty a vazby. Bˇehem vývoje aplikace a jejím dalším
rozpracováním byly nalezeny další objekty a vazby v diagramu. Vývoj se odehrává na základˇe iterativní a inkrementální metodologie, proto i diagram tˇríd se stále vyvíjí a upˇresnuje.
ˇ
Diagram tˇríd celého systému je pomˇernˇe rozsáhlý, v tuto chvíli by zahrnoval více než sto
tˇríd. Navíc se nˇekteré jeho cˇ ásti cˇ asto mˇení. Takový diagram pomˇernˇe brzy ztratí vypovídací
hodnotu. Rozhodl jsem se proto prezentovat jen jednu cˇ ást, která je pro systém charakteristická a zárovenˇ je už pomˇernˇe ustálená. Zvolil jsem diagram Data Transfer Objektu,
˚ zkrácenˇe
27
ˇ
4.4. OBJEKTOV Eˇ RELA CNÍ
MAPOVÁNÍ
DTO (viz 4.5).
DTO slouží k pˇrenosu dat mezi procesy tak, aby byl co nejvíce zredukován poˇcet volání
metod tˇechto procesu[5][7].
˚
DTO také vhodnˇe odstinuje
ˇ
vrstvy aplikace. Napˇríklad, pokud
je použito ORM, jako v mém pˇrípadˇe (viz 4.4.1), je vhodné data z entitních tˇríd pˇresunout do
DTO. Zbavíme se tím závislosti na ORM ve vyšších vrstvách aplikace a specifik Persistence
kontextu, jako jsou lazy vazby, nebo životní cyklus entity. DTO pak mužeme
˚
snadno uzpu˚
sobit napˇríklad k serializaci do XML a objekty tak využít v rámci implementace webových
služeb (WS).
K pˇresunu dat mezi entitní vrstvou a DTO používám knihovnu Dozer4 . Tato knihovna je
schopná díky Java Reflections významnou cˇ ást mapování odvodit sama. Co je nad její síly,
musí se ruˇcnˇe nastavit pomocí XML konfigurace, nebo novˇe pomocí anotací. Pro složitˇejší
pˇrípady je tˇreba implementovat konvertory. To se týká tˇreba stromové struktury formuláˇre.
Zde jsem musel implementovat pomˇernˇe komplikovaný konvertor, aby nedocházelo k zacyklení.
Balík formStructure reprezentuje strukturu formuláˇre. Mužeme
˚
zde vidˇet objekt FormDto, který reprezentuje informace, jež se vážou k formuláˇri jako celku. Dále se zde nachází
hierarchie jednotlivých prvku,
˚ jež se ve formuláˇri mohou vyskytovat. FormSegmentContainerDto reprezentuje prvek formuláˇre, jež muže
˚ obsahovat další prvky. Jedná se tedy o návrhový vzor Kompozit, který mi umožnuje
ˇ
nakládat s uzly, i listy stromové struktury formuláˇre bez rozdílu. Dále je zde uvedeno nˇekolik dalších konkrétních prvku˚ formuláˇre, jež
mˇely být implementovány v prvních iteracích.
Balík formData reprezentuje data odeslaná prostˇrednictvím formuláˇre. FormSubmitDto
reprezentuje data, jež se vážou k celému procesu vyplnˇení formuláˇre. AnswerDto reprezentuje data, odeslaná prostˇrednictvím konkrétního vstupního prvku formuláˇre. Nˇekteré
vstupní prvky mohou odeslat více odpovˇedí, proto je na AswerDto navázána tˇrída AnswerComponentDto.
4.4
Objektovˇe relaˇcní mapování
Objektovˇe orientované programování (OOP ) bylo vyvinuto se snahou rˇ ešit vzrustající
˚
komˇ
plexitu vyvíjeného software. Casem
nahradilo klasický modulární zpusob
˚
programování.
I pˇres jistou kritiku této metodologie OOP získávalo na popularitˇe [25]. V dnešní dobˇe se
tˇeší masové oblibˇe. Vˇetšina vývoje se dˇeje v prostˇredí objektovˇe orientovaných jazyku.
˚ Velká
cˇ ást moderních jazyku˚ podporuje objektovˇe orientovaný zpusob
˚
programování.
Objektovˇe relaˇcní mapování, zkrácenˇe ORM , je jeden ze zpusob
˚
u,
˚ jak se dá rˇ ešit rozdílnost relaˇcního svˇeta databází a objektového svˇeta souˇcasných programovacích jazyku˚ tzv.
impedance mismatch. V objektovém svˇetˇe jsou data udržována, jak jinak, než objekty. Objekty vˇetšinou obsahují neskalární data. Naproti tomu v relaˇcních databázích jsou nejˇcastˇeji
skalární data udržována v tabulkách, neboli relacích. Tabulka je vlastnˇe množina n-tic stejného typu.
˚ Pokud chceme v objektovém svˇetˇe pracovat s tˇemito databázovými daty, existují
4.
Dostupný na <http://dozer.sourceforge.net/> (leden 2012)
28
ˇ
4.4. OBJEKTOV Eˇ RELA CNÍ
MAPOVÁNÍ
v zásadˇe dva zpusoby.
˚
Bud’ se pokusíme jednotlivé n-tice mapovat na speciální objekty, dodržující jisté konvence. Tyto objekty potom reprezentují konkrétní n-tice, jednotlivé prvky
n-tic jsou mapovány na atributy tˇechto objektu.
˚ Nebo mužeme
˚
pracovat samostatnˇe s jednotlivými skalárními hodnotami z databáze. Druhý zmínˇený zpusob
˚
je na první pohled
pomˇernˇe nepraktický. ORM tedy funguje na principu mapování n-tic na objekty. V ORM se
zmínˇené mapované objekty nazývají entitní objekty. To jsou instance takzvaných entitních
tˇríd .
Výhodou ORM je, že poskytují další úrovenˇ abstrakce a odstíní nás od specifik SQL dialektu a jiných specialit konkrétního databázového systému. Díky tomu muže
˚ aplikace v ideálním pˇrípadˇe podporovat více ruzných
˚
relaˇcních databázových systému,
˚ nebo dokonce poskytovatele persistence úplnˇe jiného typu. Nevýhodou je, samozˇrejmˇe, pˇridání další vrstvy
a s tím spojené režie jak ve výkonnosti, tak v programátorském úsilí.
Dalším možným rˇ ešením pˇrechodu mezi dvˇema svˇety je úplné vyhnutí se relaˇcnímu
svˇetu. K dispozici jsou dokumentové databáze, jako jsou napˇríklad nativní XML databáze,
cˇ i dokonce objektovˇe orientované databáze. V pˇrípadˇe Objektových databází odpadají problémy a režie s konverzí z jednoho formátu do druhého. Jsou odstranˇeny nˇekterá omezení
relaˇcních databází. Lze naplno využít specifika objektového svˇeta. Objektové databáze však
mají ve srovnání s relaˇcními pomˇernˇe krátkou historii. Nejsou tak propracované jako vyspˇelé a léty provˇerˇ ené databázové kolosy, mezi které patˇrí napˇríklad produkty od spoleˇcˇ e v rychlosti pˇrístupu k datum
nosti Oracle. Cistˇ
˚ i ze zmínˇených duvod
˚
u˚ pokulhávají. Relaˇcní databáze také nabízejí vˇetší nezávislost. Lze je snadnˇeji použít i mimo jejich primární
aplikace.
4.4.1 Java Persistence API
Existuje znaˇcné množství rámcu,
˚ jež se snaží usnadnit pˇrechod mezi objektovým a relaˇcním svˇetem. Orientace a výbˇer toho pravého není jednoduchý. Ve svˇetˇe Javy je však situace
zjednodušena díky existenci Java Persistence API, zkrácenˇe JPA [17]. Tato specifikace definuje standardní rozhraní pro mapování objektu˚ do relaˇcních databází. Všechny významné
javové ORM rámce tento standard splnují.
ˇ
Proto není tak obtížné volit mezi jednotlivými
implementacemi, vˇetšina funkcionality i zpusob
˚
jejího užití je shodná. Anti-pattern proprietární uzamˇcení, neboli vendor lock-in je omezen na minimum. Vˇetšinou je u stávajících
projektu˚ realizovatelná i výmˇena celé ORM knihovny. Nástroje se liší pouze nadstavbami a
rozšíˇrenými funkcemi, které ještˇe nejsou specifikovány v JPA. V rámci nˇekterých JPA implementací z historických duvod
˚
u˚ paralelnˇe existují alternativní proprietární API, nesplnující
ˇ
standard. Tˇemto je, z výše uvedených duvod
˚
u,
˚ vhodné se vyhnout.
Koneˇcná specifikace JPA 1.0 byla uveˇrejnˇena v roce 2006. Její podoba byla výraznˇe ovlivnˇena projektem TopLink 5 , jehož koˇreny sahají až do roku 1990, kdy sloužil jako ORM rámec
pro jazyk Smalltalk [34]. V roce 2006 byla cˇ ást zdrojového kódu TopLinku darována opensource projektu GlassFish a pod názvem TopLink Essentials se stala referenˇcní implementací
JPA 1.0.
5.
Zkratka TOP v názvu znamená The Objective People – firma, která stála u zrodu rámce TopLink.
29
ˇ
4.4. OBJEKTOV Eˇ RELA CNÍ
MAPOVÁNÍ
V roce 2009 byla vydána vylepšená a rozšíˇrená specifikace JPA 2.0. Tato specifikace cˇ erpala z ovˇerˇ ené nadstandardní funkcionality pokroˇcilých implementací JPA 1.0, mezi které
patˇril napˇríklad i populární framework Hibernate. Mezi nejduležitˇ
˚
ejší novinky patˇrí: Criteria API pro snadnou tvorbu dynamických dotazu,
˚ lepší podpora pro takzvané embedded
objekty, rozšíˇrené mapování kolekcí a jejich uspoˇrádání, rozšíˇrený Java Persistence Query
Language, standardizace nˇekterých nastavení, Cache API a mnoho dalších. Referenˇcní implementací JPA 2.0 je open-source projekt EclipseLink, který jsem také použil ve webové
aplikaci vytvoˇrené jako souˇcást této práce. EclipsLink je vyvíjen v rámci neziskové organizace Eclipse Foundation. Vychází z TopLink Essentials, proto sebou nese mnoho let vývoje a
zkušeností jednoho z nejstarších ORM rámcu.
˚ Nejvýznamnˇejšími ORM nástroji implementujícími standard JPA jsou zmínˇený EclipseLink, Hibernate a OpenJPA.
Dále v práci budu implicitnˇe vycházet ze specifik konkrétního rámce EclipseLink. V drtivé vˇetšinˇe by však text mˇel být platný i pro ostatní rámce splnující
ˇ
JPA 2.0, cˇ asto i pro ORM
frameworky obecnˇe.
Zajímavým dusledkem
˚
používání nˇekteré z technologií, splnující
ˇ
standard JPA, je možnost nahradit relaˇcní databázi a ORM pˇrímo nˇekterou z objektových databází. Napˇríklad
Izraelská objektová databáze ObjectDB poskytuje mimo jiné i JPA rozhraní. Nakonec se tak
zcela vyhneme režii s ORM spojenou. Dle dostupných srovnání pˇritom objektové databáze
vycházejí dramaticky rychlejší než klasické relaˇcní databáze ve spojení s ORM rámci 6 .
4.4.2 Návrh perzistentní vrstvy
V této podkapitole se pokusím nastínit základní metodologii práce s ORM. Mapování mezi
relaˇcní databází a objekty lze vytvoˇrit tˇremi základními zpusoby.
˚
Forward mapping Ménˇe obvyklé je, že nejdˇríve vytvoˇríme objektový model dat splnující
ˇ
pravidla pro to, aby mohl být mapován do databáze. Tento model potom doplníme
konfigurací, která upˇresní mapování jednotlivých datových typu,
˚ mapování vztahu˚
mezi objekty atd. Konfiguraci lze specifikovat v oddˇeleném konfiguraˇcním souboru,
nebo pohodlnˇe pomocí javových anotací. Vˇetšina ORM rámcu˚ také umožnuje
ˇ
nechat
si z tohoto objektového modelu automaticky vygenerovat databázové struktury. Výsledný databázový model je sice v zásadˇe funkˇcní, ale pro reálnou použitelnost je
ˇ
vˇetšinou nutné jej následnˇe manuálnˇe upravit. Casto
je nutné provést optimalizace,
jako je vytvoˇrení indexu,
˚ doplnˇení potˇrebných integritních omezení atd. Nˇekteré specifika nemuže
˚ generátor databázových struktur bez znalosti domény odvodit.
Tento zpusob
˚
jsem použil bˇehem vytváˇrení aplikace pro tvorbu formuláˇru.
˚ Rozhodl
jsem se pro nˇej, protože datový model se mi lépe vytváˇrel z perspektivy objektového
svˇeta. Relaˇcní model se mi zdál pˇríliš svazující, odvádˇející pozornost od návrhu ke
specifikum
˚ relaˇcního svˇeta. Datový model aplikace využívá dˇediˇcnost, kterou nelze
v relaˇcních databázích pˇrirozenˇe zachytit viz podkapitola 4.4.3.
6.
http://www.jpab.org
30
ˇ
4.4. OBJEKTOV Eˇ RELA CNÍ
MAPOVÁNÍ
Reverse mapping Druhým a cˇ astˇeji používaným zpusobem
˚
tvorby mapování je vytvoˇrení
promyšleného, robustního databázového modelu, ze kterého si následnˇe manuálnˇe
odvodíme, nebo si necháme automaticky vygenerovat objektový model entitních tˇríd.
V pˇrípadˇe, že jsme si objektový model nechali vygenerovat, musíme vˇetšinou uˇcinit
drobné úpravy. Mimo jiné je potˇreba nastavit v jakou chvíli mají být pˇri naˇctení objektu z databáze naˇcítány i navázané objekty. Navázané objekty lze naˇcítat okamžitˇe
(EAGER FETCH), nebo až v momentˇe pˇrístupu k tˇemto objektum
˚ (LAZY FETCH). Pˇri
špatném nastavení strategie to muže
˚ znamenat rˇ etˇezovité naˇctení obrovského množství dat z databáze, nebo naopak zbyteˇcnˇe mnoho jednotlivých dotazu˚ do databáze.
Dále existují ruzné
˚
speciální optimalizaˇcní instrukce, napˇríklad takzvané hinty a jiné.
Tyto jsou závislé na konkrétních pˇrípadech užití a na modelované doménˇe, proto není
možné je bezpeˇcnˇe automaticky odvodit.
Meet in the middle mapping Jde o nejménˇe používaný pˇrístup k vytváˇrení mapování mezi
objekty a relacemi. Zaˇcíná se ve stavu kdy je již hotový relaˇcní databázový model
stejnˇe tak objektový model. Pomocí anotací, nebo XML konfigurace se následnˇe provádí provázání tˇechto dvou modelu.
˚ Tento pˇrístup je pomˇernˇe obtížný, klade vysoké
nároky na popis mapování. Nezˇrídka bývá potˇreba upravit databázové schéma, nebo
nˇekteré entitní tˇrídy. Sám jsem se nikdy s tímto scénáˇrem nesetkal.
4.4.3 Mapování hierarchie dˇediˇcnosti
Pro reprezentaci jednotlivých prvku˚ formuláˇre jsem použil hierarchický model. Všechny
prvky mají spoleˇcnou základní tˇrídu SegmentContainr se základními atributy. K nim pak
pˇridávají podtˇrídy prvku˚ formuláˇre specifické atributy ruzných
˚
datových typu.
˚ Obrázek
4.3 zachycuje objektovou hierarchii prvku˚ formuláˇre. S ohledem na pˇrehlednost jsou zde
zachyceny jen nejvýznamnˇejší a nejzajímavˇejší tˇrídy. Také z atributu˚ jsou uvedeny jen ty
významnˇejší. V opaˇcném pˇrípadˇe by byl diagram pˇríliš velký a nepˇrehledný. Myslím, že
zobrazená úrovenˇ detailu je pro zachycení významných principu˚ a myšlenek vhodnˇejší než
podrobná specifikace.
Reprezentace dˇediˇcnosti a polymorfismus je významným nesouladem mezi objektovým
a databázovým svˇetem. V relaˇcních databázích pro nˇe neexistuje rozšíˇrená a spolehlivá pˇrirozená podpora. Tyto vlastnosti musí být emulovány pomocí databázových tabulek. V JPA
existují tˇri strategie reprezentace hierarchické struktury dˇediˇcnosti a polymorfismu.
Strategie tabulka pro hierarchii tˇríd Tabulka pro hierarchii tˇríd v terminologii JPA „SINGLE_TABLE“ je výchozí strategie JPA. Všechny tˇrídy v hierarchii dˇediˇcnosti jsou
udržovány v jediné tabulce. Pro každý atribut každé tˇrídy v tabulce existuje sloupec. Každý objekt je reprezentován rˇ ádkem v tabulce. V tabulce je navíc speciální
31
ˇ
4.4. OBJEKTOV Eˇ RELA CNÍ
MAPOVÁNÍ
Obrázek 4.3: Hierarchie tˇríd prvku˚ formuláˇre
sloupec definující typ objektu v rˇ ádku. Každé pole, které není v objektu nebo jeho
pˇredku použito, je nastaveno na NULL. Výhodou této strategie je, že naˇctení objektu
se rovná naˇctení jednoho rˇ ádku z jedné tabulky. Naopak pokud bude hierarchie složitá a hodnˇe rozdílná, muže
˚ vzniknout velmi rozsáhlá tabulka. Tím utrpí výkonnost a
srozumitelnost databáze. Vedlejším efektem je, že každý ze sloupcu˚ musí být schopen
uchovávat NULL hodnoty. Tuto strategii vˇetšinou lze doporuˇcit pro nepˇríliš složité
hierarchie.
Strategie tabulka pro podtˇrídu Tabulka pro podtˇrídu, neboli „JOINED“ strategie znamená,
že každá tˇrída v hierarchii má svou vlastní tabulku, ve které jsou sloupce pouze pro
atributy konkrétní tˇrídy. Zdˇedˇené atributy jsou uloženy v tabulkách pˇredku.
˚ Tento
zpusob
˚
se dá oznaˇcit za nejˇcistší, jeho struktura je nejnormalizovanˇejší a data jsou
uložena nejúspornˇejším zpusobem.
˚
Nevýhodou je pomˇernˇe nízká výkonnost. Pokud
chceme naˇcíst objekt, vˇetšinou musíme pˇristoupit k nˇekolika tabulkám, stejnˇe tak pˇri
ukládání. Tento pˇrístup se hodí pro široké typy hierarchií tˇríd.
Strategie tabulka pro konkrétní tˇrídu Jinak rˇ eˇceno „TABLE_PER_CLASS“, spoˇcívá ve vytvoˇrení tabulky pro každou tˇrídu v hierarchii. V této tabulce se vyskytují všechny atri32
ˇ
4.4. OBJEKTOV Eˇ RELA CNÍ
MAPOVÁNÍ
buty dané tˇrídy, vˇcetnˇe všech atributu˚ pˇredku.
˚ Objekt je tedy kompletní na jednom
místˇe. Vˇetšina operací probíhá srovnatelnˇe rychle jako u „SINGLE_TABLE“, pˇritom
odpadá problém s bobtnáním tabulky. Problematické jsou polymorfní operace, které
si vyžadují pomˇernˇe složité a pomalé databázové dotazy.
Protože do budoucna by mˇela být hierarchická struktura prvku˚ formuláˇre pomˇernˇe
rozsáhlá a pˇritom chci udržet co nejvyšší výkonnost, zvolil jsem pro svuj
˚ projekt tuto
strategii, jak patrno z obrázku 4.4, který je výˇrezem databázového schématu, odpovídajícímu mapování struˇcného objektového modelu 4.3. Je patrné, že pro každou tˇrídu
byla vytvoˇrena samostatná tabulka. I když se na tomto neúplném schématu zdá, že
se sloupce zbyteˇcnˇe opakují, pˇri pohledu na úplné, mnohem rozsáhlejší schéma už
tento dojem není tak silný. Do budoucna je nutno poˇcítat s pˇribýváním jak sloupcu,
˚
tak celých tabulek pro nové prvky formuláˇre.
Obrázek 4.4: ER diagram reprezentující hierarchii tˇríd prvku˚ formuláˇre.
33
ˇ
4.4. OBJEKTOV Eˇ RELA CNÍ
MAPOVÁNÍ
Ve vygenerovaném schématu jsou dále zajímavé cˇ tyˇri momenty.
Výˇctové typy, konkrétnˇe MultiChoiceType a MultiChoiceLayout jsou EclipseLinkem
reprezentovány jednoduše jako sloupec typu varchar.
Vazba mezi tˇrídou InputChoice a MultiChoice je EclipseLinkem implicitnˇe mapována
pomocí tabulky, která je tu na první pohled zbyteˇcná, staˇcil by cizí klíˇc v tabulce InputChoice. Vazební tabulka se vyplatí pokud je asociace typu M : N, nebo pokud
chceme vazbu typu 1 : N optimalizovat pro více typu˚ entit cˇ etnosti 1. Vazební tabulka umožnuje
ˇ
tyto vazby vyjmout z entity cˇ etnosti N, a tím zvýšit její nezávislost.
Ve vazební tabulce pak jsou ošetˇreny všechny vazby vˇcetnˇe pˇrípadného urˇcení tabulky entity cˇ etnosti 1. Nemusí být proto prohledáváno více tabulek než je tˇreba, viz
níže vazby SegmentFormContaineru. I v tomto pˇrípadˇe JPA nabízí, at’ už prostˇrednictvím anotací, cˇ i XML konfigurace, pomˇernˇe široké možnosti nastavení výsledného
zpusobu
˚
reprezentace vazeb.
Dalším zajímavým jevem je absence vazební tabulky mezi tabulkou SegmentFormContainer a tabulkami ostatních prvku˚ formuláˇre. V tˇrídˇe SegmentFormContainer
totiž existuje atribut children, ve kterém je seznam potomku˚ SegmentFormContaineru. Tato promˇenná je emulována pomocí pˇredpˇripraveného SQL dotazu, který najde všechny prvky, mající jako pˇredka (atribut parent) daný SegmentFormContainer.
Tento dotaz je pomalejší než vyhledávání ve vazební tabulce, protože musí být provádˇen nad všemi dalšími typy prvku.
˚ Proto je vhodné u atributu children nastavit
7
LAZY FETCH , v opaˇcném pˇrípadˇe muže
˚ docházet k rˇ etˇezovitému naˇctení všech
provázaných prvku.
˚ Alternativou k LAZY FETCH je promˇenou children úplnˇe vypustit a rˇ ídit naˇcítání potomku˚ pomocí vlastních dotazu˚ do databáze. Nejlepším rˇ ešením však je pro tento typ vazby vytvoˇrit vazební tabulku. V tabulce jsou následnˇe
zaznamenány vazby na všechny tabulky, vˇcetnˇe informace o tom, na kterou tabulku
se odkazujeme. Nemusíme tedy zbyteˇcnˇe prohledávat více tabulek.
Volba databázových typu˚ sloupcu˚ pro objektové atributy je další z mapovacích nesouladu.
˚ EclipseLink je schopen bez nápovˇedy vhodnˇe zvolit typové protˇejšky, ale i
zde je možné pomocí konfigurace mapování velmi podrobnˇe nastavit.
Jakmile je vyladˇeno mapování mužeme
˚
zaˇcít práci s databází prostˇrednictvím Entitních tˇríd.
ORM nám vlastnˇe zprostˇredkuje virtuální objektové úložištˇe. V JPA se tomuto úložišti rˇ íká
Persistence Unit. V konfiguraˇcním souboru je nastaveno provázání této Persistence unit se
skuteˇcnou relaˇcní databází. Objekty jsou pak v JPA zpˇrístupnˇeny pomocí takzvaného Entity
Manageru. Entity manager obstará všechny CRUD 8 operace. S Entity managerem je spojen
takzvaný Persistence context. Persistence context je tvoˇren množinou instancí entit, které
existují v konkrétním datovém úložišti. Persistence context ohraniˇcuje prostor, ve kterém
7. LAZY FETCH, neboli líné naˇcítání, prvky jsou naˇcteny až v momentˇe kdy je k nim opravdu pˇristoupeno.
Opakem je EAGER FETCH, prvky jsou naˇcítány okamžitˇe.
8. CRUD – Create, Read, Update, Delete jsou cˇ tyˇri základní operace v rámci datového úložištˇe.
34
ˇ
4.4. OBJEKTOV Eˇ RELA CNÍ
MAPOVÁNÍ
je s tˇemito entitami manipulováno [8]. V rámci Persistence contextu mohou entity nabývat
nˇekolika stavu.
˚ Entity tedy mají jistý životní cyklus.
35
ˇ
4.4. OBJEKTOV Eˇ RELA CNÍ
MAPOVÁNÍ
Obrázek 4.5: Model tˇríd Data Transfer Objektu.
˚
36
ˇ
4.4. OBJEKTOV Eˇ RELA CNÍ
MAPOVÁNÍ
Obrázek 4.6: ER diagram zachycující výslednou strukturu v databázi. Vˇetšina atributu˚ je pro
pˇrehlednost vynechána.
37
Kapitola 5
Architektura a Implementace
Jelikož jsem se snažil aplikaci vyvíjet iterativním inkrementálním zpusobem,
˚
již od poˇcátku
jsem prubˇ
˚ ežnˇe implementoval cˇ ásti, které prošly analýzou a návrhem. Jak se rozšiˇroval model tˇríd a persistentních entit, vznikala postupnˇe i jejich skuteˇcná implementace. Díky tomu
se mi pomˇernˇe brzo podaˇrilo odhalit nˇekteré chyby v analýze a návrhu.
Pro implementaci prezentaˇcní vrstvy jsem použil technologii JSF (JavaServer Face), populární aplikaˇcní rámec pro webové aplikace na platformˇe Java. Jako doplnˇek JSF jsem použil rámec ICEfaces. ICEfaces vhodnˇe rozšiˇruje JSF sofistikovanými komponentami a znaˇcnˇe
usnadnuje
ˇ
a zjednodušuje použití technologie AJAX. Dále jsem použil velmi povedenou
knihovnu PrettyFaces, díky které lze snadno vytváˇret intuitivní URL adresy. PrettyFaces
umožní z tˇechto adres velmi pohodlnˇe extrahovat potˇrebné informace. Samozˇrejmˇe bylo
tˇreba napsat i jisté množství JavaScriptového kódu, zvláštˇe pro implementaci chování Táhni
a pust’.
5.1
JavaServer Faces
Pro technologii JavaServer Faces jsem se rozhodl, protože to není dlouho, co byla vydána její
nová verze 2.0, obsahující velké množství významných zmˇen, jež by mˇely znaˇcnˇe usnadnit
vývoj a vylepšit architekturu i výkonnost aplikací. Z dˇrívˇejška jsem mˇel jisté zkušenosti a
znalosti pˇredchozí verze 1.2 a chtˇel jsem si doplnit znalosti tohoto moderního a perspektivního nástroje.
JavaServer Faces je již od poˇcátku koncipován jako komponentní (nˇekdy oznaˇcován také
jako „pull-based“) Model-View-Conroller rámec.
Model-View-Conroller (zkrácenˇe MVC) je architektonický vzor hojnˇe používaný v prostˇredí webových aplikací. Aplikace rozdˇeluje na tˇri cˇ ásti:
Model Který v sobˇe nese doménovˇe specifická data a chování. Poskytuje data pro View
a mˇení stav typicky na základˇe instrukcí od Controlleru. Nˇekdy muže
˚ upozornovat
ˇ
View na zmˇenu dat, tak aby mohl adekvátnˇe reagovat.
View Vhodnˇe prezentuje data uchovávaná v modelu tak, aby s nimi mohl uživatel interagovat. Pro jeden Model muže
˚ existovat více ruzných
˚
View (neboli pohledu)
˚ specifického
užití (prezentace pro ruzná
˚
zaˇrízení, ruzné
˚
uživatelské role).
38
5.1. JAVASERVER FACES
Controller Pˇrijímá a zpracovává akce od uživatele, pˇrevádí je do formy kompatibilní s modelem. Zabezpeˇcuje vhodnou reakci View a Modelu na uživatelské akce.
Cílem MVC je oddˇelení aplikaˇcní logiky a dat od specifik konkrétní prezentaˇcní vrstvy. Tím
zjednodušuje architekturu a design a zvyšuje použitelnost a univerzálnost systému ve kterém je použit.
Komponentní frameworky jako je JSF se svou podstatou více blíží vývoji, jak je znám
z klasických tlustých klientu.
˚ Stránky jsou tvoˇreny stromem komponent. Existuje zde systém událostí. Nástroje tohoto typu bývají mohutnˇejší, mají tendenci skrývat HTTP podstatu
komunikace. V dˇrívˇejších dobách byly jejich hlavní doménou intranetové aplikace. Na první
pohled je odstínˇení od HTTP a pˇriblížení tlustému klientu výhodou. Pokud však pronikneme do vˇetší hloubky a zaˇcneme se pokoušet o složitˇejší zpusoby
˚
užití, které nejsou frameworkem pˇrímo podporovány zaˇcneme objevovat znaˇcnou komplikovanost nˇekdy až tˇežkopádnost tohoto pojetí. Dalšími zástupci komponentních frameworku˚ je napˇríklad Google
web Toolkit (zkrácenˇe GWT) nebo Active Server Pages (ASP) na platformˇe .net.
Alternativou ke komponentním frameworkum
˚ jsou rámce založené na akcích (nˇekdy
oznaˇcovány jako „push-based“). Nástroje tohoto typu nejdou cestou napodobování tlustých
klientu,
˚ mapují URL adresy na akce, které následnˇe ovlivní zobrazenou stránku. Akˇcní
rámce se koncepˇcnˇe více blíží podstatˇe HTTP protokolu, dá se rˇ íci, že jsou více zamˇerˇ eny
na Internetové aplikace s velkým množstvím klientu.
˚ Jsou totiž odlehˇcenˇejší a netáhnou sebou pˇrítˇež v podobˇe uchovávání stavu. Mezi zástupce tohoto konceptu patˇrí Apache Struts,
Spring MVC, nebo Ruby on Rails.
Bˇežnˇe se MVC rámec JSF používá tak, že je v XML dokumentu (View) popsána struktura
uživatelského rozhraní pomocí dostupných komponent a tagu.
˚ Toto uživatelské rozhraní
zvané view template nebo facelets view je navázáno prostˇrednictvím EL (Unified Expression
Language) na takzvané Managed Beans (Model). Managed Beany jsou obyˇcejné javové tˇrídy
nakonfigurované v konfiguraˇcním souboru JSF, nebo pˇrímo v tˇrídách samotných pomocí
anotací. Pokud však používáme rámec Spring, je možné, a dokonce vhodné místo tˇechto JSF
Managed Bean použít pˇrímo Spring Beany, které v JSF fungují stejnˇe jako nativní Managed
beany, navíc však poskytnou lepší podporu pro DI a ostatní rozšíˇrení Springu. JSF aplikace
funguje tak, že jsou všechny požadavky pˇresmˇerovány na FacesServlet (Controller), který
vybere správnou view template a projde fázemi JSF aplikace. Pro vytvoˇrení view template
lze v JSF volit z více technologií. K dispozici jsou Java Server Pages (zkrácenˇe JSP) puvodní
˚
technologie JSF verze 1.2, Facelets mnohem lepší šablonový systém, jež se stal implicitní
volbou od JSF 2.0, nebo XUL.
Životní cyklus JSF pohledu:
1. Restore view Fáze obnoví pˇredchozí stav aplikace. V pamˇeti je vytvoˇrena stromová
struktura JSF komponent reprezentující view template a pˇredchozí uložený stav tˇechto
komponent. Pokud nebyl nalezen uložený stav (to se týká prvního zobrazení pohledu) JSF pˇreskoˇcí rovnou na fázi Render response. Nehrozila totiž žádná inter39
5.1. JAVASERVER FACES
akce s komponentami na stránce a není potˇreba procházet ostatními fázemi životního
cyklu. V opaˇcném pˇrípadˇe se pokraˇcuje následující fází.
2. Apply request values V této fázi jsou stavy komponent upraveny, dle hodnot parametru˚ pˇrenášených požadavkem. Mimo jiné jsou do vstupních polí vloženy nové rˇ etˇezce z požadavku. I stlaˇcení tlaˇcítka muže
˚ pomocí JavaScriptu vyvolat zmˇenu stavu
nˇekteré z komponent. Dále se pokraˇcuje následující fází.
3. Process validations V této fázi jsou validovány hodnoty všech komponent, ke kterým jsou pˇriˇrazeny nˇejaké validátory. Validuje se napˇríklad, zda je cˇ íslo ve správném
intervalu, zda je hodnota vyplnˇena atd. Muže
˚ se jednat o uživatelem definované validátory, nebo zabudované validátory JSF. Pokud je nalezena chyba, jsou zaznamenány
pˇríslušné chybové zprávy a cyklus pˇreskoˇcí do fáze Render response. V opaˇcném pˇrípadˇe se pokraˇcuje následující fází.
4. Update model values Až v této fázi jsou hodnoty komponent propagovány do modelu na serveru. Tedy hodnoty tˇech komponent jejichž hodnoty jsou navázány na
model pomocí EL. Pomocí EL muže
˚ být dokonce do modelu navázána celá komponenta, respektive její dynamická reprezentace. Toho s výhodou využiji pˇri implementaci specifického chování aplikace. Hodnoty z komponent jsou v pˇrípadˇe nutnosti
konvertovány do odpovídajících typu˚ v modelu. K tomu jsou použity zabudované
konvertory JSF, nebo v pˇrípadˇe nutnosti konvertory vlastní, uživatelské. Pokud nˇekterá z konverzí selže, jsou zapsány pˇríslušné chybové zprávy a aplikace pˇreskoˇcí
rovnou do fáze Render response. V opaˇcném pˇrípadˇe se pokraˇcuje následující fází.
5. Invoke application V této fázi dojde ke spuštˇení akˇcních metod, tedy k vykonání
samotné byznys logiky. Pˇrípadné zmˇeny v promˇenných v modelu jsou reflektovány
stromem komponent. Na základˇe návratových hodnot akˇcních metod dojde k pˇrípadnému pˇresmˇerování stránky.
6. Render response Závˇereˇcná fáze ve které je celý strom komponent serializován a
poslán jako odpovˇed’ zpˇet. Vˇetšinou se jedná o odpovˇed’ ve formátu HTML. Také
dojde k uložení aktuálních stavu˚ komponent.
Výše jsem popsal standardní životní cyklus JSF aplikace. Nejde o úplnˇe vyˇcerpávající
popis, mnoho detailu˚ jsem vynechal, protože jsem je pro úˇcely této práce nepovažoval za
duležité.
˚
Existují další momenty, které mají vliv na prubˇ
˚ eh životního cyklu. V JSF aplikaci je
možné prubˇ
˚ eh cyklu znaˇcnˇe ovlivnit a pˇrizpusobit
˚
potˇrebám vývojáˇre.
5.1.1 Dynamické vytváˇrení stromu komponent
V pˇrípadˇe aplikace pro tvorbu formuláˇru˚ jsem musel v JSF použít pomˇernˇe neobvyklý a
málo zdokumentovaný zpusob
˚
tvorby uživatelského rozhraní. V mém pˇrípadˇe totiž není
40
5.1. JAVASERVER FACES
Obrázek 5.1: Životní cyklus JSF aplikace.
možné dopˇredu vˇedˇet, které komponenty a v jakém poˇradí se na stránce objeví. Proto jsem
pˇridával komponenty do stránky dynamicky.
Vytvoˇril jsem základní design stránky a na vhodné místo vložil jednoduchou komponentu reprezentující prázdný panel. Panel muže
˚ jako potomky obsahovat další komponenty,
lze si ho pˇredstavit jako komponentu reprezentující HTML element div. Celou komponentu
panel jsem pomocí EL navázal do modelu (do promˇenné Managed bean). Pro cˇ ást stránky,
jež se má dynamicky mˇenit dle interakce s uživatelem, tedy samotný formuláˇr tvoˇrený uživatelem, vytvoˇrím stromovou strukturu komponent v pamˇeti, podobnˇe jako by to udˇelal
rámec JSF ve fázi Restore view pro odpovídající view template. Rozdíl je v tom, že u komponent zakážu ukládání stavu.
˚ Komponenty totiž držím neustále v Managed bean i s jejich
stavy, které se neztrácejí mezi jednotlivými požadavky od klienta. Následnˇe ve fázi Update model values, kdy dojde k pˇredání odkazu na Panel ve stránce do modelu, jako potomka tomuto panelu „manuálnˇe“ pˇridám vytvoˇrený strom komponent 1 . Ve fázi Render
response je potom klientovi zaslána celá stránka stejnˇe, jako kdyby byly komponenty v panelu zapsány ve view template. Když uživatel v dalších requestech interaguje se stránkou
a mˇení její strukturu, modifikuji odpovídajícím zpusobem
˚
reprezentaci podstromu komponent v modelu a vždy jej nezapomenu ve fázi Update model values vložit jako potomka
ke komponentˇe panel z view template. Pˇrístup ke komponentˇe ve stránce však nebyl tak
1. Pokud se jedná o první zobrazení stránky k pˇredání odkazu na panel i pˇridání potomku˚ k tomuto panelu
dojde výjimeˇcnˇe ve fázi Render response.
41
5.1. JAVASERVER FACES
jednoduchý, více o tom v následující podkapitole.
5.1.2 Vazba komponent a Backing bean koncept
Abych mohl popsat koncept Backing bean a problémy s pˇrístupem k dynamické reprezentaci komponenty, nebo držením stromu komponent v modelu (Managed bean), musím popsat jak v JSF (ale i napˇríklad ve Springu) funguje životnost, neboli rozsah platnosti (v originálním znˇení Scope). Instance Managed bean obvykle vznikne v momentˇe kdy je k ní
poprvé pˇristoupeno prostˇrednictvím El.
V JSF 1.2 byly pro Managed bean k dispozici tˇri základní rozsahy:
•
Request Scope Instance Managed bean existuje v intervalu od vzniku po odeslání
odpovˇedi, tedy obvykle v rámci jednoho cyklu JSF aplikace. Tento rozsah platnosti
nepˇresahuje rozsah platnosti komponent vytvoˇrených JSF aplikací dle view template.
Proto jenom v Request scoped Managed beanech je možné pomocí EL spolehlivˇe navázat komponenty z view template [26] [30]. Tato podmínka dobˇre odpovídá konceptu Backing bean, viz níže.
•
Session Scope Stejná instance Managed bean existuje po celý zbytek klientské session.
•
Application Scope Stejná instance Managed bean existuje po celý zbytek nasazení
aplikace.
Managed beany spravované Springem podporují DI, i v JSF od verze 2.0 pˇribyla podpora
pro DI. To znamená, že managed beany se na sebe mužou
˚
vzájemnˇe odkazovat. Staˇcí jen
v beanˇe deklarovat odkaz na jinou beanu a DI kontejner se postará o vyˇrešení závislostí.
V JSF, které v tomto ohledu zdaleka nedosahuje propracovanosti Springu, platí že beana
by mˇela záviset pouze na beanˇe s vˇetším nebo stejným rozsahem platnosti. V opaˇcném pˇrípadˇe muže
˚ docházet k nebezpeˇcnému chování, kdy závislý objekt není dostupný, nebo je
v horším pˇrípadˇe držen odkaz na objekt, který již není platný.
Klasická managed bean reprezentující model by z pohledu správné dekompozice mˇela
mít co nejménˇe referencí na tˇrídy, nebo rozhraní specifická pro JSF a její view složku. Výjimkou jsou anotace, které konfigurují managed beanu. Zde vstupují do hry backing bean,
které by mˇely sloužit jako takový prostˇredník mezi pohledem, tedy view template s jejími
komponentami, validátory, konvertory, a modelem v podání managed bean. Tento koncept
je známý napˇríklad z ASP.net nebo MS Visual Basic. I když není rámcem JSF vyžadovaný,
je plnˇe podporován a cˇ asto používán. Backing bean je klasická managed bean, jejíž rozsah
platnosti by mˇel být nastaven na request. Tvoˇrí jakési podpurné
˚
pozadí pohledu se sofistikovanˇejší logikou [13]. Backing bean je tedy souˇcástí pohledu (View). Pokud budu v dalším
textu zminovat
ˇ
managed bean, je myšlena managed beana, která není typu backing bean,
je tedy souˇcástí modelu a má minimum vazeb na pohled, zejména neobsahuje odkazy na
komponenty.
42
5.1. JAVASERVER FACES
V pˇrípadˇe aplikace pro tvorbu formuláˇru˚ bylo nutné uchovat stav napˇríˇc požadavky.
Také jsem chtˇel ušetˇrit režii spojenou s vytváˇrením stromu komponent pro každý nový požadavek. Proto jsem strom komponent držel v managed beanˇe, reprezentující model, mající
rozsah platnosti pro celou session. V souladu s konceptem backing bean byl odkaz na komponentu (panel) z view template držen v backing beanˇe rozsahu platnosti typu request.
Abych mohl strom komponent vložit do pohledu, musel jsem mít pˇrístup k backing beanˇe,
která držela odkaz na komponentu z view template. Tato backing beana však má rozsah
platnosti pro jeden požadavek a nemohl jsem se na ni z managed beany s rozsahem platnosti pro celou session odkazovat. Zde mi pomohl Spring, který jsem použil pro správu
managed bean.
Spring umí kolem bean vytvoˇrit takzvaný AOP Proxy objekt. Hlavním úˇcelem této proxy
je, umožnit aspektovˇe orientované programování pomocí Springu podobnˇe, jako by byl použit AspectJ, ovšem bez nutnosti provádˇet weaving byte kódu 2 . Proxy objekty obalí tˇrídu a
umožní navˇesit funkcionalitu na všechny pˇrístupy k této tˇrídˇe z venˇcí . Tento pˇrístup má sice
jistá omezení ve srovnání s weavingem, jako je pˇridaná režie, nebo nemožnost pˇridat funkcionalitu k volání metod v rámci tˇrídy samotné, vˇetšinou je však dostaˇcující. Místo toho aby
Spring dosadil jako závislost pˇrímo managed beanu, vloží proxy objekt. V momentˇe kdy
chci pˇristoupit k závislosti, pˇristupuji vlastnˇe k maskovanému proxy objektu, který automaticky vyhledá správnou beanu a poskytne její rozhraní [3]. Díky tomu mohu za pomoci
Springu pˇristupovat z modelu k backing beanˇe a pˇredávat jí strom komponent, který je následnˇe zobrazen klientovi.
Obrázek 5.2: Schéma Backing bean obalené AOP Proxy
2. Weaving (ˇcesky vetkávání) je dodateˇcná modifikace bytecode za úˇcelem dosažení nˇejaké pˇridané funkcionality, bez nutnosti touto funkcionalitou znepˇrehlednit puvodní
˚
tˇrídu. Používá se napˇríklad pro umožnˇení
aspektovˇe orientovaného programování s funkcemi, jež jdou napˇríˇc kódem, nebo pro Líné naˇcítání asociovaných entit v JPA.
43
5.1. JAVASERVER FACES
5.1.3 Problémy s JSF 2.0
Bˇehem vývoje jsem se setkal s množstvím pˇrekážek. V poslední dobˇe velmi rychlý vývoj
JSF si v tomto ohledu vybral svoji dan.
ˇ Nˇekteré, ne pˇríliš obvyklé zpusoby
˚
užití, nejsou
dostateˇcnˇe propracovány a otestovány. Pˇri manuálním vytváˇrení stromu komponent jsem
chtˇel použít novinku v JSF 2.0 takzvané kompozitní komponenty. To bohužel nebylo tak
jednoduché.
JSF jako komponentní framework umožnuje
ˇ
rozšiˇrovat stávající, cˇ i vytváˇret úplnˇe nové
komponenty. Jde o jednu z klíˇcových vlastností. Až do verze 2.0 však bylo vytváˇrení vlastních komponent pomˇernˇe nelehkým úkolem. I když vývojáˇr zvládl byrokracii JSF, vytvoˇrit
vlastní univerzální a správnˇe fungující komponentu zabralo nemalé množství cˇ asu. V JSF 2
mˇely tento problém rˇ ešit kompozitní komponenty. Jsou to vlastnˇe nevelké fragmenty view
tamplate, kde se pomocí existujících komponent a speciálních tagu˚ vytváˇrí komponenty
nové, snadno použitelné.
Nikde se mi nepodaˇrilo najít adekvátní informace, týkající se dynamického vytváˇrení
kompozitních komponent. Vˇedˇel jsem, že sám rámec JSF musí ve fázi Restore view nˇejakým zpusobem
˚
jejich pamˇet’ovou reprezentaci vytváˇret. Po nesˇcetných pokusech, mnoha
dnech strávených zkoumáním kódu JSF a diskuzí s vývojáˇri na fóru Mojarry, se mi podaˇrilo
dopracovat se k použitelnému rˇ ešení. Bohužel se však o mnoho pozdˇeji ukázalo, že takto
vytvoˇrené komponenty jsou velmi nespolehlivé a pˇrestávají fungovat pokud jsou navzájem
zanoˇrovány. Proto jsem kompozitní komponenty v tomto pˇrípadˇe vyhodnotil jako prakticky
nepoužitelné a vydal se hledat jiné rˇ ešení. Toto zjištˇení mˇe sice stálo mnoho úsilí, cˇ asu (a
nervu)
˚ vyústilo však v nˇekolik, doufám pˇrínosných záznamu˚ do seznamu bugu˚ specifikace
JSF i její implementace Mojarra. I díky to mu by mˇelo být jednoduché vytváˇrení dynamických kompozitních komponent plnˇe podporováno, jak ve specifikaci, tak v implementaci
JSF 2.2, jež má být vydána zaˇcátkem roku 2012. V neposlední rˇ adˇe mi toto úsilí pomohlo
prohloubit moje znalosti rámce JSF.
Situaci jsem vyˇrešil tak, že místo kompozitních komponent jsem vytvoˇril tˇrídy reprezentující konkrétní prvky formuláˇre. Napˇríklad vstup pro text s popisem, nápovˇedou, konfiguraˇcním panelem, funkcí táhni a pust’, tlaˇcítkem pro odstranˇení prvku atd. Tyto tˇrídy
potom v sobˇe obsahují logiku, která vytvoˇrí strom komponent reprezentující samotný prvek formuláˇre i konfiguraˇcní panel pro nastavení tohoto prvku. Strom komponenty reaguje
na zmˇeny z konfiguraˇcního panelu a adekvátnˇe upravuje nastavení komponent prvku formuláˇre. Strom komponent prvku formuláˇre muže
˚ být také nastaven dle datového objektu
z databáze, který logicky reprezentuje danou komponentu, viz obrázek 4.3.
Tˇrídy reprezentující prvky formuláˇre také poskytují dva režimy zobrazení. V editaˇcním
režimu je možné prvky formuláˇre pˇremíst’ovat, mazat, nebo mˇenit jejich nastavení v konfiguraˇcním panelu. V prohlížecím režimu tyto komponenty nelze nijak upravovat. Proto ani
není vytváˇren konfiguraˇcní panel. Pokud se ovšem jedná o vstupní komponenty, lze jejich
prostˇrednictvím zadávat a odesílat údaje.
Toto rˇ ešení není sice tak elegantní jako by bylo použití kompozitních komponent. Na
druhou stranu to má neˇcekanˇe i své výhody. Tˇrídy reprezentující prvky formuláˇre mohou
44
ˇ
5.2. APLIKA CNÍ
RÁMEC ICEFACES
využít hierarchie dˇediˇcnosti a nemusejí proto znovu implementovat cˇ ásti, které již byly v jiných, tˇreba i jednodušších tˇrídách prvku˚ formuláˇre vyˇrešeny. V kompozitních komponentách, jež sou vytváˇreny na základˇe XML popisu bez podpory pro dˇediˇcnost, by toto použití
nebylo možné. Tím jsem pˇri tvorbˇe komponent ušetˇril znaˇcné množství práce.
5.2
Aplikaˇcní rámec ICEfaces
Pˇred pˇríchodem JSF 2.0 koncem roku 2009, nebylo možné v samotném JSF použít AJAX3 .
Pro podporu AJAXu bylo nutné minimálnˇe vyvinout nové komponenty, což je pomˇernˇe
pracné. Proto zaˇcaly vznikat projekty jako jsou RichFaces, ICEfaces, nebo Trinidad, 4 snažící
se tento projekt rˇ ešit. Vˇetšina projektu˚ poskytuje funkcionalitu na takové úrovni, že vývojáˇr
témˇerˇ nemusí pˇristoupit k použití JavaScriptu, který je za normálních okolností pro AJAX
ˇ ri roky po ustavení termínu [1], pˇrináší JSF 2.0 jako jednu z nejduležitˇ
nezbytný. Ctyˇ
˚
ejších
novinek jednotnou infrastrukturu a API pro standardizovanou podporu AJAXu. Pˇri návrhu
standardu je inspirace cˇ erpána z existujících rˇ ešení, zejména z rámce RichFaces. Rozmanité
rozšiˇrující rámce však stále mají smysl. Pˇrinášejí množství rozmanitých komponent a funkcí,
které dále rozšiˇrují i aktuální verze JSF. Naopak, dˇríve bylo velmi obtížné kombinovat ruzné
˚
knihovny komponent a rozšiˇrující rámce, hlavnˇe kvuli
˚ rozmanitým a nekompatibilním metodám použitým pro dosažení asynchronní komunikace. Nyní je vˇetšina úsilí smˇerˇ ována
k pˇrechodu na standardizovanou implementaci AJAXu v JSF 2. Použití jednotné komunikaˇcní infrastruktury napˇríˇc rozšiˇrujícími rámci by mˇelo prakticky umožnit jejich bezproblémovou interoperabilitu.
ICEfaces jsem zvolil hlavnˇe proto, že nabízí nejvˇetší množství komponent rozšiˇrujících
základní komponenty JSF, ale i komponent úplnˇe nových [12]. Velká výhoda ICEfaces ovšem
spoˇcívá v unikátním zpusobu
˚
implementace AJAXu, kterým se odlišují od ostatních rámcu˚
na bázi JSF, vˇcetnˇe JSF 2. Nepodaˇrilo se mi nalézt žádný rámec, který by v prostˇredí JSF
nabízel podobnou funkcionalitu.
ICEfaces totiž používají takzvané Direct-to-DOM [11] vykreslování. Klient komunikuje
se serverem pomocí takzvaného AJAX mostu. To znamená, že na klientské stranˇe je cˇ ást
mostu se kterou interaguje uživatel. Tato cˇ ást potom pomocí JavaScriptu komunikuje s druhou cˇ ástí mostu na Serveru, kde dojde ke spuštˇení JSF životního cyklu a následuje odpovˇed’
zpˇet na klienta obsahující cˇ ásti stánky které se mˇely pˇrekreslit. U vˇetšiny implementací je
tohoto chování dosaženo pomocí speciálních tagu,
˚ které specifikují události a akce, jež mají
vyvolat komunikaci pomocí AJAXu. Dále vymezují komponenty, tedy odpovídající cˇ ásti
stránky, které mají být následnˇe pˇrekresleny. Tento postup muže
˚ u složitých stránek dosahovat nezanedbatelné komplexity. Zˇrejmˇe si to vyžádá odpovídající programátorské úsilí a
další logiku, ve které se muže
˚ potenciálnˇe vyskytnout chyba. Napˇríklad muže
˚ dojít k tomu,
3. AJAX (Asynchronous JavaScript and XML) [1] je metodika vývoje interaktivních webových stránek, které
komunikují se serverem a odpovídajícím zpusobem
˚
mˇení svuj
˚ vzhled a obsah bez nutnosti opˇetovného naˇctení
stránky.
4. Trinidad vznikl darováním kódu ADF Faces firmou Oracle Open Source komunitˇe, proto je velmi podobný
rámci ADF Faces.
45
5.3. HTML5 TÁHNI A PUS Tˇ
že následkem AJAX akce dojde ke zmˇenˇe stavu komponenty na serveru, která není oznacˇ ena pro pˇrekreslení, po vyvolání této akce. Tím se desynchronizuje pohled se skuteˇcným
stavem, který vidí klient.
V ICEfaces tento explicitní popis asynchronní komunikace není potˇreba. V ICEfaces totiž
veškerá komunikace probíhá asynchronnˇe pokud to nenastavíme jinak. Jak ale rámec ICEfaces pozná, kterou cˇ ást stránky pˇrekreslit? Pˇri použití tohoto aplikaˇcního rámce totiž dojde
k nahrazení celého Render kitu JSF a tím fakticky ke zmˇenˇe chování závˇereˇcné fáze Render Response (viz 5.1) životního cyklu JSF. ICEfaces si v pamˇeti drží poslední stav pohledu,
který byl zaslán klientovi. Jakmile cyklus pˇrejde do poslední fáze, je serializován celý aktuální pohled a následnˇe porovnán s pohledem pˇredcházejícím. Klientovi jsou zaslány pouze
rozdíly mezi pˇredchozím a aktuálním pohledem. Nakonec je aktuální pohled uložen aby
byl k dispozici pro porovnání na konci dalšího cyklu.
Díky tomuto inteligentnímu vykreslování ICEfaces nedochází k pˇrekreslování komponent, ve kterých se ve skuteˇcnosti nic nezmˇenilo. Naopak nehrozí desynchronizace pohledu
a skuteˇcného stavu na stranˇe klienta. Na druhou stranu to pˇrináší jistou režii pˇri porovnávání dvou pohledu˚ pˇri každé interakci klient–server. To je v posledních verzích ICEfaces
rˇ ešeno optimalizaˇcními tagy, za pomoci kterých muže
˚ být oznaˇcen pouze výsek pohledu,
který má být pˇri dané asynchronní akci porovnáván s pˇredchozím stavem. Díky této optimalizaci ICEfaces nabízejí velmi elegantní a univerzální rˇ ešení asynchronní komunikace.
Mezi další optimalizace ICEfaces patˇrí takzvaný Single Submit , který umožnuje
ˇ
vybrat skupinu komponent, které mají samostatnˇe projít životním cyklem aplikace. Nemusí být tedy
zbyteˇcnˇe zpracovávána celá stránka, je redukována s tím spojená režie.
Jako pokroˇcilý webový framework poskytující AJAX, ICEfaces umožnují
ˇ efektivnˇe emulovat reverzní komunikaci od serveru smˇerem ke klientovi, pro kterou nebyl protokol HTTP
puvodnˇ
˚
e koncipován. Tento model webové komunikace bývá nazýván jako Comet, AJAX
push , nebo AJAX 2.0 [2]. V ICEfaces mohou být klienti rozdˇeleni do skupin, následnˇe je
možné na serveru vybrat skupinu a explicitnˇe vynutit aktualizaci stavu všech klientu˚ v ní
zaˇrazených. Tato funkcionalita najde své uplatnˇení v rámci moderního webu 2.0. Pokaždé
když je potˇreba na webu sledovat aktuální stav, napˇríklad v pˇrípadˇe elektronických aukcí,
sledování sociálních sítí, monitoringu zaˇrízení a tak dále. V ICEfaces je AJAX push implementován pomocí long polling 5 , nedochází tedy k pˇrehnanému zatížení serveru a proto je
možné tuto metodu použít i pro vˇetší množství klientu.
˚
5.3
HTML5 táhni a pust’
Jak jsem již uvedl, ve vyvíjené aplikaci jsem chtˇel dosáhnout co nejpˇríjemnˇejšího a nejefektivnˇejšího rozhraní pro tvorbu formuláˇru.
˚ Mimo intenzivního využití asynchronní komunikace se mi zdálo jako velice pˇríhodné, umožnit vytváˇrení formuláˇru˚ pomocí akcí typu
5. Long polling funguje tak, že klient pomocí JavaScriptu otevˇre spojení a zašle požadavek na server. Toto
spojení zustává
˚
otevˇreno dokud server nemá nˇejaká data, která by poslal zpˇet. Následnˇe klient zase otevˇre nové
spojení. Tato metoda je efektivnˇejší než periodické dotazování serveru klientem a zárovenˇ je široce podporována
webovými prohlížeˇci.
46
5.3. HTML5 TÁHNI A PUS Tˇ
táhni a pust’ (známˇejší pod názvem Drag and Drop, zkrácenˇe DND). Uživatel snadno vybere formuláˇrový prvek a pˇridá ho na libovolné vhodné místo ve vytváˇreném formuláˇri.
Stejnˇe tak snadno pˇretažením uspoˇrádá poˇradí prvku˚ ve formuláˇri. Podpora pro akce tohoto typu se nachází snad v každém rámci rozšiˇrujícím funkcionalitu JSF. V souˇcasné dobˇe
jsou však všechny implementace založeny na emulaci DND pomocí JavaScriptu. Já jsem se
však rozhodl pro implementaci nativního táhni a pust’ v souladu se standardem HTML5.
Duvod
˚
u˚ pro implementaci táhni a pust’ pomocí HTML5, i když existovalo pˇrímoˇcaré
rˇ ešení za pomoci JavaScriptu, bylo nˇekolik:
•
Široká podpora prohlížeˇci Pˇrestože je HTML5 velice mladý standard, který stále ještˇe
není dokonˇcen [10], všechny bˇežnˇe používané prohlížeˇce implementují nˇejakou jeho
podmnožinu. Nativní táhni a pust’ patˇrí mezi jednu z jeho nejlépe podporovaných
cˇ ástí [24]. Tento standard byl z velké míry pˇrevzat z proprietárního prohlížeˇce Internet Explorer. Proto je podporován Internet Explorerem už od verze 5. Já osobnˇe
jsem to zkoušel zpˇetnˇe až do verze 7. U ostatních prohlížeˇcu˚ sice nesahá podpora pro
DND tak hluboko do historie, také se však u nich tak cˇ asto nestává, aby jejich historické verze pˇrežívaly ve významných poˇctech zakonzervovány ve zkostnatˇelých
organizacích.
•
Nezávislost na JavaScriptovém, nebo jiném rámci Pokud bych se rozhodl pro implementaci pomocí JavaScriptové emulace, urˇcitˇe bych využil nˇejaké již hotové rˇ ešení poskytované JavaScriptovým, nebo jiným rámcem. To by sebou neslo závislost
na dalším aplikaˇcním rámci.
•
Možná integrace s jinými webovými aplikacemi HTML5 umožnuje
ˇ
používat DND
napˇríˇc okny a kartami prohlížeˇce.
•
Možná integrace s operaˇcním systémem HTML5 také umožnuje
ˇ
používat DND i
v návaznosti na operaˇcní systém. Napˇríklad je možné odeslat soubor na web jeho
pˇretažením nad cˇ ást webové stránky, což bych také v budoucnu rád využil pro vytváˇrení formuláˇru˚ s možností nahrávání souboru.
˚
•
Uživatelsky nejpˇríjemnˇejší efekt Nativní táhni a pust’ má pˇredpoklady pro nejplynulejší a nejvˇernˇejší projev. Akce je provádˇena pomocí nativních funkcí systému, což
se nedá srovnávat s emulací JavaScriptem. Z vlastní zkušenosti mohu rˇ íci, že efekt
pusobí
˚
opravdu vˇernˇe a pˇríjemnˇe.
•
Nejefektivnˇejší implementace Nativní DND má zˇrejmˇe výraznˇe menší nároky na
výpoˇcetní výkon klientského stroje.
•
Seznámení se s perspektivním standardem Je bez pochyb, že HTML5 je velkým pˇrínosem pro web, pˇri vývoji kvalitního moderního webu se bez nˇej nebude možné obejít. Webová komunita standard obecnˇe velice kladnˇe pˇrijímá. Proto považuji za pˇrínosné, když se mohu s tímto standardem a jeho praktickým využitím lépe seznámit.
47
5.3. HTML5 TÁHNI A PUS Tˇ
Pro použití klasického JavaScriptového rˇ ešení se mi podaˇrilo nalézt jen málo duvod
˚
u:
˚
•
Existující vyzkoušené rˇešení Je možné bez vˇetší námahy a pomˇernˇe rychle implementovat existující a léty provˇerˇ ené rˇ ešení.
•
Vysoká kompatibilita Existují verze prohlížeˇcu,
˚ ve kterých není možné použít HTML5
DND. Emulace prostˇrednictvím JavaScriptu má podporou i v nˇekterých verzích prohlížeˇcu˚ kde HTML5 DND nefunguje.
Rozhodování tedy bylo pomˇernˇe jednoduché, ne tak už samotná implementace. Zaˇcal jsem
vytváˇret nové JSF komponenty, které rozšiˇrují komponentu HtmlPanelGroup. HtmlPanelGroup slouží primárnˇe k seskupení ostatních komponent do skupin. Výstupem je HTML
element div, nebo span obohacený o nˇejakou další funkcionalitu. Idea byla taková, že tˇemito komponentami obalím vše co má interagovat s akcemi typu táhni a pust’. Pomocí reakcí na události jež budou z klientské cˇ ásti propagovány až na server, pak bude možné ke
komponentám doplnit vlastní logiku.
Pomˇernˇe záhy se mi podaˇrilo dle množství návodu˚ a dokumentace dostupných na Internetu zprovoznit první verzi, která bezproblémovˇe fungovala v prohlížeˇci Chrome. Poté ale
následovala neˇcekanˇe obtížná fáze zprovoznˇení mé implementace na ostatních rozšíˇrených
prohlížeˇcích, tedy Firefoxu a Internet Exploreru.
Pˇri použití HTML5 DND staˇcí pˇretahovatelnému elementu nastavit atribut draggable.
Element je pak možné uvádˇet v pohyb, pˇri kterém jsou vyvolávány ruzné
˚
události na dotˇcených prvcích. Pˇríkladem vyvolaných událostí jsou: Zapoˇcetí tažení (dragStart), vstup do
prvku (dragEnter), výstup z prvku (dragLeave), upuštˇení nad prvkem (drop) a tak dále. Na
tyto události je následnˇe možné reagovat pomocí JavaScriptu a vykonat potˇrebné akce.
Aby HTML5 DND fungovalo ve Firefoxu, bylo nutné vložit nˇejaký Data Transfer objekt
do události vyvolané pˇri zapoˇcetí pˇretahování (událost DragStart). V Chrome vše fungovalo i bez použití tohoto objektu. Data Transfer objekt slouží obvykle k pˇredání informace
o tom, který prvek stránky je pˇrenášen, prvku nad kterým je pˇrenášený objekt upuštˇen (pˇri
vyvolání události drop). Z mého pohledu nebylo nutné tento objekt použít, protože pro mˇe
bylo jednodušší na událost vyvolanou zapoˇcetím tažení reagovat voláním serveru, na kterém jsem také držel informaci o pˇretahovaném prvku. Nicménˇe, kvuli
˚ kompatibilitˇe pˇresto
do Data Transfer objektu nˇejaký rˇ etˇezec vkládám.
Pˇrekvapivˇe bylo daleko obtížnˇejší zprovoznit DND v prohlížeˇci Internet Explorer pˇresto,
že specifikace mˇela být pˇrevzata právˇe z tohoto prohlížeˇce. V IE totiž DND funguje jen u elementu anchor ( <a>), který navíc musí mít vyplnˇen atribut href. Získání tohoto poznatku mˇe
stálo velké množství cˇ asu, protože se mi kupodivu nepodaˇrilo nikde najít zmínku o tomto
specifiku IE, i když návodu˚ a postupu˚ pro implementaci HTML5 DND je celá rˇ ada. Dalším
zádrhelem, o kterém se nikde nepíše, je nutnost v elementu sloužícím k upuštˇení reagovat
na událost pˇresun nad prvkem (DragOver) a nastavit této události returnValue na hodnotu
false viz pˇríklad 5.3.1 6 . V opaˇcném pˇrípadˇe nedošlo k upuštˇení elementu.
6.
Otestováno v Internet Exploreru verze 8.
48
5.3. HTML5 TÁHNI A PUS Tˇ
Obrázek 5.3: Ukázka jedné z prvních funkˇcních verzí HTML5 DND
Tím byly vyˇrešeny všechny problémy s kompatibilitou prohlížeˇcu.
˚ Vyvstal však problém
týkající se implementace JSF. Problém se týkal pˇrípadu kdy se prvek tažením pˇremíst’oval
z místa na místo. To znamená, že prvek na puvodním
˚
místˇe byl odstranˇen, na novém místˇe
pak byl vytvoˇren nový identický prvek. K implementaci této funkcionality jsem používal infrastrukturu JSF pro asynchronní komunikaci. Celá akce zaˇcínala reakcí na událost zapoˇcetí
tažení (DragStart). Pokud jsem tuto událost na komponentˇe zaregistroval pro asynchronní
komunikaci prostˇrednictvím JSF, došlo k registraci HTML elementu reprezentujícího tuto
komponentu k dalším interním událostem v rámci JavaScriptového klientského rozhraní JSF
[14]. Pokud jsem však po sléze tuto komponentu odstranil ze stromu komponent a umístil
ji na jiné místo, interní odkaz na HTML element reprezentující tuto komponenty v rámci
JavaScriptu JSF najednou nabyl hodnoty null. Následnˇe došlo k vyvolání vnitˇrní události
v rámci JSF, jejíž zpracování ztroskotalo právˇe na tomto prázdném odkazu. Tím došlo k zastavení všech JavaScriptových interakcí a pro další použití bylo nutné znovu naˇcíst stránku.
Toto chování je neakceptovatelné. Implementace JSF tedy nepoˇcítá s tím, že by se stromem
49
5.4. DIAGRAM NASAZENÍ
function handleDragOver(e) {
var e = e || window.event;
if(e.preventDefault) {
e.preventDefault();
} else {
e.returnValue = false;
}
}
Pˇríklad 5.3.1: Reakce na událost pˇretahování pˇres element ( [code] DragOver [/code] )
komponent mohlo být manipulováno. Pˇritom by staˇcil jednoduchý test ukazatele na hodnotu null. Nedostatek jsem nahlásil jako chybu do systému pro správu projektu JSF 7 .
Zmínˇený problém se mi podaˇrilo obejít tak, že jsem na zapoˇcetí tažení reagoval bˇežným
JavaScriptem volajícím asynchronní JSF akci na jiném HTML elementu 8 . Akce vyvolaná na
HTML elementu již nebyla bezprostˇrední reakcí na DND událost a nejspíše proto nedošlo
k registraci HTML elementu ve vnitˇrní infrastruktuˇre klientského rozhraní JSF. Tudíž nebyla
vyvolána vnitˇrní událost JSF manipulující s ukazatelem na již neexistující HTML element.
5.4
Diagram nasazení
Diagram nasazení nám umožnuje
ˇ
získat konkrétní pˇredstavu o fyzickém rozvržení aplikaˇcního systému. Z tohoto diagramu je možné vyˇcíst, na jakých zaˇrízeních je systém nasazen,
jaká bˇehová prostˇredí jsou použita a jak je vše propojeno dohromady. Získáváme pˇrehled
o architektuˇre konkrétního bˇehového prostˇredí softwarového systému.
Jak je znázornˇeno na diagramu nasazení, 5.4 aplikace pro tvorbu webových formuláˇru˚
je vyvíjena na takzvaném Servlet kontejneru, konkrétnˇe se jedná o Apache Tomcat 7. Servlet kontejner vˇetšinou poskytuje jen základní Servlet API. Velkou cˇ ást služeb, standardnˇe
poskytovaných plnohodnotnými Java EE servery, jsem nahradil pomocí aplikaˇcního rámce
Spring, který je souˇcástí webové aplikace. Pro bˇeh aplikace je tedy dostaˇcující jen malá podmnožina platformy Java EE. Je omezena závislost aplikace na konkrétním bˇehovém prostˇredí a je tedy snadnˇejší ji provozovat i na jiných aplikaˇcních serverech, jako jsou GlassFish
Server, IBM WebSpehere, nebo Oracle WebLogic.
Aplikaci samotnou jsem implementoval tak, aby byla logicky rozdˇelena do tˇrí komponent. Komponenta Service poskytuje základní logiku aplikace, pracuje s databází a pˇrevádí
entitní tˇrídy na takzvané DTO 9 . Klientské komponenty komunikují se servisní komponentou a poskytují uživatelské rozhraní pro tvorbu formuláˇru˚ a zobrazování formuláˇru˚ pˇripravených k vyplnˇení. Návrhový vzor DTO zabezpeˇcí nezávislost klientských komponent na
ORM rámci použitém v servisní cˇ ásti.
7. Dostupný na URL <http://java.net/jira/browse/JAVASERVERFACES>
8. JavaScriptové volání i element samotný jsou souˇcástí výsledné komponenty.
9. DTO – Data Transfer Object. Jedná se o návrhový vzor sloužící pro pˇrenos dat mezi cˇ ástmi aplikace. Vˇetšinou
se jedná o jednoduché Javové tˇrídy bez funkcionality, sloužící jen pro pˇrenos dat.
50
5.4. DIAGRAM NASAZENÍ
Obrázek 5.4: Diagram nasazení aplikace pro tvorbu webových formuláˇru˚
Díky Springu a návrhovému vzoru DI jsou komponenty na sebe vázány velmi volnˇe. Lze
je snadno rozdˇelit do samostatných webových aplikací, propojených webovými službami.
Tyto aplikace pak lze provozovat na ruzných
˚
fyzických serverech, a tak podpoˇrit škálovatelnost aplikace.
Servisní komponenta v sobˇe zahrnuje ORM rámec, prostˇrednictvím kterého pracuje s databází. ORM používá JDBC 10 pro komunikaci s relaˇcní databází. Aplikace je vyvíjena nad
databázovým systémem MySQL, bˇežícím na samostatném serveru.
Pro zlepšení výkonnosti je mezi uživatele a servlet kontejner vložen webový server. Uživatel zasílá HTTP požadavky na webový server, konkrétnˇe Apache HTTP server. Webový
server potom požadavky, na aplikaci pro tvorbu formuláˇru,
˚ pˇreposílá pomocí protokolu
AJP na servlet kontejner. Statický obsah, jako jsou napˇríklad obrázky, je poskytován pˇrímo
webovým serverem, který je v tomto ohledu výraznˇe rychlejší. Pˇrípadnˇe je také možné tímto
zpusobem
˚
rˇ ešit vyvažování zátˇeže. V tomto pˇrípadˇe, by pak bˇežely instance webové aplikace v nˇekolika servlet kontejnerech na ruzných
˚
fyzických serverech. HTTP server by pak
zátˇež rozkládal mezi tyto fyzické servery.
10. JDBC – Java Database Conectivity, Javové API pro unifikovaný pˇrístup k relaˇcním databázím.
51
5.4. DIAGRAM NASAZENÍ
Výše popsané nasazení aplikace pro tvorbu webových formuláˇru˚ je možné vyzkoušet
na URL <http://formcreator.ukryt.net>. Na této adrese je k dispozici nejaktuálnˇejší vývojová verze. Aktuální verze aplikace je zde nasazena pomocí serveru kontinuální
integrace[4]. Konkrétnˇe se jedná o Open-Source server Jenkins11 pokraˇcovatel oblíbeného
Hudsonu. Jenkins je propojen se serverem pro správu kvality kódu Sonar12 . Sonar prubˇ
˚ ežnˇe
vykonává velké množství nejruznˇ
˚ ejších analýz kódu. Na URL <http://formcreator.
ukryt.net/sonar> lze nalézt výsledky tˇechto analýz.
11. <http://jenkins-ci.org/> (leden 2012)
12. <http://www.sonarsource.org/> (leden 2012)
52
Kapitola 6
Závˇer
V úvodní cˇ ásti práce jsem nejprve popsal, co to jsou webové nástroje pro správu formuláˇru˚ a
k jakému úˇcelu slouží. Specifikoval jsem základní pojmy potˇrebné pro orientaci v problematice. Následnˇe jsem popsal existující aplikace s jejich pˇrednostmi i nedostatky. Opodstatnil
jsem vznik nové webové aplikace.
V další kapitole podrobnˇeji rozebírám požadavky kladené na aplikaci vznikající jako
souˇcást této práce. Požadavky specifikuji pomˇernˇe velkoryse, s vˇedomím, že pˇresahují rozsah a možnosti této práce. Tato široká specifikace mi však umožní bˇehem následné analýzy
a vývoje lépe udržovat smˇer, kterým se má aplikace ubírat. Také mi poslouží jako základ
pro budoucí vývoj webové aplikace pro tvorbu formuláˇru.
˚ Zminuji
ˇ
také iterativní a inkrementální metodologii vývoje, která byla pro vývoj aplikace použita.
Následuje cˇ ást zabývající se analýzou a návrhem jádra webové aplikace doprovázená
diagramy. Souˇcasnˇe popisuji aplikaˇcní rámce a návrhové vzory, které se odrážejí ve výsledném návrhu. Mezi tyto patˇrí Spring a vkládání závislostí ( dependency injection), nebo mapování relaˇcní databáze na entitní tˇrídy ( object relational mapping). Také zde upozornuji
ˇ na
opomíjený princip takzvané inverze rˇ ízení, odlišující aplikaˇcní rámce od prostých knihoven.
V závˇereˇcné kapitole jsem nastínil architekturu aplikace a možnosti jejího nasazení. Popsal jsem zajímavé postupy a významné technologie použité pˇri samotné implementaci
webové aplikace pro tvorbu webových formuláˇru.
˚
Velká cˇ ást práce je vˇenována komponentnímu MVC ( Model View Controller) rámci
JavaServer Faces. Jedná se totiž o hlavní technologii prezentaˇcní vrstvy. Tento rámec byl
v práci použit pomˇernˇe neobvyklým a velmi málo zdokumentovaným zpusobem.
˚
Jednotlivé komponenty v JSF bˇežnˇe mˇení svuj
˚ stav a obsah. Pˇri tvorbˇe webových formuláˇru,
˚ však
vyvstávala potˇreba pro dynamické vytváˇrení stromu komponent reprezentujících formuláˇr. Jedním z pˇrínosu˚ této práce je nalezení a popsání spolehlivého postupu pro manipulaci
s dynamickým stromem komponent. Do nalezení spolehlivé metody jsem investoval nezanedbatelné úsilí. Svuj
˚ díl na tom nesly i chyby jak ve specifikaci, tak v implementaci JSF
1
verze 2.1 . V implementaˇcní cˇ ásti práce je tento postup prakticky použit.
Jedná se sice o pokroˇcilejší zpusob
˚
užití JSF, muže
˚ však být velmi pˇrínosný. Využití najde zvláštˇe pˇri tvorbˇe složitˇejších, dynamicky se mˇenících webových stránek. Do budoucna
by bylo vhodné uvedenou metodu podrobit zátˇežovým testum
˚ a provést vhodné optimali1. Vˇetšina tˇechto nedostatku˚ (nˇekteré jsem pomáhal identifikovat) by mˇela být odstranˇena s pˇríchodem JSF
verze 2.2, snad již v prvním cˇ tvrtletí roku 2012.
53
ˇ
6. Z ÁV ER
zace. Výpoˇcetní nároˇcnost je pomˇernˇe pˇríznivá, horší je to s pamˇet’ovými nároky, zvláštˇe pˇri
souˇcasném pˇrístupu velkého množství uživatelu.
˚
V rámci práce jsem také nalezl a popsal implementaci akce „táhni a pust’“ dle standardu HTML5, která je opravdu funkˇcní na drtivé vˇetšinˇe používaných webových prohlížeˇcu˚ (vˇcetnˇe zastaralých verzí Internet Exploreru). Návody a postupy, jež se mi podaˇrilo
najít, ve skuteˇcnosti nemˇely takovou podporu napˇríˇc prohlížeˇci.
Ve vývoji aplikace budu pokraˇcovat i po odevzdání této práce. Systém je již v testovacím
režimu používán úzkým okruhem uživatelu,
˚ majících zájem o její budoucí praktické využití.
Další funkce budu implementovat na základˇe reálných zkušeností s používáním aplikace.
ˇ
Cerpat
budu také z kapitoly 3.
Systém pro tvorbu webových formuláˇru˚ využívá znaˇcného množství aplikaˇcních rámcu˚
a knihoven splnujících
ˇ
definici otevˇreného software ( Open Source Software). Dodržení filozofie a principu˚ otevˇreného software považuji za nejlepší zpusob,
˚
jak zajistit co nejlepší
rozvoj aplikace a zužitkovat úsilí, které bylo investováno do jejího vývoje. Z tˇechto duvod
˚
u˚
hodlám aplikaci uvolnit pod otevˇrenou licencí.
54
Literatura
[1] Garrett, J.: Ajax: A New Approach to Web Applications, Dokument
dostupný
na
URL
<http://www.adaptivepath.com/ideas/
ajax-new-approach-web-applications> (prosinec 2011) , 2005. 5.2, 3
[2] Crane, D. a McCarthy, P.: Comet and Reverse Ajax: The Next-Generation Ajax 2.0,
2008, Apress, 978-1590599983, 100. 5.2
[3] Johnson, R. a Laddad, R.: Aspectj in Action: Enterprise AOP with Spring Applications,
Manning Publications, 2009, 978-1933988054, 568. 5.1.2
[4] Duval, P. a Matyas, S. a Glover, A.: Continuous Integration: Improving Software Quality and Reducing Risk, Addison-Wesley Professional, 978-0321336385, 2007, 336. 5.4
[5] Alur, D. a Malks, D. a Crupi, J.: Core J2EE Patterns: Best Practices and Design Strategies, Prentice Hall, 2003, 978-0131422469, 528. 4.3
[6] Fowler, M.: Inversion of Control Containers and the Dependency Injection pattern, Dokument dostupný na URL <http://martinfowler.com/articles/
injection.html> (prosinec 2011) , 2004. 4.1
[7] Fowler, M.: Patterns of Enterprise Application Architecture, Addison-Wesley Professional, 2002, 978-0321127426, 560. 4.1, 4.3
[8] Jendrock, E. a Evans, I. a Gollapudi, D. a Srivathsa, C. a Haase, K.: The Java EE 6
Tutorial: Basic Concepts (4th Edition) , Prentice Hall, 2010, 978-0137081851, 600. 4.4.3
[9] Jendrock, E. a Evans, I. a Gollapudi, D. a Srivathsa, C. a Haase, K.: The Java EE 6
Tutorial: Advanced Topics (4th Edition), Prentice Hall, 2012, 978-0137081868, 768.
[10] Hickson, I.: HTML5: A vocabulary and associated APIs for HTML and XHTML, Dokument dostupný na URL <http://dev.w3.org/html5/spec/Overview.html>
(prosinec 2011) , 2011 . 5.3
[11] ICEfaces 2 Documentation, Dokument dostupný na URL <http://wiki.
icefaces.org/display/ICE/ICEfaces+2+Documentation> (prosinec 2011) ,
2010. 5.2
[12] The JSF Matrix, Dokument dostupný na URL <http://www.jsfmatrix.net>
(prosinec 2011) , 2006. 5.2
[13] Burns, E. a Griffin, N.: JavaServer Faces 2.0, The Complete Reference, McGraw-Hill
Osborne Media, 2009, 978-0071625098, 752. 5.1.2
55
[14] Driscoll, J.: JSF 2: Ajax Events and Errors, Dokument dostupný na URL
<http://weblogs.java.net/blog/driscoll/archive/2009/05/jsf_
2_ajax_even.html> (prosinec 2011) , 2009. 5.3
[15] Ambler, S.: The Object Primer 3rd Edition: Agile Model Driven Development with
UML 2, Cambridge University Press, 978-0521540186, 2004, 572.
[16] Johnson, R.: Expert One-on-One J2EE Design and Development, Peer Information,
2002, 978-1861007841, 750.
[17] Keith, M. a Schincariol, M.: Pro JPA 2: Mastering the Java(TM) Persistence API ,
Apress, 2009, 978-1430219569, 536. 4.4.1
[18] Spring Framework - Reference Documentation, Dokument dostupný na
URL
http://static.springsource.org/spring/docs/3.1.x/spring-frameworkreference/html/
<http://static.springsource.org/spring/docs/3.
1.x/spring-framework-reference/html> (prosinec 2011) , 2011 .
[19] Mularien, P.: Spring Security 3, Packt Publishing, 2010, 978-1847199744, 420.
[20] Wroblewski, L. a Spool, J.: Web Form Design, Rosenfeld Media, Brooklyn, New York,
2008, 978-1-933820-24-1, 226. 3.2
[21] Stallman, R.: What Does That Server Really Serve?, Boston Review, 2010,
Dokument
dostupný
na
URL
<http://www.gnu.org/philosophy/
who-does-that-server-really-serve.html> (ˇríjen 2011) . 2.1
[22] Wysocki, R.: Effective Project Management: Traditional, Agile, Extreme, Wiley, 9780470423677, 2009, 792. 3.4
[23] Garfinkel, S.: Abelson, H.: Architects of the Information Society, Abelson, H.: , The
MIT Press, 1999, 978-0262071963, 86. 2.1
[24] Deveria, A.: When can I use..., Zdroj dostupný na URL <http://caniuse.com>
(prosinec 2011) . 5.3
[25] Cardelli, L.: Bad Engineering Properties of Object-Oriented Languages, ACM Computing Surveys, roˇcník 28, cˇ íslo 4, ACM New York, 1996, 150. 4.4
[26] Component Bindings, Dokument dostupný na URL <http://myfaces.apache.
org/orchestra/myfaces-orchestra-core/component-bindings.html>
(prosinec 2011) , 2009. 5.1.2
[27] Cockburn, A.: CrossTalk, roˇcník 21. , kvˇeten 2008, Dokument dostupný na URL
<http://www.crosstalkonline.org/storage/issue-archives/2008/
200805/200805-0-Issue.pdf> (záˇrí 2011) , 27. 3.4
56
[28] McCall, T. a Stevens, H.: Gartner Says Worldwide Software as a Service Revenue Is Forecast to Grow 21 Percent in 2011, Gartner, Inc., 2011, Dokument
dostupný na URL <http://www.gartner.com/it/page.jsp?id=1739214&M=
6e0e6b7e-2439-4289-b697-863578323245> (záˇrí 2011) . 2.1
[29] Johnson, R. a Foote, B.: Designing Reusable Classes, Journal of Object-Oriented Programming, roˇcník 1, cˇ íslo 2 , SIGS Publications Denville, NJ, USA, Dokument dostupný na URL <http://www.laputan.org/drc/drc.html> (listopad 2011) ,
1988. 4.1
[30] Programmatic manipulation of the components, Dokument dostupný na URL
<http://wiki.apache.org/myfaces/Programmatic> (prosinec 2011) , 2009.
5.1.2
[31] Sommerville, I.: Software Engineering (9th Edition), Addison Wesley, 2010, 9780137035151, 792. 4
[32] Simic, R.: Stateless JSF: high performance, zero per request memory overhead,
Dokument dostupný na URL <http://industrieit.com/blog/2011/11/
stateless-jsf-high-performance-zero-per-request-memory-overhead/>
(prosinec 2011) , 2011.
[33] Sweet, R.: The Mesa programming environment, SLIPE ’85 Proceedings of the ACM
SIGPLAN 85 symposium on Language issues in programming environments, ACM
New York, Dokument dostupný na URL <http://www.digibarn.com/friends/
curbow/star/XDEPaper.pdf> (listopad 2011) , 1985, 0-89791-165-2, 257. 2
[34] Smith, D.: A Brief History of TopLink, Dokument dostupný na URL <http://www.
oracle.com/technetwork/topics/history-of-toplink-101111.html>
(záˇrí 2011) . 4.4.1
[35] Fowler, M.: UML Distilled, Addison-Wesley Professional, 2003, 978-0321193681, 208.
3.4
57
Pˇríloha A
Zdrojové kódy aplikace pro torbu webových formuláˇru˚
Souˇcástí práce jsou zdrojové kódy webové aplikace pro tvorbu formuláˇru.
˚ S prací byl odevzdán i soubor FormCreator.zip. V tomto souboru jsou zdrojové kódy ve formátu projektu
Maven 2. Všechny nutné závislosti by se tedy mˇely automaticky stáhnout z nastavených
repozitáˇru.
˚
Aplikace je vyvíjena a otestována na aplikaˇcním kontejneru Apache Tomcat 7 1 . Pro
správnou funkci je tˇreba do knihoven Tomcatu (TOMCAT_HOME/lib) pˇridat JDBC driver databáze, na které bude aplikace provozována. Dále je potˇreba na stejné místo pˇridat náhradní classloader Springu pro správnou funkci JPA – spring-instrument-tomcat3.1.0.RELEASE.jar 2 .
V aplikaci jsou dva konfiguraˇcní soubory, které je nutné správnˇe nastavit.
src/main/resources/META-INF/jdbc.properties Zde je tˇreba nastavit pˇrístup k databázi. JPA
automaticky vytvoˇrí potˇrebné tabulky.
src/main/resources/META-INF/FormCreatorConfig.properties Zde je tˇreba nastavit pˇrístup
k SMTP serveru pro správnou funkci zasílání e-mailu.
˚ >
Aplikaci je také možné vyzkoušet on-line, viz konec kapitoly 5.4.
1. Dostupný z: <http://tomcat.apache.org/> (leden 2012).
2. <http://repo1.maven.org/maven2/org/springframework/spring-instrument-tomcat/3.
1.0.RELEASE/spring-instrument-tomcat-3.1.0.RELEASE.jar> (leden 2012)
58
Download

Systém pro správu webových formulářů