Embed Size (px)
Citation preview
SLOVENSKÁ TECHNICKÁ UNIVERZITAFakulta informatiky a informačných technológií
Ilkovičova 3, 842 16 Bratislava 4
HOREX –
plánovanie a simulácia horolezeckej expedícieTím 04
Bc. Miroslav KalloBc. Ľubomír LajošBc. Ladislav Rado
Bc. Peter Ruttkay – NedeckýBc. Peter ŠupinaBc. Tomáš Tóth
Študijný odbor: Softvérové inžinierstvoRočník: 1. Ing.Predmet: Tvorba softvérového systému v tímeVedúci projektu: Doc. Ing. Martin Šperka, PhD.
Ak. rok: 2006/2007
ii
Obsah
0 ÚVOD............................................................................................................................................................IV
0.1 ÚČEL A ROZSAH DOKUMENTU................................................................................................................IV0.2 PREHĽAD DOKUMENTU...........................................................................................................................IV0.3 ODKAZY A ZDROJE.................................................................................................................................VI0.4 SLOVNÍK POJMOV PROBLÉMOVEJ OBLASTI............................................................................................VII0.5 SKRATKY...............................................................................................................................................VII0.6 POUŽITÁ NOTÁCIA.................................................................................................................................VII
1 ANALÝZA......................................................................................................................................................1
1.1 PREHĽAD PROBLÉMOVEJ OBLASTI............................................................................................................11.2 ANALÝZA TECHNICKÝCH PROSTRIEDKOV..............................................................................................20
2 ŠPECIFIKÁCIA POŽIADAVIEK NA SYSTÉM.....................................................................................26
2.1 FUNKCIE PRODUKTU..............................................................................................................................262.2 VLASTNOSTI PRODUKTU........................................................................................................................282.3 DIAGRAM PRÍPADOV POUŽITIA SYSTÉMU...............................................................................................302.4 HRÁČI.....................................................................................................................................................312.5 PRÍPADY POUŽITIA.................................................................................................................................31
3 NÁVRH SYSTÉMU.....................................................................................................................................38
3.1 VÝPOČET ENERGIE HOROLEZCA.............................................................................................................383.2 NÁVRH ATRIBÚTOV VÝBAVY A VÝSTROJA............................................................................................403.3 SPÔSOB ULOŽENIA ÚDAJOV O VÝSTROJI A MANIPULÁCIA S TÝMITO ÚDAJMI........................................413.4 DIAGRAM TRIED SYSTÉMU.....................................................................................................................443.5 NÁVRH PROCESU SIMULÁCIE.................................................................................................................47
4 REVÍZIA ŠPECIFIKÁCIE POŽIADAVIEK NA SYSTÉM...................................................................49
5 PODROBNÝ NÁVRH.................................................................................................................................53
5.1 NÁVRH SYSTÉMU...................................................................................................................................535.2 NÁVRH STAVOV SIMULÁCIE...................................................................................................................585.3 NÁVRH ZAPISOVAČA (LOGGER).............................................................................................................645.4 NÁVRH ROZVRHU...................................................................................................................................665.5 NÁVRH MODELU POČASIA......................................................................................................................705.6 NÁVRH VSTUPNO-VÝSTUPNÉHO PODSYSTÉMU......................................................................................785.7 NÁVRH MODELU HOROLEZCA................................................................................................................845.8 NÁVRH AKTIVÍT A ÚLOH HOROLEZCA....................................................................................................895.9 NÁVRH REPREZENTÁCIE TERÉNU A TRASY EXPEDÍCIE V SIMULÁCII......................................................965.10 NÁVRH MODELU INVENTÁRA...............................................................................................................1065.11 NÁVRH POUŽÍVATEĽSKÉHO ROZHRANIA..............................................................................................113
6 ZMENY ŠPECIFIKÁCIE, PRIORITY RIEŠENIA...............................................................................123
6.1 ZMENY V ŠPECIFIKÁCII.........................................................................................................................1236.2 PRIORITY RIEŠENIA..............................................................................................................................124
7 IMPLEMENTÁCIA...................................................................................................................................125
7.1 VÝBER IMPLEMENTAČNÉHO JAZYKA A PROSTREDIA...........................................................................1257.2 OPIS REALIZÁCIE..................................................................................................................................1257.3 OHRANIČENIA......................................................................................................................................125
8 TECHNICKÁ DOKUMENTÁCIA..........................................................................................................127
9 Zhodnotenie..................................................................................................................................................128
iii
Zoznam obrázkov
obr. 1. Podiel atribútov horolezca na celkovej výkonnosti.......................................................................2obr. 2. Význam atribútov pri lezení po skale............................................................................................3obr. 3. Význam atribútov pri lezení po ľadovci........................................................................................4obr. 4. Závislosť energie horolezca od parametrov prostredia...............................................................14obr. 5 Diagram prípadov použitia systému.............................................................................................30obr. 6. Diagram aktivít Inicializácia simulácie.......................................................................................32obr. 7. Diagram aktivít Výber kroku simulácie......................................................................................34obr. 8. Diagram aktivít Vytvorenie modelu hory...................................................................................36obr. 9. Závislosť energie od vlastnosti horolezca, prostredia a inventáru..............................................39obr. 10 Diagram tried systému...............................................................................................................44obr. 11 Diagram aktivít Proces simulácie...............................................................................................47obr. 12 Diagram prípadov použitia systému...........................................................................................49obr. 13 diagram aktivít Inicializácia simulácie.......................................................................................50obr. 14 Diagram aktivít Výber kroku simulácie.....................................................................................51obr. 15 Diagram aktivít vytvorenie modelu hory...................................................................................52obr. 16 Diagram tried systému...............................................................................................................55obr. 17 Diagram tried Vstupno-výstupná úroveň systému.....................................................................56obr. 18 Stavový diagram Stavy simulácie..............................................................................................58obr. 19 Stavový diagram Vykonávanie simulácie..................................................................................60obr. 20 Diagram tried Zapisovač............................................................................................................65obr. 21 Diagram tried Rozvrh.................................................................................................................67obr. 22 Stavový diagram Stavy počasia..................................................................................................71obr. 23 Diagram tried Model Počasia.....................................................................................................72obr. 24 Sekvenčný diagram Načítanie typov počasia.............................................................................77obr. 25 Diagram tried IO modulu...........................................................................................................81obr. 26 Diagram tried Model Horolezca.................................................................................................85obr. 27 Zdravie horolezca.......................................................................................................................87obr. 28 Preplánovanie udalosti...............................................................................................................91obr. 29 Diagram tried modulu Task a Group..........................................................................................92obr. 30 Grafické znázornenie možných trás expedície...........................................................................96obr. 31 Diagram tried terénu a trasy expedície.......................................................................................98obr. 32 Diagram tried Model Inventáru................................................................................................108obr. 1 Obrazovka Konfigurácia............................................................................................................113obr. 2 Obrazovka Hlavné menu............................................................................................................114obr. 3 Obrazovka Inicializácia simulácie.............................................................................................115obr. 4 Obrazovka Informácie o skupine horolezcov.............................................................................116obr. 5 Obrazovka Informácie o horolezcoch........................................................................................116obr. 6 Obrazovka Aktuálne počasie......................................................................................................117obr. 7 Obrazovka Lokalita....................................................................................................................117obr. 8 Obrazovka Vytvorenie skupiny...................................................................................................118obr. 9 Obrazovka Pridelenie materiál horolezcom..............................................................................118obr. 10 Obrazovka Zadanie úlohy pre skupinu horolezcov..................................................................119obr. 11 Obrazovka Vytvorenie trasy.....................................................................................................119obr. 12 Obrazovka Nastavenie času úlohy...........................................................................................120obr. 13 Obrazovka Informácie o úlohe.................................................................................................120obr. 14 Obrazovka MessageBox...........................................................................................................121obr. 15 Obrazovka O aplikácii.............................................................................................................122
iv
0 Úvod
0.1 Účel a rozsah dokumentuPredkladaný dokument obsahuje špecifikáciu softvérového systému “HOREX – plánovanie
a simulácia horolezeckej expedície“.
Dokument je výsledkom študentského projektu v predmete Tvorba softvérového systému v tíme.
Vzhľadom na neexistujúce riešenia, ktoré by poskytovali ucelenú aplikáciu určenú na plánovanie
a simuláciu horolezeckej výpravy, sa v tomto dokumente zameriame na základnú štruktúru zložitého
softvérového systému a najmä na fázu simulácie samotného výstupu. Systém bude možné ďalej
rozširovať.
Dokument je určený pre všetkých, ktorí sa zaujímajú o tvorbu simulačných systémov formou hry,
ale môže slúžiť aj ďalšej skupine ľudí, ktorá bude pracovať na podobnom projekte, prípadne na
rozširovaní tohto systému.
Rozsah dokumentu je primeraný práci šiestich študentov počas dvadsiatich štyroch týždňov dvoch
semestrov. Predpokladaný čas venovaný projektu na jedného študenta počas jedného týždňa je:
5 hodín + 3 hodiny prednášok + 3 hodiny stretnutia k projektu organizované každý pondelok.
0.2 Prehľad dokumentuKapitola 1 Analýza.
V tejto časti dokumentu sa nachádza prehľad problémovej oblasti, kde sú opísané štyri hlavné aspekty
problémovej oblasti – vplyvy prostredia, vlastnosti resp. atribúty horolezcov, výbava horolezcov
a činnosti a fázy výstupu – ale aj na súvislosti medzi týmito aspektmi. Ďalej sa tu nachádza analýza
vybraných technických prostriedkov.
Kapitola 2 Špecifikácia požiadaviek na systém.
V tejto časti je vyjadrená špecifikácia požiadaviek na systém prostredníctvom diagramu prípadov
použitia, popisom jednotlivých jeho entít – hráčov a prípadov použitia. Najdôležitejšie prípady
použitia sú vyjadrené aj pomocou diagramov aktivít.
Kapitola 3 Návrh systému.
Táto časť dokumentácie obsahuje návrh závislosti energie horolezca od rôznych faktorov, návrh
atribútov výbavy a výstroja ako aj spôsob uloženia týchto údajov. Ďalej je tu opísaný diagram tried
navrhovaného systému ako aj základná časť systému – simulačný proces horolezeckej expedície.
v
Kapitola 4 Revízia špecifikácia požiadaviek na systém.
V tejto kapitole sú uvedené opravy a zmeny týkajúce sa špecifikácie systému, ktoré vyplynuli
s uvedomenia si určitých nedostatkov alebo chýb.
Kapitola 5 Podrobný návrh.
V tejto časti je uvedený podrobný opis a návrh celého systému. Sú tu bližšie charakterizované
jednotlivé modely, pričom pre každý z nich je uvedený jeho popis, význam a účel, návrh v podobe
diagramu tried, opis tried a ich atribútov a metód. Toto je doplnené o diagramy využívajúce ďalšie
techniky zápisu, obrázky, tabuľky a pod.
Kapitola 6 Zmeny špecifikácie, priority riešenia.
V tejto kapitole sú uvedené zmeny v špecifikácii systému, ktoré vyplynuli zo zmien požiadaviek alebo
zo zistení, že takéto požiadavky nemožno alebo nie je vhodné splniť. Ďalej sú tu uvedené priority
riešenia systému, podľa ktorých sa postupovalo pri vývoji systému.
Kapitola 7 Implementácia.
V tejto časti sú opísané vybrané jazyky, prostredia a nástroje použité pri implementácii systému. Ďalej
je tu uvedený opis realizácie systému, predovšetkým špecifické charakteristiky pri implementácii
systému. Taktiež sú tu uvedené ohraničenia systému, predovšetkým čo sa týka nárokov na softvér
a hardvér.
Kapitola 8 Technická dokumentácia.
V tejto kapitole je uvedená technická dokumentácia k implementácii systému.
Kapitola 9 Zhodnotenie.
V tejto kapitole je uvedené zhodnotenie ako vytvoreného systému, tak aj prác na vývoji tohto systému.
vi
0.3 Odkazy a zdroje1. Bieliková, M. Softvérové inžinierstvo: Princípy a manažment , Slovenská technická univerzita
v Bratislave, 2000.
2. Adventure Peaks Online Shop, https://www.secured-url.co.uk/adventurepeaks/acatalog/index.html
3. Everest Gear - Supplies and products for climbing enthusiasts and mountain climbers,
http://store.everestgear.com/climbing---mountaineering.html
4. gearEXPRESS.com, http://www.gearexpress.com
5. Climbing Shop | US Outdoor, http://www.usoutdoorstore.com/climbing.htm
6. Bezpečne na horách, http://www.kstst.sk/pages/vht/hory.htm
7. Vplyv vetra na teplotu ovzdušia, http://www.kstst.sk/pages/vht/meteo/ekvitemp.htm
8. Lavíny, http://www.kstst.sk/pages/vht/laviny1.htm
9. Mountaineering Hazards, http://www.abc-of-mountaineering.com/info/mountaineering-
hazards.asp
10. Zdravotné riziká vo výškach, http://www.kstst.sk/pages/vht/akli2.htm
11. Omrzliny, http://www.horska-medicina.cz/omrzliny.htm
12. Forest Fires - Prevention & Survival, http://www.abc-of-hiking.com/natural-hazards/forest-
fires.asp
13. Animal & Insect Hazards and Attacks, http://www.abc-of-hiking.com/animal-hazards/
14. Aklimatizácia, http://www.kstst.sk/pages/vht/akli1.htm
15. Transportation - Climbers guide to K2, http://www.k2climb.net/expguide/transportation.htm
16. Climbing 8000m Peaks, http://www.planetfear.com/article_detail.asp?a_id=542 a
http://www.planetfear.com/article_detail.asp?a_id=543
17. Promit, R.: Direct3D vs. OpenGL: Which API to Use When, Where, and Why.
http://www.gamedev.net/reference/articles/article1775.asp
18. Simple DirectMedia Layer project. domovská stránka SDL, http://www.libsdl.org/index.php
19. The OGRE Team. domovská stránka ORGE, http://www.ogre3d.org/
20. The OGRE Team. OGRE Manual v1.2.2, http://www.ogre3d.org/docs/manual/
21. The OGRE Team. OGRE API Reference, http://www.ogre3d.org/docs/api/html/
22. polymorph. Ogre Forums : Code Snippet: Ogre in a Win32 MFC App,
http://www.ogre3d.org/phpBB2/viewtopic.php?t=14211
vii
0.4 Slovník pojmov problémovej oblastiVýbava je v tomto prípade súhrn horolezeckých pomôcok, výstroja, jedla a iného materiálu
potrebného k horolezeckej expedícii.
Reinhold Messner je známy vysokohorský horolezec pochádzajúci z Rakúska. Zdolal medzi inými
osem najvyšších vrchov sveta.
0.5 Skratky
Skratka Vysvetlenie
2D Dvojrozmerné
API Aplikačné programové rozhranie
DOM Document Object Model – objektová reprezentácia dokumentu, štandard W3C
DTD Document Type Definition – jazyk na presné definovanie štruktúry XML dokumentov
GUI Grafické používateľské rozhranie
MSXML Microsoft XML – implementácia XML technológií od firmy Microsoft
SAX Simple API for XML – API pre udalosťami riadené spracovanie XML dokumentov
W3C World Wide Web Consortium – medzinárodné zoskupenie organizácií okolo internetu
XML eXtensible Markup Language – jazyk na opis údajov (pridáva meta-informácie)
XSL eXtended Stylesheet Language – jazyk na opis zobrazenia údajov z XML
0.6 Použitá notáciaCieľom tejto kapitoly je priblížiť čitateľovi schematické vyjadrovacie prostriedky používané
v softvérovom inžinierstve. V dokumente sú schémy vypracované na základe štandardu UML, ktorého
hlbší popis môže čitateľ nájsť v [1].
viii
0.6.1 Diagram prípadov použitia
- prípad použitia – pomenovaná a štruktúrovaným textom opísaná
typická interakcia (scenár) medzi používateľom a systémom.
- hráč – pomenovaná úloha používateľa alebo iného systému, ktorú tento hrá vo vytváranom systéme.
- asociácia – medzi hráčom a prípadom použitia. Šípka znázorňuje smer inicializácie, nie tok alebo
prenos údajov.
- závislosť – symbolizuje zahrnutie prípadu použitia, ku ktorému smeruje
šípka do prípadu použitia od ktorého smeruje šípka.
- závislosť – symbolizuje rozšírenie prípadu použitia, ku ktorému smeruje
šípka prípadom použitia od ktorého smeruje šípka
- zovšeobecnenie – vyjadruje vzťah medzi dvoma hráčmi alebo dvoma
prípadmi použitia. Indikuje, že špecializujúci prípad použitia / hráč je zhodný
so všeobecným a navyše pridáva doplnkové informácie (šípka smeruje od
špecializujúceho prípadu použitia / hráča k všeobecnému prípadu použitia / hráčovi.
0.6.2 Diagram činností
- časť v ktorej sa daná aktivita odohráva. V tomto návrhu sa vyskytuje len
používateľ a systém.
- aktivita prebiehajúca v rámci prípadu použitia. Popisuje činnosť, ktorú daná časť
vykonáva.
- vetvenie. Vstupujúca šípka udáva podmienku a vystupujúce šípky naznačujú ďalší postup.
ix
Systém
- koncový stav diagramu činností, v ňom končí posledná vykonávaná aktivita.
- počiatočný stav diagramu činností, z neho sa spúšťa prvá aktivita.
- smer časovej následnosti jednotlivých aktivít. Prípadný komentár udáva udalosť, alebo
podmienku, za ktorej aktivita daným smerom pokračuje.
- poznámka. Umožňuje vložiť rôzne doplňujúce informácie, ako
napr. zavolanie ďalšieho diagramu činností.
- horizontálna synchronizácia. Slúži na ako kontrolný bod pre zosynchronizovanie paralelne sa
vykonávajúcich činností.
0.6.3 Diagram tried
- dátová entita – trieda – reprezentuje akúkoľvek informáciu, ktorú treba uchovávať. Je to určité
zoskupenie údajov, ktoré k sebe logicky patria a ktoré skúmame v rámci analýzy.
Skladá sa z mena – podstatné meno v jednotnom čísle a zoznamom atribútov (pomenovaných
vlastností entity).
- zovšeobecnenie – je to vzťah medzi všeobecnou objektovou triedou a jej
konkrétnymi potomkami. Potomkovia dedia všetky vlastnosti (v našom prípade
atribúty) a rozširujú svoju triedu o nové vlastnosti.
- zoskupenie – hovorí, že jedna entita je súčasťou druhej entity. Napr. Mesto je
súčasťou Kraja.
- väzba – určuje vzťah medzi entitami. Je pomenovaná slovesom. V podstate
vyjadruje, že “čo robí jeden z týchto (inštancia entity1) pre jedného z tamtých
(inštancia entity2)”.
x
0.6.4 Stavové modely entít
- počiatočný stav entity – je to povinný stav a môže byť len jeden. Z tohto stavu sa začína
kresliť diagram. Určuje stav, v ktorom sa entita nachádza, po vytvorení v systéme.
- koncový stav entity – nie je povinný a môže ich byť aj viac. Určuje stav, v ktorom môže byť
entita v systéme zrušená.
- stav, v ktorom sa môže entita nachádzať v určitom čase. Je to pomenovaná situácia jedného objektu
počas jeho existencie, v ktorej spĺňa nejakú podmienku, čaká na nejakú udalosť alebo
vykonáva nejakú činnosť.
- prechod medzi jednotlivými stavmi entity. Entita môže prejsť len do toho stavu, do ktorého je
znázornený prechod.
0.6.5 Diagram komponentov
- komponent - spustiteľná časť kódu. Poskytuje súhrn daných služieb
formou čiernej skrinky. Jeho služby sú dostupné iba prostredníctvom
konzistentného, publikovaného rozhrania, ktoré zahrňuje
komunikačné štandardy.
- závislosť, vyjadruje vzťah medzi komponentmi. Šípka smeruje od závislého ku
hlavnému komponentu.
xi
1 AnalýzaAnalýza problémovej oblasti vychádza z nasledovného zadania projektu:
Vytvorte systém pre simuláciu a plánovanie horolezeckej výpravy.
Systém s atraktívnym používateľským rozhraním bude slúžiť ako hra ako aj pri plánovaní
horolezeckých expedícií, hlavne pre výpočet množstva materiálu, času prípravy a pôsobenia expedície
a analýzu pravdepodobnosti splnenia cieľov s ohľadom na možné riziká formou hry. Scenár použitia
hry je nasledovný: Používateľ zadá ciele expedície a systém mu vypočíta odhad množstva materiálu -
stany, jedlo, laná, atď. Tieto môže vložiť aj ručne. Simulácia prebieha tak, že používateľ (hráč) volí
nasledovný krok a systém simuluje jeho plnenie, pričom môžu nastať náhodné javy ako zhoršenie
počasia, ochorenie člena výpravy, lavína ktorá zasype tábor. Hráč má k dispozícii aj predpoveď
počasia, ktorá sa ale môže meniť. Hra končí alebo splnením cieľa alebo stroskotaním expedície z
rôznych dôvodov ako je chybné plánovanie zloženia expedície, málo materiálu, zlé dlhodobé a
krátkodobé rozhodnutia.
Program pre simuláciu je stavový stroj, kde prechod do nasledujúceho stavu riadi vedúci
expedície na základe existujúceho stavu a vonkajších podmienok (zdravie a výkonnosť členov
expedície, predpoveď počasia). Prechod do nasledujúceho stavu nie je deterministický ale môže byť
ovplyvnený nečakanými udalosťami (nesplnenie úlohy vplyvom vyčerpanosti, zhoršenie počasia, pád
horolezca, lavína atď., ktoré sa môžu vyskytnúť s istou pravdepodobnosťou. Táto pravdepodobnosť
závisí od obtiažnosti terénu alebo počasia v danom období - stabilné alebo nestabilné obdobie).
Parametre určujúce stav systému sú konštanty, nastaviteľné pre každú expedíciu alebo sa môžu meniť
počas simulácie. Modely členov expedície môžu byť autonómne agenty, ktorých chovanie sa môže
nedeterministicky meniť (parameter ako výkonnosť - schopnosť prekonať určité prevýšenie v určitom
čase a s určitou záťažou v určitej nadmorskej výške). Parametre simulovaných objektov a ich rozptyl
budú k dispozícii v prvej etape riešenia projektu. Výsledky by boli vo forme zoznamov, čísiel, grafov
a interaktívna hra s grafickým rozhraním, kde prostredie (hora, tábory) a horolezci (agenti) môžu byť
zobrazení viac alebo menej realisticky.
1.1 Prehľad problémovej oblastiV tejto časti sa zameriavame na štyri hlavné aspekty problémovej oblasti – vplyvy prostredia,
vlastnosti resp. atribúty horolezcov, výbava horolezcov a činnosti a fázy výstupu – ale aj na súvislosti
medzi týmito aspektmi.
1
1.1.1 Vlastnosti (parametre) horolezcov
1.1.1.1 Dôležité vlastnosti
obr. 1. Podiel atribútov horolezca na celkovej výkonnosti
Balansovanie
Môže byť definované ako schopnosť udržať určitú pozíciu, stabilizovanie tela. Každý pohyb horolezca
závisí od bilancovania v danej situácií. Je determinované hlavne koordináciou jednotlivých pohybov
a predchádzajúcimi skúsenosťami v horolezectve. Balansovanie je veľmi dôležité na správne využitie
ostatných schopnosti horolezca
Technika
Aj silovo slabší horolezec môže s dobrou technikou dosiahnuť dobrý výkon. Špičkový horolezci musia
ovládať veľmi dobre techniku lezenia. Avšak veľmi dôležité je vedieť, že pri rôznych typoch terénu sa
používajú rôzne techniky.
Lezenie tvárou k skale
Chôdza
Lezenie v špárach
Zlaňovanie
Lokálna výdrž
Je determinovaná schopnosťou tela vykonávať miernu silovú záťaž (50 – 60% z max.) po dlhšiu dobu
(3 min). Vzťahuje sa hlavne na vykonanie kratších a plynulých trás. Trénovaním môže horolezec
využíva menej energie a obnovuje silu pri lezení.
Silová výdrž
Silová výdrž opisuje výkon blízko maximálneho výkonu po určité, značné časové obdobie. Je veľmi
dôležitá pri náročných trasách s veľkým uhlom. Veľmi rýchlo sa unavuje telo.
2
Výkonnosť
Výkonnosť sa ráta ako práca vykonaná za jednotku času. Výkonnosť hrá dôležitú úlohu pri náročnom
horolezectve. Najväčšiu silu môžu horolezci používať najviac 30 s. Veľmi dôležitá je maximálna
a celková výkonnosť horolezca.
Sila
Je to schopnosť výkonu. Keď hovoríme o tom aké silné máme svaly hovoríme o tom akú silu vie daný
sval vykonať. Sila je dôležitá na plynulé premiestňovanie sa horolezca po jeho trase. Aj každá
technika vyžaduje určitú dávku sily. Pri náročných trasách je jedným z hlavných atribútov horolezcov.
1.1.1.2 Významnosť atribútov pri rôznych druhoch lezenia
Dôležitosť jednotlivých atribútov pri lezení po skale vyjadruje polygón vo vnútri osemuholníka na
obr. 2.
obr. 2. Význam atribútov pri lezení po skale
Dôležitosť jednotlivých atribútov pri lezení po ľadovci (vysokohorský výstup) vyjadruje polygón vo
vnútri osemuholníka na obr. 3.
3
obr. 3. Význam atribútov pri lezení po ľadovci
1.1.1.3 Spotreba kalórií za hodinu (70 kg horolezec)
Vertikálne lezenie 770 cal/h
chodenie po horách s 20 kg ruksakom 630 cal/h
chodenie po horách s 35 kg ruksakom 840 cal/h
1.1.2 Výstroj a výbava horolezcov
Pri plánovaní expedícií je treba klásť veľký dôraz na výbavu, ktorú si so sebou musíme vziať. Táto
výbava zahŕňa oblečenie, pomôcky na táborenie, horolezecký výstroj, lieky a ďalšie podporné
prostriedky. Treba brať do úvahy poveternostné podmienky daného miesta. Niektoré vybavenie si
nesie každý horolezec sám, iné je spoločné a nesú ho nosiči alebo niektorý zvolený horolezec.
Na internete je možné nájsť viacero obchodov, ktoré ponúkajú horolezeckú výbavu, napr. [2],
[3], [4] a [5]. Tu je možné vidieť všetok štandardný inventár, ktorý je potrebný pre expedíciu.
1.1.2.1 Základné kategórie materiálu
Z analýzy ponúkaného tovaru v obchodoch a z informácií, ktoré nám poskytol doc. Šperka, môžeme
inventár rozdeliť na nasledovné kategórie:
Oblečenie
Veci na spanie
Kuchyňa a jedlo
Horolezecký výstroj
4
Svietidlá
Komunikačné pomôcky
Navigačné pomôcky
Zdravie
Lieky
Ostatný výstroj
V nasledujúcej tabuľke je celkový prehľad analyzovaného inventáru. Je tu uvedený nástroj
výstroja, jeho primárny účel, na ktorý slúži, a indikátor množstva – či je potrebné, aby danú vec mal
každý člen expedície alebo nie.
Účel: Množstvo:Oblečenie:
spodná bielizeň chráni pred chladom jednotlivecspodky chráni pred chladom jednotlivec
hrubé ponožky chráni pred chladom jednotliveckošeľa chráni pred chladom jednotlivec
nohavice chráni pred chladom jednotlivecsveter chráni pred chladom jednotlivec
teplá vesta chráni pred chladom jednotlivecnepremokavá bunda chráni pred chladom a vlhkom jednotlivec
pršiplášť chráni pred vlhkom jednotlivecrukavice chráni pred chladom jednotlivec
čiapka chráni pred chladom jednotlivectvárová maska chráni pred vetrom a mrazom jednotlivec
slnečné okuliare ochrana pred slnkom jednotlivecochranné okuliare ochrana pred slnkom a vetrom jednotlivec
pevná kožená obuv chráni pred chladom, umožňuje pohyb v teréne jednotlivecSpanie:
spací vak chráni pred chladom, miesto na spanie jednotliveckarimatka tvorí tepelnú izoláciu od zeme jednotlivec
skladacie stoličky miesto na sedenie -stan chráni pred vetrom, mrazom a zrážkami, úkryt -
Kuchyňa: varič prístroj na prípravu jedla -
plynové bomby palivo do variča -nádoby skladovanie jedla a tekutín -
termosky uchovanie teplých tekutín -vodný filter úprava vody do požívateľnej podoby -
tekutiny ochrana pred dehydratáciou jednotlivecinstantné jedlá energetický zdroj -
zelenina a ovocie zdroj vitamínov (tiež energie a tekutín) -energetické tyčinky nevyhnutný rýchly zdroj energie jednotlivec
Horolez. výstroj: fixné laná slúžia na vytýčenie trasy -
mačky umožňujú pohyb v ťažkom horskom teréne jednotlivecskoby poskytujú uchytenie v skale jednotlivec1
1 predpokladá sa niekoľko kusov na osobu
5
karabíny spájanie lán jednotlivec2
čakan umožňuje úpravu zľadovateného terénu jednotliveckladka umožňuje ľahko dvíhať ťažké predmety alebo ľudí jednotlivechelma ochrana hlavy jednotlivec
úväz umožňuje istiť človeka lanami jednotlivecpopruhy umožňuje istiť človeka lanami jednotlivec
slučky pohyblivé uchytenie na lane jednotlivecsnehová lopatka nástroj na odhadzovanie snehu jednotlivecskrutky do ľadu poskytujú pevné uchytenie v ľadovej kryhe jednotlivec
Svetlo: baterka zdroj svetla jednotlivec
čelová lampa malý zdroj svetla jednotliveczápalky zdroj ohňa jednotlivec
zapaľovač zdroj ohňa jednotlivecsviečky malý zdroj svetla -
Navigácia: hodiny určovanie času jednotlivec
kompas určovanie svetových strán jednotlivecbuzola určovanie svetových strán a azimutov -
výškomer určovanie výškovej polohy jednotlivecteleskop umožňuje vidieť do diaľky -
mapa prostriedok na orientáciu jednotlivecKomunikácia:
vysielačky prostriedok na komunikáciu jednotlivecnotebook prostriedok na posielanie fotografií -
rádio prostriedok na predpovede -Zdravie:
opaľovací krém ochrana pred slnkom -balzam na pery ochrana pred mrazom -
kyslíková bomba umožňuje dýchať v polohách s riedkym vzduchom -lieky pomoc proti rôznym chorobám -
lekárnička prvá pomoc jednotlivecOstatný výstroj:
chrbtiak poskytuje úložný priestor pre ostatné veci jednotlivecsnežná pílka pomôcka na rezanie ľadu -
sekera nástroj na sekanie a pribíjanie jednotlivecsnežné topánky umožňujú pohyb v mäkkom snehu jednotlivec
nôž nástroj na rezanie jednotliveckufrík s náradím sada na opravovanie -
agregát zdroj energie -hygienické potreby umožňujú vykonanie potrieb mimo tábora jednotlivec
Tabuľka 1 Zoznam inventáru potrebného na expedíciu
1.1.2.2 Popis niektorých charakteristík výbavy horolezcov
Oblečenie
2 predpokladá sa niekoľko kusov na osobu
6
Bavlnené oblečenie nie je vhodné, lebo spotené odvádza teplo.
Horolezecký výstroj
Laná môžu byť statické (fixné) a dynamické. Ako materiál sa používa konope a nylon.
Nylonové laná – ľahké, flexibilné, odolné voči chladu
Konopné laná – ľahko uchopiteľné, odolné voči teplu
Navigácia a komunikácie
Členovia sú v kontakte pomocou vysielačiek. Okrem toho v základnom tábore môžu mať rádio na
získanie informácií o predpovedi počasia a v poslednej dobe je súčasťou výbavy aj notebook
s prístupom na internet, pomocou ktorého sa odosielajú fotky a podávajú sa informácie o postupe
domov.
Jedlo
V hlavnom tábore sa dajú pripraviť klasické jedlá. V táboroch sa dá jedlo pripravovať na variči.
Výhodné je brať špeciálne instantné jedlá, pretože nezaberajú veľa priestoru medzi batožinou. Do
terénu si horolezci berú energetické tyčinky. Vo väčších nadmorských výškach však nechutí jesť.
Je dôležité mať dostatok vody, preto je nutné mať vodné filtre a varič, aby bolo možné rýchlo
pripraviť vodu zo snehu alebo ľadu.
Lieky
Do základnej výbavy by mali členovia expedície zahrnúť lieky proti bolesti hlavy a žalúdka,
nevoľnosti, lieky na potlačenie výškovej choroby, nejaké základné antibiotiká, lieky proti zníženiu
príznakov dehydratácie a výškovej choroby a iné špecifické lieky, ktoré potrebujú členovia expedície.
Ostatný výstroj
Zápalky, mapy a podobné predmety, ktoré by mohli navlhnúť musia byť zabalené v igelitovom
vrecku.
1.1.2.3 Prenos výstroja a vybavenia
Do základného tábora všetok výstroj a vybavenie vynesú nosiči (je pre nich potrebné rátať s jedlom
navyše). Výbava ostane uskladnená v základnom tábore, ktorý tvorí niekoľko stanov – obytné stany
(členovia sú ubytovaný po dvoch alebo samostatne), sklad a kuchyňa. Zo základného tábora potom
potrebnú výbavu po častiach nosia horolezci sami. Na postavenie ostatných táborov sa spravidla
používajú jeden až dva stany.
7
1.1.2.4 Nosnosť horolezca
Maximálna hmotnosť, ktorú môže jeden horolezec niesť je závislá od výšky. V nasledujúcej tabuľke
sú uvedené orientačné hodnoty nosnosti horolezca od výšky. Tieto hodnoty treba brať do úvahy pri
plánovaní prenosu výbavy medzi tábormi – ak hmotnosť prevyšuje nosnosť horolezca, transport sa
musí uskutočniť na viac krokov alebo výstroj musia niesť viacerí horolezci.
Výška: Hmotnosť záťaže:5000 – 6200 m n. m. 20 kg6200 – 7400 m n. m. 15 kg
nad 7400 m n. m. 10 kg
Tabuľka 2 Závislosť nosnosti horolezcov od výšky
1.1.3 Vplyvy prostredia a ich riziká
Pri výstupe na vrchol sa horolezci stretávajú s prostredím, kde vládnu rôznorodé a premenlivé
podmienky. Jednotlivé vplyvy prostredia prinášajú rôzne riziká, na ktoré by si mali horolezci dávať
pozor.
1.1.3.1 Poveternostné vplyvy
Silný vietor a búrky, blesky [6]
Ak nás prekvapí studený front a búrka nepripravených môže to vo vysokých horách dopadnúť zle.
Možný je pokles teploty o 10 - 15 °C a môže nás ohroziť studený dážď, sneženie, krúpy, búrka. Aj v
malom potoku môže prudko stúpnuť voda.
Vo výške nad 2000 m môže byť úplne iná poveternostná situácia ako dole v údolí. Aj
uprostred leta môže snežiť. Dážď, sneh podstatne sťažujú chôdzu, terén sa stane šmykľavý - hrozí
nebezpečenstvo pádu. Hustá hmla alebo nízka oblačnosť sťažujú orientáciu a znižujú rýchlosť
pochodu. Pokiaľ nie sme vhodne oblečený ľadový vietor nás podchladí behom niekoľkých minút,
preto v predpovedi oznámené búrky alebo prechod studeného frontu brať vážne. Ak prichádza búrka
vyhýbať sa zaisteným cestám a hrebeňom, kde je väčšia možnosť zásahu bleskom.
Hmla [6]
Na horách často vznikajú hmly. Hmla je zrážajúca sa vodná para na drobné kvapôčky v chladnej
vzduchovej vrstve. Veľmi sťažuje orientáciu pre nedostatok záchytných bodov vplyvom nízkej
dohľadnosti. Musíme si všímať aj nepatrné terénne útvary. Niekedy sa pozeráme i naspäť, či v
opačnom smere nie je značkovanie spoľahlivejšie.
8
Ak stratíme značku nesnažiť sa "nejako" postupovať ďalej ale vrátiť sa k poslednej značke a
cestu znovu hľadať. Postup naslepo neznámym vysokohorským terénom môže byť životu nebezpečný.
Za zníženej viditeľnosti alebo v nepriehľadnom teréne sa skupina musí držať spolu.
Slnko [6]
Nepodceňovať jeho účinky. Slnečné žiarenie je na horách za jasnej oblohy silnejšie ako pri mori. Preto
si musíme chrániť pokožku (krémy s vysokým UV faktorom), pery (masť na pery) a oči (dobré
slnečné alebo ľadovcové okuliare so 100% UV ochranou). Chrániť si aj hlavu pred úpalom, krk a uši
pred spálením.
Difúzne (rozptýlené) svetlo [6]
Vyskytuje sa vtedy keď je jemná hmla a presvitá slnko. Všetko je biele, sneh aj obloha. Terén je rovný
a plochý, nevrhá tiene a nie sú kontrasty. Kráčať opatrne, lebo nerozoznáme priehlbiny ani prevýšenia.
Ľahko môžeme spadnúť. Opatrne pri zjazde na lyžiach. Aj keď je hmla treba mať slnečné okuliare
lebo intenzita slnečných lúčov je vyššia.
Vplyv vetra na teplotu ovzdušia [7]
Už ste sa určite stretli s tým, ako vietor dokáže negatívne zmeniť tepelnú pohodu. Vplyvom vetra sa
prúdením (konvekciou) zvyšujú tepelné straty. Tento jav sa nazýva Wind Chill faktor (chlad vetra).
Vyjadruje stratu tepla súčasným pôsobením vetra a chladu, je priamo úmerný tepelnému gradientu a
rýchlosti prúdenia vzduchu. Jeho veľkosť udávajú niektoré meteorologické stanice vo svojej
predpovedi.
Za bezvetria sa tenká vrstva vzduchu ohrievaná ľudským telom drží blízko tela a tvorí
mikroklímu. Nepríjemný pocit chladu vzniká, keď sa prúdením odstraňuje naša mikroklíma z povrchu
tela. Preto sa nám vzduch zdá chladnejší ako je v skutočnosti. Wind chill faktor nie je fyzikálna
veličina ale dáva predstavu akú teplotu vnímame vo vetre („zdanlivý chlad“, ekvivalentná teplota).
Pociťujú ho ľudia a zvieratá, teplota na teplomery sa vplyvom vetra nemení.
Vplyv má aj relatívna vlhkosť vzduchu, čím je vyššia, tým je pôsobenie chladu väčšie. Pri silnom
vetre môžeme omrznúť aj pri plusových teplotách.
1.1.3.2 Lavíny [8]
Lavíny sú prírodným javom v zime v horách a ľudstvo sa stretáva s nimi odjakživa. Ročne spadne na
celej zemeguli viac než 1.000.000 lavín a okrem veľkých škôd pripravia lavíny len v Alpách o život
priemerne viac ako 100 ľudí ročne. Kedysi mali ľudia pred lavínami veľký rešpekt a vždy sa snažili na
základe získaných skúseností minimalizovať ich účinok. Lavíny boli dlho nevypočítateľné. Dnes
9
možno pri dnešnom vedeckom poznaní relatívne dobre a presne predpovedať lavíny približne s 80 %
presnosťou, ale nikdy sa to nedá predpovedať na 100 %.
Lavínová situácia je závislá od viacerých faktorov:
Závislosť od terénu
Náchylnosť svahu k padaniu lavín je určená hlavne sklonom, orientáciou k svetovej strane (expozícia),
tvarom a členitosťou terénu, podkladom.
Závislosť od počasia
Lavína sa spustí keď je snehová vrstva nestabilná a zaťaženie je väčšie ako odpor proti pohybu. Pri
vzniku lavín majú z meteorologického hľadiska najväčší význam snehové podmienky, smer a sila
vetra spoločne s priebehom teploty. Zmena počasia môže rýchlo zmeniť lavínovú situáciu aj počas
túry.
Závislosť od snehových podmienok
Hrubšia snehová pokrývka sa vplyvom gravitácie stabilizuje lepšie ako tenká. Veľké množstvo nového
snehu býva príčinou samovoľného uvoľňovania veľkého počtu veľkých lavín. Pre posúdenie
lavínového nebezpečenstva nie je rozhodujúca celková výška snehovej pokrývky, ale intenzita zrážok,
čo znamená množstvo nového snehu za jednotku času. Či napadne 50 cm snehu za 12 alebo 24 hodín
je už veľký rozdiel. Už napadnutie viac ako 2 cm snehu za hodinu zvyšuje lavínové nebezpečenstvo.
1.1.3.3 Nebezpečný terén [9]
Padajúce kamene
Ako beží čas, skalné útvary sa rozpadávajú na menšie skaly. To môže byť spôsobené eróziou, vetrom,
topiacim sa ľadom, činnosťou zvierat. Niekedy to tiež môže zapríčinené ľudskou činnosťou, napríklad
predošlými expedíciami.
Padajúce kamene sú nebezpečné, pretože môžu spôsobiť vážne zranenia, napríklad zlomeniny.
Hoci je pred nimi možné väčšinou uskočiť, padajúce kamene môžeme aj predvídať pomocou
niektorých vonkajších znakov. Na miestach, kde kamene padajú často, môžeme dole nájsť sutiny
alebo menšie úlomky skál. Na zasnežených miestach padajúce kamene vytvárajú ryhy, ktoré sú
viditeľné z diaľky. Za každých okolností sa vyhýbajte kempovaniu alebo dlhšiemu zotrvávaniu na
miestach s týmito znakmi. Ak je potrebné nimi prejsť, urobte tak rýchlo a opatrne ako je to len možné.
Tiež môže pomôcť nasadená ochranná prilba.
Padajúci ľad
10
Podobne ako kamene, malé kúsky ľadu sa občas odlomia z ľadovca, keď stúpa teplota. To vedie
k padaniu ľadu. Rovnako ako padajúce kamene, aj padajúcemu ľadu by ste sa mali vyhýbať. Vo
všeobecnosti sa neodporúča liezť na ľadovcom pokryté skalné plochy počas teplého dňa, zvlášť nie, ak
sa blíži jar. Avšak miesta, kde zvyčajne ľad padá, môžu byť tiež rozpoznané podľa sutín pod nimi.
Pokiaľ to je možné, vyhýbajte sa týmto miestam.
Trhliny
Pozdĺž ľadovcov alebo snehových oblastí sa nachádzajú obrovské a hlboké praskliny alebo diery,
ktoré sú spôsobené pohybom ľadovca. Trhliny môžu byť pozorovateľné alebo skryté (zvyčajne
snehovou pokrývkou). Rozpoznávanie skrytých trhlín si od horolezca vyžaduje vysokú úroveň
skúseností. Počas chôdze naprieč ľadovcom pokrytým snehom je vašim najlepším zabezpečením to, ak
je vedúci tímu pripútaný lanom k aspoň dvom ďalším členom tímu, ktorí idú vedľa seba a priamo
nasledujú vedúceho tímu. Tým sa predíde jeho pádu na dno skrytej trhliny v prípade, ak na nejakú
stúpi. Ale aby to bolo isté, je potrebné, aby každý člen tímu prechádzajúci naprieč ľadovcom mal
tréning na zachraňovanie v takejto situácii.
Zľadovatené svahy
Pri chôdzi cez svahy pokryté ľadom alebo ťažkým snehom sú mačky nutnosťou. Mačky sú sady
kovových hrotov, ktoré môžu byť pripevnené na spodok vašej topánky. Pomáhajú tým, že prebodávajú
ľad alebo sneh, čím poskytujú dostatočnú priľnavosť na inak klzkom povrchu. Ďalším dobrým
nástrojom je cepín – tyč s čakanom na vrchu a s hrotom na spodku. Ten hrot sa používa na
zabezpečenie stability a rovnováhy počas chôdze po ľade presne ako vychádzková palica.
Zasnežené svahy
Tieto sú častejšie ako svahy s ťažkým snehom alebo ľadom. Zasnežené svahy sú vo všeobecnosti
ľahké na lezenie, ale dávajte si pozor na ľadovcové trhliny. Zvyčajne na úpätí svahu sú široké trhliny
a väčšinou príliš široké na to, aby ste ich preskočili. Prekonanie takejto ľadovcovej trhliny vyžaduje
použitie mosta, ktorého stavba môže byť dosť zložitá. Predtým ako prejdete cez zasnežený sneh,
všimnite si kvalitu snehu. Nová vrstva snehu na ľade môže byť nebezpečná, pretože prechod cez neho
môže ľahko spôsobiť lavínu. Najlepší druh snehu je ťažší typ, s ktorým sa môžete stretnúť skoro ráno.
Popoludní, ako sa zvyšuje teplota, má sneh tendenciu zmäknúť. Preto je ideálne začať túru v skorých
ranných hodinách.
11
1.1.3.4 Choroby spojené s nadmorskou výškou [10]
Akútna horská nemoc (AMS - acute mountain sickness)
V podstate ide o preťaženie prípadne o dekompenzáciu organizmu na nedostatok kyslíka. Môže sa
vyskytnúť vo výškach medzi 2500 a 6000 metrov a pravdepodobne postihuje 30 až 50 % horolezcov a
trekerov. Asi 50% všetkých trekerov nad 5000 m má príznaky horskej nemoci, pri čom sa jednotlivé
príznaky prejavujú jednotlivo alebo v kombinácii. Príčinou choroby je pravdepodobne ľahký opuch
mozgu v dôsledku nedostatku kyslíka. Ťažkosti sa vyskytnú 6 až 48 hodín po dosiahnutí danej výšky a
pri zodpovedajúcom správaní po jednom alebo dvoch dňoch spontánne ustúpia.
Výškový opuch pľúc (HAPE - high altitude pulmonary edema)
Opuch pľúc sa vyskytuje v 1-3 % od kritickej výšky nad 4000 m a v počiatkoch je ťažko
rozpoznateľný, pretože príznaky sa podceňujú. K zhoršenie príde asi do 48 hodín po dosiahnutí novej
maximálnej výšky, najčastejšie v noci, pretože v ľahu je tlak v pľúcach vyšší ako v stoji. HAPE
nemusia predchádzať príznaky AMS. Po troch dňoch v novej výške je riziko, že dostaneme HAPE,
veľmi malé.
Výškový opuch mozgu (HACE - high altitude cerebral edema)
Je to ťažká forma horskej nemoci. Je zriedkavejšia ako HAPE, ale je viac nebezpečná, úmrtnosť je
okolo 40%. HACE sa všeobecne vyvíja viac dní a prejavuje sa vo výške nad 5000 m.
Nervové tkanivo mozgu reaguje veľmi citlivo na nedostatok kyslíka. Chorobu spôsobuje zmena
prekrvenia a rozdelenia tekutín. Nadmerné množstvo tekutiny v hlave stláča mozog. Dochádza
pozvoľna k opúchaniu a zvyšovaniu tlaku v mozgu čo čiastočne ovplyvňuje jeho riadiacu funkciu.
1.1.3.5 Najčastejšie zdravotné riziká
Omrzliny [11]
Omrzlina je akútne miestne poškodenie tkaniva spôsobené chladom pri teplotách pod bodom mrazu za
súčasne nízkej vlhkosti vzduchu. Pri silnom vetre k nej môže prísť aj pri vyšších teplotách.
K omrznutiu dochádza najmä na miestach úplne vystavených účinku mrazu a vetru ako sú tvár, nos,
ušné laloky alebo na miestach nedostatočne chránených – na prstoch rúk a nôh. Teplota na týchto
periférnych častiach klesá v chlade oveľa rýchlejšie.
Dehydratácia
Dehydratácia je spôsobená nedostatočným prísunom tekutín do organizmu. Pri dehydratácii má krv
zvýšenú hustotu, jej cirkulácia v tele je pomalšia a preto sa zvyšuje riziko vzniku omrzlín. Preto je
dôležitý pravidelný prísun tekutín, najlepšie čistej vody.
12
1.1.3.6 Lesné požiare [12]
V prírode je vo všeobecnosti veľké riziko vzniku požiarov. Suchá tráva, konáriky, listy a stromy, to
všetko vytvára perfektné palivo, ktoré sa môže jednoducho vznietiť a vytvoriť dravý požiar.
1.1.3.7 Riziká spojené s faunou [13]
Hlavne v nižšie položených (nielen) horských oblastiach sa horolezci môžu stretnúť s rizikami, ktoré
prináša prítomnosť určitých druhov zvierat. Medzi tieto riziká patria napríklad:
poštípanie hmyzom a včelami
pohryznutie hadmi a škorpiónmi
útoky medveďov
1.1.4 Závislosť energie horolezca od parametrov prostredia
V tejto časti je opísaná závislosť energie horolezca od parametrov prostredia na základe údajov
získaných z [14] a [7].
13
obr. 4. Závislosť energie horolezca od parametrov prostredia
Tlak vzduchu
s rastúcou výškou klesá klesá aj tlak kyslíka nedostatok kyslíka v organizme proces
adaptácie (zrýchlenie dýchania a pulzu) dlhodobo to stojí veľa energie
pri nízkej teplote klesá rýchlejšie
Teplota vzduchu
s rastúcou výškou klesá (približne 6,5 °C na kilometer) rýchlejšie odvádzanie tepla
z organizmu väčšia spotreba energie
pri nízkej vlhkosti vzduchu klesá rýchlejšie (až do 10 °C na kilometer)
Pôsobenie vetra
s rastúcou rýchlosťou vetra rastú tepelné straty klesá energia horolezca
14
1.1.5 Činnosti a fázy horolezeckého výstupu
Horolezecká expedícia pozostáva z niekoľkých fáz a činností. Na nasledujúcich stranách sú popísané
najdôležitejšie z nich.
Uvádzané informácie pochádzajú z viacerých zdrojov na internetových stránkach [15], [16]
a z poznámok pochádzajúcich z diskusie s doc. Šperkom ohľadne danej problematiky.
Presun do základného tábora
Výstup do základného tábora je zväčša zabezpečený použitím autobusov, džípov alebo zvierat (napr.
jaky, ťavy alebo lamy) a môže trvať aj niekoľko dní.
Pri výstupe na veľmi vysoké hory býva posledná časť cesty k základnému táboru často
nedostupná pre autá alebo zvieratá. Vtedy si horolezci najímajú nosičov z okolitých osád, ktorí im
pomáhajú preniesť horolezecký výstroj, ale najmä jedlo určené na niekoľko týždňov. Niekedy
hmotnosť tohto nákladu dosahuje niekoľko ton, a preto nosiči absolvujú túto časť cesty niekoľkokrát.
Každý nosič totiž môže niesť maximálne 20 kg.
Odporúča sa zabezpečiť každú batožinu nejakým zámkom, pretože bude počas cesty do
základného tábora občas nestrážená [15].
Oddych v základnom tábore
V základnom tábore horolezci na začiatku strávia zopár dní, počas ktorých začínajú s aklimatizáciou –
robia kratšie túry, oddychujú a pijú veľa tekutín. Niekedy tu musia čakať na lepšie počasie.
Počas procesu aklimatizácie sa horolezci vracajú do základného tábora vždy pred tým, ako sa
pokúsia dosiahnuť vyššie položený tábor, prípadne samotný vrchol hory. Vtedy tu trávia aj niekoľko
dní, počas ktorých najmä oddychujú.
Ak je základný tábor položený vyššie ako 5000 m, aj v základnom sa už môžu prejaviť prvé
náznaky výškových chorôb, napr. bolesti hlavy a kašeľ. Vtedy býva niekedy nutné prepraviť malátnu
osobu do nemocnice.
Čakanie v stanoch na lepšie počasie
Počasie na horách sa mení a počas snežných búrok je lepšie zostať v základnom tábore. Čakanie na
lepšie počasie niekedy trvá aj týždeň. Takéto dni horolezci trávia hraním kariet, šachov,
navštevovaním členov iných expedícií, počúvaním hudby, čítaním kníh, prípadne pozeraním filmov
(ak im to prostriedky umožnia).
15
Kladenie fixných lán
Fixné laná sú potrebné najmä pri vynášaní materiálu pre nosičov a pre tých horolezcov, ktorí nemajú
dostatočné schopnosti prejsť daným terénom bez týchto lán. Väčšinou ich však používa každý (ak sú),
pretože podmienky sa často menia a z relatívne bezpečného snehu sa môže stať klzký ľad.
Fixné laná kladú hlavne dobrí horolezci – „šplhači“ a to minimálne dvaja.
Stavba tábora
Ak na hore nie sú trvalé výškové tábory, horolezci si zakladajú vlastné tábory. Príprava na stavbu
nového tábora sa začína už v predošlom tábore. Horolezci si potrebujú nachystať stan a nástroje na
jeho postavenie. Potom sa aspoň dvaja z nich vyberú do akcie. Keďže stany majú istú hmotnosť,
horolezci väčšinou postupujú po fixných lanách.
Horolezci zakladajúci tábor potrebujú nájsť vhodné miesto. Takéto miesto by nemalo byť
ohrozené zosuvmi skál, ľadovcov či lavín. Výhodné býva miesto s menšími vplyvmi vetra.
Nájsť perfektné miesto na tábor býva často nemožné. Po voľbe miesta je potrebné zarovnať
priestor na stany napríklad pomocou okolitého kamenia. Nakoniec je možné realizovať stavbu stanov.
Vybavenie tábora, vynesenie materiálu
Ak má expedícia zabezpečených nosičov, títo sa môžu podieľať aj na vynášaní materiálu do vyšších
táborov. Inak si horolezci vynášajú materiál sami.
Materiál sa do tábora zvykne vynášať niekoľko hodín až deň pred tým, ako si v ňom horolezci
naplánujú prenocovanie alebo prestávku pred pokračovaním vo výstupe.
V prípade ťažkého terénu sa pri vynášaní materiálu používajú fixné laná.
Zostup
Horolezecká expedícia nekončí na vrchole hory. Pre horolezcov je dôležité dostať sa naspäť do
základného tábora a odtiaľ domov. Veľa zostupov sa realizuje aj počas procesu aklimatizácie, kedy sa
po dosiahnutí novej výšky (ďalší tábor) zostupuje späť do základného tábora.
Pri zostupe sa takisto s výhodou používajú fixné laná, ktoré zostup uľahčujú a urýchľujú.
Záchrana chorého a zraneného
Na hore (možno s výnimkou základného tábora) by nemal nikto zostať sám.
V prípade vážnejších príznakov výškovej choroby u niektorého z horolezcov, je potrebné
zostúpiť s ním do výšky, kde sa naposledy cítil dobre, prípadne až do základného tábora. Neodporúča
sa, aby chorý horolezec zostupoval sám – potrebuje aspoň jedného ďalšieho horolezca ako sprievod.
Zároveň nie je dobré nechať jediného horolezca pokračovať vo výstupe. Ak sú horolezci štyria alebo
viacerí, môžu sa rozdeliť na dve skupiny, pričom jedna bude sprevádzať chorého, kým druhá skupina
môže pokračovať ďalej vo výstupe.
16
V prípade vážneho ochorenia alebo zranenia je nutné transportovať postihnutého do nemocnice.
V niektorých oblastiach je možné na takýto transport použitý vrtuľník. V týchto oblastiach členovia
horolezeckej expedície vopred absolvujú inštruktážny tréning, v ktorom sa dozvedia napríklad
o kreslení znaku H a veternom rukáve.
Bivakovanie
Ak si horolezci nedostatočne naplánujú výstup, môže ich pri výstupe zastihnúť noc. Vtedy im môžu
pomôcť čelové lampy, ktorými si svietia na terén. Ak je však terén náročný, mohlo by ďalšie
postupovanie cez terén viesť k zraneniu.
Za týchto okolností horolezci môžu uprednostniť bivakovanie. Bivakovaním síce predídu
riziku zranenia pri postupovaní terénom, ale má to aj svoje nevýhody. Najčastejším faktorom, ktorý je
príčinou neúspešného bivakovania, je nízka teplota. Spacie vaky totiž menej chránia horolezca pred
chladom ako stany, a preto veľmi často dochádza k omrzlinám, dokonca aj k smrti zapríčinenej
podchladením.
1.1.6 Adaptácia a aklimatizácia [14]
Nedostatok kyslíka je asi od 3000 m pozorovateľný a prispôsobovanie sa veľkej výške vyvoláva
mnohonásobné reakcie tela. Organizmus má snahu zachovať si vnútornú stálosť, preto pri zmene
podmienok odlišných od bežného prostredia sa mobilizujú príslušné mechanizmy, ktoré vedú k
stabilite vnútorného prostredia. Proces zaobstarania kyslíka sa delí na dve časti: Najprv dýchaním sa
dopraví kyslík do pľúc a potom sa kyslík transformuje krvným obehom z pľúca do buniek. Telo
reagujú na nedostatok kyslíka nasledovne:
a) zvýšením rýchlosti procesov (dýchanie, pulz) – adaptácia
b) zvýšením efektívnosti procesov (zvýšenie počtu červených krviniek) – aklimatizácia
Adaptácia
je okamžitá reakcia organizmu na nedostatok kyslíka (hypoxia). Reaguje zrýchleným dýchaním
(hyperventilácia), súčasne sa zrýchli aj pulz a tým sa upravuje prísun kyslíka na požadovanú hodnotu.
Tento proces sa nazýva adaptácia. To nie je dlhodobo žiaduce, lebo zrýchlenie týchto procesov stojí
trvale veľa energie. Ak sme vo výške dlhší čas (deň a viac) telo sa začne prispôsobovať novým
podmienkam, až postupne dôjde k aklimatizácii na danú výšku.
Aklimatizácia
je dlhodobý proces a znamená úplné prispôsobenie sa výške. Medzi hlavné prejavy aklimatizácie patrí
zvýšená transportná kapacita kyslíka krvou. Vystrieda adaptáciu v priebehu dní a týždňov. To
znamená že krvný obeh opäť funguje v normálnych hodnotách ako doma. Aklimatizácia je pomalší
17
proces, ktorý riadi zmenu zloženia krvi a trvá prirodzene nejaký čas. V podstate ide o zvýšenie počtu
červených krviniek aby bol prenos kyslíka efektívnejší. Zlepší sa príjem kyslíka v bunkách a ďalšie
zložité regulačné pochody. Po dlhšom pobyte, keď sa už červené krvinky rozmnožia, pulzová
frekvencia znovu klesne a spotrebováva sa tak opäť menej energie. V priebehu dvoch až troch týždňov
dosiahne množstvo červených krviniek maximum a potom opäť pomaly klesá. Zvýšenie počtu
červených krviniek spôsobí, že krv je hustejšia. Aj po aklimatizácii je frekvencia dýchania o niečo
vyššia ako doma. Aby sme dosiahli dobrú aklimatizáciu musíme dodržať doporučené pravidlá.
Pri aklimatizácii sa neprejavuje pamäťový efekt čiže adaptačné zmeny majú len prechodnú -
reverzibilnú povahu! To znamená že pri každom novom podujatí sa musíme znovu aklimatizovať.
Predchádzajúca dobrá reakcia na výšku neznamená, že už nemôžeme dostať akútnu horskú nemoc.
Odporučenia:
základné pravidlo znie: „Nechoď príliš rýchlo príliš vysoko!“
výška v ktorej budeme spať by sa mala zvyšovať denne o 300 až 500 m,
prespať o 200-300 m nižšie než je v ten deň dosiahnutá max. výška
počas aklimatizácie nevystupovať počas jedného dňa vyššie než o 1500 m
na každých 1000 m dosiahnutej výšky pridať jeden odpočinkový deň
v priebehu jedného týždňa nespať vyššie než o 1000 m
prvý týždeň by sme nemali vystúpiť vyššie ako 5000 m
na začiatok žiadny veľký výkon, telesnú námahu zvyšovať postupne, vyhnúť sa maximálnemu
zaťaženiu, pretože to môže narušiť aklimatizáciu
zabrániť dehydratácií a vo výškach nad 3000 m piť denne min. 2–3 litre tekutín
v strave uprednostňovať uhľohydráty
spať v polohe s mierne zvýšenou hornou polovinou tela
podľa možnosti neberte žiadne lieky, priebeh aklimatizácie sa nedá urýchliť žiadnym liekom!
včas spozorujte príznaky horskej nemoci
Ak sa zhoršuje váš zdravotný stav, okamžite zostúpte! Nečakajte do rána, okamžite zostúpte
na výšku, kde ste sa naposledy cítili po prebudení dobre!
Nechoď hore príliš rýchlo!
Choď hore, ale spi dole!
Nezostaň dlho privysoko!
Choď hore dostatočne aklimatizovaný!
Zlaté pravidlá:
Každý môže dostať horskú nemoc, ale nikto nemusí na ňu zomrieť!
Každá nemoc vo väčšej výške sa v prípade pochybnosti považuje za horskú nemoc!
Nikdy nepokračujte vo výstupe s príznakmi horskej nemoci!
18
Ak sa zhorší zdravotný ihneď zostúpte!
Nikdy nenechávajte osobu s horskou nemocou osamote!
Príznaky dostatočnej aklimatizácie:
výkon zodpovedá trénovanosti
kľudový pulz opäť klesne na pôvodnú hodnotu
prehĺbené dýchanie v kľude a pri zaťažení
periodické dýchanie v noci
dostatočné množstvo moču
Prakticky to znamená týždennú aklimatizáciu po výšku 5000 m a ďalej na každých ďalších 1000
m týždeň. Po 8 - 10 dňoch pochodu so stredne ťažkým batohom je aklimatizácia dostatočná na
prechod sediel medzi 5000 m a 6000 m alebo k spaniu v základnom tábore. Ak ostaneme v
dosiahnutej výške viac dní tak nečakáme pasívne. Ľahká telesná aktivita napr. kratšie túry podporuje
proces aklimatizácie.
Jednoduchý a veľmi cenný údaj o priebehu aklimatizácie je ranný kľudový pulz. V počiatočnej
fáze alebo pri každej novej dosiahnutej výške zmerať tep a namerané hodnoty zapísať. Dobrý priebeh
aklimatizácie je vtedy ak je malý rozdiel medzi pulzom doma a vo výške. Ak je rozdiel väčší ako 20 -
30 úderov v žiadnom prípade nepostupovať vyššie. Pulz niekoľko dní kolíše a po úspešnej adaptácii
dosiahne normálne hodnoty ako doma. Poznámka: príčinou zvýšenia pulzu môže byť aj nedostatok
tekutín.
Messner doporučuje nasledovný postup:
zvyšovať výšku cez deň: 1 týždeň do 5000 m, ďalej 1000m / týždeň
zvyšovať výšku pri prenocovaní: 1 týždeň do 4000 m, ďalej 1000 m / týždeň
na päťtisícovku minimálne týždeň, na šesťtisícovku dva týždne, na sedemtisícovku tri a na
osemtisícovku štyri týždne. I pre najvyššie osemtisícovky (8500 m a vyššie) doporučuje štyri
týždne ale nie viac než šesť týždňov.
1.1.7 Plán aklimatizácie pre vrch Broad Peak
Stavba a zakladanie táborov na horách je zvyčajne založená na štandardnom pláne a dáva vášmu telu
čas, aby sa prispôsobilo zmene výšky. Nasleduje plán lezenia na Broad Peak podľa Rolanda Huntera
[16]:
Vyniesť skupinovú výbavu do Tábora 1 (5500 m) a zostúpiť do základného tábora (5100 m).
Vyniesť osobný výstroj do Tábora 1 (5500 m), stráviť tam noc a nasledujúci deň zostúpiť do
základného tábora (5100 m).
Niekoľko dní odpočívania v základnom tábore (5100 m).
19
Vyniesť skupinovú výbavu do Tábora 1 (5500 m), na ďalší deň pokračovať do Tábora 2 (6300
m) a stráviť tam dve noci pred zostupom do základného tábora.
Niekoľko dní odpočívania v základnom tábore (5100 m).
Vyliezť do Tábora 2 (6300 m), na nasledujúci deň vyniesť veci do Tábora 3 (7200 m)
a zostúpiť do základného tábora (5100 m).
Pár dní odpočinku v základnom tábore (5100 m).
Vyliezť do Tábora 2 (6300 m), na ďalší deň pokračovať do Tábora 3 (7200 m) a stráviť tam
dve noci pred zostupom do základného tábora (5100 m).
Niekoľko dní odpočívania v základnom tábore (5100 m).
Teraz by ste mali byť pripravení a aklimatizovaní, takže s vhodným počasím a podmienkami sa
nabudúce môžete pokúsiť o výstup na vrchol (8047 m).
1.2 Analýza technických prostriedkov
1.2.1 Grafické knižnice
V nasledujúcom texte sú analyzované rozličné grafické knižnice z hľadiska možnosti ich využitia pre
aplikáciu bežiacu vo viacerých oknách. Dôležitým aspektom, ktorý je pri jednotlivých knižniciach
skúmaný je možnosť spolupráce knižnice s knižnicou MFC a win ovládacími prvkami.
Uvedené sú dve grafické API: Direct3D a OpenGl, ako aj rozličné knižnice, ktoré uľahčujú
prácu s nimi.
Problém s jednotlivými knižnicami je ten, že zvyčajne vytvárajú hlavné okno sami a sami si aj
realizujú slučku správ. To komplikuje používanie MFC s týmito knižnicami.
V analýze nie sú spomínané vlastnosti knižníc vzťahujúce sa na podpory rozličných
dodatočných spracovaní obrazu a podobne, pretože sa nepredpokladá použitie týchto techník
v systéme, resp. nie sú dôležité. Techniky, ktoré budú potrebné pre funkčnosť systému podporujú
všetky spomínané API a knižnice.
1.2.1.1 API
Pri čistom využívaní ľubovolného uvedeného API, nie je problém s využívaním MFC, alebo win
ovládacích prvkov. Nevýhodou tohoto prístupu je pravdaže nutnosť programovania viacerých činností,
ktoré pomocné knižnice veľmi uľahčujú.
Direct3D
20
Direct3D API je súčasťou DirectX a zabezpečuje vykresľovanie grafiky. DirectX je produktom
spoločnosti Microsoft a pre svoju funkčnosť vyžaduje operačný systém Microsoft Windows (DirectX
je podporovaný aj konzolou XBox). To je všeobecne jeho hlavná nevýhoda.
Všetky súčasti DirectX sú založené na COM a teda objektovej paradigme [17].
OpenGl
[17] OpenGl bol pôvodne vytvorený v roku 1992 spoločnosťou Silicon Graphics. Výhodou OpenGl je
jeho vysoká podpora vo viacerých operačných systémoch.
OpenGl je založené na procedurálnej paradigme.
Výhodou OpenGl z pohľadu vytváraného systému je jeho výučba na FIIT STU. To ho robí
veľmi dobrým kandidátom, pretože sa predpokladá rozširovanie vytváraného systému v budúcnosti
inými tímami. Použitím OpenGl by sa tak zabezpečila aspoň základná skúsenosť členov budúcich
tímov s grafickým API použitým v systéme.
1.2.1.2 Knižnice
Glut
Knižnica GLUT uľahčuje tvorbu multiplatformových grafických aplikácií využívajúcich knižnicu
OpenGL. Nevýhodou knižnice GLUT je jej procedurálna realizácia, kde sa vo väčšine jej funkcií
používajú ukazovatele na funkcie.
Knižnica vyžaduje konzolovú aplikáciu a sama vytvára okno. Taktiež sama spravuje slučku
správ a nie je kompatibilná s MFC.
SDL
[18] SDL je multiplatformová multimediálna knižnica. Okrem iného sa používa aj pri tvorbe MPEG
prehrávačov. Spolupracuje s OpenGl a tiež s Direct3D. Okrem zobrazovania grafiky uľahčuje aj prácu
so zvukom.
Knižnica nie je kompatibilná s MFC. Jediný spôsob, ktorý sa podaril objaviť pri analýze je
pomôcka (http://www.polplex.co.uk/~tigger/sdl/), ktorá vykresľuje grafiku do povrchu a ten následne
kopíruje na win okno. Tento spôsob je ale pomalý. Počas analýzy bol vykonaný aj pokus
s viacvláknovou aplikáciou, ale bez pozitívnych výsledkov.
ORGE
[19] OGRE je objektovo orientovaný grafický (iba grafický) 3D prostriedok (angl. engine). Podporuje
OpenGl aj Direct3D. Autori sa primárne snažia vytvoriť prostriedok, ktorý je dobre zdokumentovaný
a má kvalitný dizajn. Až na druhom mieste je pridávanie noviniek. To predstavuje veľkú výhodu pre
projekt, pretože bude dôležitá hlavne možnosť sa rýchlo naučiť danú knižnicu (aj pre budúcich
pokračovateľov projektu) a nie sú dôležité najmodernejšie technológie. OGRE bol použitý vo
viacerých komerčných projektoch, čo dokazuje jeho vysokú úroveň.
Medzi jeho vlastnosti patria okrem iného:
21
materiálový LOD
progresívny mesh (LOD)
časticové systémy
hierarchické grafy pre popis scény
viaceré techniky pre vykresľovanie tieňov
Použitie tohoto prostriedku by mohlo výrazne zvýšiť grafickú kvalitu vytváraného systému.
OGRE je kompatibilný s MFC a okrem toho obsahuje GUI, ktorého používanie je podobné používaniu
MFC.
1.2.2 OGRE
[19] Grafický prostriedok OGRE (Object-Oriented Graphics Rendering Engine) je šírený pod
licenciou LGPL (GNU Lesser General Public License). To v podstate znamená, že je možné ho voľne
používať za predpokladu, že všetky zmeny vykonané v jadre OGRE, budú poskytnuté komunite. Na
výsledný produkt sa teda nevzťahujú v zásade žiadne obmedzenia (netreba poskytovať jeho zdrojové
kódy a je možné ho aj predávať).
Na nasledujúcich stranách je uvedená analýza tohoto grafického prostriedku. Popísané sú
hlavné triedy a ostatné najhlavnejšie vlastnosti.
1.2.2.1 Základné triedy
V nasledujúcom texte sú priblížené hlavné triedy OGRE. Ich bližší popis je možné nájsť v [20], [21].
Root
Root je vstupným bodom OGRE. Je to prvý objekt OGRE, ktorý musí vytvoriť aplikácia. Často sa
hlavná trieda aplikácie (alebo v našom prípade trieda monitoru) odvádza z tejto triedy, čím sa
zabezpečí, že je objekt tejto triedy prvý vytvorený a posledný zrušený.
Root slúži na konfiguráciu systému (napríklad výber systému pre vykresľovanie) a tiež
poskytuje prístup k ostatným objektom, ako sú SceneManager, RenderSystem a k veľkému množstvu
iných manažérov prostriedkov (angl. resource manager).
Root tiež vytvára okno pre vykresľovanie grafiky (angl. render window). Okrem toho, ale
OGRE umožňuje použiť aj okno, ktoré je vytvorené iným spôsobom (napríklad pomocou MFC).
Vtedy je nutné pred volaním metódy pre vytvorenie okna (createRenderWindow) nastaviť
identifikátor okna (angl. handle) pre systém OGRE. To sa vykoná pomocou nasledujúceho kódu [22].
NameValuePairList parms;parms["externalWindowHandle"] = StringConverter::toString((long)m_hWnd);
RenderSystem
22
RenderSystem je abstraktná trieda, ktorá poskytuje rozhranie pre prístup k použitému 3D API. Cez ňu
sa teda nastavujú jednotlivé stavy vykresľovania, ako aj využívajú operácie grafického API.
SceneManager
Z aplikačného hľadiska je táto trieda, hneď po triede Root, druhou najdôležitejšou. Jej objekt sa
zvyčajne v aplikácií využíva najčastejšie.
SceneManager má na starosti obsah scény. Čiže všetky grafické objekty, kamery, svetlá
a podobne.
Keďže jednotlivé typy scén vyžadujú iné algoritmy a aby sa zachoval čo najvyšší výkon,
existuje viacero typov SceneManager.
Octree Scene Manager- Scéna je rozdelená pomocou oktálového stromu. Scéna sa teda
v podstate delí rekurzívne do kociek a každá kocka do ďalších 8 kociek. Každá kocka potom
obsahuje len určité vrcholy a je možné jednoduchšie zistiť, ktoré polygóny sa majú
vykresľovať.
Terrain Scene Manager- Učený je pre relatívne menšie scény, ktoré obsahujú statický terén.
Manažér umožňuje generovať terén z mapy výšok (angl. heightmap).
Nature Scene Manager- Slúži pre scény, ktoré sú väčšie ako scény určené pre Terain Scene
Manager. Mapa výšok je opakovaná na viacerých políčkach, ktoré môžu mať rozličnú textúru
povrchu.
Paging Scene Manager- Je určený pre pomerne veľké scény, ktoré sú rozložené na tzv.
stránky. V jednom čase sú načítané iba tie stránky, ktoré sú potrebné. Každá stránka môže
mať inú mapu výšok a rozličné textúry povrchov pre jednotlivé výšky.
BSP Scene Manager- Je určený pre scény tvorené interiérmi. Priestor je binárne delený na
podpriestory (angl. binary space partitioning).
DotSceneOctree SceneManager- Je podobný ako Octree Scene Manager, pričom umožňuje
uchovávať všetku geometriu a grafické objekty scény v jednom súbore.
ResourceManager
Je to základná trieda viacerých tried, ktoré slúžia pre manažment prostriedkov (textúry, mapy, grafické
objekty a podobne). Každý typ prostriedku má vlastnú triedu.
Keďže existuje pre každú triedu manažéra prostriedkov iba jedna inštancia (je to vzor
singleton), je potrebné k nej pristupovať pomocou metódy getSingleton() (napríklad
TextureManager::getSingleton() pre prístup k manažérovi textúr).
Mesh
Predstavuje triedu grafických objektov, ktoré sú vytvorené v externom grafickom prostriedku
a importované do aplikácie. Objekty tejto triedy sú spravované objektom triedy MeshManager.
Entity
23
Je to inštancia pohybujúceho sa grafického objektu v scéne. Objekt tejto triedy je založený na objekte
triedy Mesh. Viaceré Entity objekty môžu mať priradené ten istý Mesh objekt (napríklad viacero
rovnakých horolezcov v scéne).
Material
Objekty tejto triedy určujú aký materiál majú grafické objekty scény a teda aký lesk, svietivosť
a podobne. Parametre materiálov je možné nastavovať aj pomocou skriptov.
Overlay
Slúži na vykresľovanie 2D elementov v 3D scéne.
1.2.2.2 Skripty
Pre uľahčenie nastavovania parametrov, podporuje OGRE ich nastavovanie pomocou skriptov. Skripty
sú textové súbory, ktoré je možné vytvárať v ľubovolnom textovom editori. Tento prístup umožňuje
meniť správanie aplikácie bez nutnosti opätovného kompilovania.
OGRE podporuje nasledovné typy skriptov:
Material Scripts- pre definovanie materiálov.
Compositor Scripts- pre definovanie dodatočného spracovania obrazu
Particle Scripts- pre definovanie časticových systémov
Overlay Scripts- pre definovanie 2D elementov
Font Definition Scripts- pre definovanie typov písma
1.2.2.3 Hardvérový kontajner
OGRE poskytuje prístup k hardvérovým kontajnerom (angl. hardware buffer), ako sú vrcholové,
indexové a bodové (angl. pixel) kontajnery.
1.2.2.4 TieneOGRE poskytuje viacero techník pre vykresľovanie tieňov v scéne.
Maskovacie tiene (angl. stencil shadows )- Využíva sa maskovací kontajner (angl. stencil
buffer). Okraje tieňa sú jasné a nedajú sa zmäkčiť. Tento spôsob zatiaľ nie je podporovaný
grafickými kartami a preto zaťažuje CPU.
Textúrové tiene (angl. texture-based shadows)- Najprv sa tieň objektu vykreslí do textúry
a potom je premietaný do scény. Nevýhodou je nízke rozlíšenie tieňa pri zmene mierky a to,
že OGRE podporuje tento typ tieňov iba pri smerových svetlách. Pri bodových by sa totižto
museli tiene vykresľovať do textúry 8 krát, aby sa pokryli všetky smery, z ktorých je svetlo
emitované.
24
Modulované tiene (angl. modulative shadows)- Najprv sa vykreslia objekty, ktoré budú
zatienené. Potom sa pre každé svetlo vykoná stmavenie častí v tieňoch a na konci sa vykreslia
objekty, ktoré neprijímajú tiene.
Prírastkové maskovanie svetla (angl. Additive Light Masking)- V podstate sa jedná
o vykreslenie jednej scény viac krát. Jeden krát pre každé svetlo, pričom sú svetlá obmedzené
tak, aby nepôsobili na miesta, ktoré sú z ich pohľadu zakryté. Jednotlivé výsledky sa postupne
spočítavajú.
1.2.2.5 Animácie
OGRE, okrem iného, umožňuje animovať grafické objekty pomocou kostry (angl. skeletal animation).
Grafický objekt obsahuje hierarchickú kostru a jeho vrcholy sú naviazane na jednotlivé kosti s určitou
váhou. Tento spôsob je výhodný hlavne z hľadiska diskového priestoru, pretože nie je nutné
uchovávať pozíciu každého vrcholu v každom snímku animácie. Uložiť stačí len natočenia
jednotlivých kostí.
25
2 Špecifikácia požiadaviek na systém
Táto kapitola obsahuje požiadavky na funkcie ako aj vlastnosti vytváraného produktu. Ďalej obsahuje
špecifikáciu funkcií systému vo forme modelu prípadov použitia. Najprv je uvedený diagram prípadov
použitia (Error: Reference source not found) celého systému a potom sú bližšie popísané jednotlivé
časti diagramu. K najdôležitejším sú uvedené aj diagramy aktivít.
2.1 Funkcie produktuFUNKCIA #1: Vytvorenie modelu vrchu.
Používateľ bude mať možnosť vytvoriť si vlastný model hory. Pre tento účel bude slúžiť samostatná
aplikácia. Toto zahŕňa vytvorenie grafického modelu hory (jej povrchu), určenie trás výstupu a ich
parametrov vrátane stanovíšť táborov a nastavenie parametrov počasia.
FUNKCIA #2: Vytvorenie grafického modelu vrchu.
Používateľ vloží do systému výškovú mapu a RGB textúru hory, ktorá popisuje farby jednotlivých
častí. Systém z týchto vstupných údajov vygeneruje grafický 3D model hory. Inou možnosťou
vytvorenia grafického modelu hory je použitie externého grafického prostriedku a import hotového 3D
modelu do systému.
FUNKCIA #3: Určenie trás výstupu a ich parametrov.
Pre vybraný model hory si užívateľ zvolí trasy výstupu. Trasy bude zadávať po úsekoch, pričom pre
každý úsek si zvolí parametre ako napríklad náročnosť terénu, riziko lavíny a pod. Takisto sa označia
miesta, kde je možné postaviť tábor, ako ja počiatočný a konečný bod expedície.
FUNKCIA #4: Nastavenie parametrov počasia.
Stav počasia je pre danú horu globálny, to znamená, že v danom čase je v celom modeli rovnaké
počasie. Používateľ si nastaví parametre počasia pre vybraný model hory tak, že si vyberie typ počasia
a zvolí pravdepodobnosť jeho výskytu a jeho stálosť, resp. pravdepodobnosť jeho zmeny.
FUNKCIA #5: Inicializácia simulácie.
Inicializácia simulácie v sebe zahŕňa výber cieľa expedície, členov expedície, výber materiálu
a spustenie expedície.
26
FUNKCIA #6: Výber cieľa expedície
Výber cieľa expedície znamená, že užívateľ si z dostupných modelov hôr zvolí konkrétnu horu, na
ktorej bude prebiehať simulácia. Pri výbere sa budú zobrazovať jednotlivé modely aj s informáciami
o nich, ako napr. predpoveď počasia, trasy výstupu a podobne.
FUNKCIA #7: Výber členov expedície.
Užívateľ si zvolí zloženie expedičného tímu tak, že si do tímu postupne vyberie konkrétnych členov
z dostupnej množiny horolezcov. Pri výbere sa budú zobrazovať charakteristické vlastnosti alebo aj
ďalšie informácie o jednotlivých horolezcoch. Užívateľ bude mať možnosť pridať do tímu aj člena,
ktorého si sám vytvorí.
FUNKCIA #8: Vytvorenie nového člena expedície.
Užívateľ si vytvorí člena expedície tak, že pre danú množinu parametrov – charakteristických
vlastností horolezca (sila, výdrž, ...) zvolí kvalitu týchto parametrov. Kvalita bude nadobúdať hodnoty
od 1 po 10, pričom 1 znamená, že horolezec má danú vlastnosť na najhoršej úrovni a 10 znamená, že
horolezec má danú vlastnosť na najlepšej úrovni.
FUNKCIA #9: Pridelenie materiálu pre expedíciu
Po tom, čo systém vypočíta odhadované množstvo materiálu a to hlavne jedla, kyslíkových
a plynových bômb, si užívateľ vyberie konkrétne druhy a počty materiálu. Tento sa na začiatku
simulácie bude nachádzať v základnom tábore.
FUNKCIA #10: Vytvorenie objektu výbavy.
Nový objekt výbavy sa vytvorí tak, že sa zvolí názov objektu, kategória výbavy (jedlo, vystroj, ...),
parametre, ktoré ovplyvňuje (napr. energia, teplota), spôsob a intenzita, akou parameter ovplyvňuje
(napr. zvyšuje teplotu o 5 stupňov).
FUNKCIA #11: Výber kroku simulácie.
Výber kroku simulácie možno vykonať iba pre tých členov expedície, ktorý dokončili predchádzajúci
krok simulácie. Keďže jednotlivé kroky môžu trvať rôzny čas, nie všetkým horolezcom možno
v danom čase zvoliť ďalší krok. Pri výbere ďalšieho kroku simulácie sa zvolí voľný (taký, čo dokončil
predchádzajúcu úlohu) horolezec alebo skupinka horolezcov. Potom sa vyberie zo zoznamu možných
úloh požadovaná úloha a zadajú sa dodatočné voliteľné informácie (ak treba napr. pri lezení zadať cieľ
lezenia).
27
FUNKCIA #12: Zobrazenie aktuálneho stavu simulácie.
Aktuálny stav sa bude zobrazovať užívateľovi prostredníctvom grafického rozhrania, kde bude
zobrazený grafický model hory a polohy jednotlivých dynamických objektov (horolezci, tábory,
lavíny, ...). Užívateľ bude mať možnosť zvoliť si zobrazenie informácii pre väčšinu objektov, napr.
prechodom myši na horolezca sa zobrazia jeho vlastnosti, kliknutím naň sa môže spustiť ilustračné
video(napr. ako šplhá), kliknutím na lavínu sa zobrazia údaje o jej rozsahu a pod.
2.2 Vlastnosti produktu Atraktívnosť používateľského rozhrania – používateľské rozhranie musí byť dostatočne
atraktívne, aby zaujalo používateľov. Zároveň však musí byť prehľadné, pretože v simulácii
bude treba nastavovať množstvo volieb a parametrov. Toto možno zabezpečiť kombináciou
Windows ovládacích prvkov s GUI.
Zrozumiteľnosť používateľského rozhrania – používateľské rozhranie musí byť nielen
atraktívne a prehľadné, ale predovšetkým zrozumiteľné, pretože systém môžu používať
užívatelia s rôznymi skúsenosťami s prácou s počítačom. Preto by rozhranie malo obsahovať
rôzne pomocné prvky. Ovládacie prvky musia byť zvládnuteľné aj pre málo skúsených
používateľov, avšak zároveň nesmú iritovať skúsenejších používateľov. Preto by mali byť
k dispozícii rôzne alternatívy ovládacích prvkov (tlačidlá – menu – klávesové skratky).
Možnosť uloženia údajov – v systéme bude zakomponovaná, okrem ukladania parametrov
simulácie, aj možnosť uložiť a opätovne načítať už prebiehajúcu simuláciu. Takto bude možné
v kritickom okamihu simuláciu uložiť a vyskúšať viacero rozličných možností výberu
ďalšieho kroku.
Editovateľnosť konfiguračných údajov – údaje budú uložené v textovej forme
v prehľadných štruktúrach, aby sa zabezpečila možnosť jednoduchej editácie údajov aj mimo
programu.
Rozšíriteľnosť systému – keďže je predpoklad, že systém bude ďalej rozvíjaný, treba
zabezpečiť jeho rozšíriteľnosť. Toto dosiahneme pomocou vhodnej objektovo – orientovanej
dekompozície systému bez „prehnane“ zložitých súčiastok.
Objektovo – orientovaná dekompozícia – pre jednoduchšie zabezpečenie splnenia ďalších
požiadaviek bude systém dekomponovaný na základe objektovo – orientovaného prístupu.
Takáto dekompozícia sa zakladá na prirodzenom rozdelení systému do tried a lepšie odráža
problémovú oblasť, čo uľahčí tvorbu modelov nielen používateľského rozhrania. Pri tomto
prístupe je systém stabilnejší (v zmysle zmeny jeho komponentov), ako aj náklady na jeho
tvorbu sú redukované (v našom prípade predovšetkým čas).
Modularita – systém bude rozdelený na diskrétne časti(v tomto prípade triedy) tak, že každú
možno implementovať relatívne samostatne.
28
Voľná zviazanosť tried – triedy budú na sebe viac menej nezávislé, zmena jednej neovplyvní
zmenu ďalších. Podrobnosti reprezentácie a spracovania údajov budú skryté v danej triede,
komunikácia s ostatnými časťami systému (triedami) bude zabezpečená prostredníctvom
dobre definovaných rozhraní.
Veľká súdržnosť tried – triedy budú vytvárané tak, aby reprezentovali iba navzájom späté
údaje a zabezpečovali vybraný typ funkcionality (simulácia, užívateľské rozhranie, ...).
Znovupoužiteľnosť tried – ak má byť systém v budúcnosti ľahko rozšíriteľný resp.
modifikovateľný, treba zabezpečiť čo najväčšiu znovupoužiteľnosť tried. Toto dosiahneme
objektovo – orientovanými nástrojmi ako dedenie a polymorfizmus.
Robustnosť systému – pretože systém budú používať užívatelia s rôznymi skúsenosťami
s prácou s počítačom resp. neznalí vlastností systému, systém musí byť dostatočne robustný,
aby pri zle zadaných vstupoch nezlyhal. Toto možno zabezpečiť ohraničením možností
zadávania vstupov, ako aj kontrolou vstupov a upozorňovaním na chybné zadávanie vstupov.
Dokumentovateľnosť – systém musí obsahovať aktuálnu, zrozumiteľnú dokumentáciu
konzistentnú s implementáciou, konzistentné mená súčiastok. Toto je dôležité hlavne kvôli
požiadavke rozšíriteľnosti systému.
29
2.3 Diagram prípadov použitia systému
obr. 5 Diagram prípadov použitia systému
30
2.4 HráčiV nasledujúcom texte sú bližšie popísaní hráči zobrazení v diagrame prípadov použitia.
Hráč – Jedná sa o hráča, respektíve používateľa simulácie. Hráč si na začiatku vyberie cieľ
svojej expedície, členov expedície, ako aj materiál, ktorý priradí jednotlivým členom tímu.
Počas simulácie volí kroky expedície a môže si prezerať rozličné informácie o jej priebehu.
Tvorca modelu – Ide o používateľa tvoriaceho model hory. Má na starosti vytvorenie
grafického modelu hory, zadefinovanie jednotlivých bodov na hore a ich spojníc. Okrem toho
pre vytváranú horu aj definuje parametre počasia.
Horolezec – Agent predstavujúci horolezca. Jeho hlavnou časťou sú stavový stroj, ktorý
popisuje stavy reálneho človeka a atribúty vzťahujúce sa na jeho horolezecké schopnosti.
Horolezec môže prejsť do iného stavu v závislosti od vonkajšieho prostredia a rozhodnutia
hráča. Okrem toho je agent schopný meniť svoju polohu v simulovanom prostredí. Každý
horolezec má svoj batoh (inventár).
2.5 Prípady použitiaNa nasledujúcich stranách sú bližšie popísané prípady použitiam ktoré sú zobrazené v diagrame
prípadov použitia. Pre popis niektorých diagramov je použitý aj diagram aktivít.
(UC01) Inicializácia simulácie- Inicializáciu simulácie popisuje diagram na obr. 6.
Používateľ si najprv zvolí zo zoznamu cieľ expedície (UC02 výber cieľa expedície). Čiže si
vyberie horu, ktorá predstavuje konkrétnu expedíciu. Systém potom zobrazí predpoveď
počasia pre vybranú expedíciu. Používateľ si zo zoznamu existujúcich horolezcov zvolí svoj
tím pre expedíciu (UC03 výber členov expedície) a priradí im materiál (výbavu) (UC04
výber materiálu), ktorého množstvo (resp. odporúčanie množstva) systém vypočíta.
31
obr. 6. Diagram aktivít Inicializácia simulácie
(UC02) výber cieľa expedície – Zo zoznamu expedícií si hráč vyberie jednu, ktorú chce
simulovať.
(UC03) výber členov expedície – Zo zoznamu existujúcich horolezcov si užívateľ vytvorí
tím pre expedíciu. Pri rozhodovaní, ktorého horolezca príjme do tímu, sa riadi jeho
parametrami.
(UC04) výber materiálu – Hráč zvolí materiál pre expedíciu a pridelí ho jednotlivým
horolezcom. Pri tomto úkone mu pomáha systém tým, že mu vypočíta odhad potrebného
množstva materiálu. Nepridelený materiál ostane v tábore, pokiaľ ho niekomu nepridelí pri
výbere kroku simulácie (UC06 výber kroku simulácie).
(UC05) preskúmanie aktuálneho stavu simulácie – Hráč počas priebehu simulácie
môže preskúmať aktuálny stav simulácie. Môže si prezrieť predpoveď počasia, ako aj aktuálne
stavy jednotlivých horolezcov a parametre miest na hore.
(UC06) výber kroku simulácie – Počas simulácie si hráč vyberá ďalší krok simulácie.
Tento proces je zobrazený diagramom na obr. 7. Systém najprv zobrazí zoznam voľných
32
horolezcov. Horolezec sa pokladá za voľného vtedy, keď ukončil predchádzajúcu zadanú
úlohu. Užívateľ si z tohoto zoznamu vyberie jedného, alebo viacerých horolezcov (musia byť
na rovnakom mieste), ktorým bude pridelená úloha. Pri výbere horolezcov im hráč v prípade,
že sa nachádzajú v tábore pridelí materiál, ktorý si so sebou zoberú. Materiál samozrejme
musí byť v tábore, v ktorom sa horolezci nachádzajú. Systém podľa vybraných horolezcov a
materiálu zobrazí zoznam úloh, ktoré môžu vykonávať všetci vybraní horolezci. Z tohoto
zoznamu si používateľ vyberie jednu úlohu a miesto (aj cestu) pre jej vykonanie v prípade, že
to typ úlohy vyžaduje. Používateľ zadá dobu trvania úlohy ak to vyžaduje jej typ. Tento
cyklus pokračuje pokiaľ nemajú všetci horolezci určenú úlohu, pričom je možné prideliť aj
prázdnu úlohu (vyčkávanie).
33
obr. 7. Diagram aktivít Výber kroku simulácie
34
(UC06) vytvorenie objektu výbavy – Používateľ vytvorí nový objekt výbavy zadaním jeho
parametrov.
(UC08) vytvorenie nového člena expedície – Používateľ vytvorí nového horolezca zadaním
jeho parametrov.
(UC09) vytvorenie modelu hory – Tento prípad použitia zobrazuje diagram na obr. 8. Jedná
sa o vytvorenie hory a trasy expedície. Čiže neorientovaného grafu s jedným počiatočným
a konečným bodom a určitým počtom kontrolných bodov ako aj spojníc (hrán grafu) týchto
bodov. Prvým krokom je import grafického modelu hory do systému (UC15 vytvorenie
grafického modelu hory). Potom tvorca určí počiatočný (UC10 definovanie počiatočného
bodu expedície), konečný (UC11 definovanie cieľového bodu expedície) a všetky kontrolné
body (UC12 definovanie kontrolných bodov). Jednotlivé body potom pospája tak, aby bol
každý prístupný zo začiatočného bodu expedície a spojniciam zadá ich parametre (UC13
definovanie spojníc bodov). Na záver tvorca modelu zadefinuje počasie (UC14 definovanie
predpovede počasia) a podmienky prehry (UC18 definovanie podmienok prehry).
35
obr. 8. Diagram aktivít Vytvorenie modelu hory
(UC10) definovanie počiatočného bodu expedície – Viď UC09.
(UC11) definovanie cieľového bodu expedície – Viď UC09.
(UC12) definovanie kontrolných bodov – Viď UC09. Kontrolné body predstavujú miesta na
hore, ktoré je možné zadať pri výbere kroku simulácie. Jednotlivé miesta sú pospájané
spojnicami. Pri dosiahnutí určeného kontrolného bodu niektorým horolezcom (a teda pri
ukončení úlohy) sa simulácia preruší a umožní zadať novú úlohu. Každý kontrolný bod má,
okrem iných parametrov, určené aj či sa dá na jeho mieste postaviť tábor.
36
(UC13) definovanie spojníc bodov – Viď UC09. Jednotlivým spojniciam zadá tvorca modelu
parametre, pričom tieto spojnice môže rozdeliť na podúseky a tak zadať jednej spojnici viac
hodnôt rovnakého parametru.
(UC14) definovanie predpovede počasia – Tvorca modelu zadefinuje pre horu počasie. Pre
jednotlivé typy počasí určí pravdepodobnosti ich výskytu a rozsah doby trvania. Pre jednotlivé
parametre určí aj ich informačný rozptyl, aby sa zabezpečila určitá dezinformácia hráča.
(UC15) vytvorenie grafického modelu hory – Viď UC09. Pre vytvorenie grafického
modelu hory je možné importovať do systému mapu výšok (UC16 import mapy výšok),
alebo grafický model vytvorený v externom kresliacom nástroji (UC17 import 3D modelu).
(UC16) import mapy výšok – Viď UC15. Tvorca modelu zadá cestu k vytvorenej mape
výšok a k jej textúre.
(UC17) import 3D modelu – Viď UC15. Tvorca modelu zadá cestu k vytvorenému 3D
modelu hory.
(UC18) definovanie podmienok prehry – Tvorca modelu si vyberie podmienky, ktoré vedú
k prehre. Napríklad stanový maximálny čas pre expedíciu.
(UC19) prechod do iného stavu – Horolezec môže prejsť do iného stavu v závislosti od
vonkajšieho prostredia a rozhodnutia hráča. Jednotlivé stavy predstavujú stavy reálneho
človeka.
(UC20) zmena pozície – Horolezec môže počas vykonávania zadanej úlohy zmeniť svoju
pozíciu na modeli hory.
37
3 Návrh systémuTáto časť dokumentácie obsahuje návrh závislosti energie horolezca od rôznych faktorov, návrh
atribútov výbavy a výstroja ako aj spôsob uloženia týchto údajov. Ďalej je tu opísaný diagram tried
navrhovaného systému ako aj základná časť systému – simulačný proces horolezeckej expedície.
3.1 Výpočet energie horolezcaEnergiu horolezca determinujú všetky nižšie definované faktory:
Vlastnosti horolezca
Prostredie v ktorom sa horolezec nachádza
Inventár a jeho použitie.
Vytvoril sa graf, ktorý je možno vidieť na obr. 9, v ktorom je možno pozorovať od čoho závisí
energia. Graf vznikol prepojením relevantných faktorov prostredia, vlastnosti a inventáru. Po
spoločnej konzultácií sa odobrali niektoré nerelevantné faktory a vytvorili sa väzby medzi nimi. Dôraz
sa kládol na jednoduchosť a na čo najväčšie zobrazenie reality.
V grafe sú červenou farbou označené väzby medzi faktormi, ktoré sa ovplyvňujú nepriamou
úmerou a čiernou sú označené väzby medzi faktormi, ktoré sa ovplyvňujú priamou úmerou.
Prerušovanou čiarou sú označené bipolárne väzby, ktoré determinujú len možnosť alebo nemožnosť
určitej činnosti.
Inventár (v obr. 9 označený žltou farbou)
Inventár v spodnej časti grafu ovplyvňuje len prostredie. Je to taký typ inventáru, ktorý slúži na
ochranu proti zlým vplyvom prostredia. Inventár v hornej časti grafu sa rozdeľuje do dvoch skupín,
ktoré sa rozlišujú odtieňom žltej farby. Tmavšia určuje hmotnosť, ktorá negatívne vplýva na
výkonnosť. Ostatné zložky inventáru vplývajú buď priamo na energiu alebo pomocou stavov
v ktorých sa horolezec nachádza. Sú to tie časti inventáru, ktoré uspokojujú fyzické potreby horolezca.
Prostredie (v obr. 9 označené modrou farbou)
Prostredie je ovplyvňované inventárom, ktorý zmenšuje vplyvy prostredia na vlastnosti horolezca.
Prostredie vplýva na všetky vlastnosti horolezca. Priamo na stav (zdravie) vplýva jedine nadmorská
výška ktorá vlastne zväčšuje pravdepodobnosť ochorenia zo stúpajúcou výškou.
Vlastnosti horolezca (v obr. 9 označené pomarančovou farbou)
Z vlastností horolezca oproti pôvodnému návrhu ostali len základné vlastnosti. Dôvodom bolo
zjednodušenie celkovej schémy a možnosť spojenia niektorých vlastnosti do jednej kategórie (napr.
38
technika obsahuje aj balansovanie). Najdôležitejšou vlastnosťou je výkonnosť, ktoré určuje rýchlosť
spotreby energie.
Stavy horolezca (v obr. 9 označené fialovou farbou)
Stavy horolezca určujú jeho fyzické stavy. Spanie priamo vplýva na energiu a spolu s jedlom dopĺňa
energiu. Zdravie a zranenie určujú percentuálne zdravotný stav horolezca a sú to jediné atribúty, ktoré
ovplyvňujú aj sami seba.
obr. 9. Závislosť energie od vlastnosti horolezca, prostredia a inventáru
Vzorec pre výpočet energie horolezca v novom stave simulácie
(1)
(2)
39
(3)
Kde:
ZDRAVIE: hodnota od 0 (smrť) až do 1.05 (0.05 krátkodobé výkonnostné prostriedky ako
napr. adrenalín a pod.), klesať bude exponenciálne.
ZRANENIE: hodnota od 0 až do 1
INV_*: vplyv inventáru na konkrétnu vlastnosť horolezca alebo prostredia, hodnota od 0 až
do 1
ENERGIA_SPANKU: množstvo energie, ktorá pribudne za jednotku času počas spánku
CAS: čas medzi dvoma stavmi simulácie
SPOTREBA: determinuje spotrebu energie horolezca v danom okamihu
VYKONNOST: pôvodná výkonnosť horolezca, konštantne zadaná pre konkrétneho horolezca
TECHNIKA: vlastnosť horolezca, ktorý ovplyvňuje jeho výkonnosť, hodnota od 0 až do 1
NADM_VYSKA, TEREN, ZRAZKY, VIETOR, TEPLOTA, HMLA, DIF_SVETLO:
jednotlivé vplyvy prostredia, hodnota od 0 až do 1
T_ODDYCH: percento času, ktoré horolezec pri vykonávaní činnosti strávi oddychom,
hodnota od 0 až do 1, bude kvadraticky stúpať s nadmorskou výškou
ENERGIA_ODDYCH: množstvo energie, ktoré bude konštantne pribúdať, ak horolezec
nebude vykonávať žiadnu činnosť (len veľmi malá hodnota, napr. 0,01)
3.2 Návrh atribútov výbavy a výstrojaVýstroj bude vplývať na energiu, vlastnosti horolezcov a niektoré zložky počasia. To je možné vidieť
aj v diagrame (obr. 9). Preto bude predmet výstroja implementovaný triedou, ktorá bude obsahovať
všetky potrebné atribúty.
Predmet výstroja musí obsahovať minimálne nasledovné atribúty:
Meno – meno predmetu, pod ktorým bude predmet v hre viditeľný
Hmotnosť – hmotnosť predmetu v kilogramoch
Energia – vplyv predmetu na energiu horolezca (týka sa to jedla)
Zdravie – vplyv predmetu na zdravie horolezca (pre lieky, kyslík,...)
Spanie – vplyv predmetu na kvalitu spania (pre stan, spací vak, karimatku)
Terén – vplyv predmetu na náročnosť terénu
Zrážky – vplyv predmetu na účinky dažďa a snehu
Vietor – vplyv predmetu na účinky vetra
Teplota – vplyv predmetu na účinky chladu a mrazu
Hmla – vplyv predmetu na účinky nadmorskej výšky
40
Nadmorská výška – vplyv predmetu na účinky nadmorskej výšky
Počet použití – maximálny počet použití pre jednotku predmetu
Výdrž – kapacita, ktorú má jednotka predmetu (napr. plynová alebo kyslíková bomba)
Hodnoty pre účinky výstroja budú z intervalu <0;1>. Okrem nich bude ešte obsahovať meno
súboru, kde bude uložený obrázok daného predmetu, prípadne ďalšie pomocné atribúty.
3.3 Spôsob uloženia údajov o výstroji a manipulácia s týmito údajmi
3.3.1 Spôsob uloženia
Všetky údaje, ktoré budú popisovať výstroj a výbavu, budú uložené v XML súbore. Takto bude
zachovaná ich logická štruktúra a navyše ich bude možné veľmi jednoducho modifikovať.
Štruktúra súboru bude popísaná pomocou nasledovného DTD:
<!ELEMENT inventory (item)><!ELEMENT item (name,picture,weight,influence,usecount,capacity)><!ELEMENT name (#PCDATA)><!ELEMENT picture (#PCDATA)><!ELEMENT weight (#PCDATA)><!ELEMENT influence (stamina,health,sleep,terrain,wind,temperature,precipitation,fog,altitude)><!ELEMENT usecount (#PCDATA)><!ELEMENT capacity (#PCDATA)><!ELEMENT stamina (#PCDATA)><!ELEMENT health (#PCDATA)><!ELEMENT sleep (#PCDATA)><!ELEMENT terrain (#PCDATA)><!ELEMENT wind (#PCDATA)><!ELEMENT temperature (#PCDATA)><!ELEMENT precipitation (#PCDATA)><!ELEMENT fog (#PCDATA)><!ELEMENT altitude (#PCDATA)>
Takto bude presne definovaná štruktúra XML dokumentu, navyše priamo pri použití v programe bude
automaticky vykonávaná validácia vstupných údajov voči zvolenému DTD. Príklad vstupného XML
dokumentu je možné vidieť tu:
41
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE inventory SYSTEM "horex_inventory.dtd"><inventory>
<item><name>Stan</name><picture>tent01.jpg</picture><weight>10</weight><influence>
<stamina>NA</stamina><health>1.05</health><sleep>2.5</sleep><terrain>NA</terrain><wind>0.05</wind><temperature>0.2</temperature><precipitation>NA</precipitation><fog>NA</fog><altitude>NA</altitude>
</influence><usecount>INFINITE</usecount><capacity>2</capacity>
</item></inventory>
3.3.2 Zobrazovanie
Ako už bolo spomenuté, je veľmi jednoduché modifikovať údaje (stačí na to ľubovoľný textový
editor). Okrem toho však môžeme zobraziť dané údaje pomocou XSL transformácie. Tú budeme
používať na zobrazenie údajov o konkrétnom predmete v GUI hry. Transformáciu budeme definovať
ako zobrazenie na HTML stránku, ktorú potom zobrazíme v jednom okne aplikácie. Takto vyzerá
transformácia pre celý dokument (my z nej budeme používať vždy iba časť, ktorá zobrazí jeden
predmet výstroja):
42
<?xml version="1.0" encoding="UTF-8"?><xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <HTML> <BODY> <xsl:apply-templates select="inventory/item"/> </BODY> </HTML> </xsl:template> <xsl:template match="item"> <h2><xsl:value-of select="name"/></h2> <table> <tr> <td> <p>Hmotnosť: <xsl:value-of select="weight"/> kg</p> <h3>Účinky:</h3> <ul> <li>Energia: <xsl:value-of select="influence/stamina"/></li> <li>Zdravie: <xsl:value-of select="influence/health"/></li> <li>Spanie: <xsl:value-of select="influence/sleep"/></li> <li>Terén: <xsl:value-of select="influence/terrain"/></li> <li>Vietor: <xsl:value-of select="influence/wind"/></li> <li>Teplota: <xsl:value-of select="influence/temperature"/></li> <li>Zrážky: <xsl:value-of select="influence/precipittion"/></li> <li>Hmla: <xsl:value-of select="influence/fog"/></li> <li>Nadm. výška: <xsl:value-of select="influence/altitude"/></li> </ul> <p>Výdrž: <xsl:value-of select="capacity"/></p> </td> <td> <img src="{picture}"/> </td> </tr> </table> </xsl:template></xsl:transform>
3.3.3 Manipulácia
Údaje budeme načítavať pomocou knižnice MSXML 6.0. Tá umožňuje prístup k údajom pomocou
DOM aj SAX. Rozhodli sme sa použiť DOM reprezentáciu údajov.
Dôvodom je to, že celý súbor sa načíta naraz a potom je prístup k jednotlivým jeho častiam
okamžitý, pretože jednotlivé elementy sú uložené v objektových štruktúrach v pamäti. Použitie DOM
taktiež umožňuje širšie možnosti validácie a kontroly vstupných údajov.
Keďže všetky údaje sa načítajú a uložia do pamäti naraz, DOM má vyššie pamäťové nároky než
SAX. Vzhľadom na povahu produktu sa ale nepredpokladá veľké množstvo vstupných údajov, preto
tento nedostatok môžeme ignorovať.
43
3.4 Diagram tried systémuNa obr. 10 je znázornený diagram tried systému. Jednotlivé triedy sú popísané nižšie.
obr. 10 Diagram tried systému
csimulation
Predstavuje simulačné jadro systému a teda je aj jeho ústredný bod. Zodpovedá za priebeh simulácie,
pre ktorý využíva ostatné triedy.
44
cmonitor
Slúži na zobrazovanie simulácie. Informácie o všetkých objektoch simulácie získava z triedy
csimulation.
ccontroler
Jeho prostredníctvom môže používateľ systému nastavovať jednotlivé parametre simulácie.
cmountain
Je to samotný vrch, ktorý sa skladá z množiny bodov (cpoint), spojníc (cjoin) týchto bodov
a jednotlivých počasí (cweather).
cweather
Jedná sa o jeden typ (stav) počasia. Atribúty tejto triedy popisujú vlastnosti počasia ako sú napríklad
pravdepodobnosť jeho výskytu, alebo rozsah doby jeho trvania.
cmountainlocation
Predstavuje pozíciu na vrchu. Obsahuje zoznam entít (centity), ktoré sa na ňom nachádzajú. V systéme
môžu byť pozície buď bod (cpoint), alebo spojnica (cjoin).
cpointTrieda je odvodená z cmountainlocation. Predstavuje jeden bod vrchu a môže mať nasledovné typy:
cstartpoint – Počiatočný bod.
cgoalpoint – Cieľový bod.
ccontrolpoint – Bod v strede vrchu. Má určené, či sa na ňom môže nachádzať tábor a má
definovaný terén (cterain).
cjoinTrieda je odvodená z cmountainlocation. Slúži na spojenie jednotlivých bodov vrchu (cpoint). Jedna
spojnica môže mať viacero úsekov (cjoinsegment), ktoré sú definované svojím terénom (cterain).
cjoinsegment
Úsek spojnice (cjoin). Má definovaný svoj terén a dĺžku.
cterain
Definuje parametre terénu jednotlivých kontrolných bodov (ccontrolpoint) a spojníc (cjoin).
centity
Entitami v systém môžu byť horolezci (cmountaineer), ale aj tábory (ccamp). Každá entita má svoju
pozíciu na vrchu (cmountainlocation) a svoj inventár (cinventory).
45
cmountaineerJe to entita predstavujúca horolezca. Má parametre, ktoré charakterizujú jeho horolezecké schopnosti
a stavový stroj (cstate, cedge), ktorého stavy reprezentujú stavy reálneho človeka.
ccampEntita predstavujúca tábor. Aj tábor, ako entita, vlastní svoj inventár.
cinventory
Trieda predstavuje inventár, ktorý obsahuje objekty horolezeckej výbavy (coutfitobject).
ctask
Úloha, ktorú má zadanú jeden, alebo viacero horolezcov. Úloha zväzuje horolezcov a vytvára tak
skupinu. Má určenú cestu z jednotlivých spojníc (cjoin) a bod (cpoint), cez ktorý posledne prešla
skupina horolezcov, ktorá plní túto úlohu. Tento bod je potrebný pre možnosť vrátenia sa
k poslednému bodu v prípade neočakávanej situácie.
46
3.5 Návrh procesu simulácie
obr. 11 Diagram aktivít Proces simulácie
47
Proces simulácie je zobrazený diagramom aktivít na Error: Reference source not found. Používateľ si
najprv zvolí krok simulácie (viď. UC06 v kapitole Špecifikácia požiadaviek na systém). Systém
vypočíta nový stav, ktorý nastáva v nasledujúcich prípadoch:
1. Horolezec prejde na iný úsek spojnice- zmenil sa terén
2. Horolezec splní svoju úlohu
3. Zmení sa počasie
4. zmení sa denná doba
5. Zmení sa stav horolezca- napríklad ak ochorie, ale nie keď sa napríklad zmení hodnota jeho
energie
Po vypočítaní nového stavu systém určí o aký stav sa jedná. Stavy môžu mať nasledovné typy:
1) Vyžaduje zásah užívateľa
a) Ukončila sa úloha a teda je potrebné aby užívateľ zadal novú úlohu príslušnému
horolezcovi, resp. skupine horolezcov (prípad č.2). Pri tomto type stavu s kontroluje aj či
nebol dosiahnutý cieľ expedície.
b) Nastal neočakávaný stav a je potrebné aby ho užívateľ vyriešil (prípad č.3 a 5). Pod
riešením sa myslí rozhodnutie, či má horolezec pokračovať vo svojej úlohe, alebo ju má
prerušiť a vrátiť sa do predchádzajúceho kontrolného bodu. Kontroluje sa aj či
neočakávaný stav nepredstavuje neúspech expedície.
2) Nevyžaduje zásah užívateľa (prípad č.1 a 4)- Iba sa zahrnú do výpočtu nové hodnoty.
48
4 Revízia špecifikácie požiadaviek na systém
Táto kapitola obsahuje revíziu špecifikácie systému. Sú tu uvedené diagramy, ktoré boli
zmenené a popísané pridané prípady použitia. Na nasledujúcom obrázku je uvedený diagram prípadov
použitia, do ktorého boli pridané prípady použitia (UC21) uloženie simulácie a (UC22) načítanie
uloženej simulácie. Taktiež boli zmenené stereotypy <<uses>> na <<include>>.
obr. 12 Diagram prípadov použitia systému
49
4.1.1 Pridané a zmenené prípady použitia
(UC01) Inicializácia simulácie- V diagrame na obr. 6 je uvedený aktualizovaný
diagram aktivít pre tento prípad použitia. Bolo pridané potvrdenie cieľa expedície
a výpis predpovede počasia bol zmenený na výpis informácií o expedícií.
obr. 13 diagram aktivít Inicializácia simulácie
(UC06) výber kroku simulácie- V tomto prípade použitia bol iba prekreslený
diagram aktivít (obr. 7), aby vyhovoval UML 2.0.
50
obr. 14 Diagram aktivít Výber kroku simulácie
51
(UC09) vytvorenie modelu hory- V tomto prípade použitia bol iba prekreslený
diagram aktivít (), aby vyhovoval UML 2.0.
obr. 15 Diagram aktivít vytvorenie modelu hory
(UC21) uloženie simulácie – V prípade, že chce hráč pokračovať v spustenej simulácií
neskôr, umožní mu systém uložiť aktuálny stav simulácie do súboru.
(UC22) načítanie uloženej simulácie – Tento prípad použitia nastáva vtedy, keď chce
hráč pokračovať v uloženej simulácií. Simulácia sa načíta a hráč môže pokračovať
v simulácií od toho kroku, v ktorom ju uložil.
52
5 Podrobný návrh
5.1 Návrh systému
5.1.1 Diagram tried systémuNa nasledujúcom obrázku je znázornený diagram tried celého systému na logickej úrovni a tiež
asociácie medzi všetkými triedami, ktoré súvisia so simulačnou logikou. Je tu opísaná trieda
CSimulation. Jednotlivé časti diagramu, triedy a ich vzájomné vzťahy sú opísané v ďalších kapitolách.
CSimulation
Trieda implementujúca celkový mechanizmus simulácie a poskytujúca sprístupnenie jednotlivých
podsystémov systému.
Táto trieda bude uchovávať aj rozvrh a tak ho sprístupňovať ostatným jej súčastiam.
Ďalej bude sprístupňovať objekt hory (inštancia triedy CMountain) a odkazy na počiatočný
a cieľový bod expedície.
Atribúty
Protected:
float last_recalculation_time – čas posledného spustenia metódy Recalculate.
static HANDLE sim_thread_handle – identifikátor (handle) simulačného vlákna.
static DWORD sim_thread_id – identifikátor (id) simulačného vlákna.
static CSchedule schedule – rozvrh udalostí.
static bool simulating – či sa práve vykonáva simulačný cyklus.
CGroupManager group_manager – manažér skupín.
CWeatherManager weather_manager – manažér počasia.
CMountain* mountain – smerník na objekt hory.
MOUNTAINEER_LIST mountaineers – zoznam horolezcov.
CControlPoint* start_point – smerník na počiatočný bod expedície.
CControlPoint* end_point – smerník na cieľový bod expedície.
Metódy
Public:
static DWORD WINAPI SimulThreadProc(LPVOID param) – procedúra simulačného vlákna.
ExecuteSimulStep() – vykoná simulačný krok.
Recalculate() – prepočíta stav potrebných častí v simulácii.
InsertMountaineer(CMountaineer* mountaineer) – pridá horolezca do simulácie.
HANDLE GetSimThreadHandle() – vráti identifikátor (handle) simulačného vlákna.
DWORD GetSimThreadId() – vráti identifikátor (id) simulačného vlákna.
53
CSchedule& GetSchedule() – vráti referenciu na rozvrh.
CWeatherManager& GetWeatherManager() – vráti referenciu na manažéra počasia.
CGroupManager& GetGroupManager() – vráti referenciu na manažéra skupín horolezcov.
CMountain* GetMountain() – poskytnutie smerníka na objekt hory.
MOUNTAINEER_LIST& GetMountaineerList() – vráti referenciu na zoznam horolezcov.
CControlPoint* GetStartPoint() – poskytnutie smerníka na počiatočný bod expedície.
CControlPoint* GetEndPoint() – poskytnutie smerníka na cieľový bod expedície.
bool IsStartPoint(CControlPoint* test_point) – testuje, či je daný bod počiatočným
bodom expedície.
bool IsStartPoint(CControlPoint* test_point) – testuje, či je daný bod cieľovým bodom
expedície.
SetStartPoint(CControlPoint* point) – nastaví počiatočný bod expedície.
SetEndPoint(CControlPoint* point) – nastaví cieľový bod expedície.
54
obr. 16 Diagram tried systému
55
5.1.2 Diagram tried vstupno-výstupnej úrovne systémuNa nasledovnom obrázku je znázornený diagram tried vstupno-výstupnej úrovne systému, ktorý
opisuje vzťahy triedy CSimulation s triedami pre spracovanie vstupných súborov a s triedami
používateľského rozhrania.
obr. 17 Diagram tried Vstupno-výstupná úroveň systému
56
Uvedený diagram je navrhnutý podľa princípov návrhového vzoru Observer, ktorý definuje závislosť
objektov 1:n, kde ak jeden objekt zmení svoj stav, informuje o tom všetkých svojich pozorovateľov.
Títo sú automaticky aktualizovaní.
Hlavnými časťami tohto vzoru sú triedy Observer a Subject. Subject udržuje informáciu
o svojich pozorovateľoch a poskytuje rozhranie pre ich pridávanie a odoberanie. Observer definuje
aktualizačné rozhranie pre objekty, ktoré musia byť informované o zmenách v subjekte.
CWindowObserver
Abstraktná trieda observera, ktorý je tvorený dialógovým okno s ovládacími prvkami.
Atribúty
string name; – názov observera
Metódy
virtual void OnShow(); - metóda, ktorá sa vykoná pri zobrazení okna
virtual void OnHide(); - metóda, ktorá sa vykoná pri skrytí okna
CViewportObserver
Abstraktná trieda observera zobrazujúceho graficky reprezentáciu simulácie.
Atribúty
atribúty uchovávajúce informácie o manažéroch pre grafické vykresľovanie scény pomocou knižnice
OGRE
Metódy
metódy pre ošetrovanie používateľských vstupov – myš a klávesnica
CSoundObserver
Trieda observera, ktorý na základe stavu simulácie prehráva zvukové záznamy. Jedná sa
predovšetkým o spúšťanie zvukových efektov ako napr. vietor, hučanie lavíny a pod.
Atribúty
atribúty uchovávajúce informácie o prehrávačoch zvukových súborov a stavov prehrávania zvukových
stôp
Metódy
metódy pre vykonávanie operácií so zvukovými stopami
Ostatné triedy sú bližšie opísané v kapitole 5.6.
57
5.2 Návrh stavov simulácie
5.2.1 Účel návrhu stavovSimulácia horolezeckej výpravy sa počas svojho životného cyklu môže nachádzať v definovanej
množine základných stavov. Pri definícii množiny možno vychádzať z rôznych pohľadov na správanie
sa systému v jednotlivých stavov.
V tejto kapitole vychádzame z pohľadu interakcie používateľa s priebehom simulácie. Účelom
navrhnutej množiny stavov a ich vzájomných prechodov je poskytnúť objasnenie, aké informácie bude
mať používateľ k dispozícii v jednotlivých stavoch simulácie a ako mu bude umožnené v týchto
stavoch zadávať príkazy a údaje pre simuláciu.
Stavy simulácie sú uvedené v niekoľkých úrovniach abstrakcie. Jednotlivé stavy môžu mať
vlastné vnútorné stavy.
5.2.2 Stavový diagram Stavy simulácieDiagram uvedený na nasledujúcom obrázku opisuje základné stavy simulácie a prechody medzi nimi.
obr. 18 Stavový diagram Stavy simulácie
58
Inicializácia simulácie
V tomto stave sa alokujú všetky potrebné údajové štruktúry a inicializujú sa hodnotami načítanými
z externých súborov. V ďalšej fáze sa zobrazia obrazovky pre zadanie údajov a nastavení týkajúcich sa
nasledovného:
výber miesta horolezeckej expedície – hory
výber členov expedície – horolezcov
výber materiálu – jedlo a výstroj
Vykonávanie simulácie
Stavový diagram vykonávania simulácie je uvedený v ďalšej kapitole.
Vyhodnotenie simulácie
V tomto stave sa vyhodnotí priebeh simulácie. Vyhodnotí sa úspešnosť expedície – splnenie alebo
nesplnenie cieľa, prípadný dôvod zlyhania expedície a štatistické údaje o expedícii, ako napr. dĺžka
trvania, množstvo spotrebovaného jedla a pod. Ďalej možno sledovať záznamy o priebehu simulácie
prostredníctvom textového záznamu.
59
5.2.3 Stavový diagram Vykonávanie simulácieV nasledujúcom diagrame sú podrobnejšie opísané stavy a ich vzájomné prechody pri samotnom
vykonávaní simulácie horolezeckej výpravy.
obr. 19 Stavový diagram Vykonávanie simulácie
60
Simulácia je v interaktívnom stave
V tomto stave neprebieha samotný simulačný výpočet hodnôt entít vystupujúcich v simulácii, ale
simulácia je „pozastavená“. Používateľ má možnosť informovať sa o aktuálnom stave simulácie
zobrazovaním informácií o počasí, horolezcoch táboroch a pod.
Tento stav obsahuje vnútorné stavy zabezpečujúce naplánovanie ďalšieho simulačného kroku,
a to zadaním údajov používateľom: vytvorenie skupín s voľných horolezcov, to je takých, ktorí
nemajú v danom čase priradenú úlohu, priradenie materiálu horolezcom v skupine a priradenie úlohy
danej skupine horolezcov.
Vnútorné stavy stavu „Simulácia je v interaktívnom stave“ je vidno z predchádzajúceho
diagramu.
Vyberá sa lokácia
Tento stav nastáva po výbere ľubovoľnej lokácie – lokality na trojrozmernom modely hory, a to
kliknutím ľavého tlačidla myši na model. Následne po selekcii lokácie sa aktualizujú hodnoty
o aktuálnom výbere lokácie.
Ak sa v danej lokácii nenachádza žiadny voľný horolezec, zobrazia sa informácie o lokácii
a objektov na nej situovaných. V prípade prítomnosti voľného horolezca, t.j. horolezca bez úlohy,
prejde interaktívny stav do stavu „Vytváranie skupiny“.
V tomto stave je možné stále meniť zvolenú lokáciu a zobrazuje sa okno „Informácie o
lokácii“.
Vytváranie skupiny
V stave vytvárania skupiny je zobrazené okno „Vytvoriť skupinu“. Používateľ má možnosť zo
zoznamu voľných horolezcov presúvať ľubovoľných horolezcov do novovznikajúcej skupiny.
Ak používateľ v tomto stave označí myšou na modely hory inú lokáciu, prejde stav do stavu
„Vyberá sa lokácia“, ak sa na vybranej lokácii nenachádza žiadný voľný horolezec. Ak sa nachádza,
zostane v tomto stave, pričom sa však aktualizuje zoznam voľných horolezcov na danej lokácii
a predchádzajúci výber sa zruší.
Po potvrdení vytvorenia novej skupiny prejde stav do stavu „Prideľovanie materiálu“, ak sa
skupina nachádza na pozícii ľubovoľného tábora, v opačnom prípade prejde do stavu „Zadávanie
úlohy“.
Prideľovanie materiálu
61
V stave prideľovania materiálu je zobrazené okno „Prideliť materiál“. Z zoznamu dostupného
materiálu – jedla a výbavy – je možné presunúť materiál do inventárov jednotlivých horolezcov.
Takisto možno presúvať materiál opačným smerom.
Po potvrdení pridelenia materiálu prechádza stav do stavu „Zadávanie úlohy“. Takisto je
možné vrátiť sa do stavu „Vytváranie skupiny“ (vratné prechody nie sú v diagrame kvôli prehľadnosti
zakreslené).
Zadávanie úlohy
V tomto stave používateľ priradí skupinke úlohu, ktorú ma vykonať a to výberom zo zoznamu
možných úloh. Podľa typu úlohy nastaví dodatočné parametre.
Po potvrdení zadania úlohy prejde stav podľa charakteru úlohy do jedného zo stavov
„Zadávanie cesty“, „Zadávanie času“ alebo „Zobrazovanie naplánovanej úlohy“. Takisto je možné
vrátiť sa do predchádzajúceho stavu.
Počas trvania tohto stavu sa zobrazuje okno „Zadať úlohu“.
Zadávanie cesty
Zadávanie cesty je stav, kedy charakter vybranej úlohy vyžaduje od používateľa, aby vybral trasu, po
ktorej sa má skupinka presúvať.
V tomto stave sa zobrazí okno „Zadaná cesta“, v ktorom je zoznam úsekov aktuálne zvolenej
trasy. Používateľ pridáva do zoznamu nové úseky selektovaním lokácií, odstraňuje ich selekciou
v zozname.
Po potvrdení trasy prechádza stav do stavu „Zobrazenie naplánovanej úlohy“, taktiež je možné
vrátiť sa do stavu „Zadávanie úlohy“, a to zrušením zadanej cesty.
Zadávanie času
Zadávanie času je stav, kedy charakter vybranej úlohy vyžaduje od používateľa, aby zadal čas, po
ktorý ma skupinka danú úlohu plniť.
V tomto stave sa zobrazí okno „Zadať čas“ s ovládacím prvkom pre zadanie času v hodinách
reprezentovaného ako reálne číslo (takto je možné určiť čas aj v menších časových jednotkách).
Po zadaní času prechádza stav do stavu „Zobrazenie naplánovanej úlohy“, prípadne sa možno
vrátiť do stavu „Zadávanie úlohy“.
Zobrazovanie naplánovanej úlohy
V tomto stave sa zobrazia vybrané súhrnné informácie o práve naplánovanej úlohe.
Potvrdením údajov sa úloha naplánuje a prejde sa do ďalšieho stavu. Ak ešte existujú voľní
horolezci, prejde interaktívny stav do stavu „Vyberá sa lokácia“. Ak majú všetci horolezci pridelenú
62
úlohu, prejde sa do stavu „Pripravená simulácia“. Taktiež je možné sa vrátiť do predchádzajúceho
stavu.
Pripravená simulácia
Simulácia je pripravená, ak má každý horolezec pridelenú úlohu. V tomto stave je stále možné
prezerať si informácie o entitách vystupujúcich v simulácii. Zobrazuje sa okno „Informácie o lokácii“.
Po zadaní príkazu spustenia výpočtu prejde simulácia do stavu „Simulácia je vo výpočtovom
stave“.
Simulácia je vo výpočtovom stave
V tomto stave sa vykonávajú všetky naplánované úlohy, ale aj udalosti, ktoré neplánuje používateľ
(napr. zmena počasia, ochorenie horolezca, pád lavíny, atď.). Prepočítavajú sa hodnoty entít
vystupujúcich v simulácii a plánujú sa udalosti plánované automaticky (tie, ktoré neplánuje
používateľ).
V tomto stave sa môže zobrazovať „progress bar“, ktorý informuje o priebehu výpočtu.
Po skončení výpočtu sa simulácia môže ocitnúť v stave, ktorý spĺňa podmienky úspešného
alebo neúspešného ukončenia simulácie. Vtedy prejde Vykonávanie simulácie do koncového stavu.
Ináč prejde simulácia do ďalšieho simulačného cyklu a to zmenou stavu na stav „Simulácia je
v interaktívnom stave“.
63
5.3 Návrh zapisovača (Logger)
5.3.1 Účel zapisovačaZapisovač bude poskytovať metódy pre pohodlné a jednotné zapisovanie informácií do log
súboru.
Každá informácia bude mať svoj typ, pričom budú podporované nasledovný typy:
informácia
upozornenie
chyba
Zapisovač bude poskytovať spôsob pre nastavenie filtru typu správ, ktoré sa majú zapisovať
do log súboru.
64
5.3.2 Diagram tried Zapisovač
obr. 20 Diagram tried Zapisovač
CSingleton
Šablónová trieda implementujúca návrhový vzor singleton, ktorého charakteristikou je skutočnosť, že
môže existovať iba jedna jeho inštancia.
Metódy
GetInstance() – vráti inštanciu triedy danej typom v šablónovej triede.
CLogger
Zapisovač do súboru.
Atribúty
ofstream log - log súbor.
UINT message_type_mask - Určuje aké typy sprav sa majú zapisovať do súboru;
Metódy
void LogMessageType(MESSAGE_TYPE message_type) - zapíše do log súboru typ
správy.
void LogTime() - zapíše do log súboru aktuálny čas.
void LogMessage(const string& message,const string& message_source,
MESSAGE_TYPE message_type=MT_INF) - zapíše do log súboru správu.
void SetLogMessageTypes(UINT message_types) - nastaví typ sprav, ktoré sa majú
zapisovať log úboru.
65
5.4 Návrh rozvrhu
5.4.1 Účel rozvrhu a princíp jeho činnostiRozvrh je nevyhnutnou súčasťou diskrétnej simulácie. V podstate sa jedná o usporiadaný zoznam
udalostí, ktoré prislúchajú jednotlivým súčastiam simulácie.
Hlavnou úlohou rozvrhu bude možnosť pridávania nových udalostí a vykonávanie
simulačného kroku.
Pri vykonaní simulačného kroku sa vždy vyberú všetky udalosti, ktoré majú rovnaký čas
vykonania ako prvá (s najnižším časom) udalosť v rozvrhu. V rámci jedného času vykonania je nutné
aby boli udalosti zotriedené aj podľa priority, pretože bude potrebné zabezpečiť aby sa určité udalosti
v rámci rovnakého času vybrali v danom poradí.
Udalosť, ktorá sa vyberie z rozvrhu pri vykonávaní simulačného kroku sa hneď po jej vybratí
z rozvrhu vykoná.
Keďže sa môže niekedy stať, že práve vykonávaná udalosť ovplyvní už naplánované udalosti,
bude poskytovať rozvrh metódu pre preplánovanie existujúcich udalostí. Príklad takejto situácie môže
byť zmena počasia, ktorá zapríčiní, že sa všetky naplánované udalosti úloh horolezcov (kladenie
fixných lán a podobne) musia prepočítať k aktuálnemu času, pričom sa do výpočtov zahrnie staré
počasie. Každá z týchto udalostí sa potom preplánuje na nový začiatočný čas. Niekedy bude taktiež
nutné naplánované udalosti pri preplánovaní z rozvrhu odstrániť. Príkladom môže byť už spomínaná
zmena počasia, pri ktorej sa program pre každú úlohu horolezcov spýta či majú horolezci pokračovať
v úlohe, alebo sa vrátiť k poslednému kontrolnému bodu. Ak si užívateľ vyberie návrat a teda zrušenie
úlohy, musí sa pôvodná udalosť úlohy odstrániť a nahradiť sa novou.
66
5.4.2 Diagram tried RozvrhNa nasledujúcom obrázku je znázornený diagram tried rozvrhu, ktoré poskytujú funkcionalitu spojenú
s vytváraním, plánovaním a vykonávaním udalostí. Za diagramom nasleduje popis jednotlivých tried,
ich atribútov a metód.
obr. 21 Diagram tried Rozvrh
67
CSimulation
Trieda implementujúca celkový mechanizmus simulácie a poskytujúca sprístupnenie jednotlivých
podsystémov systému. Táto trieda bude uchovávať aj rozvrh a tak ho sprístupňovať ostatným jej
súčastiam.
Atribúty
CSchedule nschedule – rozvrh udalostí.
Metódy
GetSchedule() – vráti referenciu na rozvrh.
CShedule
Trieda implementujúca rozvrh naplánovaných udalostí. Vyvoláva vykonanie udalostí, ktoré sú uložené
v prioritnom rade podľa času výskytu a priority.
Atribúty
EVENTS_MAP events – usporiadaný zoznam udalostí v rozvrhu.
float sim_time – aktuálny simulačný čas (čas udalosti, ktoré sa posledne vykonali)
Metódy
bool IsEmpty() – vráti či je rozvrh prázdny.
float GetActualTime() - vráti aktuálny simulačný čas.
void InsertEvent(CEvent* new_event, float dtime, int prior) – pridá do
rozvrhu novú udalosť.
float ExecuteStep() - vykoná simulačný krok a vráti novy čas.
void Reschedule(void* owner) - preplánuje všetky udalosti prislúchajúce danému
vlastníkovi.
void DeleteEvents(void* owner) – zmaže všetky udalosti prislúchajúce danému
vlastníkovi.
CEvent
Trieda implementuje akúkoľvek naplánovanú udalosť. Odvádzajú sa z nej konkrétne udalosti, ktorým
sa prekoná metóda Execute() a poprípade Reschedule(float actual_time, int prior).
Atribúty
float birth_time – čas kedy vznikla udalosť (nastavuje ho CSchedule pri
naplánovaní udalosti).
float scheduled_time – čas na ktorý je udalosť naplánovaná (nastavuje ho CSchedule pri
naplánovaní udalosti).
68
void* owner – vlastník udalosti (napr. úloha je vlastníkom udalosti ukončenie úlohy).
Metódy
void SetBirthTime(float time) - nastaví čas kedy vznikla udalosť (resp. bola pridaná do
rozvrhu) (používa CSchedule).
void SetScheduledTime(float time) – nastaví čas na ktorý je udalosť naplánovaná
(používa CSchedule).
void Execute() – vykonanie udalosti. Túto metódu je potrebné prekonať.
bool Reschedule(float actual_time, int prior) – preplánovanie udalosti. Metódu
volá CSchedule pri preplánovavaní (Reschedule()). Ak vráti false, tak rozvrh
udalosť odstráni z rozvrhu. Táto metóda môže byť prekonaná. Ak sa
neprekoná, tak iba vráti true, čo znamená, že sa udalosť nemá zmazať
z rozvrhu.
float GetBirthTime() - vráti čas kedy vznikla udalosť (resp. bola pridaná do rozvrhu).
float GetScheduledTime() - vráti čas na ktorý je udalosť naplánovaná.
void* GetOwner() - vráti vlastníka udalosti.
CAuxEventContainer
Pomocná trieda uchovávajúca udalosť pri vykonávaní metódy Reschedule() rozvrhu CSchedule.
Atribúty
CEvent* event – udalosť.
float time - čas na ktorý je udalosť naplánovaná.
int prior - priorita udalosti.
69
5.5 Návrh modelu počasia
5.5.1 Parametre a stavy počasiaPočasie je definované svojimi parametrami, ktoré predstavujú rôzne poveternostné vplyvy. Vplyvy sú
nasledovné:
intenzita zrážok
hustota hmly
rýchlosť vetra
teplota
Vzhľadom na definované parametre môže nastať konečná množina stavov počasia. Zmena
počasia z jedného stavu do druhého je ohraničená vlastnosťami parametrov počasia. Stavy počasia
a možnosti jeho zmeny sú vyjadrené v stavovom diagrame na obr. 22.
Pozn.: Hodnoty parametrov zrážky, hmla a vietor sú len orientačné. Nula značí, že parameter
momentálne nevplýva na počasie (jeho hodnota je 0), jednotka značí, že parameter vplýva na počasie
(jeho hodnota je väčšia ako 0, max. hodnota je daná ohraničením parametru).
Počasie je ďalej definované parametrami, ktoré predstavujú dynamiku počasia –
pravdepodobnosť nastania počasia a jeho stálosť. Parametre sú:
pravdepodobnosť výskytu
minimálna doba výskytu
maximálna doba výskytu
Od týchto parametrov závisí, ktoré z daných typov resp. stavov počasia nastane pri zmene
počasia a ako dlho bude daný stav trvať, to znamená, za akú dobu sa počasie zase zmení.
70
obr. 22 Stavový diagram Stavy počasia
71
5.5.2 Diagram tried Model počasiaNa nasledovnom obrázku je znázornený diagram tried modelu počasia, ktorý zabezpečuje: načítanie a
uchovávanie informácií o možných stavoch počasia, uchovávanie aktuálneho stavu počasia, zmenu
aktuálneho počasia, zistenie dopadu počasia na energiu horolezca, ako aj možnosť naplánovať ďalšiu
zmenu počasia.
obr. 23 Diagram tried Model Počasia
72
CSimulation
Trieda implementujúca celkový mechanizmus simulácie a poskytujúca sprístupnenie jednotlivých
podsystémov systému.
Bližšie je popísaná v kapitole 5.1.1.
CShedule
Trieda implementujúca rozvrh naplánovaných udalostí. Vyvoláva vykonanie udalostí, ktoré sú uložené
v prioritnom rade podľa času výskytu.
Bližšie je popísaná v kapitole 5.4.2.
CEvent
Trieda implementuje akúkoľvek naplánovanú udalosť. Z pohľadu plánovania zmeny počasia je
zaujímavá iba jej čisto virtuálna metóda Execute().
Bližšie je popísaná v kapitole 5.4.2.
Metódy
Execute() – čisto virtuálna metóda pre vykonanie naplánovanej udalosti.
CWeatherChange
Trieda zdedená z CEvent. Implementuje udalosť zmeny počasia, ktorá sa vykoná vyvolaním
virtuálnej metódy Execute().
Metódy
Execute() – virtuálna metóda pre vyvolanie zmeny počasia, vyvolanie aktualizácií od počasia
závislých naplánovaných úloh a naplánovanie novej zmeny
počasia.
CWeatherManager
Trieda reprezentujúca manažér počasia, ktorý spravuje zoznam počasí a na základe náhodného výberu
metódou rulety vyberá aktuálne počasie.
Atribúty
CWeather* current_weather – smerník na aktuálne počasie.
WEATHER_LIST weather_list – zoznam všetkých možných počasí.
Metódy
CWeather& GetCurrentWeather() – poskytnutie referenciu na aktuálne počasie .
Load() – načítanie počasí do zoznamu možných počasí prostredníctvom poskytovateľa vstupných
údajov.
73
float ChangeWeather() – zmena aktuálneho počasia metódou rulety na základe
pravdepodobností nastania jednotlivých počasí. Vracia čas
trvania práve zmeneného počasia v hodinách.
CWeather
Trieda reprezentujúca pomenovaný stav počasia. Je definovaná parametrami poveternostných
vplyvov, ako aj pravdepodobnosťou výskytu a možným intervalom trvania – premenlivosťou.
Atribúty
string name – názov počasia.
string description – stručný opis počasia.
float wind_speed – rýchlosť vetra [km/h]. Spodné ohraničenie je 0 km/h.
float fog_density – hustota hmly [%]. Ohraničenie je 0 – 100%.
float precip_amount – intenzita zrážkovej činnosti [mm/h] – sneženie alebo dážď. Spodné
ohraničenie je 0 mm/h.
float zero_temp_heigth – nadmorská výška, v ktorej je teplota 0 0C [m].
int occur_prob – pravdepodobnosť výskytu počasia. Hodnota z intervalu <0,MAX_RAND>.
float occur_time_min – minimálna dĺžka trvania počasia. Hodnota je väčšia ako 0.
float occur_time_max – maximálna dĺžka trvania počasia. Hodnota je väčšia ako hodnota
minimálnej dĺžky trvania počasia.
Metódy
GetAttribute() – abstraktná metóda predstavujúca množinu všetkých Get() metód vracajúcich
hodnoty atribútov triedy.
SetAttribute() – abstraktná metóda predstavujúca množinu všetkých Set() metód nastavujúcich
hodnoty atribútov triedy.
string WeatherInfo() – informácia o počasí. Metóda vracia formátovaný reťazec znakov
obsahujúci názov a popis počasia, rýchlosť vetra, hustotu hmly, intenzitu
zrážok a výšku, v ktorej je teplota 0 0C.
float EnergyImpact(float heigth) – vypočíta koeficient vplyvu počasia na energiu
horolezca v závislosti od zadanej nadmorskej výšky.
float GetTemperature(float heigth) – vypočíta hodnotu teploty v závislosti od
nadmorskej výšky.
74
5.5.3 Typy počasia a ich zmenaTak, ako vyplýva zo stavového diagramu, jednotlivé stavy počasia sú reprezentované určitým typom
počasia, t.z. určitou kombináciou jednotlivých poveternostných vplyvov.
V diagrame tried modelu počasia vidno, že jednotlivé typy počasia sú reprezentované ako
celok triedou CWeather. Zmena počasia nie je daná zmenou hodnôt jednotlivých parametrov počasia,
je daná zámenou objektov triedy CWeather s preddefinovanými hodnotami parametrov. Zmenu
počasia implementuje trieda CWeatherChange, pričom výber aktuálneho počasia z množiny možných
počasí zabezpečuje trieda CWeatherManager.
V nasledujúcej tabuľke sú navrhnuté základné typy počasia a ich parametre. Treba
pripomenúť, že súčet pravdepodobností výskytu navrhovaných a využívaných typov počasí by mal
tvoriť 100 %. Dôvodom je zachovanie správnosti zadaných hodnôt pravdepodobnosti výskytu.
Pozn.: Nasledovné parametre nie sú navrhnuté pre žiadnu konkrétnu lokalitu. Pri zadávaní
jednotlivých typov počasia a ich parametrov je vhodné riadiť sa meteorologickými údajmi pre
navrhovanú lokalitu.
Názov Popis
Pravdepodobnosť výskytu
[promile]Minimálna doba trvania [h] Maximálna doba trvania [h]
Rýchlosť vetra [km/h] Hustota hmly [%] Zrážkový úhrn [mm/h]Výška s teplotou 0C [m
n. m.]
Slnečno Jasné, bezoblačné počasie bez poveternostných vplyvov. Maximálna viditeľnosť.
250 6,0 22,0
0 0 0 1800,0
Veterno Jasné, bezoblačné počasie s pomerne silným vetrom.
120 3,5 16,0
80,0 0,0 0,0 1600,0
Hmlisto Počasie s hustou hmlou. Slabá viditeľnosť.
100 4,0 12,0
0,0 70,0 0,0 1600,0
Padajúce zrážky Oblačné počasie s padajúcimi zrážkami. Vo vyšších polohách sneženie, v nižších dážď.
140 6,0 20,0
0,0 0,0 14,0 1500,0
Hmlisto a veterno Veterné počasie s prúdiacou hmlou. Slabá viditeľnosť.
80 2,0 6,0
45,0 50,0 0,0 1500,0
Sychravo Mierne padajúci dážď s tvoriacou sa hmlou.
110 7,5 18,5
0,0 40,0 10,0 1900,0
75
Výchrica Veterné počasie s prudko padajúcimi zrážkami. Zlá viditeľnosť.
120 5,5 10,0
50,0 0,0 12,0 1450,0
Veterná smršť Veterná smršť s hustým dažďom a hmlou. Minimálna viditeľnosť.
80 3,5 12,0
55,0 10,0 12,5 1550,0
Tabuľka 3 Typy počasia
76
5.5.4 Sekvenčný diagram načítania typov počasiaNa nasledovnom obrázku je znázornený sekvenčný diagram načítania typov počasia.
Princíp je nasledovný: Manažér zistí načíta do zoznamu mená všetkých súborov s typmi
počasia, ktoré mu poskytne príslušný poskytovateľ údajov CXmlDataProvider. Pre každý súbor
vytvorí manažér objekt počasia CWeather, pre každý atribút počasia načíta z poskytovateľa údajov
atribút počasia a nastaví ho v objekte, uloží objekt počasia do zoznamu možných počasí.
obr. 24 Sekvenčný diagram Načítanie typov počasia
77
5.6 Návrh vstupno-výstupného podsystému
5.6.1 Účel podsystému a princíp jeho činnostiVstupno-výstupný podsystém (ďalej len IO modul) zapuzdruje v sebe väčšinu operácií
s konfiguračnými súbormi pre aplikáciu. Menovite je to:
načítavanie parametrov inventára
načítavanie údajov o expedíciách
načítavanie údajov o horolezcoch a ich parametrov
načítavanie parametrov počasia
Do budúcnosti sa plánuje doplnenie jeho funkcionalitu o serializáciu vyššie spomenutých
parametrov do súborov pri ukladaní pozície.
Načítavané údaje budú uložené v XML súboroch. Na parsovanie týchto súborov bude použitý
Xerces–C++ Parser (aktuálne vo verzii 2.7). Zvolili sme si implementáciu DOM.
Dôvodom je to, že celý súbor sa načíta naraz a potom je prístup k jednotlivým jeho častiam
okamžitý, pretože jednotlivé elementy sú uložené v objektových štruktúrach v pamäti. Použitie DOM
taktiež umožňuje širšie možnosti validácie a kontroly vstupných údajov.
Oproti pôvodnému návrhu, kedy sa všetky informácie o expedíciách, horolezcoch a inventári
mali nachádzať v spoločných súboroch – jeden súbor pre jednu kategóriu údajov – rozhodli sme sa
zapisovať údaje o každej entite do samostatného súboru. To uľahčí manipuláciu v prípade pridávania
alebo odoberania entít. Tieto súbory budú vyhľadávané v nasledovných podadresároch hlavného
adresára aplikácie:
expeditions/ – pre informácie o expedíciách
inventory/ – pre informácie o položkách inventáru
mountaineers/ – pre informácie o horolezcoch
weather/ – pre parametre počasia
Modul si bude všetky údaje, ktoré načíta zo súborov ukladať do svojich vnútorných štruktúr
v pamäti, aby už nebolo potrebné znova ich načítavať. Preto pri viacnásobných požiadavkách
o hodnotu atribútu sa tento načíta iba pri prvej požiadavke, pri ostatných sa priamo vráti uložená
informácia.
78
5.6.2 Štruktúra načítavaných súborovŠtruktúra súborov s údajmi je presne definovaná. Na zabezpečenie kontroly štruktúry používa
aplikácia validáciu XML dokumentu pomocou DTD.
Nasledujú DTD popisy pre jednotlivé typy súborov.
Inventár<!ELEMENT item (name,purpose,image,description,type,weight,limits,impacts,enables)>
<!ATTLIST item passive (true|false) #REQUIRED><!ATTLIST item required (true|false) #REQUIRED>
<!ELEMENT name (#PCDATA)><!ELEMENT purpose (#PCDATA)><!ELEMENT image (#PCDATA)><!ELEMENT description (#PCDATA)><!ELEMENT type (#PCDATA)><!ELEMENT weight (#PCDATA)><!ELEMENT limits (use_count,durability,usage)><!ELEMENT impacts (health_factor,weather_impact,terrain_difficulty)><!ELEMENT enables (enable_breathe,enable_sleep,enable_cook,enable_move)><!ELEMENT weather_impact (precip_factor,wind_factor,fog_factor,temp_factor)><!ELEMENT terrain_difficulty (snow_factor,rock_factor,ice_factor,ground_factor,mud_factor)><!ELEMENT use_count (#PCDATA)><!ELEMENT durability (#PCDATA)><!ELEMENT usage (#PCDATA)><!ELEMENT health_factor (#PCDATA)><!ELEMENT precip_factor (#PCDATA)><!ELEMENT wind_factor (#PCDATA)><!ELEMENT fog_factor (#PCDATA)><!ELEMENT temp_factor (#PCDATA)><!ELEMENT snow_factor (#PCDATA)><!ELEMENT rock_factor (#PCDATA)><!ELEMENT ice_factor (#PCDATA)><!ELEMENT ground_factor (#PCDATA)><!ELEMENT mud_factor (#PCDATA)><!ELEMENT enable_breathe (#PCDATA)><!ELEMENT enable_sleep (#PCDATA)><!ELEMENT enable_cook (#PCDATA)><!ELEMENT enable_move (#PCDATA)>
Počasie<!ELEMENT weather (name,description,occurence,parameters)><!ELEMENT name (#PCDATA)><!ELEMENT description (#PCDATA)><!ELEMENT occurence (occur_prob,occur_time_min,occur_time_max)><!ELEMENT occur_prob (#PCDATA)><!ELEMENT occur_time_min (#PCDATA)><!ELEMENT occur_time_max (#PCDATA)><!ELEMENT parameters (wind_speed,fog_density,precip_amount,zero_temp_height)><!ELEMENT wind_speed (#PCDATA)><!ELEMENT fog_density (#PCDATA)><!ELEMENT precip_amount (#PCDATA)><!ELEMENT zero_temp_height (#PCDATA)>Horolezci
79
<!ELEMENT mountaineer (name,biography,photo,skills)><!ELEMENT name (first_name,middle_name,last_name)><!ELEMENT biography (#PCDATA)><!ELEMENT photo (#PCDATA)><!ELEMENT skills (endurance,technique,performance)><!ELEMENT first_name (#PCDATA)><!ELEMENT middle_name (#PCDATA)><!ELEMENT last_name (#PCDATA)><!ELEMENT endurance (#PCDATA)><!ELEMENT technique (#PCDATA)><!ELEMENT performance (#PCDATA)>
Expedície<!ELEMENT expedition (name,peak,information,difficulty,model_data)><!ELEMENT name (#PCDATA)><!ELEMENT peak (peak_name,height,location,image)><!ELEMENT information (#PCDATA)><!ELEMENT difficulty (#PCDATA)><!ELEMENT model_data (#PCDATA)><!ELEMENT peak_name (#PCDATA)><!ELEMENT height (#PCDATA)><!ELEMENT location (#PCDATA)><!ELEMENT image (#PCDATA)>
80
5.6.3 Diagram tried IO moduluNa nasledovnom obrázku je znázornený diagram tried IO modulu, ktorý zabezpečuje: načítanie a
uchovávanie informácií o možných typoch počasia, horolezcoch, expedíciách a pomôckach patriacich
do inventáru. Tieto informácie poskytuje ostatným častiam aplikácie.
obr. 25 Diagram tried IO modulu
81
CSingleton
Trieda implementujúca návrhový vzor singleton. Triedy, od ktorých sa vyžaduje, aby boli singletonmi
musia dediť z tejto triedy.
DOMBuilder
Trieda poskytovaná balíkom Xerces–C++ Parser. Poskytuje komplexnú funkcionalitu pre vytváranie
parserov a serializátorov údajov do XML súborov.
DOMErrorHandler
Trieda poskytovaná balíkom Xerces–C++ Parser. Je to abstraktná trieda. Pre konkrétnu implementáciu
je potrebné implementovať metódu handleError().
CHorexErrorHandler
Jednoduchá implementácia spracovania chýb pri parsovaní XML pre našu aplikáciu. Pri chybe sa
zaznamená do logu presné miesto výskytu chyby v súbore.
Metódy
handleError() – metóda, ktorá zabezpečuje reakciu na výskyt chyby.
CXmlFileData
Trieda reprezentujúca obsah jedného XML súboru. Obsahuje všetky hodnoty listových elementov ako
aj atribútov v tomto súbore.
Atribúty
BOOL_ATT_MAP bools – mapa hodnôt atribútov a elementov s hodnotou typu bool.
INT_ATT_MAP integers – mapa hodnôt atribútov a elementov s hodnotou typu int.
FLOAT_ATT_MAP floats – mapa hodnôt atribútov a elementov s hodnotou typu float.
STRING_ATT_MAP strings – mapa hodnôt atribútov a elementov s hodnotou typu string.
Metódy
TYP GetTYPAttValue(const string& att_name) – metódy, ktoré vrátia hodnotu
atribútu daného mena. Hodnoty sú zadelené do štyroch skupín
podľa ich typu: int, float a bool.
void GetStringAttValue(const string& att_name, string& value_out) –
metóda, ktorá v objekte value_out vráti hodnotu typu
string atribútu daného mena.
CXmlFileData(const string& file_path) – konštruktor triedy. V jeho tele sa používa
Xerces–C++ Parser. Uskutočňuje sa tu celá operácia
načítavania a ukladania atribútov/elementov.
82
bool IsInteger(const string& str, int* int_out) – metóda, ktorá zistí, či
zadaný reťazec obsahuje hodnotu, ktorá sa môže konvertovať
na typ int. V premennej int_out bude v prípade úspechu
výsledok.
bool IsFloat(const string& str, float* float_out) – metóda, ktorá zistí, či
zadaný reťazec obsahuje hodnotu, ktorá sa môže konvertovať
na typ float. V premennej float_out bude v prípade úspechu
výsledok.
void Trim(string& str, const string& delim) – metóda, ktorá oreže počiatočné
a koncové znaky reťazca str, ak sú zhodné s ľubovoľným zo
znakov reťazca delim.
CXmlDataProvider
Hlavná trieda IO modulu. Je implementovaná ako singleton. Poskytuje metódy pre získanie zoznamu
XML súborov vo zvolenom adresári a parametrov, ktoré sú načítavané z nájdených súborov. Načítané
parametre sú uchovávané v pamäti, aby nebolo potrebné ich znovu načítavať zo súborov.
Atribúty
FILE_ATT_MAP attributes – mapa so všetkými načítanými parametrami (radené podľa
súborov).
Metódy
TYP GetTYPAttValue(const string& file_name, const string& att_name)
– metódy, ktoré vrátia hodnotu atribútu daného mena, ktorý sa
nachádza v zadanom súbore. Hodnoty sú zadelené do štyroch
skupín podľa ich typu: int, float a bool.
void GetStringAttValue(const string& file_name, const string&
att_name, string& value_out) – metóda, ktorá
v objekte value_out vráti hodnotu typu string atribútu
daného mena, ktorý sa nachádza v zadanom súbore.
void ReadFileNames(const string& path, vector<string>& value_out) –
metóda ktorá vyhľadá všetky XML súbory v zadanom adresári.
Slúži pri inicializačných fázach, kedy si aplikácia zisťuje aké
konfiguračné súbory má k dispozícii.
83
5.7 Návrh modelu horolezca
5.7.1 Účel podsystému HorolezecHorolezec v sebe zapuzdruje všetky metódy a premenné spojené s činnosťou horolezca.
Horolezec sa manažuje sám a poskytuje rozhranie pre komunikáciu s horolezcom. Zahŕňa tri základné
dátové modely:
Energiu horolezca
Zdravie horolezca
Vyčerpanie horolezca
Hlavnou úlohou modelu horolezca je uchovávať hodnoty zdravia, energie, vyčerpania
a prerátavať spotrebu energie pre každý úsek cesty a poskytovať rozhranie triede CGroup.
Pri inicializácií sa vytvoria inštancie tried CEnergy, CHealth, CExhaustion. Tým sa vytvorí
horolezec s pnlým zdravím, energiou a žiadnou vyčerpanosťou. Horolezec rieši aj závislosť energie od
zdravia a vyčerpania od výšky. Taktiež sa stará o závislosti medzi spotrebou energie a počasím.
Horolezec je definovaný svojim
Menom
Koeficientom závislosti energie od zdravia
Koeficientom závislosti energie od inventáru
Koeficientom závislosti energie od počasia
Triedami Zdravia, Vyčerpania, Energie
Zmena zdravia horolezca závisí od vonkajšieho prostredia ako aj od pravdepodobnostného
modelu ochorenia. Úbytok energie horolezca je závislí len od vonkajších faktorov prostredia a času.
Vyčerpanie horolezca je závisle tiež len od vonkajších faktorov, ale najviac od výšky v ktorej sa
horolezec nachádza.
84
5.7.2 Diagram tried Model horolezcaNa nasledovnom obrázku je znázornený diagram tried modelu horolezca, ktorý zabezpečuje:
Uchovávanie aktuálneho stavu horolezca, zmenu stavu horolezca,
obr. 26 Diagram tried Model Horolezca
85
CMountaineer
Trieda implementujúca rozhranie medzi Energiou, Zdravím, Vyčerpaním a inými triedami.
Zabezpečuje mechanizmus komunikáciou medzi týmito triedami. Táto trieda bude uchovávať aj
samotné inštancie tried CHealth, CEnergy, CExhastion.
Atribúty
string name – Bude uchovávať meno horolezca
float weather_impact - Bude vyjadrovať vplyv počasia na horolezca
float inventory_impact - Bude vyjadrovať Vplyv inventaru na horolezca;
float health_impact - Bude vyjadrovať vplyv zdravia na energiu
CHealth *Health – Inštancia triedy CHealth
CEnergy *Energy– Inštancia triedy CEnergy
CExhaustion *Exhaustion– Inštancia triedy CExhaustion
Metódy
void ChangeMountaineer() – Trieda zabezpečujúca menenie stavu horolezca, ako premenné
bude mať vlastnosti vonkajšieho prostredia
float GetHealthCoef() – Bude vraciať koeficient zdravia
float GetInventoryCoef() – Bude vraciať koeficient inventáru
float GetEnergy() – Bude vraciať aktuálnu energiu horolezca
void AddFood() – Bude pridávať jedlo horolezcovi, pridá energiu jedla triede CEnergy
void AddSleep()- Bude pridávať spánok a oddych horolezcovi triede CExhaustion
void AddHealth() –Pridá zdravie horolezca
float GetHealth() – Bude vraciať zdravie horolezca
float GetExhaustion() – Bude vraciať vyčerpanie horolezca
float GetEnergyDecresePerHour() - Vrati ubytok energie za hodinu horolezca, dôležité pre
zisťovanie, či máme dostatok energie na prejdenie určitého úseku
float GetTimeCoef() - Koeficient ovplyvnenia casu úlohy
86
CHealth
Trieda, v ktorej sa uchováva hodnota zdravia Horolezca a ktorá zabezpečuje aj úbytok zdravia
na základe pravdepodobnostného modelu. Taktiež zabezpečuje prírastok zdravia z externých zdrojov.
obr. 27 Zdravie horolezca
Atribúty
float health - Aktuálna hodnota zdravia, hodnota je 0 - 100
float health_decrease_probability - Pravdepodobnost ochorenia 0 - 0.5
float health_decrease – Množstevny úbytok zdravia ak horolezec ochorie
Metódy
CHealth() – Konštruktor triedy, bude nastavovať atribúty
void SetDecreaseProbability() – Bude nastavovať pravdepodobnost ochorenia
float GetHealth() – Bude vraciať aktuálnu hodnotu zdravia
void SetHealthDecrease() – Bude nastavovať ubytok zdravia ak ochorie
void AddHealth() – Bude pridávať zdravie horolezcovi, napríklad pri použití lekárničky
float ChangeHealth()- Zmena zdravia za casovu jednotku
87
CEnergy
Trieda, v ktorej sa uchováva hodnota energie horolezca a ktorá zabezpečuje aj úbytok energie
na základe vonkajších vplyvov, ktorý však nastavuje používateľ triedy. Taktiež zabezpečuje prírastok
energie, napríklad po požití jedla alebo iných energetických zdrojov
Atribúty
float energy - Aktuálna hodnota energie, hodnota je 0 – 1000
Metódy
CEnergy() – Konštruktor triedy, bude nastavovať atribút energie
float GetEnergy(); – Bude vracať aktuálnu hodnotu energie
string GetEnergyStatus(); – Bude vracať slovný popis aktuálnej energie
void AddHealth() – Bude pridávať zdravie horolezcovi, napríklad pri použití lekárničky
float ChangeEnergy()- Zmena aktuálnej energie
CExhaustion
Trieda, v ktorej sa uchováva hodnota vyčerpanosti horolezca a ktorá zabezpečuje aj úbytok
vyčerpanosti na základe času od poslednej aktualizácie vyčerpanosti. Taktiež zabezpečuje prírastok
hodnoty vyčerpanosti z externých zdrojov. Nulová hodnota znamená úplnú vyčerpanosť.
Atribúty
float Exhaustion - Aktuálna hodnota vyčerpanosti, hodnota je 0 – 1000
float Exhaustion_decrease - Hodnota poklesu hodnoty vyčerpanosti za hodinu
Metódy
CExhaustion() () – Konštruktor triedy, bude nastavovať atribúty vyčerpanosti
float GetExhaustion(); – Bude vracať aktuálnu hodnotu vyčerpanosti
void ChangeExhaustionDecrease(float change); – Bude meniť úbytok vyčerpania za
časovú jednotku
void AddSleep() – Bude pridávať hodnotu vyčerpanosti horolezcovi, napríklad pri použití
oddychovaní
void ChangeExhaustion()- Zmena aktuálnej hodnoty vyčerpanosti na základe času, ktorý bude
parameter metódy
88
5.8 Návrh aktivít a úloh horolezca
5.8.1 Návrh aktivít horolezca v kroku simulácieStavba fixných lán – FixedRopesTask
Vstup: súradnice koncového bodu.
Výstup: na danom úseku budú ukotvené fixné laná, horolezec je v koncovom bode.
Vstupný stav: horolezec má dostatok fixných lán,
Výstupný stav: úsek na ktorom sú ukotvené fixné laná má nastavený atribút, odpočítanie položiek
z inventára
laná sa naťahujú len medzi viditeľnými bodmi,
súčasne sa vykonáva presun do koncového bodu,
zmena atribútu nastavenia fixných lán len ak je činnosť ukončená
Stavba tábora – BuildCampTask
Vstup: súradnice určeného miesta
Výstup: tábor je postavený
Vstupný stav: horolezec sa nachádza na určenom mieste
Výstupný stav: miesto na ktorom je tábor postavený má nastavený atribút.
Tábor je možné postaviť len ak
horolezci majú dostatok energie
horolezci majú potrebné vybavenie v inventári
pole na ktorom sa má tábor postaviť má atribút možného postavenia tábora
Pracujúcim horolezcom ubudne časť energie (rovnomerne každému v skupine, predpokladáme, že si
navzájom pomáhajú. Odoberú sa im vybrané veci z inventára.
Po postavení tábora sa miesto označí.
Oddych v tábore – RestTask
Vstup: činnosť ktorú má vykonávať čas jej trvania.
Výstup: –
Vstupný stav: horolezec sa nachádza na mieste kde je postavený tábor
Výstupný stav: doplnená energia horolezcom
V tábore možno:
jesť – variť jedlo z inventára, piť tekutiny
spať – použitie spacieho vaku
liečiť nemoci – položky inventára označené zdravie
89
Čakanie v teréne – WaitTask
Vstup: čas čakania
Výstup: –
Vstupný stav: horolezec sa nachádza na mieste kde je postavený tábor
Výstupný stav: prepočítaná energia horolezcov
Prepočítanie energie pre nasledujúce aktivity:
jedenie
možný spánok spanie, ale nie hlboký– energia sa pridáva menej
Presun – MoveTask
Vstup: cieľové súradnice
Výstup: skupina sa nachádza na cieľových súradnichach
Vstupný stav: parameter Zdravie sa ne/umožní prechod na iné miesto
Výstupný stav: –
1. Zohľadnenie terénu po ktorom sa lezie
Výber techniky,
Výpočet náročnosti podľa terénu.
Vplyv počasia
Zmena atribútov horolezca podľa výpočtu energie
2. Podmienka pri zranení
ak počet nesených > počet nesúcich potom neúspech expedície.
Pred vykonaním úloh sa prepočíta energia, zdravie, a inventár horolezcov. Na základe toho sa zistí či
horolezci môžu úlohu splniť. Pri nedostatku energie horolezca sa mu pokúsi doplniť jedlom
z inventára.
90
5.8.2 Návrh úloh a ich ohraničeníPopis navrhnutých úloh
BuildCamp – stavba tábora
FixedRopesTask – kladenie fixných lán
MoveTask – presun po usporiadanom zozname spojníc
RestTask – na bode, kde je postavený tábor
WaitTask – na spojnici alebo v bode
Ohraničenia úloh
Ohraničenia sa týkajú vykonávania úloh horolezcami vzhľadom na ich polohu a to buď v bode alebo
na spojnici. Uvádzame zoznam úloh ktoré sa môžu vykonávať kde:
BuildCamp – na bode
FixedRopesTask – na spojnici
MoveTask – na spojnici
RestTask – na bode, kde je postavený tábor
WaitTask – na spojnici alebo v bode
Preplánovanie udalosti ukončenia úlohy
Preplánovanie znamená zrušenie pôvodnej trasy a návrat do najbližšieho viditeľného bodu. Zvislé
hrubé čiary predstavujú neočakávané udalosti kedy dochádza k preplánovaniu. Z pôvodného zoznamu
plánovanej trasy sa zrušia body za hrubou čiarou a naplánuje sa prechod na najbližší predchádzajúci
viditeľný bod. Error: Reference source not found znázorňuje dve neočakávané situácie s1, s2 a návrat
do viditeľného bodu p2.
Bod p1 – začiatočný bod úlohy presunu
Bod p6 –koncový bod úlohy presunu
Body p2,p4 – viditeľné kontrolné body
Body p3,p5 – neviditeľné body, nachádzajú sa na rozhraní spojníc s rôznymi povrchmi
Spojnice j1 – j5 – plánovaná trasa
91
obr. 28 Preplánovanie udalosti
92
5.8.3 Diagram tried modulu TaskNasledujúci obrázok znázorňuje diagram významných tried z pohľadu triedy úloh CTask. Od
abstraktnej triedy CTask sú odvodené dva hlavné typy úloh. Prvý tvoria úlohy presunu
CMovementTask a druhý úlohy bez presunu horolezcov CDurationTask.
obr. 29 Diagram tried modulu Task a Group
93
CTask
Predstavuje abstraktnú triedu modulu úloh. Obsahuje čisto virtuálne metódy Execute,
Recalculate, EstimateDTime, ktoré treba prekonať v odvodených triedach.
Atribúty
Public:
enum TASK_TYPE { BUILD_CAMP_TASK, WAIT_TASK, MOVE_TASK, REST_TASK,
FIXED_ROPES_TASK }; – každá úloha ma svoj identifikátor, možnosti vyjadruje pomenovaný
typ pre úlohy.
static const float MIN_HEIGHT; – dolné ohraničenie pre výpočet odhadu času podľa pozície.
static const float MAX_HEIGHT; – horné ohraničenie pre výpočet odhadu času podľa pozície.
static const float TASK_HEIGHT_MIN[]; - dolné ohraničenie času podľa typu úlohy.static const float TASK_HEIGHT_MAX[]; - horné ohraničenie času podľa typu úloh.
Protected:
CGroup* group; – smerník na skupinu horolezcov ktorí vykonávajú úlohu.
TASK_TYPE task_type; – typ úlohy špecifikovaný vymenovaným typom
Metódy
Public:
bool Reschedule(float actual_time, int prior,const string& u_inf); )
– preplánovanie úlohy pri neočakávanej situácii. Treba
prekonať v odvodených triedach v konkrétnej úlohy. Používateľ
rozhoduje či sa má v úlohe ďalej pokračovať alebo sa má
naplánovať návrat do predchádzajúceho bodu. Popis situácie
vyjadruje reťazec u_inf . Priorita úlohy zostáva rovnaká.
virtual void Recalculate(float dtime) = 0; – prepočítanie podľa typu úlohy.
Napríklad pri kladení fixných lán sa označia úseky, na ktorých
boli položené laná do aktuálneho času. Okrem toho sa za čas
dtime prepočíta v každej úlohe energia, zdravie a inventár
horolezcov.
virtual void Execute() = 0; – metóda určuje čo sa má stať po vykonaní úlohy -
v ideálnom prípade. (napríklad v prípade úlohy položenia
fixných lán budú na úseku položené laná).
virtual float EstimateDTime() = 0; – odhad ideálneho čas trvania úlohy pri jej
plánovaní, prepočítanie podľa typu úlohy, vybraných
horolezcov.
TASK_TYPE GetTaskType(); – vráti typ úlohy.
94
Private:
float computeTaskTimeForHeight(int task_type, float height); – odhad
času typu úlohy podľa nadmorskej výšky. Používa ju metóda
EstimateDTime.
CGroup
Definuje skupinu horolezcami ktorí vykonávajú špecifikovanú úlohu. Poskytuje metódu pre
naplánovanie úlohy a presun horolezcov na novú pozíciu.
Atribúty
Private:
string name; – názov skupiny ako identifikátor
CControlPoint* current_position – súčasná (posledná) pozícia skupiny
MOUNTAINEER_LISTmountaineer_list; – zoznam horolezcov v skupine
Protected:
CTask* group_task; – úloha ktorú horolezci vykonávajú, alebo NULL
Public:
static const int TASK_EVENT_PRIORITY = 20; – konštanta priority vykonania úlohy
pre plánovač udalostí.
Metódy
Public:
string GetName() – vráti meno skupiny
void SetName(string name) – nastaví meno skupiny
CControlPoint* GetPosition() – vráti pozíciu skupiny horolezcov (posledný bod na
ktorom sa nachádzali)
string GetName() – vráti meno skupiny
bool HasTask() – zisťuje, či má skupina definovanú úlohu
CTask* GetTask() - vráti meno aktuálnu úlohu
void SetTask(CTask *task) – nastavenie úlohy
void AddMountaineer(CMountaineer* mountaineer) – pridanie horolezca do skupiny
void RemoveMountaineer(string name) – odobratie horolezca podľa mena zo skupiny
void Init() – inicializuje skupinu pridaním horolezcov na aktuálnu pozíciu a po odhade času
dokončenia úlohy naplánuje nastavenú úlohu.
void Relocate(CControlPoint *destination) – presunie horolezcov z aktuálnej
pozície na novú pozíciu určenú parametrom
95
CGroupManager
Zabezpečuje správu skupín, poskytuje metódy pre vytvorenie, získanie zoznamu skupín a stará sa
o zrušenie skupiny po dokončení úlohy uvoľnením alokovanej pamäti.
Atribúty
Private:
GROUP_LIST group_list; – zoznam skupín
Metódy
Public:
void Recalculate(float dtime) - prepočítanie energie, zdravia a inventáru horolezcov
vo všetkých skupinách.
void InsertGroup(CGroup *group) – pridanie vytvorenej skupiny horolezcov do
zoznamu všetkých skupín v simulácii
GROUP_LIST GetGroupList() – vráti ukazovateľ na zoznam skupín simulácii.
CEventTaskFinish
Udalosť v plánovači ktorá vykoná definuje. čo sa má stať po ukončení úlohy, volá metódy pre
prepočítanie hodnôt po ukončení úlohy.
Atribúty
Private:
GROUP_LIST group_list; – zoznam skupín
Metódy
Public:
CEventTaskFinish(void* owner); - konštruktor s parametrom úlohy, ktorá je vlastníkom
naplánovanej udalosti.
void Execute(); - prepočítanie hodnôt po ukončení úlohy a následné zrušenie skupiny
horolezcov, ktorá ju vykonávala
96
5.9 Návrh reprezentácie terénu a trasy expedície v simulácii
5.9.1 Reprezentácia trasy expedícieHorolezci budú mať obmedzené možnosti pohybu po hore, vymedzené preddefinovanými trasami
expedície. Tieto možné trasy definuje tvorca modelu pri vytváraní modelu hory (prípad použitia
UC09). Trasy (postupnosti lokácií) sú definované kontrolnými bodmi (UC12) a spojnicami medzi
týmito bodmi (UC13). Na hore sú definované dva špeciálne body:
počiatočný bod expedície (UC10), v ktorom všetci horolezci začínajú expedíciu. Na tomto
mieste sa nachádza aj základný tábor;
cieľový bod expedície (UC11), kde sa končí výstup horolezcov a podľa nastavenia cieľov
expedície tu môže začínať následný zostup horolezcov do základného tábora.
Typickú trasu expedície znázorňuje obrázok obr. 30.
obr. 30 Grafické znázornenie možných trás expedície
97
5.9.1.1 Kontrolné bodoyKontrolný bod je miesto na hore, ktoré je možné zvoliť ako cieľ pohybu. Kontrolný bod nemá dĺžku,
a teda prechod kontrolným bodom netrvá žiadny čas. Pozícia kontrolného bodu je určená súradnicami
v 3-rozmernom pravouhlom súradnicovom systéme, relatívne k začiatku mapy hory (okrem súradnice
reprezentujúcej výšku – tá je určená absolútne, podľa modelovanej skutočnosti).
Niektoré kontrolné body majú za úlohu iba rozdeliť spojnicu na dve s cieľom zmeniť terén
spojnice. Takéto „nevýznamné“ body, resp. body, ktoré nemajú byť možnými cieľmi pohybu, môže
tvorca modelu hory označiť ako „neviditeľné“ pre používateľa.
Vybrané kontrolné body môžu umožňovať stavbu tábora (miesto slúžiace na regeneráciu
a odpočinok horolezcov). Na iných miesta nie je stavba táboru umožnená.
5.9.1.2 Spojníce bodovSpojnica spája práve dva kontrolné body. Tieto dva body zároveň určujú pozíciu spojnice. Má
definovanú dĺžku a uhol sklonu, teda parametre významne vplývajúce na časové trvanie a energetickú
náročnosti prechodu cez túto lokáciu.
Pre zrýchlenie pohybu terénom je možné na spojnicu klásť fixné laná.
5.9.2 Reprezentácia terénuNáročnosť a rýchlosť pohybu horolezcov je do značnej miery ovplyvnená terénom, po ktorom
prechádzajú. Navrhli sme 5 základných typov terénu lokácie odvíjajúcich sa od typu podkladu terénu.
Horolezci môžu vlastniť a používať vybavenie, ktoré im uľahčuje (resp. umožňuje) pohyb v danom
type terénu (napr. obuv „snežky“ uľahčuje prechod cez zasnežený terén).
Keďže však členinosť terénu sa môže značne líšiť aj pri dvoch zhodných základných typoch
terénu, rozhodli sme sa, že tvorca modelu hory bude explicitne uvádzať aj náročnosť konkrétnej
lokácie číslom v rozsahu 0,01 (najmenšia náročnosť) až 1,0 (najväčšia náročnosť). Táto náročnosť sa
potom použije napr. pri výpočte časového trvania a energetickej náročnosti prechodu cez lokáciu
s daným terénom.
Nasledujúca tabuľka uvádza popis základných typov terénu, ich názvy používané v simulácii
a typické rozsahy náročnosti týchto terénov.
Názov terénu Náročnosť terénu PopisSnow 0,4 – 0,9 Zasnežený terén. Náročnosť stúpa priamo úmerne s hĺbkou
snehu.Rock 0,3 – 0,7 Skalnatý terén. Náročnosť je ovplyvnená sklonom
a členitosťou terénu.Ice 0,5 – 1,0 Zľadovatelý terén. Náročnosť je závislá na sklone terénu.Ground 0,01 – 0,3 Bežná suchá pôda vyznačujúca sa nízkou členitosťou.
Náročnosť stúpa priamo úmerne so sklonom terénu.Mud 0,2 – 0,5 Blato. Vzniká najmä počas dažďa a pri topení snehu a ľadu.
Náročnosť stúpa priamo úmerne so sklonom terénu.
Tabuľka 4 Reprezentácia terénu
98
5.9.3 Diagram tried terénu a trasy expedícieNa nasledovnom obrázku je znázornený diagram tried terénu a trasy expedície, ktorý zabezpečuje:
načítanie a uchovávanie informácií o lokáciách definovaných na hore, uchovávanie pozície horolezcov
a táborov, definovanie počiatočného a cieľového bodu expedície.
obr. 31 Diagram tried terénu a trasy expedície
99
CSimulation
Trieda implementujúca celkový mechanizmus simulácie a poskytujúca sprístupnenie jednotlivých
podsystémov systému.
V tomto diagrame je dôležitý jej účel v súvislosti so sprístupňovaním objektu hory (inštancia
triedy CMountain) a odkazov na počiatočný a cieľový bod expedície.
Bližšie je popísaná v kapitole 5.1.1.
Atribúty
Protected:
CMountain* mountain – smerník na objekt hory.
CControlPoint* start_point – smerník na počiatočný bod expedície.
CControlPoint* end_point – smerník na cieľový bod expedície.
Metódy
Public:
CMountain* GetMountain() – poskytnutie smerníka na objekt hory.
CControlPoint* GetStartPoint() – poskytnutie smerníka na počiatočný bod expedície.
CControlPoint* GetEndPoint() – poskytnutie smerníka na cieľový bod expedície.
bool IsStartPoint(CControlPoint* test_point) – testuje, či je daný bod počiatočným
bodom expedície.
bool IsStartPoint(CControlPoint* test_point) – testuje, či je daný bod cieľovým bodom
expedície.
SetStartPoint(CControlPoint* point) – nastaví počiatočný bod expedície.
SetEndPoint(CControlPoint* point) – nastaví cieľový bod expedície.
CShedule
Trieda implementujúca rozvrh naplánovaných udalostí. Vyvoláva vykonanie udalostí, ktoré sú uložené
v prioritnom rade podľa času výskytu.
Bližšie je popísaná v kapitole 5.4.2.
CEvent
Trieda implementuje akúkoľvek naplánovanú udalosť. Z pohľadu plánovania zmeny počasia je
zaujímavá iba jej čisto virtuálna metóda Execute().
Bližšie je popísaná v kapitole 5.4.2.
Metódy
Public:
Execute() – čisto virtuálna metóda pre vykonanie naplánovanej udalosti.
100
CAvalanche
Trieda zdedená z CEvent. Implementuje udalosť pádu lavíny, ktorá sa vykoná vyvolaním virtuálnej
metódy Execute(). Pád lavíny sa vzťahuje ku konkrétnej lokácii.
Atribúty
nemá
Metódy
Public:
Execute() – virtuálna metóda pre vyvolanie pádu lavíny. Pád lavíny spôsobí smrť horolezcov
a zničenie tábora na mieste dopadu.
CTask
Trieda CTask predstavuje abstraktnú triedu modulu úloh.
Bližšie je popísaná v kapitole 5.8.3.
CEntity
Trieda CEntity predstavuje abstraktnú triedu pre entity, ktorými sú tábor a horolezec.
CCamp
Trieda entity pre horolezecký tábor.
CMountaineer
Trieda entity pre horolezca.
Bližšie je popísaná v kapitole 5.7.2.
CMountain
Trieda CMountain predstavuje model hory. Jej hlavnou úlohou je načítavanie a uchovávanie lokácií
a plánovanie lavín.
Atribúty
Private:
string name – názov hory.
string mountain_config_file_path – cesta k súboru nastavení "mountain.cfg".
LOCATIONS_VECTOR locations – vektor všetkých lokácií na hore.
Metódy
Public:
Init(const string& locations_file_path) – inicializácia hory. Prebehne načítanie lokácií
zo zadaného XML súboru, vytvorenie základného tábora
101
a umiestnenie všetkých horolezcov na počiatočný bod
expedície.
LOCATIONS_VECTOR_ITERATOR GetLocationsIterator() – vráti iterátor nastavený na
začiatok vektora lokácií.
LOCATIONS_VECTOR_CONST_ITERATOR GetLocationsIteratorEnd() – vráti konštatný
iterátor s hodnotou konca vektora lokácií.
ScheduleAvalanches() – naplánuje lavíny na začiatku simulácie.
CLocationSerializer
Trieda CLocationSerializer slúži na serializáciu a deserializáciu údajov o lokáciách do/z XML súboru.
Metódy
Public:static Unserialize(const string& file_path, vector<CMountainLocation*>&
locations_out) – parsuje XML súbor určený prvým
parametrom a vráti vektor lokácií ako druhý parameter.
CMountainLocation
Abstraktná trieda, ktorá reprezentuje miesto na hore.
Atribúty
Private:
string id – identifikátor používaný v XML súbore.
MOUNTAINEER_LIST mountaineers – zoznam horolezcov na danej lokácii.
auto_ptr<CTerrain> terrain – smerník na terén.
Metódy
Public:
MOUNTAINEER_LIST_ITERATOR GetMountaineersIterator() – vráti iterátor nastavený na
začiatok zoznamu horolezcov.
MOUNTAINEER_LIST_CONST_ITERATOR GetMountaineersIteratorEnd() – vráti konštatný
iterátor s hodnotou konca zoznamu horolezcov.
AddMountaineer(CMountaineer* mountaineer) – pridá horolezca na lokáciu.
RemoveMountaineer(CMountaineer* mountaineer) – odoberie horolezca z lokácie.
AfterAvalanche() – metóda volaná po spadnutí lavíny.
CControlPoint
Trieda CControlPoint je odvodená od triedy CMountainLocation a reprezentuje kontrolný bod trasy.
102
Atribúty
Private:
bool visible – či je kontrolný bod viditeľný pre používateľa.
bool camp_allowed – či terénne podmienky dovoľujú postaviť tu tábor.
bool camp_established – či je tu postavený tábor.
auto_ptr<CCamp> camp – smerník na tábor postavený na tejto lokácii, ak je postavený.
JOIN_VECTOR joins – vektor spojníc, ktoré tu začínajú (resp. končia).
Metódy
Public:
CCamp* EstablishCamp(bool base_camp) – vytvorí inštanciu nového tábora.
AfterAvalanche() – metóda volaná po spadnutí lavíny. Prekonaná metóda umožňuje zároveň aj
zrušiť tábor, keďže rodičovská trieda nemá na tábor odkaz.
CJoin
Trieda CJoin je odvodená od triedy CMountainLocation a reprezentuje spojnicu trasy.
Atribúty
Private:
float length – dĺžka spojnice v metroch.
float slope_angle – sklon spojnice v stupňoch (0 až 89,9).
bool has_fixed_ropes – či sú na spojnici fixné laná.
CControlPoint* points[2] – kontrolné body, ktoré táto spojnica spája.
Metódy
Public:
CControlPoint* GetCommonPoint(CJoin* other_join) – vráti spoločný bod dvoch spojníc
(ak taký je).
CTerrain
Trieda CTerrain reprezentuje terén konkrétnej lokácie na hore.
Atribúty
Private:
string name – názov terénu.
float difficulty – náročnosť terénu (0,01 az 1,0).
CPoint3D
Trieda CPoint3D vyjadruje 3-rozmernú pozíciu bodu na hore.
103
Atribúty
Private:
float x – súradnica x.
float y – súradnica y.
float z – súradnica z.
104
5.9.4 Štruktúra súborov s definíciami lokáciíSúbor s definíciami lokácií je uložený vo formáte XML. Na zabezpečenie kontroly štruktúry používa aplikácia validáciu XML dokumentu pomocou DTD.
Nasleduje DTD popis pre súbor s lokáciami („mountainlocations.dtd“).
<!ELEMENT MountainLocations (ControlPoint|Join)*><!ATTLIST MountainLocations start IDREF #REQUIRED><!ATTLIST MountainLocations end IDREF #REQUIRED>
<!ELEMENT ControlPoint (Position,Terrain)><!ATTLIST ControlPoint id ID #REQUIRED><!ATTLIST ControlPoint visible (true|false) "true"><!ATTLIST ControlPoint camp_allowed (true|false) #REQUIRED><!ATTLIST ControlPoint camp_established (true|false) "false">
<!ELEMENT Join (Terrain)><!ATTLIST Join id ID #REQUIRED><!ATTLIST Join length CDATA #REQUIRED><!ATTLIST Join slope_angle CDATA #REQUIRED><!ATTLIST Join has_fixed_ropes (true|false) "false"><!ATTLIST Join starts_at IDREF #REQUIRED><!ATTLIST Join ends_at IDREF #REQUIRED>
<!ELEMENT Position EMPTY><!ATTLIST Position x CDATA #REQUIRED><!ATTLIST Position y CDATA #REQUIRED><!ATTLIST Position z CDATA #REQUIRED>
<!ELEMENT Terrain EMPTY><!ATTLIST Terrain name CDATA #REQUIRED><!ATTLIST Terrain difficulty CDATA #REQUIRED>
Nasleduje príklad zápisu XML súboru s definíciou lokácií.
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE MountainLocations SYSTEM "mountainlocations.dtd"><MountainLocations start="ControlPoint:1" end="ControlPoint:4"> <ControlPoint id="ControlPoint:1" visible="true" camp_allowed="true" camp_established="false"> <Position x="15.4" y="13.2" z="36.7" /> <Terrain name="ground" difficulty="0.1" /> </ControlPoint> <ControlPoint id="ControlPoint:2" visible="true" camp_allowed="false" camp_established="false"> <Position x="15.7" y="13.8" z="42.6" /> <Terrain name="rock" difficulty="0.4" /> </ControlPoint> <ControlPoint id="ControlPoint:3" visible="true" camp_allowed="false" camp_established="false"> <Position x="15.1" y="14.5" z="45.9" /> <Terrain name="rock" difficulty="0.6" /> </ControlPoint> <ControlPoint id="ControlPoint:4" visible="true" camp_allowed="true" camp_established="false"> <Position x="16.4" y="14.3" z="47.2" /> <Terrain name="snow" difficulty="0.9" /> </ControlPoint> <Join id="Join:1" length="14.5" slope_angle="15.6" has_fixed_ropes="false" starts_at="ControlPoint:1" ends_at="ControlPoint:2"> <Terrain name="mud" difficulty="0.3" /> </Join>
105
<Join id="Join:2" length="18.2" slope_angle="8.3" has_fixed_ropes="false" starts_at="ControlPoint:2" ends_at="ControlPoint:3"> <Terrain name="rock" difficulty="0.5" /> </Join> <Join id="Join:3" length="19.4" slope_angle="9.6" has_fixed_ropes="false" starts_at="ControlPoint:2" ends_at="ControlPoint:4"> <Terrain name="ice" difficulty="0.8" /> </Join></MountainLocations>
106
5.10Návrh modelu inventára
5.10.1 Parametre predmetovKaždý predmet, ktorý bude aplikácia používať je charakterizovaný množstvom parametrov. Pre
konkrétny predmet nemusia byť všetky parametre významné, ale daný model bol zvolený, aby bol
jednotný pre všetky predmety. Toto je aktuálny úplný zoznam parametrov predmetov:
meno
popis
účel
hmotnosť
typ
cesta k obrázku
indikátor pasívneho predmetu
indikátor vyžadovaného predmetu
počet použití
trvanlivosť (kapacita)
podmienky použitia
faktor vplyvu na zdravie
faktor vplyvu na vplyv zrážok
faktor vplyvu na vplyv vetra
faktor vplyvu na vplyv hmly
faktor vplyvu na vplyv teploty
faktor vplyvu na náročnosť zasneženého terénu
faktor vplyvu na náročnosť skalnatého terénu
faktor vplyvu na náročnosť obyčajného terénu (pevná zem)
faktor vplyvu na náročnosť mäkkého blatového terénu
faktor vplyvu na náročnosť zľadovateného terénu
indikátor umožnenia dýchania vo vysokých polohách
indikátor umožnenia regenerujúceho spánku
indikátor umožnenia prípravy jedál
indikátor umožnenia pohybu
Parametre faktory a indikátory sa používajú v simulácii pri výpočtoch vplyvu terénu a počasia
na úbytok energie horolezcov pri pohybe, alebo pri prepočítavaní zdravia horolezcov. Ostatné
parametre sú informatívne.
107
Aplikácia bude rozlišovať nasledovných šesť typov predmetov:
šaty
vybavenie
nástroje
jedlo
lieky
ostatné
Jedlo a lieky budú mať špeciálne postavenie, pretože u nich bude mať trvanlivosť alternatívny
význam. Nebude znamenať časovú trvanlivosť, ale energetickú hodnotu jedla, alebo liečiaci účinok
liekov.
108
5.10.2 Diagram tried Model inventáruNa nasledovnom obrázku je znázornený diagram tried modelu inventáru, ktorý má na starosti celý
manažment inventárov horolezcov a táborov. Poskytuje možnosti na získavanie nových predmetov (v
základnom tábore), pohyb predmetov medzi jednotlivými inventármi a používanie predmetov. Triedy
modelu inventáru sú označené v diagrame modrou farbou.
obr. 32 Diagram tried Model Inventáru
109
CEntity
Abstraktná trieda, ktorá reprezentuje entitu na hore pri expedícii. Základnými entitami sú horolezci a
tábory. Z hľadiska inventáru je dôležitá, pretože entity sú majiteľmi svojho inventáru.
CCamp
Trieda reprezentujúca tábor. Je to odvodená trieda od triedy CEntity. Jej špecialitou hľadiska inventáru
je to, že slúži iba ako úložisko predmetov – predmety zaradené do inventáru tábora budú
deaktivované. Špeciálne postavenie má základný tábor, ktorý slúži aj ako zdroj nových predmetov.
CSimulation
Trieda implementujúca celkový mechanizmus simulácie a poskytujúca sprístupnenie jednotlivých
podsystémov systému.
Bližšie je popísaná v kapitole 5.1.1.
CShedule
Trieda implementujúca rozvrh naplánovaných udalostí. Vyvoláva vykonanie udalostí, ktoré sú uložené
v prioritnom rade podľa času výskytu.
Bližšie je popísaná v kapitole 5.4.2.
CEvent
Trieda implementuje akúkoľvek naplánovanú udalosť.
Bližšie je popísaná v kapitole 5.4.2.
Metódy
Execute() – čisto virtuálna metóda pre vykonanie naplánovanej udalosti.
CItemDepleted
Trieda zdedená z CEvent. Implementuje udalosť vyčerpania kapacity (trvanlivosti) predmetu. Vykoná
sa vyvolaním virtuálnej metódy Execute().
Metódy
Execute() – virtuálna metóda pre deaktiváciu predmetu a jeho následné vyňatie z inventáru
a vyvolanie aktualizácií od inventáru závislých naplánovaných úloh.
CInventory
Trieda reprezentujúca inventár entity. Skaldá sa z dvoch častí – deaktiovaných predmetov
a aktivovaných predmetov.
110
Atribúty
CEntity* owner – entita, ktorá vlastní inventár
ITEM_LIST deactivated – zoznam všetkých neaktivovaných predmetov v inventári
ITEM_LIST activated – zoznam všetkých aktivovaných predmetov v inventári
float actual_weight – celková aktuálna hmotnosť inventáru
float max_weight – maximálna povolená hmotnosť inventáru
Metódy
CEntity* GetOwner() { return owner; } – vráti smerník na vlastníka inventáru
bool AddItem(CItem* item, float* gain_out) – metóda, pomocou ktorej pridávame
predmety do inventára
bool RemoveItem(CItem* item) – metóda, pomocou ktorej odoberáme predmety z
inventára
CItem* GetItem(const string& item_name) – metóda, ktorá nájde predmet v inventári
a vráti naň odkaz
bool UseItem(CItem* item, CEntity* subject, float* gain_out) – metóda,
ktorá vykonáva činnosti pri použití predmetu
bool DeactivateItem(CItem* item) – metóda, ktorá deaktivuje používaný predmet
void DeactivateAll() – metóda, ktorá deaktivuje všetky používané predmety v inventári (je
volaná pri skončení úlohy)
void Update(float time) – metóda, ktorá aktualizuje hodnoty parametrov aktivovaných
predmetov pri zmene stavu
ITEM_LIST& GetDeactivatedItemsList() – metóda, ktorá vráti smerník na zoznam
neaktivovaných predmetov
ITEM_LIST& GetActivatedItemsList() – metóda, ktorá vráti smerník na zoznam
aktivovaných predmetov
CItem
Trieda reprezentujúca konkrétny predmet, ktorý sa pohybuje v simulácii. Odkazuje sa na triedu
CItemData, ktorá obsahuje jeho nemenné parametre.
Atribúty
CItemData* data – smerník na objekt CItemData, ktorý poskytuje všetky nemenné parametre
CInventory* owner – smerník na inventár, v ktorom je daná CItem uložená
bool activated – indikátor aktivovaného predmetu
int times_used – počet vyčerpaných použití predmetu
float durability_used – doba, počas ktorej sa predmet používal
111
float last_update – čas, kedy prebehla posledná aktualizácia parametrov predmetu
Metódy
void Update(float time) – metóda, ktorá aktualizuje použitie spotreby predmetu
void Deactivate()–metóda, ktorá nastaví indikátor použitia na false (volá sa na konci použitia)
void SetOwner(CInventory* item_owner) – metóda, ktorá nastaví rodičovský inventár
pre predmet
int GetTimesUsed()–metóda, ktorá vráti aktuálnu hodnotu počtu použití predmetu
float GetDurabilityUsed()–metóda, ktorá vráti aktuálnu hodnotu spotrebovanej výdrže
predmetu
CItemData* GetItemData()–metóda, metóda, ktorá vráti smerník na objekt s prislúchajúcimi
informáciami
CInventory* GetOwner()–metóda, ktorá vráti smerník na rodičovský inventár
bool Use(CEntity* subject, float* gain_out) – metóda, ktorá reprezentuje
použitie predmetu
float GetLastUpade()–metóda, ktorá vráti čas poslednej aktualizácie parametrov
bool IsActivated()–metóda, ktorá zisti aktuálny stav použitia predmetu
void ItemInfo(string& value_out) – metóda, ktorá vráti reťazec so súhrnnými
informáciami o predmete
CInventoryManager
Trieda reprezentujúca manažér inventáru. Je zdrojom nových predmetov. V simulácii je dovolené iba
základnému táboru poskytovať túto funkcionalitu.
Atribúty
ITEM_DATA_MAP inventory – informácie o všetkých predmetoch, ktoré sú známe aplikácii,
zatriedené podľa mena súboru, v ktorom sa nachádzajú
Metódy
CItem* GetNewItem(const string& item_key) – metóda vytvorí novu inštanciu
predmetu pomocou triedy CItem a vráti smerník
CItemData
Trieda reprezentujúca typ predmetu. Obsahuje všetky informácie o ňom a slúži ako podklad pre
vytváranie konkrétnych inštancií predmetov (trieda CItem) pre simuláciu.
Atribúty
bool passive – Indikátor, či je vec pasívna - nie je nutné ju aktivovať, stačí ju mať v inventári.
bool required – Indikátor, či je daná vec vyžadovaná.
112
string name – Meno veci.
string purpose – Účel, na ktorý vec slúži.
string image – Cesta k obrázku, ktorý sa zobrazí v hre.
string description – Podrobnejší popis veci.
ITEM_TYPE type – Typ veci.
float weight – Hmotnosť veci, ovplyvňuje spotrebu energie horolezca.
int use_count – Maximálny počet použiti. (0 = neobmedzene).
float durability – Maximálna dĺžka použitia v hodinách. (0 = neobmedzene). Pre jedlo
a lieky predstavuje kapacitu – energetickú hodnotu.
ITEM_USAGE usage – Podmienky, kedy a kde je možné vec použiť.
float health_factor – Faktor, ktorým vec ovplyvňuje zdravie horolezca.
float precip_factor – Faktor, ktorým vec ovplyvňuje vplyv zrážok na horolezca.
float wind_factor – Faktor, ktorým vec ovplyvňuje vplyv vetra na horolezca.
float fog_factor – Faktor, ktorým vec ovplyvňuje vplyv hmly na horolezca.
float temp_factor – Faktor, ktorým vec ovplyvňuje vplyv teploty na horolezca.
float snow_factor – Faktor, ktorým vec ovplyvňuje náročnost snehového terénu.
float rock_factor – Faktor, ktorým vec ovplyvňuje náročnost skalnatého terénu.
float ice_factor – Faktor, ktorým vec ovplyvňuje náročnost zladovateného terénu.
float ground_factor – Faktor, ktorým vec ovplyvňuje náročnost obyčajného pevneho terénu.
float mud_factor – Faktor, ktorým vec ovplyvňuje náročnost blatového terénu.
bool enable_breathe Indikátor, či vec umožnuje dýchanie vo vysokých polohách.
bool enable_sleep – Indikátor, či vec umožnuje vydatný spánok.
bool zenable_cook – Indikátor, či vec umožnuje prípravu jedál.
bool enable_move – Indikátor, či vec umožnuje pohyb.
int ref_count – Počet inštancií triedy CItem, ktoré referencujú danú položku.
Metódy
GetAttribute() – abstraktná metóda predstavujúca množinu všetkých Get() metód vracajúcich
hodnoty atribútov triedy. Pre boolovské atribúty sa metódy volajú
IsAttribute() a ENablesAttribute().
IncreaseRefCount– inkrementuje počítadlo referencií na danú položku.
DecreaseRefCount– dekrementuje počítadlo referencií na danú položku.
string ItemInfo() – informácia o predmete. Metóda vracia formátovaný reťazec znakov
obsahujúci väčšinu parametrov predmetu (cesta k súboru s obrázkom nie je zahrnutá).
113
5.11Návrh používateľského rozhrania
5.11.1 Všeobecné informácie
Používateľské rozhranie bude vytvorené pomocou knižnice CEGUI. V základnom móde bude
pracovať v celoobrazovkovom režime. Všetky okná pre vizualizáciu a riadenie aplikácie a simulácie
budú ako plávajúce okná.
Používateľské rozhranie bude pozostávať zo samostatných modulov, tzv. observerov. Každý
observer bude predstavovať jedno plávajúce okno. Tieto sa budú špecializovať na rôzne funkcie.
V základnej verzii budú nasledovné observery:
Hlavné menu
Inicializácia simulácie
3D zobrazovač
Textový log
Riadiaci panel
Pred spustením samotnej aplikácie sa zobrazí ešte jedno dialógové okno, kde si môže
používateľ zvoliť konfiguráciu grafického módu a jeho parametrov (napríklad rozlíšenie, farebnú
hĺbku, vyhladzovanie hrán,...). Ak sa raz konfigurácia nastaví, obrazovka sa už nebude zobrazovať.
Zobrazí sa až po výskyte nejakej chyby pri inicializácii grafického režimu.
obr. 33 Obrazovka Konfigurácia
114
5.11.2 Hlavné menuHlavné menu bude poskytovať možnosti pre začatie simulácie, získanie informácií o aplikácii.
Bude viditeľné počas celej simulácie a bude umožňovať spúšťať novú simuláciu a ukončovať
ju a taktiež ukončiť celý program. Bude sa skladať zo štyroch plávajúcich tlačidiel, ktoré sa budú
nachádzať po celý čas v ľavom hornom rohu obrazovky.
Ovládacie prvky:
Tlačidlo Nová simulácia – zastaví simuláciu a spustí inicializáciu novej simulácie
Tlačidlo O aplikácii – zobrazí informácie o aplikácii a jej autoroch
Tlačidlo Koniec – ukončí program
obr. 34 Obrazovka Hlavné menu
5.11.3 Obrazovka pre inicializáciu simuláciePri voľbe štartu novej simulácie sa otvorí okno, ktoré nastaví niektoré parametre pre simuláciu. Sú to:
Výber expedície
Výber horolezcov
Ostatné činnosti (vytvorenie potrebných štruktúr v pamäti, načítanie inventáru, načítanie
modelu hory,...) sa vykonajú automatizovane.
Ovládacie prvky:
Tlačidlo ŠTART – spustí novú simuláciu
Tlačidlo – presunie vybratého horolezca v zozname voľných horolezcov do
zoznamu vybratých horolezcov
Tlačidlo – presunie vybratého horolezca v zozname vybratých horolezcov do
zoznamu voľných horolezcov
ListBox Expedície – zoznam všetkých expedícií, ktoré sú známe aplikácii
ListBox Voľní horolezci – zoznam všetkých horolezcov, ktorí sú známi aplikácii
ListBox Vybratí horolezci – zoznam horolezcov, ktorí sa majú zúčastniť expedície
Okrem týchto ovládacích prvkov sa na obrazovke nachádzajú aj prvku, ktoré sú schopné
poňať informáciu a zobraziť ju. Ide o textové aj obrazové údaje o horolezcoch a expedíciách.
115
obr. 35 Obrazovka Inicializácia simulácie
5.11.4 Obrazovky pre kontrolu simulácie
Obrazovky pre kontrolu simulácie sú implementované triedami podľa návrhových vzorov observer
a state (5.1.2). Jednotlivé obrazovky sa zobrazujú v určených stavoch simulácie, ktoré boli definované
v kapitole 5.2.3.
Informácie o skupine horolezcov
Obrazovka vypisuje v každom stave simulácie informácie o existujúcej skupine horolezcov, ktorý boli
označený kliknutím myšou na grafický model postavy. V obrazovke sa zobrazí zoznam horolezcov
v skupine, nim pridelená úloha, prípadne miesto ich aktivity alebo čas trvania aktivity.
116
obr. 36 Obrazovka Informácie o skupine horolezcov
Informácie o horolezcoch
Obrazovka vypisuje v každom stave simulácie informácie o horolezcovi, ktorý bol vybraný
prostredníctvom ovládacieho prvku combobox umiestneného vo vrchnej časti obrazovky. Informácie
sa vypisujú do zoznamu umiestnenom pod týmto prvkom.
obr. 37 Obrazovka Informácie o horolezcoch
Aktuálne počasie
Obrazovka sa zobrazuje v každom stave simulácie. Zobrazujú sa v nej informácie o aktuálnom počasí.
117
obr. 38 Obrazovka Aktuálne počasie
Lokalita
Obrazovka sa zobrazuje v každom stave simulácie. Po kliknutí myšou na niektorú lokalitu modelu
hory sa v obrazovke zobrazia informácie o zvolenej lokalite a o horolezcoch a táboroch, ak sú na nej
umiestnené.
obr. 39 Obrazovka Lokalita
Vytvorenie skupiny
Obrazovka sa zobrazuje po selekcii lokality, na ktorej sa nachádzajú horolezci bez priradenej úlohy.
Na ľavej strane sa nachádza zoznam voľných horolezcov a na pravej zoznam horolezcov v práve
vytváranej skupine horolezcov. Po stlačení tlačidla OK sa vytvorí nová skupinka.
118
obr. 40 Obrazovka Vytvorenie skupiny
Pridelenie materiálu horolezcom
Obrazovka sa zobrazí bezprostredne po vytvorení novej skupiny horolezcov. V ľavej časti sa nachádza
zoznam dostupného materiálu. V pravej časti obrazovky si horolezec zvolí pomocou comboboxu
horolezca a priradí mu materiál. Materiál horolezca sa zobrazuje v zozname umiestnenom na pravej
strane obrazovky bod voľbou horolezca. Tlačidlom OK sa potvrdzuje pridelenie materiálu.
obr. 41 Obrazovka Pridelenie materiál horolezcom
Zadanie úlohy pre skupinu horolezcov
Obrazovka sa zobrazuje bezprostredne po pridelení materiálu skupine horolezcov. Obsahuje
combobox, pomocou ktorého je možné zvoliť úlohu pre skupinu. Voľba úlohy sa potvrdzuje stlačením
tlačidla OK.
119
obr. 42 Obrazovka Zadanie úlohy pre skupinu horolezcov
Vytvorenie trasy
Obrazovka sa zobrazuje po zvolení úlohy, ktorá si vyžaduje zadanie trasy. V ľavej časti obrazovky sa
zobrazuje postupnosť lokalít tvoriaca trasu. V pravej časti sa zobrazujú susedné lokality posledne
zvolenej časti trasy. Tieto lokality je možné pridať ku trase stlačením tlačidla pridať. Stlačením
tlačidla Zmazať poslednú sa vymaže posledná časť trasy, tlačidlom OK sa potvrdzuje zadanie trasy.
obr. 43 Obrazovka Vytvorenie trasy
Nastavenie času úlohy
Obrazovka sa zobrazuje po zvolení úlohy, ktorá si vyžaduje zadanie času. Čas sa zadáva v hodinách
do editboxu a potvrdzuje sa tlačidlom OK.
120
obr. 44 Obrazovka Nastavenie času úlohy
Informácie o úlohePo zadaní všetkých potrebných údajov o úlohe sa zobrazí okno so súhrnnou informáciou o úlohe.
V obrazovke sa zobrazí zoznam horolezcov v skupine, nim pridelená úloha, prípadne miesto ich
aktivity alebo čas trvania aktivity. Po stlačení tlačidla OK sa ukončí proces zadávania úlohy.
obr. 45 Obrazovka Informácie o úlohe
Viewport
Obrazovku predstavuje okno, v ktorom sa počas celej simulácie zobrazuje grafický model hory
a ostatných objektov (horolezci, tábory, ...). V okne sa zobrazuje priebeh simulácie a slúži pre
interakciu používateľa s objektmi.
Úspech
121
Obrazovka sa zobrazuje po úspešnom konci horolezeckej výpravy. Zobrazuje oznam o úspechu
horolezeckej výpravy. Po stlačení tlačidla OK sa ukončí simulácia.
Neúspech
Obrazovka sa zobrazuje po neúspešnom konci horolezeckej výpravy. Zobrazuje oznam o neúspechu
horolezeckej výpravy. Po stlačení tlačidla OK sa ukončí simulácia.
5.11.5 MessageBoxPočas simulácie môže dôjsť k rôznym udalostiam. Používateľ bude o týchto udalostiach informovaný
pomocou MessageBox-u.
Bude to informatívne okno, ktoré zobrazí informáciu o udalosti, opýta sa používateľa na ďalší
postup a bude čakať na potvrdenie. Používateľ zodpovie otázku stlačením jedného z tlačidiel. Otázky
budú formulované tak, aby bolo možné na ne odpovedať áno alebo nie.
Ovládacie prvky:
Tlačidlo Áno – kladne odpovie na položenú otázku
Tlačidlo Nie – záporne odpovie na položenú otázku
obr. 46 Obrazovka MessageBox
5.11.6 O aplikáciiPlávajúce okienko, ktoré bude zobrazovať informácie o aplikácii. Vyvolané bude z hlavného menu
stlačením tlačidla O aplikácii.
Ovládacie prvky:
žiadne – zatvárať sa bude tlačidlom X vpravo hore
122
obr. 47 Obrazovka O aplikácii
123
6 Zmeny špecifikácie, priority riešenia
6.1 Zmeny v špecifikáciiŠpecifikácia zostala viac menej bez zmeny. Zmenilo sa iba nasledujúce.
Pri implementácii nebude využitá knižnica MFC pre tvorbu okien s ovládacími prvkami pre
vstupno-výstupné operácie používateľa. Aplikácia bude vykresľovať aj používateľské rozhranie
s využitím funkcií grafickej knižnice OpenGl.
Ďalšou zmenou je fakt, že stav simulácie nebude možno ukladať, načítavať a ani vracať späť
kroky simulácie. Od týchto funkcií systému sme upustili vzhľadom na potrebu vytvorenia
komplikovaného a rozsiahleho modulu, ktorý by bol schopný vytvoriť konzistentný záznam o stave
simulácie a takisto tento záznam načítať a inicializovať potrebné štruktúry pre korektné nastavenie
uloženého stavu simulácie. Ako problém sa ukázali predovšetkým náhodné veličiny, ktoré nezaručujú
zopakovanie udalostí po opätovnom načítaní stavu simulácie a následného pokračovania simulácie.
Tento modul je možné dorobiť v budúcnosti.
124
6.2 Priority riešeniaVzhľadom na rozsah projektu, jeho charakter a to, že je vytváraný ako pilotná aplikácia takpovoediac
od základov, je nevyhnutné stanoviť priority pri riešení projektu, hlavne čo sa týka implementácie
produktu.
Charakteristické pre simulačné systémy je to, že ich vnútorné spracovanie je veľmi zložité,
pomerovo oveľa zložitejšie vzhľadom ku spracovaniu vstupov a výstupov. Preto sú stanovené tieto
priority pri vytváraní produktu:
1. Implementácia vnútornej simulačnej logiky – reprezentácia objektov a plánovanie udalostí
2. Vytvorenie jednoduchého, ale s realitou konzistentného modelu fyzikálnych apektov systému
3. Vytvorenie zapisovača údajov do externého log súboru – výpis informácii o vykonávaní
programu pre jednoduchšie spozorovanie a ladenie chýb
4. Zápis vstupných údajov do súborov a implementácia manipulácie so súbormi vstupných
údajov (pomocou XML)
5. Implementácia grafickej reprezentácie interaktívneho používateľského rozhrania
6. Vytvorenie testovacieho modelu hory pre simulovanie horolezeckého výstupu
7. Vytvorenie dokumentácie inžinierskeho diela, používateľskej príručky a diela o riadení
projektu
8. Vytvorenie aplikácie pre vytváranie modelov hôr pre simulácie horolezeckých výstupov
9. Implementácia textového informačného modulu – informácie o priebehu simulácie
a vyhodnotenie priebehu horolezeckého výstupu
10. Obohatenie simulácie o zvukové efekty
11. Obohatenie simulácie o multimediálne informácie – zobrazenie videí a animácií
125
7 Implementácia
7.1 Výber implementačného jazyka a prostredia Vzhľadom na využívané knižnice bol ako implementačný jazyk zvolený jazyk C++. Systém bol
implementovaný v prostredí Microsoft Visual Studio .NET 2005 Team Suite so Service Pack 1, pod
operačným systémom Windows XP Professional SP2.
7.2 Opis realizácie Pri realizácii implementácie navrhnutej aplikácie boli využité nasledovné knižnice:
OGRE 1.4.0 – grafický engine pre vykresľovanie scén
CEGUI 0.5 – knižnica pre vytváranie „windows-like“ okienok a kontrolných prvkov pod
OpenGl
Xerces 2.7.0 – knižnica pre parsovanie, generovanie, manipulovanie a validáciu XML 1.0
dokumentov
Tieto uvedené knižnice v niesli do návrhu rôzne špecifiká (hlavne knižnica OGRE), pričom však
značne uľahčili implementáciu navrhnutej aplikácie.
Aplikácia bola navrhnutá tak, že ju bolo možné rozdeliť do určitých celkov, ktoré sú opisované
v jednotlivých kapitolách podrobného návrhu. To umožnilo, aby každú časť implementovali členovia
tímu viac-menej samostatne a nezávisle na sebe.
Implementácia jednotlivých tried je podrobne opísaná v technickej dokumentácii.
7.3 OhraničeniaSoftvér
Vzhľadom na to, že aplikácia využíva funkcie windows.h, a to hlavne pre prácu v systéme súborov,
aplikáciu je možné spustiť iba pod operačným systémom Windows. Kvôli nainštalovaným súčastiam
sa odporúča systém Windows XP a novšie.
Pre prípadnú úpravu a rozširovanie aplikácie je nutné mať nainštalovanú knižnice Ogre 1.4.0 a CEGUI
0.5.
Hardvér
Minimálna konfigurácia PC:
procesor – 2400MHz Pentium 3 alebo AMD Athlon XP a lepsie
operačná pamäť – 512 MB
miesto na disku – 120 MB
grafická karta – GeForce4 alebo ATI 7200, 32MB pamäte
zvuková karta DX9 kompatibilná
126
Odporúčaná konfigurácia PC:
procesor – 1800MHz Pentium 4 alebo AMD Turion a lepsie
operačná pamäť – 1024 MB
miesto na disku – 120 MB
grafická karta – GeForce6200 alebo ATI 9200, 64MB pamäte
zvuková karta DX9 kompatibilná
127
8 Technická dokumentáciaOpis jednotlivých komponentov a tried systému je uvedený v elektronickej podobe na priloženom
médiu v súbore technicka_dokumentacia.chm.
128
9 ZhodnotenieVzhľadom na rozsah a charakter projektu, a vzhľadom na to, že predmetom tvorby bola novo –
vytváraná aplikácia, sme nestihli vytvoriť produkt v rozsahu, v ktorom bol špecifikovaný.
Podarilo sa nám vytvoriť funkčnú aplikáciu simulujúcu horolezeckú výpravu v rozsahu,
danom prioritami v kapitole 6.2, po prioritu č. 7 (vrátane).
Najväčším nedostatkom je, že sa nám nepodarilo splniť prioritu č. 8 a vytvoriť tak aplikáciu
pre vytváranie modelov hôr pre simuláciu horolezeckých výstupov. Tento nedostatok obmedzuje
používanie vytvoreného produktu, nakoľko je prácne vytárať tieto modely „ručne“. Pozitívom však je,
že sa jedná o samostatnú aplikáciu a jej vytvorenie môže byť predmetom ďalšieho rozširovania
systému.
Čo sa týka obohatenia systému a multimediálne informácie (textové informácie, videá,
animácie, zvuky), ich neimplementovanie systému nijako nevplýva na funkčnosť systému. Ich budúca
implementácia vhodným spôsobom môže zvýšiť atraktivitu aplikácie.
Pri tvorbe softvérového systému v tíme sa jednotlivý členovia naučili pracovať v tíme, hlavne
čo sa týka koordinácie úsilia jednotlivcov a dôležitosti komunikácie. Pri riešení projektu hlavne
v druhom semestri členovia tímu narazili na problém vzájomného pochopenia myšlienok a pochopenia
častí systému iných členov tímu. Takisto narazili na problém pri integrácií jednotlivých subsystémov.
Tu sa ukázalo, že absencia sekvenčných diagramov robila problémy pri podrobnom návrhu systému,
hlavne rozhraní tried.
Ukázalo sa, že rozsah podrobného návrhu systému a jeho následnej implementácie je pomerne
veľký na to, aby bolo možné podrobne implementovať špecifikovaný systém za dodržania všetkých
postupov pri vývoji softvérového produktu v etape návrhu a implementácie. Týka sa to hlavne
používania metód a techník štruktúrovaného zápisu (UML), sledovania kvality a testovania.
Taktiež sa ukázalo resp. potvrdilo, že pre tento typ aplikácie nie je vhodné využívať procesy
RUP, oveľa vhodnejšie je postupovať podľa metodológie evolučného vývoja softvéru. Dôvodom je
hlavne fakt, že takýto systém nie je funkčný dovtedy, pokiaľ nie je vytvorený v podstate celý systém.
Pri evolučnom prístupe možno tento systém vytvárať postupne rozširovaním požiadaviek
a zvyšovaním podrobnosti realizácie jednotlivých častí. Ďalším dôvodom je vlastnosť tohto systému,
a to veľmi komplikované testovanie systému. Pri tomto type aplikácii možno logickú správnosť
simulácie otestovať až potom, čo je vytvorený celý systém – vnútorné spracovanie (logická vrstva) aj
rozhranie. Navyše pri simulácii obvykle vzniká obrovské množstvo stavov, možností a situácií, čo sa
dá len sotva pokryť testovaním, ak vôbec.
Napriek všetkým negatívam si členovia tímu odniesli s tímového projektu veľa cenných
skúseností a predstavu o tvorbe softvérového systému v tíme. Podstatné bolo hlavne uvedomenie si
nedostatkov v práci tímu.
129
V závere možno povedať, že sa podarilo vytvoriť funkčný produkt a do veľkej miery splniť
požiadavky uvedené v špecifikácii systému.
130
