}w
!"#$%&'()+,-./012345<yA|
Masarykova univerzita
Fakulta informatiky
e-learningová aplikácia
na výučbu návrhových vzorov
Diplomová práca
Bc. Branislav Paulis
Brno, jar 2013
prehlásenie
Prehlasujem, že táto diplomová práca je mojím pôvodným autorským dielom,
ktoré som vypracoval samostatne. Všetky zdroje, pramene a literatúru, ktoré
som pri vypracovaní používal alebo z nich čerpal, v práci riadne citujem s uvedením úplného odkazu na príslušný zdroj.
V Brne dňa 23. mája 2013
Branislav Paulis
Vedúci práce: RNDr. Radek Ošlejšek, Ph.D.
ii
poďakovanie
Na nasledujúcich riadkoch by som veľmi rád poďakoval svojmu vedúcemu
RNDr. Radkovi Ošlejškovi, Ph.D. za jeho čas, ktorý si na mňa vždy ochotne
našiel, rovnako ako aj za jeho poskytnuté pripomienky a ostatné cenné rady.
Obrovské vďaka chcem ďalej vysloviť svojim milujúcim rodičom a sestre, ktorej
budem v živote vždy držať palce, že ma podporovali počas celého štúdia možno
aj viac, než vôbec sami tušia. Ďakujem tiež priateľke za jej pomoc, nesmiernu
trpezlivosť a úsmev, všetkým kamarátom, kolegom a hlavne chalanom, ktorí
sa mi snažili poradiť pri volaní vzdialených EJB.
iii
zhrnutie
Cieľom diplomovej práce je vytvoriť sadu UML diagramov tried zachytávajúcu
návrhové vzory od autorov prezývaných Gang of Four. Tieto diagramy sú prezentované vo vektorovom formáte SVG, kde sú doplnené o sémantické anotácie
pomocou ontológie s použitím jazyka OWL. Sada diagramov je súčasťou webovej aplikácie – klienta, ktorý je implementovaný pomocou Java technológií
a využíva služby systému GATE vyvíjaného na Fakulte informatiky Masarykovej univerzity. Aplikácia poskytuje prostredie na výučbu návrhových vzorov využívajúce dialógovú komunikáciu s „obrázkami“ vďaka systému GATE.
E-learning v takejto forme má slúžiť predovšetkým nevidiacim a slabozrakým
používateľom, ktorým má pomôcť dozvedieť sa podrobnejšie o účele a štruktúre
jednotlivých návrhových vzorov. Webový klient je pripravený v budúcnosti poslúžiť ako doplnok momentálne stále vyvíjajúceho sa projektu GATE. V texte
diplomovej práce je okrem iného popísaná prístupnosť počítačovej grafiky, funkcia i realizácia anotácií obrázkov so zameraním na UML modely návrhových
vzorov a implementácia výslednej webovej aplikácie.
kľúčové slová
návrhové vzory, e-learning, prístupnosť, nevidiaci, UML, diagram tried, grafika, dialóg, SVG, anotácia, ontológia, OWL, Protégé, GATE, webová aplikácia, klient, Java EE, JSP, Stripes, EJB
iv
abstract
The goal of this diploma thesis is to create a set of UML class diagrams describing design patterns by Gang of Four. These diagrams are presented in vector
graphics format SVG where are added semantic annotations with ontology
using language OWL. The set of diagrams is a part of the web application –
client that is implemented with Java technologies and calls services of GATE
system, which is developing at the Faculty of Informatics Masaryk University.
The application provides an interface for learning of design patterns that uses
communication with the „pictures“ via dialogs thanks to GATE system. This
form of e-learning helps especially for blind or visually impaired users to learn
more about purposes and structures of design patterns. The web client is ready to be used in the future as a supplement of the GATE project that is still
developing. Thesis text describes accessibility of computer graphics, function
and realization of annotations of mainly the UML models of design patterns
and implementation of the web application.
keywords
design patterns, e-learning, accessibility, blind, UML, class diagram, graphics,
dialog, SVG, annotation, ontology, OWL, Protégé, GATE, web application,
client, Java EE, JSP, Stripes, EJB
v
obsah
1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Prístupnosť informačných technológií . . . . . . .
2.1 Pravidlá prístupného webu . . . . . . . . . . . . .
2.2 Podpora nevidiacich používateľov . . . . . . . . .
3 Počítačová grafika založená na dialógu . . . . . .
3.1 Projekt GATE . . . . . . . . . . . . . . . . . . .
3.2 Vektorový formát SVG . . . . . . . . . . . . . . .
3.3 Ontológia a jazyk OWL . . . . . . . . . . . . . .
3.4 Anotovanie spojením ontológie s SVG . . . . . . .
3.5 Anotácia rastrového obrazu a fotografie . . . . . .
3.6 Využitie komunikatívnych obrázkov v e-learningu
4 Tvorba diagramov návrhových vzorov . . . . . . .
4.1 Návrhové vzory Gang of Four . . . . . . . . . . .
4.2 Tvorba grafiky UML diagramov . . . . . . . . . .
4.3 Anotácie návrhových vzorov . . . . . . . . . . . .
4.4 Komunikácia s obrázkami návrhových vzorov . . .
5 Webová aplikácia na výučbu návrhových vzorov
5.1 Návrh aplikácie . . . . . . . . . . . . . . . . . . .
5.2 Používateľská prístupnosť . . . . . . . . . . . . .
5.3 Technológie a implementácia . . . . . . . . . . . .
5.4 Lokalizácia aplikácie . . . . . . . . . . . . . . . .
6 Záver . . . . . . . . . . . . . . . . . . . . . . . . . . .
Literatúra . . . . . . . . . . . . . . . . . . . . . . . . . .
Zoznam obrázkov . . . . . . . . . . . . . . . . . . . . .
Zoznam zdrojových kódov . . . . . . . . . . . . . . . .
A UML diagramy návrhových vzorov . . . . . . . .
B Snímka z webovej aplikácie . . . . . . . . . . . . .
C Obsah priloženého média . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
3
4
8
11
12
13
15
18
21
22
24
24
27
29
32
34
34
36
39
45
48
50
55
56
57
61
62
vi
kapitola 1
úvod
S rozvojom informačných technológií sa v súčasnosti čoraz viac stretávame
s pojmom prístupnosť. V širšom zmysle pod prístupnosťou informačných technológií myslíme ich prispôsobenie tak, aby boli dostupné pokiaľ možno všetkým svojim používateľom. Technológiu alebo systém považujeme za prístupné,
ak majú svoje rozhranie prispôsobené takým spôsobom, že sú s ním schopní
pracovať aj ľudia s rôznymi formami zdravotného postihnutia. Nezanedbateľný
podiel zdravotne postihnutých ľudí predstavujú jedinci s poruchou zraku. Popri
poruche sluchového aparátu je slepota handicap, kedy je veľmi náročné postihnutému ponúknuť alternatívu, ktorá by nahradila chýbajúci vnem a poskytla
by mu tak pôvodnú funkcionalitu zariadenia alebo systému.
Nanešťastie pre nevidiacich používateľov, internet ako miesto obrovského
množstva informácií však dnes poskytuje aj veľké množstvo obsahu, ktorý má
výhradne vizuálny charakter. Na to, aby bola takýmto handicapovaným používateľom sprostredkovaná informácia primárne grafická, existujú mnohé metódy. Termín „prístupnosť počítačovej grafiky“ sa stal základným kameňom
aj pre projekt GATE – Graphics Accessible to Everyone [15], ktorý prebieha
na Fakulte informatiky Masarykovej univerzity v Brne. Táto diplomová práca
si kladie za cieľ vytvoriť webovú aplikáciu, ktorá v spolupráci so systémom
vyvíjaným v projekte GATE poskytne prostredie zjednodušujúce zrakovo postihnutým používateľom e-learningový proces. Grafické výučbové materiály reprezentujúce diagramy návrhových vzorov, ktoré sú prezentované v tejto práci,
sú doplnené sémantickými anotáciami, a tým vytvárajú obsah vhodný aj pre
nevidiacich študentov.
Písomná časť textu diplomovej práce sa skladá z niekoľkých častí. V prvej
z nich sa v krátkosti bližšie pozrieme na pojem prístupnosť v kontexte informačných technológií a počítačovej grafiky. Zameriame sa najmä na zrakovo
postihnutých ľudí a akým spôsobom im informačné technológie pomáhajú komunikovať s okolím a získavať informácie. Uvedieme si predovšetkým pravidlá
prístupného webu. Nasledujúca obsiahlejšia kapitola popisuje počítačovú gra1
1. Úvod
fiku založenú na dialógu a spomínaný projekt GATE. Predstavíme si hlavné
ciele tohto projektu a spôsoby, akými je možné nevidiacim používateľom sprostredkovať informácie nachádzajúce sa v grafickej podobe na obrázkoch či fotografiách. V tejto časti sa ďalej venujeme aj charakteristike vektorového formátu
SVG. Dôraz je kladený na jeho použitie k uchovávaniu sémantických informácií
o obrázku spojením s tzv. ontológiou a značkovacím jazykom OWL. Súčasťou
tejto kapitoly je objasnenie funkcie anotácií v obrázkoch, s ktorými je možné
viesť dialógovú komunikáciu, a ich vhodnosť na účely e-learningu.
Štvrtá kapitola poskytuje pohľad do problematiky návrhových vzorov, konkrétne pôvodných vzorov od skupiny autorov prezývaných Gang of Four [1].
Následne je v tejto časti práce popísaný proces tvorby UML diagramov tried
vybraných návrhových vzorov reprezentovaných grafickým súborom SVG. Súčasťou štvrtej kapitoly sú aj konkrétne príklady anotácií týchto návrhových
vzorov pomocou ontológie. Posledná nosná časť textu predstavuje popis implementácie webovej aplikácie, ktorá poskytne používateľom prostredie na výučbu
návrhových vzorov formou e-learningu. Vytvorený „klient“ vychádza z teoretických poznatkov, s ktorými sme sa zoznámili v úvodných častiach diplomovej práce. Kapitola okrem iného venuje pozornosť aj prehľadu technológií
použitých pri vývoji webovej aplikácie, napríklad frameworku Stripes alebo
knižniciam na prácu s JavaServer Pages. Na záver sa pokúsime zhrnúť, aké
ďalšie kroky sú vhodné k rozšíreniu vytvorených e-learningových materiálov
a webovej aplikácie.
Výsledkom práce je sada anotovaných UML diagramov tried niekoľkých návrhových vzorov. Na účely poskytnutia vhodného e-learningového prostredia
pre nevidiacich užívateľov bola vytvorená klientská aplikácia vo forme webových stránok. Aplikácia je realizovaná s použitím technológií Java Platform,
Enterprise Edition a volá služby systému GATE na strane servera. Tento systém je stále vo fáze vývoja, čo momentálne limituje aj použiteľnosť samotného klienta na reálnu výučbu v praxi. Napriek tomu je aplikácia pripravená
v budúcnosti vďaka využívaniu systému GATE poskytnúť pohodlné webové
rozhranie na komunikáciu s obrázkami zachytávajúcimi diagramy návrhových
vzorov.
2
„Sila webu spočíva v jeho
univerzálnosti. Aby bol
prístupný pre každého,
bez ohľadu na zdravotné
postihnutie, je jeho
základnou úlohou.“
kapitola 2
Tim Berners-Lee,
riaditeľ W3C [17]
prístupnosť
informačných technológií
Podľa odhadov Svetovej zdravotníckej organizácie (WHO) v súčasnosti trpí
zdravotným postihnutím okolo 15% celkovej ľudskej populácie na Zemi. Pričom asi pätinu z toho tvoria ľudia, ktorým ich handicap výrazným spôsobom
bráni v každodennom fungovaní. V sedemdesiatych rokoch 20. storočia počet
invalidov predstavoval len 10% populácie a WHO sa domnieva, že tento podiel
bude aj naďalej rásť. Hlavným faktorom zvyšujúceho sa počtu ľudí so zdravotným postihnutím je celkové starnutie populácie, pretože riziko invalidity
u starých ľudí je vyššie. Takisto na toto číslo nepriaznivo pôsobí aj celosvetovo čoraz vyšší výskyt chorôb ako je cukrovka a rôznych kardiovaskulárnych
ochorení či duševných porúch [14].
Myslieť si teda, že pri poskytovaní akejkoľvek verejne dostupnej služby
alebo výrobe produktu nie je nutné brať ohľad na zdravotne postihnutých
ľudí, by bolo naivné. Každá správna moderná budova slúžiaca širšej verejnosti
by dnes mala poskytovať bezbariérový vstup alebo nápisy v Braillovom písme.
Dokonca zvukovú signalizáciu zastávok v prostriedkoch mestskej hromadnej
dopravy určite ocenia nie len nevidiaci, ale častokrát aj bežní cestujúci. Tieto
uľahčenia pre handicapovaných jedincov, ktoré si súčasne kladú za cieľ poskytnúť rovnaké podmienky na vykonávanie daných činností všetkým ľuďom,
môžeme zahrnúť pod pojem prístupnosť.
Informačné a komunikačné technológie dnes nepochybne ovplyvňujú mnohé
stránky ľudského života a spôsob, akým sa ľudia učia, pracujú, komunikujú.
Súčasné technológie predstavujú veľký potenciál, ktorý sa dá využiť na pomoc znevýhodneným skupinám ľudí práve v oblasti sociálnej, ekonomickej i vo
vzdelávaní. Je žiaduce udržanie či zlepšenie kvality ich života a integrácie do
spoločnosti, ako aj nadobudnutie nezávislosti v profesionálnom i súkromnom
živote [16]. United Nations dokonca považuje prístup k informačným a komunikačným technológiám za základné ľudské právo [17]. Spôsobmi, akými
pomocou informačných technológií docieliť, aby zdravotne postihnutí dosaho3
2. Prístupnosť informačných technológií
vali rovnakej kvality činností každodenného života, sa zaoberá vo svete mnoho
inštitúcií.
2.1 Pravidlá prístupného webu
Jedna z iniciatív, ktorá sa snaží zaviesť a presadzovať pravidlá prístupnosti je
World Wide Web Consortium, skrátene konzorcium W3. Táto medzinárodná
organizácia spoločne s pomocou verejnosti vyvíja webové štandardy. Mimo
iného sa W3C už od roku 1997 pokúša zdokonaliť prístupnosť webu svojím
programom Web Accessibility Initiative. Misia WAI je viesť web k využitiu
svojho plného potenciálu na to, aby bol prístupný a umožnil aj handicapovaným ľuďom spolupodieľať sa rovnakou mierou na jeho podobe [17].
K dosiahnutiu týchto cieľov vydalo konzorcium v máji 1999 sadu odporúčaní, ktorá sa stala prvou celosvetovou uznávanou metodikou. Poslúžila ako
základ na vytvorenie celej rady ďalších metodík prístupnosti. Zahŕňala dnes
už dobre známe pravidlá ako napríklad použitie alternatív za zvukový a vizuálny obsah, nespoliehanie sa na farebné odlíšenie prvkov alebo poskytnutie
jednotného navigačného mechanizmu na stránke. Táto metodika je v dnešnej dobe už zastaraná a neodporúča sa ju používať [20]. O pár rokov neskôr
preto došlo k jej prepracovaniu a v súčasnosti sú platné štandardy Web Content Accessibility Guidelines (WCAG) 2.0, ktoré sa skladajú z 12 odporúčaní
kategorizovaných pod 4 základné princípy. Nasleduje skrátený voľný preklad
týchto pravidiel a ich výkladu nachádzajúceho sa na oficiálnej stránke W3
konzorcia [18, 19]. Miestami je doplnený tiež o vlastnú autorskú interpretáciu.
Tieto pravidlá boli zúžitkované aj v praktickej časti tejto diplomovej práce
a ich použitie je stručne ilustrované v kapitole 5.
Pravidlá prístupného webu podľa metodiky WCAG 2.0:
1. Vnímateľnosť
Informácie a súčasti používateľského rozhrania musia byť prezentované takým spôsobom, aby ich užívatelia boli schopní vnímať. To znamená, že
nesmú byť skryté pred niektorým zo zmyslov.
˓→ Textové alternatívy – poskytnite používateľovi náhradu v textovej
podobe za každý netextový prvok nachádzajúci sa na stránke tak,
aby ho bolo možné v prípade potreby previesť napríklad na zväčšené písmo, Braillovo písmo, hovorené slovo alebo zjednodušený jazyk
a podobne. Obzvlášť popísaný by mal byť ovládací prvok reagujúci
na vstup používateľa alebo dôležitý audiovizuálny obsah. Ďalej kód
4
2. Prístupnosť informačných technológií
CAPTCHA1 by mal obsahovať viacero alternatívnych výstupov využívajúcich rôzne zmysly, aby sme pokryli rôzne postihnutia. Vždy je
ale potrebné odlíšiť netextový obsah, ktorý plní iba dekoračnú či formátovaciu funkciu. Takýto vizuálny prvok by nemal byť užívateľovi
prezentovaný v textovej podobe a použitý tak, aby ho mohli asistenčné technológie, ktoré pomáhajú invalidom pracovať s počítačom,
ignorovať.
˓→ Časovo závislé multimediálne prvky – audio a video obsah, či už
prebieha naživo, alebo je prezentovaný vo forme vopred nakrúteného
záznamu, by mal podľa možností obsahovať vhodné alternatívy ako
titulky, prípadne byť interpretovaný posunkovou rečou.
˓→ Prispôsobiteľnosť – vytvorte taký obsah, ktorý je možné prezentovať viacerými spôsobmi bez straty informácie či narušenia štruktúry
dokumentu. Príkladom môže byť použitie zjednodušeného vzhľadu
stránky alebo vlastnej, používateľom definovanej, šablóny. Vzájomné
vzťahy medzi prvkami sú sémanticky zadané a vlastnosti týchto komponentov nezávisia výhradne na ich vzhľade. Poradie informácií či
navigácia je logická a intuitívna.
˓→ Rozlíšiteľnosť – uľahčite používateľom vidieť i počuť obsah a zároveň
rozoznať popredie od pozadia. Farba nemôže byť jediný prostriedok,
ktorý poskytne informácie o odlíšení vizuálneho prvku alebo vykonanej akcii. Text musí byť vzhľadom k svojmu pozadiu kontrastný
minimálne v pomere 4,5:1. Výnimka sa týka textu, ktorý je súčasťou
logotypu nejakej spoločnosti alebo produktu. Ďalej môže používateľ
zväčšiť text až na 200 % pôvodnej veľkosti bez straty obsahu či porušenia funkcionality. Pri prezentácii je uprednostňovaný textový formát
dát pred textom vo formáte obrázka. Opäť tvorí výnimku logotyp
a text, ktorý má iba dekoratívny charakter. Vhodné je držať sa tiež
všeobecných typografických zásad ako je menej než 80 znakov textu
v riadku, dostatočné odsadenie odsekov a podobne. Posledné obmedzenia v tejto časti sa týkajú zvuku. Ak sa na stránke automaticky
spustí prehrávanie audia, ktoré trvá dlhšie ako 3 sekundy, používateľ
by mal mať k dispozícii mechanizmus na jeho zastavenie alebo úp1. CAPTCHA je akronym z anglického jazyka pre „Completely Automated Public Turing
test to tell Computers and Humans Apart“ predstavujúci obvykle obrázok so zdeformovanou skupinou znakov tak, aby boli rozpoznateľné len človekom a nie OCR nástrojom na
optické spracovanie textu. Vyskytuje sa napríklad aj vo forme jednoduchých otázok v prirodzenom jazyku typu „Koľko je 5 + 3?“. Používa sa najčastejšie vo webovom prostredí, kde
potrebujeme rozlíšiť ľudského používateľa od počítačového robota.
5
2. Prístupnosť informačných technológií
ravu hlasitosti. Popri hovorenom slove sa v pozadí nesmie nachádzať
žiaden zvuk, prípadne je aspoň štyrikrát tichší ako hlasový prejav.
2. Ovládateľnosť
Súčasti používateľského rozhrania a navigačné prvky musia byť ovládateľné. Rozhranie nepožaduje vykonanie takej operácie, ktorú používateľ
vykonať nemôže.
˓→ Prístupnosť pomocou klávesnice – zaistite, aby všetky funkcie
obsahu bolo možné obsluhovať cez rozhranie klávesnice. Používateľ
by mal mať možnosť ovládať webovú stránku pomocou klávesových
skratiek.
˓→ Dostatok času – nechajte používateľovi dostatok času na prečítanie a prácu s obsahom. Je vhodné umožniť vypnutie alebo predĺženie
prípadného časového obmedzenia. Za výnimku môžeme považovať časový limit, ktorý je nutnou súčasťou udalosti prebiehajúcej v reálnom
čase. Pohybujúce sa a blikajúce objekty musia poskytnúť používateľovi možnosť tieto prvky zastaviť alebo skryť. Taktiež by používateľ
mal mať možnosť regulovať frekvenciu automaticky aktualizovaného
obsahu na stránke.
˓→ Vyvarovanie sa záchvatom – vynechajte v prezentácii obsah, ktorý
by mohol vyvolávať záchvaty, napríklad grafický prvok blikajúci viac
ako trikrát za sekundu.
˓→ Prehľadná navigácia – uľahčite používateľovi navigáciu, hľadanie
obsahu či určovanie aktuálnej pozície v hierarchii webových stránok.
Každá stránka by mala obsahovať titulok a mala by byť logicky štruktúrovaná, teda používať záhlavia jednotlivých častí, čiže hlavičky, nadpisy atď. Pri odkazoch by ich účel mal byť zrejmý zo samotného textového označenia odkazu.
3. Zrozumiteľnosť
Informácie a ovládanie používateľského rozhrania musia byť zrozumiteľné.
Obsah alebo ovládací prvok teda nemôžu prekračovať hranicu, ktorá by už
pre používateľa bola nezrozumiteľná.
˓→ Čitateľnosť – zaistite čitateľný a zrozumiteľný textový obsah. Jazyk
stránky by mal byť prispôsobený cieľovému používateľovi. To môže
zahŕňať výber vhodných jazykových termínov, definovanie skratiek
alebo mechanizmus určujúci špecifickú výslovnosť neobvyklých slov.
6
2. Prístupnosť informačných technológií
˓→ Predvídateľnosť – vzhľad a ovládanie stránok musí byť intuitívne.
Zmena kontextu stránky by nemala prebehnúť automaticky ako vedľajší efekt inej používateľom vykonanej zmeny. Ak áno, je na túto
zmenu vopred upozornený. Spôsob identifikácie prvkov na stránkach
je jednotný, rovnako je konzistentná aj ich navigácia.
˓→ Pomoc pri zadávaní – pomôžte používateľovi vyvarovať sa chýb,
prípadne ich opraviť. Automaticky zistená chyba pri zadávaní by mala
byť vyznačená a textovo popísaná používateľovi s následným návrhom
krokov vedúcich k jej opraveniu. Používateľovi by mala byť ďalej
k dispozícii kontextová nápoveda alebo tiež mechanizmus umožňujúci
skontrolovanie a potvrdenie zadávaných údajov.
4. Robustnosť
Obsah musí byť dostatočne robustný, aby mohol byť spoľahlivo interpretovaný širokou škálou tzv. používateľských agentov2 vrátane asistenčných
technológií. To znamená, že používateľ musí mať prístup k obsahu aj potom, ako sa ním použité zariadenie alebo technológia zmenia na novšie
a pokročilejšie.
˓→ Kompatibilita – snažte sa zabezpečiť maximálnu kompatibilitu so súčasnými i budúcimi webovými prehliadačmi a inými zobrazovacími
zariadeniami, ktoré sa môžu podieľať pri prezentácii daného obsahu.
Sem patrí okrem iného aj dodržovanie správnej syntaxe použitého
značkovacieho jazyka. Napríklad je vhodné vyvarovať sa kríženiu značiek alebo zdvojeným atribútom.
Existuje mnoho ďalších inštitúcií vydávajúcich odporúčania na tvorbu prístupného webu, ktoré sa snažia vychádzať z podobných princípov ako W3C.
V domácom prostredí môžeme sledovať napríklad súbor pravidiel slovenskej
iniciatívy Blind Friendly Web [23]. Obdobná česká metodika je Blind Friendly
Web 2.3 [21] alebo Pravidla tvorby přístupného webu [22], ktoré vznikli na účely
novely zákona o informačných systémoch verejnej správy v Českej republike.
Bohužiaľ, nemôžeme však očakávať, že pravidlá prístupnosti budú využívať
všetky dnešné webové stránky. Pútavý vzhľad a pohyblivá reklama, to je to,
čo nájdeme v súčasnosti na mnohých moderných internetových portáloch. Reklamné záujmy s cieľom upútať pozornosť, prípadne často až „otupiť“ zmysly
2. User agent (z angl.) je v širšom slova zmysle softvér, ktorý koná v mene používateľa,
napr. mailový klient. V užšom slova zmysle sa jedná o klienta určitého internetového protokolu. Pojmom user-agent označujeme aj reťazec v hlavičke HTTP, ktorý identifikuje verziu
a typ prehliadača, operačný systém a podobne.
7
2. Prístupnosť informačných technológií
používateľa majú prednosť pred prístupnosťou. David Špinar v knihe Tvoříme
přístupné webové stránky [9] dokonca uvádza, že prístupnosť webu vychádza
z jeho samotných základov a nejedná sa o žiadnu nadstavbu. Obviňuje tvorcov
www stránok, ktorí vykonávajú svoju prácu nesprávne, že jedine vďaka nim
dnes majú web a bezbariérovosť k sebe tak ďaleko. Tvrdí, že prístupný web
je taký, pri ktorom boli iba dodržané pôvodné pravidlá tvorby webových stránok a dodržovanie zásad prístupnosti je teda len „oprašovanie“ zásad správnej
tvorby stránok, na ktorých bol kedysi web postavený [9].
Tieto bezbariérové a reklamné prístupy sa však v zásade nevylučujú, a tak
vytvárať moderne vyzerajúce stránky, ktoré sú zároveň prístupné, by malo byť
v našom spoločnom záujme. Rovnako vývoj a hľadanie nových postupov treba
očakávať aj naďalej pri úpravách spomínaných pravidiel prístupnosti, aby sa
web stal miestom, kde je kvalitný obsah prezentovaný pútavým spôsobom každému používateľovi bez ohľadu na to či trpí nejakým zdravotným postihnutím,
alebo nie. V nasledujúcej časti textu sa ešte v krátkosti pozrime na handicap,
ktorý je pre prácu s počítačom a celkovo s informáciami veľmi špecifický, a to
je postihnutie zrakové.
2.2 Podpora nevidiacich používateľov
Hovorí sa, že zrakom vnímame až 80 % informácií z okolitého prostredia. Zrak
je jedným s najdôležitejších zmyslov človeka, a preto, ako sme si spomenuli
v úvode práce, jeho nahradenie v zmysle ponúknutia alternatív, aby bola dosiahnutá prístupnosť určitej technológie, je pomerne zložité.
Zrakové postihnutie
Zrakovú poruchu je možné definovať ako mechanické poškodenie zrakového
analyzátora, alebo poruchu v jeho funkciách. Ľudia so zrakovým postihnutím
predstavujú približne 1,5 % celkovej populácie. Môžeme ich členiť do 4 základných skupín, v rámci ktorých ešte existuje široká individuálna variabilita. Táto
základná diferenciácia však nemá slúžiť na oddeľovanie zrakovo postihnutých
ľudí od ostatných, ale na zefektívnenie a skvalitnenie procesu ich výchovy,
vzdelávania a integrácie do spoločnosti. Pre ďalšiu prácu so zrakovo postihnutými, najmä pre pedagogickú činnosť a aplikáciu kompenzačných pomôcok, je
nevyhnutné prihliadať aj na príčinu a dobu vzniku zrakovej poruchy. Rozlišujeme či sa zrakové poškodenie vyskytuje u postihnutého od narodenia, alebo sa
vyvinulo neskôr počas života. Najzaužívanejšie je ale delenie do spomínaných
4 základných skupín z hľadiska zrakovej ostrosti, tzv. vízusu [24, 25].
8
2. Prístupnosť informačných technológií
Nevidiacimi nazývame osoby s úplnou stratou zrakového vnímania, ale
tiež aj osoby schopné zrakom vnímať maximálne svetlo, avšak nedokážu lokalizovať jeho zdroj. Prakticky nevidiaci majú zachované zvyšky zraku tak, že
sú schopní vnímať svetlo, obrysy a tvary predmetov, ale ani s najlepšou možnou korekciou nedokážu využívať zrak ako dominantný a jediný analyzátor pri
práci, orientácii a získavaní informácií. Ďalšiu skupinu zrakového postihnutia
tvoria slabozrakí. Sú to jedinci, ktorí napriek najlepšej možnej korekcii majú
problémy s vykonávaním zrakovej práce. Takíto ľudia majú vážne poškodený
zrak, ale disponujú jeho užitočnými zvyškami, ktoré sa dajú efektívne využiť.
Osoby s porušeným binokulárnym videním majú problém so spoluprácou medzi svojím pravým a ľavým okom. Jednoducho trpia poruchou videnia
oboma očami, čo spôsobuje problémy v priestorovom videní [24]. Do osobitnej skupiny patria ešte farboslepí, ktorí majú problém vnímať určitý rozsah
farebného spektra. Vo väčšine prípadov sa nejedná o úplnú farbosleposť, kedy
postihnutý vidí len v odtieňoch sivej, ale o nedostatok čapíkov citlivých na
určitú farbu, najčastejšie zelenú alebo červenú.
Nevidiaci a práca s počítačom
Zrakovo postihnutí používatelia používajú na príjem informácií z okolitého
sveta takzvané audio-taktilné techniky. Ako vyplýva z názvu, ide o techniky,
pri ktorých nevidiaci používa svoje ostatné zmysly, teda sluch a hmat. Už od
raného detstva sú zvuky, hudba a reč pre nevidiaceho veľmi dôležité, pretože
mu napomáhajú v pojmotvorbe. Práve vďaka dennému cviku je možné predpokladať, že schopnosť počúvať a sústrediť sa na počuté je viac vyvinutá. Na
druhej strane hmatom zas postihnutý získava informácie o štruktúre, teplote,
veľkosti či tvare. Za pomoci rúk môže porovnávať rozdielne, podobné a totožné
črty predmetov okolitého prostredia [26].
Je veľmi dôležité ponúknuť zrakovo postihnutým nástroje na prácu, ktoré
využijú práve ich sluchové a hmatové orgány. Existuje množstvo asistenčných
technológií a rôznych kompenzačných pomôcok umožňujúcich nevidiacim pracovať s počítačom. Najčastejšie využívaným nástrojom je čítač obrazovky. Ide
o program, ktorý pomocou hlasového syntetizátoru dokáže používateľovi interpretovať všetko, čo je práve viditeľné na obrazovke. Syntetický hlas nevidiacemu prečíta okrem čistého textu aj obsah dialógových okien, príkazy v ponuke
či práve stláčané klávesy. Tento hlasový výstup je schopný dokonca rozpoznať
aj sémantické vyjadrenie textu pomocou jazyka HTML. To znamená, že vie
napríklad oddeliť nadpisy rôznych úrovní od obsahu odseku, identifikovať hy9
2. Prístupnosť informačných technológií
pertextové odkazy či interpretovať alternatívny text definovaný pri grafických
prvkoch umiestnených na stránke.
Hmatový výstup môže mať podobu Braillovho riadku. Tento hmatový displej je hardvérové zariadenie umožňujúce zobraziť jeden riadok textovej informácie, ktorá je zobrazená na obrazovke, v Braillovom bodovom písme. Zariadenie
je využívané najmä ťažko postihnutými osobami, ktoré okrem zrakovej poruchy trpia aj stratou sluchu. Naopak slabozrakí jedinci, ktorí nie sú postihnutí
úplnou slepotou, majú k dispozícií rôzne formy zväčšovacieho softvéru. Program pracujúci rovnako ako lupa umožňuje až niekoľkonásobne zväčšiť zvolenú
časť obrazovky. Podobným nástrojom je dnes vybavená aj väčšina moderných
grafických operačných systémov [26]. Pri zníženej citlivosti na svetlo alebo
farbosleposti pomáhajú postihnutým zasa doplnkové programy zvyšujúce kontrast a podobne.
Získavanie informácií je základnou potrebou každého z nás. Na začiatku
podkapitoly si uvádzame, že pomocou zraku je človek schopný vnímať až 4/5
informácií. Bez asistenčných technológií by nevidiaci teda dosahovali úroveň
príjmu informácii iba okolo 20 %, čo už pramení s mentálnou retardáciou.
Tieto technológie však tvoria iba nevyhnutný základ, ktorý potrebujú používatelia so špecifickými nárokmi v dôsledku ich zdravotného postihnutia. Ale aj
najlepší nástroj umožňujúci handicapovaným pracovať s počítačom bude nanič, ak pri vývoji softvéru alebo tvorbe webových stránok nebudeme myslieť
na prístupnosť. Pre zrakovo postihnutých je samozrejme najnáročnejšie prijať
akúkoľvek informáciu vizuálneho charakteru. V nasledujúcich kapitolách práce
si ale predstavíme metódy, akými je možné sprístupniť počítačovú grafiku,
a tým docieliť aj efektívnejší samovzdelávací proces pre zrakovo postihnutých
ľudí.
10
kapitola 3
počítačová grafika
založená na dialógu
V predchádzajúcej kapitole sme si rozobrali, prečo je dôležité zrakovo postihnutým používateľom sprístupniť informácie grafického charakteru. Dnes sú
však v princípe väčšinou informácie, ktoré vieme z obrázka zistiť, limitované na
jeho rozmery, farebnú hĺbku a podobne. V prípade fotografie môžu byť údaje
doplnené o dátum a čas zosnímania či GPS súradnice fotografovaného miesta.
Je zrejmé, že pre používateľa podstatné a zaujímavé informácie nie je možné
jednoduchým spôsobom z obrázka získať. Môžu to byť informácie o ľuďoch,
budovách, prostredí a iných objektoch nachádzajúcich sa na fotografii.
Jednoduchým riešením by bolo automatické rozpoznávanie obrazu a detekcia takýchto objektov. Nanešťastie táto oblasť informatiky je ešte len „v plienkach“ a nejakú dobu potrvá, kým budeme schopní vykonať plnoautomatickú
analýzu ľubovoľného obrázku a dostať tak jeho úplný slovný popis. Keď sa
tak stane, obrázok bude pozostávať nie len z grafickej informácie, ale aj z obrovského množstva relevantných informácií, ktoré ho budú popisovať. Preto
je dôležité poskytnúť používateľovi možnosť „komunikovať“ s takýmto obrázkom, a tým mu postupne interpretovať všetko, čo ho bude zaujímať [8].
Kým však nie sme schopní úplne programovo rozpoznávať objekty, je žiaduce dopĺňať informácie do obrázku či fotografie manuálne. A to môžu vykonávať buď vidiace osoby, alebo aj nevidiaci s približnou znalosťou obsahu
fotografie, ktorým pomôže práve asistencia pomocou dialógu. Takto je možné
efektívne zhromažďovať informácie a ukladať ich postupne do obrázku pomocou ontológie. Bližšie si však o ontológií povieme v podkapitole 3.3. Vektorový
grafický formát SVG, sa vďaka svojej prispôsobivosti javí ako veľmi vhodný na
zaznamenávanie štruktúrovaných a objektovo orientovaných údajov. Možnosť
uchovávať v SVG grafike popri vektorových grafických primitívach aj textové
reťazce či rastrový obraz z neho robí spôsobilý formát použiteľný práve na reprezentáciu komunikatívnych obrázkov [5, 6]. O tom ale viac až v nasledujúcich
podkapitolách. Predstavme si teraz projekt GATE, ktorý sa snaží zdokonaľovať
11
3. Počítačová grafika založená na dialógu
uvedený princíp dialógovo založenej komunikácie s obrázkom a implementovať
ho do praxe.
3.1 Projekt GATE
Projekt GATE (Graphics Accessible to Everyone) je výskumný projekt prebiehajúci na Fakulte informatiky Masarykovej univerzity v Brne. Je riešený
v rámci Laboratória vyhľadávania a dialógu (LSD – Laobratory of Searching
and Dialogue) a vedie ho doc. RNDr. Ivan Kopeček, CSc. Jeho tím vyvíja
systém GATE, ktorý si kladie tri nasledovné ciele:
1. vyvinúť nástroje na jednoduchú tvorbu anotácií obrázkov,
2. poskytnúť nevidiacim používateľom podporu v „prezeraní“ obrázkov,
3. vyvinúť systém generujúci grafické výstupy v istej obmedzenej podobe,
ktoré majú možnosť vytvoriť nevidiaci za pomoci dialógu [15].
V tejto diplomovej práci budeme bližšie pracovať iba s prvými dvoma
cieľmi. Generovaním zjednodušenej grafiky pomocou systému GATE sa zaoberá napríklad článok Creating Pictures by Dialogue [4]. Autori tu uvádzajú,
že takto vytvorené obrázky môžu zrakovo postihnutí potom použiť vo svojich
vlastných webových prezentáciách, publikáciách či ilustrovaných narodeninových e-mailoch. Samotní nevidiaci používatelia pritom určite nájdu mnohé
ďalšie využitia. Výhodou týchto obrázkov je tiež to, že vzhľadom k ich vzniku
sú už plne sémanticky popísané. Ďalšou prácou v tejto oblasti by malo byť zdokonaľovanie samotnej dialógovej komunikácie a implementácia systému, ktorý
by generoval obrázky len s použitím základných grafických primitív. Výzvou
do budúcnosti je integrácia modulu, ktorý by sa staral o dodržiavanie určitých estetických princípov alebo vylepšenie nástroja, ktorý bude používateľov
o vytvorenom obrázku informovať. S týmto úzko súvisí i druhý cieľ celého projektu GATE. Autori si v článku sľubujú, že systém môže byť pre nevidiacich
použiteľný a zaujímavý, pričom sa opierajú o spoluprácu so Strediskom Teiresiás Masarykovej univerzity slúžiacim na pomoc študentom so špecifickými
nárokmi, kde bol nástroj testovaný počas roku 2005 [4]. V súčasnosti je už
tento nástroj funkčnou súčasťou systému GATE [15].
Základná architektúra systému GATE
Stručne si predstavme moduly, z ktorých sa skladá systém GATE. Prvým
z nich je ANNOTATOR, ktorý má na starosti navigáciu na obrázku. Jeho
12
3. Počítačová grafika založená na dialógu
hlavnou úlohou je vďaka spolupráci s grafickou ontológiou informovať používateľa o vizuálnom obsahu obrázka. To je možné vykonať dvoma spôsobmi –
slovne a pomocou zvukových efektov, čo označujeme za takzvanú sonifikáciu.
Jeden z nástrojov podporujúcich túto komunikáciu je RNG (Recursive Navigation Grid), ktorý rozdeľuje obrázok na 9 obdĺžnikových oblastí. Rozloženie
je analogické s rozložením čísel na numerickej klávesnici. Každá z oblastí sa
potom rekurzívne ďalej delí na 9 menších atď. Používateľ má možnosť takto
lokalizovať každý bod na obrázku alebo oblasť s danou presnosťou zodpovedajúcou úrovni rekurzívneho zanorenia v mriežke [5].
Druhý nástroj, pomocou ktorého môže používateľ komunikovať s obrázkom,
je WWL (What-Where Language). Jedná sa o jazyk, ktorý je zjednodušený
fragment anglického, prípadne aj iného jazyka. Každá veta má tvar „What
is where“ alebo „Where is what“, teda „Čo je kde“ a „Kde je čo“ [5]. Toto
dovoľuje používateľovi klásť systému jednoduché otázky vzťahujúce sa k polohe
objektu na scéne, napr. „Kde je kostol?“, „Čo je v pozadí?“, „Čo je napravo
od rieky?“. V rovnakom jazyku systém odpovedá, napr. „Kostol je v zadnej
časti ulice.“, „V pozadí sú stromy.“, „Napravo od rieky je ulica.“. Takto by
mohli vyzerať otázky a odpovede pri prehliadaní obrázku 3.2.
Verbálnu časť dialógu zahŕňajúcu aj WWL komunikáciu má na starosti
VIM (Verbal Information Module). Tento modul rieši a opravuje mnoho možných nezrovnalostí, ktoré môžu vzniknúť počas komunikácie. Systém podporuje dve komunikačné stratégie reprezentované dvoma nezávislými modulmi,
ktoré však navzájom spolupracujú a používateľ má tiež možnosť si medzi nimi
ľubovoľne prepínať. GUIDE poskytuje slovné informácie o obrázku, získané
z jeho anotácií alebo parametrov uložených priamo v grafickom formáte. Na
druhej strane modul EXPLORER neslúži ku komunikácii verbálnej, ale analógovej, teda pomocou myši, numerickej klávesnice alebo zvukov. Tento druh
neverbálnej komunikácie prichádza na rad vtedy, keď potrebujeme rýchlo a dynamicky preskúmať časť obrázku, ktorá nie je anotovaná. Zvukové signály
vznikajú kombináciou troch tónov, ktorých frekvencie reprezentujú intenzitu
daného kanálu vo farebnom modeli RGB. Nevidiaci používateľ sa môže týmto
spôsobom efektívne dozvedieť, akú farbu má práve preskúmavaný obrazový
bod [6].
3.2 Vektorový formát SVG
SVG (Scalable Vector Graphics) je formát založený na značkovacom jazyku
XML (eXtensible Markup Language) a slúži na popis dvojrozmernej grafiky.
Ide o štandard vyvíjaný konzorciom W32.1 . Jeho základom je práca s vektoro13
3. Počítačová grafika založená na dialógu
vou grafikou, ale podporuje aj ostatné typy grafických objektov ako je rastrový
obraz a text. Tieto objekty môžu byť zoskupované a ďalej rôzne transformované
pomocou dostupných funkcií [27]. SVG okrem základných grafických a priestorových transformácií podporuje aj širokú škálu pokročilej funkcionality v podobe maskovania objektov pomocou alfa kanálu alebo využívania konvolučných filtrov. Formát neposkytuje len prácu so statickou grafikou, ale umožňuje
aj tvorbu animácií či dokonca interaktívnych prvkov. Pomocou SVG môžeme
vybudovať interaktívny mapový portál, jednoduché hry, grafické editory integrované do HTML stránok a podobne [28].
Softvérová podpora formátu SVG je v súčasnosti síce na slušnej úrovni,
napriek tomu sa nájdu webové prehliadače, ktoré majú so zobrazením dokumentu SVG problém. Nedostatočnú podporu má napríklad Internet Explorer 8.0 a jeho staršie verzie. Slabá podpora je taktiež v prehliadačoch operačného systému Android. Donedávna našli uplatnenie aj zásuvné moduly do prehliadačov, ktoré sa špecializovali na zobrazovanie SVG dát, napr. Adobe SVG
Viewer. Pri používaní tohto formátu vektorovej grafiky vo webovom prostredí
musíme preto dbať na kompatibilitu s čo najväčším počtom zariadení, operačných systémov a jednotlivých prehladačov. Kameňom úrazu sa môže stať
používanie pokročilých prvkov jazyka. Väčšina mobilných prehliadačov má
problémy s podporou animácií alebo SVG filtrov ako je rozmazanie či vrhanie
tieňa. Mozilla Firefox zasa neumožňuje používať pomerne rozšírenú funkciu
písma vloženého priamo v SVG [29]. O rôznych spôsoboch umiestnenia SVG
elementu na HTML stránku, aby bola zabezpečená dostatočná kompatibilita,
si povieme viac v časti 5.2.
Skriptovanie a grafika SVG
Výhodou grafického formátu SVG je to, že sa vlastne jedná o dáta uložené
v XML dokumente. Preto môžeme napríklad skontrolovať validitu každého
dokumentu ešte pred samotným spracovaním. Vďaka XML je možné využívať
DOM (Document Object Model), teda programovo pridávať, odoberať či inak
meniť jednotlivé uzly stromu, z ktorého sa dokument skladá, a tým ovplyvniť
výslednú podobu kresby. Taktiež je možné reagovať na rôzne udalosti, ktoré
vzniknú pri práci s dokumentom, napr. kliknutie na grafický prvok. K práci
s DOM typicky slúžia skriptovacie jazyky, predovšetkým JavaScript, ktorý je
dostupný skoro z každého webového prehliadača. Takisto existuje aj programové rozhranie pre jazyky ako Java. Pri SVG sa v podstate jedná o analógiu
skriptovania HTML alebo CSS, takže prechod medzi týmito technológiami je
pomerne jednoduchý [28].
14
3. Počítačová grafika založená na dialógu
Ako sme si už uviedli, formát SVG je primárne určený na prácu s vektorovou grafikou. Tá tvorí alternatívu ku grafike rastrovej, ktorá je reprezentovaná
diskrétne a skladá sa z jednotlivých obrazových bodov (pixelov) usporiadaných v pomyselnej ortogonálnej mriežke. Vektorová grafika definuje svoj obraz
pomocou základných geometrický primitív ako úsečky, krivky, mnohouholníky
či elipsy. V dôsledku toho má obraz spojitý charakter, a tak nedochádza k jeho
deformácii pri zmene veľkosti. Takýto obraz je vhodné použiť všade tam, kde
nie je veľmi zložité popísať ho týmto spôsobom a podobná deformácia je neželaná, napr. pri tvorbe logoypu. Naopak reprezentovať fotografiu pomocou vektorov je prakticky nemožné. SVG však dokáže zobrazovať aj elementy priamo
obsahujúce rastrový obraz, a to v podobe PNG alebo JPEG formátu.
Podrobnejší rozbor jednotlivých grafických prvkov a celkovo tvorby vektorovej grafiky vo formáte SVG by nepochybne presahoval rámec tejto diplomovej práce. Štruktúre súboru a popisu vybraných SVG elementov sa venujem
v sekcii 3.4 a ďalej aj v texte práce týkajúcom sa praktickej časti, konkrétne
v podkapitolách 4.2 a 4.3.
3.3 Ontológia a jazyk OWL
V širšom slova zmysle označuje ontológia filozofickú disciplínu, ktorá sa zaoberá bytím a súcnom. V informatike tento pojem plní trochu odlišnú funkciu,
no vychádza zo spoločných základov. Podľa Thomasa Grubera je ontológia
formálne, explicitné vyjadrenie konceptualizácie [30]. Konceptualizácia je systém pojmov modelujúcich nejakú časť sveta. Zjednodušene si možno ontológiu
predstaviť ako množinu konceptov (entít, objektov), ich vlastností a vzťahov
medzi nimi, ktoré modelujú určitú doménu. Formálnosť ontológie sa prejavuje
jej jednoduchou algoritmickou spracovateľnosťou. To, že je explicitná zasa vyjadruje fakt, že čo v ontológii nie je uvedené, to neplatí.
Projekt GATE sa zaoberá predovšetkým grafickou ontológiou, ktorá popisuje vizuálne vlastnosti objektov. Sú to všetky vlastnosti zúčastňujúce sa
na sémantickom popise grafickej informácie, napríklad topológia, geometria,
osvetlenie alebo farby [7]. V tejto diplomovej práci pracujeme hlavne s ontológiami z oblasti UML1 a návrhových vzorov. Návrhové vzory budú podrobnejšie
rozoberané v kapitole 4.
1. Unified Modeling Language je modelovací jazyk používaný v softvérovom inžinierstve. Jeho najčastejšie využitie nájdeme pri analýze a návrhu objektovo orientovaných systémov. Základom je predovšetkým grafická reprezentácia modelov. Medzi najpoužívanejšie
modely patrí diagram tried, prípadov použitia, sekvenčný diagram či diagram aktivít.
15
3. Počítačová grafika založená na dialógu
Web Ontology Language
Z definície ontológie vyplýva, že je možné ju reprezentovať formálnymi jazykmi.
Konzorcium W32.1 má na starosti vývoj jazyka používaného na tvorbu ontológií, ktorý sa nazýva OWL (Web Ontology Language). Využitie nachádza tento
jazyk všade tam, kde obsah a informácie majú byť spracovávané aplikáciami
a nie len prezentované ľuďom. OWL je vysoko interpretovateľný vďaka tomu, že
podobne ako SVG vychádza z rozšíreného značkovacieho jazyka formátu XML.
Jazyk OWL je ďalej založený na skupine špecifikácií RDF (Resource Description Framework) a RDFS (RDF Schema) rovnako od W3C. Všeobecný rámec
RDF vznikol na popis zdrojov a výmenu dát najmä v prostredí webu, a tým ho
má posúvať k tzv. sémantickému webu, ktorého základom je dobre definovaný
význam informácií a ich ľahká strojová spracovateľnosť. Rozšírenie v podobe
RDFS poskytuje konštrukcie na vytváranie vlastných slovníkov slúžiacich na
popis zdrojov v rôznych doménach [31, 32].
Pri vytváraní ontológie je často potrebné vyjadriť spôsoby, akými ju možno
ešte presnejšie opísať. Sem patrí napríklad obmedzenie kardinality, určenie
identických objektov a podobne. Je to práve jazyk OWL, ktorý obsahuje prostriedky na reprezentáciu takýchto konštrukcií. Koncom roku 2009 obohatilo
W3C tento jazyk ešte o ďalšie prvky a vznikol OWL 2, pričom kompatibilita
s pôvodnou verziou zostala zachovaná. Špecifikácia jazyka OWL definuje jeho
tri varianty so vzrastajúcou úrovňou expresivity. Sú to OWL Lite, OWL DL
a OWL Full.
Podjazyk OWL Lite sa vyznačuje možnosťou tvorby len jednoduchých hierarchií alebo obmedzením kardinality iba na hodnoty 0 či 1. OWL DL je
syntaktickým rozšírením OWL Lite a má maximálnu schopnosť expresivity
pri zachovaní výpočtovej úplnosti a rozhodnuteľnosti, teda že všetky logické
odôvodnenia budú spočítané v konečnom čase. Názov pochádza z takzvanej
„deskriptívnej logiky“, ktorá skúma podmnožinu čiastočne rozhodnuteľných
predikátov logiky prvého rádu a stala sa základom formálneho zápisu reprezentácie znalostí, čiže aj ontológií. Trochu odlišnú sémantiku poskytuje variant OWL Full. Zaručuje najvyššiu mieru kompatibility s RDFS, napr. tým,
že trieda môže byť kolekciou indivíduí a súčasne indivíduom samotným. Za
indivíduum považujeme konkrétny objekt použitý v ontológii. V podjazyku
OWL Full však už nie je zaručená výpočtová úplnosť a rozhodnuteľnosť [31].
Základy jazyka OWL
Na ukážke zdrojového kódu 3.1 si demonštrujme základnú syntax OWL a princíp tvorby ontológie v tomto jazyku. Pre zjednodušenie ukážka neobsahuje po16
3. Počítačová grafika založená na dialógu
vinné prvky ako hlavičku OWL súboru alebo definovanie menných priestorov
XML. Takisto sa ontológia nemusí nachádzať v jednom súbore kompletná, ale
môže sa odkazovať na iný externý OWL súbor pomocou <owl:imports/>3.2 .
V zásade sa však ontológia skladá z troch častí, a tými sú triedy, vlastnosti
a inštancie (indivíduá). Fragment zdrojového kódu začína definovaním triedy
Student, ktorá je potomkom triedy Person. Podobne nasleduje definícia ďalšej
triedy Teacher.
< owl:Class rdf:ID = " Student " >
< rdfs:subClassOf rdf:resource = " # Person " / >
</ owl:Class >
< owl:Class rdf:ID = " Teacher " >
< rdfs:subClassOf rdf:resource = " # Person " / >
</ owl:Class >
< o w l : D a t a t y p e P r o p e r t y rdf:ID = " age " >
< rdfs:range
rdf:resource = " http: // www . w3 . org /2001/ XMLSchema # integer " / >
< rdfs:domain rdf:resource = " # Person " / >
</ o w l : D a t a t y p e P r o p e r t y >
< o wl :O bj ec tP ro pe rt y rdf:ID = " isTeaching " >
< rdfs:range rdf:resource = " # Student " / >
< rdfs:domain rdf:resource = " # Teacher " / >
</ o wl :O bj ec tP ro pe rt y >
< o wl :O bj ec tP ro pe rt y rdf:ID = " isTaught " >
< owl:inverseOf rdf:resource = " # isTeaching " / >
</ o wl :O bj ec tP ro pe rt y >
< Student rdf:ID = " Adam " / >
< Teacher rdf:ID = " Kowalski " / >
Kód 3.1: Príklad ontológie v jazyku OWL.
Vlastnosti rozoznávame dvojakého typu – dátové a objektové. Každá vlastnosť má špecifikovanú doménu a rozsah, pričom spája inštanciu z domény
s inštanciou z rozsahu. Dátové vlastnosti spájajú inštancie tried s dátovým
typom schémy XML, prípadne RDF literálom. Na ukážke je príklad jednoduchej dátovej vlastnosti, ktorá slúži na priradenie veku danej osobe. Vidíme,
že ako doména je určená trieda Person a ako rozsah zas dátový typ integer
z XML schémy, čo predstavuje celé číslo. Objektové vlastnosti sú binárne relácie medzi inštanciami dvoch tried. Vlastnosť isTeaching vyjadruje, že učiteľ
vyučuje študenta. Ďalej sa môžu vlastnosti špeciálne vyznačovať tým, že sú
17
3. Počítačová grafika založená na dialógu
k inej vlastnosti napríklad inverzné, tranzitívne, symetrické a podobne. To
je aj prípad vlastnosti isTaught, pri ktorej je explicitne uvedená jej inverzia
k isTeaching. Tým sme automaticky zaručili, že vlastnosť „je vyučovaný“,
inak povedané „má učiteľa“, za svoju doménu považuje študenta a priradený
objekt je z rozsahu inštancií učiteľa. Posledné dva riadky príkladu zdrojového
kódu ilustrujú vytvorenie samotných inštancií. Vznikajú nám teda inštancia
študenta identifikovateľná ako Adam a inštancia učiteľa Kowalského.
3.4 Anotovanie spojením ontológie s SVG
Pod pojmom anotácia si môžeme predstaviť krátku slovnú charakteristiku
alebo poznámku, ktorá má predovšetkým vysvetľujúcu funkciu. V spojitosti
s informačnými technológiami sa anotácie najčastejšie vyskytujú napríklad
v podobe komentárov zrojového kódu programu či textových popisov slúžiacich ako alternatíva k obrazovým a zvukovým dátam vo webovom prostredí.
Táto diplomová práca sa zaoberá práve efektívnou anotáciou obrazovej informácie.
Existuje niekoľko spôsobov, ktorými je možné anotovať obrázok. Prvým
z nich je použitie voľného textu, kedy je obrázok alebo fotografia popísaná
vlastnými slovami bez ďalšieho obmedzenia. Tento typ anotácie je však ťažko
strojovo spracovateľný a vyžaduje zložitú analýzu prirodzeného jazyka. Ďalším
problémom môže byť veľká rozmanitosť slovného popisu pri formuláciách s rovnakým významom. Na druhej strane je anotácia využívajúca kľúčové slová.
Nevýhodou je však strata pôvodného významu informácie tým, že je prevedená iba na výčet jednotlivých slov a slovných spojení. Obmedzenie anotácie
len na použitie kľúčových slov tiež mnohokrát spôsobuje aj nejednoznačnosť
takejto anotácie.
Kompromisom spájajúcim výhody oboch popísaných prístupov k tvorbe
anotácií je využitie štruktúrovaných dát. Vďaka dobre štruktúrovaným, logicky a formálne usporiadaným údajom máme možnosť zabezpečiť podobnú
vyjadrovaciu silu akú poskytuje prirodzený jazyk a zároveň obmedziť množinu
používaných výrazov tak, aby bol popis jednoznačný. Takéto dáta by mali
byť tvorené entitami, ich vlastnosťami a vzťahmi medzi nimi. Z uvedeného
princípu vychádza práve anotácia pomocou ontológie popísanej v predchádzajúcej podkapitole. Podľa autorov systému GATE použitím grafickej ontológie
v procese anotácie predídeme problémom spojeným s multijazyčnosťou anotácií alebo chaotickou a nejednoznačnou terminológiou. Ontológia nám takisto
ponúka možnosť udržať aj pri anotácií rôznych grafických objektov sémantiku
stále konzistentnú [5, 6].
18
3. Počítačová grafika založená na dialógu
Za najvhodnejšiu technológiu, ktorá by účinne uchovávala obrazové dáta
spolu s anotáciami, sa javí spojenie OWL a SVG ako štandardov založených
na XML. Týmto je možné prepojiť grafiku spolu s požadovanou sémantikou
a všetko spoločne uchovávať v prispôsobiteľnom formáte SVG. Telo dokumentu
obsahuje hierarchicky organizovaný grafický obsah. Vytváranie štruktúry sa vykonáva najčastejšie zoskupovaním objektov pomocou značky <g>. Prítomnosť
tohto elementu nemá vizuálny vplyv na samotný SVG obrázok.
Obr. 3.1: Porovnanie grafickej a logickej hierarchie objektov. Autorská
ilustrácia vytvorená podľa obrázku v článku [6].
Vo všeobecnosti však potrebujeme pri tvorbe grafiky dodržať určité špecifické usporiadanie grafických prvkov. Obzvlášť to platí aj pre animáciu, kedy
musí výtvarník napríklad sledovať štruktúru jednotlivých častí ľudského tela,
aby mohol potom animovať prirodzene vyzerajúci pohyb človeka. Táto hierarchická štruktúra vyskytujúca sa vo vektorových editoroch alebo programoch
na modelovanie 3D grafiky sa nazýva scene graph. Pri statických obrázkoch
je často nutné usporiadať objekty takým spôsobom, aby sme predišli ich vzájomnému sa prekrývaniu. Súčasná špecifikácia SVG 1.1 bohužiaľ nedisponuje
atribútom z-index, ktorý by umožňoval udávať poradie grafických objektov.
Jedinou možnosťou ako uvedené neprekrývanie sa docieliť, je dodržať poradie elementov v dokumente. Preto objekt, ktorý je v popredí, musí nasledovať
v SVG súbore až po objekte nachádzajúcom sa v pozadí.
Hierarchia entít definovaná v grafickej ontológií ma takisto vlastnú štruktúru, ktorá nie vždy korešponduje s usporiadaním prvkov na obrázku, a do19
3. Počítačová grafika založená na dialógu
konca môže byť aj výrazne odlišná [6]. Na obrázku 3.1 vidíme príklad, ako sa
môže líšiť strom usporiadania grafických prvkov, čiže spomínaný „graf scény“,
od štruktúry určenej sémantickými kategóriami. Túto nezhodu pri anotácií
SVG obrázku riešime priradením unikátneho id každému grafickému elementu.
Údaje obsahujúce samotné anotácie sa nachádzajú mimo hlavného tela dokumentu, a to na začiatku alebo na konci súboru s použitím XML značky
<metadata>. Hlavným cieľom tejto časti SVG dokumentu je jednoznačne prepojiť grafické uzly s danými indivíduami ontológie [6]. Nasledujúca ukážka
zdrojového kódu 3.2 demonštruje, ako by uvedené prepojenie vyzeralo v SVG
dokumente obrázka 3.1.
< metadata id = " G A T E _ A N N O T A T I O N _ M E T A D A T A " >
< rdf:RDF >
< owl:Ontology rdf:about = " " >
< owl:imports
rdf:resource = " http: // ontologies . com / HumanBody . owl " / >
</ owl:Ontology >
< Head rdf:ID = " head " / >
.. neck classification ..
< Hair rdf:ID = " hair " >
< color rdf:resource = " # darkbrown " / >
< length rdf:resource = " # medium " / >
</ Hair rdf:ID = " hair " >
< Accessories rdf:ID = " hair - tie " >
< color rdf:resource = " # darkblue " / >
</ Accessories rdf:ID = " hair - tie " >
.. classification of eyes , nose , etc ..
</ rdf:RDF >
</ metadata >
<g id = " G A T E _ G R A P H I C A L _ C O N T E N T " >
.. neck definition ..
<g id = " head " transform = " translate (150 ,75) " >
.. definition of ears , face , etc ..
<g id = " hair " transform = " translate (0 , -75) " >
.. ponytail definition ..
<g id = " hair - tie " transform = " translate (120 ,40) " >
< path style = " fill:black " .. tie outline geometry .. / >
< path style = " fill:darkblue " .. tie fill geometry .. / >
</ g >
.. the top of head main hair definition ..
</ g >
</ g >
</ g >
Kód 3.2: Zdrojový kód anotovaného SVG obrázka 3.1. Autorský kód
vytvorený na základe článkov [6, 8].
20
3. Počítačová grafika založená na dialógu
3.5 Anotácia rastrového obrazu a fotografie
Ako sme si spomínali v podkapitole 3.2, SVG formát je schopný uchovávať
aj rastrové obrázky. Takýto obraz, napríklad fotografia, je uložený väčšinou
vo formáte JPEG, teda je reprezentovaný ako jednoliaty neštruktúrovaný objekt. Myšlienka skrytá za anotáciou rastrového obrazu pozostáva z vyznačenia
oblastí záujmu, ktoré sú následne anotované. Tieto oblasti sú označené pomocou geometrických primitív a ako neviditeľné objekty, teda majúce plne
transparentnú výplň a žiadne obrysy, sú uložené v SVG súbore spolu s rastrom. Priehľadné oblasti sú organizované do hierarchie typickej pre vektorovú
grafiku a zvrchu prekrývajú hlavnú fotografiu. Označovanie záujmových oblastí
je pomerne zložité na to, aby mohlo prebiehať úplne automaticky. Je vhodné
umožniť používateľovi pohodlné zostrojenie týchto tvarov v programe, ktorý
slúži na anotáciu obrázkov [6].
Obrázok 3.2 znázorňuje príklad, akým spôsobom je možné manuálne označkovať rastrový obrázok. Jednotlivé oblasti sú na účely ilustrácie explicitne
vyznačené hrubými bielymi obrysmi, no vo výslednom SVG súbore sa však
neobjavujú. Fotografia zachytáva malú dedinku Zaton zo zátoky v Šibenickokninskej župe na území Chorvátska. Napriek pomerne veľkému množstvu objektov reálneho sveta nachádzajúcich sa na obrázku, sme schopní pomocou
anotácií a s využitím grafickej ontológie nevidiacemu používateľovi priblížiť
letnú prímorskú scenériu, ktorá je na fotografii zachytená. To je možné vďaka
interakcii, ktorá prebieha medzi používateľom a systémom GATE formou dialógovej komunikácie v zjednodušenom jazyku WWL3.1 . Príklad podobného
dialógu si budeme uvádzať v časti 4.4.
Ako môžeme vidieť na obrázku 3.2, jedným z dôležitých prvkov, ktoré
uľahčia nevidiacemu orientáciu na fotografii je označenie hĺbkových oblastí.
Písmenom X označíme popredie, ako Y je označená centrálna časť a pozadie
fotografie označuje písmeno Z. Sémanticky na obrázku rozoznávame niekoľko
objektov. Písmeno A označuje cestu, B chodník a písmenom C sme označili
kaviareň po pravej strane cesty. Ďalej D označuje vodu v zátoke, písmeno E
zasa oblasť, ktorá zachytáva budovy a stromy v zadnej časti fotografovanej
ulice. F označuje les v pozadí a nakoniec G oblohu. Ak chceme ísť v sémantike
o úroveň ďalej, vyznačené oblasti je možné rozbiť do ďalších podúrovní. Na
chodníku B1 zvlášť vyznačíme pouličné lampy B2 a B3. Oblasť kaviarne sa
rozdelila na posedenie pred kaviarňou C2 a samotnú budovu C1. Zo zadných
budov ulice E1 venujeme zvláštnu pozornosť bližšej stavbe napravo E3 a kostolu E2. Oblasť stromov v pozadí označená ako F1 vyčlenila budovu F2 na
vrchole kopca.
21
3. Počítačová grafika založená na dialógu
Obr. 3.2: Pôvodná fotografia (vľavo hore), označenie podľa prvej sémantickej
úrovne (vpravo hore), druhej úrovne (vľavo dole) a označenie na základe
hĺbky (vpravo dole). Autorská ilustrácia vytvorená podľa obrázkov
v článkoch [5, 6].
3.6 Využitie komunikatívnych obrázkov v e-learningu
Anotácie využívajúce ontológiu sú vďaka jej orientácií na znalosti a súvislosti
medzi entitami z určitej domény vhodné na pedagogické účely, predovšetkým elearning. Špecializovaná ontológia môže obsahovať veľké množstvo informácií,
ktoré však nie sú prítomné na obrázku priamo. Sem môžeme zahrnúť napríklad
detailné popisy zobrazených objektov vo viacerých jazykoch či spojitosť týchto
objektov s inými relevantnými pojmami v rámci ontológie [7].
Predstavme si napríklad obrázok obsahujúci chemický vzorec zložitej organickej zlúčeniny. Ak by sme chceli len s použitím grafickej ontológie preskúmať
čo sa nachádza na takomto obrázku, asi by nás neuspokojila odpoveď, že vľavo
je šesťuholník s každou druhou obrysovou hranou zdvojenou. Skôr by nás zaujímalo, že v ľavej časti vzorca sa nachádza benzénové jadro. Následne by sme
sa mohli pýtať, s čím sa toto jadro spája, koľko hydroxylových skupín vzorec
obsahuje a podobne. Rovnako sa od takéhoto anotovaného obrázka vďaka dia22
3. Počítačová grafika založená na dialógu
lógu s ním môžeme dozvedieť niečo viac o samotnom benzénovom jadre, či už
kompletnú definíciu, alebo na tvorbe akých ďalších významných zlúčenín sa
zúčastňuje. V tom by nám jednoducho pomohla ontológia z doménovej oblasti
organickej chémie, ktorá by bola použitá v anotácii.
Podobným spôsobom si môžeme predstaviť aj e-learningové študijné materiály zo softvérového inžinierstva. Kopeček a Ošlejšek v Communicative Images [8] uvádzajú príklad UML diagramu prípadov použitia. V tomto prípade
nám tiež nepomôžu popisy, že na obrázku sú elipsovité útvary s textami
„pridanie záznamu“ či „zmazanie záznamu“. Potrebujeme sa dozvedieť, že
účastník administrátor má možnosť pridávať a mazať záznamy z databázy.
Ku grafickej ontológií charakterizujúcej iba vizuálne vlastnosti objektov je
nutné teda pridať podporu ontológie zo špecifickej domény. Tým sa nevidiaci
používateľ dozvie to, čo na obrázku vidieť nemôže. Túto informáciu ale dostane v správnej terminológii a súvislostiach, ktoré presahujú grafickú stránku
obrázku.
V prvej kapitole práce sme si spomínali, že aj napriek tomu, že zvuková
signalizácia zastávok v prostriedkoch mestskej hromadnej dopravy je určená
predovšetkým pre zrakovo postihnutých ľudí, výrazným spôsobom uľahčuje
život i bežným cestujúcim. Takisto aj použitie komunikatívnych obrázkov môže
v procese samovzdelávania pomôcť pochopiť informáciu, ktorá je znázornená
iba graficky, každému študentovi. V nasledujúcich častiach práce sa zameriame
práve na komunikatívne obrázky modelov UML, ktoré popisujú problematiku
návrhových vzorov používaných pri vývoji softvéru.
23
„Venované Gang of Four,
ktorých pohľad na návrhové
vzory a poznatky o nich
zmenili tvár návrhu softvéru
navždy a uľahčili tak život
vývojárom po celom svete.“
kapitola 4
venovanie autorov
Head First Design Patterns [3]
tvorba diagramov
návrhových vzorov
Navrhovanie objektovo orientovaného programového vybavenia je náročné. No
návrh objektovo orientovaného softvéru tak, aby bol znovupoužiteľný, je však
ešte náročnejší. Takýmito slovami aspoň začínajú svoju knihu Erich Gamma
a kolektív. Je nutné nájsť vhodné objekty, faktorizovať ich do tried, definovať rozhrania, určiť hierarchie dedičností a kľúčové príbuzenské vzťahy medzi
nimi. Návrh musí byť dostatočne špecifický pre náš problém, ale zároveň dosť
všeobecný na to, aby sa dal využiť pri ďalších projektoch v budúcnosti. Skúsení návrhári dajú za pravdu, že vytvoriť tvárny návrh tak, aby bol opätovne
použiteľný, nie je možné hneď na prvýkrát, ale obvykle je treba ho niekoľkokrát
použiť a zdokonaliť. Väčšinou je pri vývoji softvéru lepšie chytiť sa riešenia,
ktoré už v minulosti fungovalo, ako riešiť každý problém vždy od začiatku [1].
Podľa definície Rinkeho Hoekstra je návrhový vzor archetypické riešenie návrhového problému daného určitým kontextom [10]. Zjednodušene povedané,
v mnohých objektovo orientovaných systémoch nájdeme znovu sa opakujúce
vzory tried a komunikujúcich objektov. Návrhový vzor (design pattern) je potom niečo, čo všeobecne popisuje a rieši špecifické návrhové problémy, ktoré
sa opakovane objavujú pri vývoji týchto systémov.
4.1 Návrhové vzory Gang of Four
Za jedno z najprelomovejších diel týkajúcich sa návrhových vzorov objektovo orientovaných programov považujeme knihu Design Patterns: Elements
of Reusable Object-Oriented Software [1] z roku 1995 od spomínaných autorov Gammu, Helma, Johnsona a Vlissidesa. Autori sú známi pod prezývkou
Gang of Four, skrátene GoF. Položili tu základné kamene návrhových vzorov
tak, ako ich poznáme a chápeme v súčasnosti. V tejto ucelenej publikácii nájdeme predovšetkým katalóg 23 návrhových vzorov. Sú rozdelené do 3 kategórií
24
4. Tvorba diagramov návrhových vzorov
podľa toho či sa zaoberajú tvorbou objektov, ich štruktúrou alebo správaním.
Aj napriek tomu, že vzory vznikali v období, kedy ešte neexistovali súčasné
moderné objektovo orientované programovacie jazyky, ani notácia UML na
nákresy diagramov, dielo je i dnes stále aktuálne. To len umocňuje fakt, že
vzory sú vytvorené naozaj veľmi všeobecne a je možné ich prispôsobiť rôznym
jazykom i vyvíjaným programovým systémom.
Každý návrhový vzor v uvedenej publikácií sa skladá zo štyroch základných prvkov. Prvým je názov vzoru, ktorý jedným alebo dvomi slovami jednoznačne popisuje riešený návrhový problém a dnes je už zaradený v terminológii návrhu softvéru. Druhý prvok je identifikácia samotného problému, kedy
je vhodné vzor použiť, aj s jeho kontextom. Ďalej je to riešenie popisujúce už
prvky, z ktorých sa skladá návrh. Charakterizované sú vzájomné vzťahy, povinnosti a spolupráca týchto prvkov. Riešenie ale určite nepopisuje konkrétnu
implementáciu, pretože vzor je ako šablóna, ktorú je možné použiť v rôznych
situáciách. Vzor obsahuje skôr abstraktný popis návrhového problému a spôsob, akým ho vzájomné usporiadanie objektov vyrieši. Súčasťou riešenia je tiež
uvedenie štruktúry vzoru, teda grafické vyjadrenie jednotlivých tried a vzťahov
medzi nimi. Posledným prvkom sú dôsledky, ktoré pramenia z použitia vzoru.
Dôsledky nám pomôžu pochopiť náklady a výhody, prípadne i nevýhody, ktoré
prinesie použitie daného návrhu [1]. Zachytiť všetky tieto dodatočné informácie o vzoroch je hlavnou úlohou ontológie3.3 návrhových vzorov použitej v našej
diplomovej práci. Práve toto sú údaje, ktoré nie je možné získať len jednoduchým pohľadom na UML diagram, ale používateľ sa ich dozvie až komunikáciou
s obrázkom v procese elektronického samoštúdia.
Názvy návrhových vzorov, ktoré vytvoril Erich Gamma a jeho tím, sa do
našich jazykov prekladajú len zriedka a častejšie sa používajú pôvodné výrazy v angličtine. Na niektorých miestach v nasledujúcej časti textu a taktiež
predovšetkým aj v lokalizovanej webovej aplikácii, ktorá tvorí praktický výstup tejto diplomovej práce, budú použité slovenské a české ekvivalenty týchto
výrazov. V tlačených publikáciách či na internete sa môžeme stretnúť s rôznymi prekladmi a interpretáciami návrhových vzorov. Napríklad skupinu vzorov creational patterns môžu v češtine reprezentovať výrazy ako „vytvářející“,
„tvořivé“ alebo vo voľnom preklade aj „vzory týkající se tvorby objektů“. Pre
jednotnosť však budeme používať výrazy korešpondujúce s pomenovaniami,
ktoré sú uvedené v publikácii Návrh programů pomocí vzorů [2], čo je český
preklad pôvodného diela autorov Gang of Four.
Zhrňme si teraz základné informácie o návrhových vzoroch. Podrobný popis
jednotlivých vzorov nie je pre nás v tejto chvíli podstatný a určite by presahoval
rámec tejto diplomovej práce. Vymenujme si však všetky vzory v abecednom
25
4. Tvorba diagramov návrhových vzorov
poradí aj s roztriedením do kategórií, kam sú zaradené. Špeciálnu pozornosť
venujme a pár slovami si popíšme základný účel len niekoľkých prvých návrhových vzorov. Tieto vybrané vzory a ich štruktúra sú aj materiálom praktickej
časti diplomovej práce. Pri charakteristike vychádzame do veľkej miery z originálneho textu publikácie o návrhových vzoroch [1, 2].
Návrhové vzory GoF:
1. Tvorivé vzory (Creational Patterns)
Skupina návrhových vzorov zabstraktňujúca proces tvorby inštancií a pomáhajúca budovať systém, ktorý je nezávislý na spôsobe tvorby, skladania
a vyjadrovania jeho objektov. Tieto vzory sú dôležité najmä v systémoch
závislých na objektovej skladbe viac, než na triednej dedičnosti.
˓→ Abstraktná továreň (Abstract Factory) – poskytuje rozhranie na
vytváranie celej skupiny príbuzných či závislých objektov bez toho,
aby sa museli špecifikovať ich konkrétne triedy. Klient je izolovaný od
volania týchto tried.
˓→ Staviteľ (Builder) – oddeľuje zostrojenie komplexného objektu od
jeho reprezentácie. Rovnaký konštrukčný proces potom môže vytvárať
rôzne vyjadrenia tohto objektu.
˓→ Továrenská metóda (Factory Method), ˓→ Prototyp (Prototype),
˓→ Jedináčik (Singleton)
2. Štrukturálne vzory (Structural Patterns)
Ide o návrhové vzory, ktoré sa zaoberajú skladaním tried a objektov, čím
vytvárajú rozsiahlejšie štruktúry. Triedne štrukturálne vzory používajú ku
skladaniu rozhraní a implementácií dedičnosť, kým vzory objektového typu
na realizáciu novej funkcionality popisujú skôr spôsob skladby objektov.
˓→ Adaptér (Adapter) – prevádza rozhranie jednej triedy na iné rozhranie očakávané klientom. Adaptér teda umožňuje spoluprácu tried,
ktorá by inak nebola možná z dôvodu nekompatibilných rozhraní.
Existujú dva typy adaptéru. Triedny (Class Adapter) používa viacnásobnú dedičnosť. Objektový (Object Adapter) sa zasa spolieha na
objektovú skladbu.
˓→ Most (Bridge) – oddeľuje abstrakciu, čiže rozhranie triedy, od jej
implementácie, aby ich bolo možné meniť nezávisle na sebe.
26
4. Tvorba diagramov návrhových vzorov
˓→ Skladba (Composite) – skladá objekty do stromových štruktúr na vyjadrenie hierarchií typu celok – časť. Klientom umožňuje jednotne zaobchádzať so samostatnými objektmi (listami stromu) i celými skladbami objektov (vnútornými uzlami).
˓→ Dekorátor (Decorator) – pripája k objektu ďalšie povinnosti dynamicky. Pri rozširovaní funkcionality poskytuje flexibilnú alternatívu
k tvorbe podtried.
˓→ Fasáda (Facade), ˓→ Mušia váha (Flyweight), ˓→ Zástupca (Proxy)
3. Vzory chovania (Behavioral Patterns)
Návrhové vzory zaoberajúce sa chovaním tried a objektov sa používajú
k rozdeľovaniu povinností medzi jednotlivé objekty. Tieto vzory použijeme,
ak sa chceme zamerať na spôsob vzájomného prepojenia objektov a komunikáciu medzi nimi.
˓→ Reťaz zodpovednosti (Chain of Responsibility) – sa vyhýba spojeniu odosielateľa a príjemcu žiadosti tým, že umožní túto žiadosť
spracovať viac než jednému objektu. Príjemcov zreťazí a posúva žiadosť prostredníctvom reťaze, až kým ju nejaký objekt nespracuje.
˓→ Príkaz (Command) – zapúzdri žiadosti do objektu, a tým umožní
parametrizovať klientov pomocou rôznych žiadostí, napríklad žiadosť
o zaradenie do fronty alebo žiadosť o zápis na štandardný výstup.
Vďaka tomu podporuje aj operácie s funkciou „Späť“.
˓→ Interpret (Interpreter), ˓→ Iterátor (Iterator), ˓→ Sprostredkovateľ (Mediator), ˓→ Obnovovateľ (Memento), ˓→ Pozorovateľ (Observer), ˓→ Stav (State), ˓→ Stratégia (Strategy), ˓→ Šablónová
metóda (Template Method), ˓→ Návštevník (Visitor)
4.2 Tvorba grafiky UML diagramov
Prvou časťou praktického výstupu tejto diplomovej práce bolo vytvorenie UML
diagramov tried zachytávajúcich vybrané návrhové vzory. Diagramy sú na neskoršie účely anotácie prezentované vo vektorovej grafike v súboroch formátu
SVG. Táto podkapitola sa snaží priblížiť proces tvorby uvedených obrázkov.
Je dôležité si spomenúť, že na tvorbu vektorovej grafiky existuje veľké množstvo grafických editorov ako Adobe Illustrator, CorelDRAW či Inkscape. Tieto
nástroje samozrejme umožňujú aj export do štandardu SVG. Keďže sme ale
potrebovali úplnú kontrolu nie len nad vzhľadom, ale hlavne nad vnútornou
27
4. Tvorba diagramov návrhových vzorov
štruktúrou súboru a všetkými použitými SVG elementmi, uprednostnili sme
radšej variantu manuálneho zhotovenia týchto obrázkov. Akým spôsobom je
možné si ručnú tvorbu zjednodušiť, aby nebola priveľmi pracná, si ukážeme
o chvíľu. Najprv však pár slov k samotným grafickým objektom.
Základom diagramu tried je niekoľko notácií, ktoré môžeme vidieť v podobe vektorových objektov na obrázku 4.1. Vľavo je to trieda, označovaná ako
class, ktorá môže obsahovať atribút. Mínus pred atribútom triedy dodržuje
konvencie a signalizuje jeho privátnosť. Trieda obsahuje aj metódu, ktorá je
naopak označená znamienkom plus ako verejná. Nasleduje abstraktná trieda
alebo tiež rozhranie, čo v našom prípade momentálne nie je podstatné. Na
rozdiel od triedy konkrétnej, ktorá je vyznačená modrou farbou, abstraktná
trieda sa odtieňom blíži skôr k farbe zelenej. V oboch prípadoch sa jedná
o SVG element <rectangle> s určenou šírkou a výškou. Výplň obdĺžnika
tvorí gradient príslušnej farby. Tento farebný prechod reprezentovaný značkou
<linearGradient> je definovaný zvlášť pre hlavičku a vo svetlejšom prevedení
zvlášť pre telo triedy. Jedine farebné rozlíšenie typu triedy nestačí, napríklad
aj kvôli farboslepým používateľom (viď podkapitolu 2.1 a 2.2), preto je text
v abstraktnej triede písaný kurzívou, takisto podľa konvencií UML.
Obr. 4.1: Vektorové tvary UML notácie diagramu tried.
Na obrázku ďalej vidíme, akým spôsobom je znázornený v diagrame komentár. V ňom sa najčastejšie nachádza text popisujúci ako vyzerá telo metódy danej triedy. Vpravo sa nachádzajú šípky predstavujúce jednotlivé vzťahy
medzi triedami. Vrchná šípka reprezentuje špecializáciu, teda dedičnosť od rodičovskej triedy. Môže znamenať rozšírenie abstraktnej triedy alebo implementáciu rozhrania. V strede vidíme asociáciu typu agregácia, ktorá spája triedy
vo vzťahu celok – časť. Niekedy je nad agregáciou uvedený text, ktorý popisuje daný vzťah. Ak je plná čiara bez piktogramu kosoštvorca, predstavuje
všeobecnú väzbu vyjadrujúcu závislosť so stereotypom «call» resp. «use». Posledná šípka s prerušovanou čiarou zas vyjadruje závislosť so stereotypom «instantiate» resp. «create». Pomocou tejto sady grafických objektov sme schopní
popísať kompletnú štruktúru návrhových vzorov GoF.
Aby sme predišli príliš pracnej tvorbe grafiky, kedy sa ručne píše zdrojový kód SVG dokumentu, snažili sme sa využiť opakovaný výskyt grafických
objektov. Pri každom ďalšom použití objektu sme upravili len jeho základný
28
4. Tvorba diagramov návrhových vzorov
tvar jednoduchou transformáciou posunu translate(x,y) a prípadnou úpravou rozmerov. Takisto zakončenia šípok sa neudávali zakaždým s inou hodnotou pixelov, ale príslušná polyline bola len transformovaná napríklad pomocou rotate(-90), čím zmenila smer o 90∘ proti smeru hodinových ručičiek.
„Plátno“, na ktoré sme vykresľovali vektorové tvary malo pri všetkých vzoroch
rovnakú veľkosť 800 x 500 bodov. K rýchlejšej orientácií pri umiestňovaní objektov sme si pomohli umiestnením pomocnej mriežky s hustotou 25 pixelov do
pozadia. Najväčšou slabinou v tejto fáze bolo písmo. Pokusy o vloženie vlastného SVG fontu do dokumentu zlyhali kvôli nedostatočnej podpore webových
prehliadačov. Tento problém popisujem v časti 3.2. Nakoniec bolo nevyhnutné
zvoliť typ písma, ktorý by sa zobrazoval podobne pokiaľ možno na všetkých
platformách a operačných systémoch, aby nedochádzalo k pretekaniu textu
z vyznačených oblastí. Túto vlastnosť najlepšie spĺňalo tradičné bezserifové
písmo z rodiny Arial.
Pozorný čitateľ by si mohol položiť otázku, prečo sme nepoužili nejaké
existujúce diagramy návrhových vzorov v rastrovej podobe. Jednak sme chceli
vytvoriť sadu autorských UML diagramov, ale hlavne išlo o zachytenie ich objektovej hierarchie vo vektorovom formáte. Síce bol v predchádzajúcej kapitole
popísaný aj spôsob, akým je možné anotovať rastrový obraz, naším cieľom je
však poskytnúť pre projekt GATE čiste vektorové obrázky s jednoznačným
priradením konkrétneho sémantického objektu z ontológie ku grafickému.
4.3 Anotácie návrhových vzorov
V tejto časti si rozšírime naše SVG obrázky o anotácie. Budeme vychádzať
z poznatkov uvádzaných v podkapitolách 3.3 a 3.4, kde sme rozoberali spojenie grafického obsahu a ontológie do jedného súboru. Cieľom práce je anotovať
diagramy návrhových vzorov s použitím ontológie DesignPatterns.owl1 opisujúcej vybrané návrhové vzory. Pri vytváraní diagramov sme doplnili uvedený
OWL súbor, ktorý nám bol poskytnutý z projektu GATE, ešte o návrhový
vzor Dekorátor. Je v ňom nutné mimo iného deklarovať triedy ontológie, ktoré
predstavujú jednotlivé triedy zúčastňujúce sa na výstavbe daného návrhového
vzoru. Ďalej je potrebné popísať úlohu týchto tried vzoru či vlastnosti návrhového vzoru samotného, napríklad základný účel, dôsledky jeho použitia
alebo spoluprácu s inými vzormi. Na popis diagramu tried je nevyhnutná aj
ďalšia OWL ontológia, nachádzajúca sa v súbore UML.owl2 . Tu môžeme vidieť
základné entity používajúce sa pri návrhu objektovo orientovaných systémov,
1. Dostupné na: <http://lsd.fi.muni.cz/gate/ontologies/DesignPatterns.owl>.
2. Dostupné na: <http://lsd.fi.muni.cz/gate/ontologies/UML.owl>.
29
4. Tvorba diagramov návrhových vzorov
ako sú trieda, atribút, metóda, komentár a iné. Alebo tiež vlastnosti týchto
entít, napr. „je podtriedou“, „dedí od“, „má parameter“ a podobne.
Pri práci s ontológiami sme používali nástroj Protégé. Jedná sa o voľne
dostupný editor ontológií s otvoreným zdrojovým kódom. Okrem zápisu ontologických dát v podobe rámcov (frames), umožňuje takzvaný Protégé-OWL
manipulovať aj s ontológiou v jazyku OWL. Na domovskej stránke projektu je
k dispozícii stiahnuteľná verzia desktopového klienta a takisto aj webové rozhranie tohto programu. Protégé je vyvíjaný v jazyku Java, ľahko rozšíriteľný
a poskytuje aj vlastné aplikačné programové rozhranie [33].
Výhodou nástroja Protégé je pohodlné prezeranie a úprava ontologických
dát. Program nám ale neposlúžil na úpravu ontológie priamo, to je možné vykonať jednoduchým spôsobom aj ručne v dokumente OWL. Plnil skôr funkciu
zobrazovania sémantických dát a overovania správnosti výslednej ontológie.
Pri anotácií vektorových obrázkov však v editore Protégé nebolo možné otvoriť priamo celý SVG dokument aj s grafickým obsahom. Súbor musel prejsť
jednoduchou transformáciou na dokument OWL, pričom bol z neho odstránený všetok obsah špecifický pre SVG, teda zostala prítomná len anotácia
ohraničená elementom <rdf:RDF>3.2 .
Poďme si teraz už rozobrať samotný proces anotovania UML diagramu
tried konkrétneho návrhového vzoru. K tomu nám pomôže zdrojový kód 4.1,
čo je skrátená ukážka SVG obrázku zobrazujúceho vzor Reťaz zodpovednosti.
Kvôli rozsahu a jednoduchosti sa náš príklad skladá len z niekoľko málo indivíduí a objektov. V značke najvyššej úrovne <svg> sú prítomné atribúty, vďaka
ktorým sa bude dokument vložený do HTML stránky zobrazovať korektne
aj po zmene mierky. Nasledujú dve hlavné časti súboru, ktoré vyžaduje pri
spracovaní systém GATE. Sú to sémantická anotácia vo forme metadát uzavretých do značky <metadata id=”GATE_ANNOTATION_METADATA”> a grafická
časť v elemente <g id=”GATE_GRAPHICAL_CONTENT”>. Pre rýchlu orientáciu
v zdrojovom kóde SVG dokumentu sme ich vyznačili červenou farbou.
Nasleduje definícia menných priestorov, kde sú okrem rdf, rdfs a owl
prítomné aj XML schéma i naše vlastné OWL ontológie. Ďalej vidíme anotáciu k celému grafickému obsahu zahŕňajúcu komentár v českom aj anglickom jazyku. Prvé indivíduum pochádzajúce z ontológie návrhových vzorov už
predstavuje konkrétnu triedu zúčastnenú pri návrhu vzoru Reťaz zodpovednosti, a to triedu Handler. Pokračuje výpis vlastností danej triedy, teda že je
abstraktná, tvorí rodičov triedam ConcreteHandler1 a ConcreteHandler2,
má sama so sebou vzťah závislosti so stereotypom «call», obsahuje atribút
successor a metódu handleRequest. Anotačná časť je v ukážke kódu zakončená entitou z ontológie UML, ktorá reprezentuje uvedený atribút „následník“.
30
4. Tvorba diagramov návrhových vzorov
< svg xmlns = " http: // www . w3 . org /2000/ svg " x = " 0 " y = " 0 " width = " 800 " height = " 500 "
p r e s e r v e A s p e c t R a t i o = " xMinYMin meet " viewBox = " 0 0 800 500 " >
< metadata id = "GATE_ANNOTATION_METADATA" >
< rdf:RDF xmlns:rdf = " http: // www . w3 . org /1999/02/22 - rdf-synt ax-ns # "
xmlns:rdfs = " http: // www . w3 . org /2000/01/ rdf-schema # "
xmlns:owl = " http: // www . w3 . org /2002/07/ owl # "
xmlns:xsd = " http: // www . w3 . org /2001/ XMLSchema # "
xmlns:uml = " http: // lsd . fi . muni . cz / gate / ontologies / UML . owl # "
xmlns:dp = " http: // lsd . fi . muni . cz / gate / ontologies / DesignP atterns . owl # " >
< o w l : N a m e d I n d i v i d u a l rdf:about = "GATE_GRAPHICAL_CONTENT" >
< rdfs:comment xml:lang = " cs " >
UML diagram tříd návrhového vzoru Řetěz odpovědnosti . </ rdfs:comment >
< rdfs:comment xml:lang = " en " >
Chain of Resp onsibili ty Design Pattern UML Class Diagram . </ rdfs:comment >
</ o w l : N a m e d I n d i v i d u a l >
< o w l : N a m e d I n d i v i d u a l rdf:about = "handlerClass" >
< rdf:type rdf:resource = " http: // lsd . fi . muni . cz / gate / ontologies /
Desig nPattern s . owl # HandlerClass " / >
< d p : i s P a r t i c i p a n t O f rdf:resource = " http: // lsd . fi . muni . cz / gate / ontologies /
DesignPattern . owl # c h a i n O f R e s p o n s i b i l i t y " / >
< u m l : c l a s s i f i e r N a m e rdf:datatype = " xsd:string " > Handler </ u m l : c l a s s i f i e r N a m e >
< u m l : i s A b s t r a c t C l a s s rdf:datatype = " xsd:boolean " > true </ u m l : i s A b s t r a c t C l a s s >
< uml:isParrent rdf:resource = " c o n c r e t e H a n d l e r 1 C l a s s " / >
< uml:isParrent rdf:resource = " c o n c r e t e H a n d l e r 2 C l a s s " / >
< dp:calls rdf:resource = " handlerClass " / >
< u m l : h a s A t t r i b u t e rdf:resource = " s u c c e s s o r A t t r i b u t e " / >
< u m l : h a s O p e r a t i o n rdf:resource = " a b s t r a c t H a n d l e R e q u e s t M e t h o d " / >
</ o w l : N a m e d I n d i v i d u a l >
< o w l : N a m e d I n d i v i d u a l rdf:about = "successorAttribute" >
< rdf:type rdf:resource = " http: // lsd . fi . muni . cz / gate / ontologies /
UML . owl # Attribute " / >
< u m l : a t t r i b u t e N a m e rdf:datatype = " xsd:string " > successor </ u m l : a t t r i b u t e N a m e >
</ o w l : N a m e d I n d i v i d u a l >
</ rdf:RDF >
</ metadata >
<g id = "GATE_GRAPHICAL_CONTENT" >
<g id = "chainOfResponsibilityPattern" transform = " translate (137 ,137 ) " >
<g id = "handlerClass" transform = " translate (250 ,0 ) " >
< rect style = " fill:url (# g r a d A b s t r a c t H e a d ) ; stro ke-width :2 ; stroke:black "
x = " 0 " y = " 0 " width = " 150 " height = " 25 " / >
< rect style = " fill:url (# g r a d A b s t r a c t B o d y ) ; stro ke-width :2 ; stroke:black "
x = " 0 " y = " 25 " width = " 150 " height = " 25 " / >
< rect style = " fill:url (# g r a d A b s t r a c t B o d y ) ; stro ke-width :2 ; stroke:black "
x = " 0 " y = " 50 " width = " 150 " height = " 25 " / >
< text font-family = " Arial " font-size = " 14 " font-weight = " bold "
font-style = " italic " >
< tspan x = " 75 " y = " 17 " text-anchor = " middle " > Handler </ tspan >
< tspan x = " 5 " y = " 42 " text-anchor = " start " >- successor </ tspan >
< tspan x = " 5 " y = " 67 " text-anchor = " start " >+ handleRequest () </ tspan >
</ text >
</ g >
<g id = "handlerToHandlerAssociation" transform = " translate (400 ,37 ) " >
< polyline style = " fill:none ; str oke-widt h:2 ; stroke:black "
points = " 0 ,0 100 ,0 100 ,-75 -37,-75 -37,-37 " / >
< polyline transform = " translate ( -37,-37 ) rotate (180) "
points = " -5,10 0 ,0 5 ,10 " / >
< text font-family = " Arial " font-size = " 14 " font-weight = " bold " >
< tspan x = " 50 " y = " -7 " text-anchor = " middle " > successor </ tspan >
</ text >
</ g >
</ g >
</ g >
</ svg >
Kód 4.1: Ukážka SVG dokumentu Reťaze zodpovednosti.
31
4. Tvorba diagramov návrhových vzorov
Druhá časť zdrojového kódu 4.1 zjednodušeným spôsobom znázorňuje zápis grafických objektov. Pre prehľadnosť sú opäť vyznačené červenou farbou.
Hneď ako prvý element môžeme vidieť zoskupenie celého návrhového vzoru.
Táto skupina obsahuje celkovo dve grafické komponenty vzoru. Prvou z nich
je trieda Handler. Jedná sa o obdĺžnikové tvary, zvlášť pre hlavičku a telo
triedy, vyplnené príslušným farebným gradientom. Vnútro objektu obsahuje
text popisujúci názov triedy, jej atribút a metódu. Všimnime si všade prítomné
transformácie posunutia, pri ktorých prepisovaním hodnôt meníme relatívnu
pozíciu vzhľadom k nadradenému elementu. Tým, že neudávame pozíciu zakaždým absolútne, si podstatne urýchľujeme znovupoužitie tvarov pri ich ďalšom
výskyte. Posledný vizuálny prvok je šípka vyjadrujúca cyklickú závislosť triedy
Handler a je tvorená lomenou čiarou.
Výsledný obrázok kompletného diagramu návrhového vzoru Reťaz zodpovednosti môžeme aj spolu s ostatnými vzormi nájsť v prílohe A diplomovej
práce. Ešte raz ale upriamme svoju pozornosť na handlerClass, kde id grafického elementu je totožné s identifikátorom rovnakého indivídua zo sémantickej
časti, čo je pri prepojení anotácií s grafickými objektmi veľmi dôležité. Práve
vďaka tomu bude možné napríklad preskúmavať obrázok pomocou myši, a tak
dostať sémantický popis objektu, na ktorý používateľ klikne.
4.4 Komunikácia s obrázkami návrhových vzorov
Ku komunikácii s obrázkami predstavujúcimi UML diagramy tried návrhových
vzorov môžeme pristupovať dvoma spôsobmi. Buď, ako spomíname vyššie, prehliadaním obrázka za pomoci používateľovho klikania myšou po jeho ploche,
kedy preskúmavame priamo oblasti jednotlivých skupín grafických primitív
uložených v SVG. V našom prípade sú to predovšetkým triedy zakreslené notáciou UML, ktoré sú reprezentované obdĺžnikovými tvarmi. A k nim je vďaka
anotáciám jednoznačne priradená entita z danej ontológie.
Ďalší prístup ku komunikácií s návrhovými vzormi využíva formu dialógu.
Táto komunikácia prebieha v interaktívnej podobe tak, že používateľ položí
otázku, ktorú spracuje GATE. Systém nájde odpoveď v anotovanom SVG súbore, sformuluje ju a následne zobrazí používateľovi. Celá komunikácia môže
prebiehať napríklad v zjednodušenom jazyku WWL3.1 , teda formou otázok
a odpovedí v tvare podobnom konštrukcii viet typu „Čo je kde“ alebo „Kde
je čo“. Uveďme si ale príklad, ktorý využíva pokročilejšiu formu jazyka. Asi
nasledovne by mohla v ideálnom prípade vyzerať dialógová komunikácia, ak
by sme si prezerali diagram konkrétneho návrhového vzoru, na ktorom sme si
ilustrovali spojenie SVG a OWL prvkov v predchádzajúcich podkapitolách.
32
4. Tvorba diagramov návrhových vzorov
Príklad dialógu s Reťazou zodpovednosti:
↗:
↘:
Na čo slúži návrhový vzor?
Reťaz zodpovednosti sa vyhýba spojeniu odosielateľa a príjemcu žiadosti tím,
že umožní túto žiadosť spracovať viac než jednému objektu. Príjemcov zreťazí a posúva žiadosť prostredníctvom reťaze, až kým ju nejaký objekt nespracuje.
↗:
↘:
Kedy ho použijeme?
Použijeme ho keď má byť sada objektov spracovávajúcich žiadosť určená
dynamicky.
↗:
↘:
Ďalšie použitie?
Použijeme ho keď chceme žiadosť vystaviť jednému z niekoľkých objektov bez
toho, aby sme explicitne určovali príjemcu.
↗:
↘:
Z akých súčastí sa skladá návrhový vzor?
Reťaz zodpovednosti sa skladá z tried Client, Handler a ConcreteHandler.
↗:
↘:
Aká je úloha triedy Client?
Client inicializuje žiadosť na objekt ConcreteHandler v reťazi.
↗:
↘:
Akú triedu volá Client?
Client volá triedu Handler.
↗:
↘:
Čo je trieda Handler?
Handler je abstraktná trieda. Obsahuje atribút successor a rozhranie
metódy handleRequest. Má potomkov ConcreteHandler1 a ConcreteHandler2. Trieda Handler volá samú seba.
↗:
↘:
ConcreteHandler1 je abstraktná trieda?
Nie.
↗:
↘:
ConcreteHandler1 teda implementuje metódu handleRequest?
Áno, to je skutočne tak.
Týmto príkladom dialógovej komunikácie, ktorý si myslíme, že nie je treba
zvlášť popisovať, uzatvárame kapitolu o tvorbe anotovaných grafických študijných materiálov zaznamenávajúcich problematiku tzv. design patterns pomocou UML diagramov tried. Samotnú analýzu uvedenej komunikácie a rozpoznávanie položených otázok má na starosti iný komponent systému GATE,
ktorý už nie je predmetom tejto diplomovej práce. Cieľom práce je v záverečnej časti ešte zhrnúť proces vývoja webovej aplikácie, ktorá poskytne vhodné
používateľské prostredie na výučbu návrhových vzorov formou e-learningu. Rozhranie aplikácie je primárne určené pre zrakovo postihnutých používateľov.
33
kapitola 5
webová aplikácia
na výučbu návrhových vzorov
Hlavným programovým výstupom tejto diplomovej práce je implementácia
webovej aplikácie na podporu e-learningu. Má poskytnúť najmä nevidiacim
používateľom pohodlný nástroj, pomocou ktorého sa prostredníctvom dialógovej komunikácie môžu dozvedieť niečo viac o návrhových vzoroch z ich UML
modelov. Webový klient volá služby systému GATE, s ktorým sme sa oboznámili v časti 3.1. Keďže sa jedná o výskumný projekt a vývoj tohto systému
v súčasnosti stále prebieha, pri realizácií akýchkoľvek doplnkových nástrojov
systému zľahka narážame na takzvaný „výskumný problém“ [13], kde sa môže
výsledný produkt a s ním spojené poskytované služby v čase meniť. Našťastie
projekt GATE má jasne definované ciele3.1 , určené technológie, na ktorých je
jeho systém postavený, a postupne napĺňa špecifikované požiadavky. S touto
vopred nie úplne istou záverečnou podobou systému a jeho komponentov je
nutné počítať, a preto by naša aplikácia mala byť dostatočne ľahko prispôsobiteľná v priebehu vývoja i v budúcnosti.
5.1 Návrh aplikácie
V tejto časti si uvedieme základné požiadavky na vlastnosti webového klienta
a zhrnieme si proces jeho návrhu. Úplne esenciálnu vlastnosť predstavovala
prístupnosť2.1 , keďže hlavné využitie nástroja majú nájsť zdravotne postihnutí
používatelia, ktorí nedisponujú funkčným zrakovým orgánom. Opatreniam zabezpečujúcim prístupnosť sa budeme bližšie venovať až v nasledujúcej podkapitole. Ďalšie požiadavky mali zabezpečiť jednoduchú rozšíriteľnosť webových
stránok i samotnej aplikácie a rovnako aj použitie všeobecne dobre známeho
programového prostredia. Podľa zadania práce ním mal byť jazyk Java a jeho
pokročilé webové technológie.
34
5. Webová aplikácia na výučbu návrhových vzorov
Začnime návrhom GUI (graphical user interface). Na obrázku 5.1 je skica
grafického používateľského rozhrania webovej aplikácie zhotovená pomocou
Balsamiq Mockups. Tento jednoduchý nástroj sa používa pri návrhu dizajnu
webových stránok a grafických rozhraní všeobecne. Slúži na pohodlnú tvorbu
tzv. wireframe modelov, kde znázorňujeme rozmiestnenie jednotlivých prvkov
rozhrania. Skúšobná, časovo obmedzená verzia tohto programu je dostupná na
stiahnutie zdarma na domovskej stránke projektu [34].
Obr. 5.1: Náčrt používateľského rozhrania webovej aplikácie. Ilustrácia
vytvorená pomocou nástroja Balsamiq Mockups [34].
Webová stránka je rozdelená do dvoch stĺpcov. Užší z nich sa nachádza
vľavo, kde nájdeme okrem tlačidiel na zmenu jazyka hlavne základnú navigáciu, ktorú tvoria jednotlivé návrhové vzory zoradené abecedne a zoskupené
podľa kategórií vzorov. Pravá časť rozhrania poskytuje vlastný obsah danej
stránky, teda buď úvodné informácie, alebo podrobnosti o aktuálne vybranom
návrhovom vzore. Hlavnú súčasť tvorí samotný UML diagram vzoru. Po pra35
5. Webová aplikácia na výučbu návrhových vzorov
vej strane diagramu je zoznam príkladov obsahujúcich odkaz ako na základnú
štruktúru vzoru, tak aj na ďalšie príklady ilustrujúce reálne prípady použitia
vzoru. Používateľ tiež môže nahrať vlastný SVG súbor s príkladom z disku. Pod
diagramom je časť spravujúca komunikáciu so vzorom. Obsahuje používateľský vstup vo forme slovnej otázky a všetky správy momentálne prebiehajúceho
dialógu.
Čo sa týka návrhu funkcionality webového klienta, ten je určený len základnou ideou celej aplikácie. Tvorí ju výber návrhového vzoru z ponuky a jeho
konkrétneho diagramu zo skupiny príkladov. Následne je SVG dokument zachytávajúci tento diagram na pozadí odoslaný na server systému GATE, aby
bol spracovaný. Používateľ potom využíva jednoduchý dialóg, kde po zadaní
otázky je opäť na pozadí odoslaná na server. Po vyhodnotení otázky a sformulovaní odpovede obdržíme od servera odpoveď v podobe textového reťazca,
ktorý zobrazíme používateľovi na výstup. V dobe riešenia diplomovej práce
ešte systém GATE nedisponuje implementáciou tejto služby, ale vďaka vypracovanému rozhraniu môžeme pripraviť túto funkcionalitu na našej klientskej
strane. Medzi ďalšie služby by malo patriť aj preskúmavanie anotovaných oblastí SVG obrázku pomocou myši. Táto časť systému v súčasnosti ešte rovnako
nie je funkčná.
5.2 Používateľská prístupnosť
Ako sme už párkrát spomenuli, webová stránka má slúžiť predovšetkým nevidiacim používateľom, preto je nesmierne dôležité držať sa pri jej tvorbe pravidiel prístupného webu, ktorým sme sa obsiahlo venovali v teoretickej časti
práce. Popíšme si niekoľko základných aplikácií týchto pravidiel použitých na
našej stránke.
˓→ Textové popisy
Základnou textovou alternatívou grafických elementov HTML stránky je
hodnota atribútu alt. Problémom ale je, že tento atribút je typicky definovaný len pre element <img>. Väčšina obrázkov na stránke sa však nenachádza v uvedenom elemente, ale je tu prítomná vďaka CSS (Cascading Style
Sheets), kde sa vyskytujú ako background iných elementov. Najčastejšie
sú to v našom prípade prvky div, nadpisy h1, h2 alebo položky zoznamu
li. Musíme teda postúpiť v textových popisoch trochu ďalej a na to nám
slúži atribút title, ktorý je v HTML5 definovaný pre každý element.
Spomínané obrázky ale slúžia iba ako pozadie, teda väčšinou plnia dekoračnú úlohu. A práve pri pravidlách prístupnosti stránok sme si uvádzali,
36
5. Webová aplikácia na výučbu návrhových vzorov
že popisovať takéto obrázky nie je nutné, je to naopak kontraproduktívne.
Čo má ale veľký význam popísať atribútom title sú hypertextové odkazy. Elementy <a> kvôli modernému dizajnu často tvoria vnorený obsah
prvkov s obrázkom v pozadí a ich hlavný text v skutočnosti ani vôbec nie
je viditeľný.
˓→ Logická štruktúra a navigácia
S textovými popismi elementov úzko súvisí aj orientácia a pohyb po
stránke. Dnes sa mnohé stránky snažia zaujať návštevníka oku lahodiacim vzhľadom tým, že preferujú obsah vyjadrený graficky pred textom.
No pri tom ich tvorcovia zabúdajú na jednu zásadnú vec. Ako bude vyzerať stránka, ak sa nenačíta súbor definujúci kaskádové štýly? Nestratí
sa logická štruktúra stránky alebo dokonca jej obsah? Žiaľ, existujú webové stránky, pri ktorých k takémuto javu naozaj dochádza. Tomu sa
musíme v našej aplikácií vyvarovať, obzvlášť keď má byť prístupná pre
nevidiacich. Asistenčná technológia používaná handicapovaným si poradí
najlepšie so stránkou, ktorá nie je viazaná na takéto vizuálne formátovanie.
Nestačí teda do vrchnej časti stránky umiestniť obrázkové logo zahŕňajúce
jej nadpis, ale musíme pri ňom doslova „schovať“ aj príslušný textový reťazec. Aj keď pre používateľa s korektne zobrazeným CSS nebude viditeľný,
v skutočnosti je jeho prítomnosť na stránke veľmi dôležitá. Naša stránka
preto tvorí logicky usporiadanú štruktúru aj bez grafického formátovania.
Za nadpisom stránky nasleduje ponuka predstavujúca zoznam návrhových
vzorov. Ďalej sa nachádza nadpis aktuálne prehliadaného vzoru, jeho diagram a napokon priestor na dialóg. Všimnime si v jednotlivých správach
komunikácie explicitne uvedené popisy question a answer aj napriek tomu,
že sú tieto dva typy správ oddelené vizuálne pomocou obrázkov šípok.
˓→ Klávesové skratky
Vstup klávesnice používajú zrakovo postihnutí používatelia pomerne často.
Ani my ich nesmieme nechať blúdiť po našich stránkach iba pomocou
myši a postupne preskúmavať každý element. Navigáciu na stránke určite
urýchli priradenie tzv. hotkeys každému zaujímavému odkazu. To je možné
docieliť pomocou atribútu accesskey, ktorému nastavíme príslušný znak
z klávesnice. Na webe sa dá sa naraziť na niekoľko menej alebo viac oficiálnych štandardov. Kým podľa niektorých odporúčaní sú to začiatočné
písmená odkazov, napr. I pre index, teda návrat na hlavnú stránku, podľa
iných pravidiel by takáto domovská stránka projektu mala byť prístupná
numerickým klávesom 1 [35]. Testovanie ukázalo, že numerické klávesnice
vo väčšine prehliadačov vôbec nereagujú. Preto sme našu aplikáciu vy37
5. Webová aplikácia na výučbu návrhových vzorov
bavili práve začiatočnými písmenami odkazov pri použití ich anglického
výrazu. Napríklad L pre zmenu jazyka či N pre prechod na stránku nasledujúceho návrhového vzoru, resp. P na stránku predchádzajúceho vzoru.
Tieto klávesové skratky, tým že reprezentujú vždy iný odkaz, musia byť
ale na našich stránkach priraďované dynamicky. Skript, ktorý danú alokáciu skratiek rieši, si predstavíme až neskôr v sekcii o JSP. Používateľ
je so skratkami vyskytujúcimi sa vo webovej aplikácii oboznámený na
úvodnej stránke, kde je spolu s nimi vysvetlené aj ich vyvolanie v rôznych prehliadačoch a operačných systémoch, napr. Alt + Shift + skratka
vo Firefox.
Vloženie SVG dokumentu do HTML stránky
Momentálne sa pozrieme na prístupnosť nie z hľadiska potencionálneho zdravotného postihnutia používateľov, ale kvôli použitiu rôznych zobrazovacích
zariadení a webových prehliadačov. V podkapitole 3.2 sme si uvádzali stav
podpory prehliadačov pri zobrazovaní SVG obrázkov na HTML stránkach.
Existuje niekoľko spôsobov vloženia SVG dokumentu do stránky. Nasledujúci
úsek textu je spracovaný podľa informácií v článkoch [36, 37].
˓→ <embed> – element s dobrou podporou prehliadačov v dokumente typu
HTML5, pričom nie je validný pre staršiu verziu HTML4. Cesta k súboru
sa nastavuje atribútom scr a typ súboru má v prípade SVG hodnotu
image/svg+xml.
˓→ <object> – je validný pre HTML4, XHTML aj HTML5, ale nepodporuje
priame skriptovanie. Atribút odkazujúci na dokument je data. Výhodou
je možnosť nastaviť do vnútra elementu ďalšie prvky, ktoré prehliadač využije, ak nebude schopný zobraziť pôvodný <object>. Pri starších prehliadačoch bolo vhodné do vnútra definovať aj parametre objektu pomocou
elementu <param> alebo uviesť odkaz na stiahnutie zásuvného modulu,
ktorý by tento objekt dokázal zobraziť.
˓→ <iframe> – generuje okolo obrázka hraničné čiary, ktoré musia byť odstránené pomocou štýlov. Na súbor sa odkazuje takisto atribútom scr.
Nevýhodou je, že neumožňuje uviesť odkaz na prípadné stiahnutie zásuvného modulu.
Často sa využíva na vloženie SVG obrázku aj klasický <img> prvok. Je
mu možné v atribúte scr odovzdať ako pôvodný SVG súbor, tak prípadne
jeho rastrovú alternatívu. Takýto princíp používa aktuálne aj projekt GATE
38
5. Webová aplikácia na výučbu návrhových vzorov
na svojej domovskej stránke [15]. Pričom vkladá do HTML kódu rastrový
duplikát obrázku v PNG podobe a na požadovaný SVG súbor sa odkazuje
atribútom rel.
V našej aplikácii sme nakoniec zvolili spôsob vloženia SVG dokumentu,
ktorý sa nám javil ako najuniverzálnejší, teda pomocou elementu <object>
a vo vnútri neho ešte uviedli <embed> spĺňajúci spomínanú fallback funkciu.
Pri tomto rozhodnutí sme ale čerpali z neúplných informácií o budúcej výslednej podobe a možnostiach nástrojov systému GATE. Ak by si to situácia
v budúcnosti vyžadovala, dané prvky zobrazujúce SVG súbor je možné v kóde
aplikácie kedykoľvek veľmi jednoducho zmeniť bez narušenia celkovej štruktúry
stránok.
5.3 Technológie a implementácia
Webová aplikácia Design Patterns by Dialog, skrátene DEPAD, je postavená na technológií Java EE (Java Platform, Enterprise Edition) a na implementáciu využíva niekoľko jej základných prvkov i nadstavbu v podobe frameworku Stripes. Samotný popis niektorých implementačných detailov aplikácie
je sprevádzaný vysvetlením pojmov MVC architektúry, stránok JSP, značiek
JSTL a objektov EJB. Pozrime si teraz na obrázku 5.2, ako v zjednodušenej podobe vyzerá v našom prípade diagram nasadenia, takzvaný deployment
diagram.
Obr. 5.2: Zjednodušený diagram nasadenia aplikácie DEPAD.
Architektúra MVC
MVC (Model-View-Controller) je architektonický vzor, ktorý rozdeľuje aplikáciu do troch komponentov – dátový model, používateľské rozhranie a riadiaca
logika. Tieto komponenty sú navzájom nezávislé v tom zmysle, že modifikácia
39
5. Webová aplikácia na výučbu návrhových vzorov
niektorej z nich má len minimálny vplyv na ostatné. Model predstavuje objekt
aplikácie a dáta, s ktorými sa pracuje. View slúži na vyjadrenie modelu, ktorý
je tu reprezentovaný v podobe vhodnej na interakciu s používateľom. A nakoniec Controller definuje spôsob, akým sa reaguje na udalosti pochádzajúce
z používateľského rozhrania, a tiež zaisťuje zmeny v modeli a „náhľade“ [1].
Architektúra MVC sa typicky využíva pri tvorbe webových aplikácií. V takomto prípade model predstavuje celá aplikačná logika aj s vrstvou prezistentnou, ktorá má na starosti uchovávanie dát v databáze. Prezentačná vrstva
predstavuje súčasne ako používateľské rozhranie, tak aj jeho riadiacu logiku.
Na implementáciu prezentačnej vrstvy nám slúžia napríklad nástroje Spring
MVC, Stripes, Struts, JSF, Tapestry či Wicket. Rámec Stripes použitý aj
v praktickej časti diplomovej práce si bližšie predstavíme neskôr v texte.
Naša aplikácia predstavujúca webového klienta komunikujúceho so systémom GATE z pohľadu MVC v podstate nedisponuje vlastným komponentom
model. Keďže sa jedná o takzvanú klient-server architektúru, kde je klient
pomerne „tenký“, hlavný dátový model a aplikačná logika sa nadchádza na
strane servera. Webová aplikácia vzhľadom k požiadavkám na implementáciu
nepracuje so žiadnou databázou, kam by sa ukladala história dialógu používateľa s návrhovým vzorom. Jednotlivé otázky a ich odpovede sú používateľovi
dostupné len dočasne. Po opustení konverzácie nie je možné sa k prerušenému
dialógu vrátiť. Naopak najväčšiu implementačnú časť tvorí požívateľské rozhranie a riadiaca logika.
Tok udalostí v našej MVC aplikácií vyzerá nasledovne. Používateľ si vyberie návrhový vzor z ponuky vďaka grafickému rozhraniu webovej stránky
a controller ho presmeruje na príslušnú stránku so vzorom. Ďalej si používateľ
vyberie UML diagram, s ktorým chce viesť dialóg. Riadiaca logika spracuje
požiadavku a daný SVG dokument s diagramom odošle inicializovať sa na
server. Systém GATE reprezentujúci model potom pracuje s dátami tohto dokumentu. Informácie pochádzajúce z modelu v podobe textových odpovedí na
položené otázky sa zobrazia v používateľskom rozhraní a tak ďalej.
JavaServer Pages
JSP (JavaServer Pages) sú nadstavbou Java servletov, čiže nástrojov na nízkoúrovňovú obsluhu protokolu HTTP na strane servera. Písať webové aplikácie
priamo písaním servletov je ale veľmi nepohodlné, keďže každý riadok musí byť
vygenerovaný pomocou volania metódy. JSP stránka predstavuje úplne opačný
prístup, lebo predstavuje text, kde je občas vložený kód v jazyku Java. Tieto
stránky sú textové súbory s príponou .jsp. Pri prvej požiadavke na zobrazenie
40
5. Webová aplikácia na výučbu návrhových vzorov
sú servletovým kontajnerom prevedené na klasické servlety, preložené do Java
tried .class a napokon mapované na URL pôvodného JSP súboru [39].
Úseky Java kódu vo vnútri HTML stránky sa nazývajú scriptlets. Dnes sa
skriptlety už veľmi nepoužívajú, pretože vedú k tvorbe webových aplikácií len
pomocou JSP stránok obsahujúcich takýto kód. Skriptlet predstavuje všetko,
čo sa nachádza v značkách <% a %>. HTML text a výkonný kód sú zmiešané, čo
je neprehľadné a spôsobuje náročnú údržbu kódu. Kvôli spätnej kompatibilite
sú ale skriptlety v JSP stránkach stále podporované [39].
Naša webová aplikácia DEPAD v prvej fáze obsahovala na JSP stránkach
skriptlety, ktoré mali na starosti napríklad dynamické prideľovanie klávesových
skratiek odkazom podľa toho, na ktorej stránke sa nachádzal používateľ. Pozostávali z kódu kontrolujúceho rovnosť textových reťazcov a podobne. Keďže
v súčasnosti už nie je odporúčané používať skriptlety, museli sme aj my zvoliť
inú variantu generovania dynamického obsahu. Alternatívnym mechanizmom
sú JSP značky, nazývané aj „tagy“, zaznamenávajúce vykonanie určitej akcie.
JSP značka vyzerá podobne ako v XML, tvorí ju prefix a konkrétne meno
značky doplnené o prípadné atribúty.
Štandardizovanú knižnicu JSP značiek tvorí JSTL (JSP Standard Tag Library) skladajúca sa z piatich rôznych balíkov funkcií. Pre nás sú momentálne
zaujímavé akcie core, ktoré pracujú s premennými, vetvením, cyklami či URL
adresami. Ďalej sú to fmt funkcie na formátovanie a internacionalizáciu, teda
použitie textov v rôznych jazykoch. Silnou stránkou JSTL je používanie jazyka
EL (Expression Language), ktorý umožňuje jednoduchý prístup k atribútom
stránky (page), požiadavky (request), spojenia (session) alebo celej aplikácie
(application). Výrazy EL sú prístupné pomocou konštrukcie uzatvorenej v znakoch ${ a }, môžu sa nachádzať kdekoľvek na stránke a sú vyhodnocované
servletovým kontajnerom. Jazyk EL disponuje napríklad aritmetickými, logickými či relačnými operátormi [11, 39]. Nahradenie ťažkopádnych skriptletov
týmito EL výrazmi v našej aplikácií spravilo kód prehľadnejší a jednoduchší
na údržbu. Krátku ukážku kódu používajúceho JSTL i EL prezentujeme na
príklade 5.2 pri lokalizácii aplikácie. Ostatné zdrojové kódy JSP stránok samozrejme nájdeme v praktickej časti tejto diplomovej práce.
Framework Stripes
Webové aplikačné rámce sú softvérové knižnice, ktoré poskytujú nástroje na
sprístupnenie požadovaných služieb typicky sa vyskytujúcich vo väčšine webových aplikácií. Rámce tvoria nadstavbu servletov, no na rozdiel od JSP
slúžiacich na generovanie webových stránok, sa snažia riešiť skôr prechod ap41
5. Webová aplikácia na výučbu návrhových vzorov
likáciou. Buď pracujeme s rámcami orientovanými na vizuálne komponenty
(Wicket, JSF), alebo na spracovanie HTTP požiadaviek (Spring MVC, Struts).
Ako sme si už spomínali, vymenované frameworky sa používajú pri tvorbe prezentačnej vrstvy.
Stripes je nový populárny rámec, ktorý spadá do kategórie frameworkov
založených na akciách. Poučil sa z chýb svojich predchodcov a nevyužíva žiadne
konfiguračné súbory, ale len anotácie zavedené v Java 5.0. Uvedený princíp
sa nazýva convention-over-configuration. Jedná sa o prístup zjednodušujúci
vývojárovi proces vývoja tým, že je vyžadované prepísať nastavenia iba vtedy,
ak vyvíjaná aplikácia potrebuje správanie, ktoré sa odlišuje od konvenčného.
Nie je nutné vždy prechádzať kompletnú konfiguráciu a nastavovať každý jeden
prvok osobitne [38, 39].
Framework Stripes je realizovaný pomocou servletu a servlet filtru. Pri
konfigurácií teda stačí len dopísať ich definície do súboru WEB-INF/web.xml,
čo predstavuje takzvaný „popisovač nasadenia“ (deployment descriptor). Tu je
možné napríklad pomocou parametra ActionResolver.Packages určiť, v ktorých balíkoch budú hľadané ActionBeans a podobne. ActionBeans tvoria základnú funkcionalitu rámcu Stripes a sem sa umiestňuje všetok výkonný kód.
Z pohľadu MVC modelu sa vlastne jedná o controller, ktorý obsahuje metódy
spracovávajúce HTTP požiadavky. Návratovou hodnotou metód je objekt typu
Resolution, ktorý priamo určuje, kam sa predá riadenie a kam bude prehliadač presmerovaný [39].
Stripes je možné integrovať s rôznymi rámcami na generovanie stránok.
Pre použitie s JSP je predpripravená knižnica značiek. Výhodou Stripes je,
že nie je nutné vytvárať nové objekty entít len kvôli prezentačnej vrstve a pri
vypĺňaní formulárov sa manipuluje priamo s objektmi z modelu [39]. Toto sme
ale pri realizácii DEPAD klienta nepoužili, keďže nepracujeme so žiadnym modelom. Medzi ďalšie silné stránky tohto frameworku patrí aj vylepšený nástroj
na skladanie stránok, kedy stačí vytvoriť JSP so šablónou stránky. V našej
aplikácii takejto šablóne zodpovedá súbor layout.jsp.
Webový rámec Stripes bol zvolený kvôli svojej jednoduchosti, ktorou disponuje vďaka spomínanému princípu convention-over-configuration. Spočiatku
bolo uvažované použitie Spring MVC, ale nakoľko implementácia zahŕňala len
používateľské rozhranie a riadiacu logiku bez modelu, usúdili sme, že táto
technológia nie je úplne vhodná na vývoj aplikácie daného rozsahu a uprednostnili sme radšej framework Stripes. Základnou myšlienkou implementácie
sú ActionBean objekty pre každý návrhový vzor. Jednotlivé metódy sa potom odkazujú na konkrétny diagram vzoru. Stripes nám ponúkol mimo iného
aj pohodlnú možnosť nahrávania súborov do aplikácie z disku a ich následné
42
5. Webová aplikácia na výučbu návrhových vzorov
odoslanie na GATE server. Okrem základných knižníc frameworku sme použili aj doplnok stripesstuff-0.3.jar, ktorý sa síce nenachádza v centrálnom
repozitári, ale je voľne stiahnuteľný z webu. K našej aplikácii je pribalený v adresári lib. Z knižnice Stripes Stuff sme použili napríklad anotáciu @Session,
ktorá zabezpečí uchovanie hodnoty atribútu v rámci celého spojenia.
Viac informácií o potrebných závislostiach ku kompilácii nášho projektu
typu Maven a jeho spustení na aplikačnom serveri Glassfish sa nachádza v súbore readme.txt, ktorý je distribuovaný spolu so zdrojovým kódom praktickej
časti tejto diplomovej práce. Súčasťou súboru je aj stručný popis krokov vedúcich k rozšíreniu aplikácie o ďalšie diagramy a návrhové vzory.
Enterprise JavaBeans
EJB (Enterprise JavaBeans) je serverová komponentovo orientovaná architektúra umožňujúca modulárnu tvorbu podnikových (enterprise) aplikácií. Slúži
na implementáciu aplikačnej logiky, tzv. „business vrstvy“, informačného systému. Hlavné uplatnenie nachádzajú predovšetkým v trojvrstvovej architektúre, kde oddeľujú aplikačnú vrstvu od prezentačnej a perzistentnej. Konfigurácia EJB podobne ako u alternatívneho frameworku Spring prebieha deklaratívnym spôsobom, teda chovanie programu sa nedefinuje tradične postupnosťou príkazov ako dosiahnuť cieľ, ale špecifikáciou cieľa samotného, ktorý má byť
dosiahnutý. Ich kľúčovou vlastnosťou je interoperabilita, a to ako medzi rôznymi webovými kontajnermi a aplikačnými servermi, tak i medzi inými aplikáciami navzájom. Tá prebieha prostredníctvom rozhrania protokolu IIOP [39].
Verzia EJB 3.0 pochádza z roku 2006, bola predstavená v Java EE 5 a prináša výrazné zjednodušenie vývoja oproti predchádzajúcim verziám. Podobne
ako Stripes, aj EJB vychádza z princípu, v ktorom sa snaží minimalizovať nutnosť konfigurácie. Deklaratívny spôsob programovania využíva anotácie jazyka
Java. Rozoznávame niekoľko základných typov EJB komponent, ale nám si teraz stačí uviesť existenciu stateless a stateful varianty. Druhá spomínaná, ktorá
je reprezentovaná anotáciou @Stateful, si udržuje stav klienta počas komunikácie v rámci jedného spojenia, tzv. (session). Tieto typy EJB objektov sa
využívajú aj v systéme GATE. Komponenty EJB môžu implementovať dve
rozhrania – lokálne a vzdialené. Prvé je anotované ako @Local a jeho metódy
sú počas behu volané v jednom Java Virtual Machine. Vzdialené rozhranie
@Remote slúži typicky na volanie metód bežiacich na vzdialenom aplikačnom
serveri, napríklad pomocou spomínaného IIOP protokolu [12, 39].
Náš webový klient má komunikovať so systémom GATE práve použitím
vzdialených volaní EJB komponentov. Úlohou diplomovej práce je využiť stav
43
5. Webová aplikácia na výučbu návrhových vzorov
a funkcie tohto systému dostupné v súčasnom období realizácie práce. Bohužiaľ, to znamená zredukovanie komunikácie len na počiatočnú inicializáciu
SVG dokumentu, bez ďalšej funkcionality, ktorá by predstavovala samotné vedenie dialógu používateľa s anotovaným obrázkom. Napriek tomu sa jednalo
o najproblematickejšiu časť celej práce.
Základom volania Remote EJB je takzvaný JNDI lookup. Ten spočíva vo vyhľadaní EJB komponentu pomocou Java Naming and Directory Interface.
Zo serverovej strany sme dostali údaje, že v našom prípade má požadovaná
cesta ku komponentu tvar java:global/GateSVG-ejb-1.0/GateSvgBean!cz.muni.fi.gate.svg.GateSvgRemote. Tento reťazec je parametrom metódy
lookup volanej na objekte InitialContext. Pri inicializácií kontextu mu však
musíme nastaviť vlastnosť cieľového servera, v našom prípade ako setProperty(”org.omg.CORBA.ORBInitialHost”, ”andromeda.fi.muni.cz”). Prípadne je možné nastaviť initial host explicitne pri spúšťaní programu ako JVM
argument. Prvá komplikácia nastala, keď s nami server odmietal komunikovať.
Mala pôvod v zabezpečení servera, ktorý neprijímal požiadavky zariadení pristupujúcich z neznámej IP adresy.
Po sprístupnení komunikácie so serverom sme prišli na skutočnosť, že úspešné vyhľadanie a rozpoznanie EJB komponentu GateSvgBean na serveri, ak
sa k tomuto EJB pristupuje „zvonka“, závisí na jeho znalosti. Pokiaľ sa teda
snažíme nájsť komponent, ktorý nie je súčasťou žiadneho verejného repozitára,
sme odkázaní na jeho lokálnu závislosť. Súbor GateSVG-ejb-1.0.jar musí byť
distribuovaný spolu s aplikáciou a musí byť súčasťou classpath pri jej spúšťaní.
Ak chceme s EJB objektom pracovať, volať jeho metódy, nesmieme zabudnúť
pridať závislosť na projekte obsahujúcom tento komponent.
Ďalší problém sa objavil práve pri pridávaní týchto závislostí. Webový
kontajner Apache Tomcat mal viacero kolízií s pôvodným GATE SVG projektom a deploy našej aplikácie v ňom nebol možný. Zvolili sme teda variantu aplikačného servera GlassFish, na ktorom beží aj celý systém GATE.
Z neznámych príčin mal ale aj tento server problémy s priloženou jar aplikáciou, konkrétne s triedami tretej strany org.w3c.dom.svg.SVGDocument
a org.w3c.dom.svg.SVGSVGElement, ktoré sú súčasťou Apache Batik SVG
Toolkit použitého na serveri pri práci s SVG dokumentmi. Lokálne sme teda
museli upraviť zdrojové kódy projektu GateSVG-ejb, kedy sme z nich vylúčili
všetky výskyty týchto objektov. Skompilovaná jar knižnica už následne problémy nerobila. To, že nie je korektne funkčná, v tomto prípade nie je vôbec
podstatné, pretože slúži len na definíciu EJB, ktorú má lookup hľadať. V skutočnosti sa samozrejme pracuje so stateful EJB komponentom nachádzajúcom
sa na serveri. V prípade, že by sme na spúšťanie programu vyhľadávajúceho
44
5. Webová aplikácia na výučbu návrhových vzorov
spomínaný EJB nepoužili GlassFish, bolo by nutné pridať explicitne závislosti
na knižnici gf-client, prípadne aj glassfish-embedded-all.
Napriek tomu, že nakoniec riešenie využívajúce vzdialené EJB je funkčné,
v pozícií tvorcov serverovej strany systému GATE by sme mohli zvážiť použitie webových služieb. Tým by sme predišli nutnosti lokálnych závislostí
u klienta. Určite by sa dalo prehodnotiť použitie rozhrania REST (REpresentational State Transfer), ktoré by komunikovalo priamo výmenou správ
v podobe XML, prípadne JSON. Formát XML sa javí ako veľmi výhodný
predovšetkým na prenos dokumentov SVG a OWL, s ktorými sa v systéme
pracuje, keďže tie sú reprezentované práve pomocou XML. Na druhej strane
je možné využiť priamo technológiu JAX-WS (Java API for XML-Based Web
Services), ktorá je súčasťou Java EE. Tak by sa jednoducho využili anotácie
@WebService a @WebMethod, vďaka čomu by bol vygenerovaný WSDL dokument a komunikácia by prebiehala pomocou protokolu SOAP (Simple Object
Access Protocol). Akým spôsobom by sa dala realizovať takáto webová služba,
môžeme nájsť napríklad v knihe EJB 3 Developer Guide [12].
Popis uvedených technológií a spôsobov implementácie prípadnej webovej
služby na tomto mieste by však výrazne presahoval rámec našej diplomovej
práce. Na určenie vhodnosti takéhoto riešenia však nemáme ani dostatok informácií o štruktúre a funkcionalite celej serverovej časti. Situáciu komplikuje
aj fakt, že sa pracuje so stateful komponentmi, ktoré udržujú stav a po príkazoch zadaných používateľom sa čiastočne menia. Podľa nám dostupných
informácií sa totiž zdá, že systém môže na rovnakú otázku v rôznych fázach
dialógu reagovať inak, pričom vychádza z predošlej komunikácie.
5.4 Lokalizácia aplikácie
Lokalizácia aplikácie do viacerých jazykov je v Jave EE s použitím moderných rámcov samozrejmosť. Má to v réžii spomínaná technológia JSTL, konkrétne jej knižnica formatting actions označovaná ako fmt, a využíva súbory
.properties, kde hľadá lokalizované reťazce. Aplikácia si zistí jazykové preferencie webového prehliadača a podľa toho vyberá príslušnú lokalizáciu. Nášho
klienta ale potrebujeme rozšíriť aj o dynamickú zmenu jazyka, ktorú vyvolá
používateľ kliknutím na obrázok vlajky na stránke.
V prípade aplikácie ako je naša, máme na výber hneď niekoľko možností
ako lokalizovať. Pri použití frameworku Stripes je v prvom rade nutné doplniť požadované hodnoty locale do konfiguračného súboru web.xml5.3 , ktoré sa
nastavujú pomocou parametra LocalePicker.Locales. Predstavme si teraz
dva spôsoby, ako môžeme postupovať ďalej. Buď pomocou Stripes, ktorý po45
5. Webová aplikácia na výučbu návrhových vzorov
skytuje tzv. extensions slúžiace na tvorbu vlastných interceptorov1 , typových
konvertorov a iných konfigurovateľných komponentov. V podobe parametra
Extension.Packages sa udáva do konfiguračného súboru balík, v ktorom potom Stripes hľadá nami definované rozšírenia.
Príklad implementácie triedy, ktorá rozširuje DefaultLocalePicker z API
frameworku Stripes, môžeme vidieť na ukážke 5.1. Táto trieda musí byť umiestnená v uvedenom balíku s rozšíreniami. Najprv sa hľadá parameter lang, ktorý
môže nadobúdať napríklad hodnoty cs, sk alebo en, v požiadavke HTTP. Ak
sa nájde, uloží sa do session. V prípade že sa parameter nenachádza v požiadavke, prehľadáva sa spojenie. Ak sa parameter nenájde ani v spojení, vrátená
bude predvolená hodnota lokalizácie pri spracovaní požiadavky. Inak je vrátená novovytvorená lokalizácia s hodnotou uvedenou v parametri lang.
public class Cu sto mL oc al eP ic ke r extends D e fa u l tL o c al e P ic k e r {
private static final String locale = " lang " ;
@Override
public Locale pickLocale ( Ht tp Se rv le tR eq ue st request ) {
HttpSession session = request . getSession () ;
String result = request . getParameter ( locale ) ;
if ( result != null ) {
session . setAttribute ( locale , result ) ;
} else {
result = ( String ) session . getAttribute ( locale ) ;
}
if ( result != null ) {
return new Locale ( result ) ;
}
return super . pickLocale ( request ) ;
}
}
Kód 5.1: Príklad triedy rozširujúcej DefaultLocalePicker zo Stripes API.
Druhý prístup k zmene jazyka využíva priamo len knižnicu JSTL a to
kombináciu akcií fmt a core. Nasledujúci fragment zdrojového kódu 5.2 sa
nachádza na začiatku každej stránky. V našom prípade je teda vhodné ho vložiť
do súboru layout.jsp. Zisťuje hodnotu parametra lang a podľa toho nastaví
danú lokalizáciu pomocou <f:setLocale/>. Ak sa v ňom náhodou nachádza
neznáma či nepodporovaná hodnota, vezme jednoducho jazyk vrátený v HTTP
1. Interceptor pridáva určité špeciálne správanie do bežného životného cyklu inštancie objektu. Predstavuje ho metóda označená anotáciou, ktorá sa môže vykonať pred vytvorením
objektu, zrušením a podobne.
46
5. Webová aplikácia na výučbu návrhových vzorov
odpovedi. Tento spôsob lokalizácie bol v našej aplikácií uprednostnený pred
prvým spomínaným prístupom využívajúcim aj rámec Stripes. A to najmä
z dôvodu menšej závislosti na použitom frameworku, ak by chcel byť Stripes
v budúcnosti na prezentačnej vrstve aplikácie nahradený inou technológiou.
<% @ taglib prefix = " c " uri = " http: // java . sun . com / jsp / jstl / core " % >
<% @ taglib prefix = " f " uri = " http: // java . sun . com / jsp / jstl / fmt " % >
< c:choose >
< c:when test = ’ ${ param . lang == " cs " } ’ >
< f:setLocale value = " cs " scope = " session " / >
< c:set var = " lang " value = " cs " scope = " session " / >
</ c:when >
< c:when test = ’ ${ param . lang == " sk " } ’ >
< f:setLocale value = " sk " scope = " session " / >
< c:set var = " lang " value = " sk " scope = " session " / >
</ c:when >
< c:when test = ’ ${ param . lang == " en " } ’ >
< f:setLocale value = " en " scope = " session " / >
< c:set var = " lang " value = " en " scope = " session " / >
</ c:when >
< c:otherwise >
< f:setLocale value = ’ ${ pageContext . response . locale .
language } ’ scope = " session " / >
< c:set var = " lang " value = ’ ${ pageContext . response . locale .
language } ’ scope = " session " / >
</ c:otherwise >
</ c:choose >
Kód 5.2: Nastavenie lokalizácie pomocou JSTL.
Parameter lang sa dostane do URL tak, že používateľ klikne na odkaz
v tvare <a href=”?lang=cs”>. Tento hypertextový odkaz sa nachádza na tlačidle s ikonou českej vlajky. Hodnota jazyka, ktorá je po jeho výbere uložená do session, sa používa aj na vizuálne znázornenie práve aktívnej lokalizácie. Majme dva obrázky vlajky, kde na jednom je táto vlajka zvýraznená
a na druhom potlačená. V súbore CSS sú potom definované dve triedy, zvlášť
pre element s obrázkovým pozadím aktívnej alebo neaktívnej vlajky. Tento
element v JSP stránke obsahuje atribút class=’${(sessionScope.lang ==
”cs”) ? ”flag-cs” : ”flag-cs-unactive”}’, ktorý má hodnotu podmieneného výrazu zapísaného v expression language 5.3 , čim sa zobrazí zvýraznená
vlajka len vtedy, keď jazyk nadobúda príslušnú hodnotu. Takto definované
ikony vlajok pre celý zoznam použitých jazykov na stránke zapríčinia, že vždy
je používateľovi zvýraznená práve jedna vlajka korešpondujúca s aktuálnou
lokalizáciou.
47
kapitola 6
záver
Diplomová práca E-learningová aplikácia na výučbu návrhových vzorov obsahuje sadu vlastných UML diagramov tried pôvodných návrhových vzorov od
autorov prezývaných Gang of Four. Tieto diagramy sú vytvorené ako vektorové
obrázky v grafickom formáte SVG a v rovnakom súbore sú doplnené sémantickými anotáciami použitím ontológií z domén návrhových vzorov a UML.
Na zápis anotácií je použitý jazyk ontológií OWL, ktorý vhodne dopĺňa štruktúru SVG dokumentu, keďže obidva tieto jazyky vychádzajú zo značkovacieho
štandardu XML. Takto reprezentované diagramy tvoria e-learningový materiál určený hlavne nevidiacim a zrakovo postihnutým používateľom, keďže im
poskytujú možnosť „prezerať si“ obrázok nie len na základe popisu jeho vizuálnych, ale aj sémantických vlastností.
Druhou časťou práce je implementácia webovej aplikácie, ktorá disponuje
prístupným grafickým rozhraním vhodným práve pre používateľov so zrakovým
handicapom. Webový klient komunikuje so systémom GATE, čo je produkt
vyvíjaný v rovnomennom projekte prebiehajúcom v Laboratóriu vyhľadávania
a dialógu na Fakulte informatiky Masarykovej univerzity. Náš vytvorený nástroj volá služby bežiace na serveri systému GATE, vďaka čomu robí z diagramov návrhových vzorov tzv. „komunikatívne obrázky“. Používateľ má možnosť
viesť dialógovou formou komunikáciu s daným návrhovým vzorom a dozvedieť
sa napríklad niečo o jeho štruktúre, výhodách či dôsledkoch použitia.
Aplikácia je implementovaná s využitím jazyka Java EE doplneného technológiami ako JSP stránky alebo framework Stripes, ktoré sú typické pre realizáciu prezentačnej vrstvy softvéru. Pri samotnej komunikácií so systémom
GATE sa využíva vzdialené volanie jedného z jeho poskytovaných EJB objektov. Bohužiaľ, GATE je výskumný projekt, ktorý je stále v procese vývoja
a momentálne ešte neposkytuje funkcie na vedenie spomínaného dialógu. Preto
je aj funkcionalita implementovaného klienta redukovaná len na počiatočné
odoslanie a inicializáciu SVG dokumentu na serveri. Súčasťou aplikácie sú okrem sady základných diagramov návrhových vzorov aj diagramy predstavujúce
48
typické príklady použitia týchto vzorov. Nakoniec webový klient umožňuje tiež
nahrať na server i vlastný anotovaný SVG dokument.
V práci sa nachádzajú diagramy prvých deviatich návrhových vzorov. Rozšírenie práce môžeme určite vidieť v doplnení materiálov o ostatné GoF vzory.
Text štvrtej kapitoly prehľadne popisuje, ako SVG dokumenty daných diagramov vytvárať. Práca sa nezaoberá novšími návrhovými vzormi iných kategórií,
ktoré je možné v konečnom dôsledku vytvoriť rovnakým spôsobom. Podobne
môžeme uvažovať aj obrázky takzvaných antipatterns. Z nich by sa študent
učil o schémach objektového návrhu, ktorým je lepšie sa vyvarovať. Ďalšou
výzvou do budúcnosti sú i ostatné UML diagramy, napríklad sekvenčné diagramy alebo diagramy použitia. Vtedy by bolo nutné vytvoriť aj nové ontológie
modelujúce danú problematiku.
Webová aplikácia je tiež vhodná na rozšírenie v podobe funkčnej dialógovej komunikácie s obrázkami. Súčasná implementácia je však na to dobre
pripravená a vyžaduje v budúcnosti minimálne množstvo potrebných zásahov.
Pri rozširovaní pomôže okrem komentovaných zdrojových kódov priložených
k práci aj popis použitých technológií a samotnej implementácie uvádzaný
v piatej kapitole. Prístupnosť nášho klienta, ktorá je vzhľadom na cieľovú
skupinu používateľov veľmi dôležitá, sa prejavuje aplikovaním pravidiel prístupného webu, ktoré boli rozoberané v druhej kapitole práce. Výslednému
produktu by určite prospelo, ak by bol poskytnutý priestor na otestovanie prístupnosti aplikácie priamo nevidiacimi používateľmi v Stredisku pre pomoc
študentom so špecifickými nárokmi Teiresiás.
49
literatúra
[1] GAMMA, Erich., HELM, Richard., JOHNSON, Ralph., VLISSIDES,
John. Design Patterns: Elements of Reusable Object-Oriented Software.
Reading, USA: Addison-Wesley, 1995. 386 s. ISBN 0-201-63361-2. 2, 24,
25, 26, 40
[2] GAMMA, Erich., et al. Návrh programů pomocí vzorů: Stavební kameny
objektově orientovaných programů. Přeložil MAKOVEC, Pavel. Praha,
CZ: Grada, 2003. 280 s. ISBN 80-247-0302-5. 25, 26
[3] FREEMAN, Eric., FREEMAN, Elisabeth., SIERRA, Kathy., BATES,
Bert. Head First Design Patterns. Sebastopol, USA: O’Reilly Media, 2004.
678 s. ISBN 978-0-596-00712-6. 24
[4] KOPEČEK, Ivan., OŠLEJŠEK, Radek. Creating Pictures by Dialogue. In
Computers Helping People with Special Needs: 10th International Conference, ICCHP 2006. Berlin, Heidelberg, DE: Springer-Verlag, 2006. str.
61-68, 8 s. ISBN 3-540-36020-4. 12
[5] KOPEČEK, Ivan., OŠLEJŠEK, Radek. Dialogue-Based Processing of
Graphics and Graphical Ontologies. In Text, Speech and Dialogue. Proceedings of 11th International Conference. Berlin, Heidelberg, DE: SpringerVerlag, 2008. str. 601-608, 8 s. ISBN 978-3-540-87390-7. 11, 13, 18, 22
[6] KOPEČEK, Ivan., OŠLEJŠEK, Radek. GATE to Accessibility of Computer Graphics. In Computers Helping People with Special Needs: 11th
International Conference, ICCHP 2008. Berlin, Heidelberg, DE: SpringerVerlag, 2008. str. 295-302, 8 s. ISBN 978-3-540-70539-0. 11, 13, 18, 19,
20, 21, 22
[7] KOPEČEK, Ivan., OŠLEJŠEK, Radek. Annotating and Describing Pictures – Applications in E-Learning and Accessibility of Graphics. In Computers Helping People with Special Needs: 12th International Conference,
ICCHP 2010. Berlin, Heidelberg, DE: Springer-Verlag, 2010. str. 124-130,
7 s. ISBN 978-3-642-14096-9. 15, 22
50
[8] KOPEČEK, Ivan., OŠLEJŠEK, Radek. Communicative Images. In
Smart Graphics, 11th International Symposium. Berlin, Heidelberg, DE:
Springer-Verlag, 2011. str. 163-173, 11 s. ISBN 978-3-642-22570-3. 11, 20,
23
[9] ŠPINAR, David. Tvoříme přístupné webové stránky. Brno, CZ: Zoner
Press, 2004. 360 s. ISBN 80-86815-11-0. 8
[10] HOEKSTRA, Rinke. Ontology Representation: Design Patterns and Ontologies That Make Sense. Amsterdam, NL: IOS Press, 2009. 236 s. ISBN
978-1-60750-013-1. 24
[11] GEARY, David M. Core JSTL: Mastering the JSP Standard Tag Library.
Prentice Hall, 2002. 608 s. ISBN 978-0131001534. 41
[12] SIKORA, Michael. EJB 3 Developer Guide. Birmingham, UK: Packt Publishing, 2008. 276 s. ISBN 978-1-847195-60-9. 43, 45
[13] RÁČEK, Jaroslav., SOCHOR, Jiří. Vedení týmového projektu. Úvod do
projektového řízení, plánování projektu [online]. Brno, CZ: Fakulta informatiky Masarykovy univerzity, 2013 [cit. 16. mája 2011]. Dostupné po autentizácii na: <https://is.muni.cz/auth/el/1433/jaro2013/PA104/
um/39022855/tp_01_uvod_a_planovani.pdf>. 34
[14] World Health Organization. World Report on Disability – Summary [online]. Geneva, CH: WHO, 2011 [cit. 10. apríla 2013]. Dostupné na: <http:
//whqlibdoc.who.int/hq/2011/WHO_NMH_VIP_11.01_eng.pdf>. 3
[15] Laboratoř vyhledávání a dialogu. GATE project – Graphics Accessible
to Everyone [online]. Brno, CZ: Fakulta informatiky Masarykovy univerzity, 2013 [cit. 21. apríla 2013]. Dostupné na: <http://lsd.fi.muni.cz/
gate/>. 1, 12, 39
[16] ŠIMŠÍK, Dušan., GALAJDOVÁ, Alena., DOLNÁ, Zlatica. Advances in
Electrical and Electronic Engineering. Podporné technológie pre komunikáciu a informácie [online]. Košice, SK: Technická univerzita, 2005 [cit.
22. apríla 2013]. Dostupné na: <http://dspace.vsb.cz/bitstream/
handle/10084/83698/AEEE-2005-4-4-220-simsik.pdf>. 3
[17] Web Design and Applications. Accessibility [online]. Spracovali HENRY,
Shawn Lawton., MCGEE, Liam. World Wide Web Consortium, 2013
[cit. 22. apríla 2013]. Dostupné na: <http://www.w3.org/standards/
webdesign/accessibility>. 3, 4
51
[18] Web Content Accessibility Guidelines (WCAG) 2.0 [online]. Spracovali
CALDWELL, Ben., COOPER, Michael., REID, Loretta Guarino., VANDERHEIDEN, Gregg. World Wide Web Consortium, 11. decembra 2008
[cit. 22. apríla 2013]. Dostupné na: <http://www.w3.org/TR/WCAG/>. 4
[19] Understanding WCAG 2.0 [online]. Spracovali COOPER, Michael.,
REID, Loretta Guarino., VANDERHEIDEN, Gregg. World Wide Web
Consortium, 3. januára 2012 [cit. 22. apríla 2013]. Dostupné na: <http:
//www.w3.org/TR/UNDERSTANDING-WCAG20/>. 4
[20] Blind Friendly Web. Metodiky [online]. TyfloCentrum Brno a SONS ČR,
2013 [cit. 22. apríla 2013]. Dostupné na: <http://blindfriendly.cz/
metodiky>. 4
[21] Blind Friendly Web. Metodika Blind Friendly Web 2.3 [online]. PAVLÍČEK, Radek. TyfloCentrum Brno a SONS ČR, 31. marca 2005 [cit. 25.
apríla 2013]. Dostupné na: <http://blindfriendly.cz/metodika>. 7
[22] Přístupnost. Pravidla tvorby přístupného webu [online]. ŠPINAR, David.
2013 [cit. 28. apríla 2013]. Dostupné na: <http://pristupnost.nawebu.
cz/texty/pravidla-standardy.php>. 7
[23] Blind Friendly Web. Blind Friendly Web pravidlá [online]. Únia nevidiacich a slabozrakých Slovenska, 2012 [cit. 28. apríla 2013]. Dostupné na: <http://blindfriendly.unss.sk/blind-friendly-webnavod.php>. 7
[24] Zrakové postihnutie. Sociálna rehabilitácia zrakovo postihnutých
[online]. HÓKOVÁ, Timea. Národná rada občanov so zdravotným postihnutím v SR, 2013 [cit. 26. apríla 2013]. Dostupné na:
<http://www.nrozp.sk/index.php/soc-rehabilitacia/zrakovopostihnuti/88-socialna-rehabilitacia-zrakovo-postihnutych>.
8, 9
[25] Človek so zrakovým postihnutím. Zrakové postihnutie a jeho diferenciácia [online]. Opora s.r.o., 2012 [cit. 26. apríla 2013]. Dostupné na: <http://www.opora.sk/stranka/zrakove-postihnutiejeho-diferenciacia>. 8
[26] IKT vo vzdelávaní zdravotne postihnutých. Zrakovo postihnutí a ich spôsob vnímania sveta [online]. JAŠKOVÁ, Ľudmila. Fakulta matematiky, fyziky a informatiky, Univerzita Komenského v Bratislave, 2013 [cit. 28. ap52
ríla 2013]. Dostupné na: <http://edi.fmph.uniba.sk/~jaskova/IKTH/
tema02/tema02.html>. 9, 10
[27] Scalable Vector Graphics (SVG) 1.1 (Second Edition) [online]. Spracoval DAHLSTRÖM, Erik., et al. World Wide Web Consortium, 16. augusta 2011 [cit. 9. mája 2013]. Dostupné na: <http://www.w3.org/TR/
SVG11/>. 14
[28] TIŠNOVSKÝ, Pavel. Vektorový grafický formát SVG [online]. Root.cz, 2.
augusta 2007 [cit. 9. mája 2013]. Dostupné na: <http://www.root.cz/
clanky/vektorovy-graficky-format-svg/>. 14
[29] Support tables for HTML5, CSS3, etc. [online]. Spracoval DEVERIA,
Alexis. Can I use. . . , 2013 [cit. 9. mája 2013]. Dostupné na: <http:
//caniuse.com/#cats=SVG>. 14
[30] GRUBER, Thomas R. A Translation Approach to Portable Ontology Specifications [online]. In Knowledge Acquisition, Volume 5 Issue 2. London, UK: Academic Press, 1993 [cit. 4. mája 2013]. Dostupné na: <http:
//tomgruber.org/writing/ontolingua-kaj-1993.pdf>. 15
[31] OWL Web Ontology Language Overview [online]. Spracovali MCGUINNESS, Deborah L., VAN HARMELEN, Frank. World Wide Web Consortium, 10. februára 2004 [cit. 6. mája 2013]. Dostupné na: <http:
//www.w3.org/TR/owl-features/>. 16
[32] Resource Description Framework (RDF): Concepts and Abstract Syntax
[online]. Spracovali KLYNE, Graham., CARROLL, Jeremy J. World Wide
Web Consortium, 10. februára 2004 [cit. 6. mája 2013]. Dostupné na:
<http://www.w3.org/TR/rdf-concepts/>. 16
[33] Welcome to Protégé [online]. Stanford Center for Biomedical Informatics
Research, 2013 [cit. 12. mája 2013]. Dostupné na: <http://protege.
stanford.edu/>. 30
[34] Balsamiq Mockups [online]. Balsamiq Studios, 2013 [cit. 16. mája 2013].
Dostupné na: <http://www.balsamiq.com/>. 35
[35] Web authoring and surfing. Using accesskey attribute in HTML forms
and links [online]. Spracoval KORPELA, Jukka. Tampere, FI: Tampere
University of Techlonogy, 8. mája 2006 [cit. 17. mája 2013]. Dostupné na:
<http://www.cs.tut.fi/~jkorpela/forms/accesskey.html>. 37
53
[36] SVG Tutorial. SVG in HTML Pages [online]. W3Schools, 2013 [cit.
17. mája 2013]. Dostupné na: <http://www.w3schools.com/svg/svg_
inhtml.asp>. 38
[37] Web Design / HTML. Adding SVG to HTML [online]. Spracovala KYRNIN, Jennifer. About.com, 2013 [cit. 17. mája 2013]. Dostupné na: <http://webdesign.about.com/od/svg/qt/add-svg-tohtml.htm>. 38
[38] Stripes Framework [online]. Spracoval HINKLE, Greg., GUNTER, Ben.
Atlassian Confluence, 18. mája 2012 [cit. 19. mája 2013]. Dostupné na:
<http://www.stripesframework.org/display/stripes/Home>. 42
[39] Wiki FI MUNI. Kategorie: Java EE [online]. Fakulta informatiky Masarykovy univerzity, 2013 [cit. 18. mája 2013]. Dostupné na: <http:
//kore.fi.muni.cz/wiki/index.php/Kategorie:Java_EE>. 41, 42, 43
54
zoznam obrázkov
3.1
3.2
Porovnanie grafickej a logickej hierarchie objektov . . . . . . .
Fotografia s označením podľa sémantických úrovní a hĺbky . .
19
22
4.1
Vektorové tvary UML notácie diagramu tried . . . . . . . . . .
28
5.1
5.2
Náčrt používateľského rozhrania webovej aplikácie . . . . . . .
Zjednodušený diagram nasadenia aplikácie DEPAD . . . . . .
35
39
A.1
A.2
A.3
A.4
A.5
A.6
A.7
A.8
A.9
Diagram
Diagram
Diagram
Diagram
Diagram
Diagram
Diagram
Diagram
Diagram
.
.
.
.
.
.
.
.
.
57
57
58
58
58
59
59
60
60
. . . .
61
tried
tried
tried
tried
tried
tried
tried
tried
tried
návrhového
návrhového
návrhového
návrhového
návrhového
návrhového
návrhového
návrhového
návrhového
vzoru
vzoru
vzoru
vzoru
vzoru
vzoru
vzoru
vzoru
vzoru
Abstraktná továreň
Staviteľ . . . . . . .
Triedny adaptér . .
Objektový adaptér .
Most . . . . . . . .
Skladba . . . . . . .
Dekorátor . . . . . .
Reťaz zodpovednosti
Príkaz . . . . . . . .
B.1 Snímka z webovej aplikácie Design Patterns by Dialog
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
55
zoznam zdrojových kódov
3.1
3.2
Príklad ontológie v jazyku OWL . . . . . . . . . . . . . . . . .
Zdrojový kód anotovaného SVG obrázka . . . . . . . . . . . .
17
20
4.1
Ukážka SVG dokumentu Reťaze zodpovednosti . . . . . . . .
31
5.1
5.2
Príklad triedy rozširujúcej DefaultLocalePicker zo Stripes API
Nastavenie lokalizácie pomocou JSTL . . . . . . . . . . . . . .
46
47
56
príloha A
UML diagramy návrhových vzorov
Obr. A.1: Diagram tried návrhového vzoru Abstraktná továreň.
Obr. A.2: Diagram tried návrhového vzoru Staviteľ.
57
Obr. A.3: Diagram tried návrhového vzoru Triedny adaptér.
Obr. A.4: Diagram tried návrhového vzoru Objektový adaptér.
Obr. A.5: Diagram tried návrhového vzoru Most.
58
Obr. A.6: Diagram tried návrhového vzoru Skladba.
Obr. A.7: Diagram tried návrhového vzoru Dekorátor.
59
Obr. A.8: Diagram tried návrhového vzoru Reťaz zodpovednosti.
Obr. A.9: Diagram tried návrhového vzoru Príkaz.
60
príloha B
snímka z webovej aplikácie
Obr. B.1: Snímka z webovej aplikácie Design Patterns by Dialog.
61
príloha C
obsah priloženého média
˓→ Zdrojové súbory tejto práce v typografickom systéme LATEX.
˓→ Výsledná práca vo formáte PDF.
˓→ Zdrojové súbory webovej aplikácie v jazyku Java ako projekt typu Maven
vrátane knižníc, štýlu CSS a použitých obrázkov.
˓→ Anotované SVG obrázky UML diagramov tried vybraných návrhových
vzorov a ich príkladov použitia.
62
Download

E-learningová aplikácia na výučbu návrhových vzorov