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

Rozměr: px
Začít zobrazení ze stránky:

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

Transkript

1 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

2 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

3 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

4 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

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

6 Obsah 1 Úvod Struktura a fungování dětského tábora Osoby na táboře Táborníci Vedoucí Táborový den Hry a táborové bodování Návrh systému Požadavky na systém Požadované vlastnosti Požadované funkce Jazyk UML Diagram případů užití Diagram tříd Popis diagramu tříd navrženého systému Entitně-relační diagram Popis entitně-relačního diagramu navrženého systému Návrh grafického uživatelského rozhraní Implementace Použité technologie Java Apache Derby Vývojové prostředí a použité nástroje Netbeans Toad Data Modeler Programování aplikace Aplikační logika systému Grafické uživatelské rozhraní Popis vytvořené aplikace Obsah adresáře aplikace Práce s aplikací Hodnocení uživatelů Možnosti rozšíření do budoucna Závěr Literatura A Obsah CD

7 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

8 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

9 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 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

10 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 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

11 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

12 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

13 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í 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

14 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á 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

15 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

16 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

17 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

18 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 <<control>> a třídy, které jsou využívané pro komunikaci systému a uživatelů a které se označují <<boundary>> 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 <<control>>. 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

19 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 <<control>>: 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

20 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ě, u 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

21 3. NÁVRH SYSTÉMU Obrázek 3.2: Diagram tříd 16

22 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

23 3. NÁVRH SYSTÉMU 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

24 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

25 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

26 3. NÁVRH SYSTÉMU Obrázek 3.3: Entitně-relační diagram 21

27 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

28 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 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 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

29 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í 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

30 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ů 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í 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

31 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í 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 <<control>>, 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

32 4. IMPLEMENTACE 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ě 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

10. blok Logický návrh databáze

10. blok Logický návrh databáze 10. blok Logický návrh databáze Studijní cíl Tento blok je věnován převodu konceptuálního návrhu databáze na návrh logický. Blok se věnuje tvorbě tabulek na základě entit z konceptuálního modelu a dále

Více

Modelování řízené případy užití

Modelování řízené případy užití Modelování řízené případy užití kompletní proces od UC po implementaci, robustnost 2005 Radek Ošlejšek, Jiří Sochor FI MU Brno oslejsek@fi.muni.cz http://www.fi.muni.cz/~oslejsek/pa103 30. 3. 2005 PA103:

Více

3 druhy UML diagramů

3 druhy UML diagramů UML grafický jazyk se pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů zjednodušuje komunikaci mezi zadavatelem a řešitelem projektu UML podporuje objektově orientovaný přístup

Více

Modelování webových služeb v UML

Modelování webových služeb v UML Modelování webových služeb v UML Jaromír Šveřepa LBMS, s.r.o. Abstrakt: Tento příspěvek se zaměřuje na praktický postup pro identifikaci potřeby webové služby, modelování způsobu jejího použití, popřípadě

Více

EXTRAKT z české technické normy

EXTRAKT z české technické normy EXTRAKT z české technické normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním 03.220.01, 35.240.70 materiálem o normě. Inteligentní dopravní systémy Geografické datové soubory (GDF)

Více

Unifikovaný modelovací jazyk UML

Unifikovaný modelovací jazyk UML Unifikovaný modelovací jazyk UML Karel Richta katedra počíta tačů FEL ČVUT Praha richta@fel fel.cvut.czcz Motto: Komunikačním m prostředkem informační komunity se postupem času stala angličtina. Chcete-li

Více

Navigace na webových stránkách

Navigace na webových stránkách Navigace na webových stránkách Tato kapitola navazuje na kapitoly o přístupnosti, použitelnosti a optimalizaci webových stránek a podrobněji popisuje tvorbu informační architektury webových stránek, zejména

Více

Objektově orientované technologie Diagram komponent Implementační náhled (Diagram rozmístění) Pavel Děrgel, Daniela Szturcová

Objektově orientované technologie Diagram komponent Implementační náhled (Diagram rozmístění) Pavel Děrgel, Daniela Szturcová Objektově orientované technologie Diagram komponent Implementační náhled (Diagram rozmístění) Pavel Děrgel, Daniela Szturcová Osnova K čemu slouží diagram komponent obsah komponent závislosti rozhraní

Více

Univerzita Pardubice Fakulta ekonomicko-správní Ústav systémového inženýrství a informatiky

Univerzita Pardubice Fakulta ekonomicko-správní Ústav systémového inženýrství a informatiky Univerzita Pardubice Fakulta ekonomicko-správní Ústav systémového inženýrství a informatiky Datová podpora na úrovni kontaktního pracoviště Úřadu práce pro státní sociální podporu Josef Hájek Bakalářská

Více

Informační systémy 2008/2009. Radim Farana. Obsah. UML - charakteristika

Informační systémy 2008/2009. Radim Farana. Obsah. UML - charakteristika 2 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Jazyk UML, základní modely, diagramy aktivit, diagramy entit.

Více

Implementace A* algoritmu na konkrétní problém orientace v prostoru budov

Implementace A* algoritmu na konkrétní problém orientace v prostoru budov Implementace A* algoritmu na konkrétní problém orientace v prostoru budov Popis problému Orientaci ve známém prostředí lze převést na problém nalezení cesty z místa A do místa B. Obecně platí, že robot

Více

UML - Unified Modeling Language

UML - Unified Modeling Language UML - Unified Modeling Language Martin Molhanec Katedra elektrotechnologie, ČVUT - Fakulta elektrotechnická, Technická 2, 166 21 PRAHA 6 e-mail: molhanec@fel.cvut.cz Abstrakt UML Unified Modeling Language

Více

Úvod do databázových systémů 6. cvičení

Úvod do databázových systémů 6. cvičení Vysoká škola báňská Technická univerzita Ostrava Fakulta elektrotechniky a informatiky Úvod do databázových systémů 6. cvičení Ing. Petr Lukáš petr.lukas@nativa.cz Ostrava, 2012 Modelování databází [1]

Více

Objektově orientované technologie Logická struktura systému Objektový diagram. Pavel Děrgel, Daniela Szturcová

Objektově orientované technologie Logická struktura systému Objektový diagram. Pavel Děrgel, Daniela Szturcová Objektově orientované technologie Logická struktura systému Objektový diagram Pavel Děrgel, Daniela Szturcová Osnova Modelování objektů objektový diagram Struktura a vazby mezi objekty Dobré zvyky při

Více

software MAJETEK verze 4.xx verze 4.03 3.1.2013

software MAJETEK verze 4.xx verze 4.03 3.1.2013 software MAJETEK verze 4.xx verze 4.03 3.1.2013 doba daňového odpisu Ve volbě Tabulky - Tabulky - Daňové - Lineární sazby lze přes opravit údaje o daňových opisech (doba odepisování a % ročního odpisu).

Více

Infrastruktura UML. Modelování struktury v UML. Superstruktura UML. Notace objektů. Diagramy objektů

Infrastruktura UML. Modelování struktury v UML. Superstruktura UML. Notace objektů. Diagramy objektů Infrastruktura UML v UML Karel Richta listopad 2011 Richta: B101TMM - v UML 2 Superstruktura UML Směr pohledu na systém dle UML Diagramy popisující strukturu diagramy tříd, objektů, kompozitní struktury,

Více

Metodika Portálu pohledávek ve vztahu k uživateli

Metodika Portálu pohledávek ve vztahu k uživateli Metodika Portálu pohledávek ve vztahu k uživateli Obsah Úvod 1. Základní vlastnosti a pojmy 1.1. Ikony 1.2. Vaše první přihlášení do aplikace 1.3. Přístupové údaje 2. Popis práce v aplikaci portálu pohledávek

Více

2. Konceptuální model dat, E-R konceptuální model

2. Konceptuální model dat, E-R konceptuální model 2. Konceptuální model dat, E-R konceptuální model Úvod Databázový model souhrn prostředků, pojmů a metod, jak na logické úrovni popsat data a jejich strukturu výsledkem je databázové schéma. Databázové

Více

VYTVÁŘENÍ A MANAGEMENT TESTŮ A PROJEKTŮ

VYTVÁŘENÍ A MANAGEMENT TESTŮ A PROJEKTŮ VYTVÁŘENÍ A MANAGEMENT TESTŮ A PROJEKTŮ RNDr. Petra Poulová, Ph.D. Ing. Hana Šrámková Fakulta informatiky a managementu Univerzity Hradec Králové Projekt je spolufinancován Evropským sociálním fondem a

Více

Klíčová slova: OOP, konstruktor, destruktor, třída, objekt, atribut, metoda

Klíčová slova: OOP, konstruktor, destruktor, třída, objekt, atribut, metoda Anotace sady: Úvod do objektově orientovaného programování, VY_32_INOVACE_PRG_OOP_01 Autor: Blanka Sadovská Klíčová slova: OOP, konstruktor, destruktor, třída, objekt, atribut, metoda Druh učebního materiálu:

Více

Principy UML. Clear View Training 2005 v2.2 1

Principy UML. Clear View Training 2005 v2.2 1 Principy UML Clear View Training 2005 v2.2 1 1.2 Co je touml? Unified Modelling Language (UML) je univerzálníjazyk pro vizuální modelování systémů Podporuje všechny životní cykly Mohou jej implementovat

Více

Modelování procesů s využitím MS Visio.

Modelování procesů s využitím MS Visio. Modelování procesů s využitím MS Visio jan.matula@autocont.cz Co je to modelování procesů? Kreslení unifikovaných či standardizovaných symbolů, tvarů a grafů, které graficky znázorňují hlavní, řídící nebo

Více

ELEKTRONICKÁ PORODNÍ KNIHA POPIS APLIKACE Michal Huptych, Petr Janků, Lenka Lhotská

ELEKTRONICKÁ PORODNÍ KNIHA POPIS APLIKACE Michal Huptych, Petr Janků, Lenka Lhotská ELEKTRONICKÁ PORODNÍ KNIHA POPIS APLIKACE Michal Huptych, Petr Janků, Lenka Lhotská Anotace Tento příspěvek popisuje aplikaci, která je převodem tzv. porodní knihy do elektronické podoby. Aplikace vzniká

Více

7.3 Diagramy tříd - základy

7.3 Diagramy tříd - základy 7.3 Diagramy tříd - základy - popisuje typy objektů a statické vztahy mezi nimi Objednávka -datumpřijetí -předplacena -číslo -cena +vyřiď() +uzavři() {if Objednávka.zákazník.charakteristika = 'nejistý'

Více

2. blok část B Základní syntaxe příkazů SELECT, INSERT, UPDATE, DELETE

2. blok část B Základní syntaxe příkazů SELECT, INSERT, UPDATE, DELETE 2. blok část B Základní syntaxe příkazů SELECT, INSERT, UPDATE, DELETE Studijní cíl Tento blok je věnován základní syntaxi příkazu SELECT, pojmům projekce a restrikce. Stručně zde budou představeny příkazy

Více

Ostatní portálové aplikace

Ostatní portálové aplikace Univerzitní informační systém Slovenská zemědělská univerzita v Nitře Ostatní portálové aplikace Svazek 9 Verze: 1.20 Datum: 10. března 2016 Autor: Jitka Šedá, Martin Tyllich Obsah Seznam obrázků 5 1

Více

Úvod do databázových systémů

Úvod do databázových systémů Vysoká škola báňská Technická univerzita Ostrava Fakulta elektrotechniky a informatiky Úvod do databázových systémů Cvičení 7 Ing. Petr Lukáš petr.lukas@vsb.cz Ostrava, 2014 Modelování databází Modelování

Více

Teoretické minimum z PJV

Teoretické minimum z PJV Teoretické minimum z PJV Pozn.: následující text popisuje vlastnosti jazyka Java zjednodušeně pouze pro potřeby výuky. Třída Zavádí se v programu deklarací třídy což je část programu od klíčových slov

Více

Tábor 2015 Hrádek u Sušice

Tábor 2015 Hrádek u Sušice Tábor 2015 Hrádek u Sušice Vážení rodiče, Vedoucí našeho oddílu již začínají připravovat tábor 2015. Proto jsme pro vás připravili krátký sešit s prvními informacemi o táboře. Podrobnější informace přijdou

Více

Modul EPNO. Téma: Elektronické odesílání evidenčních listů přepravy nebezpečných odpadů

Modul EPNO. Téma: Elektronické odesílání evidenčních listů přepravy nebezpečných odpadů Modul EPNO Téma: Elektronické odesílání evidenčních listů přepravy nebezpečných odpadů Program: EVI 8 Vypracoval: Mgr. Tomáš Čejchan (oddělení Podpora) Revize: 07.03.2014 Tento dokument popisuje funkcionalitu

Více

7 Jazyk UML (Unified Modeling Language)

7 Jazyk UML (Unified Modeling Language) 7 Jazyk UML (Unified Modeling Language) 7.1 Základní charakteristika jazyka Motivace - vznik řady OO metod a metodologií (konec 80. let a první polovina 90.let) podobné notace vyjadřující totéž, komplikující

Více

OOT Objektově orientované technologie

OOT Objektově orientované technologie OOT Objektově orientované technologie Logická struktura systému (Diagram tříd) Daniela Szturcová Institut geoinformatiky, HGF Osnova Třídy Statický pohled na systém Atributy a operace, řízení přístupu

Více

UML. Unified Modeling Language. Součásti UML

UML. Unified Modeling Language. Součásti UML UML Unified Modeling Language 1995 počátek 1997 verze 1.0 leden dnes verze 2.0 (vývoj stále nedokončen) Standardní notace OMG podpora velkých firem (Microsoft, IBM, Oracle, HP ) popisuje struktury popisuje

Více

Ostatní portálové aplikace

Ostatní portálové aplikace Univerzitní informační systém Panevropská vysoká škola Ostatní portálové aplikace Svazek 9 Verze: 1.20 Datum: 10. března 2016 Autor: Jitka Šedá, Martin Tyllich Obsah Seznam obrázků 5 1 Helpdesk pro UIS

Více

Manuál k aplikaci SDO PILOT v.0.2

Manuál k aplikaci SDO PILOT v.0.2 Manuál k aplikaci SDO PILOT v.0.2 Základní informace o aplikaci Aplikace slouží pro zjednodušené vytváření dokumentů Souhrnů doporučených opatření pro Evropsky významné lokality. Vznikala přírustkovým

Více

OpusBenefit. Uživatelský manuál k verzi 1.0 verze 1-2010 1 / 24. K l i e n t s k á d a t a b á z e

OpusBenefit. Uživatelský manuál k verzi 1.0 verze 1-2010 1 / 24. K l i e n t s k á d a t a b á z e 1 / 24 1 Úvod Program OpusBenefit byl vytvořen proto, aby naši obchodní partneři mohli sledovat aktivity svých zákazníků (nákupy v jejich obchodech, využívání jejich služeb, návštěvy jejich zařízení),

Více

Metodika. Oznámení o vykonávání působností v agendě ve smyslu zákona č. 111/2009. Sb., o základních registrech. Verze 1.6

Metodika. Oznámení o vykonávání působností v agendě ve smyslu zákona č. 111/2009. Sb., o základních registrech. Verze 1.6 Metodika Oznámení o vykonávání působností v agendě ve smyslu zákona č. 111/2009 Sb., o základních registrech Verze 1.6 AIS RPP Působnostní určeno pro oznamovatele Oznámení o vykonávání působností č. 111/2009

Více

Univerzita Pardubice Fakulta ekonomicko-správní Ústav systémového inženýrství a informatiky Návrh a tvorba databáze v prostředí vybrané firmy

Univerzita Pardubice Fakulta ekonomicko-správní Ústav systémového inženýrství a informatiky Návrh a tvorba databáze v prostředí vybrané firmy Univerzita Pardubice Fakulta ekonomicko-správní Ústav systémového inženýrství a informatiky Návrh a tvorba databáze v prostředí vybrané firmy Pavla Vaníčková Bakalářská práce 2012 Prohlášení Prohlašuji,

Více

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz UML a jeho použití v procesu vývoje Jaroslav Žáček jaroslav.zacek@osu.cz Různé pohledy na modelování Různé pohledy na modelování Unified Modeling Language UML není metodikou ani programovacím jazykem,

Více

Tvorba informačních systémů

Tvorba informačních systémů Tvorba informačních systémů Michal Krátký 1 1 Katedra informatiky VŠB Technická univerzita Ostrava Tvorba informačních systémů, 2005/2006 c 2006 Michal Krátký Tvorba informačních systémů 1/35 Konceptuální

Více

EVROPSKÁ ŽELEZNIČNÍ AGENTURA. SYSTÉMOVÝ PŘÍSTUP Prováděcí pokyny pro tvorbu a zavádění systému zajišťování bezpečnosti železnic

EVROPSKÁ ŽELEZNIČNÍ AGENTURA. SYSTÉMOVÝ PŘÍSTUP Prováděcí pokyny pro tvorbu a zavádění systému zajišťování bezpečnosti železnic EVROPSKÁ ŽELEZNIČNÍ AGENTURA SYSTÉMOVÝ PŘÍSTUP Prováděcí pokyny pro tvorbu a zavádění systému zajišťování bezpečnosti železnic Verze 1.0 13. 12. 2010 Správa verze Dokument zpracovala: Vydal: Kontrolu provedl:

Více

NÁVRH A REALIZACE WWW PREZENTACE ČKR

NÁVRH A REALIZACE WWW PREZENTACE ČKR NÁVRH A REALIZACE WWW PREZENTACE ČKR Šárka Ocelková Ústav výpočetní techniky MU v Brně, Botanická 68a, 602 00 Brno, ČR E-mail: ocelkova@ics.muni.cz Abstrakt U zrodu www prezentace České konference rektorů

Více

7 Jazyk UML (Unified Modeling Language)

7 Jazyk UML (Unified Modeling Language) 7 Jazyk UML (Unified Modeling Language) 7.1 Základní charakteristika jazyka Motivace - vznik řady OO metod a metodologií (konec 80. let a první polovina 90.let) podobné notace vyjadřující totéž, komplikující

Více

TÉMATICKÝ OKRUH Softwarové inženýrství

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 24. Otázka : Implementační fáze. Postupy při specifikaci organizace softwarových komponent pomocí UML. Mapování modelů na struktury programovacího

Více

Test uživatelského rozhraní aplikace Google Maps

Test uživatelského rozhraní aplikace Google Maps ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE FAKULTA ELEKTROTECHNICKÁ Test uživatelského rozhraní aplikace Google Maps Testování uživatelského rozhraní - A4B39TUR Semestrální práce A2 Tom Nováček novacto2@fel.cvut.cz

Více

Komputerizace problémových domén

Komputerizace problémových domén Milan Mišovič (ČVUT FIT) Pokročilé informační systémy MI-PIS, 2011, Přednáška 03 1/19 Komputerizace problémových domén Prof. RNDr. Milan Mišovič, CSc. Katedra softwarového inženýrství Fakulta informačních

Více

DĚTSKÉ CENTRUM SE HLÁSÍ K ALTERNATIVNÍMU PROGRAMU THE WORLD AS HE SEES THE CHILD

DĚTSKÉ CENTRUM SE HLÁSÍ K ALTERNATIVNÍMU PROGRAMU THE WORLD AS HE SEES THE CHILD DĚTSKÉ CENTRUM SE HLÁSÍ K ALTERNATIVNÍMU PROGRAMU THE WORLD AS HE SEES THE CHILD,, Svět jak ho vidí dítě Tento program odmítá jakoukoliv konvenci ve styku s dětmi. SYSTÉM VÝCHOVNÉHO PROCESU, JE ORIENTOVÁN

Více

4. Základy relačních databází, logická úroveň návrhu

4. Základy relačních databází, logická úroveň návrhu 4. Základy relačních databází, logická úroveň návrhu Když před desítkami let doktor E. F. Codd zavedl pojem relační databáze, pohlíželo se na tabulky jako na relace, se kterými se daly provádět různé operace.

Více

Uživatelem řízená navigace v univerzitním informačním systému

Uživatelem řízená navigace v univerzitním informačním systému Hana Netrefová 1 Uživatelem řízená navigace v univerzitním informačním systému Hana Netrefová Abstrakt S vývojem počítačově orientovaných informačních systémů je stále větší důraz kladen na jejich uživatelskou

Více

PLÁN VÝCHOVY, PÉČE A VZDĚLÁVÁNÍ. Dětská skupina Malíček

PLÁN VÝCHOVY, PÉČE A VZDĚLÁVÁNÍ. Dětská skupina Malíček PLÁN VÝCHOVY, PÉČE A VZDĚLÁVÁNÍ Dětská skupina Malíček Při definování Plánu výchovy, péče a vzdělávání jsme se inspirovali v Rámcovém programu pro předškolní vzdělávání. Začlenili jsme zde také filozofie,

Více

Ruční návrh Připravíme si odpovědi na základní otázky Co chceme řešit (projektovat) a proč Komu to bude sloužit Jaký užitek z toho bude mít uživatel I

Ruční návrh Připravíme si odpovědi na základní otázky Co chceme řešit (projektovat) a proč Komu to bude sloužit Jaký užitek z toho bude mít uživatel I Návrh řešení IS Vývoj informačních systémů Ruční návrh Připravíme si odpovědi na základní otázky Co chceme řešit (projektovat) a proč Komu to bude sloužit Jaký užitek z toho bude mít uživatel IS a jaký

Více

Objektově orientované technologie Dynamický náhled Stavový diagram. Pavel Děrgel, Daniela Ďuráková

Objektově orientované technologie Dynamický náhled Stavový diagram. Pavel Děrgel, Daniela Ďuráková Objektově orientované technologie Dynamický náhled Stavový diagram Pavel Děrgel, Daniela Ďuráková Osnova Modelování životního cyklu objektu počátek a konec objektu stavy a přechody mezi stavy události

Více

RNDr. Jakub Lokoč, Ph.D. RNDr. Michal Kopecký, Ph.D. Katedra softwarového inženýrství Matematicko-Fyzikální fakulta Univerzita Karlova v Praze

RNDr. Jakub Lokoč, Ph.D. RNDr. Michal Kopecký, Ph.D. Katedra softwarového inženýrství Matematicko-Fyzikální fakulta Univerzita Karlova v Praze RNDr. Jakub Lokoč, Ph.D. RNDr. Michal Kopecký, Ph.D. Katedra softwarového inženýrství Matematicko-Fyzikální fakulta Univerzita Karlova v Praze 1 Konceptuální modelování 2 Vytvořte model pro reprezentaci

Více

33 Uživatelé asistence

33 Uživatelé asistence 33 Uživatelé asistence Uživatelský modul Uživatelé asistence náleží k modulům řešícím agendu služby osobní asistentce. Modul realizuje evidenci uživatelů služby osobní asistence (včetně zájemců o službu).

Více

HRY, PŘÍPRAVA AKCÍ PŘÍPRAVA HRY

HRY, PŘÍPRAVA AKCÍ PŘÍPRAVA HRY HRY, PŘÍPRAVA AKCÍ Využíváním her i soutěží v naší činnosti učíme děti poctivosti, ukázněnosti, smyslu pro kamarádství, pro společnost, ohleduplnosti k mladším. Jejích smyslem a cílem je výchova k fairplay,

Více

Stručný průvodce uživatele pro externí organizaci

Stručný průvodce uživatele pro externí organizaci Stručný průvodce uživatele pro externí organizaci únor 2010 Radek Maca Obsah Obsah... 2 1. Filosofie práce... 3 Účel aplikace... 3 Možnosti využití... 3 Základní funkcionality... 4 Výstupy... 4 Výstupy

Více

Parametrizace, harmonogram

Parametrizace, harmonogram Parametrizace, harmonogram Modul slouží pro parametrizování informačního systému a pro vytváření časového plánu akademického roku na fakultě. Fakulty si v něm zadávají a specifikují potřebné "časové značky"

Více

MapleCloud a jeho použ ití. Vladimír Žák

MapleCloud a jeho použ ití. Vladimír Žák MapleCloud a jeho použ ití Vladimír Žák Brno, 2015 Obsah 1 Úvod... 4 2 Novinky v MapleCloud pro Maple 2015... 5 3 MapleCloud a registrace... 6 4 Použití MapleCloud přímo z Maple 2015... 7 4.1 Popis jednotlivých

Více

METODICKÉ POKYNY PRO TRENÉRY HC ČESKÁ LÍPA

METODICKÉ POKYNY PRO TRENÉRY HC ČESKÁ LÍPA METODICKÉ POKYNY PRO TRENÉRY HC ČESKÁ LÍPA Pro sezóny 2014-2015,2015-2016 Cíle a úkoly práce s mládeží Cílem dlouholeté práce s mládeží je zajistit, aby došlo k optimálnímu osobnostnímu a sportovnímu rozvoji

Více

Raketové sporty (badminton, squash) ve školní TV. A proč ne?

Raketové sporty (badminton, squash) ve školní TV. A proč ne? Masarykova univerzita Fakulta sportovních studií Raketové sporty (badminton, squash) ve školní TV. A proč ne? TEXTOVÁ OPORA KE KURZU Martina Bernacíková, Zora Svobodová Brno 2011 Publikace byla zpracována

Více

Uživatelská příručka + základní informace o IS o ISVS

Uživatelská příručka + základní informace o IS o ISVS Uživatelská příručka + základní informace o IS o ISVS Vážení uživatelé, vítejte v Informačním systému o informačních systémech veřejné správy (dále jen IS o ISVS ) Obsah uživatelské příručky: 1. Obecně

Více

Manuál k databázi soupisů duší

Manuál k databázi soupisů duší Manuál k databázi soupisů duší Obsah Úvod... 3 1. Orientace v databázi... 3 2. Vkládání údajů do databáze... 4 2.1 Formulář obec... 5 2.2 Formulář dům... 6 2.3 Formulář domácnost... 7 2.4 Formulář osoba...

Více

MATURITNÍ PRÁCE dokumentace

MATURITNÍ PRÁCE dokumentace MATURITNÍ PRÁCE dokumentace Jídelníček SŠIEŘ pro Android Martin Bartoň školní rok: 2012/2013 obor: třída: Počítačové systémy PS4.A ABSTRAKT Práce je zaměřená na problematiku tvorby Android aplikací,

Více

Výčtový typ strana 67

Výčtový typ strana 67 Výčtový typ strana 67 8. Výčtový typ V této kapitole si ukážeme, jak implementovat v Javě statické seznamy konstant (hodnot). Příkladem mohou být dny v týdnu, měsíce v roce, planety obíhající kolem slunce

Více

Informační systémy 2008/2009. Radim Farana. Obsah. Nástroje business modelování. Business modelling, základní nástroje a metody business modelování.

Informační systémy 2008/2009. Radim Farana. Obsah. Nástroje business modelování. Business modelling, základní nástroje a metody business modelování. 3 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Business modelling, základní nástroje a metody business modelování.

Více

7.6 Další diagramy UML

7.6 Další diagramy UML 7.6 Další diagramy UML 7.6.1 Moduly (balíčky - package) a kolaborace (collaboration) Jak rozložit rozsáhlý systém na menší? - seskupování tříd (prvků modelu) do jednotek vyšší úrovně (package v UML). UI

Více

Dalším příkladem může být například výstup dat na různá zařízení, souborů, grafických rozhraní, sítě atd.

Dalším příkladem může být například výstup dat na různá zařízení, souborů, grafických rozhraní, sítě atd. 1. Zapouzdření Cíl látky Tento blok nejdříve přiblíží zásadu zapouzdření a odpoutání kódu a po té na relacích, jako jsou asociace, agregace a kompozice, vysvětlí jak lze objektový zdrojový kód zapouzdřovat

Více

Systém integrované péče. Návod online aplikace SIP ČPZP

Systém integrované péče. Návod online aplikace SIP ČPZP Systém integrované péče Návod online aplikace SIP ČPZP aktualizace: 31. leden 2014 OBSAH 1. Úvod... 3 2. Registrace do projektu SIP... 4 3. Práce s online aplikací SIP ČPZP... 6 3.1 Přihlášení do aplikace...6

Více

20. Projekt Domácí mediotéka

20. Projekt Domácí mediotéka Projekt Domácí mediotéka strana 211 20. Projekt Domácí mediotéka 20.1. Základní popis, zadání úkolu V projektu Domácí mediotéka (Dome) se jednoduchým způsobem evidují CD a videa. Projekt je velmi jednoduchý

Více

7.6 Další diagramy UML

7.6 Další diagramy UML 7.6 Další diagramy UML 7.6.1 Moduly (balíčky - package) a kolaborace (collaboration) Jak rozložit rozsáhlý systém na menší? - seskupování tříd (prvků modelu) do jednotek vyšší úrovně (package v UML). UI

Více

Tématický blok 2 téma 2 Kapitola 4.1. Rozvaha a její struktura, bilanční princip

Tématický blok 2 téma 2 Kapitola 4.1. Rozvaha a její struktura, bilanční princip Tématický blok 2 téma 2 Kapitola 4.1. Rozvaha a její struktura, bilanční princip Obsah kapitoly 4.1. Rozvaha a její struktura 4.1.1. Struktura rozvahy 4.1.2. Forma rozvahy Studijní cíle Cílem v této druhé

Více

Projekt Vzdělávání dotykem CZ.1.07/1.3.00/51.0031. WORD 2013 práce s textovými soubory. Autoři: Jan Heller a David Peterka

Projekt Vzdělávání dotykem CZ.1.07/1.3.00/51.0031. WORD 2013 práce s textovými soubory. Autoři: Jan Heller a David Peterka Projekt Vzdělávání dotykem CZ.1.07/1.3.00/51.0031 WORD 2013 práce s textovými soubory Autoři: Jan Heller a David Peterka 1 Obsah Úvodní slovo realizačního týmu... 4 Úvod... 6 1. Prostředí MS Word 2013...

Více

Obsah přednášky. 12. Dokumentace zdrojového kódu Tvorba elektronické dokumentace UML. Co je diagram tříd. Ing. Ondřej Guth

Obsah přednášky. 12. Dokumentace zdrojového kódu Tvorba elektronické dokumentace UML. Co je diagram tříd. Ing. Ondřej Guth Evropský sociální fond. 12. Dokumentace zdrojového kódu Tvorba elektronické dokumentace Ing. Ondřej Guth Katedra teoretické informatiky Fakulta informačních technologií České vysoké učení technické v Praze

Více

Grantové řízení Oranžové hřiště

Grantové řízení Oranžové hřiště Grantové řízení Oranžové hřiště Jak podat žádost? Jak vyplnit formulář? Jak získat informace o stavu zpracování žádosti? 1/12 Jak podat Žádost o nadační příspěvek Podat žádost lze výhradně vyplněním a

Více

Josefína Ukázková. Křestní jméno: Josefína Datum narození: 16.6.1975 CESTY ŽIVOTA. Milá Josefíno.

Josefína Ukázková. Křestní jméno: Josefína Datum narození: 16.6.1975 CESTY ŽIVOTA. Milá Josefíno. Josefína Ukázková Křestní jméno: Josefína Datum narození: 16.6.1975 CESTY ŽIVOTA Milá Josefíno. Výše jsou pro Vás vyloženy všechny karty, které Vám utvářejí Vaše cesty v nejbližší budoucnosti. Je potřeba

Více

7.2 Model použití (jednání) (Use Case)

7.2 Model použití (jednání) (Use Case) 7.2 Model použití (jednání) (Use Case) - při analýze požadavků často popis typických interakcí uživatele, nedokumentované Jacobson model použití (1992) Scénář Posloupnost kroků popisujících interakci mezi

Více

EvMO2010 návod k použití programu (2015)

EvMO2010 návod k použití programu (2015) EvMO2010 návod k použití programu (2015) Program EvMO2010 slouží k jednoduché evidenci členů, plateb, povolenek a odvodů. Dále je možno evidovat přestupky a další informace členů MO. Cílem bylo vytvoří

Více

Rozhodovací procesy v ŽP HRY A SIMULAČNÍ MODELY

Rozhodovací procesy v ŽP HRY A SIMULAČNÍ MODELY Rozhodovací procesy v ŽP HRY A SIMULAČNÍ MODELY Teorie her proč využívat hry? Hry a rozhodování varianty her cíle a vítězné strategie (simulační) Modely Operační hra WRENCH Cv. Katedra hydromeliorací a

Více

Jazyk UML - přehled. diagram hierarchie procesů. IS firmy. podpora řízení. evidence zaměstnanců. pokladny. výroba. diagram procesních vláken

Jazyk UML - přehled. diagram hierarchie procesů. IS firmy. podpora řízení. evidence zaměstnanců. pokladny. výroba. diagram procesních vláken Jazyk UML - přehled Unified Modeling Language jazyk pro popis objektově orientované analýzy a návrhu aplikací slouží k vzájemné komunikaci mezi zadavatelem a návrhářem systému má několik částí, není nutné

Více

Inteligentní vyhledávač hodnocení knih

Inteligentní vyhledávač hodnocení knih MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Inteligentní vyhledávač hodnocení knih Bakalářská práce Tomáš Kácel Brno, 2012 Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem

Více

7.3 Diagramy tříd - základy

7.3 Diagramy tříd - základy 7.3 Diagramy tříd - základy - popisuje typy objektů a statické vztahy mezi nimi Objednávka -datumpřijetí -předplacena -číslo -cena +vyřiď() +uzavři() {if Objednávka.zákazník.charakteristika = 'nejistý'

Více

Vysoká škola ekonomická v Praze

Vysoká škola ekonomická v Praze Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky obor informatika 2007 Srovnání portálů zdravotních pojišťoven z pohledu malého a středního podniku jako zaměstnavatele (bakalářská práce)

Více

1. Dědičnost a polymorfismus

1. Dědičnost a polymorfismus 1. Dědičnost a polymorfismus Cíl látky Cílem této kapitoly je představit klíčové pojmy dědičnosti a polymorfismu. Předtím však je nutné se seznámit se základními pojmy zobecnění neboli generalizace. Komentář

Více

Tabulka symbolů. Vazba (binding) Vazba - příklad. Deklarace a definice. Miroslav Beneš Dušan Kolář

Tabulka symbolů. Vazba (binding) Vazba - příklad. Deklarace a definice. Miroslav Beneš Dušan Kolář Vazba (binding) Tabulka symbolů Miroslav Beneš Dušan Kolář vazba = spojení mezi entitou a vlastností okamžik vazby (binding time) při návrhu jazyka při implementaci jazyka během překladu/spojování/zavádění

Více

Objektově orientované technologie. Daniela Szturcová

Objektově orientované technologie. Daniela Szturcová Objektově orientované technologie Cvičení 5 - Tvorba třídního diagramu Daniela Szturcová 1 5 Tvorba třídního diagramu Cíl cvičení Vyhledat třídy, jejich atributy a operace. Navrhnout vazby mezi třídami.

Více

FTC08 instalační manuál k dotykovému panelu systému Foxys

FTC08 instalační manuál k dotykovému panelu systému Foxys FTC08 instalační manuál k dotykovému panelu systému Foxys Foxtron spol. s r.o. Jeseniova 1522/53 130 00 Praha 3 tel/fax: +420 274 772 527 E-mail: info@foxtron.cz www: http://www.foxtron.cz Verze dokumentu

Více

Úvod...15. Používané konvence... 16. 1. Seznámení s Outlookem...17

Úvod...15. Používané konvence... 16. 1. Seznámení s Outlookem...17 Obsah Úvod...15 Používané konvence... 16 1. Seznámení s Outlookem...17 1.1 Novinky verze 2003... 17 1.1.1 Navigační podokno...17 1.1.2 Nabídka Přejít...17 1.1.3 Podokno pro čtení...18 1.1.4 Rozložení seznamu

Více

Projekt inovace vzdělávání na SOŠ a SOU Horky nad Jizerou. Pokyny pro zpracování ročníkové práce z předmětu FIKTIVNÍ FIRMA. Verze 1.

Projekt inovace vzdělávání na SOŠ a SOU Horky nad Jizerou. Pokyny pro zpracování ročníkové práce z předmětu FIKTIVNÍ FIRMA. Verze 1. Projekt inovace vzdělávání na SOŠ a SOU Horky nad Jizerou Pokyny pro zpracování ročníkové práce z předmětu FIKTIVNÍ FIRMA Verze 1.1 Tento projekt byl spolufinancován Evropským sociálním fondem a státním

Více

Tabulkové processory MS Excel (OpenOffice Calc)

Tabulkové processory MS Excel (OpenOffice Calc) Maturitní téma: Tabulkové processory MS Excel (OpenOffice Calc) Charakteristika tabulkového editoru Tabulkový editor (sprematuritníadsheet) se používá všude tam, kde je třeba zpracovávat data uspořádaná

Více

PREPROCESOR POKRAČOVÁNÍ

PREPROCESOR POKRAČOVÁNÍ PREPROCESOR POKRAČOVÁNÍ Chybová hlášení V C# podobně jako v C++ existuje direktiva #error, která způsobí vypsání chybového hlášení překladačem a zastavení překladu. jazyk C# navíc nabízí direktivu #warning,

Více

UML: Unified Modeling Language

UML: Unified Modeling Language UML 1 UML: Unified Modeling Language Systém kombinace softwaru, hardwaru, dat a uživatelů, která umožňuje řešení konkrétního problému Vývoj systémů vytváření systémů pro klienta Vývoj probíhá na základě

Více

Architektura aplikace

Architektura aplikace Architektura aplikace MARBES-JIRA plugin Tým: GRSS Členové: František Schneider Jaroslav Ráb Lukáš Gemela Jaromír Staněk Upravil Verze dokumentu Datum F. Schneider 1.0 25.3.2012 F. Schneider 2.0 25.4.2012

Více

Ostatní portálové aplikace

Ostatní portálové aplikace Akademický informační systém ŠKODA AUTO VYSOKÁ ŠKOLA o.p.s. Ostatní portálové aplikace Svazek 9 Verze: 1.20 Datum: 10. března 2016 Autor: Jitka Šedá, Martin Tyllich Obsah Seznam obrázků 5 1 Absolventi

Více

Ukázka knihy z internetového knihkupectví www.kosmas.cz

Ukázka knihy z internetového knihkupectví www.kosmas.cz Ukázka knihy z internetového knihkupectví www.kosmas.cz Fotbalová cvičení a hry druhé, doplněné vydání Hana Volfová, Jaromír Votík Ilona Kolovská Grada Publishing Ukázka knihy z internetového knihkupectví

Více

UŽIVATELSKÁ DOKUMENTACE. TS-ELDAx SMART TRUST electronic ARCHIVE Cloudové rozhraní

UŽIVATELSKÁ DOKUMENTACE. TS-ELDAx SMART TRUST electronic ARCHIVE Cloudové rozhraní UŽIVATELSKÁ DOKUMENTACE TS-ELDAx SMART TRUST electronic ARCHIVE Cloudové rozhraní SMLOUVA (PROJEKT) ČÍSLO: STÁDIUM: Schváleno ZAKÁZKA ČÍSLO: DŮVĚRNOST: Veřejné ZE DNE: DATUM AKTUALIZACE: ZPRACOVAL / AUTOR:

Více

Vývoj IS - strukturované paradigma II

Vývoj IS - strukturované paradigma II Milan Mišovič (ČVUT FIT) Pokročilé informační systémy MI-PIS, 2011, Přednáška 05 1/18 Vývoj IS - strukturované paradigma II Prof. RNDr. Milan Mišovič, CSc. Katedra softwarového inženýrství Fakulta informačních

Více

Návod na základní používání Helpdesku AGEL

Návod na základní používání Helpdesku AGEL Návod na základní používání Helpdesku AGEL Úvod Přihlášení Nástěnka Vyhledání a otevření úlohy Otevření úlohy Seznam úloh Vyhledávání úloh Vytvoření nové úlohy Práce s úlohami Editace úlohy Změna stavu

Více

Helios RED a Internetový obchod

Helios RED a Internetový obchod (pracovní verze!) Helios RED a Internetový obchod Obsah dokumetace: 1. Úvod 2. Evidované údaje na skladové kartě 3. Přenos skladových karet z Helios RED do e-shopu 4. Přenos objednávek z e-shopu do Helios

Více

Třídní vzdělávací plán ŠVP PV Rok s kocourkem Matyášem

Třídní vzdělávací plán ŠVP PV Rok s kocourkem Matyášem Třídní vzdělávací plán ŠVP PV Rok s kocourkem Matyášem Integrovaný blok Tématický okruh (celek) Témata Co je nám nejblíže To jsou moji kamarádi CO JE KOLEM NÁS Co najdeme v naší třídě Už znáš celou školku

Více