Informační systém pro podporu organizace dětských táborů

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Informační systém pro podporu organizace dětských táborů BAKALÁŘSKÁ PRÁCE

Jakub Faltýnek

Brno, 2009

Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Vedoucí práce: Mgr. Luděk Bártek, Ph.D.

ii

Poděkování Rád bych poděkoval Mgr. Luďku Bártkovi, Ph.D., vedoucímu mé bakalářské práce, za vstřícnost při konzultacích a cenné rady, které mi při psaní této práce pomohly.

iii

Shrnutí Obsahem této práce je návrh a implementace informačního systému pro podporu organizace dětských táborů. V jednotlivých částech je postupně popsáno fungování dětského tábora a z toho plynoucí požadavky na informační systém. Dále je popsán návrh systému a jeho implementace, která je realizována pomocí programovacího jazyka Java a databáze Apache Derby.

iv

Klíčová slova Informační systém, dětský tábor, UML, Java, Apache Derby

v

Obsah Úvod . . . . . . . . . . . . . . . . . . . . . . . . Struktura a fungování dětského tábora . . . . . . . . . . 2.1 Osoby na táboře . . . . . . . . . . . . . . . . . 2.1.1 Táborníci . . . . . . . . . . . . . . . . 2.1.2 Vedoucí . . . . . . . . . . . . . . . . . 2.2 Táborový den . . . . . . . . . . . . . . . . . . 2.3 Hry a táborové bodování . . . . . . . . . . . . . . 3 Návrh systému . . . . . . . . . . . . . . . . . . . . 3.1 Požadavky na systém . . . . . . . . . . . . . . . 3.1.1 Požadované vlastnosti . . . . . . . . . . . . 3.1.2 Požadované funkce . . . . . . . . . . . . . 3.2 Jazyk UML . . . . . . . . . . . . . . . . . . . 3.3 Diagram případů užití . . . . . . . . . . . . . . . 3.4 Diagram tříd . . . . . . . . . . . . . . . . . . . 3.4.1 Popis diagramu tříd navrženého systému . . . . . 3.5 Entitně-relační diagram . . . . . . . . . . . . . . 3.5.1 Popis entitně-relačního diagramu navrženého systému 3.6 Návrh grafického uživatelského rozhraní . . . . . . . . 4 Implementace . . . . . . . . . . . . . . . . . . . . 4.1 Použité technologie . . . . . . . . . . . . . . . . 4.1.1 Java . . . . . . . . . . . . . . . . . . . 4.1.2 Apache Derby . . . . . . . . . . . . . . . 4.2 Vývojové prostředí a použité nástroje . . . . . . . . . 4.2.1 Netbeans . . . . . . . . . . . . . . . . . 4.2.2 Toad Data Modeler . . . . . . . . . . . . . 4.3 Programování aplikace . . . . . . . . . . . . . . . 4.3.1 Aplikační logika systému . . . . . . . . . . . 4.3.2 Grafické uživatelské rozhraní . . . . . . . . . 4.4 Popis vytvořené aplikace . . . . . . . . . . . . . . 4.4.1 Obsah adresáře aplikace . . . . . . . . . . . 4.4.2 Práce s aplikací . . . . . . . . . . . . . . 4.5 Hodnocení uživatelů . . . . . . . . . . . . . . . . 4.6 Možnosti rozšíření do budoucna . . . . . . . . . . . 5 Závěr . . . . . . . . . . . . . . . . . . . . . . . . Literatura . . . . . . . . . . . . . . . . . . . . . . . . A Obsah CD . . . . . . . . . . . . . . . . . . . . . .

1 2

1

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

. .

. . . . . .

. . .

. . . .

. . . . . . . .

. . . . . .

. .

. . . . .

. . . .

. . .

. . . . . . . .

. . .

. . .

. . .

. . . .

. . .

. . . .

.

. . . . . .

. . . . . .

.

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

. . . . .

. . . .

. . .

. . . . . .

.

. . . . . . . . .

. . . . .

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

. . . . .

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

.

. . . .

. . .

. . . .

2 4 4 4 5 6 7 8 8 8 9 10 11 13 13 17 18 22 23 23 23 24 24 25 25 26 26 27 27 27 28 31 31 32 33 34

Kapitola 1

Úvod Dětské tábory byly a stále jsou pro mnoho dětí nedílnou součástí prázdnin. V současnosti je to pro nemalou část z nich jediný týden nebo dva v roce strávené mimo moderní civilizaci a bez vymožeností dnešní doby – televize, počítačů, mobilních telefonů či hudebních přehrávačů. Měl by to být čas, kdy mají šanci poznat se i z jiné stránky, naučit se něco nového, co se ve škole nedozví, dokázat překonat sami sebe. Hlavním cílem táborových vedoucích by ovšem měla být snaha ukázat dětem jak žít dobře a ohleduplně k ostatním lidem, přírodě a také sami k sobě a dále učit se s dětmi dobrým návykům a vlastnostem a zdokonalovat je. Nejlepší cestou ke splnění tohoto nesnadného úkolu je trávit s dětmi v průběhu tábora co nejvíce času a opravdu se zajímat o jejich radosti i starosti. To však na táborech zdaleka nebývá pravidlem. Vedoucí mají často spoustu práce, chystají program nebo k němu shání potřebné věci, v horším případě jsou někde jen tak schovaní, aby se dětem nemuseli věnovat. Zlepšit tuto situaci je jedním z cílů této práce. Implementovaný systém by měl ušetřit čas a práci vedoucímu, který se na táboře stará o věci, jako je rozdělování táborníků do družinek nebo bodování her. Připočtení bodů do bodování, úprava pořadí, či příprava různých seznamů pro tisk zabírá netriviální množství času, což by se mělo díky novému systému zlepšit a vedoucí pak bude moci trávit více času s dětmi než u počítače. Cílem je také navrhnout a implementovat funkce systému, které usnadní registraci dětí na tábor, umožní snadno ukládat a měnit údaje o dětech, vedoucích i táborových hrách. V neposlední řadě je snahou vytvořit uživatelsky přívětivou aplikaci, která se bude v praxi snadno používat. Tento úvod je první kapitolou celé práce. Ve druhé kapitole je popsáno, jak dětský tábor funguje. To je důležité vědět vzhledem k následnému navrhování systému. Nejdříve jsou zmíněny osoby, jež se tábora účastní (táborníci, vedoucí). Následuje popis běžného táborového dne, kde je uvedeno, kdy probíhají jaké aktivity a také kdy a jak bude možné využít nový systém. Poslední část je věnována hrám, které jsou na táboře jednou z hlavních částí programu. Je zde také vysvětleno, jak funguje táborové bodování. Třetí kapitola zachycuje návrh systému. Nejprve jsou zde shrnuty všechny požadavky na systém. Následuje krátké seznámení se s jazykem UML a poté jsou zobrazeny a vysvětleny dva diagramy tohoto jazyka. Prvním je diagram případů užití, který zachycuje, co všechno může uživatel se systémem provádět. Druhý je pak diagram tříd, jenž popisuje statickou strukturu systému a zobrazuje jednotlivé třídy, které jsou poté implementovány. Další podkapitolou je návrh datové struktury systému pomocí entitně-relačního diagramu. Zde jsou zachyceny a popsány všechny tabulky databáze, kde budou uložena všechna data. V závěru kapitoly je také

2

1. ÚVOD několik informací o návrhu grafického uživatelského rozhraní. Čtvrtá kapitola je věnována implementaci systému. Na začátku jsou popsány vybrané technologie, které byly použity při tvorbě aplikace a také zmíněno vývojové prostředí a nástroje, které byly při práci využívány. Dále je v této kapitole zachyceno, jak probíhalo samotné programování. Následuje popis vytvořené aplikace, kde je nejprve uvedeno, co všechno se nachází v adresáři aplikace, poté je popsána práce s ní a její vzhled je zde zachycen na několika obrázcích. Předposlední částí této kapitoly je hodnocení aplikace uživateli, jsou zde také krátce zachyceny jejich připomínky a návrhy. V závěrečné části jsou uvedeny možnosti rozšíření aplikace do budoucna. Poslední kapitolou je závěr, kde jsou stručně shrnuty výsledky celé práce.

3

Kapitola 2

Struktura a fungování dětského tábora K vytvoření kvalitního informačního systému, který bude pro vedoucí přínosem, je třeba nejdříve se seznámit s tím, jak běžný dětský tábor funguje. Musíme vědět, jací lidé a s jakými funkcemi se ho účastní, znát aktivity, které na táboře probíhají, ať už se jedná o každodenní činnosti nebo o události výjimečné. Z těchto znalostí potom můžeme odvodit požadavky, které by měl nový systém splňovat. V této kapitole se vychází především z vlastních táborových zkušeností a také z dokumentu Táboření s Kristem [1], ve kterém je velmi dobře popsáno, jak by měl správný tábor fungovat.

2.1 Osoby na táboře Tou nejdůležitější součástí každého tábora jsou lidé. Tábor, kde by chyběli táborníci nebo vedoucí si snad ani nejde představit. Často je však potřeba i dalších lidí, někdo se musí starat o kuchyni, nezbytný je také zdravotník. Pokud tyto funkce nemohou zastávat vedoucí, je nutné najít ochotné lidi, kteří se toho dokážou ujmout. Od počtu osob, které se tábora účastní, se odvíjí celkový charakter tábora. Jinak probíhá tábor, kde je 10 dětí a 10 vedoucích, jinak takový, kde je táborníků osmdesát a pět lidí, kteří je mají vést, a jinak tábor s šedesáti čtyřmi dětmi a dvacítkou vedoucích. Podstatné je, aby byl počet vedoucích přiměřený vzhledem k počtu dětí. Ve výše uvedeném prvním případě se bude polovina vedoucích nudit, ve druhém naopak bude těžké děti uhlídat. V praxi se ukazuje jako nejlepší poměr uvedený v posledním případě, kdy na jednoho vedoucího připadají asi tři děti. Táborníci a vedoucí, dvě nejpodstatnější skupiny osob na táboře, jsou dále popsány podrobněji a je stručně uvedeno, jaké funkce by u nového systému ocenily nejvíce.

2.1.1 Táborníci Jako táborníky si v případě dětského tábora představíme děti ve školním věku, existují však také jak tábory pro děti mladší, na které mohou jet děti samy nebo se svými rodiči, tak tábory či akce podobného rázu pro dospívající nebo i dospělé. Podle věku táborníků, jejich počtu, pohlaví, na základě jejich znalostí nebo zaměření se určuje, co bude náplní tábora, jaké hry se budou hrát, na jak velké túry se může jít, kolik hodin musí táborníci každý den spát a spousta dalších věcí. Jen těžko by šlo vydat se s osmiletými dětmi na celodenní pochod nebo naopak hrát obyčejnou honičku s adolescenty a přikazovat jim být každý den v devět hodin v posteli.

4

2. STRUKTURA

A FUNGOVÁNÍ DĚTSKÉHO TÁBORA

Je velmi výhodné a užitečné rozdělit táborníky na začátku celého tábora do menších skupin. Každá taková skupinka má potom jednoho vedoucího, který se o ni více zajímá a stará. Členové se více poznají a každý má tak větší šanci najít si alespoň několik nových kamarádů. Skupinky spolu soutěží v táborových hrách, střídají se v různých službách, také spolu sedí při jídle. Důležité je vytvořit skupinky vyrovnané jak po stránce fyzických sil, tak také na základě vědomostí. Již z tohoto stručného popisu vyplývají některé požadavky na to, co by měl zvládat nový systém. Základem je samotná registrace táborníků spolu s uložením důležitých informací o nich, dále mimo jiné možnost rozdělit táborníky do jednotlivých skupinek a ty mít také možnost vytvářet či upravovat a další funkce, které jsou v systému implementovány a popsány později.

2.1.2 Vedoucí Vedoucí jsou druhou podstatnou skupinou osob na každém táboře. Hlavně na nich záleží, jak se dětem bude tábor líbit a s jakým pocitem budou odjíždět. Velmi důležité je tvořit dobrý kolektiv a být s každým zadobře, protože i jedna rozhádaná dvojice může být velkým problémem. Aby tábor probíhal hladce a všechno fungovalo co nejlépe, je potřeba, aby každý vedoucí plnil funkce a úkoly, které mu byly svěřeny. Existuje několik rolí, ve kterých může vedoucí na táboře být a které mají svá specifika. Ty jsou dále popsány o něco podrobněji. 

hlavní vedoucí – člověk, který stojí v čele celého tábora. Řídí a usměrňuje ostatní vedoucí, má při rozhodování poslední slovo. Měl by mít přehled o všem, co se na táboře děje. Je zodpovědný za všechno, co se stane. Nemá většinou na starosti žádnou konkrétní část programu ani funkce, ale musí dohlížet na to, aby bylo vše dobře zorganizované a aby každý plnil to, co má.



sekretářka – osoba, pro jejíž potřebu je nový systém hlavně určen. Jejím úkolem je rozdělovat táborníky do skupinek, vytvářet nejrůznější seznamy, aktualizovat počet získaných bodů každého táborníka či vytvářet pořadí jednotlivců nebo skupinek. Vedoucí zastávající tuto funkci tráví mnoho času v táborové kanceláři u počítače. Vytvořený systém by měl tuto skutečnost alespoň částečně zlepšit.



kmotři – vedoucí, kteří mají na starosti jednotlivé skupinky. Tráví s nimi více času než jiní vedoucí, snaží se co nejlépe poznat každého člena ve skupince, pomáhají, pokud je to zapotřebí, nebo řeší případné problémy.

5

2. STRUKTURA 

A FUNGOVÁNÍ DĚTSKÉHO TÁBORA

zdravotník – člověk, který hlavně na větších táborech nesmí chybět. Musí mít přehled o zdravotním stavu a omezeních každého táborníka. Měl by být schopen rozpoznat a léčit nemoci a zranění, ke kterým může na táboře dojít. Často tuto funkci vykonává vedoucí, který prošel zdravotnickým kurzem, ideální je však mít v týmu přímo lékaře nebo zdravotní sestru.

Další funkce, jež může vedoucí na táboře plnit, se již vztahují spíše k samotnému programu tábora, a proto je zde nebudu podrobněji popisovat. Každému vedoucímu by měl nový systém sloužit přinejmenším nepřímo, pokud budou chtít po sekretářce seznam táborníku, rozdělení starších a mladších chlapců a děvčat nebo když si bude například zdravotník chtít projít táborníky a jejich zdravotní omezení.

2.2 Táborový den Každý den na táboře (až na několik výjimek, jako je výlet či celodenní hra) má svůj řád, pevné části programu, které nesmí chybět. Průběh jednoho klasického táborového dne je dále v krátkosti popsán včetně toho, kdy se využije informační systém a k jakým účelům. Den začíná ranním budíčkem, po kterém se táborníci chystají na rozcvičku, případně se převlékají do plavek, pokud po rozcvičce následuje ranní umytí v potoce. Na signál se řadí před svými stany a poté následuje již zmíněná rozcvička a případné mytí. Dalším bodem je ranní hygiena a příprava na prohlídku pořádku, kterou po uplynutí několika minut provádí vedoucí. Poté je na řadě snídaně. Ranní a dopolední blok je rozdělen slavnostním ranním nástupem. Zde se oznamují všechny důležité věci, jako je informace, která skupinka bude mít po celý den službu, případné narozeniny, hlášení noční hlídky, je prozrazen program který bude dopoledne následovat. To vše je shrnuto a zaznamenáno v ranním rozkazu, který systém umí vygenerovat a následně vytisknout a usnadní tak práci sekretářce, která má za úkol tento rozkaz připravovat. Dopoledne je pak vyplněno hrou nebo jinou aktivitou, například brigádou. Pokud je hra bodována, je možné hned po jejím skončení zapsat do systému body, které byly jednotlivými táborníky či skupinkami získány. V poledne je pro všechny nachystán oběd a po něm následuje polední klid, což je doba určená pro odpočinek a různé klidné aktivity jako je hraní stolních her nebo čtení knížky. Během toho je už vedoucími chystán odpolední program, po němž následuje sportovní blok. Zde může být systém využit pro vytvoření seznamu starších a mladších chlapců a děvčat, podle nějž jsou pak táborníci rozděleni. V těchto skupinách pak plní jednotlivé disciplíny. Po ukončení sportování je na řadě hygiena, po níž probíhá večerní klid sloužící opět hlavně k odpočinku. Poté nesmí chybět večeře a po ní večerní nástup, kde se hodnotí uplynulý den a vyhlašuje se například pořadí her, které dopoledne či odpoledne proběhly. K tomu se opět

6

2. STRUKTURA

A FUNGOVÁNÍ DĚTSKÉHO TÁBORA

využije systém, který sestaví a vytiskne pořadí hry a celý večerní rozkaz, kde lze najít noční hlídku na následující noc či službu na další den. Poslední částí dne je večerní program, který může probíhat formou zábavných soutěží, noční hry nebo posezením u táborového ohně.

2.3 Hry a táborové bodování Celotáborová soutěž dává každému táboru ten správný náboj. Který táborník by si nepřál být na konci tábora u slavnostního ohně vyhlášen vítězem celého bodování, jenž si může vybrat za odměnu nějakou lákavou cenu? Nenajde se asi moc takových, kteří by nechtěli uspět. Proto je tábor vyplněn nejrůznějšími aktivitami, při nichž se táborníci snaží získat co nejvíce bodů jak pro sebe, tak pro svou skupinku, aby na konci dosáhli na ten nejvyšší stupeň. První velkou skupinou činností, které se bodují, jsou samozřejmě hry. Ty se dají rozdělit na hry zaměřené na fyzickou stránku a na ty, u kterých se musí hlavně přemýšlet. Do první kategorie spadají nejrůznější běhací hry v lese či na louce, kde mají táborníci úkol něco hledat nebo sbírat, a také akční hry, ve kterých je například úkolem porazit zlého nepřítele v souboji o nějaké území. U her logických je stěžejním bodem luštění tajné šifry nebo i vymýšlení různých básniček ze zadaných slov. V jedné hře se pochopitelně mohou objevit prvky z první i druhé kategorie, je ale důležité, aby byly oba typy her na táboře zastoupeny rovnoměrně. Další činností, kterou je možné bodovat, jsou bloky, kdy se táborníci učí novým dovednostem v různých oblastech, jako je obratnost, bystrost, příroda či umění. Tato aktivita se v průběhu tábora několikrát opakuje. Příležitostí k bodování jsou také zkoušky, které jsou různě nazývány, nejznámějším označením jsou asi bobříky. Táborník tak může být oceněn za absolvování stezky odvahy, za prokázání statečnosti nebo za stálý pořádek ve svém stanu. Na táboře se soutěží ve dvou kategoriích. Každý táborník bojuje sám za sebe v bodování jednotlivců, skupinky mají také své vlastní bodování. Celkový počet bodů každé skupinky je pak vypočítán jako součet získaných bodů všech členů skupinky a také bodů, které vybojovala skupinka ve hrách, kde nesoutěžili jednotlivci, ale skupinky jako celek. Právě bodování jednotlivých aktivit a vytváření pořadí v obou kategoriích je jedna z věcí, kterou by měl nový systém nejvíce usnadnit. Přínosná bude jistě i možnost vytisknutí pořadí jednotlivců i skupinek, které je na táboře pravidelně vyvěšováno a bedlivě sledováno všemi táborníky.

7

Kapitola 3

Návrh systému Samotné tvorbě informačního systému musí předcházet období, kdy je cílem navržení struktury budoucího systému, jeho chování a funkce tak, aby byly splněny všechny požadavky, jež jsou na systém kladeny uživateli, kteří jej budou používat. Následující podkapitoly jsou tedy věnovány návrhu systému. Nejdříve je popsáno, co všechno se očekává od nového systému, jaké by měl mít vlastnosti a implementované funkce. Dále je pomocí jazyka UML vytvořen a podrobněji popsán diagram tříd a diagram užití budoucího systému. Poslední část je věnována entitně-relačnímu diagramu, který je využit při vytváření databáze systému.

3.1 Požadavky na systém Požadavky na systém byly sepsány hlavně na základě zkušeností s pozicí sekretáře, tedy člověka, pro kterého je nový systém primárně určen. Proběhla také konzultace s vedoucí, která funkci sekretářky vykonává v současnosti. Informační systém by měl na táboře zrychlit a usnadnit práci v několika oblastech, jež má táborová sekretářka na starosti. Očekáván je systém, který bude rychle a spolehlivě fungovat na drtivé většině současných počítačů. Měl by umožňovat registraci dětí na tábor, ukládání důležitých údajů o tábornících do databáze, podobně by měl zacházet i s vedoucími. K dalším požadovaným funkcím patří ukládání her do databáze, vytváření táborových skupinek, zařazování táborníků do nich, generování denních rozkazů na základě zadaných informací a v neposlední řadě co nejjednodušší správa táborového bodování.

3.1.1 Požadované vlastnosti Nejdůležitější požadovanou vlastností nového systému je uživatelská přívětivost. Každému uživateli by se mělo s aplikací pracovat pohodlně, práce by měla být rychlá a efektivní. Uživatel by měl aplikaci kompletně pochopit a naučit se používat zanedlouho po prvním spuštění. Pro dosažení této vlastností je klíčový dobrý návrh grafického uživatelského rozhraní. Bezproblémové fungování systému v různých operačních systémech a jejich verzích je další vlastnost, kterou by budoucí uživatelé ocenili, stejně jako nevelké nároky na výkon počítače.

8

3. NÁVRH SYSTÉMU Poslední vlastností, jež má jistě své výhody, je přenositelnost systému. Tedy možnost pracovat se systémem například na počítači doma při přípravě tábora a poté jej jednoduše přenést na počítač, který je přímo v místě, kde tábor probíhá, a který se pro práci na táboře používá.

3.1.2 Požadované funkce Zde je uveden seznam všech požadovaných funkcí, které jsou poté implementovány v novém systému. Funkce jsou rozděleny do kategorií podle oblasti, do níž spadají. Práce s turnusy (Pojmem turnus je označován takový tábor, který je součásti určité série například čtyř táborů. Potom mluvíme o prvním až čtvrtém turnusu.)  vytvoření nového turnusu  změna údajů o turnusu  odstranění existujícího turnusu  vybrání turnusu pro další práci Práce s táborníky  registrace nového táborníka na turnus  změna údajů o táborníkovi  odstranění registrovaného táborníka z turnusu  rozdělení táborníků podle věku na starší a mladší  tisk rozdělených skupin Práce s vedoucími  registrace nového vedoucího na turnus  změna údajů o vedoucím  odstranění registrovaného vedoucího z turnusu Práce se skupinkami  vytvoření nové skupinky na turnusu  změna údajů o skupince  odstranění skupinky z turnusu  zařazení táborníků do skupinek  vypsání táborníků i s jejich skupinkami  tisk seznamu skupinek a jejich členů

9

3. NÁVRH SYSTÉMU Práce s hrami  vytvoření nové hry na turnuse  změna údajů o hře  odstranění hry z turnusu Tvorba denního táborového rozkazu  přidání dne a potřebných údajů do databáze  změna údajů o dni  odstranění dne z turnusu  vygenerování denního rozkazu podle vybraného dne  tisk denního rozkazu Správa táborového bodování  obodování hry  vytvoření a tisk pořadí hry  vytvoření a tisk pořadí jednotlivců  vytvoření a tisk pořadí skupinek Práce s databází  odstranění táborníka, vedoucího nebo hry z databáze  obnovení celé databáze

3.2 Jazyk UML UML (Unified Modeling Language) je grafický jazyk pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů. Umožňuje modelovat jednoduché i složité aplikace pomocí stejné formální syntaxe [2]. UML podporuje objektově orientovaný přístup k analýze, návrhu a popisu programových systémů. S vývojem jazyka začali v roce 1994 Grady Booch a Jim Rumbaugh. Cílem bylo spojit do té doby nejlepší metodologie v oblasti OOAD (Object Oriented Analyses and Design). Jazyk se dále vyvíjí a v současnosti se používá verze 2.0. Při návrhu systému pomocí UML můžeme použít mnoho diagramů, které jazyk definuje. Diagramy jsou rozděleny do dvou skupin. Tou první jsou diagramy struktur, jejichž cílem je zobrazit statickou strukturu modelovaného systému a patří sem:   

diagram tříd diagram vnitřní struktury diagram objektů

10

3. NÁVRH SYSTÉMU   

diagram komponent diagram balíčků diagram nasazení

Druhou skupinou jsou diagramy chování, jež zachycují dynamické aspekty modelovaného systému. Do této skupiny jsou řazeny:    

diagram případů užití diagram aktivit stavový diagram diagramy interakce o sekvenční diagram o diagram komunikace o diagram interakcí o diagram časování

V této práci jsou použity dva diagramy, po jednom z každé skupiny, konkrétně diagram případů užití a diagram tříd.

3.3 Diagram případů užití Diagram případů užití (Use Case Diagram) [3] zobrazuje chování systému z hlediska uživatele. Zachycuje všechna možná užití systému účastníkem. Každý případ užití má své jméno. Účastník je kdokoliv nebo cokoliv, co se systémem komunikuje. Může jím být tedy člověk, ale také nějaký hardware či jiný systém. Diagram zobrazující nový táborový informační systém obsahuje pouze jednoho účastníka, a to táborovou sekretářku, která pracuje s celým systémem, a je proto účastníkem všech případů užití. Každý případ užití je zobrazen jednou bublinou s příslušným jménem, která je spojena s odpovídajícím účastníkem. Jednotlivá jména jasně určují podstatu každého případu užití, proto není nutná další textová specifikace a vysvětlování. Diagram očividně odpovídá seznamu požadovaných funkcí, což znamená, že v systému tyto funkce opravdu nebudou chybět. Závislost, která je v diagramu značena přerušovanou čarou s šipkou a stereotypem <<extend>>, označuje skutečnost, že případ užití může být rozšířen o chování toho případu užití, ze kterého šipka vychází. V konkrétním případě to znamená, že zobrazení pořadí jednotlivců, skupinek, či jiných informací je rozšířeno o možnost vytisknutí těchto informací. Kvůli přehlednosti není označení <<extend>> uvedeno u každé šipky.

11

3. NÁVRH SYSTÉMU Táborový informační systém

<<extend>>

<<extend>> <<extend>>

<<extend>>

<<extend>>

Obrázek 3.1: Diagram případů užití

12

3. NÁVRH SYSTÉMU

3.4 Diagram tříd Diagram tříd [4] slouží k zobrazení statické struktury systému. Popisuje jednotlivé třídy a vztahy mezi nimi. Třídou rozumíme množinu objektů, jež mají stejné atributy, metody a vztahy.  Atributy charakterizují vlastnosti objektu a vypovídají o jeho stavu.  Metody jsou funkční složkou objektu, která zajišťuje jeho chování.  Vztahy mezi třídami popisují, jak jsou na sobě třídy závislé a jak spolu mohou komunikovat. Můžeme je rozdělit na několik typů: o asociace – obecný vztah mezi prvky modelu, specifikuje spojení mezi jejich instancemi o agregace – forma asociace, vyjadřuje vztah části a celku o kompozice – silnější vazba než agregace, třída reprezentující část nemůže existovat bez třídy představující celek o dědičnost – třída (potomek) dědí atributy a metody třídy, která je jejím předkem o závislost – vztah mezi dvěma elementy, kdy změna nezávislého ovlivní element závislý o realizace – vztah mezi třídou a jejím rozhraním Počet objektů, které se v libovolném okamžiku účastní vztahu, se označuje jako kardinalita (násobnost) vztahu. Udává se buď rozsah hodnot, nebo jedna přesná hodnota. Pro neomezený maximální počet se používá znak *. Model může obsahovat několik typů tříd. Jedním jsou třídy, jež reprezentují objekty nesoucí informace a uložená data. Označují se stereotypem <<entity>>. Dalšími typy jsou třídy provádějící různé činnosti a operace, jež jsou značeny stereotypem <> a třídy, které jsou využívané pro komunikaci systému a uživatelů a které se označují <>.

3.4.1 Popis diagramu tříd navrženého systému Diagram tříd popisující nový systém zachycuje aplikační logiku systému. Obsahuje tedy pouze třídy typu <<entity>> a <>. Třídy reprezentující uživatelské rozhraní stojí až nad aplikační logikou, neposkytují žádné další funkce, a proto nejsou v diagramu zahrnuty. Díky tomuto rozdělení tříd je možné implementovat různé typy uživatelského rozhraní (např. desktopové, webové) bez nutnosti upravovat nějakým způsobem všechny třídy celého systému. Jedinou přidanou funkcionalitou na úrovni uživatelského rozhraní je tisk, který je řešen pomocí metod pro tisk grafických komponent, což považuji za nejvýhodnější řešení. Aby šlo umístit diagram do této práce na jedinou stránku, jsou v něm vynechány některé součásti, které jsou zobrazeny na diagramu obsaženém na CD. Chybí tu atributy a metody tříd, není zde také číslicí označena kardinalita vztahu, jestliže je rovna 1.

13

3. NÁVRH SYSTÉMU V diagramu najdeme tři typy vztahů. Asociace je zobrazena plnou čarou s šipkou a doplněna stereotypem <<work>>, jež značí, že objekty třídy, ze které vztah vychází, pracuje pomocí svých metod hlavně s objekty třídy, do které šipka směřuje. Podobně závislost je značena přerušovanou čarou s šipkou u třídy, jejíž změna ovlivní třídu závislou, a stereotypem <<use>>. Posledním vztahem, který lze v diagramu nalézt, je agregace, značená plnou čarou a šipkou u třídy, která je v daném vztahu části a kosočtvercem u třídy představující celek. Diagram na CD obsahuje u agregací i informaci o tom, který atribut v celku reprezentuje danou část. Níže jsou popsány jednotlivé třídy a to, co mají v novém systému na starost. Třídy typu <<entity>>: Každý objekt všech tříd tohoto typu obsahuje atributy uchovávající informace o objektu a metody vracející hodnoty těchto atributů. Má také metody compareTo (slouží k porovnání s jiným objektem dané třídy) a toString (vypíše informace o objektu). 

Term – každý objekt této třídy reprezentuje jeden turnus. Kromě atributů uchovávajících informace o turnusu má také ty, jež reprezentují instance tříd spojených s touto třídou pomocí agregace. Obsahuje metody vracející hodnoty všech těchto atributů.



Child – třída reprezentující táborníka.



Instructor – třída reprezentující táborového vedoucího.



Group – třída reprezentující skupinku, do kterých jsou táborníci rozdělováni.



Game – třída reprezentující táborovou hru.



Day – třída reprezentující táborový den.

Třídy typu <>: 

Camp – třída reprezentující tábor. Obsahuje metody pro spojení s databází a pro veškerou práci s turnusy. Má atributy reprezentující instance tříd spojených s touto třídou pomocí agregace a také metody vracející hodnoty těchto atributů. Jako všechny následující třídy má atribut connection, jež je využíván při komunikaci s databází.

14

3. NÁVRH SYSTÉMU 

CampChildRegister – třída obsahující metody pro práci s táborníky v rámci celého tábora. Táborník je registrován nejdříve na tábor a poté na konkrétní turnus. To znamená, že táborník zůstává v táborové databázi i po odhlášení z turnusu nebo po zrušení daného turnusu a je poté usnadněna třeba jeho registrace na jiný turnus. Tato třída tedy zajišťuje operace s táborníky, jež jsou nezávislé na určitém turnusu (např. změna bydliště, emailu a dalších údajů, odstranění z databáze atd.). Podobně fungují i následující dvě třídy.



CampInstructorRegister – obsahuje metody pro práci s vedoucími v rámci celého tábora.



CampGameRegister – obsahuje metody pro práci s hrami v rámci celého tábora.



TermChildRegister – obsahuje metody pro práci s táborníky v rámci turnusu.



TermInstructorRegister – obsahuje metody pro práci s vedoucími v rámci turnusu.



TermGameRegister – obsahuje metody pro práci s hrami v rámci turnusu.



TermGroupRegister – obsahuje metody pro práci se skupinkami v rámci turnusu.



TermDayRegister – obsahuje metody pro práci se dny v rámci turnusu.



TermCompetition – obsahuje metody zajišťující správu táborového bodování jednotlivců.



TermGroupCompetition – obsahuje metody zajišťující správu táborového bodování skupin.



SetParent – obsahuje metodu zajišťující správné nastavení informací o rodičích u každého táborníka.



SetCity – obsahuje metodu zajišťující správné nastaven údajů o městě a PSČ u každého táborníka a vedoucího.



CreateDatabase – umožňuje obnovení celé databáze.

15

3. NÁVRH SYSTÉMU

Obrázek 3.2: Diagram tříd

16

3. NÁVRH SYSTÉMU

3.5 Entitně-relační diagram Pomocí entitně-relačního diagramu je možné navrhnout datovou strukturu systému. Diagram je tvořen entitami (představují jednotlivé tabulky databáze) a vazbami, jež mezi nimi existují. Entita je objekt reálného či abstraktního světa a má určité vlastnosti, které se nazývají atributy. Ty reprezentují její vnitřní datovou strukturu. Atribut je vždy určitého typu (např. číslo, řetězec znaků, pravdivostní hodnota). Tento typ určuje přípustný obsah daného atributu. Některé atributy mají za úkol rozlišovat jednotlivé instance entity. Takový atribut se nazývá primární klíč a musí vždy nabývat nějaké hodnoty, která navíc musí být v rámci všech instancí entity unikátní. Jiné atributy mohou být cizím klíčem. Odkazují na instance některé jiné tabulky. Cizí klíče se tvoří na základě vazeb mezi tabulkami. Každá vazba má definovanou kardinalitu. Ta určuje, kolik instancí jedné entity může mít vztah s jakoukoliv instancí druhé entity. Uvádí se vždy minimální kardinalita, jež může nabývat hodnot 0 nebo 1, a maximální kardinalita, které může mít hodnotu 0 nebo N (nekonečno). Pokud jsou dvě entity spojeny vazbou, která má na obou koncích maximální kardinalitu N, je mezi nimi vytvořena nová entita označovaná jako vazební. Každá instance této entity je potom reprezentací vazby, kvůli níž vznikla. Vazby, které vzniknou při vytvoření vazební entity, není nutné popisovat, neboť jejich význam je dán definicí vazební entity. Aby po implementaci a při následném používání databáze nedocházelo k různým anomáliím a problémům při práci s daty v databázi, mělo by navržené schéma (všechny tabulky) splňovat jistá pravidla, která se nazývají normální formy (NF).

 1. normální forma – říká, že všechny atributy tabulky musí být atomické (dále nedělitelné). Hodnotou tedy nesmí být jakoby další tabulka.

 2. normální forma – tabulka musí být v 1. NF a každý atribut, který není primárním klíčem, musí být na primárním klíči úplně závislý. To znamená, že pokud by se primární klíč tabulky skládal z více než jednoho atributu, nesmí být ostatní atributy závislé jen na některém z nich, ale na všech.

 3. normální forma – tabulka musí být v 2. NF a žádný atribut, který není primárním klíčem, není na žádném klíči tranzitivně závislý. Tedy není závislý na nějakém atributu, jež je závislý na klíči, ale všechny atributy jsou přímo závislé na klíči. Další stupně normálních forem řeší situace, které se v této práci na modelu nevyskytují, a proto tu již nejsou popsány podrobně.

17

3. NÁVRH SYSTÉMU 3.5.1 Popis entitně-relačního diagramu navrženého systému Diagram obsahuje celkem 13 entit, z nichž 5 je vazebních. Ty jsou znázorněny obdélníky se zaoblenými rohy. Každá entita obsahuje seznam svých atributů, ve druhém sloupci jsou pak typy těchto atributů. Červeně označený atribut se symbolem červeného klíče označuje primární klíč dané entity, zelenou barvou jsou označeny cizí klíče. Pokud jsou vazební entity spojeny s jinou entitou vazbou, jež je zobrazena plnou čarou, pak je tato vazba popsána definicí vazební entity. Ostatní vazby jsou značeny přerušovanou čarou a číslem, pod kterým jsou níže popsány. Kardinalita rovna nule je znázorněna prázdným kolečkem, jednička je označena čárkou kolmou na vazbu a N je značeno rozvětvením vazby na jejím konci. Minimální kardinalita je značena dále od entity, maximální blíže k dané entitě. Jestliže je maximální kardinalita 1, pak tato skutečnost není v diagramu značena a u vazby najdeme pouze kardinalitu minimální. Následuje popis jednotlivých entit v diagramu znázorňujícím nový systém: 

child – instancí této entity je každé dítě, které je registrované v táborové databázi. Musí mít unikátní rodné číslo. Cizími klíči se odkazuje na entity parent a city.



instructor – instancí této entity je každý vedoucí registrovaný v táborové databázi. Musí mít unikátní rodné číslo. Cizím klíčem se odkazuje na entitu city.



parent – instancí této entity je každý rodič, jehož potomek je registrován v táborové databázi.



city – instancí této entity je každá obec či město, jež je trvalým bydlištěm táborníka registrovaného v databázi.



game – instancí této entity je každá hra, která je registrovaná v táborové databázi.



term – instancí této entity je každý turnus, který je registrován v táborové databázi.



group_in_term – instancí této entity je každá skupinka, která je registrovaná v určitém turnusu. Na příslušný turnus je odkazováno cizím klíčem. Stejně tak na vedoucího, jenž je kmotrem dané skupinky.



day_in_term – instancí této entity je každý den určitého turnusu. Na příslušný turnus je odkazováno cizím klíčem. Podobně na skupinky, které mají v daný den noční a denní službu, a na vedoucího, který má noční pohotovost.

18

3. NÁVRH SYSTÉMU Ostatní entity jsou vazební a jsou tedy popsány vztahem entit, jež spojují. Za lomítkem je potom uvedena kardinalita daného vztahu. 

child_in_term – instancí této entity je každá reprezentace vazby mezi entitami child a term ve smyslu: Dítě registrované na daném turnusu / 0,N : 0,N. Tento zápis znamená, že dítě může být registrované na 0 až N turnusech (podle 0,N za dvojtečkou) a že na turnusu muže být registrováno 0 až N dětí (podle 0,N před dvojtečkou).



instructor_in_term – instancí této entity je každá reprezentace vazby mezi entitami instructor a term ve smyslu: Vedoucí registrovaný na daném turnusu / 0,N : 0,N.



game_in_term – instancí této entity je každá reprezentace vazby mezi entitami game a term ve smyslu: Hra registrovaná na daném turnusu / 0,N : 0,N.



competition – instancí této entity je každá reprezentace vazby mezi entitami child_in_term, game_in_term a atributem points ve smyslu: Body získané daným táborníkem v dané hře / 0,1 : 0,N.



group_competition – instancí této entity je každá reprezentace vazby mezi entitami group_in_term, game_in_term a atributem points ve smyslu: Body získané danou skupinkou v dané hře / 0,1 : 0,N.

Následující popis každé z vazeb odpovídá vždy vazbě označené v diagramu příslušným číslem. 

vazba č.1 – Táborník je potomkem svého otce / 0,N : 0,1. Odkazem na otce je atribut father_id v tabulce child.



vazba č.2 – Táborník je potomkem své matky / 0,N : 0,1. Odkazem na matku je atribut mother_id v tabulce child.



vazba č.3 – Táborník bydlící v dané obci / 0,N : 0,1. Odkazem na obec je atribut city_id v tabulce child.



vazba č.4 – Vedoucí bydlící v dané obci / 0,N : 0,1. Odkazem na obec je atribut city_id v tabulce instructor.

19

3. NÁVRH SYSTÉMU 

vazba č.5 – Táborník je členem dané skupinky / 0,N : 0,1. Odkazem na skupinku je atribut group_in_term_id v tabulce child_in_term.



vazba č.6 – Vedoucí, který je kmotrem dané skupinky / 0,1 : 0,N. Odkazem na vedoucího je atribut instructor_in_term_id v tabulce group_in_term.



vazba č.7 – Skupinka mající daný den denní službu / 0,1 : 0,N. Odkazem na skupinku je atribut day_watch v tabulce day_in_term.



vazba č.8 – Skupinka mající daný den noční hlídku / 0,1 : 0:N. Odkazem na skupinku je atribut night_watch v tabulce day_in_term.



vazba č.9 – Vedoucí mající daný den noční pohotovost / 0,1 : 0,N. Odkazem na vedoucího je atribut instructor_night_watch v tabulce day_in_term.



vazba č.10 – Vedoucí mající na starost danou hru / 0,1 : 0:N. Odkazem na vedoucího je atribut instructor1 v tabulce game_in_term.



vazba č.11 – Vedoucí mající na starost danou hru / 0,1 : 0:N. Odkazem na vedoucího je atribut instructor2 v tabulce game_in_term.



vazba č. 12 – Skupinka registrovaná na daném turnusu / 0,N : 1,1. Odkazem na turnus je atribut term_id v tabulce group_in_term.



vazba č. 13 – Táborový den daného turnusu / 0,N : 1,1. Odkazem na turnus je atribut term_id v tabulce day_in_term.

20

3. NÁVRH SYSTÉMU

Obrázek 3.3: Entitně-relační diagram

21

3. NÁVRH SYSTÉMU

3.6 Návrh grafického uživatelského rozhraní Součástí této práce je i vytvoření desktopové aplikace pro nový systém, a proto je důležité dobře promyslet a navrhnout grafické uživatelské rozhraní, neboť je to jedna z nejdůležitějších věcí, na nichž závisí spokojenost uživatelů. Cílem je tedy navrhnout uživatelsky přívětivou aplikaci, kterou nebude těžké naučit se ovládat a s níž se bude snadno a rychle pracovat. Proto je třeba vzít při návrhu v potaz již existující aplikace, které uživatelé používají, a držet se zažitých zvyklostí. Menu by například mělo vypadat a fungovat tak, jako je tomu u většiny desktopových aplikací. Není tedy příliš dobré, aby bylo u jiného než horního okraje aplikace, nebo dokonce v aplikaci chybělo. Důležité je všechny položky menu správně rozčlenit do jednotlivých kategorií a podkategorií, aby se v něm dalo snadno orientovat. Po vybrání položky v menu by se mělo vždy objevit dialogové okno, ve kterém může uživatel najít požadované informace nebo provést to, co potřebuje. Každé takové okno by mělo být možné zavřít kromě klasického křížku v pravém horním rohu i tlačítkem pro to určeným. V hlavním okně aplikace by po celou dobu používání aplikace měl být zobrazen obsah databáze systému, aby uživatel viděl, co všechno je v databázi uloženo. Důležité je také zvolit vhodnou velikost i typ písma. Čím menší písmo, tím méně uživatelů text přečte, a čím bude písmo větší, tím složitěji půjde zobrazit na stránce všechny potřebné popisky a informace. Není ani dobré příliš experimentovat jak s barvou písma, tak s barevným provedením grafických komponent celé aplikace. Je třeba vždy brát v úvahu cílovou skupinu uživatelů. Je tedy správné, aby byly například ve výukovém programu pro malé děti pestřejší barvy než odstíny šedi, naopak takový program pro evidenci firemních zakázek asi nebude mít každou nabídku a tlačítko v jiné barvě. Uživatel by měl mít možnost změnit velikost okna aplikace tak, jak bude potřebovat pro svou práci. Pro případ zmenšení okna je třeba, aby byly součástí grafického rozhraní i vertikální a horizontální posuvník (scrollbar), které umožní zobrazit všechen obsah i v menším okně. Po vytvoření návrhu je dobré prodiskutovat jej s budoucími uživateli a vzít v potaz jejich smysluplné připomínky. Je snadnější pozměnit částečně návrh, než upravovat později již vytvořenou aplikaci, se kterou se uživatelům špatně pracuje.

22

Kapitola 4

Implementace Praktickou částí této práce je implementace systému v podobě desktopové aplikace. Náplní kapitoly je tedy popis této fáze vývoje. Výsledná aplikace je uložená včetně zdrojových kódů na CD, jež je přílohou práce. V následujících podkapitolách jsou nejprve popsány použité technologie, dále využívané vývojové prostředí a nástroje. Nechybí ani seznámení se s fungováním aplikace. Nakonec byla testována použitelnost aplikace několika uživateli a výsledky a některé poznatky jsou v práci zaznamenány.

4.1 Použité technologie Výběr programovacího jazyka a databáze byl ovlivněn jednak zkušenostmi s danými technologiemi a také vlastnostmi těchto technologií. Nakonec jsou pro implementaci použity programovací jazyk Java a databáze Apache Derby z důvodů, jež jsou dále popsány.

4.1.1 Java Java je objektově orientovaný programovací jazyk, rozsáhlá počítačová technologie a platforma, jež byla vyvinuta firmou Sun Microsystems a představena v roce 1995. V současnosti je Java jedním z nejpoužívanějších programovacích jazyků na světě. Celá platforma se dělí na tři části. První je Java Platform, Standard Edition [5], která je použita pro tvorbu tohoto systému, dalšími jsou Java Platform, Enterprise Edition, jež se využívá pro psaní podnikových aplikací, a Java Platform, Micro Edition, která je určena pro vytváření aplikací do mobilních zařízení [6]. Mezi základní vlastnosti a přednosti tohoto jazyka patří to, že je: 

jednoduchý – Java vychází z jazyka C++. Oproti němu však neobsahuje některé konstrukce, které způsobovaly při programování potíže, a přidává mnoho užitečných vlastností.



objektově orientovaný – obsahuje pouze osm primitivních datových typů, všechny ostatní typy jsou objektové.



nezávislý na architektuře – při kompilaci nevzniká strojový kód, ale pouze mezikód (bytecode). Ten je nezávislý na operačním systému

23

4. IMPLEMENTACE či architektuře. Program tak může pracovat na libovolném počítači, který má k dispozici Java Virtual Machine, což je interpret tohoto mezikódu. Jazyk umožňuje vytvářet a zpracovávat vícevláknové aplikace. Zajišťuje i jejich synchronizaci. Správa paměti je řízena garbage collectorem, který automaticky vyhledává již nepoužívané části paměti a uvolňuje je pro další použití. Pro vývoj grafického uživatelského rozhraní aplikací je možno použít rozhraní Swing. Java také umožňuje pomocí příslušného ovladače snadné spojení s databází a následně poskytuje metody pro snadnou práci s daty v této databázi. Jednou z nevýhod tohoto programovacího jazyka je pomalejší start programů, které jsou v něm psané, oproti jazykům se statickou kompilací. Důvodem je skutečnost, že je nejprve nutné přeložit mezikód do nativního kódu prostředí, ve kterém je program spuštěn. Další nevýhodou může být větší paměťová náročnost, neboť po dobu, kdy je aplikace spuštěná, musí být v paměti celé běhové prostředí. I přes tyto nevýhody stále jasně převažují pozitiva. Díky nim a také zkušenostem s tvorbou aplikací v Javě nebyl výběr programovacího jazyka složitou záležitostí.

4.1.2 Apache Derby Apache Derby [8] je open source relační databáze implementovaná v Javě. Neklade velké nároky na potřebné místo na disku, bez uložených dat zabere jen něco přes 2 MB. Je založena na Java, JDBC a SQL standardech. Poskytuje embedded (vestavěný) JDBC ovladač, který umožňuje použít Derby jednoduše v jakémkoli programu psaném v Javě. Podporuje i režim klient/server a poskytuje příslušné ovladače. Pro použití Derby v aplikaci s využitím embedded ovladače stačí mít k aplikaci přidanou knihovnu derby.jar, jež obsahuje mimo jiné třídu org.apache.derby.jdbc.EmbeddedDriver.class, která je zodpovědná za spojení s databází a její následné používání. Právě kvůli možnosti jednoduchého spojení s databází při spuštění aplikace, kdy se o toto spojení uživatel nemusí starat, a také z důvodu, že není třeba instalovat žádné další aplikace, jež by poskytovali databázi pro vytvořený program, byla použita databáze Apache Derby.

4.2 Vývojové prostředí a použité nástroje Zdrojové kódy by asi nebylo příliš pohodlné psát v nějakém textovém editoru, stejně tak digramy by nebylo snadné vytvořit v obyčejném Malování ve Windows. Proto je velmi výhodné použít vývojové prostředí, jež co nejvíce usnadní a urychlí práci. Také pro tvorbu diagramů

24

4. IMPLEMENTACE existuje spousta speciálních aplikací, z nichž je dobré některou použít pro jejich pohodlné vytvoření. V následujících podkapitolách je popsáno vývojové prostředí Netbeans, jež bylo využito jak při návrhu systému, tak při samotném programování, a také modelovací nástroj Toad Data Modeler, který je vhodný pro tvorbu entitně-relačních diagramů.

4.2.1 Netbeans Vývojové prostředí Netbeans je nástroj, pomocí kterého programátoři mohou psát, překládat, ladit a distribuovat aplikace. Samotné vývojové prostředí je vytvářeno v jazyce Java, ovšem podporuje prakticky jakýkoliv programovací jazyk. Existuje rovněž velké množství modulů, které toto vývojové prostředí rozšiřují [9]. Netbeans poskytuje programátorovi mnoho funkcí, které vývoj aplikací usnadňují. Psaní kódu je ulehčeno barevným odlišením jednotlivých částí (např. atributy, metody). Podporováno je automatické doplňování kódu, kdy jsou nabízeny hodící se třídy, metody či atributy. Prostředí také automaticky upozorňuje na chyby v kódu, které tak jsou pro programátora snadno odhalitelné. Obzvlášť užitečný je v Netbeans návrhář grafického rozhraní, kde je možné navrhnout každé okno aplikace, přidat do něj všechny potřebné komponenty a také upravit jejich vlastnosti tak, aby všechno správně fungovalo. Bez této možnosti by psaní kódu grafického rozhraní trvalo nesrovnatelně delší dobu. Využit byl také jeden z rozšiřujících modulů, konkrétně UML, pomocí kterého jsem vytvářel diagram tříd a diagram případů užití. Je možné, že by se daly najít aplikace, ve kterých by bylo vytváření diagramů o něco pohodlnější, na druhou stranu však šlo bez větších problémů s diagramy pracovat i v Netbeans a nemusel jsem hledat, instalovat a učit se pracovat s nějakou další aplikací.

4.2.2 Toad Data Modeler Toad Data Modeler je nástroj pro vytváření logického i fyzického modelu systému. V této práci byl využitý k vytvoření entitně-relačního diagramu, který zobrazuje strukturu databáze. Tento nástroj umožňuje snadné vytvoření všech potřebných entit i jejich atributů. Barevně odlišuje jednotlivé klíče. Zobrazuje vazby mezi jednotlivými entitami a také příslušné kardinality a popis těchto vazeb. Vyzkoušeny byly i jiné nástroje pro tvorbu entitně-relačního diagramu, ale nakonec byl vybrán Toad Data Modeler pro svou přehlednost a poměrně snad používání.

25

4. IMPLEMENTACE

4.3 Programování aplikace V okamžiku, kdy byl hotový návrh systému, vybrány technologie i vývojové prostředí, bylo možné začít se samotným programováním aplikace. To se dá rozdělit na dvě hlavní části. V té první bylo cílem podle vypracovaného diagramu tříd implementovat třídy tvořící aplikační logiku systému. Ve druhé přišla na řadu tvorba grafického uživatelského rozhraní.

4.3.1 Aplikační logika systému Nejprve bylo třeba implementovat třídy označené v diagramu stereotypem <<entity>>, jež reprezentují objekty nesoucí data. Postupně byly vytvořeny třídy Child, Instructor, Game, Group, Day a Term. V žádné z těchto tříd nechybí metoda compareTo, jež slouží k uspořádání objektů. Poté přišla na řadu třída CreateDatabase, jejímž úkolem je vytvořit v databázi potřebné tabulky se všemi atributy. Zde se využil entitně-relační diagram, díky kterému již nebylo obtížné napsat všechen potřebný kód pro správné vytvoření tabulek. Následovala implementace třídy Camp, která je nutným předpokladem pro vytvoření dalších tříd. V této třídě jsou také první metody, jež provádí určité operace s objekty nesoucími data, zde konkrétně s objekty třídy Term. Důležitou funkcí této třídy je navázání spojení s databází. Díky němu pak mohou s databází prostřednictvím SQL dotazů komunikovat i ostatní třídy. Aby mohly být testovány všechny implementované metody v této i dalších třídách, byla po dobu programování vytvořena pomocná třída Demo, která hlavně pomocí výpisu na standardní výstup umožňovala ověřit funkčnost jednotlivých metod a jejich chování v mimořádných případech, jako byl například zadání nepovoleného typu dat, nebo nevyplnění povinného údaje. Po třídě Camp pak následovala implementace všech ostatních tříd označených na diagramu jako <>, jež operují s třídami typu <<entity>>. Nejprve to byly třídy s metodami pracujícími s objekty v rámci celého tábora (CampChildRegister, CampInstructorRegister, CampGameRegister). Pak už byly potřeba třídy, které zajišťují správné uložení údajů o rodičích táborníků (SetParent) a o obci či městě, kde táborník bydlí (SetCity). Následovaly třídy, jejichž metody operovaly s objekty v rámci turnusu (TermChildRegister, TermInstructorRegister, TermGameRegister, TermGroupRegister, TermDayRegister). Posledním úkolem pak bylo vytvořit třídy, jež jsou zodpovědné za táborové bodování (TermCompetition, TermGroupCompetition).

26

4. IMPLEMENTACE 4.3.2 Grafické uživatelské rozhraní Jakmile byly vytvořeny všechny třídy tvořící aplikační logiku systému, mohlo se začít s tvorbou grafického uživatelského rozhraní. Použito bylo rozhraní Swing, který poskytuje mnoho tříd reprezentujících různé grafické komponenty, jako jsou tlačítka, popisky, tabulky či menu. K dispozici je také spousta metod, jež umožňují práci s těmito komponentami. Důležité bylo postupovat podle návrhu grafického rozhraní tak, abych dosáhl požadovaného výsledku. Nejprve byla vytvořena třída CampSwing. Ta obsahuje metodu main, pomocí které se spouští celá aplikace. Také zajišťuje zobrazování hlavního okna aplikace, ve kterém se nachází menu a také tabulky obsahující data uložená v databázi. Poté byly postupně implementovány třídy reprezentující jednotlivá dialogová okna, respektive jejich obsah. Každá z tříd je propojena s příslušnou třídou z aplikační logiky systému a každé dialogové okno tak poskytuje uživateli jednu z požadovaných funkcí systému. Nezbytné bylo snažit se co nejlépe rozvrhnout grafické komponenty v dialogových oknech tak, aby se v nich uživatel bez problému orientoval a všechny komponenty fungovaly tak, jak by měly. To, jestli se všechno zobrazuje správně a všechny poskytované funkce se skutečně dají využít, bylo vždy testováno spuštěním aplikace a vyzkoušením nově implementované třídy. Bylo také třeba vytvořit třídu PrintUtilities, která v aplikaci zajišťuje tisk. Nakonec se provedla internacionalizace aplikace a poté lokalizace do češtiny pomocí souborů Bundle.properties a Bundle_cs_CZ.properties.

4.4 Popis vytvořené aplikace V této kapitole je popsáno, co všechno musí být v adresáři aplikace, aby ji bylo možné používat, a jak vytvořená aplikace funguje a co všechno uživateli poskytuje. Na počítači, kde má být aplikace používána, nesmí chybět Java Runtime Environment, což je prostředí pro běh programů psaných v Javě.

4.4.1 Obsah adresáře aplikace Ještě před samotným spuštěním je dobré vědět, jaké soubory a podadresáře obsahuje adresář aplikace. V adresáři Táborová sekretářka, jenž je uložen na přiloženém CD, se nachází soubor camp.jar, který obsahuje všechny soubory s příponou .class, což jsou zdrojové kódy přeložené do mezikódu, který je poté interpretován pomocí Java Virtual Machine. Soubor táborová sekretářka.bat obsahuje skript zajišťující spuštění aplikace v operačním systému Windows. Posledním souborem v adresáři je derby.log, do nějž je zapisována informace o připojení se k databázi. Adresář obsahuje také dva podadresáře. Prvním je lib, který obsahuje

27

4. IMPLEMENTACE knihovnu derby.jar, která obsahuje třídy zodpovědné za spojení a práci s databází, v tomto případě se jedná konkrétně o třídu org.apache.derby.jdbc.EmbeddedDriver.class. Druhým podadresářem je db, což je samotná databáze systému.

4.4.2 Práce s aplikací Poté, co jsme se seznámili s obsahem celého adresáře, můžeme aplikaci spustit příkazem java –jar camp.jar, který by měl bez problémů fungovat jak ve Windows, tak v unixových operačních systémech. Ve Windows je ke spuštění možné použít soubor táborová sekretářka.bat, případně stačí otevřít soubor camp.jar. V té chvíli se vytvoří spojení mezi aplikací a databází. Uživateli se také objeví hlavní okno aplikace společně s oknem pro výběr turnusu (obrázek 4.1). Bez vybrání turnusu není možné dále s aplikací pracovat, a je proto nutné nejprve některý z turnusů vybrat, případně vytvořit turnus nový a vybrat poté tento.

Obrázek 4.1: Hlavní okno po spuštění aplikace

28

4. IMPLEMENTACE Jakmile uživatel zvolí některý z turnusů, pracuje od tohoto okamžiku s tímto turnusem. Může provádět všechny úkony, jež jsou v menu nabízeny a dále popsány. 

Systém – zde je možné provádět některé operace s databází (odstranit táborníka, vedoucího či hru a obnovit celou databázi) a také aplikaci ukončit.



Turnus – tato nabídka umožňuje přidat nový turnus, odstranit existující, změnit údaje o turnusu, případně vybrat jiný turnus pro další práci. Při přidávání nového a při změně údajů již existujícího turnusu jsou v otevřeném dialogovém okně označeny hvězdičkou položky, které musí být vyplněny. Při nezadání těchto údajů nebo při zadání údajů ve špatném formátu se objeví okno s informací o tom, jaká chyba se vyskytla, takže uživatel má možnost ihned špatně zadané údaje opravit. Podobné je to u všech dalších nabídek, které umožňují registraci či změnu údajů.



Táborník – umožňuje registrovat táborníka (Pokud byl již táborník dříve registrován na jiném turnusu a je tedy v databázi, je možné ho vybrat a pouze doplnit nebo změnit potřebné údaje. Stejně to funguje u registrace vedoucího a hry.), zrušit registraci, změnit uložené údaje a také rozdělit všechny táborníky na mladší a starší. V příslušném okně stačí kliknout na tlačítko Rozdělit a chlapci i děvčata jsou zvlášť rozděleni podle věku. Pokud se objeví výjimka, kdy některý schopný mladší táborník je přeřazen do skupiny starších, je možné tento údaj u daného táborníka změnit a ten se potom bude zobrazovat ve správné skupině. Toto rozdělení je možné vytisknout pomocí tlačítka Tisk.



Družinka – v této nabídce je možné přidat novou skupinku, zrušit existující, změnit údaje, dále je zde možnost přidat nebo odebrat členy jednotlivým skupinkám. Uživatel může určit, kolik členů mají skupinky mít. Následně si vybere skupinky, jejichž obsazení chce změnit. Nakonec může zaráz uložit změny ve všech skupinkách, nebo ukládat změny každé skupinky zvlášť. Je zde také možnost tisku tohoto okna. Poslední možností v této nabídce je zobrazit v tabulce všechny táborníky a skupinky, do kterých patří. Tato tabulka jde také vytisknout.



Vedoucí – zde je možné registrovat nového vedoucího, zrušit registraci a změnit údaje o vedoucím. (Na obrázku 4.2 je ukázka okna pro registraci vedoucího.)



Hra – umožňuje přidat novou hru, zrušit existující a změnit údaje o hře.

29

4. IMPLEMENTACE 

Den – tato nabídka umožňuje přidat nový táborový den, zrušit existující, změnit údaje o dni a také vygenerovat denní rozkaz s potřebnými informacemi podle vybraného dne. Tento rozkaz je možné vytisknout, aby mohl být použit při slavnostním nástupu na táboře.



Bodování – tato nabídka slouží ke správě táborového bodování. Je zde možné obodovat jednotlivé hry. Uživatel vybere hru a také to, jestli chce bodovat jednotlivce, nebo družinky. Podle toho se zobrazí seznam táborníků, či družinek a poté stačí zapsat ke každému dosažené body. Dále tato nabídka umožňuje zobrazit pořadí hry na základě výběru uživatele. Poslední dvě položky zajišťují zobrazení pořadí jednotlivců a družinek. Všechna pořadí je také možné vytisknout.

Veškerá data uložená v databázi jsou zobrazená v jednotlivých tabulkách v hlavním okně aplikace a uživatel může jednoduše kliknutím na příslušnou záložku vybrat, které tabulka má být zobrazena. Záložky Táborníci, Družinky, Vedoucí, Hry a Dny se vztahují k právě vybranému turnusu. V tabulkách, které obsahuje poslední záložka Databáze, jsou všechny turnusy, táborníci, vedoucí a hry, jež se nachází v celé databázi bez ohledu na konkrétní turnus. O poslední provedené operaci je uživatel informován pomocí informačního řádku, který je umístěn nahoře vpravo od záložek.

Obr. 4.2: Dialogové okno pro registraci nového vedoucího

30

4. IMPLEMENTACE

4.5 Hodnocení uživatelů Vytvořená aplikace byla předvedena několika budoucím uživatelům. Nejprve jim byly stručně vysvětleny hlavní funkce aplikace a poté si ji mohli vyzkoušet. Následně měli říct své názory a připomínky. Uživatelé program hodnotili kladně, přišel jim jednoduchý na pochopení, takže ani neměli příliš dotazů, jak s aplikací pracovat. Považují jej za použitelný v praxi. Přinese podle nich ulehčení hlavně v oblasti táborového bodování, což bylo jedním z hlavních cílů při tvorbě aplikace. Uživatelům se také líbilo generování denního rozkazu, jehož příprava již nezabere tolik času. Došlo také na připomínky, které mohou být využity při případném vylepšování aplikace v budoucnu. Jednalo se hlavně o rozdělování táborníků do skupinek, kde by uživatelé uvítali zjednodušení (např. rozdělit táborníky při rozřazování do skupinek na chlapce a děvčata, aby bylo vybírání členů skupinky snadnější a přehlednější, nebo mít možnost přiřadit skupinku k táborníkovi). Dále by uživatelé ocenili možnost importu a exportu údajů o tábornících či vedoucích z nebo do textového souboru. To by umožnilo snadnou výměnu dat mezi aplikací a jinými programy (např. tabulkovými procesory). Celkový dojem uživatelů byl tedy dobrý a snad bude stejný při opravdovém používání aplikace.

4.6 Možnosti rozšíření do budoucna Vývoj aplikace se dokončením této práce zdaleka nemusí zastavit. Uživatele hned při hodnocení napadlo několik dalších funkcí, které by bylo možné implementovat a které by přinesly další ulehčení a zrychlení práce táborového sekretáře. Dvě jsou již zmíněny v předchozí kapitole. V následujícím seznamu je uvedeno několik nejzajímavějších funkcí, jež by mohly být v budoucnu doplněny.      

import a export údajů tisk všech uložených údajů ukládání více údajů o tábornících, vedoucích, skupinkách, hrách i dnech automatické rozdělení táborníků do stanů, zobrazení tohoto rozdělení a jeho tisk automatické rozdělení táborníků do skupinek na základě zvolených kritérií ukládání programu tábora a jeho následné další využití

31

Kapitola 5

Závěr Cílem této práce bylo navrhnout a implementovat systém, který by pomohl vedoucím na dětských táborech. Po dokončení celé práce se dá říct, že se podařilo tento cíl naplnit a vytvořený systém bude pro uživatele opravdu užitečný. Podařilo se navrhnout systém se všemi požadovanými funkcemi a podle vypracovaného návrhu byly také tyto funkce implementovány. Při návrhu bylo podstatné všechno řádně promyslet nejen s ohledem na následné programování aplikace, ale také na možnost rozšíření o další funkce v budoucnu. V průběhu implementace se občas vyskytly menší problémy, které se však vždy podařilo vyřešit, takže by výsledná aplikace neměla obsahovat chyby, jež by ohrožovaly její fungování. Vytvořená aplikace byla konzultována s budoucími uživateli, kteří ji ohodnotili kladně, ale měli také užitečné připomínky a nápady, které mohou být zohledněny při případném budoucím zdokonalování aplikace. Dle názoru uživatelů bude systém vytvořený v rámci bakalářské práce opravdu použitelný v praxi a pomůže tak vedoucím na táboře v jejich nesnadné, ale chvályhodné a užitečné práci s dětmi.

32

Literatura [1] FIŠER, JOSEF: Táboření s Kristem (souhrn článků pro časopis Paprsek), Jablonné nad Orlicí, 2003, dokument dostupný na www: http://www.animaiuventutis.cz/dokumenty/tabor/taboreni%20s% 20kristem.doc (2) [2] KANISOVÁ, HANA, MÜLLER, MIROSLAV: UML srozumitelně, 2. aktualiz. vyd., Brno, Computer Press, 2007, 176 s. (3.2) [3] OO, UML, analýza, metodologie – diagram případů užití, [online], dostupný na www: http://mpavus.wz.cz/uml/uml-b-use-case-3-2-1.php (3.3) [4] OO, UML, analýza, metodologie – diagram tříd, [online], dostupný na www: http://mpavus.wz.cz/uml/uml-s-class-3-3-1.php (3.4) [5] Java API Specification, [online], dostupný na www: http://java.sun.com/javase/6/docs/api/ (4.1.1) [6] Programovací jazyk Java, [online], dostupný na www: http://v1.dione.zcu.cz/java/uvod.html (4.1.1) [7] BLOCH, JOSHUA: Java efektivně: 57 zásad softwarového experta, 1. vyd., Praha, Grada, c2001, 230 s. [8] Derby Reference Manual, [online], dostupný na www: http://db.apache.org/derby/docs/dev/ref (4.1.2) [9] Netbeans, [online], dostupný na www: http://www.contrib.netbeans.org/index_cs.html (4.2.1)

33

Příloha A

Obsah CD Součástí této práce je také CD, obsahující adresáře: 

Táborová sekretářka – obsahuje vytvořenou desktopovou aplikaci.



Zdrojové kódy – obsahuje všechny zdrojové kódy celé aplikace.



Diagramy – obsahuje diagram případů užití, který je v této práci na str. 12, diagram tříd ze str. 16, větší a podrobnější diagram tříd, na němž jsou u každé třídy uvedeny její atributy a metody, a entitně-relační diagram ze str. 21.



Text práce – obsahuje tuto práci ve formátu PDF.

34