VÝUKOVÁ STRATEGICKÁ HRA PRO ZRAKOVĚ POSTIŽENÉ

České vysoké učení technické v Praze FAKULTA ELEKTROTECHNICKÁ Katedra počítačové grafiky a interakce

VÝUKOVÁ STRATEGICKÁ HRA PRO ZRAKOVĚ POSTIŽENÉ Bakalářská práce

Autor práce: Markéta Jurášková, DiS. Vedoucí bakalářské práce: Mgr. Ing. David Vít

Studijní program: Softwarové technologie a management Obor: Web a multimédia Rok odevzdání práce: 2010

Anotace Tato bakalářská práce je zaměřena na návrh strategické výukové hry určené pro zrakově postižené. Rozlišuje druhy zrakového postižení s ohledem na možnost využití počítače v osobním životě a na požadavky uživatelského rozhraní. Obsahuje detailní analýzu hry, její implementaci v jazyce Java s využitím technologií AWT, Java Media Framework a XML, včetně usability testování se zástupkyní cílové skupiny a jeho zhodnocení s ohledem na přístupnost. Aplikace je navržena tak, aby spolupracovala s odečítačem ZoomText 9.1. Hlavním přínosem práce je zhodnocení použitelnosti programovacího jazyka Java pro vytváření aplikací pro hlasově postižené.

Annotation This bachelor thesis is focused on a teaching strategy game for visually impaired design. It distinguishes visual handicaps with relation to a computer usage in a personal life and user interface requirements. It contains a detailed game analysis, its Java language implementation, utilizing AWT, Java Media Framework and XML technologies, including an usability testing with a target group representative and its evaluation with regards to an accessibility issues. Application is designed to cooperate with ZoomText 9.1 screen reader. The empirical Java language applicability for accessible application development judgement represents the main contribution of this work.

Poděkování Chtěla bych tímto poděkovat panu Mgr. Ing. Davidu Vítovi za vedení bakalářské práce a mnoho podnětných připomínek při jejím zpracování. Dále pak Ing. Václavu Chalupníčkovi za pomoc s analýzou a softwarovým návrhem. A v neposlední řadě bych chtěla poděkovat Miluši Juráškové, jakožto zástupci cílové skupiny za ochotné konzultování, testování a pomoc při rozvoji bakalářské práce. Poděkování též náleží mému partnerovi především za trpělivost a kamarádům za konzultace matematických výpočtů, strategie hry a její testování.

Prohlášení Prohlašuji, že jsem tuto bakalářskou práci vypracovala samostatně a použité podklady řádně uvedla v přiloženém seznamu. Při vypracování práce byly využity příslušné softwarové produkty v souladu s licenčními podmínkami výrobce. Nemám závažný důvod proti dalšímu využití tohoto v akademickém prostředí ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Kladně dne 21.5.2010

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

Obsah

Obsah Obsah Obsah ............................................................................................................................................ 1 1.

Úvod ...................................................................................................................................... 4

1.1. Poslání bakalářské práce ........................................................................................................ 4 2.

Analýza cílové skupiny........................................................................................................... 5

2.1. Kompenzační pomůcky .......................................................................................................... 7 2.1.1. Hlasový výstup (Odečítač obrazovky) ................................................................................. 7 2.1.2. Hmatový výstup (Braillský řádek)........................................................................................ 8 2.1.3. Zvětšovací programy ........................................................................................................... 9 2.2. Potřeby uživatele ................................................................................................................. 10 3.

Identifikace klíčových požadavků a omezení ...................................................................... 10

3.1. Požadavky............................................................................................................................. 10 3.2. Omezení ............................................................................................................................... 12 4.

Vize hry ................................................................................................................................ 12

4.1. Strategie obecně .................................................................................................................. 12 4.2. Módy hry .............................................................................................................................. 13 4.3. Herní detaily ......................................................................................................................... 13 4.4. Databáze .............................................................................................................................. 14 4.5. Náhodné události a podmíněné události ............................................................................. 14 4.6. Uchování informací o stavu hry a aplikace .......................................................................... 14 4.7. Možnosti dalšího rozšíření ................................................................................................... 15 5.

Softwarová analýza ............................................................................................................. 15

5.1. Use Case ............................................................................................................................... 16 5.1.1. Seznam a popis účastníků (actors) .................................................................................... 17 5.1.2. Ostatní diagramy Use Case ............................................................................................... 17 5.1.3. Příklady scénářů případů užití ........................................................................................... 18 5.2. Activity diagram ................................................................................................................... 19 5.3. State transition diagram....................................................................................................... 20 5.4. Class Diagram ....................................................................................................................... 21 5.4.1. Popis tříd ........................................................................................................................... 22 5.5. Sequence diagram ................................................................................................................ 23 1

Obsah 5.6. Plán projektu ........................................................................................................................ 24 6.

Návrh uživatelského rozhraní.............................................................................................. 24

7.

Implementace ..................................................................................................................... 25

7.1. Tvorba uživatelského rozhraní ............................................................................................. 27 7.1.1. Tvorba chybějících komponent ......................................................................................... 29 7.2. XML DATA............................................................................................................................. 33 7.2.1. SAX .................................................................................................................................... 34 7.2.2. DOM .................................................................................................................................. 34 7.2.3. Zpracování XML ................................................................................................................. 34 7.2.3.1. Načítání .......................................................................................................................... 34 7.2.3.2. Ukládání ......................................................................................................................... 35 7.2.3.3. Typy vytvořených XML dokumentů ............................................................................... 35 7.3. Zvukové knihovny................................................................................................................. 38 7.3.1. Java sound API................................................................................................................... 38 7.3.2. JMF (Java Media Framework) ........................................................................................... 39 7.3.3. Výběr technologie ............................................................................................................. 39 7.4. Výkonné jádro ...................................................................................................................... 39 7.5. Matematický model ............................................................................................................. 40 8.

Usability testování ............................................................................................................... 42

8.1. Usability testování s koncovým uživatelem ......................................................................... 42 8.1.1. Prostředky a cíle ................................................................................................................ 42 8.1.2. Testování ........................................................................................................................... 43 8.1.3. Závěr.................................................................................................................................. 47 8.2. Usability testování se zástupcem bez hendikepu ................................................................ 48 8.2.1. Prostředky a cíle ................................................................................................................ 48 8.2.2. Testování ........................................................................................................................... 48 8.2.3. Závěr.................................................................................................................................. 48 9. 10.

JUnit testování..................................................................................................................... 48 Závěr................................................................................................................................ 49

10.1. Téma a rozsah práce .......................................................................................................... 50 10.2. Zhodnocení přístupnosti .................................................................................................... 51 10.3. Praktické využití aplikace ................................................................................................... 51 Použitá literatura......................................................................................................................... 53 Použité zdroje.............................................................................................................................. 54 2

Obsah Seznam obrázků .......................................................................................................................... 56 Seznam příloh.............................................................................................................................. 57 Příloha 1 – Instalační návod Zoozoom ........................................................................................ 58 Příloha 2 - Use Case UC1 Ovládání otevírací doby ...................................................................... 59 Příloha 3 – Use Case UC2 Procházka po zoo ............................................................................... 60 Příloha 4 – Use Case UC3 Správa krmiva..................................................................................... 61 Příloha 5 – Use Case UC4 Správa objektů ................................................................................... 61 Příloha 6 – Use Case UC5 Správa zvířat ....................................................................................... 62 Příloha 7 – Use Case UC6 Vkládání dat ....................................................................................... 63 Příloha 8 – Use Case UC7 Řešení kvízů........................................................................................ 64 Příloha 9 – Konfigurační DTD Zoo – base .................................................................................... 65 Příloha 10 – XML dokument Zoo databáze ................................................................................. 66 Příloha 11 – Konfigurační DTD Zoo – save .................................................................................. 67 Příloha 12 – XML dokument Záloha hry ...................................................................................... 68 Příloha 13 – Konfigurační DTD Zoo – config................................................................................ 69 Příloha 14 – XML dokument Zoo konfigurace ............................................................................. 69 Příloha 15 – Obsah souborů na přiloženém CD .......................................................................... 70

3

Úvod

1. Úvod V současné době je počítač nezbytným pomocníkem v každé domácnosti a to zrakově postižených nevyjímaje. Zrakově postižení jsou však zvláštní cílová skupina se speciálními požadavky na softwarové i hardwarové produkty. Vzhledem k svému hendikepu nemohou počítač ovládat jako běžný uživatel zrakem a myší, proto byly pro ně vytvořeny speciální programy, které z obrazovky předčítají text, pozici, ovládací prvky a všechny další dostupné textové informace. Tyto programy se nazývají odečítače. Nicméně samotné odečítače přístupnost počítače této skupině zcela zajistit nedokážou. Dalším dílem přispívají tzv. softwarové zvětšovače. Jejich úlohou je zvětšit dle požadavků obrazovku, aby osoba se zrakovým postižením mohla případně použít myš, či si prohlédla, co se na obrazovce ve skutečnosti děje. Zástupcem hardwarových pomůcek zaměřeným na hmat postiženého je braillský řádek, který hmatově zprostředkovává dění na obrazovce. Právě díky zmíněnému speciálnímu softwaru a hardwaru, může zrakově postižený obsluhovat zařízení jako běžný uživatel, avšak stále existují mezery v úplné přístupnosti počítačového světa této skupině.

1.1. Poslání bakalářské práce Cílem bakalářské práce je vytvoření strategicko-výukové hry přizpůsobené náročným požadavkům zrakově postižených a výše uvedeným kompenzačním pomůckám. Bohužel, stále ještě ne všichni tvůrci programů a především webových stránek vycházejí těmto postiženým vstříc. Velikou mezeru tak mohou zrakově postižení pocítit zvláště v oblasti zábavy, kde si běžný uživatel vybírá ze širokého sortimentu stále více graficky náročnějších her. Posláním hry, vytvářené v rámci bakalářské práce, která byla nazvána ZooZoom, je tedy otestovat zda vůbec se zvolenými prostředky lze zmíněnou hru vytvořit, a jakým způsobem lze překlenout mezeru a poskytnout zrakově postiženým nejen představu o kráse zvířecího světa v zoologické zahradě, ale i zábavnou formou informovat o vybraných druzích, o jejich způsobu života, výskytu v přírodě apod.

4

Analýza cílové skupiny

2. Analýza cílové skupiny Z výše uvedených informací tedy vyplývá, že uživatelé budou lidé (mohou být všech generací) se zrakovým postižením, mající doma ozvučený počítač jako pomůcku ke svému každodennímu životu.

Zrakově postižené lze rozdělit do tří skupin dle druhu postižení.

a) Nevidomí a těžce zrakově postižení Jedná se o osoby s úplnou ztrátou zraku a osoby se zbytky zraku, které však nejsou dostačující pro orientaci, ovládání a práci s počítačem.

b) Osoby se závažnějšími vadami zraku Tato skupina zdravotně postižených je poměrně rozsáhlá. Naštěstí, ačkoliv trpí určitou poruchou vidění, o zrak úplně nepřišli. Jedná se však o závažné poruchy zraku, které nedokážou být kompenzovány brýlemi, či kontaktními čočkami, a tak zasahují do každodenních činností, jako je nakupování, čtení a v neposlední řadě i využívání počítače. Mezi zrakové vady v této kategorii patří: 

diabetická retinopatie (tmavá místa „výpadky“ v zorném poli),



dva typy zákalů, a to šedý zákal (má za následek rozmazaný až mlhavý efekt, pohled skrz špinavé okno) a zelený zákal (ztráta periferního vidění – trubicové vidění),



nebo degenerace sítnice (zastření centrálního pohledu – jedná se o opak trubicového vidění).

Tyto vady jsou obvyklejší spíše u starších lidí, nicméně postihují jedince jakéhokoliv věku. Mohou být zapříčiněny traumatickým zraněním, geneticky, či nemocí. Dnešní lékařská péče je však na tak vysoké úrovni, že lze operativně některým jedincům pomoci.

5


c) Uživatelé s poruchami barvocitu Třetí a poslední skupinou jsou takzvaní „barvoslepí“. Poruchy spojené se zhoršenou schopností vnímat barvy patří k nejčastějším. Takovouto vadou trpí přibližně 8,5% populace (8 % muži; 0,5 % ženy). Úplná ztráta vnímání barev je velmi vzácná, zato lehčí formy této vady, které se projevují zhoršeným vnímáním jen určitých barev, jsou zcela běžné. Normální stav rozeznávání tří barevných složek se nazývá trichromazie a znamená, že se v oku nacházejí tři skupiny sítnicových čípků s pigmenty reagujícími na červenou, zelenou a modrou barvu. Chybí-li úplně jedna skupina pigmentu, jedná se o dichromazii. Pro postiženého to znamená, že vůbec nerozená jednu z výše uvedených barev. Pokud postižený nerozezná červenou, trpí vadou s názvem protanopie, v případě zelené barvy deuteranopií a velmi vzácná je tritanopie, kdy dotyčný nevidí barvu modrou. Následující obrázek ukazuje změnu barevného vidění postižených.

Obrázek 1 - Poruchy vidění

6


Velmi vzácnou vadou zraku je monochromazie, kdy v oku chybí dvě z těchto tří skupin čípků. Lidé takto postižení pak vůbec nejsou schopni vnímat barevné spektrum a rozeznávají jen černou, bílou, případně odstíny šedé barvy. Navzdory poškození zraku mohou nevidomí a slabozrací, naučí-li se využívat kompenzačních pomůcek, používat počítač poměrně bez obtíží. Tyto technologie jsou navrženy přesně podle potřeb zrakově postižených a snaží se poskytnout postiženému stejné možnosti při práci s počítačem, tak jako má každý běžný uživatel.

2.1. Kompenzační pomůcky Zrakově postižení uživatelé používají při práci s počítačem výstupní zařízení s hlasovým výstupem (odečítač obrazovky) nebo hmatovým výstupem (braillský řádek). Obě tato zařízení dokážou reprodukovat stejný textový obsah. Z tohoto důvodu musí být použitý text pro zobrazení informací skutečným živým textem a ne text interpretovaný obrázkem či jinak. Slabozrací pak navíc ještě vyžívají služeb zvětšovacích programů. Vstupním zařízením pro hendikepované je klávesnice a některé ovládací prvky braillského řádku, pomocí kterých počítač ovládají.

2.1.1. Hlasový výstup (Odečítač obrazovky) Hlasový výstup je mnohdy špatně označován názvem jedné ze svých dvou částí. Skládá se speciálního programu tzv. odečítače obrazovky a hlasového syntezátoru. Je-li odečítač spuštěn, zpracovává prostřednictvím hlasového syntezátoru text zobrazený v aktuálním okně či dialogu a převádí jej do zvukové podoby, kterou následně pomocí zvukové karty a reproduktorů nebo sluchátek interpretuje uživateli ve formě syntetického hlasu. Společně se zvukovým výstupem lze využít odečítače obrazovky k hmatovému výstupu pomocí braillského řádku. Mezi nejpoužívanější odečítače obrazovky patří JAWS a ZoomText. Aplikace ZoomText, jejíž bezplatná demoverze byla využita při průběžném testování, navíc obsahuje funkce pro zvětšování obrazovky.

7


Obrázek 2 - Zvětšovač a odečítač ZoomText

2.1.2. Hmatový výstup (Braillský řádek) Hmatový výstup se skládá z odečítače obrazovky (podobně jako hlasový výstup) a výše zmíněného braillského řádku. Braillský řádek (někdy také nazývaný jako braillský displej, či hmatový displej) je hardwarové zařízení, které převádí textové informace zaslané odečítačem obrazovky do Braillova písma. Každý znak je zobrazen samostatně pomocí osmi bodů (čtyři řádky a dva sloupce), jak je patrné z následující ukázky.

Obrázek 3 - Braillovo písmo

8


Obrázek 4 - Detail braillského řádku

Braillský řádek je k počítači připojen přes rozhraní USB a funguje jako výstupní i vstupní zařízení. Jednotlivé typy se liší počtem zobrazovaných znaků, zobrazovanými doplňkovými informacemi (znaky), například o pozici kurzory na obrazovce, a mívají také odlišné funkce vstupních kláves. Jednotlivé modely podle typu zobrazují 20, 40, 70 nebo 80 znaků. Ovládací a řídící klávesy jsou většinou umístěny tak, aby jejich obsluhu obstaraly pouze palce obou rukou a ostatní prsty položené na řádku mohly číst text.

Obrázek 5 - Braillský řádek

Nejefektivnějším způsobem obsluhy počítače pro nevidomé uživatele je kombinace hlasového výstupu a braillského řádku.

2.1.3. Zvětšovací programy Zvětšovací programy jsou softwarové programy, které fungují obdobně jako lupa a umožňují libovolně zvětšit určitou oblast obrazovky tak, aby byla pro postiženého čitelná. Některé z těchto programů navíc umožňují rozdělení obrazovky na vícero částí. Příkladem je rozdělní na dvě části, kdy jedna je zvětšená požadavků 9

Identifikace klíčových požadavků a omezení

uživatele a druhá se standardní velikostí (nezvětšené prostředí) umožňuje lepší navigaci a orientaci v prostoru plochy.

2.2. Potřeby uživatele Nevidomý uživatel nemá jinou možnost, než obsluhovat počítač a veškeré programy výhradně z klávesnice. I u slabozrakých uživatelů je vhodnější ovládání PC z klávesnice, protože zadávání příkazů tímto způsobem je přesnější než klikání myší na objekty na obrazovce. Samo sebou je nutné brát v úvahu, že slabozraký uživatel má při práci několika násobně zvětšenou plochu monitoru, či využívá jiné barevné schéma (např. místo písma černého na bílém podkladu, písmo žluté na černém). Významnou roli pro zrakově postiženého též hraje jednoduchost prostředí. Nevidomí si musí umět svět aplikace představit a dobře se v něm orientovat. Dále pak nelze opomenout volbu vhodné barevné skladby, pokud možno co nejvíce kontrastní, ne však s přehnaným množstvím barevných odstínů. Na pozadí by neměl být vzor, který snižuje čitelnost. Nejlepší je pak umožnit uživateli individuální nastavení. Všechny výše uvedené faktory vedou k poznatku, že hra musí být dobře vyřešena i po grafické stránce, srozumitelná, intuitivní, s co možná nejjednodušším ovládáním. Je třeba se vyhnout příliš malým objektům, kombinacím nekontrastních barev či naopak příliš složitým prvkům, které by mohly uživatele zmást a dezorientovat. Hra by v žádném případě neměla být jakkoliv stresující či nepříjemná, naopak musí představovat vhodný a zábavný nástroj.

3. Identifikace klíčových požadavků a omezení 3.1. Požadavky Platforma Windows: Počítače pro nevidomé jsou vybaveny operačním systémem Windows, se kterým spolupracují pro ně nezbytné odečítače.

10

Identifikace klíčových požadavků a omezení

Textová podoba: Odečítače obrazovky pracují s obyčejným textem, nikoliv však nakresleným. Hra bude proto formována především do textové podoby, doplněna zvuky a vhodnými obrázky.

Nastavitelné grafické rozhraní: Pro slabozrakého uživatele je důležitá možnost nastavit si své vyhovující prostředí, a to jak velikost písma, tak i barevné schéma.

Jednoduchost ovládání: Základním kamenem celé hry je srozumitelné ovládání a dobrá orientace uživatele. Nevidomí si musí umět představit prostředí, ve kterém pracuje, a neztrácet se v něm. Každý takovýto nedostatek může vést ke zmatku a stresu.

Klávesové zkratky: Je nutné zaměřit se na volbu intuitivních klávesových zkratek, kterými by si uživatel mohl s ovládáním hry vypomoci.

Systémové hlášení: V případě vzniku jakékoli chyby programu, musí být uživatel informován o vzniklé situaci a jejím řešení.

Nápověda: Nedílnou součástí hry musí být vždy dostupná srozumitelná nápověda a to nejen jak hru ovládat, ale i nápověda ke hře samotné.

Rozšiřitelnost plynoucí ze zadání: Navrhnout hru tak, aby poskytovala možnost doplnit databázi zvířat v zoologické o nové živočišné druhy a případně další možnosti.

11

Vize hry

3.2. Omezení Z podstaty určení cílové skupiny vyplývají zásadní grafická omezení. Hra musí být zpracována především v textové a zvukové podobě. Jedním z dalších omezení je funkčnost pouze na platformě Windows. Ačkoliv je pro implementaci zvolen multiplatformní jazyk Java, hra prakticky nemá pro žádný jiný operační systém využití. V neposlední řadě pak musí být systém implementován tak, aby komunikoval s odečítačem, který pak poskytne dění na monitoru zrakově postiženému. Omezení taktéž vyplývá z autorských práv k nahrávkám, proto je nutné najít a využít ty, které pod autorská práva nespadají (nahrát své, či využít zvuků přírody). Při volbě klávesových zkratek je třeba vyjít z používaných horkých kláves pro rychlé ovládání odečítače, které postižený může volat z jakéhokoliv místa, a vyhnout se tak konfliktu s vybranými zkratkami.

4. Vize hry Hra splňuje všechny specifické požadavky dané cílovou skupinou, spolupracuje s odečítačem a poskytuje široké možnosti dalšího rozšíření.

4.1. Strategie obecně Princip hry vychází z fungování skutečné zoologické zahrady, která z počátku začíná s několika vystavovanými druhy zvířat, malou návštěvností, kdy je pro širokou veřejnost nezajímavá. Postupem doby se však rozvíjí, nakupuje nové živočišné druhy, rozšiřuje pavilony a stává se pro veřejnost atraktivní. Stejně tak hráč postupně obohacuje svoji zoologickou zahradu a snaží se zvýšit návštěvnost, která mu přináší finanční ohodnocení.

12

Vize hry

4.2. Módy hry Hra bude mít dva módy: otevřeno a zavřeno. V případě módu otevřeno do zoologické zahrady přicházejí návštěvníci. Čas je diskrétně rozdělen na zvolené dny, a hráč je po uplynutí zvoleného počtu dnů o této skutečnosti informován (může přejít k módu zavřeno do módu otevřeno) a uplynulý čas je vyhodnocen. Vzniklé událostí, jejich posloupnost a dopad na zoologickou zahradu, jaká je výsledná výše finančních prostředků apod. Je-li hráčem vybrán mód zavřeno, brány zoo jsou pro návštěvníky uzavřeny a hráč může svou zoo zdokonalovat, nakupovat krmivo pro zvířata, kupovat nová zvířata z nabídky, která se mu postupem hraní otvírá, umístit tvory do příbytků či rozšiřovat zoo o nové pavilony apod. V souhrnu lze říct, že hráč v tomto módu spravuje celou zahradu. Nakupuje, prodává, přemísťuje, rozšiřuje bez časového omezení.

4.3. Herní detaily Hráč má k dispozici čtyři druhy příbytků pro zvířata: výběh, klec, terárium a akvárium, do kterých by měl vhodně umístit svá zvířata. Přičemž kromě výběhu musí být všechny příbytky součástí pavilonu. V každém pavilonu je specifikováno, kolik příbytků lze do něho postavit, tak jako je určeno kolik zvířátek je možno v těchto příbytcích ubytovat. Výuková stránka hry spočívá v záměrném nezobrazení některých informací o zvířatech, např. druh příbytku, aby byl hráč nucen chybějící informace nastudovat. Zisk či ztráta v zoo bude výsledkem odečtení příjmů z vybraného vstupného (dle atraktivity a úrovně zoo) od výdajů na provoz. Je tedy důležité udržovat zoologickou zahradu atraktivní pro návštěvníky, toho lze dosáhnout neustálým rozvojem zoo, nakupováním nových druhů, příbytků atd. Výdaje pak představují nákupy krmiva pro zvířata a celkové náklady na provoz zoo včetně údržby příbytků.

13

Vize hry

4.4. Databáze Nejdůležitější základnou hry je samotná databáze. Pomocí jazyka XML budou uchovávány informace o jednotlivých tvorech, událostech, krmivu a příbytcích podstatné pro hru. O zvířatech je nutné uchovávat takové informace, které podají hráči vyčerpávající přehled o jejich životě (výuková část hry) a pro slabozraké uchování odkazu na velký obrázek.

4.5. Náhodné události a podmíněné události Nepodmíněnými událostmi jsou myšleny situace, které systém vybírá z databáze událostí během módu otevřeno. Tyto události jsou rozděleny do několika kategorií v souvislosti s jejich vznikem. Reagují bezprostředně na stav v zoo. K nim je dále přidána jedna událost, která je vybrána zcela náhodně. Příkladem kategorie událostí je nedostatek krmiva, či špatně umístěné zvíře. Vyhodnocení událostí přichází se skončením cyklu navoleného počtu dní, nestanou-li se zásadnější změny typu úmrtí zvířete. Jejich dopad je realizován ve stejný den, jako tyto události nastaly a tím pak ovlivňuje události následujících dní. Události

podmíněné

vycházejí

přímo

z nepodmíněných.

Příkladem

nepodmíněné události, na kterou navazuje událost podmíněná, je návštěva celebrity v zoo. Událost sama o sobě neovlivní vůbec nic, avšak na základě tohoto například celebrita daruje zoo peněžitý dar a tak zoo získá finanční prostředky. Všechny podmíněné události jsou zaneseny v databázi jako součást události nepodmíněné.

4.6. Uchování informací o stavu hry a aplikace Protože má každý hráč své specifické požadavky na herní prostředí, je potřeba uchovávat informace o nastavení aplikace. Data proto budou uchována pomocí jazyka XML jako konfigurační soubor. V neposlední řadě je nutné uchovávat stav hry, opět bude využito jazyka XML k zpětnému obnovení hry ze zálohy uloženého stavu hry. Záloha musí dodržet

14

Softwarová analýza

strukturu příbytků a zvířat v zoo, uchovat stav financí, úroveň, náklady atd., aby bylo možné po ukončení hry pokračovat tam, kde hra skončila.

4.7. Možnosti dalšího rozšíření Rozšíření databáze Hra bude díky databázi volně rozšiřitelná ve všech oblastech. Především rozšiřitelností na poli událostí získává hra s každou přidanou událostí úplně nové dimenze. V příloze Události jsou zachyceny oblasti, ze kterých by je bylo možno vytvářet a rozšiřovat. Pro snadnou správu databáze by mohl být implementován rozšiřující modul editoru pro zadávání potřebných dat přímo do databáze.

Prohlídka zoo Pro zpestření by mohl být mód otevřené zoo obohacen o virtuální prohlídku hráčovy zoologické zahrady. Prohlídka by byla sestavena z namluveného povídání o jednotlivých tvorech dle jejich umístění v zoologické, jejich chování včetně zvuků na pozadí. Cílem by bylo zrakově postiženým nabídnout prostředí zoologické zahrady alespoň virtuální cestou.

Kvízy Výuková část by mohla být doplněna o různě obtížné kvízy sestavené z otázky dle databáze zvířat. Kvízy by zmapovaly znalosti hráče ze života zvířat a případně přinesly různé bonusy do hry.

5. Softwarová analýza Jedním z prostředků pro softwarovou analýzu je jazyk UML (Unified Modeling Language). Jedná se o grafický jazyk pro navrhování, specifikaci, vizualizaci a dokumentaci objektových programů různé složitosti. Představuje taktéž výborný nástroj pro komunikaci mezi vývojáři, kteří snadno zachytí své myšlenky do diagramů a zprostředkují ostatním. Modely sestavované v rámci UML analýzy na systém nahlíží jako na celek, ale z různých oblastí pohledu. Vždy však s jednotným cílem, kterým je 15


zaznamenání kompletního návrhu a všech prvků, tak aby byl programátor schopen vytvořit navržený program bez obtíží a nutností konzultace se zástupcem cílové skupiny. V rámci softwarové analýzy tohoto projektu byly zpracovány diagramy Use Case (případů užití) pro vybrané situace, Class model hry ZooZoom, State Diagram zvířete, Activity Diagram pro hru a Sequence Diagram pro správce událostí v programu Enterprise Architect.

5.1. Use Case Diagram případu užití zachycuje možné interakce uživatele se systémem. Uživatelé neboli aktéři, představují určité uživatelské role, s jejichž scénářem přistupují k systému, a mají tak vymezeny své specifické funkční činnosti (administrátor, hráč, editor atd.). Každá funkční činnost pak představuje samostatný diagram případu užití systému. Následující obrázek ukazuje Use Case diagram pro celou hru ZooZoom včetně rozšiřitelných částí. Obsahuje-li název případu užití odkaz na další Use Case diagram, je tento zpracován samostatně a uveden následovně s tímto označením.

Obrázek 6 - USE CASE diagram ZooZoom

16


5.1.1. Seznam a popis účastníků (actors) Hráč Představuje všechny uživatele, kteří přistupují k aplikaci s účelem si zahrát, či si rozšířit vědomosti o zvířatech. Bude moci plně využívat všechny funkce aplikace (kromě editování dat). Příklad užití – hráč rozšiřuje své zoo a nakupuje nové zvíře: správa zvířat.

Editor Reprezentuje i případného hráče s právy na editaci vkládání, mazání databázových dat. Po autorizaci do systému může pracovat s daty o zvířatech. Příklad užití – přidává do aplikace nová zvířata.

5.1.2. Ostatní diagramy Use Case Celkově bylo navrženo několik dalších případů užití, zde bude však uveden pouze jeden, a to Správa zvířat, k doplnění následující kapitoly týkající se scénáře k tomuto případu užití. Ostatní jsou zařazeny podle příslušného označení v přílohách k této práci.

Obrázek 7 - Use Case správa zvířat

17


Dále byly rozpracovány následující případy užití: UC1 – Ovládání otevírací doby UC2 – Rozšiřující část Procházka po zoo UC3 – Správa krmiva UC4 – Správa objektů UC6 – Rozšiřující modul Vkládání dat UC7 – Rozšiřující část Řešení kvízů

5.1.3. Příklady scénářů případů užití Nákup nového zvířete hráčem Hráč se rozhodl koupit nové zvíře do zoo.

Tok událostí:

Basic Path 1)

Hráč zvolí možnost nákup nového zvířete.

2)

Vybere ze seznamu, do kterého aplikace zařadí dle dosažené úrovně zahrady příslušná zvířata ke koupi.

3)

Vybere umístění nového zvířete do příbytku v pavilonu či výběhu.

4)

V případně pavilonu aplikace požaduje výběr konkrétního objektu (klec, akvárium).

5)

Aplikace ověří, zda lze nové zvíře pořídit a umístit.

6)

Aplikace přiřadí nově koupené zvíře do příslušného objektu a odečte náklady na pořízení.

Alternate Zrušení nákupu zvířete 2)

Zrušení prováděných úprav kdykoliv stiskem tlačítka storno.

18


Doplňkový scénář nastavení barevného pozadí hráčem Hráč zvolí z menu nastavení okénka a je mu zprostředkováno dialogové okno pro nastavení.

Tok událostí:

Basic Path 1)

Hráč rozbalí menu Nastavení a zvolí položku okénko.

2)

Přesune kurzor na posuvník určující barvu pozadí.

3)

Kurzorovou klávesou doprava či doleva zvolí barvu pozadí, která je mu zprostředkovávána na pozadí dialogového okna.

4)

Výběr potvrdí tlačítkem OK.

5)

Aplikace uloží novou konfiguraci prostředí a zobrazí nové nastavení.

Alternate Hráči současné nastavení vyhovuje 1)

Dialog nastavení hráč kdykoliv opustit stiskem tlačítka Zrušit.

5.2. Activity diagram Diagramy aktivit představují chování či rozhodování v průběhu toku událostí. Používají se k zobrazení logiky procesů v sekvenci jednotlivých kroků, které jsou pak v modelu zachyceny jako akce a vnořené aktivity. Tam, kde jedna aktivita končí, vyvolává její konec přechod na začátek další aktivity. Následující diagram sleduje hráče od jeho vstupu do zoologické zahrady po její opuštění a zachycuje veškeré aktivity, které v systému může hráč provádět.

19


Obrázek 8 - Activity diagram Hraní hry

5.3. State transition diagram Diagram stavů a přechodů zachycuje přechody mezi jednotlivými stavy určitého objektu systému v souvislosti s vnějšími podněty. Vnějšími podněty se rozumí například předávané události, které určitým způsobem modifikují atributy daného objektu a tím tak mění jeho stavy (zvíře je zdravé, zvíře je nemocné). Diagram stavů a přechodů pro objekt zvířete zachycuje jeho „životní cyklus“ v zoologické zahradě.

20


Obrázek 9 - State diagram zvířete

5.4. Class Diagram Diagramy tříd patří k nejpoužívanějším nástrojům jazyka UML. Přestavují statickou strukturu tříd a vztahů mezi nimi z objektového pohledu. Lze je považovat za předpis pro vytvoření tříd analyzovaného projektu.

21


Obrázek 10 - Class Diagram

5.4.1. Popis tříd Zoo Třída Zoo zachovává veškeré informace o stavu zoo (peníze, náklady). Dále uchovává odkaz na třídu Food, veškeré instance třídy Pavilion a Egress a odkaz na třídu EventsManager. Je tedy nejvyšší a řídící třídou.

Food, KindOfFood Třída Food je správcem veškerého krmiva v zoologické zahradě. Obsahuje odkazy na instance KindOfFood, neboli druhy krmiva vlastněné hráčem a rozdělené podle typů zvířat (masožravec, býložravec, všežravec). Zajišťuje veškerou manipulaci s krmivem.

EventsManager Tato třída obstarává veškerou správu událostí a poskytuje informace o právě uskutečněných událostech i o historii.

Event, EventN a EventP Event je abstraktní třída, která soustředí společné vlastnosti pro její potomky EventP a EventN. Uchovává informace potřebné k získání databázových informací či 22


informace o důsledcích této události. EventN obsahuje odkazy na její příslušné EventP a zachovává čas, kdy nastala.

Location, Pavilion a Egress Location je opět abstraktní třída soutředící společné vlastnosti pro třídy Pavilion a Egress. Zachovává informace o kapacitě, atraktivitě či údržbě. Společná pro třídy Pavilion a Egress je také ta skutečnost, že se umisťují na nejvyšší úroveň v zoo. Pavilion pak dále obsahuje odkaz na v sobě umístěné příbytky, naopak Egress na ubytovaná zvířata.

PlaceForAnimal, Aquarium, Terrarium, Cage Tyto třídy mají podobné vlastnosti jako předchozí skupina s tím rozdílem, že jejich umístění je uvnitř pavilonu. Abstraktní třída PlaceForAnimal, od které ostatní dědí, zachovává opět společné informace, jako je například odkaz na ubytovaná zvířata, kapacitu, atraktivitu atd. Třídy pak samy sebe pouze identifikují, pokud je potřeba vědět, o jaký příbytek se jednalá.

Animal Posledním článek struktury je třída Animal. Tato si vede záznam o spotřebě krmiva, atraktivitě, odkaz na databázové informace, jako stáří, typ krmiva atd.

5.5. Sequence diagram Sekvenční diagramy spolu s diagramy případu užití patří do skupiny diagramů zobrazujících dynamickou stránku systému. Snaží se identifikovat objekty a zobrazit komunikaci mezi nimi v průběhu dané operace, kterou může představovat určitý případ užití. Komunikace interpretovaná sekvenčním diagramem zachycuje otevření zoo, vytvoření událostí a následné zobrazení výsledků uživateli.

23

Návrh uživatelského rozhraní

Obrázek 11 - Sekvenční diagram Správce událostí

5.6. Plán projektu V rámci předmětu Řízení softwarových projektů XD36RSF byl k vizím tohoto projektu (včetně všech možných rozšíření) vytvořen Plán, jenž podrobně analyzuje časové možnosti, zvolené prostředky, rizika, stanovuje ocenění, požadavky na kvalitu či testování a sestavuje plán řízení těchto oblastí. Plán projektu je začleněn pouze do příloh na přiloženém CD a tvoří nedílnou součást této bakalářské práce, neboť jsem následně podle něj postupovala v oblastech týkajících se této práce.

6. Návrh uživatelského rozhraní Příprava na vytvoření tohoto projektu směřovala i do řad cílové skupiny, kdy jsem po absolvování náročných lektorských zkoušek zkusila vyučovat zdravotně postižené základům ovládání operačního systému Windows z klávesnice. Praktické zkušenosti vedly pak k návrhu uživatelského rozhraní podle vzoru průzkumníku Windows, se kterým se klienti pod mým vedením učili pracovat. Po několika výukových hodinách byli schopni představit si systém souborů a složek, přirovnávaný ke stolu s šuplíky a v něm dalšími šuplíky, a orientovat se v něm. Jejich největší předností byla rychlá adaptabilita na vzniklé obtíže a prakticky „neomezená“ kapacita paměti, kterou

24

Implementace

mě neustále překvapovali. První návrhy podle průzkumníku Windows, konzultované se slabozrakým klientem vyhovovaly jeho potřebám. Aplikační menu Pavilon

Výběh

Pavilon

HERNÍ MENU

prostor průzkumníku s ikonami

7. Implementace Pro implementaci samotné hry byl vybrán jazyk Java. Tento výběr byl učiněn z malé skupiny vyučovaných jazyků v rámci studia, kdy se jevil nejvhodnějším. Základy jazyka C++ nebyly dostatečné k vytvoření grafické aplikace a konzolový program by nevyhovoval nárokům cílové skupiny. Jazyk PHP sám o sobě taktéž nepředstavuje vhodný nástroj a v kombinaci s webovými technologiemi by pouze přiblížil projekt ostatním špatně dostupným online hrám. Tedy jediným, do hloubky probíraným jazykem a jazykem vyzkoušeným i v praxi, byla již výše uvedená Java. Prvním krokem před samotnou implementací bylo zvolení konkrétní technologie jazyka Java pro grafické rozhraní. V Jazyce Java je možné použít několik typů knihoven poskytující grafické komponenty pro uživatelské rozhraní. Například se jedná o technologie AWT a SWING, jež jsou součástí standardních knihoven jazyka Java, či opensource knihovna SWT, která je nabízena společně s vývojovým prostředím Eclipse. Nejstarší technologií a je AWT (Abstract Windowing Toolkit), která obsahuje pouze základní prostředky společné pro všechny platformy. V dnešní době je již značně zastaralá a prakticky nepoužívaná. Z této technologie vycházejí další již zmíněné modernější.

Po

pracovních

zkušenostech

s napsáním

programu

ve

Swingu

a zohledněním faktu, že je součástí standardních knihoven, byla první volba naprosto zřejmá. Nicméně se však ukázalo, že ne příliš šťastná. Druhým krokem bylo totiž zjišťování, zda odečítače spolupracují s jazykem Java a se zvolenou technologií jako takovou.

25

Implementace

Po vytvoření prvního okénka s aplikačním menu (horní pruh menu v každém programu) a konfrontací s odečítačem následovalo zoufalé prohledávání diskuzí o Swingu, zveřejněných chyb jazyka, protože, ačkoliv dokumentace uvádí, že klávesová zkratka ALT má aktivovat toto menu, nic se po stisku ALT neotevřelo. Tato chyba byla nakonec opravdu v databázi Oracle – Sun Microsystems nalezena. Následovalo otestování přístupnosti jednotlivých komponent, avšak ani tady technologie Swing nesplnila očekávání. Nezbytnou výše zmíněnou podmínkou spolupráce odečítače a aplikací je obyčejný živý text bez obrázků. Odečítače pro svou činnost využívají Win32 API funkci operačního systému Windows, která vrátí handle aktivního okna operačního systému, tedy okna, které je má fokus. Ze získaného handle dále pomocí dalších API funkcí se následně zjišťuje typ okna a jeho „window text“ vlastnost, případně další detaily. Tyto informace odečítač následně předává TTS (textto-speach) aplikačnímu stroji (Microsoft speach API), který vygeneruje příslušný hlasový výstup. Vzhledem k tomu, že Swing využívá tzv. lehkou implementaci (lightweight), jsou všechny komponenty této knihovny vykresleny pomocí dvojitého bufferování grafickými funkcemi jazyka Java. Znamená to tedy, že komponenty jsou pouhými překreslujícími se obrázky. Jediným aktivním oknem operačního systému používaným aplikací napsanou pomocí rozhraní Swing je hostitelské okno Windows, v němž je nakreslena základní okenní komponenta JFrame nebo JDialog. Jak již bylo zmíněno, odečítače neumí pracovat s nakreslenými texty a tedy ani nakreslenými ovládacími prvky, tudíž aplikace napsaná pomocí Swingu není s odečítači kompatibilní. S tímto zjištěním myšlenka napsání hry ve Swingu ztratila své kouzlo. Na výběr zůstala technologie AWT a SWT. Při prvním rozboru byla knihovna SWT jako opensource vyřazena pro nedostatečnou dokumentaci a absolutní neznámou, její implementace je však obdobná Swingu. Postup otestování komponent byl zopakován i pro technologii AWT. Ta oproti Swingu využívá pro všechny své komponenty prostředky hostitelského operačního systému a tedy v případě jejich aktivace je odečítač pomocí výše zmíněných Win32 API funkcí schopen získat handle používaného okna či komponenty, a tak předat potřebná data pro interpretaci uživateli. Proto byla zvolena technologie AWT, navzdory její zastaralosti.

26

Implementace

7.1. Tvorba uživatelského rozhraní Uživatelské rozhraní se skládá z několika funkčních oblastí, které jsou logicky rozděleny, z nichž každá je označena velkým písmenkem F v názvu třídy. Společným rysem všech komponent je plná podpora práce odečítače spojená s kompletní přístupností prostřednictvím klávesnice. Tato funkčnost byla naprosto zásadní, a proto vyžadovala vytvoření fokus politiky (třída AFocusTraveral) a nových přístupných komponent, kterým se věnuje následující kapitola. Pro lepší orientaci postižených v programu, byly popisy reprezentované komponentou typu Label na některých místech při aktivaci fokusu zdůrazněny změnou písma. Výsledná celková průchodnost (fokus politika) byla modifikována na základě Usability testování a identifikovaných požadavků zástupcem cílové skupiny. Detailní informace o tomto testování jsou zpracovány v příslušné kapitole.

FFace Hlavní okno celé aplikace, potomek třídy Frame a výchozí bod uživatelského rozhraní celé aplikace. Zprostředkovává veškeré ovládací a informační prvky aplikace. Zabezpečuje ukládání a načítání hry.

FMenuBar FMenuBar je klasické aplikační menu (pruh menu pod názvem okna). Jeho funkcí je předání příkazu z uživatelského rozhraní dle vybrané položky menu příslušným třídám. Obsahuje několik kategorií a již zmíněné položky menu, které jsou provázány s klávesovými zkratkami. Podporuje volitelné nastavení písma uživatele, avšak pouze v rozsahu, který umožňuje operační systém.

FScout FScout napodobuje chování průzkumníku Windows v režimu zobrazení ikon. Třída představuje aktivní prostor pro ikony a veškerou manipulaci s nimi. Každá instance si uchovává odkaz na svého předchůdce a tím je zaručena struktura a průchod od nejnižší úrovně po nejvyšší. V opačném směru zajišťují průchod samotné ikony, tedy nedílnou součástí této třídy je seznam ikon v průzkumníku obsažených. Pro třídu 27

Implementace

FScout byl navržen speciální manažer rozložení komponent AScoutLayoutManager, který usazuje ikony na správné pozice a dovoluje přesun fokusu mezi nimi navigačními klávesami.

FToolBar FToolBar je druhým typem menu. Bezprostředně reaguje na dění v aplikaci a mění tak tlačítka (tedy i funkce), které lze v danou chvíli využít. Podporuje průchod navigačními klávesami nahoru a dolu. Zprávy z klávesnice o stisku tlačítka ToolBaru identifikuje třída navržená přímo pro tento účel: AToolButtonKeyAdapter. Pro zobrazení správných tlačítek dává impulz třída FFace.

FAObjectManager – FFoodManager, FAnimalManager, FObjectManager Abstraktní třída FAObjectManager je základem uživatelského rozhraní dialogových

oken

pro

veškerou

správu

zvířat

(FAnimalManager),

budov

(FObjectManager) a krmiva (FFoodManager). Jednotlivé instance správců jsou přímo napojeny na databázová data a data hry. Z prostředí správce zvířat lze navíc přehrát zvuky zvířete a zobrazit fotografie.

FMessageBox Představuje chybějící dialogové okno pro zobrazení zprávy uživateli s běžnou funkčností, jaká je u odpovídající komponenty ve Swingu či jiných vývojových prostředích, například .NET. Základní funkčnost je navíc rozšířena pro podporu odečítače. Pro výsledné zpracovávání událostí stisku tlačítek na message-boxu, byla vytvořena třída AMSBoxButtonKeyAdaper.

Obrázek 12 - Message Box

28

Implementace

FConfigDialog Vedle komponenty reprezentující ikonu (CIcon a pomocných tříd) byl konfigurační dialog (FConfigDialog) nejsložitější částí uživatelského rozhraní z hlediska podpory přístupnosti. Dialog je navržen ve formě záložek (Swingový ekvivalent JTabbedPane), jehož podpora v AWT zcela chybí. Klíčovým problémem bylo zajištění přechodu mezi jednotlivými záložkami pomocí klávesové zkratky CTRL + TAB. Překonání tohoto problému vyžadovalo odchycení příslušných zpráv klávesnicových událostí přímo ze systémové fronty AWT Event Queue. Obdobná implementace byla též využita při návrhu třídy reprezentujících ikonu a message-box dialogu. FConfigDialog umožňuje nastavení všech parametrů písma, barvy pozadí, popředí, nastavení hlasitosti hudby, historie událostí a dalších parametrů. Podpora nastavení barvy pozadí vyžadovala vytvoření speciální komponenty CPanel, která zajistí korektní přenastavení barvy všem komponentám na sobě umístěným.

Obrázek 13 - Config Dialog

7.1.1. Tvorba chybějících komponent Vize grafické podoby hry byla tedy postavena na principu fungování průzkumníku Windows. Technologie AWT nabízí pouze omezený počet komponent: List, TextArea, TextField, Choice, CheckBox, RadioGroup (sestavená z CheckBoxů), Label, Panel, Scrollbar, Canvas (plátno pro kreslení). Jakékoliv další vznikají podle potřeby na základě dědičnosti z těchto a jsou dotvářeny do výsledné podoby

29

Implementace

nastavováním velikosti, barvy a požadovaných vlastností, nebo vhodnou kompozicí několika základních komponent. Grafické komponenty jsou kresleny pomocí metody paint(Graphics g), jejímž přetížením jsou získány nové možnosti práce s komponentami po stránce jejich grafického vzhledu. Žádné z výše uvedených komponent nelze bohužel nastavit přímou cestou ani rámeček. Největší překážku představovala absence jakékoliv jednoduché komponenty pro kreslení obrázků. Plátno neboli Canvas je sice určeno k tomuto účelu, avšak obrázky opět kreslí metodou paint(Graphics g). Zde vznikaly obrovské problémy s nastavováním velikosti, kterou plátno získává až po svém nakreslení. Bohužel se tato komplikace projevila i v jiných případech. Hendikepovaní procházejí aplikací část po části, která je dostupná z klávesnice klávesami TAB, či navigačními. Nejsnadněji lze tento systém přirovnat procházení tabulkou buňka po buňce. Proto musí být jednotlivé komponenty dostupné (lze na ně umístit fokus) a zachovat v každém takovémto průchodu logické uspořádání. Výchozí stav dostupnosti komponenty, jak se ukázalo, není nijak nastaven. Nebyla-li žádná komponenta v aktuálním pořadníku pro převzetí fokusu, obdržela fokus náhodná komponenta. Tedy všechny komponenty, které nemají být dostupné, musí mít nastaveno false metodou focusable(boolean b). Všechny nově vznikající komponenty (třídy) byly označeny velkým písmenem C na začátku jejich názvu a zařazeny do balíčku UI, tedy uživatelské rozhraní.

CBorderPanel Reakcí na neexistenci metody orámování komponenty bylo vytvoření panelu s rámečkem. Rámeček vzniká pouze přetížením metody paint() o dokreslení na pozadí 3D obdélníku s velikostí panelu.

CScrollBar Jedná se o potomka třídy Scrollbar, která má pouze přetíženou metodu k nastavení preferované velikosti. Záměrem této úpravy je použití Scrollbaru jako posuvníku pro nastavování barvy.

30

Implementace

CFocusableLabel K žádné textové komponentě nebylo možné jednoduchým způsobem připojit popisek (Label), který by odečítač společně s aktivací textového pole přečetl. Základní komponenta Label totiž není za normálních okolností dostupná, jinými slovy nereaguje na ni fokus. Nově vzniklá komponenta povoluje přístup fokusu a navíc při aktivaci zvětší písmo. Nevýhodou však stále zůstává, že se jedná o samostatnou fokusem dostupnou komponentu, kterou musí zrakově postižený přejít, jednak aby se dozvěděl uvozující popis k následující komponentě a aby měl na následující komponentě umístěný fokus (např. Zde zadejte jméno:

, text zvýrazněný tučně představuje

Label a obdélníček textovou komponentu).

CImage Třída CImage doplňuje řadu komponent o chybějící snadné vykreslování obrázků. Sama o sobě tvoří kombinaci Canvas plátna, na kterém je obrázek vykreslen a Panelu, v němž je posléze umístěn. Zvláštností této třídy je zajištění skutečné velikosti podle obrázku, kdy musí být po nakreslení a získání velikosti ještě jednou překreslena, aby zobrazení bylo korektní.

CIcon Ikona CIcon vzniká kompozicí komponent typu Panel, Canvas, Label a TextField. Canvas je použit pro kreslení obrázku ikony, komponenta typu Label ukazuje popisek a zajišťuje veškerou dostupnost celé ikony. V případě editace je label nahrazen textovým polem. Vše je pospojováno panely s vhodným typem rozložení (layout) a zakázanou dostupností. Třída CIcon využívá speciálně modifikovaných komponent zmíněného typu: CIconImage, CIconImageCanvas – horní část ikony, vykreslování obrázku, CIconTitle, CIconTitleLabel, CIconTitleEditField – dolní část ikony, správa popisku, jeho editace, dostupnost.

Obrázek 14 – Ikona

31

Implementace

Pro

plnou

podporu

AIconMouseAdapter,

která

přístupnosti zajišťuje

byly událostí

vytvořeny

aktivní

uskutečněné

třídy myší,

a AIconMouseAWTListener, odchytávající událostí z AWT Event Queue pro korektní ukončení editace ikony.

CTextArea Součástí hry je zprostředkování mnoha textových informací, opět neexistovala pro ty toto účely žádná konkrétní komponenta. Východiskem byla modifikace textového pole. Výsledná komponenta nedovoluje editaci textu. Při průchodu aplikací reaguje na klávesu TAB, jejíž původní význam znamenal vložení znaku tabelátoru do textu. Nepříjemností je vyvolané varovného zvukového hlášení systému Windows při stisku jakékoliv alfanumerické klávesy, jako pokus o editaci needitovatelného pole. Navzdory této komplikaci byla tato komponenta nejvhodnější, protože dovoluje plynulé čtení textu. Druhou komponentou využitou pro zprostředkování seznamů informací je list, který žádnou modifikaci nepotřeboval.

CSoundBar CSoundBar představuje velmi jednoduchý panel pro přehrávač zvuku. Obsahuje pouze tlačítko Spustit, které je po spuštění nahrazeno tlačítkem Pauza a tlačítko Zastavit. Vše je umístěno v jediném panelu se zakázanou dostupností.

Obrázek 15 - Sound Bar

CPanel Potomek třídy Panel podporující překreslování pozadí i popředí všech komponent uvnitř s výjimkou instance třídy CScrollbar, u kterého je překreslování nežádoucí.

32

Implementace

CMessageBoxDrawingPanel Doplňkový panel k message-boxu, jenž dle typu zprávy zobrazuje znaky „!“, „i“, nebo „?“.

CTabbedPane a pomocné třídy CTabContainerPanel, CTabLabel Tato komponenta jako celek byla využita pro vytvoření konfiguračního dialogu. CTabLabel představuje jednotlivé záložky (ucha složek v kartotéce) a třída CTabContainerPanel tyto záložky zaobaluje. S výběrem konkrétní záložky je pak měněn obsah celé komponenty CTabbedPane.

7.2. XML DATA Jazyk XML (eXtensible Markup Language) bývá často připodobňován jazyku HTML. Podobně jako HTML uspořádává informace pomocí tagů a jim přiřazených atributů do určité předem dané struktury na základě několika jednoduchých pravidel. Rozdíl mezi těmito jazyky však představuje u XML neomezená možnost definice vlastních tagů a z toho vyplývající struktury informací, což je důvodem skutečnosti, že jazyk XML představuje výborný nástroj pro uchování dat. Velikou odlišností mezi HTML a XML není jen zmíněná definice tagů, ale také konečné určení dokumentů v těchto jazycích napsaných. Každý dokument XML představuje text strukturovaných dat sloužících pro přenos a opětovné zpracování počítačem. Aby byla zachována platnost (validita) dokumentu, je vhodné pro XML dokument přiřadit DTD (definici DOCTYPE), která představuje předpis pravidel a dostupných elementů (tagů) či atributů, a následně dokument s definicí validovat. Součástí standardních knihoven jazyka Java jsou rozhraní pro práci s XML (JAXP – Java API for XML Processing), která umožňuje jeho tvorbu, načítání a ukládání přímo uvnitř aplikace. Java dále podporuje konkrétně dva typy doplňkových API (XML Parser) pro zpracování dokumentů. První je Simple API for XML, neboli SAX a druhý vytvářející objektový model dokumentu je DOM, tedy Document Object Model for XML.

33

Implementace

7.2.1. SAX Jedním z nejjednodušších XML Parserů je rozhraní SAX. Používá se především k analýze dokumentu, kdy parser dokument postupně čte a předává systému zprávu o tom, jakou událost (např. začátek elementu) právě zaznamenal. Reakcí na obdrženou zprávu je zavolání call backové funkce (v Javě metody příslušného listeneru) určené této události. SAX tedy nenačítá celý dokument do paměti, ale rozebírá krok po kroku.

7.2.2. DOM DOM je rozhraní pro práci s dokumenty definované standardy W3C. Na rozdíl od SAX zmapuje celý dokument do paměti. Jediný výsledný objekt pak zapouzdřuje další objekty odpovídající každé příslušné části (element, atribut) dokumentu. Díky této struktuře mohou být dokumenty snadno vytvářeny či upravovány.

7.2.3. Zpracování XML Nutnost skriptování herních data pomocí tohoto jazyka vyplývala již ze zadání. V průběhu práce s XML se však ukázalo, že má tento jazyk natolik výborné vlastnosti pro uchovávání dat, že jej bylo využito v projektu hned několikrát. Samostatné dokumenty XML a pro ně napsané definiční DTD tvoří: herní databáze, konfigurační soubor a jednotlivé zálohy stavu hry. Ukázky všech těchto dokumentů jsou zařazeny do příloh k bakalářské práci. Bohužel snadná editace XML dokumentů v jakémkoliv (byť základním) textovém editoru není v případě uložených stavů hry žádoucí. Snadná dostupnost působí v reálném prostředí jako lákadlo k podvádění, proto by obsah dokumentů o stavu hry měl být přinejmenším zakódován. Toto však překračuje rámec zadání této bakalářské práce.

7.2.3.1. Načítání Prvním úkolem při práci s XML byla příprava načítání XML dokumentů. V balíčku XML byla vytvořena speciální třída XMLParser a pro ni pomocné třídy XElement, 34

Implementace

XAttributes, XException. Třída XMLParser zastřešuje oba výše zmíněné postupy pro práci s načítáním dokumentů, tedy SAX i DOM. Volbu postupu určí pouze parametr konstruktoru třídy. Standardní Apache implementace DOM parseru je postavena na parseru SAX. Při zpracování dokumentu DOM parserem jsou použity prostředky standardních knihoven a výsledkem je org.w3c.dom.Document.

Technologie SAX vyžadovala implementaci pomocných tříd XElement a XAttributes, které jsou při volání call back funkcí v průběhu čtení dokumentu vytvářeny, přiřazovány a propojovány do podobné, avšak velmi zjednodušené struktury dokumentu W3C. Výsledkem je kořenový XElement celé struktury. Data určená k dalšímu zpracování jsou pro jednoduchost načítána SAX parserem. Poslední pomocná třída XException je používána při samotné práci s načtenou strukturou, vznikají-li výjimky z chybně zadaných dat.

7.2.3.2. Ukládání Data načtená DOM parserem jsou z důvodu zachování struktury využívána pro úpravu konfiguračního souboru v případě jakékoliv změny. V získaném dokumentu jsou upraveny požadované položky a poté je dokument pomocí třídy XMLSaver uložen. Třída XMLSaver tedy podporuje pouze ukládání DOM struktury, která je po jednotlivých částech poskládána do StringBufferu a poté otevřeným výstupním proudem odeslána do souboru. Služeb XMLSaveru využívá nejen konfigurační soubor, ale i zálohování stavu zoo. Zde je vždy vytvořen úplně nový dokument W3C ze všech potřebných informací k opětovnému načtení hry.

7.2.3.3. Typy vytvořených XML dokumentů Jak již bylo uvedeno, hra používá tři různé typy XML dokumentů.

35

Implementace

Databáze (zoozoom – base) Databáze obsahuje veškerá statická data, která hra využívá. Její struktura je rozdělena na čtyři základní části, kterými jsou animals (část týkající se zvířat), habitations (příbytků), food (krmiva) a events (událostí). Zvířata jsou určena jednoznačným ID, poskytují veškeré informace zajišťující výukovou formu hry, mají specifikovány údaje podstatné pro hru (level, atraktivita, náklady, spotřeba, typ krmiva, zda se jedná o predátora), uchovávají odkaz na obrázek a zvuk zvířete. Dále zprostředkovávají záznam o preferovaných příbytcích včetně procentuálního ohodnocení preference, které je další možností rozšíření hry, při zpracovávání událostí. Příbytky se od sebe liší typem, avšak mají společné statické informace. Jsou určeny specifickým ID pro snadné vyhledávání, podávají informace podstatné pro hru (kapacita, level, cena, atraktivita) a zprostředkovávají detailní popis objektu. Typy příbytků jsou: Pavilion, Egress, Aquarium, Terrarium, Cage. Krmivo představuje jednotlivé druhy krmiva, tedy kindOfFood, které jsou zapouzdřeny elementem Food. Jednotlivé druhy mají své jednoznačné ID a údaje potřebné pro hru (typ krmiva, cena, level), včetně popisu krmiva. Události představují největší možnosti rozšíření celé hry. Každá kategorie vytvořená pro určité herní situace obsahuje nepodmíněné události, ze kterých je náhodně vybíráno v případě vzniku této situace. Kategorie lackOfFood reaguje na nedostatek krmiva v zoo a události v ní obsažené ovlivňují pouze zvířata. Z kategorie lackOfMoney je vybíráno v případě nedostatku peněz. Události mohou ovlivnit celé zoo. Kategorie badHabitation se týká pouze zvířecích událostí, kdy hráč umístil zvíře do špatného (nepreferovaného – např. ryba v teráriu) příbytku. Čtvrtou kategorii představuje overCapability, kdy je v příbytku zvířat více než je jeho kapacita. Tato kategorie přestavuje možnosti pro rozšíření při narození zvířete. Událostí v ní zahrnuté ovlivňují zvířata a příbytek. Umístí-li hráč více různých druhů do jediného obydlí, jsou volány události z kategorie moreInOne, jež mohou ovlivnit zvířata samotná, nebo příbytek. Podobnou kategorií je predator, která reaguje na umístění jiného živočišného druhu k predátorovi. Události v kategorii se týkají pouze zvířat. Předposlední kategorie reaguje na stáří zvířat v zoo, události samozřejmě ovlivňují pouze zvířata. A poslední

36

Implementace

kategorie others je kategorie všech ostatních událostí, které mohou ovlivnit běh celé zoo a z nichž je při každém dni jedna vybírána. Jednotlivé nepodmíněné události jsou tedy zařazeny do těchto kategorií. Specialitou nepodmíněných událostí je možnost přiřazení události, která je s danou pravděpodobností vyvolána vznikem její mateřské nepodmíněné události. Jinak řečeno element nepodmíněné události v sobě obsahuje elementy podmíněných událostí. Každá událost, ať už podmíněná, či nepodmíněná má své jednoznačné ID, název a pravděpodobnost vzniku. Dále má přesné určení atributů, kterými pak dále ovlivňuje běh hry. Jedná se o skupinu „group“: – animal, food, building, money, nothing, cost, attractivity, a dopad „impact“: - less, more, damage, nothing, z nichž lze utvořit následující kombinace: 

animal – less (ubývá zvíře), more (přibývá), damage (onemocní),



food – less (veškeré množství jednoho druhu ubude), more (přibývá krmiva, které hráč vlastní), damage (ubývá náhodné množství krmiva, které hráč vlastní),



building – less (ubývá náhodně obydlí), more (hráč náhodně obdrží obydlí vybrané z typu, které vlastní), damage (poškození obydlí, znamená realizaci jeho opravy),



nothing – nothing (neovlivňuje vůbec nic, zavedeno pro pestrost a barvitost hry),



money, cost, attractivity – less (uvedená položka ubývá), more (přibývá).

Následující ukázka zobrazuje kategorii událostí „others“ a v ní obsažené nepodmíněné události, včetně příkladu podmíněných. <event impact="nothing" group="nothing" probability="10" event_id="4" name="celebrita" event_details="zoo navštivila Tereza Maxová">

37

Implementace

Záloha stavu hry (zoozoom - save) Tento XML dokument je rozdělen na tři části. První část configuration uchovává informace o stavu pokladny, dosažené úrovni, jménu hráče, nastavení obtížnosti, nákladech zoo a atraktivitě, včetně zachování stavu krmiva v zoo. O krmivu je nutné si pamatovat pouze množství a jednoznačný identifikátor, ostatní informace jsou při zpětném načtení získány pomocí ID z databáze. Funkcí druhé části je zachování celkové struktury zoologické zahrady. V zoo jsou pavilony, výběhy. V pavilonech jsou umístěny příbytky a v nich zvířata, ve výbězích již pobíhají samotná zvířata. O všech je nutné zachovávat opět jednoznačný identifikátor, jméno přiřazené hráčem, stáří a stav. Poslední částí je uchování historie událostí. Struktura zůstává zachována jako u databázových (nepodmíněné v podmíněných), přičemž každá událost zná své herní detaily, jednoznačné ID, kategorii a v případě nepodmíněné navíc časový údaj vzniku.

Konfigurační soubor (zooConfig) Vzhledem ke specifickým požadavkům nastavení prostředí hry bylo potřeba uchovávat tyto informace. Konfigurační soubor tedy obsahuje data pro nastavení písma (barva, velikost, typ), velikost okna, zda bylo maximalizováno, barvu pozadí, cestu, kam byla poslední hra ukládána, a další doplňková nastavení zvuku, historie a ovládání.

7.3. Zvukové knihovny Pro práci se zvukem jazyk Java standardně nabízí nízkoúrovňové rozhraní Java Sound API. O rozhraní vyšší úrovně, Java Media Framework, musí být platforma Javy rozšířena doinstalací. Toto rozšíření je volně dostupné na webových stránkách Oracle – Sun Microsystems.

7.3.1. Java sound API Toto rozhraní poskytuje plnou podporu ke zvukovému vstupu i výstupu systému. Je vhodné pro tvorbu zvukových efektů do her, přehrávání a práci se souboru

38

Implementace

typu MIDI, tvorbu a editaci mediálního obsahu, který je pak následně zprostředkován konečným uživatelům atd.

7.3.2. JMF (Java Media Framework) JMF představuje uniformní rozhraní pro práci s multimediálním obsahem. Jeho součástí je i integrovaná komponenta přehrávače. Mezi jeho velké přednosti patří zabudována podpora většiny známých multimediálních formátů, zejména podpora MP3, které budou využity ve hře. Oproti tomuto Java sound API standardně podporuje pouze formáty wave a midi, přičemž podpora jiných formátů vyžaduje doinstalaci speciálních pluginů.

7.3.3. Výběr technologie Java Sound API je ve srovnání s JMF nízkoúrovňové rozhraní, které nabízí mnoho možností pro detailní kontrolu práce zvukových zařízení. Oproti tomu JMF díky velkému počtu podporovaných kodeků a nástrojů pro řízení multimediálního obsahu nabízí výrazně komfortnější platformu pro práci s multimédii. Vzhledem k potřebám hry, zejména jednodušší podpoře mp3, či jiných formátů bylo zvoleno rozhraní JMF. Původním záměrem bylo i využití integrované komponenty multimediálního přehrávače. Bohužel je tato komponenta založena na Swingu a tudíž odečítačem nepodporovaná, musela být proto nahrazena komponentou vlastní CSoundBar.

7.4. Výkonné jádro Výkonné jádro aplikace obsažené v balíčku zoo bylo navrženo beze změn přesně podle objektového class modelu zpracovaného v UML analýze. Implementace však vyžadovala doplnění několika interface, ať už pro snadnější manipulaci s třídami – IconModificationInterface (zapouzdřující instance třídy ukryté pod maskou ikony), či nutnost zapouzdření kvůli společnému rysu tříd – HabitationInterface (všechny příbytky), AnimalInterface (příbytky obsahující zvířata), a pomocných tříd – DataParser (třída pro převody řetězců na jiné typy). Zvláštností výkonného jádra je použití tzv.

39

Implementace

reflexe při vytváření jednotlivých tříd z obsahu XML zálohy hry či databáze. Při čtení jsou pouze podle názvu elementu vytvářeny třídy reprezentující objekty v zoo, a to bez nutnosti znát konkrétně, o kterou třídu se jedná.

7.5. Matematický model V rámci práce bylo rovněž nutno navrhnout matematické modely pro výpočty přírůstku atraktivity, hodnoty úrovně, přírůstkem příjmů a náklady závislými na stavu hry. Náhodný prvek je představovaný proměnnou RAND, která vrací racionální číslo z intervalu <0; 1>. V softwarové implementaci je volba náhodného čísla realizována pomocí systémové funkce metody Math.random(). Ve hře vystupuje hodnota ratio R, která byla empiricky stanovena pro obtížnou verzi na 0,3, pro normální verzi na 0,5 a lehkou verzi na 0,7. Při návrhu matematického modelu byly navrženy průběhy závislostí jednotlivých veličin s využitím standardních matematických funkcí a jejich transformací, následně byly jednotlivé součinitele složeny do součinu dílčích funkcí a následně pak vhodně upraveny pomocí volitelných konstant na přijatelný průběh absolutních veličin. Pro empirické testování byla použita jednoduchá aplikace, která je součástí projektu. Výsledný matematický model je závislý na stanovení hodnot empirických konstant K0, K1, K2, K3, K4, K5 a K6, výše uvedeným hodnotám obtížnosti ratio R a absolutním konstantám Imin, Amax.

Přírůstek nákladů Přírůstek nákladů ∆C je deterministická veličina závislá na řídících veličinách level L a ratio R. Výsledná hodnota ∆C vznikne jako součin dvou funkcí těchto řídících veličin. Chování funkce je nastavitelné pomocí dvou racionálních konstant K0 a K1. Jde o součin kvadratické funkce L vynásobený konstantou závisející sestupně na R, kde se absolutní chování funkce upraví pomocí konstant K0 a K1. Význam K1 představuje minimální přírůstek nákladů. Náhodná složka se v této funkci neuplatňuje. ∆𝐶 = 𝐾0 + 1 − 𝑅 . 𝐿2 + 𝐾1

40

Implementace

Přírůstek atraktivity Přírůstek atraktivity ∆A je deterministická veličina závislá na řídících veličinách level L a ratio R. Jde o součin lineární závislosti na R a transformované funkce arcus tangens veličiny L transformovaný do intervalu <0; Amax>, kde Amax je absolutní hodnota maximálního přírůstku atraktivity. Tato funkce využívá asymptotického chování funkce arcus tangens v kladném nekonečnu. Chování funkce je možno upravit stanovením hodnoty konstanty K2 a absolutní hodnoty maximálního přírůstku atraktivity Amax. Náhodná složka se v této funkci neuplatňuje.

∆𝐴 = 𝐾2 + 𝑅 . 𝑎𝑟𝑐𝑡𝑔 𝐿.

𝐴𝑚𝑎𝑥 . 2 𝜋

Příjem Příjem I je stochastická veličina závislá na řídících veličinách level L, ratio R a atraktivita A. Představa této funkce vycházela z průběhu závislostí I na dílčích veličinách, přičemž výsledná hodnota je vytvořena jako součin těchto dílčích funkcí. Příjem I je závislý na druhé odmocnině L, kdy je posílen nelineární nárůst pro nižší hodnoty L, pro vyšší hodnoty L nárůst klesá. Závislost I na R odpovídá (1+R)2, hodnota R se pohybuje v intervalu <0; 1>, proto je kvadratická funkce posunuta do -1, aby násobením tímto součinitelem docházelo s rostoucím R k růstu celkové hodnoty I. Druhá mocnina R posiluje nelineárně vyšší hodnoty R, které odpovídají jednoduššímu hernímu režimu. Násobení této části náhodným číslem způsobuje, že součinitel obsahující veličinu R dosahuje hodnot z intervalu <1; 5>, přičemž pro jednodušší herní režimy s vyšším R navyšuje hodnotu příjmu náhoda RAND výrazněji. Závislost I na atraktivitě A závisí na druhé mocnině ln(A+1), tedy pro vyšší atraktivitu je použit logaritmický převod, aby nedocházelo k astronomickému nárůstu příjmů zoo s rostoucí atraktivitou. Druhá mocnina logaritmu urychluje růst dílčí funkce. V původním návrhu byla použita pouze neumocněná hodnota ln(A+1), nicméně absolutní hodnoty funkce přes nastavování konstant K3 a Imin nedávaly uspokojivé výsledky. Po úpravě se chování funkce zlepšilo. Výsledný součin dílčích součinitelů je kvůli vhodnému absolutnímu výpočtu hodnoty I vynásoben konstantou K3 a je k němu připočtena konstanta minimální velikosti příjmu Imin. 41

Usability testování

𝐼 = 𝐾3 . (1 + 𝑅𝐴𝑁𝐷. 1 + 𝑅 2 ). 𝐿. ln 𝐴 + 1

2

+ 𝐼𝑚𝑖𝑛

Level Level L je deterministická veličina závislá na řídících veličinách ratio R a atraktivita A. Úroveň L závisí lineárně na R, je nutná aditivní konstanta K 4 udávající posun po ose y. L závisí na A logaritmicky, je nutný posun vertikální asymptoty do -1 a hodnota A je upravena multiplikativní konstantou K5. Výsledná hodnota je následně upravena multiplikativní konstantou K6 tak, aby absolutní hodnota dávala přijatelné výsledky. Chování funkce je tedy nastavitelné konstantami K4, K5 a K6.

𝐿=

𝐾4 + 𝑅 . ln 𝐾5 . 𝐴 + 1 + 1 . 𝐾6 ln 2

𝑃𝑜𝑧𝑛á𝑚𝑘𝑎: log 2 𝐾5 . 𝐴 + 1 =

ln(𝐾5 . 𝐴 + 1) ln 2

8. Usability testování Tento druh testování patří mezi techniky black-box testování (testují se vstupy a výstupy, aniž by bylo známo dění uvnitř). Usability testování prováděné přímou konfrontací konečného uživatele s programem slouží především ke zjištění, zda výsledný produkt splňuje očekávání. Zda má ergonomické ovládání, je pochopitelný, nematoucí a přístupný. Předmětem testů nebyla samotná instalace aplikace. Pro instalaci je vytvořen instalační manuál, který je součástí příloh.

8.1. Usability testování s koncovým uživatelem 8.1.1. Prostředky a cíle Usability testování proběhlo v domácím prostředí uživatelky na počítači s operačním systémem Windows Vista a speciálním software ZoomText 9.1. Uživatelka je slabozraká a tímto hendikepem trpí od raného dětství. Patří do věkové skupiny lidí 42


mezi 50 – 60 let. Cílem usability testování bylo ověřit, zda hra je přístupná, dostatečně intuitivní, zda spolupracuje korektně s odečítačem a je uživatelsky přívětivá.

8.1.2. Testování Usability test byl rozdělen do několika částí. V úvodní části byla uživatelka seznámena s cíli testu a vyzvána k vyslovení veškerých podnětů nápadů či připomínek. Následovalo několik otázek zjišťujících momentální rozpoložení a chuť objevovat nové v neznámém prostředí. Ani otázka, zda lze pořizované fotografie použít v rámci tohoto projektu nezůstala opomenuta. Uživatelka byla příjemně naladěna a se vším souhlasila. Následující kroky již směřovaly k programu samotnému. Uživatelce byla spuštěna hra a měla bez jakéhokoliv vysvětlení, co aplikace dělá, zkusit ve hře s pomocí odečítače najít chybějící informace. Zprvu chvilku váhala, ale prakticky automaticky otevřela aplikační menu, kde se položku po položce dopracovala k nápovědě. Odečítač bez problému přečetl nápovědu a uživatelka byla dále instruována k nastavování vzhledu okénka. Zde se projevily obavy z akceptování dvojitého stisku TAB pro přechod z fokusable labelu jako plané. Uživatelka sice v prvním kontaktu s touto komponentou zaváhala, zda je již na následující komponentě, labelem uvozenou, (konkrétně u labelu k nastavování barvy), nicméně při druhém setkání s touto komponentou nejevila žádné známky zmatení a brala ji okamžitě za normální součást. Nyní se přistoupilo k bodu vytvoření nové hry, což neznamenalo žádné velké komplikace. Uživatelka otevřela aplikační menu a vybrala položku nová hra. Poté vyplnila jméno a navolila jednoduchou obtížnost. Do prostoru průzkumníku se po potvrzení dialogu načetly výchozí ikony. Drobný nedostatek byl zaznamenán při průchodu herním menu. Uživatelka chtěla použít navigační klávesy pro posun nahoru a dolu, jejichž podpora nebyla v testované verzi implementována. Tento nedostatek byl bezprostředně odstraněn. Při práci s ikonami uživatelka využila funkcí zvětšovače a přiblížila si obrázky ikon, i přes zhoršenou kvalitu zvětšením poznala obsah a na zhoršení kvality obrázků vůbec nereagovala. Závěr vyvozený z reakcí je, že zhoršená kvalita obrázku zvětšováním je běžnou záležitostí, na kterou jsou tito uživatelé zvyklí. Systém složek jako v průzkumníku Windows vyžadoval nejprve naučení struktury zoologické zahrady, 43


po něm již nepředstavoval žádné problémy. Kontextové menu uživatelka prakticky nepoužívala.

Obrázek 16 - Usability testování Zvětšené ikony

První zmatky se projevily u správců (objektů, krmiva, zvířat), kdy tlačítko „zavřít“ bylo původně popsáno jako „Do zahrady“ a tlačítko „Zpět na správce“ pouze jako „Zpět“. Uživatelka si nedokázala představit, co znamená „Do zahrady“, a i po několikátém průchodu nebyla schopna význam tohoto tlačítka akceptovat. Raději proto navrhovala přejmenování těchto tlačítek na současnou verzi. Při testování správců byla také odhalena chyba odečítače, který nebyl schopen v komponentě typu list (seznam objektů k prodeji) přečíst první řádek seznamu a četl druhý neustále dokolečka. Tato chyba se projevovala naprosto náhodně. Dle informací uživatelky tato chyba vzniká i v jiných programech. Nefungovala zde ani uživatelkou v jiných programech používaná klávesová zkratka „mezerník“ pro zopakování přečtené položky seznamu.

44


Obrázek 17 - Usability testování Správce

Před zakoupením nového zvířete otevřela uživatelka samovolně informace o zvířeti. Data dostupná ke zvířeti (opět pomocí komponenty typu TextArea, jako u Nápovědy) odečítač bez problému přečetl. Uživatelka byla poté vyzvána ke stisku jakékoliv alfanumerické klávesy, po jejímž zmáčknutí se ozval varovný zvuk. Na tento signál uživatelka vůbec zděšeně nereagovala, naopak doslova pronesla: „Na tohle jsem zvyklá.“ Reakce zahnala veškerá negativní očekávání.

Obrázek 18 - Usability testování TextArea

45


V dalším kroku již uživatelka zkoušela otevřít obrázek zvířete. Jeho velikost byla dostačující, celkově se jí líbil a především ocenila otevírání v novém dialogovém okně. Ovšem popis tlačítka „OK“ působil zmatení, proto musel být změněn na „Zavřít“. Přehrání zvuku přineslo také drobné obtíže, jelikož bylo na záznamu zvířete nejprve nahráno ticho a zvíře se ozvalo až po chvilce čekání. Uživatelka si nebyla jistá, zda zvuk skutečně spustila a ověřovala tento stav s tlačítky přehrávače. Při dalším spuštění zvuků, tento problém již nenastal.

Obrázek 19 - Usability testování Zobrazení obrázku

Nyní byla uživatelka vyzvána k otevření zoo. Přednastavený jeden den potvrdila klávesou Enter a následně na to procházela uplynulé události. Zoo mělo záměrně přednastaven nedostatek krmiva, jehož důsledkem bylo vyvolání události úmrtí zvířete z hladu. Uživatelka intuitivně opět zoo zavřela a začala pořizovat chybějící krmivo. Při pokynu k ukončení programu uživatelka okamžitě stiskla klávesovou zkratku ALT + F4 a po vyzvání k uložení hry bez delšího přemýšlení hru uložila do složky dokumentů. Nevidomí a slabozrací jsou vyučováni, aby si všechny informace střádali do dokumentů, protože pro ně představují jednoduše přístupný bod z plochy i průzkumníku.

46


Poslední otázka byla zaměřena na znovuobnovení stavu zoo. Uživatelka přesně věděla, že záloha práce na zoo je uložena v dokumentech a že pro načtení do programu použije funkci načíst. S touto operací se setkává běžně při práci s textovými dokumenty např. typu MS Word.

8.1.3. Závěr Závěrem tohoto testování je tedy nutno konstatovat, že systém vyžadoval drobné úpravy k zlepšení přístupnosti uživatelům. Zástupce cílové skupiny však projevil neobyčejnou představivost, učenlivost a především adaptabilitu na nedostatky v přístupnosti. Test tedy přinesl pozitivní výsledky. Uživatelka byla hrou natolik nadšena, že mě již druhý den po testu kontaktovala s prosbou o upravenou novou verzi, kterou chtěla dále zprostředkovat svým hendikepovaným kamarádům. Co se týče zobrazení hry v prostředí Windows Vista, nebyly výsledky testu uspokojivé. Systém Vista dosadil do okna posuvníky, z důvodu nastavitelného look and feel vzhledu. Veškeré dekorativní rámečky kolem oken jsou pak rozměrnější a zobrazovaný obsah se do těchto oken nevejde. Tento problém nastává i u jiných aplikací, které nejsou vytvářeny přímo pro prostředí Windows Vista.

Obrázek 20 - Usability testování AWT na Vistě

47

JUnit testování

8.2. Usability testování se zástupcem bez hendikepu 8.2.1. Prostředky a cíle Usability testování probíhalo na počítači s operačním systémem Windows XP Professional. Test probíhal obdobným způsobem za účelem porovnání přístupnosti pro osoby bez hendikepu. Testující osoba opět souhlasila se zveřejněním výsledků a podnětů v této práci.

8.2.2. Testování Vše probíhalo bez obtíží až do bodu před nákupem zvířete, tedy konkrétně práci se správci. Tlačítka umístěná pod přehledem aktuálního stavu představovala neergonomické tažení myši, kdežto pro zrakově postiženého, který má na prvním tlačítku umístěn fokus obtíže nepřinášely. Zrakově postižená uživatelka naopak uvítala, že jsou na stejném místě jako u všech ostatních dialogů. Druhou připomínkou byla absence jakéhokoliv maličkého obrázku zvířete u jeho zobrazených informací. Pro zrakově postiženého ovšem tento obrázek nemá žádný smysl. A poslední poznámkou byla chudost vygenerovaných událostí, které jsou pouze textové.

8.2.3. Závěr Hra se tedy jeví i pro uživatele bez hendikepu hratelná, avšak není pro ně dostatečně atraktivní a „barevná“, plná obrázků. Rozhodně se neblíží ostatním graficky náročným hrám určeným pro na tuto cílovou skupinu. Přístupnost by tedy vyžadovala přinejmenším drobné změny v uspořádání komponent ve správcích.

9. JUnit testování Vedoucím bakalářské práce mi bylo doporučeno seznámit se v rámci testování s metodikou JUnit testů, které je vhodnou součástí black-box testování jednotlivých objektů aplikace. V prostředí JBuilder 2007 je implementována podpora JUnit verze 4.

48

Závěr

Tato podpora umožňuje vytvoření Test case pro libovolnou třídu aplikace. Test case je speciální třída, která má anotované metody setUp(), tearDown() a libovolný počet testovacích metod. V metodě setUp() se nastavují výchozí parametry prostředí každého testu, v metodě tearDown() se poté prostředí vyčistí. V rámci jednotlivých testovacích metod je potom testována funkčnost důležitých metod testované třídy. Vzhledem k použité implementaci návrhu aplikace, není snadné vytvořit testovací prostředí pro většinu tříd výkonného jádra, neboť nastavení testů by vyžadovalo prakticky vytvoření paralelní aplikace. JUnit testování bylo tedy vyzkoušeno na pomocné třídě DataParser, přičemž díky němu byly objeveny dvě chyby v této třídě a zajímavý fakt, že systémová metoda Boolean.parseBool() interpretuje jakoukoliv číselnou hodnotu jako false, ačkoliv bych předpokládala, že vložení jiného textového řetězce než true a false vyvolá NumberFormatException výjimku. JUnit testování je základním stavebním kamenem programování řízeného testy (Test Driven Development), které při návrhu každé třídy vychází z paralelního návrhu Test case a tedy aplikace je touto metodikou testována v průběhu celé implementace. Na základě této zkušenosti s JUnit testováním se při dalším vývoji aplikací pokusím uplatnit některé prvky programování řízeného testy tak, abych mohla využít jeho výhod. Toto vyžaduje částečné rozčlenění interakce mezi objekty výkonného jádra pomocí rozhraní.

10. Závěr Hlavním cílem tohoto projektu bylo překlenutí mezery na poli her pro zrakově postižené a dosažení optimální přístupnosti a ergonomie ovládání aplikace. Tento záměr byl s danými prostředky přes značné komplikace dodržen. Byla vytvořena hra dle náročných požadavků cílové skupiny, která vhodnou formou předkládá informace ze světa zvířat. Jazyk

Java,

v němž

byla

hra

implementována,

představuje

výborný

multiplatformní nástroj. V tomto případě naopak tato přednost představovala nedostatek. Důsledkem multiplatformního uzpůsobení jsou komponenty nejčastěji

49

Závěr

používané grafické knihovny Swing pouze kresleny, tudíž pro odečítač, vyžadující prostý text získaný z window handle, absolutně nedostupné. Zastaralá knihovna AWT, prakticky nepoužívaná již od verze jazyka 1.2, taktéž není vhodným nástroje k tvorbě přístupných aplikací. Její omezený počet komponent musí být komplikovaně rozšířen a modifikován. Nevýhodu též přestavuje nelehká instalace, není-li výsledná aplikace zapouzdřena jako „.exe“ s instalátorem, kterou zrakově postižení se základním kurzem práce se systémem Windows rozhodně nejsou schopni především pochopit a následně zvládnout. Instalace pro ně přestavuje průchod sledu dialogových oken tlačítkem „next“ a po dokončení instalace získání ikony na ploše jakožto přístupového bodu pro spuštění aplikace. K tomuto závěru mě dovedly reakce klientky na pokus o instalaci programu v průběhu výukového kurzu, proto jsem před usability testováním sama aplikaci uživatelce nainstalovala a umístila pro ni pouze ikonu na plochu. Stresová situace s instalací by pak následně mohla ovlivnit průběh celého testování. I přes všechny tyto nedostatky usability testování ukázalo, že hra byla pro uživatelku použitelná a hratelná.

10.1. Téma a rozsah práce V rámci tématu práce bylo použito široké spektrum osvědčených i nových nástrojů a technik, práce tak zasahovala do mnoha vyučovaných oblastí v průběhu studia. Při softwarové analýze jsem si vyzkoušela modelování v jazyce UML. Díky takto předem určených cílům prostředky UML, byla vlastní implementace jednodušší. Samostatná implementace pak přinesla nové poznatky z oblasti využitelnosti XML, jakožto výborného nástroje k uchování dat. Jazyk Java bohužel vůbec očekávání nesplnil (především v oblasti uživatelského rozhraní) a znamenal mnohdy pouhé obcházení chybějících částí a nedostatků. Nejzajímavější část představovalo usability testování, kdy jsem si po praktické stránce vyzkoušela přístup k testované osobě a testování jako takové. Díky zkušenostem z absolvovaných kurzů a znalosti práce s odečítačem bylo uživatelské rozhraní, až na malé nedostatky, navrženo srozumitelně, díky tomuto se testování vyhnulo slepým cestám a nepřinášelo zmatení či stres. Následovalo JUnit testování, které patřilo do oblasti prakticky neznámé. Jeho výsledky předčily všechna očekávání, nejen že objevila v testované třídě drobné chyby, ale 50

Závěr

způsob jeho provádění mě nasměroval v dalším programování k jinému způsobu navrhování aplikací a průběžnému využívání těchto testů. Právě odlišný návrh a teprve závěrečné testování zapříčinily, že nebylo možné otestovat hlavní třídy výkonného jádra. Otestována byla tedy jen pomocná třída ke zpracování databázových dat.

10.2. Zhodnocení přístupnosti Usability testování v obou případech ukázalo, že je aplikace jak pro skupinu hendikepovaných osob, tak i pro osoby bez hendikepu přístupná. Přesto by pro osoby bez hendikepu vyžadovala změny v návrhu a rozložení komponent. Text, který byl zrakově postiženým zprostředkován pomocí odečítače a textových komponent, by mohl být pouze nakreslen bez krkolomných úprav speciálních komponent. Především by celá aplikace nemusela být napsána zastaralejší technologií AWT a v neposlední řadě by mohla být „barevnější“, což představuje pro slabozraké či postižené s poruchami barvocitu značné obtíže. Celá hra by rozkvetla více obrázky různých velikostí,

které

pro

zrakově

postižené

nemají

vypovídací

schopnost,

aby

nehendikepovaným osobám nepřipadala tolik chudá. Dalším zajímavým zjištěním bylo, že i samotné odečítače mají své chyby, které nejsou způsobeny přístupností aplikací. Účastnice testu na tyto chyby reagovala okamžitým, naprosto automatickým, hledáním jiných východisek, z čehož vyplývá, že se tyto nedostatky objevují často. Zdravotně postižení se též často narážejí na nepřístupnost, a co je nepřístupné, znamená pro ně jako by nebylo. Jsou proto nuceni k neustálému vzdělávání a hledání kompromisů.

10.3. Praktické využití aplikace Hra svým charakterem, jednak zábavním, tak výukovým, má určitě svůj potenciál. Nicméně prostředky, které k vytvoření nabídl jazyk Java, nejsou úplně ideální. Dále by bylo dobré před nasazením implementovat i výše navrhované rozšíření a tak celou koncepci hry ještě obohatit. Nemělo by být zapomenuto ani na jednoduchý instalační program. Přesto se však domnívám, že i v této podobě udělá radost několika hendikepovaným

z okruhu

přátel

účastnice 51

Usability

testování.

Snadná

Závěr

modifikovatelnost vstupních dat přináší široké možnosti a tito lidé se svou zvídavostí a rychlostí se učit novým věcem brzy bez problému otevřou databázi v textovém editoru a začnou doplňovat nová zvířata či události.

52

Použitá literatura

Použitá literatura 

KISZKA, B. – 1001 tipů a triků pro jazyk Java, vydání první. Brno: Computer Press 2009



HORTON, I. – Java 5. Praha: Neocortex 2005



CLUTTON-BROCKOVÁ, J. – Savci, vydání první. Praha: Knižní klub 2005



DARWIN, I. F. – Java kuchařka programátora, vydání první. Brno: Computer Press 2006



BECK, K. – Programování řízené testy, vydání první. Praha: Grada Publishing 2004



ARLOW, J., NEUSTADT I. – UML 2 a unifikovaný proces vývoje aplikací, vydání první. Brno: Computer Press 2007



Zrakové handicapy - kompenzační pomůcky a doporučení při tvorbě www stránek [online]. Plzeň 2010. Dostupný z WWW: http://handicap.zcu.cz/pomucky_zrak.php



Úvod do objektového modelování a jazyka UML [online]. Praha 2010. Dostupný z WWW: http://www.komix.cz/Tisk/Clanky/Historie/Uvod_UML.aspx



Java SE 6 Documentation [online]. Redwood Shores: Oracle 2010. Dostupný z WWW: http://java.sun.com/javase/6/docs/

53

Použité zdroje

Použité zdroje 

Medvěd hnědý. In: Wikipedia, the free encyclopedia [online]. St. Petersburg, FL: Wikimedia Foundation, 2001, poslední editace 2010-05-04. Dostupný z WWW: http://cs.wikipedia.org/wiki/Medv%C4%9Bd_hn%C4%9Bd%C3%BD



Medvěd hnědý obrázek *online+. Poslední otevření 2010-05-12. Dostupný z WWW: http://www.firstpeople.us/pictures/bear/1600x1200/Lifes_a_Bear1600x1200.jpg



Šimpanz učenlivý. In: Wikipedia, the free encyclopedia [online]. St. Petersburg, FL: Wikimedia Foundation, 2001, poslední editace 2009-12-01. Dostupný z WWW: http://cs.wikipedia.org/wiki/%C5%A0impanz_u%C4%8Denliv%C3%BD



Šimpanz učenlivý obrázek *online+. Poslední otevření 2010-05-12. Dostupný z WWW: http://i.lidovky.cz/09/061/lngal/GLU2b8f41_simp.jpg



Vlk obecný. In: Wikipedia, the free encyclopedia [online]. St. Petersburg, FL: Wikimedia Foundation, 2001, poslední editace 2010-04-27. Dostupný z WWW: http://cs.wikipedia.org/wiki/Vlk_obecn%C3%BD



Vlk obecný obrázek *online+. Poslední otevření 2010-05-12. Dostupný z WWW: http://pohlednice.oblibena.cz/wallpapers/full/67303131.jpg



Hadi čeledi Elapidae – korálovcovití (Mamba zelená). In: Planeta zvířat, časopis listopad 2005 [online]. Praha: Planeta zvířat, 2005. Dostupný z WWW: http://casopis.planetazvirat.cz/051122-hadi-celedi-elapidae-koralovcoviti-2.html



Mamba zelená obrázek *online+. Poslední otevření 2010-05-12. Dostupný z WWW: http://z.about.com/d/goafrica/1/0/O/I/sb10065404d-001.jpg



Amazoňan žlutohlavý [online]. Poslední otevření 2010-05-12. Dostupný z WWW: http://papousci-drozd.ic.cz/index.php?clanek=34



Amazoňan žlutohlavý obrázek *online+. Poslední otevření 2010-05-12. Dostupný z WWW: http://content.breederoo.com/users/Jade/images/content/Yellowcrowned_Amazonforweb.jpg



Braillská abeceda obrázek *online+. Poslední otevření 2010-05-12. Dostupný z WWW: http://www.sons.cz/braillska_abeceda_sada.php

54

Použité zdroje



Detail braillského řádku obrázek *online+. Poslední otevření 2010-05-10. Dostupný z WWW: http://i.iinfo.cz/urs/detail-braillsky-122390843131780.jpg



Braillský řádek obrázek *online+. Poslední otevření 2010-05-10. Dostupný z WWW: http://handicap.zcu.cz/pomucky_zrak.php



Poruchy vidění obrázek *online+. Poslední otevření 2010-05-10. Dostupný z WWW: http://handicap.zcu.cz/pomucky_zrak.php



Pavillon icona obrázek *online+. Poslední otevření 2010-05-10. Dostupný z WWW: http://www.holz-haus.de/65001/images/navi_8-eck-pavillon.png



Icon gate obrázek *online+. Poslední otevření 2010-05-10. Dostupný z WWW: http://www.istockphoto.com/file_thumbview_approve/4216872/2/istockphoto _4216872-wrought-iron-gate-vector.jpg



Animal sound *online+. Poslední otevření 2010-05-10. Dostupný z WWW: http://www.animalpicturesarchive.com/animal/SOUND/



Meditation music free – Painting the ocean *online+. Poslední otevření 2010-0510. Dostupný z WWW: http://amazingsounds.iespana.es/aseanimal.htm

55

Seznam obrázků

Seznam obrázků Obrázek 1 - Poruchy vidění ........................................................................................................... 6 Obrázek 2 - Zvětšovač a odečítač ZoomText................................................................................. 8 Obrázek 3 - Braillovo písmo .......................................................................................................... 8 Obrázek 4 - Detail braillského řádku ............................................................................................. 9 Obrázek 5 - Braillský řádek ............................................................................................................ 9 Obrázek 6 - USE CASE diagram ZooZoom ................................................................................... 16 Obrázek 7 - Use Case správa zvířat ............................................................................................. 17 Obrázek 8 - Activity diagram Hraní hry ....................................................................................... 20 Obrázek 9 - State diagram zvířete ............................................................................................... 21 Obrázek 10 - Class Diagram ........................................................................................................ 22 Obrázek 11 - Sekvenční diagram Správce událostí ..................................................................... 24 Obrázek 12 - Message Box .......................................................................................................... 28 Obrázek 13 - Config Dialog .......................................................................................................... 29 Obrázek 14 – Ikona...................................................................................................................... 31 Obrázek 15 - Sound Bar............................................................................................................... 32 Obrázek 16 - Usability testování Zvětšené ikony ........................................................................ 44 Obrázek 17 - Usability testování Správce .................................................................................... 45 Obrázek 18 - Usability testování TextArea .................................................................................. 45 Obrázek 19 - Usability testování Zobrazení obrázku................................................................... 46 Obrázek 20 - Usability testování AWT na Vistě ........................................................................... 47

56

Seznam příloh

Seznam příloh 

Příloha č. 1 – Instalační návod ZooZoom



Příloha č. 2 – Use Case UC1 Ovládání otevírací doby



Příloha č. 3 – Use Case UC2 Procházka po zoo



Příloha č. 4 – Use Case UC3 Správa krmiva



Příloha č. 5 – Use Case UC4 Správa objektů



Příloha č. 6 – Use Case UC5 Správa zvířat



Příloha č. 7 – Use Case UC6 Vkládání dat



Příloha č. 8 – Use Case UC7 Řešení kvízů



Příloha č. 9 – Konfigurační DTD Zoo – base



Příloha č. 10 – XML dokument Zoo databáze



Příloha č. 11 – Konfigurační DTD Zoo – save



Příloha č. 12 – XML dokument Záloha hry



Příloha č. 13 – Konfigurační DTD Zoo – config



Příloha č. 14 – XML dokument Zoo konfigurace



Příloha č. 15 – Obsah souborů na přiloženém CD

57

Příloha 1 – Instalační návod Zoozoom

Příloha 1 – Instalační návod Zoozoom Požadavky: Windows XP, Vista, 7 s funkční zvukovou kartou a zvukovým výstupním zařízením. 1. Instalace ZoomText 9.1 V případě, že na Vašem počítači není instalován ZoomText či jiný odečítač, spusťte instalačního CD program install/ZT_large-inter_918_8.exe. Postupujte pomocí kroků rychlé instalace. 2. Instalace JRE 6 Pokud na Vašem počítači není instalováno JRE 6, spusťte z instalačního CD program

install/jre-6u17-windows-i586.exe.

Alternativně

můžete

stáhnout

nejnovější verzi ze stránek http://java.sun.com. 3. Otestování funkčnosti JRE 

Spusťte příkazový řádek (cmd.exe) a zadejte příkaz: java -version



Odpověď příkazu musí začínat textem: java version "1.6.

4. Instalace knihovny Java Media Framework Z instalačního CD instalujte program install/jmf-2_1_1e-windows-i586.exe. Postupujte podle pokynů instalátoru a po instalaci ověřte, zda se do zvoleného adresáře program nainstaloval. 5. Zkopírování adresáře hry Do zvoleného adresáře zkopírujte z instalačního CD adresář zoozoom/ včetně kompletního obsahu. 6. Spuštění hry Hra ZooZoom se spouští poklepáním na soubor zoozoom.jar, z klávesnice v případě aktivního fokusu klávesou Enter, případně pomocí příkazu z příkazového řádku: javaw -jar zoozoom.jar, který musí být aktivován z pracovního adresáře, v němž je umístěn. Rovněž je možno vytvořit zástupce tohoto příkazu, ale je nezbytné, aby byl pracovní adresář zástupce nastaven na adresář, kde je umístěn soubor zoozoom.jar. Standardně zástupce nastaví pracovní adresář zástupce do adresáře, v němž je umístěn program javaw.exe. 58

Příloha 2 - Use Case UC1 Ovládání otevírací doby

Příloha 2 - Use Case UC1 Ovládání otevírací doby

59

Příloha 3 – Use Case UC2 Procházka po zoo

Příloha 3 – Use Case UC2 Procházka po zoo

60

Příloha 4 – Use Case UC3 Správa krmiva

Příloha 4 – Use Case UC3 Správa krmiva

Příloha 5 – Use Case UC4 Správa objektů

61

Příloha 6 – Use Case UC5 Správa zvířat

Příloha 6 – Use Case UC5 Správa zvířat

62

Příloha 7 – Use Case UC6 Vkládání dat

Příloha 7 – Use Case UC6 Vkládání dat

63

Příloha 8 – Use Case UC7 Řešení kvízů

Příloha 8 – Use Case UC7 Řešení kvízů

64

Příloha 9 – Konfigurační DTD Zoo – base

Příloha 9 – Konfigurační DTD Zoo – base
events (lackOfFood,lackOfMoney,badHabitation,overCapability,moreInOne,predator,age,others) > lackOfFood (event*)> lackOfMoney (event*)> badHabitation (event*)> overCapability (event*)> moreInOne (event*)> others (event*)> age (event*)> predator (event*)>

65

Příloha 10 – XML dokument Zoo databáze

Příloha 10 – XML dokument Zoo databáze <description> Amazoňan je zhruba 38 cm velký. Tohoto papouška nalezneme ve volné přírodě převážně na území Mexika. Obývá listnaté pobřežní lesy, mangrovové porosty a vždyzelené tropické lesy v Belize, nadmořská výška nepřesahuje většinou 700m n. m.. Zdržuje se v párech, vyjímečně v menších skupinkách a to jenom v mimohnízdním období. Hnízdní v dutinách stromů od března do května, občas zalétávají na kukuřičné a ovocné plantáže. Početní stav ve volné přírodě rapidně klesá, především díky kácení lesů zemědělci, kteří hledají novou ornou půdu a také masovým odchytem ptáků v 70. letech 20. století. Samec je zelený, čelo má žluté, temeno též žluté, někdy má žlutá péra okolo očí, příuší a líce jasně smaragdově zelené. Ohbí křídla má červené a okraje křídla žlutavě zelené. Ocasní péra jsou zelená. Zobák je tmavě šedý u kořene na horní části z obou stran oranžový, duhovka oranžová, běhák bledě šedý. Samice je stejně zbarvena jako samec. Krmivo tvoří především různé druhy semínek obohacených o ovoce a zeleninu. <preference> <events> <event impact="less" probability="80" name="úmrtí zvířete z hladu" event_details="v zahradě není dostatek krmiva, pokud se tento stav nezlepší, hrozí úmrtí dalších zvířat" event_id="0" group="animal"/> <event impact="damage" probability="80" name="zvíře onemocnělo" event_details="v zahradě není dostatek krmiva, pokud tento stav setrvá, hrozí onemocnění i dalších zvířat, případně jejich smrt" event_id="1" group="animal"/> <event impact="less" probability="5" name="exekuce" event_details="zahrada neměla dostatek zoomů k zaplacení provozu, nedostatek exekutor vyřešil prodejem majetku" event_id="0" group="animal"/> <event impact="less" probability="5" name="exekuce" event_details="zahrada neměla dostatek zoomů k zaplacení provozu, nedostatek exekutor vyřešil prodejem majetku" event_id="0" group="building"/> <event impact="less" probability="5" name="exekuce" event_details="zahrada neměla dostatek zoomů k zaplacení provozu, nedostatek exekutor vyřešil prodejem majetku" event_id="0" group="food"/> <event impact="less" probability="80" name="úmrtí zvířete" event_details="zvíře bylo umístěno do špatného obydlí, které zapříčinilo jeho umrtí" event_id="0" group="animal"/> <event impact="less" probability="80" event_id="2" group="money" name="stávka" event_details="si doplň dle modelu"/> <moreInOne> <predator> <event impact="less" probability="80" name="úmrtí zvířete" event_details="zvíře bylo umístěno do obydlí s predátorem, který jej napadal" event_id="0" group="animal"/> <event impact="damage" probability="80" name="poranění zvířete" event_details="zvíře bylo umístěno do obydlí s predátorem, který na něho zaútočil, naštěstí se jej včas podařilo zachránit" event_id="0" group="animal"/> <event name="stáří zvířete" event_details="zvířátko zemřelo stářím" event_id="0" group="animal" impact="less" probability="80"/> <event impact="more" probability="10" event_id="5" group="money" name="spozor" event_details="zoo obdržela sponzorský dar"/> <event impact="damage" probability="10" event_id="7" group="food" name="krysy" event_details="krysy znehodnotily zásoby potravy"/> <event impact="less" probability="10" event_id="8" group="cost" name="dodavatel" event_details="získal jsi nového výhodnějšího dodavatele"/>

66

Příloha 11 – Konfigurační DTD Zoo – save

Příloha 11 – Konfigurační DTD Zoo – save

67

Příloha 12 – XML dokument Záloha hry

Příloha 12 – XML dokument Záloha hry <external age="0" habitation_id="4" name_in_game="Můj první" repair_time="10"> <pavilion> <events> <event event_id="0" age="5" info=="Tato událost zoo nijak neovlivnila." category="others">

68

Příloha 13 – Konfigurační DTD Zoo – config

Příloha 13 – Konfigurační DTD Zoo – config
color color color color

EMPTY > blue CDATA #REQUIRED > green CDATA #REQUIRED > red CDATA #REQUIRED >

initSettings initSettings initSettings initSettings initSettings initSettings initSettings initSettings

( background, font, icon ) > height CDATA #REQUIRED > maximized CDATA #REQUIRED > key (z|o|i) #REQUIRED > width CDATA #REQUIRED > mute CDATA #REQUIRED > historyCount CDATA #REQUIRED > dirPath CDATA #REQUIRED >

Příloha 14 – XML dokument Zoo konfigurace

69

Příloha 15 – Obsah souborů na přiloženém CD

Příloha 15 – Obsah souborů na přiloženém CD Přiložené CD obsahuje následující strukturu adresářů a souborů: 

Adresář text obsahující bakalářskou práci ve formátu pdf včetně příloh, které byly uvedeny v textu a dokumentu info.txt s podrobným obsahem jednotlivých adresářů CD.



Adresář install se všemi soubory potřebnými pro instalaci dle instalačního návodu, který je součástí příloh této práce.



Adresář workspace, představující pracovní adresář pro JBuilder2007.



Adresář source obsahující jednotlivě zdrojové kódy hry ZooZoom a Testeru úrovně hry.

70

VÝUKOVÁ STRATEGICKÁ HRA PRO ZRAKOVĚ POSTIŽENÉ

Recommend Documents