}w!"#$%&'()+,-./012345<ya

Transcription

1 Masarykova univerzita Fakulta informatiky }w!"#$%&'()+,-./012345<ya e-learningová aplikácia na výučbu návrhových vzorov Diplomová práca Bc. Branislav Paulis Brno, jar 2013

2 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

3 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

4 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

5 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

6 obsah 1 Úvod Prístupnosť informačných technológií Pravidlá prístupného webu Podpora nevidiacich používateľov Počítačová grafika založená na dialógu Projekt GATE Vektorový formát SVG Ontológia a jazyk OWL Anotovanie spojením ontológie s SVG Anotácia rastrového obrazu a fotografie Využitie komunikatívnych obrázkov v e-learningu Tvorba diagramov návrhových vzorov Návrhové vzory Gang of Four Tvorba grafiky UML diagramov Anotácie návrhových vzorov Komunikácia s obrázkami návrhových vzorov Webová aplikácia na výučbu návrhových vzorov Návrh aplikácie Používateľská prístupnosť Technológie a implementácia Lokalizácia aplikácie 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 vi

7 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ú gra- 1

8 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

9 kapitola 2 prístupnosť informačných technológií 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. Tim Berners-Lee, riaditeľ W3C [17] 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í dosaho- 3

10 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

11 2. Prístupnosť informačných technológií CAPTCHA 1 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 úp- 1. 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

12 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

13 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 agentov 2 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

14 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

15 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ť hy- 9

16 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

17 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

18 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 och. 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 študentov 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

19 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 vykonať dosiahnuť 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 W Jeho základom je práca s vektoro- 13

20 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

21 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 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 UML 1 a návrhových vzorov. Návrhové vzory budú podrobnejšie rozoberané v kapitole 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

22 Web Ontology Language 3. Počítačová grafika založená na dialógu Z definície ontológie vyplýva, že je možné ju reprezentovať formálnymi jazykmi. Konzorcium W3 2.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 po- 16

23 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 > < owl:datatypeproperty rdf:id =" age "> < rdfs: range rdf:resource =" http: // /2001/ XMLSchema # integer "/> < rdfs:domain rdf:resource ="# Person "/> </ owl: DatatypeProperty > < owl:objectproperty rdf:id =" isteaching "> < rdfs:range rdf:resource ="# Student "/> < rdfs:domain rdf:resource ="# Teacher "/> </ owl: ObjectProperty > < owl:objectproperty rdf:id =" istaught "> < owl:inverseof rdf:resource ="# isteaching "/> </ owl: ObjectProperty > < 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

24 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

25 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 do- 19

26 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=" GATE_ANNOTATION_METADATA "> < 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=" GATE_GRAPHICAL_CONTENT ">.. 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

27 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 WWL 3.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

28 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

29 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

30 kapitola 4 tvorba diagramov návrhových vzorov 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. venovanie autorov Head First Design Patterns [3] 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

31 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ógie 3.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

32 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

33 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

34 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

35 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.owl 1 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.owl 2. Tu môžeme vidieť základné entity používajúce sa pri návrhu objektovo orientovaných systémov, 1. Dostupné na: < 2. Dostupné na: < 29

36 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

37 4. Tvorba diagramov návrhových vzorov <svg xmlns =" http: // /2000/ svg " x="0" y="0" width =" 800 " height =" 500 " preserveaspectratio =" xminymin meet " viewbox =" " > < metadata id="gate_annotation_metadata" > < rdf:rdf xmlns:rdf =" http: // www. w3. org /1999/02/22 -rdf-syntax-ns #" xmlns:rdfs =" http: // /2000/01/ rdf-schema #" xmlns:owl =" http: // /2002/07/ owl #" xmlns:xsd =" http: // /2001/ XMLSchema #" xmlns:uml =" http: // lsd.fi. muni.cz/ gate / ontologies / UML. owl #" xmlns:dp =" http: // lsd.fi. muni.cz/ gate / ontologies / DesignPatterns. owl #"> < owl:namedindividual 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 Responsibility Design Pattern UML Class Diagram. </ rdfs:comment > </ owl:namedindividual > < owl:namedindividual rdf:about ="handlerclass" > < rdf:type rdf:resource =" http: // lsd.fi. muni.cz/ gate / ontologies / DesignPatterns. owl # HandlerClass "/> < dp:isparticipantof rdf:resource =" http: // lsd. fi. muni. cz/ gate / ontologies / DesignPattern. owl # chainofresponsibility "/ > < uml:classifiername rdf:datatype =" xsd:string " > Handler </ uml:classifiername > < uml:isabstractclass rdf:datatype =" xsd:boolean " >true </ uml:isabstractclass > < uml:isparrent rdf:resource =" concretehandler1class "/ > < uml:isparrent rdf:resource =" concretehandler2class "/ > < dp:calls rdf:resource =" handlerclass "/ > < uml:hasattribute rdf:resource =" successorattribute "/ > < uml:hasoperation rdf:resource =" abstracthandlerequestmethod "/ > </ owl:namedindividual > < owl:namedindividual rdf:about ="successorattribute" > < rdf:type rdf:resource =" http: // lsd.fi. muni.cz/ gate / ontologies / UML. owl # Attribute "/> < uml:attributename rdf:datatype =" xsd:string " > successor </ uml:attributename > </ owl:namedindividual > </ 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 (# gradabstracthead ); stroke-width:2 ; stroke:black " x="0" y="0" width =" 150 " height ="25"/> <rect style =" fill:url (# gradabstractbody ); stroke-width:2 ; stroke:black " x="0" y="25" width =" 150 " height ="25"/> <rect style =" fill:url (# gradabstractbody ); stroke-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 ; stroke-width: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

38 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 WWL 3.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

39 Príklad dialógu s Reťazou zodpovednosti: 4. Tvorba diagramov návrhových vzorov : : : : : : : : : : : : : : : : : : 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 Concrete- Handler2. 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

40 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é ciele 3.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

41 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 pra- 35

42 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

43 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 vy- 37

44 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

45 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

46 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

47 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 ap- 41

48 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

49 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 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á 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é a jeho metódy sú počas behu volané v jednom Java Virtual Machine. Vzdialené 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

50 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

51 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 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.xml 5.3, ktoré sa nastavujú pomocou parametra LocalePicker.Locales. Predstavme si teraz dva spôsoby, ako môžeme postupovať ďalej. Buď pomocou Stripes, ktorý po- 45

52 5. Webová aplikácia na výučbu návrhových vzorov skytuje tzv. extensions slúžiace na tvorbu vlastných interceptorov 1, 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 CustomLocalePicker extends DefaultLocalePicker { } private static final String locale = " lang public Locale picklocale ( HttpServletRequest 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

53 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

54 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

55 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

56 literatúra [1] GAMMA, Erich., HELM, Richard., JOHNSON, Ralph., VLISSIDES, John. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, USA: Addison-Wesley, s. ISBN , 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, s. ISBN , 26 [3] FREEMAN, Eric., FREEMAN, Elisabeth., SIERRA, Kathy., BATES, Bert. Head First Design Patterns. Sebastopol, USA: O Reilly Media, s. ISBN [4] KOPEČEK, Ivan., OŠLEJŠEK, Radek. Creating Pictures by Dialogue. In Computers Helping People with Special Needs: 10th International Conference, ICCHP Berlin, Heidelberg, DE: Springer-Verlag, str , 8 s. ISBN [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: Springer- Verlag, str , 8 s. ISBN , 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 Berlin, Heidelberg, DE: Springer- Verlag, str , 8 s. ISBN , 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 Berlin, Heidelberg, DE: Springer-Verlag, str , 7 s. ISBN , 22 50

57 [8] KOPEČEK, Ivan., OŠLEJŠEK, Radek. Communicative Images. In Smart Graphics, 11th International Symposium. Berlin, Heidelberg, DE: Springer-Verlag, str , 11 s. ISBN , 20, 23 [9] ŠPINAR, David. Tvoříme přístupné webové stránky. Brno, CZ: Zoner Press, s. ISBN [10] HOEKSTRA, Rinke. Ontology Representation: Design Patterns and Ontologies That Make Sense. Amsterdam, NL: IOS Press, s. ISBN [11] GEARY, David M. Core JSTL: Mastering the JSP Standard Tag Library. Prentice Hall, s. ISBN [12] SIKORA, Michael. EJB 3 Developer Guide. Birmingham, UK: Packt Publishing, s. ISBN , 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: < um/ /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: < 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: < handle/10084/83698/aeee 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: < webdesign/accessibility>. 3, 4 51

58 [18] Web Content Accessibility Guidelines (WCAG) 2.0 [online]. Spracovali CALDWELL, Ben., COOPER, Michael., REID, Loretta Guarino., VAN- DERHEIDEN, Gregg. World Wide Web Consortium, 11. decembra 2008 [cit. 22. apríla 2013]. Dostupné na: < 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: // 4 [20] Blind Friendly Web. Metodiky [online]. TyfloCentrum Brno a SONS ČR, 2013 [cit. 22. apríla 2013]. Dostupné na: < 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: < 7 [22] Přístupnost. Pravidla tvorby přístupného webu [online]. ŠPINAR, David [cit. 28. apríla 2013]. Dostupné na: < 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: < 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: < 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: < 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. ap- 52

59 ríla 2013]. Dostupné na: < 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: < SVG11/>. 14 [28] TIŠNOVSKÝ, Pavel. Vektorový grafický formát SVG [online]. Root.cz, 2. augusta 2007 [cit. 9. mája 2013]. Dostupné na: < 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 MCGUIN- NESS, Deborah L., VAN HARMELEN, Frank. World Wide Web Consortium, 10. februára 2004 [cit. 6. mája 2013]. Dostupné na: <http: // 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: < 16 [33] Welcome to Protégé [online]. Stanford Center for Biomedical Informatics Research, 2013 [cit. 12. mája 2013]. Dostupné na: < stanford.edu/>. 30 [34] Balsamiq Mockups [online]. Balsamiq Studios, 2013 [cit. 16. mája 2013]. Dostupné na: < 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: <

60 [36] SVG Tutorial. SVG in HTML Pages [online]. W3Schools, 2013 [cit. 17. mája 2013]. Dostupné na: < 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: < 38 [38] Stripes Framework [online]. Spracoval HINKLE, Greg., GUNTER, Ben. Atlassian Confluence, 18. mája 2012 [cit. 19. mája 2013]. Dostupné na: < 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

61 zoznam obrázkov 3.1 Porovnanie grafickej a logickej hierarchie objektov Fotografia s označením podľa sémantických úrovní a hĺbky Vektorové tvary UML notácie diagramu tried Náčrt používateľského rozhrania webovej aplikácie Zjednodušený diagram nasadenia aplikácie DEPAD A.1 Diagram tried návrhového vzoru Abstraktná továreň A.2 Diagram tried návrhového vzoru Staviteľ A.3 Diagram tried návrhového vzoru Triedny adaptér A.4 Diagram tried návrhového vzoru Objektový adaptér A.5 Diagram tried návrhového vzoru Most A.6 Diagram tried návrhového vzoru Skladba A.7 Diagram tried návrhového vzoru Dekorátor A.8 Diagram tried návrhového vzoru Reťaz zodpovednosti A.9 Diagram tried návrhového vzoru Príkaz B.1 Snímka z webovej aplikácie Design Patterns by Dialog

62 zoznam zdrojových kódov 3.1 Príklad ontológie v jazyku OWL Zdrojový kód anotovaného SVG obrázka Ukážka SVG dokumentu Reťaze zodpovednosti Príklad triedy rozširujúcej DefaultLocalePicker zo Stripes API Nastavenie lokalizácie pomocou JSTL

63 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

64 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

65 Obr. A.6: Diagram tried návrhového vzoru Skladba. Obr. A.7: Diagram tried návrhového vzoru Dekorátor. 59

66 Obr. A.8: Diagram tried návrhového vzoru Reťaz zodpovednosti. Obr. A.9: Diagram tried návrhového vzoru Príkaz. 60

67 príloha B snímka z webovej aplikácie Obr. B.1: Snímka z webovej aplikácie Design Patterns by Dialog. 61