Elektronická tídní kniha

Elektronická tídní kniha Electronic class register Bc. Tomáš Dudek

UTB ve Zlín, Fakulta aplikované informatiky, 2007 5 ABSTRAKT Dokument popisuje využití výpoetní techniky k vedení tídní knihy, nikoliv její nahrazení. Dvodem je snaha tento proces co nejvíce zjednodušit a zefektivnit. Práce je rozdlena do nkolika ástí. První z nich je vnována popisu použití klasické tídní knihy. Další ást se zabývá porovnáním klasické tídní knihy s existujícími elektronickými podobami tohoto dokumentu a návrhem vlastního systému. Obsahem práce je vytvoení uživatelského rozhraní a toho, co vše je nutné vytvoit, aby výsledná aplikace splnila obecn platná kritéria na vzhled a použitelnost. Nejvtší draz je vnován speciáln návrhu webových aplikací, které mají svá specifika a popisu jednotlivých technologií pro vývoj webových aplikací. Toto prostedí je zvoleno zámrn z dvodu obliby mezi poítaovými uživateli. Ti se s ním mohou setkat takka na každém kroku nejen v podob internetových stránek, ale napíklad i v rzných formuláích, hrách i v podob rozhraní pro konfiguraci síového hardwaru, jako jsou routery, ADSL modemy a jiná nejen síová zaízení. Dokument popisuje použité technologie, zejména ASP.NET, Framework a jeho specifika. Klíová slova: ASP, PHP, server,.net, Framework, webová aplikace, tídní kniha

UTB ve Zlín, Fakulta aplikované informatiky, 2007 6 ABSTRACT This document describes how computers can be used to manage a class register but not to replace it. The reason is to make this process simpler and more effective. This paper is divided into several parts. The first part describes the procedure of using the standard class register. The next part compares the standard class register with existing electronic registers and my proposed system. This paper elaborates the design of a user interface and all the conditions that must be met in order for this application to meet the generally accepted appearance and usability criteria. The biggest emphasis is on the design of web applications and their specifics as well as the description of technologies used in developing web applications. I have selected this tool because of its great popularity among computer users. They can encounter this tool virtually everywhere; not only as web pages but also as various web forms, games and configuration interfaces for network hardware such as routers, ADSL modems and other network equipment. This document describes used technologies, particularly ASP.NET, Framework and its specifics. Keywords: ASP, PHP, server,.net, Framework, web application, class register

UTB ve Zlín, Fakulta aplikované informatiky, 2007 7 Podkování: Dkuji ing. Petrovi Neumannovi Ph.D. za odborné vedení, cenné rady a pipomínky, které jsem uplatnil pi psaní diplomové práce. Motto: Tajemství úspchu lovka spoívá ve zvyku dlat to, co neúspšní lidé dlají neradi. A.Jackson King

UTB ve Zlín, Fakulta aplikované informatiky, 2007 8 Prohlašuji, že jsem na diplomové práci pracoval samostatn a použitou literaturu jsem citoval. V pípad publikace výsledk, je-li to uvolnno na základ licenní smlouvy, budu uveden jako spoluautor. Ve Zlín. Podpis diplomanta

UTB ve Zlín, Fakulta aplikované informatiky, 2007 9

UTB ve Zlín, Fakulta aplikované informatiky, 2007 10 OBSAH ÚVOD... 12 1 TEORETICKÁ ÁST... 13 TÍDNÍ KNIHA... 14 1.1 KLASICKÁ PODOBA TÍDNÍ KNIHY... 14 1.2 TÍDNÍ KNIHA JAKO POVINNÝ DOKUMENT... 19 1.3 ELEKTONICKÁ PODOBA TÍDNÍ KNIHY... 20 1.3.1 Bakalá systém pro administrativu školy... 21 1.3.2 Projekt Škola OnLine... 22 1.3.3 Záškolák žákovský informaní a docházkový systém... 23 1.4 ELEKTRONICKÁ TÍDNÍ KNIHA V PRAXI... 24 2 VÝBR VHODNÉ TECHNOLOGIE PRO RELIZACI PROJEKTU... 25 2.1 WEBOVÁ APLIKACE... 25 3 2.2 VÝPOETNÍ MODELY... 27 2.2.1 Klient server... 27 2.2.1.1 Ti druhy inností... 28 2.2.2 Dvou versus tíúrovová architektura... 30 2.2.3 Tencí bohatí klienti, technologie Java a.net... 31 2.2.3.1 Výhody vícevrstvé architektury... 31 2.2.3.2 Tenký bohatý klient... 31 2.2.3.3 Technologie Java a.net... 32 2.2.3.4 Další klientská prostedí... 32 SPECIFIKACE POŽADAVK... 33 3.1 ZDROJE POŽADAVK... 33 3.1.1 Požadavky na systém elektronické tídní knihy... 34 3.2 PÍPADY UŽITÍ... 36 3.2.1 Aktéi... 36 3.3 NAVRŽENÉ PÍPADY UŽITÍ... 37 3.4 GRAFICKÉ UŽIVATELSKÉ ROZHRANÍ... 39 4 PRAKTICKÁ ÁST... 40 POUŽITÉ TECHNOLOGIE PI REALIZACI PROJEKTU... 41 4.1.NET... 41 4.1.1.NET framework... 41 4.1.2 Operaní systém a Framework... 42 4.2 ASP.NET 2.0... 43 4.2.1 Výhody ASP.NET oproti pedchozí verzi ASP... 44 4.2.2 Stavové prostedí nad bezstavovým protokolem... 44 4.3 UKÁZKY KÓDU ASP... 45 4.3.1 C# nebo Visual Basic... 45

UTB ve Zlín, Fakulta aplikované informatiky, 2007 11 5 4.3.2 Dva oddlené pístupy psaní kódu... 45 4.3.3 Stavební lánky webové aplikace... 46 4.3.3.1 Ovládací prvek PlaceHolder... 46 4.3.4 Pedávání hodnot z pedchozí stránky... 47 REALIZACE DATOVÉHO MODELU... 49 5.1 ER-DIAGRAM ELEKRONICKÉ TÍDNÍ KNIHY... 49 6 POPIS PROGRAMU... 52 6.1 SPUŠTNÍ APLIKACE... 52 6.2 ÚVODNÍ STRÁNKA APLIKACE... 52 6.3 PIHLÁŠENÍ DO SYSTÉMU... 54 6.4 ADMINISTRÁTORSKÉ INNOSTI... 55 6.4.1 Nastavení školního roku... 55 6.4.2 Evidence student... 56 6.4.3 Tídy... 57 6.4.4 Pedmty... 58 6.4.5 Místnosti... 58 6.4.6 Zamstnanci... 58 6.4.7 Uživatelské úty... 59 6.4.8 Správa rozvrhu... 59 6.5 TÍDNÍ KNIHA... 61 6.5.1 Zápis do tídní knihy... 61 6.6 KONTROLA ABSENCE... 62 6.7 VIZUALIZACE ROZVRHU... 62 7 MINIMÁLNÍ INSTLACE A DMINISTRACE WEBOVÉHO SÍDLA... 65 7.1 VÝBR OPERANÍHO SYSTÉMU... 65 7.2 INSTALACE WEBOVÉHO SERVERU... 65 7.2.1 Instalace IIS pro Windows 2000/XP... 66 7.2.2 Instalace IIS pro Windows Server 2003... 67 7.2.3 Virtuální adresáe... 69 7.2.3.1 Pojem virtuální adresá... 69 7.2.3.2 Vytvoení virtuálního adresáe pro aplikaci ASP.NET... 70 7.2.4 Registrace ASP :NET pro Internet information service... 71 7.3 INSTALACE DATOVÉHO SKLADU... 72 ZÁVR... 73 THE CONCLUSION... 74 SEZNAM POUŽITÉ LITERATURY... 75 SEZNAM POUŽITÝCH SYMBOL A ZKRATEK... 77 SEZNAM OBRÁZK... 78 SEZNAM TABULEK... 79

UTB ve Zlín, Fakulta aplikované informatiky, 2007 12 ÚVOD V dnešní dob se stále více mluví o rozmachu poíta. Nejedná se jen o technické vybavení poítae, ale pedevším o programové vybavení ureném snad již pro všechny odvtví lidského života. Již dnes existují lidé, kteí si neumjí pedstavit teba jen jediný den bez poítae. Vtšina uživatel používá své zaízení jako komunikaní prostedek, na práci, pro zábavu a jako zdroj informací. Ale asi nejvtším dvodem, pro tak velký rozmach poítaových systém je jejich vzájemné propojení pomocí poítaové sít. Což uživateli dává obrovské možnosti využitelnosti a zapojení výpoetní techniky do rzných odvtví lidské innosti, tedy i do školských dokument. Tato práce je zamena na software urený pro pedagogickou innost a pedevším vytvoení aplikace pro elektronickou tídní knihu pomocí webové aplikace. Vývoj samotné aplikace jde rozfázovat do nkolika ástí. Zaprvé musíme stanovit požadavky na aplikaci. Toto provedeme na základ analýzy dostupných dokument o klasické papírové tídní knize, její tvorb, pravidlech vedení a možnostech moderního pístupu k ní. Také je nutné porovnat klasické tídní knihy a již existující podoby elektronických tídních knih. V neposlední ad získání informací od svých koleg uitel, kteí budou vhodný zdrojem námt a pípadné kritiky. Zadruhé musíme nalézt vhodný nástroj pro tvorbu aplikace, aby její použitelnost byla co nejhodnjší. Tato ást práce zahrnuje seznámení se s technologií pro vývoj aplikací, s jednotlivými programovacími jazyky, pístupu k tvorb databázi a práci s ní. Tato ást je velice dležitá. Musíme porovnat klady a zápory. Další krok obsahuje postupy vývoje aplikace, tvorba jednotlivých ástí a jejich propojení. Závreným krokem je zavedení aplikace do praxe, vetn popisu funkcí a instalace.

UTB ve Zlín, Fakulta aplikované informatiky, 2007 13 I. TEORETICKÁ ÁST

UTB ve Zlín, Fakulta aplikované informatiky, 2007 14 1 TÍDNÍ KNIHA Snad každý si ze svých mladých let pamatuje tídní knihu. Nkteí si lépe i he vybaví, jak vypadá a emu slouží. Nejprve trochu teorie, popíšeme si, jak taková kniha vypadá. Každé školské zaízení musí dle zákona, dokonce i mateské školy vést tídní knihu. Studenti školského zaízení jsou rozdleni do skupin, kterým se íká tídy. Tída školského zaízení má svou tídní knihu, která slouží pro zaznamenávání rzných dat. Každá tídní kniha je jednoznan identifikovaná jménem tídy, školním rokem. 1.1 Klasická podoba tídní knihy Tídní kniha je dležitou souástí školních tiskopis. Její vyplování se ídí uritými pravidly. Mezi nejhlavnjší pravidla patí, že se v dokumentu se nic neškrtá ani nepepisuje. Další pravidla ídí, kdo do tídní knihy zapisuje a jakým zpsobem [1.]. Tídní kniha se skládá z tchto ástí: 1. Obal 2. Pední strana 3. Seznam pedmt 4. Hospitace a inspekce ve tíd 5. Seznam žák 6. Týdenní zápis 7. Zasedací poádek a rozvrh hodin 1. Obal Obsahuje jméno tídy a školní rok. Slouží pouze k informativním úelm, které vypíše tídní uitel na zaátku školního roku. Na této stran se v prbhu roku nevpisují ani neupravují stávající údaje (obr. 1 ).

UTB ve Zlín, Fakulta aplikované informatiky, 2007 15 Obr. 1. Obal tídní knihy 2. Pední strana Obsahuje úplný název školy s kódem školy, zkrácený název školy, název studijního oboru s jeho kódem, zamení oboru, IZO, jméno tídy, školní rok, podpis tídního uitele a editele školy, kulaté razítko školy. Tato strana opt slouží k informaním úel a vypisuje je tídní uitel. Velice dležité je zde kulaté razítko školy a podpisy (obr.. 2). Obr. 2. Pední strana tídní knihy

UTB ve Zlín, Fakulta aplikované informatiky, 2007 16 3. Seznam pedmt Strana je rozdlena na dv ásti.v první ásti jsou vypisovány povinné pedmty, v druhé ásti jsou nepovinné pedmty. U každého pedmtu je vypsán jeho celý název, zkratka a podpis vyuujícího s údajem, od kdy pedmt ve tíd vyuuje. Název pedmt a zkratku vypisuje tídní uitel na zaátku roku. Každý vyuující má za povinnost se podepsat, zapsat datum na zaátku vyuování. Pokud dojde bhem roku k výmn vyuujících, také další vyuují má za povinnost se podepsat a napsat datum zahájení výuky (obr. 3 ). Obr. 3. Seznam pedmt 4. Hospitace a inspekce ve tíd Tato strana slouží k informaci o hospitaci nebo inspekci provedené ve tíd. Osoba na inspekci i hospitaci je povinna vypsat datum, název pedmtu, jméno uitele a také se podepsat (obr. 4). Obr. 4. Hospitace a inspekce ve tíd 5. Pehled docházky Seznam se skládá ze dvou stran. Na první stran existuje seznam žák dle abecedy, jejich jméno i píjmení, informace o dojíždní do školy a týdenní souet absence. Tato strana slouží

UTB ve Zlín, Fakulta aplikované informatiky, 2007 17 pro první pololetí. V poslední kolonce je celkový souet jak omluvených, tak i neomluvených hodin žáka. Na druhé stran již není seznam žák, ovšem pokrauje zde tabulka pro souet zameškaných hodin v jednotlivých týdnech. Opt je zde celkový souhrn omluvených i neomluvených hodin za druhé pololetí. Dále zde nalezneme místo pro poznámku o nepovinných pedmtech jednotlivých žák, rozdlení do skupin a další poznámky. Tyto informace zapisuje tídní uitel i zástupce tídního uitele (obr. 5. a 6. ). Obr. 5. Docházka list 1. Obr. 6 Docházka list 2. 6. Týdenní zápis V tídní knize obsahuje 41 týdenních výpis. Každý výpis se skládá ze dvou list. V záhlaví stánek nalezneme íslo týdne, msíc, školní rok a poádkovou službu z ad žák tídy. List je rozdlen na 5 hlavních tabulek jednotlivé dny s datem. Dny jsou rozdleny do hodin. Každý vyuující je povinen na zaátku hodiny provést zápis názvu pedmtu ve zkratce, poadové íslo hodiny pedmtu, probírané uivo a podepsat se. Druhou dležitou ást tvoí seznam nepítomných žák v jednotlivých hodinách. Jména se píší do sloupce pod sebou, pi vtší absenci se mohou napsat dva žáci na jeden

UTB ve Zlín, Fakulta aplikované informatiky, 2007 18 ádek. Nepítomnost tohoto žáka se úhlopín vyškrtne. V neposlední ad je zde také místo pro poznámky vyuujících jak k chování jednotlivých žák, tak i k sdlením. Tídní uitel má za povinnost vypisovat íslo týdne vypsat íslo týdne, msíc a rok, datum u jednotlivých dn a jména žák povených službou. Postupn musí vyplovat kolonky u absence žák. Omluvení nepítomnosti vyznaí peškrtnutím úhlopíky. Také musí zapsat souet omluvených a neomluvených hodin s dvodem absence (obr. 7 a 8). Obr. 7. Týdenní zápis 1. Lis t Obr. 8. Týdenní zápis 2. list 7. Zasedací poádek a rozvrh hodin Tato strana slouží k informaci pro žáky i pro uitele. V první ásti jsou zapsány jména žák dle jednotlivých lavic ve tíd. V druhé ásti je prostor pro rozvrh hodin na 1. i 2. pololetí (obr. 9 ).

UTB ve Zlín, Fakulta aplikované informatiky, 2007 19 Obr. 9. Zasedací poádek a rozvrh hodin 1.2 Tídní kniha jako povinný dokument Tídní kniha patí mezi povinnou dokumentaci školy. Pravidla její podoby jsou v zákon. 561/2004 Sb. O pedškolním, základním, stedním, vyšším odborném a jiném vzdlávání (školský zákon) 28 odst. 1 Dokumentace škol a školských zaízení a ve znní pozdjších pedpis. Je zaazena do druhé kategorie tiskopis : Tiskopisy vzor SEVT - alternativní formou schválených tiskopis SEVT jsou výstupy z poítae na kanceláský papír a tiskopisy ostatních vydavatelství za pedpokladu, že bude dodržen schválený vzor SEVT. Platnost od školního roku 1989/1990 (tídní knihy, tídní výkazy, protokoly..). [1.] Z tchto zákon vyplývá: Tídní kniha patí mezi povinné dokumentace. seznam dokumentace pro školy je každoron aktualizován a uveejován na Vstníku MŠMT R. Zmny v textových ástích tiskopis jsou každoron uvádny v Seznamu povinné dokumentace škol a v Kupních smlouvách SEVT. Poítaové zpracování tídních výkaz je možné za pedpokladu, že bude souasn vytváena listinná kopie dokument a dodržena vcná schoda poítaového a runího zpracování tiskopis. Pro usnadnní tisku tídních výkaz je možné vytvoit každé pololetí souhrnou tabulku hodnocení prospchu a chování tídy a na závr studia nebo pi pestupu žáka na jinou školu doplnit jednotlivým žákm hodnocení prospchu

UTB ve Zlín, Fakulta aplikované informatiky, 2007 20 a chování. Tabulka hodnocení tídy se stanou souástí dokumentace a budou rovnž archivovány. Poznámky, které nebudou psány run, opatí tídní uitel parafou. Tato podmínka vstoupila v platnost od školního roku 1999/2000. Dle zákona o osobních údajích.. 256/1999 Sb., o ochran osobních údaj v informaních systémech a 8 zákona. 106/1999 Sb., o osobním pístupu k informacím a zákonu. 101/2000 Sb., o ochran osobních údaj a o zmn nkterých zákon od školního roku 2001/2002 nebudou školní tiskopisy obsahovat kolonku o národnosti. Vzory tiskopis povinné dokumentace škol a školských zaízení jsou uveejnny na internetových stránkách MŠMT v oddílech pedškolní, speciální, základní, stední a vyšší odborné školství. 1.3 Elektonická podoba tídní knihy V pedchozí kapitole si mžeme peíst vtu o tom, že je možné používat elektronickou podobu písemností, jestliže existuje vcná shoda s originálními písemnostmi. K emu tedy mít klasickou tídní knihu a ješt mít elektronickou podobu tch samých informací? Odpov je snadná i v tak jednoduchém systému jako je evidence tídní knihy, lze nalézt spoustu dležitých informací. Napíklad který vyuující co, kde a kdy uí, zda student byl pítomen výuce, co která tída práv probírá, kolik asu vnuje opakování, kdy vyuující naposledy psal s tídou písemnou práci, a tak dále. Podle mého názoru nejvíce možností skýtá evidence absence, kde je možné jednoduše zjistit, kdo a kdy ze student tídy chybl. Je možné vysledovat a vytvoit si jasný pohled na studenta a jeho docházku. A to zda je jeho absence nahodilá nebo cílená. Dochází-li ze strany studenta k záškoláctví a vyhýbání se výuce nebo jen uritému pedmtu. Pokud vyuující bude mít nástroje na jasnou analýzu studentovi docházky, je možné pedejít rzným prospchovým problémm studenta a vzájemným konfliktm mezi ním a vyuujícím. V dnešní dob se již na trhu vyskytuje nkolik podob elektronické tídní knihy. Vtšinou se jedná o pídavný modul k evidenci žák a jejich klasifikace. Ovšem stále se jedná jen o první vlaštovky. Jejich uplatnní v praxi se ukáže až asem. Je tu stále mnoho pekážek, které tyto programy budou muset pekovat, než se dostanou do každodenní souásti uitelova života.

UTB ve Zlín, Fakulta aplikované informatiky, 2007 21 Jedná se pedevším o tyto pekážky: - Špatná vybavenost škol technickým vybavením - Neochota zavádt a uit se nové vci z ad starších uitel - Špatná informovanost o novinkách Ovšem tyto pekážky se již na nkterých školách pekonávají a i výuka dostává nový pohled. K pekonání první pekážky velice pomáhá ochota MŠMT R, které se snaží zavést do škol nové inovativní prvky jak do výuky, tak i do ešení problém s dokumentací. V dalších kapitolách se seznámíme se temi programy, které umožují vést elektronickou tídní knihu. Jsou velice rozlišné, jak pro náronost finanní, tak i typem ovládáním. Jedná se o programy: - Škola OnLine - Bakalá - Záškolák 1.3.1 Bakalá systém pro administrativu školy Jedná se o program, který pokrývá prakticky všechny oblasti školní administrativy [2.]. Program se skládá z nkolika modul. Mezi základní moduly patí: - Evidence žák a zamstnanc - Pijímací zkoušky, Knihovna, Inventarizace,... - Grafické zpracování klasifikace - Rozvrh hodin, Suplování, Plán akcí školy - Rozpis maturit - Tematické plány - Web - informaní modul pro rodie a žáky - Web - uitelé - Tídní kniha V dnešní dob je tento program velice rozšíen do škol. Mezi jeho výhody patí lehké rozšíení dokumentace o potebné údaje a také potebné prbžné aktualizace novinek.

UTB ve Zlín, Fakulta aplikované informatiky, 2007 22 Mezi novinky patí modul tídní kniha, který je dnes jen v beta verzi a s jeho zaazení do prodeje se poítá od píštího školního roku. Ta nám umožuje zadávat nepítomnosti žák v jednotlivých hodinách, dnech a týdnech, její rozlišení v teoretické a odborné výuce. Lehké sledování absence v jednotlivých pedmtech. Tisk pehled absence v jednotlivých obdobích, vetn pekroení nastaveného limitu v jednotlivých pedmtech. Zadaná absence je zobrazována ve webové aplikaci Informaní modul pro rodie. Je propojena nejen s modulem Web informaní modul pro rodie a žáky, ale také s modulem Rozvrh a Suplování. 1.3.2 Projekt Škola OnLine Projekt je tvoen pod záštitou MŠMT [3.]. Škola OnLine je nejen informaním zdrojem pro školy, je také komunikaním nástrojem on.line mezi školou a rodii. Je rozdlen na nkolik sekcí. Zpsob pístupu k informacím a jejich zabezpeení: Každý rodi nebo student, který pistupuje k žákovské, má své osobní heslo, pomocí kterého má pístup pouze k tm informacím, které jsou pro nj ureny. Díky tomu jsou pro žáka dostupné pouze jeho vlastní výsledky a pro rodie pouze výsledky jeho dtí. Možnosti žákovské sekce (obr. 10 ): - Docházka - pehled docházky žáka v celém školním roce - Hodnocení - výsledky žáka v pedmtech - Plány hodnocení - pehled zkoušení, která žáka v nejbližší dob ekají - Rozvrhy - aktuální rozvrh žáka i celé jeho tídy - Komunikace - prostednictvím e-mailu nebo SMS zpráv automatické odesílání informací o známkách a docházce pomocí e-mailu nebo na váš mobilní

UTB ve Zlín, Fakulta aplikované informatiky, 2007 23 Obr. 10. Princip žákovské sekce 1.3.3 Záškolák žákovský informaní a docházkový systém Systém vyrábí plzeská firma NetPro systems, spol. s r.o. Je tvoen v rámci projektu Metla na záškoláky [4.]. Systém umožuje kontrolu nad docházkou, studijními aktivitami a prospchem žák. Poskytuje okamžitý pehled rodi o chování jejich dtí. K systému je nutné vybavit školu snímacími terminály a poítaovou sítí. Projekt je rozdlen do tí sekcí pro uitele, pro rodie a pro žáky. - Rodim umožuje aktivn sledovat studijní aktivity svých dtí. - Uitelm dává nástroj pro plánovité uplatování uebních osnov. - Žákm nabízí prostor pro aktivní vzdlávání bez zbyteného stresu s podporou informovaných rodi. Celý systéme je rozdlen do dvou ástí: 1. Žákovský docházkový systém Žák-student získá pi nástupu do školy registraní prkazku urenou k jeho bezdotykové identifikaci v rámci docházkového systému školy. Po píchodu do budovy školy se žák-student zaregistruje u instalovaných bezdotykových terminál. Tím je do systému zanesena informace o jeho pítomnosti, která se zakládá do docházkového listu každého žáka-studenta. Vyhodnocování docházky žák je stžejním kritériem pro navazující funkce jak ve sfée škola-uitel tak ve sfée rodi Výsledky statistik vedených nad docházkovými listy žák z jedné tídy nebo skupiny jsou vedeny jako Elektronická tídní kniha.

UTB ve Zlín, Fakulta aplikované informatiky, 2007 24 2. Školský informaní systém. Informaní systém školy pedstavuje soubor intranetových služeb pístupných pomocí bžného internetového prohlížee. 1.4 Elektronická tídní kniha v praxi Hlavním zámrem mé diplomové práce je vytvoit program tídní kniha. Tuto aplikaci jsem vytvoil na podklad kladených požadavk na školské dokumenty. Díky tomu, že vyuuji na stední škole, a ochot mých spolupracovník a vedení školy jsem ml i možnost svou aplikaci pedvést svým kolegm a vyzkoušet ji v praxi. Naše škola je rozdlena na nkolik budov. V naší budov si žijeme z velké ásti vlastním životem, máme zde jen 8 tíd, proto zde mže vyuovat z velké ásti stálá skupina vyuujících a je vytvoen vlastní rozvrh hodin. Po technické stránce jsme docela dobe vybaveni. V budov máme uebny výpoetní techniky a projektory, penosné projektory s notebooky a samozejm zde nechybí internetová sí s wifi. Velká ást uitel zaíná využívat moderních výukových prostedk ve výuce, tedy i notebook s projektorem a pipojením na internet. Proto nebyl tak velký problém zauit je pro práci s elektronickou tídní knihou. Tento nápad se ásti vyuujícím zamlouval, ovšem stále se vyskytují jedinci, kteí nechtjí zavádt nové vci a pedevším u nich chybí ochota nemu novému se uti, pedevším, pokud se to týká výpoetní techniky. ást spolupracovník využívalo nkolik dní mj program. Jejich odezva byla vtšinou kladná. Ovšem i problémy se vyskytly. Nkteré chyby programu se odhalili až pi dlouhodobjším využívání. Informace od spolupracovník o nalezených chybách a problémem pi práci však jsou velice dležité a zakládá se na nich další konfigurace programu. Doufám, že v budoucnu bude naše škola moci využívat více informaních systém nejen k vnitním záležitostem, ale i ke komunikaci s žáky a rodii pomocí internetu.

UTB ve Zlín, Fakulta aplikované informatiky, 2007 25 2 VÝBR VHODNÉ TECHNOLOGIE PRO RELIZACI PROJEKTU Výbr vhodného technologie pro realizaci projektu, je jedna z klíových operací, kterou nelze podcenit. Výbr nevhodné technologie mže znamenat velké problémy jak pi vývoji, implementaci, tak i provozu systému. Vzhledem k mé orientaci na produkty firmy Microsoft, mám do jisté míry omezený výbr. Nicmén i v tom to segmentu se dá najít vhodné prostedky pro vývoj takovéto aplikace. Vzhledem k dlouhodobé zkušenosti s vývojovým prostedím Visual Studio, jsem volil cestu nejmenšího zla a zstal jsem jí vrný i nadále. Nicmén ml jsem nutkání poznat nco nového a nakonec jsem si vybral vývojové prostedí postavené na technologii.net a to konkrétn Visual Studio 2005. Dalším pomrn velkým dilematem bylo rozhodnout se pro vytvoení klasické desktopové aplikace, nebo rovnou vytvoit webovou aplikaci. Odpov se zprvu nezdála zcela jednoznaná, bylo zde hodn plus nová zabhnutá technologie, silná podpora atd., ale na druhé stran bylo nkolik mínus, kterých jsem se pi vývoji obával pece jenom webová aplikace se trochu jinak chová, složitjší vývoj, implementace. Nakonec pevládly klady nad zápory a vybral jsem webovou verzi aplikace. Ješt než se pustíme do realizace konkrétní aplikace, nejprve v další ásti popíši nkteré dležité pojmy. 2.1 Webová aplikace Webová aplikace je podle definice klient/server software, který komunikuje s uživatelem nebo jiným systémem prostednictvím protokolu HTTP. Za klienta používají uživatelé nejastji webové prohlížee, jako je Internet Explorer, Mozilla nebo Opera. Automatizované systémy, napíklad roboti fulltextových vyhledáva, pak pistupují s pomocí HTTP agent. Klient na základ interakce s uživatelem zasílá serveru jednotlivé požadavky a následn zobrazuje obdržené webové stránky zapsané zpravidla v jazyce (X)HTML. Rozsah aplikací poskytovaných služeb se mže pohybovat od jednoduchých úloh, jakými je napíklad kniha host, až po složitjší a programy typu elektronické obchody, nebo bankovní aplikace.

UTB ve Zlín, Fakulta aplikované informatiky, 2007 26 Je možné vymezit skupinu funkních požadavk, které jsou spolené pro tém všechny pokroilejší webové aplikace. Jejich podpora pímo v používaných programovacích jazycích ale asto nativn neexistuje vbec, nebo je pouze ástená i nedostatená. Potebné funkce si musí vývojá doprogramovat sám. Naštstí pro naprostou vtšinu takových úloh existují již hotové knihovny, které bývají i voln k dispozici. Ucelenjší soubor takových knihoven, zajišující komplexní funkcionalitu nutnou pro vývoj webové aplikace, tvoí framework. Neexistuje žádná ustálení a všeobecn pijímaná definice výrazu framework. Nejastji se však objevují dv základní pojetí tohoto výrazu. První pístup chápe framework jako balík užitených kód a knihoven, které ucelen a standardn pokrývají dané spolené požadavky aplikací. Jsou uloženy v njaké dostupné repository a programátor si do aplikace naítá jen ty vybrané knihovny, které zrovna potebuje, v závislosti na charakteru dané aplikace. V komplexní aplikaci tak pro ošetení njakého problému použije pokroilé a sofistikované knihovny, zatímco pro jednoduchou úlohu staí knihovna se základní funkností. Druhé pojetí je užší v tom smyslu, že vše výše popsané považuje jen za balík relativn samostatných navzájem nesouvisejících knihoven, nikoliv za framework. Framework vzniká práv až vhodným poskládáním tchto jednotlivých knihoven dohromady, jejich úelným provázáním. Vzájemnými interakcemi mezi nimi asto získáme dodatené funknosti, které se u izolovaných knihoven nemohou objevit. Tímto postupem se tedy vytvoí pevný rámec, framework, uvnit kterého se pak vyvíjí výsledná aplikace. Druhé pojetí má jednu zejmou nevýhodu. V takovém frameworku je pevn dán rozsah a komplexnost poskytovaných funkcí. Programátor aplikace má jen omezenou volnost výbru knihoven, kvli jejich vzájemné provázanosti se vždy musí použít naprostá vtšina z nich, a už jsou práv poteba, nebo ne. Jeden konkrétní takto pojatý framework se tak z hlediska složitosti a šíe poskytovaných služeb hodí jen pro uritou skupinu aplikací, které jej využijí. Napíklad tvoit primitivní knihu host v komplexním frameworku, který poskytuje podporu pro moduly, registrované uživatele, uživatelské skupiny, pístupová práva a ošetení timeoutu je jako jít s kanónem na vrabce. Naopak, pi výbru vhodného a odpovídajícího frameworku je tvorba výsledné aplikace zpravidla efektivnjší a systémovjší, než pi použití jednotlivých oddlených knihoven.

UTB ve Zlín, Fakulta aplikované informatiky, 2007 27 Nyní zkusme definovat základní funkní požadavky, které jsou spolené a typické pro vtšinu pokroilejších webových aplikací, a které by tedy ml komplexní framework njakým zpsobem zajišovat: vhodná architektura aplikace; modularita; zabezpeení aplikace; validace vstupních parametr; uživatelské autentizace a správa uživatel; sessions a entitní autentizace; autorizace a pístupová práva; jednotná databázová vrstva; logování událostí a akcí; validita výstupních stánek; maskování URL. 2.2 Výpoetní modely Server je v informatice obecné oznaení pro proces nebo systém, který poskytuje njakou službu. Služba je obvykle realizována nkterým aplikaním síovým protokolem, jako je napíklad http (web server) nebo LPD (tiskový server). Proces, který službu využívá, se nazývá klient, architektura, která používá tento princip, se nazývá klient server. 2.2.1 Klient server Výpoetní model klient server je vhodné chápat pedevším jako dlbu práce mezi dvma složkami a to serverem a jeho klientem. V dnešní dob, plné rznorodých aplikací, pitom mají ob složky velmi mnoho prostoru pro to, jak konkrétn si mezi sebou rozdlit jednotlivé úkoly. V dsledku toho je pak možné se setkat s více rznými variantami modelu

UTB ve Zlín, Fakulta aplikované informatiky, 2007 28 klient server, které se liší práv v tom, kolik toho nese na svých bedrech každá z obou složek. A krom toho, musí se vždy jednat práv a pouze o dv složky? Až doposud jsme za hlavní motivaci celého modelu klient server považovali snahu minimalizovat objem dat penášených po sítí mezi klientem a serverem. Imperativnost tohoto kritéria se v ase mže mnit, zejména v dsledku stále vtší dostupnosti penosových kapacit, a ke slovu se mohou významnjším zpsobem dostávat i další kritéria a motivace. Napíklad rzná implementaní hlediska související s tím, jak obtížné je prakticky implementovat tu kterou složku. Vždy poídit si výkonnjší hardware, i propustnjší penosové cesty, je dnes do znané míry již jen otázkou dostatku penz, zatímco zajištní všeho potebného pro vývoj i následný provoz aplikací mže být mnohem náronjší. A již jde o potebný knot how, vhodné vývojové nástroje, personální zajištní i schopnost vše koírovat. No a to samozdejmn také musí ovlivnit konkrétní formu dlby práce mezi servery a jejich klienty. 2.2.1.1 Ti druhy inností Výpoetní modely klient server je dnes nejastji využívanými aplikacemi, které spadají do široké, velmi vágn definované kategorie Informaních systém. Pedstavit si pod tím mžeme napíklad aplikace pro podporu nejrznjších agend rzných firem, institucí a dalších orgán. Od úetnictví, skladového hospodáství, až teba po systémy na podporu rozhodování. Všechny takové aplikace pitom mají nkteré spolené rysy. Napíklad se v nich vždy vyskytují njaká základní data, která musí být vhodným zpsobem uskladnna a souasn k nim musí být zajištn takový pístup, jaký vyhovuje povaze a charakteru samotné aplikace. Další nezbytnou souástí je pak njaká forma komunikace s uživatelem, spoívající ve sbru dotaz a jiných píkaz a povel od uživatele smrem k aplikaci, a na druhé stran i nezbytné zobrazování ( i honosnjší prezentaci) získaných výsledk. Dále zde musí být ješt tetí ást, která zajišuje všechno to, co je pro danou aplikaci specifické a konkrétní, neboli realizuje vlastní logiku celé aplikace. Napíklad pjde-li o úetnictví, jsou práv zde implementována všechna pravidla zpsobující správné promítnutí jedné úetní operace do všech út, podút, knih, list, kterých se to týká.

UTB ve Zlín, Fakulta aplikované informatiky, 2007 29 Zmínné ti druhy inností, které jsme si vymezili, jsou v rzných odborných pramenech oznaovány rzn. Nazname si zde alespo jednu terminologii, zavedenou prestižní konzultaní firnou The Partner Group: Presentation uživatelské rozhraní a komunikace s uživatelem (prezentaní innost) Application Function vlastní logika aplikace (aplikaní innost) Data Management správa dat Volba jedné konkrétní terminologie v závru pedchozího odstavce pitom nebyla náhodná, protože práv od zmínné konzultaní firmy Garten Group pochází zejm nepoužívanjší klasifikace možných zpsob dlby práce mezi klientem a serverem. Patí se napíklad: Distributed Presentation Zde jsou prezentaní innosti rozdleny mezi klientem a serverem, který navíc sám vykonává i všechny zbývající innosti. Na stran serveru se nejastji jedná o generování výstup ve znakovém režimu do textového okna, které ale ve skutenosti není nikde zobrazováno. Jeho obsah je místo toho penášen klientovi, a teprve ten jej zobrazuje uživateli, obvykle již v grafickém režimu emulujícím znakový režim textového okna. Analogicky pak pro obrácený smr, týkající se vstup od uživatele. Hlavní výhodou tohoto ešení, které se asi nejvíce blíží modelu host terminál je skutenost, že serverová ást aplikace mže používat standardní systémové prostedky pro zobrazování na znakových výstupních zaízeních. Repote Presentation Veškeré prezentaní funkce ponechány na klientovi, zatímco veškeré aplikaní funkce a funkce spojené se správou dat zajišuje server. Distributed Funkction Všechny prezentaní funkce jsou na klientovi, veškerá správa dat na serveru a o aplikaní funkce se ob složky dlí. Nkteré innosti související s vlastní logikou aplikace tedy zajišuje sám klient, zatímco zbývající obstarává server. Repote Data Management

UTB ve Zlín, Fakulta aplikované informatiky, 2007 30 Veškeré prezentaní i aplikaní innosti zajišuje klient, zatímco server se vnuje pouze správ dat. Distributed Data Base Vtšinu inností zajišuje klient (veškeré prezentaní innosti, aplikaní innosti), zatímco o udržení a správu dat se dlí se serverem. Jak již název této varianty napovídá, je tato varianta urena zejména pro podporu distribuovaných databází. 2.2.2 Dvou versus tíúrov ová architektura Základní premisou, kterou jsme až dosud u celého modelu klient server pedpokládali, je dlba práce mezi dva disjunktní subjekty, server a klient. Jak se ale tato dvousložkovost sluuje s tím, že vtšina aplikací, které z tohoto modelu vychází, musí zajistit ti hlavní okruhy inností? Nebylo by pirozenjším ešením používat složky ti? Pak by rozdlení kompetencí mezi n mohlo být velmi jednoduché a pirozené a nemuselo by vést nkdy k ponkud krkolomným zpsobm rozdlování tí vcí mezi dva subjekty. Nebylo by tedy koncepnjším ešením zavést tíúrovovou architekturu klient server místo stávající dvouúrovové? Pravdou je, že se tak dnes mnohdy již dje, pedevším u rozsáhlejších a náronjších aplikací povahy velkých informaních systém. Dochází zde totiž stále více k osamostatování databází a systém ízení bází dat a k jejich pesunu na pozadí nebo na samostatné poítae, které jsou optimalizovány pro provozování rzných databází. Výhodou je pak i skutenost, že aplikaní innosti, ve smyslu výše uvedené tíúrovové klasifikace, mohou být stále mén závislé na konkrétním databázovém stroji, díky pokrokm ve standardizaci zpsob komunikace s databázemi, napíklad díky jazyku SQL. Zajímavé a velmi perspektivní možnosti se pitom objevují i v oblasti prezentaních služeb. Zde se totiž doslova vnucuje myšlenka využití služby Word Wide Web, ze které se stále více stává univerzální klientská platforma využitelná pedevším pro prezentaní úely. S pomocí služby WWW je vcelku jednoduché postarat se o zobrazení výstup na uživatelov poítai a o sbr jeho vstup urených samotné aplikaci. Jediné, co je k tomu poteba, je zajistit realizace vhodné brány mezi aplikaní ástí samotné aplikace a WWW serverem, která bude zajišovat potebné konverze. Velkou výhodou pitom bude jednotné uživatelské prostedí, nebo koncový uživatel bude pistupovat

UTB ve Zlín, Fakulta aplikované informatiky, 2007 31 k rzným službám a systémm prostednictvím jednoho jediného uživatelského rozhraní, respektive prostednictvím jediného klientského programu WWW prohlížee (browseru). 2.2.3 Tencí bohatí klienti, technologie Java a.net Zatímco v architektue klient/server bží programy (pesnji aplikaní logika, business logika) na bohatých, dobe vybavených grafických klientech a s daty uloženými na serverech v centrálních databázích, na pelomu tisíciletí se zaala prosazovat centralizovaná koncepce s oznaením vícevrstvá architektura. 2.2.3.1 Výhody vícevrstvé architektury Zjednodušen lze íci, že jde o návrat po vývojové spirále k terminálovému provozu, jen o poznání dokonalejšímu, než jak jej znali pamtníci starých sálových poíta. Ve vícevrstvé architektue program bží na centrálních systémech vytvoených ze vzájemn spolupracujících aplikaních server. Na klientských stanicích se pouze zobrazují data a ovládací prvky pro styk uživatele s aplikací. Základní výhodou vícevrstvé architektury pi údržb programu je proto snadná údržba aplikací, daná již zmínnou centralizací. V pípad (nového) tenkého bohatého klienta se totiž krom výmny ásti centrální aplikace na aplikaním serveru as od asu provede - pln automaticky a pro uživatele skryt - jeho jednoduchá aktualizace (update) po síti. Opravy chyb, zmny verzí a drobná vylepšení program se již nemusejí složit provádt na tisících poíta, staí zde pouhá výmna píslušné ásti centrální aplikace na aplikaních serverech. Vzhledem k centralizaci tedy odpadají problémy spojené s distribuovaným zpracováním dat, jako je sehrávání datových soubor s následnou synchronizací a ztotožováním. S podporou nového technického vybavení (clustery, externí disková pole, grid-technologie a blade-servery) se snadno eší i problémy svázané se škálovatelností a se zálohováním informaního systému. 2.2.3.2 Tenký bohatý klient Uživateli se údaje asto zobrazují na koncovém terminálu (stanici), v univerzálním a snadno dostupném internetovém prohlížei (HTML), který nemá pílišné nároky na zdroje. Taková klientská stanice se proto nkdy také oznauje jako "tenký klient"

UTB ve Zlín, Fakulta aplikované informatiky, 2007 32 HTML. Souasný vývoj však ukazuje, že snížení komfortu ovládání aplikací, které je vynucené omezenými možnostmi jazyka HTML, je píliš znatelné. Zaíná se proto ím dál více objevovat komfortnjší koncové prostedí. Jedná se o klientské programy využívající pln grafické možnosti operaních systém k tomu, aby uživateli nabídly všechen ovládací komfort, na který je zvyklý ze starších systém klient/server. Aby se odlišili "noví" klienti z vícevrstvé architektury od "starých" (tlustých) klient z architektury klient/server, zavedl se ve vícevrstvé architektue také pojem tenký bohatý klient. Tento druh terminálových program lze vytváet jak v prostedí.net spolenosti Microsoft, tak i jako aplikace nebo applety v jazyce Java s využitím grafických knihoven Swing. Jedním z možných klient jsou i informaní kiosky, jaké jsou umístny napíklad na Ministerstvu práce a sociálních vcí. 2.2.3.3 Technologie Java a.net Pevládající technologie pro tvorbu vícevrstvých aplikací jsou dv, a sice.net spolenosti Microsoft a Java 2 Enterprise Edition (J2EE) spolenosti Sun Microsystems. Technologie.NET se uplatuje zejména v rámci operaního systému Microsoft Windows, technologii J2EE zase podporují firmy jako IBM, Oracle, Sun a další smrem k systémm Linux, Unix a Windows. Akoli jsou rozdíly mezi obma technologiemi znané, existuje naštstí spolená platforma, na níž se mohou technologie.net a J2EE domluvit. Jedná se o webové služby (Web Services) a s nimi spojené standardy XML (extended Markup Language), SOAP (Simple Object Access Protocol), UDDI (Universal Description Discovery and Integration) a WSDL (Web Service Definition Language). 2.2.3.4 Další klientská prostedí Ve vícevrstvé architektue se vedle tenkých klient na bázi osobních poíta a notebook stále více uplatují PDA (Personal Digital Assistant) a mobilní telefony. Malá mobilní zaízení se mohou pipojovat k informaním systémm bu bezdrátov prostednictvím služeb mobilních operátor, nebo pes klientskou stanici. návrhu systému elektronické tídní knihy

UTB ve Zlín, Fakulta aplikované informatiky, 2007 33 3 SPECIFIKACE POŽADAVK Specifikace požadavk znamenají popis jisté funknosti systému nebo jeho vlastností, které budou v systému implementovány, tedy požadavky, pání uživatel systému. Rozlišujeme pitom dva druhy základní typy požadavk: funknost specifické požadavky na funknost systému, ne-funkní specifikují jisté vlastnosti systému, pípadn podmínky omezující fungování systému. Specifikace požadavk musí vyjadovat, co by systém ml poskytovat, nikoliv jakým zpsobem se to bude provádt. Tato ást je asi nejdležitjší z celého návrhu a realizace projektu, také nejvíce podceovanou ástí návrhu. Je to mu tak z jednoho prostého dvodu, a to že pání zadavatele nebo uživatele se asto velice liší od výsledného díla programátora. 3.1 Zdroje požadavk Proces získávání požadavk od budoucích uživatel je pomrn nároný. Existují uživatelé, kteí mají již konkrétné pedstavu o funknosti systému a jsou schopni pesn specifikovat své požadavky a s programátorem se pesn domluvit jaké služby má systém poskytovat. Na druhé stran jsou uživatelé, kteí vývojái svou práci nijak neulehují a nejsou schopni jasn formulovat svá pání. Tito uživatelé nechávají vývojái uritou volnost pi návrhu a požadují dodání systému, který uspokojí všechny jeho nároky, aniž by spolupracovali na jejich návrzích. Zdroje požadavk: legislativa jsou situace, pi kterých se musíme ídit nkterými normami, které urují právní mantinely, jako je napíklad ochrana osobních informací požadavky zákazníka tato skupina je asi nejvtším zdrojem informací existující systémy uživatel do jisté míry slouží jako vhodný náhled na problematiku, kterou nkdo vytvoil ped vámi pracovní procesy uživatel uživatel provádí stále stejné operace, které se dají z automatizovat a ulehit tím pracovníkovi as na jiné dležité úkony

UTB ve Zlín, Fakulta aplikované informatiky, 2007 34 vlastní know-how pro danou problematiku jsou specifické obory, kdy programátor nejprve musí nastudovat a získat informace, aby sám byl schopen navrhnou to nejlepší ešení pro zákazníka, aby systém po jeho zavedení sploval specifické požadavky prostedí zákazníka a jeho softwarové a hardwarové vybavení programátor se musí rozhodnout, jakým zpsobem bude provádna implementace systému a zda bude moci využít prostedk, které má uživatel k dispozici. Pro úplnost si ješt uvedeme nefunkní požadavky, které sice neovlivují funknost systému, jsou dležité je brát na vdomí, protože tvoí okrajové podmínky ešení projektu. dodržení uritých standard, využití uritých komponent, rychlost odezvy systému na požadavek, nároky na výkonnost, zabezpeení systému, použitá architektura, atd. 3.1.1 Požadavky na systém elektronické tídní knihy Z takto jasn definovaných pravidel pro specifikaci požadavk vyplývají následující oekávání od systému. Je nutné evidovat základní informace o tchto skupinách a to: Informace o škole sem zejména patí název školy, který je jednoznaným identifikátorem školního zaízení, specifikace a struktura školního roku, která je klíová pro celou datovou strukturu aplikace. Hlavní závislost je v tom, že aplikace musí být schopná jednoduše znovu použitelná pro další zachycení školního období nejen pro souasné použití.

UTB ve Zlín, Fakulta aplikované informatiky, 2007 35 Informace o studentech zde se jedná o data související s existencí studenta, jako je jeho jméno a píjmení, rodné íslo pro jeho jednoznanou identifikaci v celém systému, samozejm je zde kladem draz na ochranu osobních dat, a proto by se rodné íslo nemlo vyskytovat jen tam, kde je to nutné. Dále pak adresa studenta, popípad další kontaktní informace. Informace o rodiích studenta je nutné vytvoit u každého studenta informace o jeho rodiích, které mají mít informaní charakter v pípad poteby komunikace s rodii studenta. Informace o zamstnancích zde se bude jednat pouze údaje sloužících pro interní poteby organizace. Každá zamstnanec musí být jednoznané identifikovatelný. Informace o pedmtech základní údaje o tom, které vyuovací pedmty se v dané organizaci vyuují. Tídy budou sloužit pro vytváení skupin student daného oboru. Informace, které bude nutno evidovat, pro vedení tídí knihy. Mezi tyto data patí obor vzdlávání, oznaení stídy a aktuální roník tídy. Mezi dležité informace bude nutné rozdlení student do skupin podle nutnosti vyuování nkterých pedmt nebo z dvodu kapacity odborných ueben. Místnosti slouží jako údaj, pro organizaci výuky, bude tedy nutné vytvoit systém identifikátor každé místnosti. Plánování rozvrhu školy tyto informace budou asi nejzásadnjší pro celou aplikaci. Zde je nutné podchytit všechny asové sledy výuky, využití uitel a obsazenost tídy. Tato evidence tvoí nejdležitjší ást návrhu a jeho konená podoba ovlivní podobou a funknost celého systému. Evidence tídní knihy pro každou tídu bude vytvoena tídní kniha. Tídí kniha bude obsahovat údaje o tom, kdy byla oduena jaká vyuovací hodina, kdo ji vedl, co bylo obsahem. U každé vyuovací hodin bude uvedena absence studenta.

UTB ve Zlín, Fakulta aplikované informatiky, 2007 36 Nefunkní požadavky Aplikace bude muset být pístupná odkudkoliv z interní sít školy, tak aby vyuující mohl pohodln jednoduše provést zápis do tídní knihy. Je nutné vytvoit jasné pravidla pístupu pro jednotlivé skupiny uživatel a zamezit tím neoprávnnému vstupu nežádoucích osob. Je nutné vytvoit aplikaci, která bude jednoduše ovladatelná a uživatelsky pívtivá, tak aby uživatel neml problémy s ovládáním systému. Pi své práci na projektu jsem nechal do jisté míry ovlivnit vlastními názory a požadavky na evidenci tídní knihy. Postupem práce jsme zjistil, že samotný návrh systému nebude, až tak jednoduchý a budu muset zakomponovat mnoho vcí a požadavk, s kterými jsem pi mém prvotním návrhu vbec nepoítal. 3.2 Pípady užití Pípady užití nkdy také oznaované jako užitné pípady. Snahou je pesn zachytit funknost, která bude budoucím informaním systémem pokryta a vymezují tak jednoznan rozsah prací. Každý pípad popisuje jeden z použití systému, tedy jednu funknost systému. 3.2.1 Aktéi Pojem aktér pedstavuje roli, ve které vystupuje uživatel v rámci jeho komunikace se systémem. Aktérem se nemyslí pouze jeden konkrétní lovk, ale celá skupina uživatel, kteí budou provádt popisovanou roly. Na druhé stran jeden fyzický uživatel mže vystupovat ve více rzných rolích. K jednomu aktéru mžeme asociovat více pípad užití. Pi návrhu si jednoznan musíme uvdomit, že aktérem musí být lovk nikoliv ást systému.

UTB ve Zlín, Fakulta aplikované informatiky, 2007 37 3.3 Navržené pípady užití Vzhled systému a jeho rozmanitosti, je nutné brát v potaz, že systém bude muset být njakým zpsobem chránn. Uživatelé, kteí budou aplikaci využívat, musí mít omezené pravomoci a omezený pístup k jednotlivým operacím. V zásad budou v systému použity tyto typy uživatel: Admin neomezený vládce celé aplikace. Bude mít za úkol zprávu celého systému. Bude mít nestarosti zprávu uživatel, tedy jejich vytváení, mazaní, editaci. Dále také definovat rozvrh. Uitel bude moci editovat stávající data o studentech a tídách, zápis do tídní knihy, omlouvat absenci. Student bude se jednat o nepihlášeného uživatele, který bude moci napíklad pouze prohlížet rozvrh. Rodi tento aktér bude moci po zadání ovovacího údaje prohlížet absenci svého dítte. Use Case (obr. 11) názorn popisuje uvedené pípady užití a vztahy mezi uživatelskými rolemi.

UTB ve Zlín, Fakulta aplikované informatiky, 2007 38 Obr. 11. Use Case pípady užití

UTB ve Zlín, Fakulta aplikované informatiky, 2007 39 3.4 Grafické uživatelské rozhraní Grafický vzhlede a zpsob komunikace s uživatelem jsou základními faktory, které ovlivují použitelnost a kvalitu programu. Grafický návrh vzhledu je kreativní vc, která se neustále vyvíjí a musí se do jisté míry pizpsobit novým trendm, které jej ovlivují. Pkný vhled nesmí být na úkor použitelnosti celého aplikace. Nejvtším z problém je zajistit kompromis mezi kvalitním zhledem a funkností. Není nikde definovány hranice, které urují, jak co má vypadat. Každý dnes vytvoený program používá pro interakci s uživatelem njaké grafické prostedí (Graphical User Interface). Pry jsou ty doby, kdy uživatel se musel smíit s ernou obrazovkou a celá interakce se probíhala pomocí píkaz v stupu a výstupu. Grafické uživatelské prostedí umožuje jednoduše a pehledn shromažovat informace od uživatele a opt je uživateli zobrazit. Základem GUI jsou standardní grafické prvky, které tvoí celé uživatelské rozhraní. Jednotlivé prvky jsou tvoeny tlaítky, textovými boxy, nabídkami, kontextové menu, seznamy atd. Grafické uživatelské prostedí do jisté míry pináší do aplikací jakýsi stereotyp, protože vtšina aplikací (asi 2 / 3) má stejný vzhled. Nicmén pro uživatele to je výhoda. Uživatel nemusí dlouho pemýšlet o tom, jak který prvek má vypadat a co má za úkol.

UTB ve Zlín, Fakulta aplikované informatiky, 2007 40 II. PRAKTICKÁ ÁST

UTB ve Zlín, Fakulta aplikované informatiky, 2007 41 4 POUŽITÉ TECHNOLOGIE PI REALIZACI PROJEKTU V této kapitole se podrobnji podíváme na technologie, které jsem použil pro vývoj aplikace. 4.1.NET.NET je zastešující název pro soubor technologií v softwarových produktech tvoících celou novou platformu, která je dostupná pro Web, Windows i Pocket PC. Pro tvorbu aplikací splujících tyto myšlenky vydal Microsoft Visual Studio.NET, které bylo oproti pedchozí verzi rozšíeno o snadné návrhy webových XML služeb.net, a.net Framework, zajišující prostedí potebné pro bh aplikací a nabízející jak spouštcí rozhraní, tak potebné knihovny, jako Java. Visual studio se skládá z jazyk Visual Basic, J#, C# a Managed C++. Tmito jazyky napsanou aplikaci pak mžete bez problém pevést do ASP.NET(Web) nebo pro pocket PC (.NET Compact Framework). 4.1.1.NET framework Pro innost webových stránek v ASP.NET 2.0 je teba komponenta zvaná Microsoft.NET Framework 2.0. Framework se stará o zabezpeující záležitosti, které díve museli vývojái asto ešit a dnes je považují za tak samozejmé a mnohdy si je ani neuvdomují. NET Framework se stará o nízkoúrovové a nezáživné povinností jakými jsou: správa pamti, vytváení a rušení objekt spouštní a zastavování vláken kódu bezpenost kódu a kontrola oprávnní k provádným operacím natahování potebných knihoven a komponent do pamti apod. O tyto tém neviditelné, ale velmi dležité operace se stará ást zvaná Common Language Runtime (CLR) viz obr. 12

UTB ve Zlín, Fakulta aplikované informatiky, 2007 42 Obr. 12. Vrstvy Framework Base Class Library (BCL) je knihovna obsahující nejastjší pomocné funkce práci se soubory, tídní, diagnostiku, síovou komunikaci apod. ADO.NET je knihovna pro prácis daty s možností jejich XML reprezentace. Dále jsou na obrázku dv knihovny pro vývoj uživatelského rozhraní Windows Forms pro desktopové aplikace a ASP.NET pro webové uživatelské rozhraní [5.]. Velmi dležitou ástí.net frameworku jsou podporované jazyky..net framework je jazykov nezávislý, pro libovolnou úlohu lze v podstat použít jakýkoliv z podporovaných jazyk. Asi nejastji používanými jazyk jsou C# a Visual Basic.NET, které jsou s dílny Microsoft. Je úpln jedno, který jazyk si vybereme, výsledek by ml být stejný, pokud jde o funknost i výkonnost. 4.1.2 Operaní systém a Framework.NET Framework je primárn uren pro majitele operaního systému Windows, vyžaduje se minimáln verze Windows 98. Jedná se komponentu, která se do systému doinstaluje. Komponenta se dá získat napíklad pomocí služby Windows Update, nebo stáhnout ze stánek firmy Microsoft. K dispozici je i verze.net Compact Framework (.NET CF) pro Pocket PC s operaním systémem Windows Mobile, která je s klasickou verzí kompatibilní a tak není nutné kompilovat rzné aplikace pro PC a PDA - na obou systémech bude aplikace

UTB ve Zlín, Fakulta aplikované informatiky, 2007 43 fungovat stejn. Jak již název napovídá,.net CF neobsahuje všechny objekty, funkce a metody z pvodního.net Frameworku GNU obdoba.net se nazývá DotGNU; její ást nazývaná DotGNU Portable.NET umožuje spouštt všechny.net aplikace na unixových platformách (Linuxu, BSD, Mac OS X, Solarisu, AIX) a dokonce pomocí nástroj Cygwin a Mingw32 i na Windows. V prostedí operaních systém Linux, UNIX, Mac OS X je ovšem k dispozici i sada nástroj kompatibilní pímo s Microsoft.NET pod názvem Mono. Tuto sadu nástroj však nevyvíjí firma Microsoft, ale v obvyklém duchu opensource skupina dobrovolných vývojá. 4.2 ASP.NET 2.0 ASP Active Serve Page jedná se o stránky vykonávané na stran serveru. V souasné dob se používá verze 2.0. Z pohledu komunikace mezi klientem a serverem je funguje ASP.NET stejn jako PHP. Požadavky na zobrazení webu jsou poslané na server, ten posléze vygeneruje kód HTML, který potom zašle klientovi. Když se na problém podíváme podrobnji, najdeme odlišnosti od typického serverového skriptovacího jazyka, protože ASP.NET a v nm vytvoené stránky se oznaují jako webové aplikace. Po pijetí požadavku od klienta server zkontroluje požadovanou aplikaci a vytvoí relaci pro práci aplikací. Aplikací se dá jednoduše naprogramovat, co má v daném okamžiku provádt. Vytvoí potebnou flexibilitu a úplnou kontrolu na tím, co se s aplikací dje. Prostedí pro vývoj ASP.NET aplikací poskytuje programátoru mnoho zjednodušení. Základním principem je technologie formulá. Kde je celý projekt ASP.NET postavený na formuláích a komunikace prostednictvím nich. Formulá potom obsahuje jednotlivé ovládací prvky a ty mají své události. K události prvku mžeme pidat jednoduše kód, který se má provést pi vyvolání události. Vznikem událostí, napíklad stiskem tlaítka, se provede odeslání požadavku na server a ten pak vrátí výsledek v podob HTML.