České vysoké učení technické v Praze Fakulta elektrotechnická. Bakalářská práce. Návrh webové hry. Neudert Zbyněk. Vedoucí práce: Ing

České vysoké učení technické v Praze Fakulta elektrotechnická

Bakalářská práce

Návrh webové hry Neudert Zbyněk

Vedoucí práce: Ing. Jiří Mlejnek Studijní program: Elektrotechnika a informatika Obor: Výpočetní technika

květen 2008

iv

Poděkování Mé poděkování patří zejména Ing. Jiřímu Mlejnkovi za vedení mé práce a poskytnuté konzultace. Dále pak všem členům rodiny a mé přítelkyni Monice Jetmarové za trpělivost a podporu při vzniku práce. Za věcné připomínky a následnou implementaci mého návrhu děkuji kolegům Michaelu Minářovi a Davidu Komárkovi. Za jazykovou a stylistickou korekturu děkuji PaedDr. Haně Chalupníkové, za pomoc při přepisech dokumentace slečně Ivaně Doležalové, a za jazykové překlady RNDr. Karlu Neudertovi.

v

vi

Prohlášení Prohlašuji, že jsem svou bakalářskou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto díla ve smyslu §60 Zákona č.121/2000 Sb., o právu autorském a o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). Ve Vysokém Mýtě dne 11.6. 2008

……………………………………

vii

viii

Abstract This work deals with a proposal of web game for children in the age of 7 to 12 years. It is designed to satisfy conditions of younger children oriented games with easy control. First, according to problem specifications, nowadays on-line web games were explored and age rating systems for classification of this type of games were found. Furthermore, a model of strategy game has been proposed in which one could build and upgrade unique Zoo-garden. There were also implemented rules and possible options into this model. Whole work was documented by methods of software engineering with use of UML language and UP methodology. Main focus was to separate means of view manipulation from data and to ensure easy extensibility of whole project. A tutorial and a brief game walkthrough were created as the last part of the whole project.

Abstrakt Tato práce se zabývá návrhem webové hry pro děti ve věku 7 – 12 let. Hra zde popsaná je navržena tak, aby splňovala podmínky na hry pro děti a mládež kladené a aby její ovládání nebylo pro děti příliš složité. Dle zadání byla nejprve prozkoumána současná nabídka online webových her a zjištěny systémy klasifikující hry pro děti a mládež. Následně byla navržena hra s námětem zoologických zahrad, umožňující hráčům vytvářet a dále budovat jedinečnou zoologickou zahradu. Pro hru byla sestavena vlastní pravidla a možnosti. Celá práce je dokumentována pomocí metod softwarového inženýrství s využitím jazyka UML a metodiky UP. Při návrhu byl kladen důraz na oddělenou manipulaci se zobrazovacími prostředky a daty zajišťujícími snadnou rozšiřitelnost hry. V závěru práce byl vytvořen tutoriál a stručný návod ke hře.

ix

x

OBSAH SEZNAM OBRÁZKŮ

xiii

1. Úvod 2. Dělení her 2.1. Dělení online her 3. Současná nabídka online webových her 4. Požadavky na hry pro děti a mládež 4.1. Klasifikační systém PEGI 4.2. PEGI Online 4.2. Shrnutí požadavků kladených na hry pro děti a mládež 5. Téma navrhované hry versus požadavky na tyto hry 6. Jazyk UML 6.1. Historie UML 6.2. Budoucnost UML 6.3. Modelování v jazyce UML 7. Unified Process 7.1. Postupy a fáze metodiky UP 8. Požadavky a jejich specifikace 8.1. Slovníček pojmů 8.2. Odborný článek 8.3. Strukturovaný katalog požadavků 8.4. Business process model 8.5. Use Case diagramy 9. Analýza 9.1. Diagram analytických tříd 9.2. Pravidla hry – diagramy aktivit 9.2.1. Přidělování finančních prostředků na konto hráče 9.2.2. Záchranné odchyty 10. Návrh 10.1. Uživatelské rozhraní 11. Nasazení – diagram nasazení 12. Rozšiřitelnost hry 13. Tutoriál ke hře 13.1. Text tutoriálu 14. Návod ke hře 14.1. Hlavní strana návodu - rozcestník 14.2. Terárium chameleónů – část návodu 14.3. Chameleón jemenský – část návodu 14.4. Lovec – část návodu 14.5. Tvůj zisk – část návodu 14.6. Páření zvířat – část návodu 14.7. Výcvik zvířat – část návodu 14.8. Rozšiřování zahrady – část návodu 15. Závěr 16. Použité zdroje informací

1 3 3 5 7 7 8 9 11 13 13 13 14 15 15 17 17 19 20 22 23 29 29 30 31 34 37 37 39 41 43 43 45 45 46 46 47 47 47 47 48 49 51

A Diagramy strukturovaného katalogu požadavků B Use Case diagramy a jejich scénáře

53 57

xi

xii

C D E F G

Business Process modely Model analytických tříd Pravidla hry – diagramy aktivit Návrh uživatelského rozhranní Obsah přiloženého CD

69 81 84 90 92

xiii

xiv

SEZNAM OBRÁZKŮ Obr. 4.1. Piktogramy PEGI

5

Obr. 4.2. Logo PEGI Online

5

Obr. 8.1. Postup pracovních procesů při prodeji zvířete

20

Obr. 8.2. Příklad Use Case diagramu

22

Obr. 9.1. Diagram analytických tříd – zmenšený

28

Obr. 9.2. Obnova stavu konta – diagram aktivit

31

Obr. 9.3. Odchyt – diagram aktivit

33

Obr. 10.1. Users interface – návrh hlavní herní obrazovky

36

Obr. 11.1. Diagram nasazení – zjednodušený

37

xv

xvi

1. Úvod Podnětem ke vzniku tématu se stala hypotéza, že současná nabídka on-line webových her nepokrývá cílovou skupinu mladších dětí ve věku 7-12let. Práce se proto zabývá průzkumem současné nabídky těchto her pro výše uvedenou cílovou skupinu, specifikací požadavků, které jsou na tyto hry kladeny, a navrhuje vlastní webovou aplikaci. Návrh je dokumentován dle metodiky unifikovaného procesu vývoje aplikací s využitím modelovacího jazyka UML2, který slouží pro vizuální modelování systému.

1

2

2. Dělení her Vzhledem k neexistenci standardizovaného rozdělení her bylo zavedeno vlastní dělení, které bude přínosné pro tento projekt. Hry mohou být děleny například dle jejich obsahu. Zdroj [1] předkládá následující dělení: -

„Střílečky“ – FPS (Firts person shooter)

-

Akční

-

Strategie – RTS (Real time strategy)

-

Dobrodružné – adventures

-

Hry na hrdiny – RPG (Role
Playing game)

-

Závodní

-

Sportovní

-

Simulační

-

Online

V tomto dělení se také vyskytuje kategorie on-line her. On-line hry mohou být dále děleny na všechny výše uvedené kategorie jako klasické offline hry, přestože některé kategorie nejsou pro on-line hry typické. Cílem projektu je navržení strategické hry, a proto je třeba tento typ přesněji definovat. Mezi strategie jsou řazeny takové počítačové hry, u kterých je ovládána větší skupina objektů a je s nimi manipulováno po hrací ploše tak, aby byla utrpěna co nejmenší újma na vitalitě, bojeschopnosti, údržbě objektů, zdrojů, území, jednotek, sil atp. Zároveň je tato újma působena protivníkům. Strategie jsou kategoricky děleny do několika sfér podle obsahu a cíle, jenž je dán. Jednou podkategorií strategických her jsou budovatelské strategie, které představují takový podžánr, v němž se hráč soustředí na budování a ekonomiku místo na boj. Představitelé tohoto žánru jsou tvoření hrami, ve kterých hráč jako plánovač a vůdce řídí město nebo osadu a usiluje o její rozkvět, jak uvádí [10].

2.1. Dělení online her Dle zdroje [2] jsou do on-line kategorie her řazeny takové počítačové hry, které umožňují hraní po internetu. Hra je buď pro tento styl hraní přímo navržena, nebo nabízí

3

tento způsob hry jako druhou možnost vedle hry pro jednoho hráče bez potřeby připojení k síti. Hry vyvíjené přímo pro hraní po internetu (někdy označované zkratkou OMG: online multiplayer game) jsou děleny do několika kategorií: -

MUD (Multi-User Dungeon – tradiční hra pro více hráčů hraná prostřednictvím textového rozhraní)

-

MMOG

(Massively-Multiplayer

Online

Game

–

modernější

s grafickým rozhraním; podle žánru se dělí na: o MMORPG (Massively-Multiplayer Online Role Playing Game) o MMORTS (Massively-Multiplayer Online Real-Time Strategy) o MMOFPS (Massively-Multiplayer Online First Person Shooter) -

Webové hry – hry ovládané pomocí běžného webového prohlížeče

4

obdoba

3. Současná nabídka online webových her Mezi

zástupce

MUD

patří

například

hra

LiT

(Lost

in

Time).

Jedná

se o víceuživatelskou on-line hru, kde hráč potkává desítky dalších hráčů a bojuje proti nástrahám rozsáhlého fantasy světa, nebo proti svým protihráčům. LiT je dlouhodobý neustále se rozšiřující herní projekt sahající až do roku 1995, kdy se internet v ČR teprve rozšiřoval a je tedy pravděpodobně nejstarší internetovou hrou na českých serverech [3]. Mezi nejznámější a nejrozšířenější zástupce MMOG patří hra Ragnarok. Herní možnosti Ragnaroku jsou velmi rozsáhlé. Hráč začíná jako nováček (novice), ze kterého přechází na jedno ze šesti základních povolání (1st class). Na tato povolání následně navazují tzv. 2nd class povolání, a tak si hráč v této hře z celkem 39 různých povolání. Postavy těchto povolání dále užívají mnoha stovek dovedností (skillů), předmětů, zbraní, zbrojí a lektvarů. Hráč se svou postavou navštěvuje rozmanitá města, pouště, pralesy či jeskyně plné příšer a tajemných bytostí od nejslabších, až po nejstrašlivější monstra. Cíl hry spočívá především v získávání zkušeností a zdokonalování dovedností vybraného povolání.

Ragnarok dále

nabízí hráčům rozmanité možnosti vzájemné interakce. Ve hře lze nalézt party systém, gildy, chat, grafické emotikony a další možnosti předávání zpráv. Hráči je povoleno ochočit a chovat zvířecího pomocníka, plnit úkoly, pomáhat začínajícím hráčům nebo se účastnit guildových válek, dobývat hrady a stát se nepřemožitelným hrdinou. Hru Ragnarok od roku 2003 v ČR propaguje projekt CzechRO [4]. Jednou z nejznámějších webových her současnosti se v ČR stává Travian. Cílem hráče je budování co možná nejvíce prosperujících a bojeschopných vesnic a na vlastní riziko, nebo jako součást větší aliance - ničení menších osad a aliancí. Tímto tématem je v současné době inspirováno více webových her, jako například Divoké kmeny, StarGate nebo WebGame. Jejich detailních popisem se tato práce nezabývá. Do výčtu webových her je ještě zařazena známá hra Bitte Fight, ve které hráč na začátku volí, stane-li se upírem nebo vlkodlakem. Jako člen jednoho z těchto dvou táborů usiluje o co nejvyšší skóre dané rasy. Při dalším hledání webových her jsou nacházeny především populární flashové aplikace, jejichž zaměření lze dělit dle druhé kapitoly této práce. Dále uvádíme citaci, podle níž není snadné vhodnou hru pro děti a mládež sehnat. „Ano, je problém sehnat ‘nezávadnou‘ hru. Hru, ve které není krev a násilí (sexu je ve hrách jako šafránu) [5].“ Pro další práci je brán na zřetel předpoklad, že nabídka online her pro děti nižšího věku je silně nedostatečná a nevyhovující.

5

6

4. Požadavky na hry pro děti a mládež Jedním z úkolů této práce je prozkoumání a nalezení požadavků, které jsou kladeny na hry pro děti a mládež. Nalézání těchto požadavků je velmi nesnadné, neboť se jimi málokterá organizace nebo skupina lidí zabývá. Při hledání požadavků nalézáme spíše kritiku rodičů a organizací stávajících her. Přesto bylo zjištěno, že požadavky kladené na hry pro děti a mládež, jasně překládá PEGI (Pen European Game Information).

4.1. Klasifikační systém PEGI Jedná se o systém celoevropské informace o hrách klasifikující vhodnost interaktivních her. Účelem systému je zabezpečení přístupu mládeže pouze ke hrám, které jsou vhodné pro danou věkovou kategorii. Systém má podporu nejen všech hlavních výrobců hracích konzol, ale rovněž autorů her a vývojových programátorů interaktivních herních systémů po celé Evropě. Systém byl vyvinut Evropskou federací pro interaktivní software (Interactive Software Federation of Europe – ISFE). Cílem Evropské komise je nasazení tohoto systému jako modelu evropské harmonizace pro ochranu dětí a nezletilých osob na úseku společenských her. Systém PEGI byl uveden na trh v roce 2003 a nahrazuje předcházející národnostní klasifikační systémy vhodnosti her pro mládež. Klasifikace vhodnosti je uvedena na přední i zadní straně obalu interaktivních her. Systém PEGI je složen ze dvou oddělených, vzájemně se doplňujících prvků. První z nich klasifikuje vhodnost pro věkové kategorie 3+, 7+ 12+, 16+ nebo 18+. Druhý z nich vyjadřuje jednu nebo více charakteristik hry. Ikony na zadní straně obalu pak tyto charakteristiky znázorňují. Pro vyjádření žánru hry obsahuje systém PEGI až šest ikon. Působnost charakteristiky hry poté odpovídá klasifikaci vhodnosti pro určitou kategorii mládeže. Kombinováním klasifikace věkové vhodnosti a charakteristiky hry je umožněno rodičům a osobám vybírajícím hry dosáhnout ujištění, že určitá hra je přiměřeně vhodná věku uživatele. PEGI je navržen tak, aby odpovídal měnícím se kulturním normám a postojům napříč světovými zeměmi. Je také podporován většinou vládních agentur příslušných států a všemi organizacemi obchodujícími s interaktivním softwarem.

7

Obr. 4.1. Piktogramy PEGI Klasifikace PEGI je dobrovolná. Hodnocení je prováděno přímo členy herního průmyslu. Děje se tak prostřednictvím formuláře vlastního hodnocení. Ten je vyplněn vnitropodnikovým programátorem a na jeho základě hra získává hodnocení vhodnosti. Pro každou obsahovou kategorii je na základě odpovědí programátora stanoven přiměřený věk. Hodnocení

navržené

vydavatelem

je

prověřeno

nizozemským

institutem

pro hodnocení audiovizuálních médií (Netherlands Institute For The Classcification of Audiovisual Media – NICAM). Hry, u kterých je navrženo hodnocení 16+ nebo 18+, jsou před potvrzením ohodnocení prověřeny. Hry s hodnocením 12+ a namátkově vybrané hry 3+ a 7+ jsou prověřeny po potvrzení ohodnocení. Na konci tohoto procesu udělí NICAM v zastoupení evropské federace ISFE licenci k užívání loga a možných charakteristik [6].

4.2. PEGI Online PEGI Online je novým doplňkem výše uvedeného systému PEGI. Klade si za účel poskytnout mládeži větší ochranu před nevhodným herním obsahem. Licenci k vyobrazování loga PEGI Online uděluje správce tohoto systému jakémukoli poskytovateli online her, jenž splňuje požadavky stanovené kodexem bezpečnosti PEGI Online (PEGI Online Safety Code – POSC). Požadavky se týkají povinnosti chránit webové stránky před nelegálním a nepřístojným obsahem vytvářeným uživateli a nežádoucími odkazy, jakož i zajištění opatření na ochranu mladých lidí a jejich soukromí v průběhu hraní online her.

Obr. 4.2. Logo PEGI online

8

Kodex bezpečnosti POSC je zpracován za účelem podpory minimální úrovně ochrany, jež by měla být mladistvím poskytována v prostředí online her. Správci systému, kteří přijmou tento kodex, se zavazují k odstranění nevhodného materiálu ze svých stránek a k zajištění patřičného chování uživatelů. V důsledku toho jim je povoleno, po registraci v systému PEGI, zobrazovat na stránkách svých webových aplikací logo PEGI Online. Aby systém zobrazující logo PEGI Online splnil hlavní ustanovení kodexu, musí obsahovat pouze hry, jejichž obsah byl patřičně ohodnocen regulérním systémem PEGI. Hráčům musí být umožněno ohlásit existenci nevhodného obsahu na jakýchkoliv souvisejících webových stránkách. Držitelé licence jsou dále povinni zajistit, aby spravované online služby byly chráněny před nelegálním, urážlivým, rasistickým, ponižujícím, korupčním, výhružným a obscénním obsahem. Jakýkoliv držitel licence PEGI Online je povinen shromažďované osobní informace od uživatelů chránit v souladu se zákony Evropské unie. Dále jsou držitelé povinni při reklamní politice uplatňovat zásady tak, že veškeré reklamy musí přesně odrážet povahu a obsah prezentovaného produktu, případně i jeho hodnocení. Reklamy musí být vytvářeny se smyslem pro zodpovědnost vůči veřejnosti. Nesmí obsahovat žádnou skutečnost, jež by mohla být příčinou závažného či rozsáhlého deliktu. Reklamy s hodnocením 16+ nebo 18+ nesmí být zaměřeny na ty, kteří jsou mladší. Další doplňkové či samostatné produkty, jež jsou propagovány spolu s hlavním produktem, musejí být vhodné pro uživatele, pro něž je určen hlavní produkt. Držitelům licence PEGI Online je dále doporučeno, aby prostřednictvím všeobecného prohlášení veřejnost informovali o sponzorování a/nebo reklamě související s jakoukoliv online službou [7].

4.2. Shrnutí požadavků kladených na hry pro děti a mládež Po prostudování výše uvedených požadavků je zřejmé, že hra by neměla děti učit používat k dosažení svých cílů násilí a intrikářství. Budou-li dětem tato témata předkládána, mohou se tyto metody stát jakousi normou v chování, což nelze považovat za stav, o jehož dosažení společnost usiluje. Existenci her s touto tématiku však nelze zabránit. I mezi těmito interaktivními systémy se nacházejí velmi kvalitní softwarové projekty, které však nejsou a nemohou být primárně určeny pro mladší děti. Jako příklad těchto systémů lze předložit nedávno uvedenou hru Zaklínač (Wiedźmin). Hra byla hráči rychle přijata a pozitivně hodnocena kritikou. Byla

9

ale také klasifikována systémem PEGI jako vhodná pro starší 18 let. Již na obalu hry nalezneme informace o přítomnosti násilí ve hře [8]. Z pedagogického hlediska je vhodné, aby hry pro děti pomáhaly při rozvoji logického myšlení a získávání nových informací. Hra může pomoci dítě naučit logicky uvažovat, zvažovat různé klady a zápory jednotlivých řešení a nést odpovědnost za jejich provedení. V budoucím životě mladých lidí jsou často mnohá rozhodnutí závažná a nezvratná, proto je může hra na tyto situace nenásilnou formou alespoň minimálně připravit. V této práci byla při vývoji hry pro děti dodržována tato pravidla. Hra by měla: -

být prostá násilí, intrikářství a sexu

-

napomáhat rozvíjet myšlení

-

vhodným způsobem rozšiřovat znalosti o problému, na který je zaměřena

10

5. Téma navrhované hry versus požadavky na tyto hry Rámcové téma hry vyplývající ze zadání práce je zaměřeno na budování zoologické zahrady a péči o zvířata v této zahradě umístěná. V této kapitole bude nastíněno, jak lze výše deklarovaným požadavkům při tomto tématu vyhovět. Již z primárního zaměření hry je patrno, že hra je zařazena do kategorie budovatelských strategií, kde násilí nehraje žádnou významnou roli, a tak lze vhodným definováním herních možností násilí ze hry odstranit úplně. Bude-li hra navržena tak, aby cílem hráče byla co nejvyšší prosperita vlastní zoologické zahrady, nebudou se v této vyskytovat ani možnosti podvodu a intrikaření (nevylučující taktizování). Nevhodný sexuální materiál se ve hře o zoologických zahradách objeví jen stěží. Rozšiřování znalostí uživatelů (dětí) může být zajištěno zobrazováním základních informací o každém zvířecím druhu vyskytujícím se ve hře. Mezi tyto informace bude patřit jméno v českém případně latinském jazyce, místo výskytu, životní sty, průměrný dožívaný věk a typická potrava. Z výše uvedených argumentů je zřejmé, že téma zoologických zahrad požadavky kladené na hry pro děti a mládež může splňovat. S ohledem na uvedené skutečnosti byla započata práce na analýze a návrhu hry.

11

12

6. Jazyk UML UML je univerzální jazyk pro vizuální modelování systémů a lze jej využít nejen při modelování objektově orientovaných softwarových projektů. Tento jazyk byl navržen tak, aby spojil nejlepší existující postupy modelovacích technik a softwarového inženýrství, ale jako takový nenabízí žádný druh metodiky modelování. Také proto není jazyk UML vázán na žádnou specifickou metodiku nebo životní cyklus systému. Přesto je ovšem jazyk UML přednostně využíván ve spojení s metodikou UP, protože cílem jazyka UML a metodiky UP je od jejich vzniku podpora nejlepších postupů používaných v softwarovém inženýrství, jak uvádí zdroj [9].

6.1. Historie UML Do roku 1994 existovalo několik soupeřících jazyků a metodik pro vizuální modelování. Prvním pokusem o sjednocení byla metodika Vision. Do její přípravy však nebyly zapojeni autoři metod, které tvořily podstatnou část tehdejšího trhu a tato metodika zanikla ve chvíli, kdy se autoři tehdy významných metod spojili ve firmě Rational Corporation, která pracovala na tvorbě jazyka UML. V roce 1996 předložilo sdružení Object Management Group, dále jen OMG, specifikaci Request For
Proposal (RFP), v níž jako standart pro vizuální modelování navrhlo jazyk UML. Od té doby všechny soupeřící metody postupně upadaly a jazyk UML byl veřejností plně přijat [9].

6.2. Budoucnost UML Budoucnost jazyka UML může být definována skrze poslední aktivitu organizace OMG nazvanou MDA. Architektura MDA definuje představu vývoje softwaru na základě modelů. Podle MDA je software vytvářen jako sled transformací modelů prováděných v modelovacím nástroji. Z pohledu této architektury je zdrojový kód programu pouze určitým specifickým modelem systému. Dnes používané MDA nástroje jsou v ojedinělých případech schopné generovat 70-90% kódu [9].

13

6.3. Modelování v jazyce UML Objektové

modelování

považuje

svět

nebo

systém

za

skupinu

vzájemně

se ovlivňujících objektů. Objekty pak obsahují určité informace a vykonávají různé funkce. Skupina modelů v jazyce UML tedy obsahuje statickou strukturu systému, ve které stanoví, jaké typy objektů jsou podstatné a jaká je mezi nimi souvislost, a dále pak dynamickou strukturu, ve které zachycuje spolupráci jednotlivých objektů při zajišťování funkcí daného systému. K tomu jazyk UML využívá tři základní stavební bloky a to Předměty, Relace spojující tyto objekty a Diagramy, znázorňující zajímavé pohledy na systém.

14

7. Unified Process Metodika UP se zrodila jako vyspělý a otevřený standard tvorby softwarového vybavení vyvinutý autory jazyka UML. Práce na této metodice započala již kolem roku 1967 tvorbou Ericssonova modelu, který vycházel z myšlenky, že složité systémy je třeba modelovat jako množiny vzájemně spojených a spolupracujících podsystémových bloků [9].

7.1. Postupy a fáze metodiky UP Metodika UP usiluje o přírůstkovou tvorbu robustní architektury navrhovaného systému a obsahuje pět základních pracovních postupů. Těmito postupy jsou: Požadavky Analýza Návrh Implementace Testování Přírůstková tvorba vytvářeného systému může v každém iteračním kroku obsahovat až všech pět pracovních postupů v závislosti na aktuálních požadavcích. Množství práce potřebné vykonat v jednotlivých iteracích, se ale přibližně řídí fází, ve které se vývoj softwarového díla nachází. Metodika UP také definuje 4 základní fáze vývoje softwarového díla, a to: Zahájení Rozpracování Konstrukce Zavedení Každá fáze vývoje definuje své vlastní cíle, kterými jsou ve fázi Zahájení - začátek práce na projektu, ve fázi Rozpracování je cílem vytvoření první spustitelné verze, ve fázi Konstrukce - převedení první verze na kompletní funkční systém a ve fázi Zavedení nasazení vytvořeného systému na provoz u uživatele [9].

15

16

8. Požadavky a jejich specifikace Hledáme-li požadavky na jakýkoli systém, stává se nám základním vodítkem tzv. odborný článek. Jedná se o text v přirozeném jazyce, zpravidla sepsaný odborníkem na danou problematiku nebo zadavatelem. V našem případě se stal autorem odborného článku řešitel práce. Rozborem tohoto článku získáváme strukturovaný katalog požadavků, který jednoznačně vymezuje požadavky na systém. Vyskytují-li se v tomto katalogu nejednoznačná slovní spojení nebo slova, je nutno sestavit také slovník pojmů, který jednoznačně definuje klíčové pojmy a terminologii pro daný systém, užívané pak po celou dobu práce na projektu. Pro další mapování požadavků kladených na systém slouží business process model (Model pracovních postupů) a Use Case diagram (diagram případů užití). První model z výše jmenovaných, slouží k jednoduchému zachycení pracovních postupů a vyznačení, kterými postupy sledujeme jaké cíle. Diagramy případů užití znázorňují, v jakých situacích uživatelé daný systém používají. Při zpracování tohoto diagramu je nutné dbát, aby všechny požadavky zachycené ve strukturovaném katalogu požadavků odpovídaly alespoň jednomu případu užití.

8.1. Slovníček pojmů Administrátor Administrátorem se rozumí osoba s vyššími přístupovými právy, mezi jejíž privilegia patří čtení, změna, mazání i přidávání systémových dat. Finanční prostředek Finančním prostředkem se rozumí zůstatek uživatelova konta v herní měně ZLK (Zoolák). Nejedná se o žádnou reálnou finanční hotovost. Hráč Hráčem se rozumí standardní uživatel systému, který vlastní jednu zoologickou zahradu a pečuje o její rozvoj. Konto Kontem se rozumí finanční konto hráče v herní měně. Nejedná se o žádnou peněžní formu.

17

Nálada zvířete Nálada zvířete je virtuálním ukazatelem jeho stavu, který reflektuje, jak je o zvíře postaráno. Její nízká bodová známka se negativně projevuje na návštěvnosti zahrady. Návod Návodem ke hře se rozumí veškeré informace potřebné pro správné strategické rozhodnutí hráče za cílem dosažení co nejlepšího herního výsledku. Návštěvnost zahrady Návštěvnost zahrady je virtuálním měřítkem pro přidělování finančních prostředků na konto hráče. Je imaginárním počtem zákazníků, kteří hráčovu zahradu navštíví. NPC Non-player-character (Nehrající postava) – zde zastupuje obchodníka prodávajícího a odkupujícího zvířata. Obchoduje i se zaměstnanci. Parcela Parcelou rozumíme prostor pro postavení pavilonu. Pavilon Pavilonem rozumíme virtuální stavbu, do níž smíme umisťovat zvířata daného druhu. Popularita zvířete Popularita zvířete je ukazatelem jeho vycvičenosti a její vysoká známka se pozitivně projevuje na návštěvnosti zahrady. Pozemek Pozemkem rozumíme část zahrady, na níž je definovaný počet parcel pro postavení pavilonů. Profil Profilem rozumíme osobní data a informace o hráči. Některá z nich mohou být viditelná všem účastníkům systému, jiná nikoli. Registrace Registrací rozumíme úspěšné uložení informací o hráči do systému. Stavební úprava Stavební úpravou rozumíme vystavění nebo zboření pavilonu Systémová data Systémovými daty rozumíme informace o hře, herní manuál, tutoriál, data o zvířatech a jejich druzích, data o zaměstnancích a jejich profesích.

18

Tutoriál Tutoriálem rozumíme stručný návod, jak začít hrát. Tedy seznámení hráče s prvními kroky hry. Účet Účtem rozumíme data uložená v systému po úspěšné registraci uživatele. Tedy jeho profil a informace identifikující jeho zvířata a zahradu. Účet svému majiteli zajišťuje přístup do herního systému. Na serveru smí každý hráč vlastnit pouze jeden účet. Záchranný odchyt Záchranným odchytem se rozumí možnost hráče získat zvíře odchytem ohrožených druhů z divočiny. Hráč pro účast na tomto odchytu musí zaměstnávat specifický druh zaměstnance. Zaměstnanec Zaměstnanec je virtuální člen zahrady pečující o zvířata nebo umožňující další aktivity. Rozlišujeme 4 profese zaměstnanců - uklízeč, ošetřovatel, cvičitel a lovec. Zoo (Zahrada, Zoologická zahrada) Zahradou rozumíme virtuální prostor pro stavbu pavilonů a následné umisťování zvířat. Zahrada se stává spojením několika pozemků. Zpráva Zprávou v systému rozumíme informační elektronický text přidružený k účtu hráče. Hráči si mohou zprávy zasílat mezi sebou nebo jsou pomocí nich informování o důležitých věcech nastalých v systému. Potom jsou tyto zprávy automaticky generovány a doručovány systémem.

8.2. Odborný článek Uvedený článek slouží k nástinu možností a pravidel jednoduché budovatelské strategie pro děti. Interaktivní systém, pracovně označený jako Zooland, je webová hra s námětem zoologických zahrad určená primárně pro hráče ve věku 7 – 12 let. Cílem hry je vytvoření vlastní zoologické zahrady s co nejrozličnějším počtem pavilonů a v nich umístěných zvířat, což vede k velké návštěvnosti zahrady. Ve hře mají hráči možnost spolu komunikovat prostřednictvím zasílaných zpráv. Zaregistrovanému hráči je na startu hry přidělen pozemek odpovídající 1/9 maximální rozloze zahrady. Na každé z 9ti částí zahrady se nalézá předem definovaný počet stavebních

19

parcel. Na těchto parcelách je možné postavit různorodé pavilony za předem stanovená ceny a poté do nich umísťovat zvířata. Získání zvířat se děje dvojím způsobem. V prvém případě může být zvíře jednoduše zakoupeno prostřednictvím NPC obchodníka. Cena zvířat je zde pevně dána s dilatací dle stavu zvířete. Nabídka obchodníka je doplňována pokaždé, klesne-li počet nabídek pod určenou mez. Prodej zvířete NPC obchodníkovi je možný za sníženou nákupní cenu. Druhým způsobem zisku zvířete je účast na záchranném odchytu zvěře z divočiny. Aby bylo možné se tohoto lovu účastnit je nutné zaměstnat v zahradě Lovce. Problematice zaměstnanců se věnujeme níže. Pokud hráč zaměstnává lovce, může se přihlásit na libovolný odchyt s předem určeným cílem. Cíl odchytu ovlivňuje jakou zvěř je možné odchytit. První z účastníků lovu se stává jeho pořadatelem. Náklady na stravu zvěře jsou pravidelně odčítány z finančního konta hráče. Hráč se dále stará o to aby v pavilonech byl optimální počet zvířat. Přeplnění, nebo naopak nízký počet jedinců daného druhu v pavilonu se negativně projevuje na náladě zvířete. Zvíře je také možno cvičit a tím zvýšit jeho popularitu. Má-li hráč od jednoho druhu zvířete pár, může zvířata spárovat a po uplynutí doby březosti daného zvířecího druhu očekávat mláďata. Pravděpodobnost úspěchu je ovlivněna náladou zvířat a jejich druhem. Finanční prostředky pro rozvoj zahrady jsou hráči přidělovány na základě výsledku hodnotící rovnice která je mimo rámec tohoto článku. Hráč by měl v zahradě zaměstnávat Lovce kteří mu umožní účast na odchytech a na každých několik zvířat jednoho ošetřovatele.Posledním typem zaměstnance je uklízeč. Je-li nedostatek ošetřovatelů nebo uklízečů projevuje se tato situace negativně na náladě zvířat.

8.3. Strukturovaný katalog požadavků Při sestavování katalogu požadavků se zaměřujeme na odhalení funkčních a nefunkčních požadavků kladených na systém. Funkční požadavky nám sdělují, co systém bude dělat. Nefunkčními požadavky se rozumí omezení a nároky kladené na vyvíjený systém. Pozornou studií odborného článku byl sestaven takovýto katalog požadavků: FUNKČNÍ POŽADAVKY 1. Správa účtů 1.1. Registrace

- umožňuje registraci do systému

20

1.2. Mazání vlastního účtu

- umožní zaregistrovanému hráči smazat svůj účet

1.3. Změna vlastního profilu - umožňuje změnit údaje zadané při registraci 1.4. Přihlášení

- umožní registrovaným hráčům vstup do systému

1.5. Odhlášení

- umožní přihlášenému uživateli ze systému odejít

2. Získání informací 2.1. O ostatních hráčích 2.2. O herních možnostech 2.3. O pozemcích 2.4. O vlastní ZOO 2.5. O výsledcích 2.6. O pavilonech 3. Obchod 3.1. Obchod s pozemky

- umožňuje nakupovat a prodávat pozemky v zahradě

3.2. Obchod se zvířaty

- umožňuje nakupovat a prodávat zvířata

4. Stavební úpravy

- stavba a zbourání budov (pavilonů)

5. Zajišťování a správa zaměstnanců

- najímání a propouštění zaměstnanců

6. Účast na záchranných odchytech

- účast nebo organizace odchytu zvěře

7. Zasílání a správa zpráv

- umožňuje komunikaci mezi hráči

8. Výměna a půjčování zvířat

- umožňuje měnit a půjčovat zvířata

9. Správa druhů zvířat

- umožní administrátorům spravovat druhy zvířat

10. Administrátorská správa

- umožňuje administrátorům zobrazovat a měnit libovolná data

NEFUNKČNÍ POŽADAVKY 1N. Pouze online přístup s využitím internetového připojení a webového prohlížeče 2N. Zabezpečení přístupu a uložených hesel 3N. Zaručená funkčnost v Mozzile Firefox 4N. Vícevrstvá architektura zajišťující oddělenou práci s daty a zobrazovacími prostředky

21

8.4. Business process model Pro názornou představu o cílech systému a procesech, které vedou k dosažení k těmto cílům, byl sestaven model pracovních procesů. Na tomto modelu je jasně zřejmé, jaké kroky může uživatel systému činit pro dosažení určitého výsledku. Jedná se tak vlastně o model pravidel hry z pohledu uživatele. Obecně není nutné tento model používat pouze ke znázornění pracovních procesů uvnitř softwarového systému. Jako příklad lze uvést pracovní postup odesílání e-mailové zprávy interní podnikovou sítí. Přesun zprávy vnitropodnikovou sítí je problém řešený v rámci systému zajišťující elektronickou firemní komunikaci. V modelu pracovních postupů se však objeví i proces „napsaní e-mailové zprávy“, kterou zjevně zajišťuje lidský faktor, nikoli vytvářený systém. V našem modelu pracovních procesů je však cílem znázornit příbuznost procesů, zajišťovaných vytvářeným systémem, pro snadnější představu o možnostech systému.

analysis Prodat zv íře

Výběr zv ířete k prodej i

ANO

NPC obchodníkovi?

NE

Stanov ení prodej ní ceny

Potv rzení prodej ní ceny

Prov edení prodej e

Potv rzení a nabídnutí zv ířete k prodej i

«goal» Prodej zv ířete

Obr. 8.1. Postup pracovních procesů při prodeji zvířete

22

8.5. Use Case diagramy Use Case diagramy (diagramy případů užití) zachycují jednotlivé možnosti, kterými uživatel systém využívá. Pomocí těchto digramů lze také zachytit, jací uživatelé náš systém používají. Pomocí scénářů těchto případů srozumitelnou formou popíšeme, jaké akce očekáváme od systému a uživatele k úspěšnému průběhu daného případu užití. Tento scénář slouží jako pomůcka programátora při implementaci daného případu. S užitím scénáře získává programátor přehled, jaké funkce je třeba v systému definovat. Sestavování Use Case diagramů se přísně řídí požadavky, které jsou podchyceny ve strukturovaném katalogu požadavků. Jak již bylo výše podotknuto, je třeba zajistit, aby veškeré funkční požadavky, kladené na systém, mohli aktéři – uživatelé systému obsloužit. Podle požadavků popsaných v kapitole 8.3. byly pro náš interaktivní systém navrženi tito uživatelé systému a tyto případy užití: Aktéři:

Administrátor Hráč

Případy užití:

Zahrada:

UC16-ZakoupitPozemek UC26-PostavitPavilon UC27-ZbořitPavilon

Zvířata:

UC43-SpárovatZvířata UC14-ZakoupitZvíře UC15-ProdatZvíře UC18-VyměnitZvíře UC19-ZapůjčitZvíře

Zaměstnanci: UC30-NajmoutZaměstnance UC31-PropustitZaměstnance UC33-PřiřaditCvičitele UC34-OdebratCvičitele Odchyt:

UC44- VytvořitTermín UC24-PřihlásitNaTermín UC25-Odhlásit_z_termínu

Informace:

UC10-Vlastní Zoo UC8-Pozemek 23

UC9-Pavilon UC11-Tutoriál UC12-Výsledky UC13-ZměnitTutoriál Komunikace: UC20-ZaslatZprávu UC21-ČístZprávu UC22-SmazatZprávu Správa účtů: UC1-Registrovat UC2-Přihlásit/Odhlásit UC3-ZměnitVlastníProfil UC4-SmazatVlastníÚčet UC5-SmazatLibovolnýÚčet UC6-ZměnitLibovolnýProfil UC7-ZapsatNovéhoAdministrátora Admin:

UC40-PřečístLibovolnáData UC41-ZměnitLibovolnáData UC42-PřidatZvířecíDruh

uc Zv ířata Zvířata

UC14-ZakoupitZv íře

UC15-ProdatZv íře

Hráč (from Actors)

UC18-VyměnitZv íře

UC43Spárov atZv ířata

UC19-Zapůj čitZv íře

Obr. 8.1. Příklad Use Case diagramu

24

Takto sestavené diagramy jsou dále upřesněny popisem jednotlivých případů užití a dále sestavením scénářů ke každému jednotlivému případu nebo skupině obdobně probíhajících případů užití. Pro sestavení popisů a scénářů neexistuje jasně definovaná norma a styl. Tyto slouží především k větší informovanosti zainteresovaných osob, a tak kladou důraz především na obsah nikoli styl. Při vytváření scénářů a jejich doplňování došlo k situaci, že některé tyto diagramy mají dva i více scénářů. Tato situace by se měla řešit rozdělením případu užití na více případů tak, aby mezi nimi vznikla vazba extend. Vzhledem k omezenému časovému rozsahu práce již však diagramy nebyly přepracovávány. UC43-SpárovatZvířata Umožňuje hráči pářit zvířata v rámci své zahrady. Scénář Páření Hráč při zobrazeném seznamu zvířat volí volbu najít partnera. (možnost je neaktivní u příliš mladých nebo starých zvířat a u samic březích a nedávno pářených). Systém zobrazí seznam možných zvířat do páru. Po výběru protějšku je určen úspěch páření. Při úspěchu je samice označena za březí a po uplynutí doby březosti rodí mláďata.

UC14-ZakoupitZvíře Zvíře lze zakoupit od NPC obchodníka nebo ze seznamu nabídnutých zvířat, kam je přidávají hráči. Při nedostatku nabídek jsou tyto generovány systémem. Scénář Nákup od protihráče Stejná jako NPC jen jsou zobrazena zvířata, která jiní hráči chtějí prodat. Odečtená suma od hráče A je přičtena na konto hráče B. NPC obchodník Případ spuštěn požadavkem hráče. Je zobrazen seznam zvířat, která jsou prodejná. Hráč si vybere zvíře a potvrdí jeho nákup. Z jeho finančního konta je odečtena požadovaná suma. 25

Zvíře je přivlastněno hráčem a přímo umístěno do pavilonu. UC15-ProdatZvíře Zvíře lze prodat buď NPC obchodníkovi za paušální cenu (50% z nákupní ceny) nebo jej odkoupí jiný hráč, když je zvíře nabídnuto k prodeji. Nabídky učiněné hráčem lze zrušit. Hráč má tedy možnost vidět seznam učiněných nabídek. Scénář Nabídnutí k prodeji pro jiné hráče Hráč vybere zvíře k prodeji. Hráč určí zda prodává NPC nebo nabízí pro jiné hráče. Hráč zadá cenu, za jakou je ochoten zvíře prodat. Zvíře zůstává majetkem hráče, ale po odsouhlasení nabídky jiným hráčem je mu změněn vlastník a hráči 1 je částka přičtena, hráči 2 odečtena. Prodej NPC Hráč vybere zvíře k prodeji. Hráč určí, zda prodává NPC nebo nabízí pro jiné hráče. Je mu zobrazen dotaz na odsouhlasení ceny. Zvíře přechází NPC, hráči je připsána na účet odpovídající suma peněz. UC18-VyměnitZvíře Výměna je interakcí dvou uživatelů. Scénář popisuje výměnu jak ze strany nabízejícího, tak ze strany hráče, který nabídku přijímá. Výměna umožňuje vyměnit zvířata mezi hráči 1:1. Scénář Akceptování nabídky – provedení výměn Hráč zobrazí seznam zvířat k výměně. Vybere jednu nabídku a je dotázán na potvrzení. (Nabídky které nemůže přijmout jsou deaktivovány.) Po potvrzení nabídky jsou oběma zúčastněným zvířatům změněni vlastníci. Nabídnutí zvířete – pomocí volby „vyměnit“ u každého zvířete Analogicky, jako ze seznamu, jen se vyplňuje i zvíře, které bude směňováno.

26

Nabídnutí zvířete – ze seznamu zvířat Při zobrazeném seznamu zvířat hráč volí možnost vyměnit. Hráč volí, za jaké zvíře chce svoje zvíře vyměnit. Po vyplnění je zobrazen dotaz na potvrzení. Po potvrzení zvíře zůstává ve vlastnictví hráče, ale při přijmutí nabídky je přivlastněno druhým hráčem. UC19-ZapůjčitZvíře Systém umožňuje zapůjčování zvířat mezi zahradami výlučně za účelem páření zvířat. Po vystavení nabídky je tato platná po akceptování druhým hráčem. Scénář Nabízím samce Hráč vybere samce, kterého může zapůjčit. Hráč zadá do formuláře cenu, jakou požaduje za půjčení. Zvíře je přidáno do seznamu zvířat, která mohou být půjčena. Požaduji samce k samici Hráč vybere, k jaké samici chce sehnat samce. Zadá, jakou sumu je ochoten za zapůjčení zaplatit. Systém po potvrzení nabídku uloží. Půjčuji samce Hráč zobrazí seznam požadavků Vlastní-li vhodného samce a souhlasí-li s platbou, akceptuje nabídku. Vybere vhodného samce. Je změněn dočasný majitel zvířete a je provedena transakce. Přijímám nabídnutého samce Hráč zobrazí nabídku samců, které si může k páření zapůjčit. Po výběru a potvrzení se hráč stává samcovým dočasným majitelem. Je provedena transakce mezi hráči.

27

Ke snadné orientaci ve vazbách mezi jednotlivými případy užití a požadavky, kterým se snažíme těmito případy vyhovět, slouží tzv. matice odpovědnosti (relationship matrix). Pomocí této pomůcky může analytik snadno sledovat, jakým požadavkům odpovídají jaké případy užití.

28

9. Analýza Záměrem analýzy je tvorba analytického modelu, který se zaměřuje na to, co musí systém udělat, ale nezabývá se detaily, jakým způsobem to dělá. Tyto detaily jsou řešeny později ve fázi návrhu. Hranice mezi těmito dvěma postupy je velice nejasná a tenká a závisí do značné míry na individuálním cítění analytika. Stejně tak můžeme říct, že se pracovní postup analýzy kryje s postupem získávání a upřesňování požadavků a nenásleduje tedy striktně až po něm. Potřebujeme-li některé požadavky upřesnit, často musíme nejprve danou část systému analyzovat. Výstupem pracovního postupu analýza je především diagram analytických tříd, který je tvořen klíčovými pojmy problémové domény. Vycházíme při tom z předešle vytvořených diagramů případů užití a jejich analýzou (a také analýzou strukturovaných požadavků), klíčové prvky systému odhalujeme.

9.1. Diagram analytických tříd Při sestavování diagramu analytických tříd je zpravidla velkým problémem nezahrnout do modelu jakákoli implementační rozhodnutí. Tato rozhodnutí provádíme až ve fázi Návrhu. Tento diagram je určen pro maximální počet zainteresovaných osob, a proto je nutné udržovat jej co nejjednodušší. Proto by do tohoto modelu měly být zahrnuty pouze třídy, které odrážejí pojmy ze slovníku pojmů pro daný systém. Bertrand Mayer ve své knize Object Oriented Software Construction (Tvorba objektově orientovaného softwaru) poukazuje na skutečnost, že neexistuje žádný jednoduchý a 100% spolehlivý algoritmus vedoucí k správnému nalezení analytických tříd [9]. Ten by totiž ve své podstatě zajišťoval neomylný postup návrhu a tvorby objektově orientovaného softwaru. Přesto existuje několik technik vedoucích ke správným závěrům. Mezi tyto postupy patří analýza textu, rozhovory s uživateli a experty příslušných domén. V našem případě byla použita metoda analýzy podstatných jmen a sloves aplikovaná na odborný článek. Jedná se o velmi snadno aplikovatelnou techniku, kdy podstatná jména a fráze jimi tvořené zpravidla vyjadřují třídy a jejich atributy, slovesa pak ukazují na odpovědnosti nebo operace tříd. Při sestavování modelu bylo rozhodnuto nezabývat se odpovědnostmi a operacemi jednotlivých tříd.

29

class Domain model 3

Typ_účtu Odchyt + + + +

cena_organizovani: int cena_ucastnik: int lokace: char na_zvire: int

+ +

0..*

1..*

je_majitelem 1

je_prijemcem Zpráv a datum: datetime 0..* obsah: text odesilatel: int predmet: char

Parcela

1

1

+ Účet vlastni adresa: char 0..1 heslo: char 0..* jméno: char prihlasovaci_jmeno: char + nabizi + 0..1 0..1 + zamestnava + 0..* +

+ 1 + + + 1

0..*

1..*

jmeno: char nalada: int pohlavi: int 0..* popularita: int vek: int

0..1

NPC_obchodnik

nazev: char plat_prumer: int prumerne_zvirat: int

Pav ilon

je_umisteno 0..1

0..*

1 Druh_zv ířete + + + + + +

je_zastavena 0..1

0..*

0..1

Profese + + +

1

nabizi

jmeno: char 0..* plat: int pocet_zvirat: int nabizi

obsazena: boolean

Zv íře

0..*

Zaměstnanec + + +

1

1..*

0..1

0..*

aktualizace: datetime stav: int

cena: int pocet_parcel: int

obsahuje 1 je_majitel

ucastni_se

+ + + +

jméno: char 1 návštěvnost: int

organizuje

Konto

+ 1..* +

je_tvorena

Zahrada + +

1

0..*

+ +

Pozemek

prava: int typ: int

naklady: int nazev: char popis: text prumerny_vek: int sance_odchyt: int sance_pareni: int

lze_umistit 1

1

1

Druh_pav ilonu + + + + + +

cena: int nazev: char nizky_pocet_zvirat: int popis: text pro_druh: int vysoky_pocet_zvirat: int

Obr. 9.1. Diagram analytických tříd - zmenšený Uvedené datové typy, nejsou konkrétními datovými typy implementačního jazyka. Jejich význam spočívá v usnadnění představy dané třídy.

9.2. Pravidla hry – diagramy aktivit Dle zadání práce bylo naším dalším cílem sestavit pro hru vlastní pravidla. Část zadání požadující vytvoření vlastních herních možností byla splněna navržením případů užití. Pro zachycení vnitřních pravidel hry byly užity diagramy aktivit. Tyto diagramy slouží k zachycení posloupností akcí a rozhodování při jejich řízení z pohledu systému. Dle zdroje [9] jsou diagramy aktivit objektově orientovanými diagramy toků. Díky nim lze zachytit proces jako kolekci aktivit a přechodů mezi nimi. Dle samého zdroje lze tyto diagramy připojit k mnoha modelovaným elementům a jejich použití pro modelování vnitřních postupů v systému tedy není v rozporu s metodikou UP a jazykem UML. Každý diagram aktivit začíná počátečním stavem a směřuje do stavu koncového. Mezi těmito dvěma stavy se nachází určitý počet aktivit, jež v našem případě představují

30

nedělitelnou činnost systému. V diagramu se mohou také vyskytovat dílčí aktivity, které v sobě zapouzdřují grafy vnořených aktivit. Ukončení každé aktivity vyvolává přechod do dalšího stavu. Podrobnější popis možností vytváření těchto diagramů můžeme nalézt v [9]. Pro hru bylo potřeba stanovit tato pravidla: -

přidělovaní finančních prostředků na konto hráče

-

generování nových zvířat

-

stanovení výsledku záchranného odchytu

-

stanovení úspěchu při páření zvířat

-

rození nových zvířat

-

smrt zvířat

-

výcvik zvířat

-

změna nálady zvířat

-

průběh registrace

9.2.1. Přidělování finančních prostředků na konto hráče Klíčovým pravidlem ve hře je přidělování finančních prostředků hráčům. Jejím jediným řídicím faktorem je návštěvnost zahrady, která symbolicky vyjadřuje počet návštěv v hráčově zahradě. Rovnice určující návštěvnost je navržena tak, aby zohledňovala rozmanitost zvířecích druhů v zahradě, počet zvířat, jejich cenu, náladu i popularitu. Cena zvířat byla určena dle zjištěných informací v obchodech s exotickými zvířaty nebo odhadem dle nákladů na krmivo pro jeden rok. Každý z výše uvedených činitelů má svoji váhu, kterou se podílí na celkovém výsledku hodnotící rovnice. Konstanty určující váhu činitelů byly určeny empiricky. Výsledná rovnice má tvar:

Navstevnost =

pocet _ druhu ⋅ ∑ [(cenai + popularita i ⋅ 100 + nalada i ⋅ 75) ⋅ 0,012] pocet _ pavilonu i

Cena zvířete nabývá hodnot v rozmezí 2-20000, popularita a nálada pak hodnot 0-5. Z rovnice jasně vyplývá, že není cílem mít v zahradě co možná nejvyšší počet nejdražších

31

zvířat, ale cílem hry se stává různorodost pavilonů a zvířat, správná péče o zvířata znamenající jejich dobrou náladu a pravidelné cvičení mající efekt na popularitu zvířat. Velikost příjmů se poté vypočte jako násobek návštěvnosti, což v podstatě symbolizuje vstupné pro virtuální návštěvníky. Násobící konstanta je opět určena empiricky. Pr ijem = Naklady ⋅ 2 Pro další zpestření hry se také s rostoucím počtem zvířat a zaměstnanců v zoologické zahradě navyšují náklady na její povoz. Výsledný zisk potom získáme jako odečtení příjmů a nákladů v dané zahradě. Náklady na provoz jsou dány součtem nákladů na krmení zvěře a platy zaměstnanců. Cena krmiva zvířat je určena jako zlomek reálných nákladů na krmení zvěře v zoologické zahradě v reálném světě. Potřebné číselné údaje byly čerpány z letáku Adopce zvířat v zoo – ZOO Dvůr králové. Pro názornost vkládáme několik z nich: Slon Africký

150 000Kč

Tygr ussurijský

120 000Kč

Nosorožec dvourohý

90 000Kč

Žirafa Rothschildova

45 000Kč

Gepard

40 000Kč

Levhart

30 000Kč

Lvíček zlatohlavý

25 000Kč

Pes ušatý

20 000Kč

Pelikán bílý

15 000Kč

Hadilov písař

12 000Kč

Ledňák obrovský

8 000Kč

Anakonda velká

6 000Kč

Antilopa koňská

6 000Kč

Krokodýl úzkohlavý

5 000Kč

Ara

4 000Kč

Varan smaragdový

3 000Kč

Sladkovodní ryby

2 000Kč

Tropické mořské ryby

1 500Kč

Chameleón jemenský

1 000Kč

Pralesnička

500Kč

32

Platy zaměstnanců byly stanoveny odhadem, a to v následujících sumách: Ošetřovatel

10ZLK

Uklízeč

5ZLK

Cvičitel

30ZLK

Lovec

100ZLK Výsledná rovnice pro stanovení nákladů má tento tvar:

Naklady = ∑ (naklady _ na _ krmenii ) + pocet _ osetrovatelu ⋅ plat o + pocet _ uklizecu ⋅ plat u + i

+ pocet _ lovcu ⋅ plat l Na základě daných rovnic již můžeme určit hráčův zisk a to pouhým odečtením nákladů a příjmů. Zisk = Pr ijmy − Naklady Přičtení herních finančních prostředků probíhá přírůstkově v daný čas spočtením, o kolik se při daném zisku změnil stav konta od poslední aktualizace. Přesné implementační rozhodnutí o načasování a provádění této aktualizace je nad rámec našeho návrhu.

33

act Obnov a stav u konta

ActivityInitial

Urči počet pav ilonů

Urči počet druhů

Naj di v šechna zv ířata

Poslední zmena konta

Urci zmenu

Spočti zisk Uloz zmeny

Spočti Náv štěv nost

Spočti Náklady

Spočti příj em

Naj di v šechny zaměstnance

ActivityFinal

Obr. 9.2. Obnova stavu konta – diagram aktivit

9.2.2. Záchranné odchyty Dle odborného článku, v němž byl nastíněn celý rámec hry, mají hráči možnost se účastnit záchranných odchytů zvěře ve volné přírodě. Hráč má možnost záchranný odchyt buď přímo organizovat, nebo se pouze účastnit. Organizátor lovu vybere ze seznamu ohrožených druhů zvíře, které se pokusí z divočiny zachránit, a za uspořádání lovu zaplatí cenu odpovídající průměrné ceně tohoto zvířete u NPC-obchodníka. Výsledná situace nastalá po uskutečnění odchytu se řídí níže uvedeným diagramem aktivit. V čase uskutečnění odchytu systém vypočte úspěch lovu dle rovnice, jejíž výsledek ovlivňuje počet účastníků a koeficient odrážející skutečnost, jak náročné je daný zvířecí druh odchytit. I v reálném světě by však při takovéto aktivitě skupiny lidí hrála určitou roli náhoda a štěstí. Tato situace je řešena následující rovnicí: Uspech _ lovu = Random _ num + pocet _ ucastniku + koeficient _ druhu _ zvere

34

Rozmezí náhodného čísla je stanoveno 0-10, počet účastníků 3-10, koeficient obtížnosti ulovení nabývá maximální hodnoty 5, která znamená velmi snadno ulovitelnou zvěř. Pokud je výsledek rovnice vyšší nebo roven číslu 12, byl odchyt úspěšný. Počet ulovených zvířat určíme takto: Pocet _ zvirat = Uspech _ lovu − 11 Následujícím problémem se stává přidělení ulovených zvířat jednotlivým účastníkům. Přidělování je řízeno počtem předešlých neúspěšných účastí na lovech. Hráči s nejvyšším počtem předchozích neúspěchů se dělí o ulovená zvířata. Ostatním je zvýšen počet neúspěchů, což jim de facto zajišťuje větší šanci na příštím odchytu.

act Odchyt

ActivityInitial

Výpočet úspěšnost

Urči počet chycených zv ířat

Úspěch?

NE

Odešli zpráv y o neúspěchu

Rozděl zv ířata

Odesli zprav u o v ysledku ActivityFinal

Obr. 9.3. Odchyt – diagram aktivit Ve hře se dále nacházejí pravidla určující úspěchy pokusů o páření zvířat, pravidla definující generování nových zvířat, jejich rození a úmrtí, pravidlo výcviku definující růst popularity zvířete a pravidlo určují změny stavu – nálady zvířat. Diagramy těchto pravidel jsou uvedeny v příloze tohoto dokumentu, neboť jejich detailní popis není pro účel tohoto podstatný.

35

36

10. Návrh V závěru vytváření konceptu vlastní hry pro děti a mládež byla použita část pracovního postupu Návrh. Dle metodiky UP je cílem tohoto pracovního postupu upřesňování postupu Analýzy vedoucí k detailním informacím o všech částech systému tak, aby byla možná jeho implementace. V zásadě můžeme v této chvíli postupovat dvěma směry. Můžeme se rozhodnout pro zachování analytické části modelu a vytvářet model upřesněný – návrhový. Výsledkem jsou pak dva modely, kde Návrhový vychází z předešle vytvořeného. Druhou možností, která byla užita v naší práci, je upřesňování analytického bez vytváření modelu nového. Nevýhodou této možnosti je ztráta analytické části. Dopad tohoto nedostatku na naši práci byl zhodnocen jako zanedbatelný. V této části vzniku softwarového díla bychom měli opět upřesnit případy užití a popsat jejich realizaci. Toho bylo v našem případě docíleno upřesňováním jednotlivých scénářů definujících průběh těchto případů. Diagramy všech případů užití včetně jejich scénářů nalezneme v příloze tohoto dokumentu. Dále můžeme specifikovat diagram analytických tříd sestavením diagramu tříd návrhových. Tyto třídy již neobsahují pouze základní atributy a nejzákladnější odpovědnosti, ale jsou přímým vzorem pro implementaci programátorem. Vzhledem k tomu, že naše práce je především analytická, nebyl tento model sestaven a implementační rozhodnutí se ponechává programátorovi.

10.1. Uživatelské rozhraní Návrh uživatelského rozhraní také patří k závěru práce při návrhu softwarového projektu. Vzhledem k tomu, že se jedná o hru pro děti nízkého věku, je třeba klást důraz na snadné ovládání, přehlednost a snadnou orientaci v systému. K tomu účelu byly sestaveny diagramy zachycující koncept několika základních částí systému. Pro sestavování Users interface diagramy nepředkládá jazyk UML ani metodika UP žádný předepsaný standard. Je tedy třeba zaměřit se pouze na srozumitelnost těchto digramů. Následující obrázek předkládá návrh hlavní herní obrazovky.

37

ui Hra Hlav ní herní

Logo

(from Zaklad)

Tvoji zahradu navštěvuje: Y denne

Tvoje zahrada vydělává X za CAS

Náklady na provoz zahrady jsou N za CAS

Hlavni strana

Zpávy

(from Zaklad) Manuál (from Zaklad) Tutoriál

Celkov á mapa zahrady dělená na pozemky

(from Zaklad) Odhlásit

Statistiky Informace o mojí zoo

Obr. 10.1. Users interface – návrh hlavní herní obrazovky Zde představený návrh uživatelského rozhraní není pro implementaci systému závazný. Slouží opět především k lepšímu pochopení navrhované hry.

38

11. Nasazení – diagram nasazení Dle zadání měl být při návrhu kladen důraz na snadnou rozšiřitelnost hry. Tu lze zajistit vícevrstvou architekturou našeho systému. Tento požadavek byl zahrnut již do strukturovaného katalogu požadavků. Proto byl dále sestaven diagram nasazení mapující základní návrh architektonické implementace. Ta spočívá v rozpoznání architektonicky významných komponent a jejich namapování na fyzický hardware. Jak můžeme vidět na jeho vyobrazení níže, náš systém by měl být nasazen na webový server a pomocí protokolu http komunikovat s klientským počítačem, na jehož straně neprobíhá žádná business logika (pracovní logika).

deployment Deployment Model

Serv er

Klient_PC

«execution environment» WebBrow ser

Presentation_layer

Business_logic

Data_acces_layer

DataBase

Obr. 11.1. Diagram nasazení - zjednodušený

39

40

12. Rozšiřitelnost hry Požadavku na snadnou rozšiřitelnost vyhovuje náš systém svojí vícevrstvou architekturou, která dovoluje přiměřeně snadným způsobem implementovat ve hře nové hráčské možnosti, nová pravidla či jejich úpravu. Pokud by systém nedodržoval vícevrstvou architekturu a záležitosti týkající se prací s daty a jejich zobrazením by se nacházely na stejné úrovni nebo dokonce ve stejných zdrojových souborech, byla by případná další orientace v těchto kódech a jejich úprava téměř nemožná.

41

42

13. Tutoriál ke hře Tutoriálem rozumíme stručný návod určený hráčům před zahájením hry. V tutoriálu se stručně zaměřujeme na osvětlení cíle hry a základní postupy hry, aniž bychom se podrobněji zabývali všemi možnostmi, které hra nabízí. V rámci tohoto dokumentu předkládáme textovou část tutoriálu bez doprovodných ilustrací.

13.1. Text tutoriálu Strana 1 Začínáš s malým pozemkem a tvým úkolem je vytvořit svoji vlastní jedinečnou a především prosperující zoologickou zahradu. Strana 2 K vybudování zahrady potřebuješ spoustu finančních prostředků v herní měně ZOOLÁKů. Každá zvíře Ti pomáhá zooláky vydělat, ale nezapomeň, že vydržování každého zvířete s sebou nese nějaké náklady. Strana 3 Než si do zahrady přivedeš první zvíře, je třeba mít pro něj připravený pavilon, terárium nebo výběh a najaté zaměstnance, kteří se o něj budou starat. Pavilony, zvířata i zaměstnance vybírej pečlivě. Strana 4 Jak se máš ve všech možnostech hry orientovat? Přímo z hlavní obrazovky můžeš: -

pracovat se všemi svými zvířaty (zvířata)

-

pracovat se všemi svými zaměstnanci (zaměstnanci)

-

informovat se o všem co právě probíhá (akce)

-

porovnávat se soupeři (výsledky)

-

odesílat a přijímat zprávy (zprávy)

-

zobrazit manuál ke hře (manuál)

-

začít budovat zahradu (vstup na pozemek)

43

44

14. Návod ke hře Aby se hráči mohli zorientovat ve všem, co jim hra nabízí a mohli činit zodpovědná rozhodnutí, je třeba vytvořit návod ke hře, obsahující souhrn všech informací o hře a jejich možnostech. Tento manuál je v současné době ve fázi tvorby. Nastiňujeme tedy pouze jeho strukturu s ukázkou několika textů, které ovšem tvoří jen část všech informací, jež je do návodu třeba vložit. Zde uvedené části návodu zachycují systém v zajímavých úhlech pohledu, a jejich uveřejněním může čtenář získat celistvější přehled o navrhovaném systému.

14.1. Hlavní strana návodu - rozcestník V tomto herním návodu nalezneš informace o: -

pavilonech, teráriích a výbězích (odkazuje na seznam všech budov ve hře)

-

zvířatech (odkazuje na seznam všech zvířat ve hře)

-

zaměstnancích (odkazuje na seznam všech profesí ve hře)

-

tvém zisku

-

nákupu zvířat

-

prodeji zvířat

-

odchytu zvířat

-

páření zvířat

-

půjčování zvířat

-

výměně zvířat

-

péči o zvířata

-

výcviku zvířat

-

stavbě pavilonů

-

rozšiřování zahrady

-

zasílání zpráv

45

14.2. Terárium chameleónů – část návodu Toto terárium je určeno pro chov chameleónů. Chameleón je tvor, který potřebuje vlastní teritorium. Protože je ale terárium dosti prostorné, chovej v něm nejlépe chameleóny dva. Cena terária je 100ZLK.

14.3. Chameleón jemenský – část návodu Tento druh chameleóna žije na zarostlých březích řek a jezer a zalesněných plošinách Jemenu a jihu Arabského poloostrova. Jeho vzhled je velice různorodý, ale základní barvou je zelená a hnědá. Barva chameleóna je závislá na mnoha faktorech. Mezi ně patří i zdravotní stav, nálada a okolní prostředí.Samec chameleóna má na zadních nohách od narození patrný osten. Dožívá se přibližně 5ti let. (Samice pouze 3) Živí se převážně hmyzem, ale je schopen pozřít i menší obratlovce, jako třeba myši. Chameleóni se líhnou z vajíček, kterých samice po úspěšném páření a jednom měsíci březosti naklade 20-40. Mláďata se líhnou po 6 měsících. Herní údaje: Průměrná cena:

10ZLK

Náklady na potravu:

10ZLK/rok

Průměrný věk:

4roky

Průměrný počet mláďat:

30

Po jaké době budou mláďata:

7měsíců

Ochota k páření:

mizivá

Šance na odchycení:

mizivá

46

14.4. Lovec – část návodu Lovec Ti umožní účastnit se záchranného odchytu ohrožených živočišných druhů z divočiny. Je to odborník na práci se zvířaty, a proto je jeho plat ze všech profesí nejvyšší. Herní údaje: Plat:

100ZLK

14.5. Tvůj zisk – část návodu Zisk tvé zahrady vniká rozdílem mezi příjmy a výdaji. Do výdajů se započítávají náklady na krmení zvěře a platy všech tvých zaměstnanců. Tvůj příjem rose přiměřeně k tomu, jaká je návštěvnost tvojí zahrady. Návštěvnost zahrady si sám dopředu nemůžeš spočítat, ale můžeš ji zvýšit výcvikem zvířat, správnou péčí o ně a také umístěním vzácnějších a dražších zvířat do své zahrady. Zisk, který tvoje zahrada přináší, se Ti na konto přičte na konci každého dne, který ve tvé zahradě uplyne za jednu hodinu.

14.6. Páření zvířat – část návodu Pokud máš ve svém pavilonu samce i samici nějakého zvířecího druhu, můžeš se pokusit vychovat mláďata. Úspěch tvého snažení závisí na náladě – stavu obou zvířat a na tom, jak ochotně se daný zvířecí druh páří. Pokud budeš úspěšný, po určité době se ve tvém pavilonu objeví nová zvířata.

14.7. Výcvik zvířat – část návodu Výcvik zvířat je spolehlivou metodou, jak přilákat do své zahrady více návštěvníků. K tomu, abys mohl zvíře začít cvičit, musíš zaměstnat cvičitele. Když potom k nějakému zvířeti cvičitele přiřadíš, jeho popularitu postupně poroste.

47

14.8. Rozšiřování zahrady – část návodu Na začátku hry máš pouze 5 parcel, na kterých můžeš postavit pavilon nebo výběh pro zvířata. Nestačí-li ti již tento prostor, je třeba zakoupit nějaký sousední pozemek. Každý pozemek ti dovolí postavit 5 dalších pavilonů.

48

15. Závěr Výše popsaná práce, věnující se předložení konceptu vlastní hry pro děti ve věku 7-12 let, splňuje zadání ve všech jeho bodech. Věnuje se průzkumu nabídek her pro děti a zkoumá požadavky, které by měly tyto hry splňovat. Nabídka her, především on-line, byla shledána jako nevyhovující a bylo zjištěno, že požadavky na tyto hry jsou jasně definovány klasifikačním systémem PEGI, jehož odnož PEGI-Online je systém specializující se na klasifikaci online her. Navrhovaná hra je tedy koncipována tak, aby se v budoucnu mohla o certifikaci PEGI-Online ucházet. Na základě výše zjištěných informací byl sestaven návrh hry, ve které mají hráči možnost budovat jedinečnou zoologickou zahradu skupováním pozemků a výstavbou pavilonů. Do nich mohou umisťovat zvířata, o která se starají prostřednictvím najatých zaměstnanců. Se zvířaty lze dle požadavků zadání také obchodovat. Všechny hráčské možnosti definované pro tuto hru jsou formálně zachyceny v jazyce UML a celé nastavení konceptu hry se řídilo metodikou UP. Při analýze a návrhu byly použity zejména Use Case diagramy pro zdokumentování hráčských možností a aktivity diagramy pro pravidla a vnitřní postupy v systému. V závěru práce je navržený systém zhodnocen dle možnosti dalšího rozšíření a nastíněna možnost jeho implementace zohledňující jak vícevrstvou architekturu systému, tak požadavek na použitelnost systému na klientské stanici pouze s použitím webového prohlížeče. Navržený systém je mimo rámec této práce implementován a nasazován k testovacímu provozu. Proto lze prohlásit zdokumentovanou analýzu a návrh za dostatečný.

49

50

16. Použité zdroje informací [1]

Tiscali Games – hlavní strana http://games.tiscali.cz

[2]

Online hra. (30. 03. 2008). Wikipedie: Otevřená encyklopedie. http://cs.wikipedia.org/w/index.php?title=Online_hra&oldid=2410163

[3]

Lost in Time – Co je to Lit? http://lostintime.mudy.cz/

[4]

CzechRO.net – fórum (úvodní strana) http://www.czechro.net/

[5]

Pětkovic domácí web - Hry pro děti: Je to bídné http://k5.web.klfree.net/content/view/6/3/

[6]

PEGI Pan European Game Information - ORGANIZACE http://www.pegi.info/cs/index/id/60/

[7]

PEGI Online – Co je PEGI Online? http://www.pegionline.eu/cs/index/id/61/

[8]

The Witcher (Zaklínač) – Role Playing Game http:www.cdprojekt.cz/witcher

[9]

Jim Arlow, Ila Neustadt. UML2 a unifikovaný proces vývoje aplikací. Computer Press, a.s., Brno, 2007

[10]

Budovatelská strategie. (27. 12. 2007). Wikipedie: Otevřená encyklopedie. http://cs.wikipedia.org/w/index.php?title=Budovatelsk%C3%A1_strategie&oldid=209 9928.

51

52

A Diagramy strukturovaného katalogu požadavků

custom Functional Requirements Business Rules + Obchodování + Správa úč tu + Správa zahrady + Získávání informací + 10. Administrátorská správa + 6. Úč ast na záchranných odchytech + 7. Zasílání a správa zpráv + 9. Správa druhů zvířat

Obr. A1 Balíčky funkčních požadavků

custom Business Logic 6. Účast na záchranných odchytech Správ a účtu

Obchodov ání

Získáv ání informací

+ 1. Správa účtů

+ 2. Získání informací

+ 3. Obchod

+ 1.1 registrace

+ 2.1 o ostatních hráč ích

+ 3.1 Obchod s pozemky

+ 1.2 mazání vlastního účtu

+ 2.2 o herních možnostech

+ 3.2 Obchod se zvířaty

+ 1.3 změna vlastního profilu

+ 2.3 o pozemcích

+ 1.4 přihlášení

+ 2.4 o vlastní ZOO

+ 1.5 odhlášení

+ 2.5 o výsledcích

7. Zasílání a správa zpráv

9. Správa druhů zvířat Správ a zahrady

+ 2.6. O pavilonech

+ 4. Stavební úpravy + 5. Zajišťování a správa zaměstnanců + 8. Výměna a půjčování zvířat

Obr. A2 Funkční požadavky

53

10. Administrátorská správa

custom Správ a účtu 1.1 registrace

1.2 mazání vlastního úč tu

1. Správa účtů

1.3 změna vlastního profilu

1.4 přihlášení

1.5 odhlášení

Obr. A3 Funkční požadavky – Správa účtů

custom Čtení informací 2.1 o ostatních hráč ích 2.2 o herních možnostech

2.3 o pozemcích 2. Získání informací

2.4 o vlastní ZOO

2.6. O pavilonech

2.5 o výsledcích

Obr. A4 Funkční požadavky – Čtení informací

54

custom Obchodov ání 3.1 Obchod s pozemky

3. Obchod

3.2 Obchod se zvířaty

Obr. A5 Funkční požadavky – Obchodování

custom Správ a zahrady 5. Zajišťování a správa zaměstnanců

4. Stavební úpravy

8. Výměna a půjčování zvířat

Obr. A6 Funkční požadavky – Správa zahrady

custom Non-Functional Requirements 1N. Pouze online přístup s využitím webového prhlížeč e a internetového připojení

2N. zabezpeč ení přístupu a uložených hesel

3N. zaruč ená funkč nost v Mozzile Firefox

Obr. A7 Nefunkční požadavky

55

4N. Vícevrstvá architektura zajišťující oddělenou práci s daty a zobrazovacími prostředky

56

B

Use Case diagramy a jejich scénáře

uc Správ aÚčtů SprávaÚč tů

UC1-Registrov at UC2-Přihlásit/Odhlásit

UC3-ZměnitVlastníProfil Hráč (from Actors) UC4-SmazatVlastníÚčet

Administrátor (from Actors)

UC5-SmazatLibov olnýÚčet

UC6-ZměnitLibov olnýProfil UC7-ZapsatNov éhoAdministrátora

Obr. B1 Případy užití – Správa účtů UC1-Registrovat Zaregistruje hráče na základě zadaných informací. Scénář Registrace Případ spuštěn požadavkem hráče Hráč do připraveného formuláře zadává uživatelské jméno, jméno, příjmení, věk, mailovou adresu, heslo, heslo pro potvrzení, volitelně zadává město (bod 2) Systém ověří jedinečnost uživatelského jména, mailové adresy a shodnost hesel KDYŽ „v pořádku“ Systém zapíše do databáze zadaná data Hráči je zobrazena jeho zahrada KDYŽ „chyba“ 57

Systém upozorní na chybu a oznámí co je špatně Návrat do bodu 2 s před vyplněnými daty ve formuláři (jen ta data co byla v pořádku) UC2-Přihlásit/Odhlásit Běžný proces přihlášení nebo odhlášení uživatele(administrátora Scénář Přihlášení Uživatel do připraveného formuláře zadá uživatelské jméno a heslo Systém ověří správnost údajů srovnáním s DB KDYŽ „chyba“ Návrat na přihlašovací stránku s před vyplněným uživatelským jménem bylo-li platné Odhlášení Systém uchová čas odhlášení uživatele Uživatel je přesměrován na závěrečnou stránku UC3-ZměnitVlastníProfil Změní současné údaje o uživateli Scénář Změna profilu Případ spuštěn požadavkem hráče ze stránky zobrazující uživatelův profil Systém zobrazí formulář s před vyplněnými současnými záznamy Po stisku uživatele na tlačítko Uložit je obsah všech polí kontrolován na validnost KDYŽ „v pořádku“ Hodnoty změněných polí jsou uloženy Zobrazení změněného profilu KDYŽ „chyba“ Zobrazení formuláře na změnu s původními údaji UC4-SmazatVlastníÚčet Scénář Smazání účtu Případ spuštěn požadavkem hráče stiskem tlačítka na stránce zobrazující profil Systém zobrazí upozornění a požadavek na zadání hesla a ověří KDYŽ „v pořádku“ Po potvrzení je účet smazán KDYŽ „chyba“ Zobrazení uživatelova profilu UC5-SmazatLibovolnýÚčet Scénář Smazat Po stisku tlačítka zobrazeno varování s možnostmi SMAZAT a PONECHAT ÚČET

58

Při stisku SMAZAT je ze systému odebrán účet a všechny související záznamy (definováno později) UC6-ZměnitLibovolnýProfil Scénář Změna Při prohlížení informací o uživatelích je případ spuštěn požadavkem administrátora Systém zobrazí formulář s před vyplněnými položkami daného profilu Po stisku tlačítka ULOŽIT jsou jednotlivé položky kontrolovány na validitu a poté uloženy do systému UC7-ZapsatNovéhoAdministrátora Scénář Nový admin Případ spuštěn požadavkem administrátora s úvodní administrátorské stránky Do připraveného formuláře je zapsáno povinně uživatelské jméno mail a heslo Do systému je uložen nový uživatel – administrátor Novému administrátorovi je odeslán mail s uživatelským jménem a heslem na zadanou mailovou adresu

59

uc Informace

Diagram ukazuje o č em lze získat během hry informace. Je také znázorněno které informace zadáva do systému administrátor.

Informace

UC10-Vlastní Zoo UC13-ZměnitTutoriál

UC8-Pozemek

UC9-Pav ilon

Administrátor (from Actors)

Hráč (from Actors)

UC11-Tutoriál

UC12-Výsledky

Obr. B2 Případy užití – Informace

UC10-VlastníZoo Zobrazuje souhrnné informace o hráčově zoo. Tato volba je přístupná na jakékoliv herní obrazovce. Na každé obrazovce by měl hráč vidět návštěvnost, náklady a příjmy a počty zvířat jednotlivých druhů. Scénář Informace o vlastní Zoo Případ spuštěn požadavkem hráče Systém zobrazí výpis nejdůležitějších informací o dané zoo (jméno vlastníka, název zahrady, počet vlastněných zvířat, nejvýnosnější a nejméně výdělečné zvíře, počet a druhy zaměstnanců, jejich platy, počet pavilonů, návštěvnost, náklady, příjem a vypočtený zisk) Po ukončení prohlížení návrat na místo odkud byl požadavek vyvolán UC8-Pozemek Souhrnné informace o pozemku, počet a druhy pavilonů, počty a druhy zvířat budou zobrazeny při zobrazení pozemku UC9-Pavilon Souhrnné informace o pavilonu, typ, celkový počet zvířat, nej zvíře, rozpis jednotlivých zvířat (popularita), nálada, přiřazení zaměstnanců

60

UC11-Tutoriál Odkaz na každé stránce. Zobrazuje základní informace zejména jak začít hrát. UC12-Výsledky Zobrazuje výsledky hry, návštěvnost, počet druhů zvířat, počty zvířat, nej zvíře. UC13-ZměnitTutoriál Část administrátorského menu kde lze pomocí formuláře změnit zobrazovaný text v tutoriálu.

61

uc Komunikace Komunikace/Zprávy

UC20-ZaslatZpráv u

UC21-ČístZpráv u Hráč (from Actors) UC22-SmazatZpráv u

Obr. B3 Případy užití – Komunikace UC20-ZaslatZprávu Scénář Odeslání Uživatel přejde do sekce zpráv Uživatel vyplní adresáta, předmět a text zprávy Uživatel potvrdí odeslání Systém přiřadí zprávu příjemci (adresátovi) UC21-ČístZprávu Scénář Čtení Při vstupu do sekce se zprávami systém zobrazí předměty a odesilatele všech zpráv patřících hráči Po stisku detailu systém zobrazuje celý text zprávy UC22-SmazatZprávu Možnost bude dostupná jak s seznamu zpráv, tak v detailu zprávy, umožňuje smazat zprávu.

62

uc Odchyt ZáchrannéOdchyty

UC44- Vytv ořitTermín

Hráč UC24-PřihlásitNaTermín

(from Actors)

UC25-Odhlásit_z_termínu

Obr. B4 Případy užití – Odchyt UC44-VytvořitTermín Umožní hráči uspořádat odchyt zvěře v divočině. Scénář Vytvořit odchyt Případ spuštěn požadavkem hráč. Pro kontrolu, zda hráč zaměstnává lovce, hráč vybírá místo pro odchyt a počet hráčů, kteří se mohou zúčastnit. Systém zobrazí vypočtenou cenu za uspořádání lovu Hráč stanoví vstupní cenu pro hráče, kteří se právě vytvořeného lovu budou chtít zúčastnit. Při potvrzení je hráči odečtena suma z konta UC24-PřihlásitNaTermín Umožňuje hráči přihlásit se k odchytu zvěře v přírodě. Scénář Přihlásit k odchytu Případ spuštěn požadavkem hráč. Systém zobrazí seznam všech možných odchytů s udáním místa a času. Hráč vybírá jednu možnost a systém zobrazí vstupní cenu. Při souhlasu proběhne kontrola zaměstnanců na lovu a odečte finance z konta. Pokud v pořádku je hráč na odchyt přihlášen.

63

UC25-Odhlásit_z_termínu Umožňuje odhlášení z lovu pokud tento ještě neprobíhá nebo neproběhl. Scénář Odhlášení Případ spuštěn požadavkem hráče. Po potvrzení je hráči vráceno 50% vstupního poplatku Hráč je odhlášen.

64

uc Zaměstnanci správaZaměstnanců

UC30-Naj moutZaměstnance

UC31-PropustitZaměstnance Hráč (from Actors)

UC33-PřiřaditCv ičitele

UC34-OdebratCv ičitele

Obr. B5 Případy užití – Zaměstnanci UC30-NajmoutZaměstnance Umožní najmout zaměstnance. Pro chod zahrady je nutné najímat uklizeče a ošetřovatele, pro účast na odchytu je nutné zaměstnat tým pro odchyt zvěře. Scénář Najmutí zaměstnance Případ spuštěn požadavkem uživatele. Systém zobrazí aktuální seznam volných zaměstnanců. Po výběru zaměstnance je zobrazen dotaz na potvrzení. Po potvrzení je zaměstnanec najat. Hráči se zvýší náklady na provoz Zoo. UC31-PropustitZaměstnance Scénář Propuštění zaměstnance Systém zobrazí seznam všech hráčových zaměstnanců. Po výběru zaměstnance k propuštění je zobrazen dotaz na potvrzení. Po potvrzení je zaměstnanec propuštěn. (zařazen do seznamu nezaměstnaných a může být najat jiným nebo tímtéž hráčem)

65

UC33-PřiřaditCvičitele Cvičení zvířat zvyšuje jejich popularitu. Jeden cvičitel může cvičit nejvýše jedno zvíře. Scénář Přiřazení cvičitele – ze seznamu zaměstnanců Systém zobrazí seznam všech hráčových zaměstnanců. Po výběru volby „přiřadit ke zvířeti“ u volného cvičitele zobrazen seznam všech zvířat. Po výběru zvířete je zobrazen dotaz na potvrzení. Po potvrzení začne být zvíře cvičeno. Přiřazení cvičitele – ze seznamu zvířat Systém zobrazí seznam zvířat (celkový nebo pavilonu) Při výběru volby „přiřadit cvičitele“ je zobrazen seznam volných cvičitelů. Po výběru cvičitele je zobrazen dotaz na potvrzení Po potvrzení začne být zvíře cvičeno. UC34-OdebratCvičitele Odebrání cvičitelů se děje analogicky jako jejich přiřazení. Můžeme tak rovněž učinit v seznamu zaměstnanců nebo zvířat (clk i pavilonu).

66

uc AdminRozhraní

RozhraníAdministrátora

Přístup na základě ověření administrátorských práv.

UC40-PřečístLibov olnáData

Administrátor (from Actors)

UC41-ZměnitLibov olnáData

UC42-PřidatZv ířecíDruh

Obr. B6 Případy užití – Administrátorské rozhraní UC40-PřičístLibovolnáData Část administrativního rozhraní umožňující zobrazení o všech hráčích, zahradách, zvířatech, zaměstnancích, zvířecích druzích a pavilonech UC41-ZměnitLibovolnáData Při procházení výpisu dat může administrátor změnit libovolnou položku UC42-PřidatZvířecíDruh Část administrativního rozhraní umožňující přidání nového zvířecího druhu (také pavilonu a typu zaměstnance)

67

uc Zahrada Zahrada

UC16-ZakoupitPozemek

UC26-Postav itPav ilon

Hráč (from Actors) UC27-ZbořitPav ilon

Obr. B7 Případy užití – Zahrada UC16-ZakoupitPozemek Scénář Rozšíření Případ spuštěn požadavkem hráče (kliknutí na nezakoupenou 1/16 ve vlastní zahradě) Zobrazena cena, která je spočtena jako x * počet stavebních parcel Při potvrzení je částka odečtena z konta uživatele a pozemek je označen za aktivní UC26-PostavitPavilon Při nákupu parcely je ihned zobrazen dotaz na druh pavilonu. Po výběru je provedena transakce Scénář Postavit Při kliku na nezastavěnou parcelu je zobrazen seznam všech pavilonů a jejich cen a doby stavby Po výběru pavilonu je odečtena částka z konta a zobrazen obrázek probíhající stavby na dané parcele Po uplynutí doby stavění je zobrazen obrázek pavilonu a lze do něj již umisťovat zvířata UC27-ZbořitPavilon Při vstupu do pavilonu je možnost pavilon zbořit, je-li prázdný. Hráč nedostane nazpět žádné finanční prostředky. Scénář Zbořit Při kliku na postavený pavilon se zobrazují data o pavilonu Na této obrazovce možnosti pavilon zbořit Kontrola zda je bez zvířat 0,25*cena pavilonu na konto hráče Odstranění z databáze

68

C

Business Process modely analysis Koupit zv íře

Výběr v hodného zv ířete

Potv rzení ceny

«goal» Nákup nov ého zv ířete - v yšší náv štěv nost

Obr. C1 Model pracovního postupu Koupit zvíře

analysis Prodat zv íře

Výběr zv ířete k prodej i

ANO

NPC obchodníkovi?

NE

Stanov ení prodej ní ceny

Potv rzení prodej ní ceny

Prov edení prodej e

Potv rzení a nabídnutí zv ířete k prodej i

«goal» Prodej zv ířete

Obr. C2 Model pracovního postupu Prodat zvíře

69

analysis Pujcovani zvirat

VYTVÁŘÍM

Přijímám nebo vytvářím?

Vytvářím nabídku nebo poptávku?

P

N PŘIJÍMÁM

N

Výběr samce k půjčení

Stanovení samce, kterého potřebuji

Stanovení požadované ceny

Stanovení ceny, kteoru jsem ochocen zaplatit

P Přijímám poptávku nebo nabídku?

Výběr vhodného samce

Výběr poptávky včetně finančních nároků

Odsouhlasení ceny za půjčení Příjmutí poptávky

«goal» Zajištění vhodného partnera pro páření

Obr. C3 Model pracovního postupu Půjčování zvířat

70

analysis Spářit zv ířata

Výběr samice k páření

Výběr samce

Potv rzení a prov edení páření

«goal» Odchov zv ířat v zaj etí

Obr. C4 Model pracovního postupu Spářit zvířata

71

analysis Vyměnit zv ířata

NABÍZÍM

Nabízím nebo přijímám

PŘIJÍMÁM

Výběr zv ířete které chci v yměnit

Výběr v hodné nabídky

Výběr zv ířete, za které chci měnit

Odsouhlasení nabídky

Potv rzení nabídky

«goal» Výměna zv ířat mezi dv ěma Zoo

Obr. C5 Model pracovního postupu Vyměnit zvířata

72

analysis Nákup pozemku

Výběr v hodného pozemku

Odsouhlasení nabídnuté ceny

Prov edení transakce/nákupu

«goal» Rozšíření v lastní zahrady

Obr. C6 Model pracovního postupu Nákup pozemku

73

analysis Nákup pav ilonu v .1

Výběr v hodného pozemku

Výběr v hodné parcely

Výběr pav ilu ze seznamu dostupných

Nákup pav ilonu

«goal» Výstav ba pav ilonu pro nov ý druh zv ířat

Obr. C7 Model pracovního postupu Nákup pavilonu

74

analysis Naj mutí «goal» Naj mutí zaměstnance k péči o zv ířata nebo účasti na lov ech

Výběr profese zaměstnance

Výběr v lastností a platu dle nabídky

Potv rzení

Obr. C8 Model pracovního postupu Najmutí zaměstnance

analysis Propuštění

Výběr nepotřebného/nev hodného zaměstnance

«goal» Propuštení zaměstnance (snížení nákladů)

Potv rzení propuštění

Obr. C9 Model pracovního postupu Propuštění zaměstnance

75

analysis Přiřazení cv ičitele

Výber zv ířete k v ýcv iku

«goal» Začátek v ýcv iku zv ířete

Výběr v olného cv ičitele

Přiřazení/potv rzení

Obr. C10 Model pracovního postupu Přiřazení cvičitele

analysis Odebrání cv ičitele

Výběr zv ířete k ukončení v ýcv iku

«goal» Ukončení v ýcv iku zv ířete

Odebrání cv ičitele

Potv rzení

Obr. C11 Model pracovního postupu Odebrání cvičitele

76

analysis Odchyty

ANO

Mám volného lovce?

NE

Zorganizovat odchyt?

ANO

Prihlásit nebo odhlásit?

PŘIHLÁSIT

Výběr druhu a lokace

ODHLÁSIT

Mám volného lovce?

Výběr termínu pro odhlášení

ANO Výběr druhu a lokace

Stanov ení počtu účastníků

Odhlášení Odsouhlasení účasnického poplatku

Stanov ení poplatku za účast

Potv rzení

Potv rzení/přihlášení

«goal» Odchyt zv ěře z div očiny a j eho organizace

Obr. C12 Model pracovního postupu Odchyty

analysis Informace

Výběr obj ektu o kterám chci zj istit informace

«goal» Získání informací

Přečtení informace

Obr. C13 Model pracovního postupu Získání informací

77

analysis Zpráv y

NE

Výběr zpráv y

Napsat novou?

ANO

Vypnění adresáta

Vypnění předmětu ANO

Vymazat?

Vymazání Napsání zpráv y

NE Přečtení zpráv y

Odeslání

«goal» Práce se zpráv ami a komunikace mezi hráči

Obr. C14 Model pracovního postupu Práce se zprávami

analysis Registrace

Vyplnění formuláře

«goal» Začátek účasti v e hře Souhlas s podmínkami

Potv rzení údaj ů

Obr. C15 Model pracovního postupu Registrace

78

analysis Přihlášení

Vypnění j ména a hesla «goal» Přihlášení ke sv ému účtu Potv rzení/Přihlášení

Obr. C16 Model pracovního postupu Přihlášení

analysis Profil NE

Zobrazení profilu

NE

Změnit?

Smazat?

ANO

ANO

Potv rzení v ymazání

Zapsání nov ých dat do formuláře

Potv rzení «goal» Ukončení působení v e hře

«goal» Změna osobních informací

Obr. C17 Model pracovního postupu Práce s profilem

79

80

D Model analytických tříd class Domain model 3

Typ_účtu Odchyt + + + +

cena_organizovani: int cena_ucastnik: int lokace: char na_zvire: int

+ +

0..*

+ +

jméno: char 1 návštěvnost: int 0..1

1

1..*

je_majitel 0..1

Parcela

1

0..*

+

obsazena: boolean

Účet

aktualizace: datetime stav: int

je_majitelem 1

je_prijemcem Zpráv a datum: datetime 0..* obsah: text odesilatel: int predmet: char

1

vlastni adresa: char 0..1 heslo: char 0..* jméno: char prihlasovaci_jmeno: char + nabizi + 0..1 0..1 + zamestnava + 0..* +

+ 1 + + + 1

0..*

0..*

osetruje

Zaměstnanec + + + 1..*

0..* jmeno: char 0..* plat: int pocet_zvirat: int nabizi 0..1

1 Zv íře jmeno: char nalada: int pohlavi: int 0..* popularita: int vek: int

0..*

nabizi

+ + + + + +

NPC_obchodnik

nazev: char plat_prumer: int prumerne_zvirat: int

81

Pav ilon

je_umisteno 0..1

0..*

1

0..1

je_zastavena 0..1

0..*

Druh_zv ířete

Profese + + +

cena: int pocet_parcel: int

obsahuje

0..*

Konto

+ 1..* +

je_tvorena

Zahrada

organizuje ucastni_se

+ + + +

prava: int typ: int 1

0..*

+ +

Pozemek

naklady: int nazev: char popis: text prumerny_vek: int sance_odchyt: int sance_pareni: int

lze_umistit 1

1

1

Druh_pav ilonu + + + + + +

cena: int nazev: char nizky_pocet_zvirat: int popis: text pro_druh: int vysoky_pocet_zvirat: int

Účet - adresa - heslo - jméno - prihlasovaci _jmeno

- volitelný atribut s adresou vlastníka účtu - heslo pro přihlášení uživatele - jméno vlastníka účtu - přihlašovací jméno k účtu

Typ účtu - typ - prava

- číslo typu účtu - číslo úrovně přístupových práv

Zahrada - jmeno - navstevnost

- název zahrady - návštěvnost zahrady (ukazatel růstu příjmů)

Pozemek - cena - pocet_parcel

- cena za nákup pozemku - počet parcel na pozemku

Parcela - obsazena

- určuje zda lze ještě na parcele stavět

Zvíře - jmeno - nalada - popularita - vek - pohlavi

- jméno zvířete - psychický stav zvířete - ukazatel vycvičenosti zvířete - určuje kolika let se zvíře dožije - pohlaví zvířete

Druh_Pavilonu - cena - nazev - nizky_pocet_zvirat - vysoky_počet_zvirat - popis - pro druh

- cena daného typu pavilonu - název pavilonu - mezní spodní hranice ideálního počtu zvířat v zahradě - mezní horní hranice ideálního počtu zvířat v zahradě - informační popis pavilonu - které druhy zvířat lze do toho druhu pavilonu umístit

Druh_Zvířete - naklady - nazev - popis - prumerny_vek - sance_pareni - sance_odchyt

- náklady na daný typ zvěře - název druhu - informační popis druhu zvířat - průměrný věk zvířat tohoto druhu - obtížnost úspěšného páření zvířat - obtížnost odchytu druhu

Zaměstnanec - jmeno - plat - pocet_zvirat

- jméno zaměstnance - náklady na zaměstnance (jeho plat) - o kolik zvířat se zaměstnanec může starat

82

Odchyt - cena_organizovani - cena_ucastnik - lokace - na_zvire

- poplatek za organizování odchytu - vstupní poplatek za přihlášení na daný odchytu - cíl odchytu - jaké zvíře lze odchytit

Konto - aktualizace - stav

- datum a čas poslední aktualitě stavu konta - zůstatek na kontě

Zpráva - datum - obsah - odesilatel - predmet

- datum a čas odeslání zprávy - celý text zprávy - přihlašovací jméno odesilatele zprávy - předmět zprávy

Profese - nazev - plat_prumer - prumerne_zvirat

- název profese - průměrný plat pro zaměstnance této profese - o kolik zvířat v průměru se tento typ zaměstnance stará

83

E

Pravidla hry – diagramy aktivit act Nov á zv ířata

Stejným principem funguje i generování nových zaměstnanců

ActivityInitial

Je dostatek nabídek? NE ANO

Generuj zv ířata

ActivityFinal

Obr. E1 Nová zvířata – diagram aktivit act Úspěch páření ActivityInitial

Spočti úspěch

Zaznamenej březost

ANO

Úspěch

NE

Zmena stav u samice

Oznam v ýsledek

ActivityFinal

Obr. E2 Úspěch páření – diagram aktivit

84

act Rození Konec březosti samice

Vytv oř nov á zv ířata

Zruš březost

ActivityFinal

Obr. E3 Rození zvířat – diagram aktivit

act Smrt ActivityInitial

Současný v ěk zv ířete

Zemřelo zvíře?

ANO

NE Vymaž zv íře

Informuj hráče

ActivityFinal

Obr. E4 Smrt zvířete – diagram aktivit

85

act Registrace

Vytv oření nov ého hráče Registrace

Uložení hodnot z registračního formuláře

Vytv orení Zoo

Vytv oření nov ých pozemků

Vytv oření v šech možných parcel

ActivityFinal

Obr. E5 Registrace – diagram aktivit

86

act Odchyt

ActivityInitial

Výpočet úspěšnost

Urči počet chycených zv ířat

Úspěch?

NE

Odešli zpráv y o neúspěchu

Rozděl zv ířata

Odesli zprav u o v ysledku ActivityFinal

Obr. E6 Nová zvířata – diagram aktivit

87

act Změna nalady

Naj di zv ířata bez zaměstnance Zač átek

NE

Vyber prv ní/další zv íře bez zaměstnance

Existuje takové zvíře

Vytv oř seznam v šech zv ířat

Je bez zaměstnance více než 2 měsíce? Vyber j edno/další zv íře

Sniž náladu Jsou přiřazení zaměstnanci déle než 2 měsíce? NE Nastav nov ý čas aktualizace

ANO

Nastav nov ý čas aktualizace

Zv yš náladu

Kontrola u všech? NE ANO ANO Proběhla kontrola u všech zvířat? Konec

Obr. E7 Změna nálady zvířat – diagram aktivit

act Výcv ik

Naj di zv ířata s cv ičitelem

Jak dlouho j e zv íře cv ičeno?

Více než 2 měsíce?

Zv yš popularitu

Nastav nov é datum počátku v ýcv iku

Obr. E8 Výcvik zvířat – diagram aktivit 88

89

F Návrh uživatelského rozhranní custom Základní Tutoriál

Obsah strany x

daší

předchozí Registrace

«navigate»

Registrační obrazov ka

Hlav ni strana «navigate»

Přihlašovací jméno Logo Heslo

Novinky

Heslo znovu Hlavni strana Jméno Tutoriál Příjmení Manuál e-mail Věk Registrace

Přihlásit se Bydli ště Registrovat Souhlas «navigate» «navigate»

Přihlašov ací obrazov ka

Přihlašovací jméno

Heslo

Přihlásit

Obr. F1 Uživatelské rozhraní – před přihlášením

90

91

G Obsah přiloženého CD ReadMe.txt Text BP.pdf

- vlastní bakalářská práce

Zooland.eap

- projekt pro program Enterprise Architect

Data

92