Zde bude zadání práce

Transkript

1 Zde bude zadání práce

2 2

3 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Diplomová práce E škola Bc. Ľubomír Mičko Vedoucí práce: Ing. Božena Mannová, Ph.D. Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpočetní technika Leden

4 4

5 Poděkování Na tomto místě bych rád vyjádřil poděkování své manželce a rodině za podporu a také Ing. Boženě Mannové, Ph.D. za vstřícný přístup a vedení. 5

6 6

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

8 8

9 Abstract The subject of this thesis is analysis and implementation of school register and students data evidence application focused on data collection for the UIV (Institute for Informations in Education). Result is a web application implemented as a SaaS (Software as a Service), which will be available to schools via internet. This work also includes evaluation of the coverage of existing applications. Abstrakt Cílem diplomové práce je analýza, návrh a realizace aplikační podpory pro evidenci školní matriky se zaměřením na sběr dat pro ÚIV (Ústav pro informace ve vzdělávání). Výsledkem je produkt - webová aplikace realizovaná jako SaaS (Software as a Service), do které se školy budou mít možnost registrovat a používat ji. Součástí práce je také vyhodnocení pokrytí této oblasti existujícími aplikacemi. 9

10 10

11 Obsah 1.Úvod Kontext zadání Vymezení cílů a rozsahu řešení Metodika Struktura práce Přehled cílů Analýza současného stavu Struktura škol a školských zařízení Proces sběru dat ÚIV Import dat do aplikace Matrika Formát a struktura souborů Termíny předání dat Okruhy údajů vedených v dokumentaci školy Struktura agregovaných údajů pro předání ÚIV Struktura individuálních údajů pro předání ÚIV Číselníky Platnost a historie změn údajů Procesy ve školní matrice Analýza existujících řešení Kriteria analýzy Bakaláři Škola OnLine Shrnutí Analýza a návrh realizace Software jako služba Požadavky na systém Funkční požadavky Nástroje pro evidenci školy a žáků Nástroje pro administraci formulářů, číselníků a uživatelů Požadavky na registrační proces Nefunkční požadavky Případy užití Cílová skupina uživatelů a role Diagram případů užití Evidence právnické osoby, součástí a žáků Administrace formulářů, číselníků a uživatelů Neregistrovaní uživatelé Programovací jazyk Vývojové prostředí, nástroje softwarového inženýrství Návrh architektury Běhové prostředí a aplikační server Databázový server Operační systém Diagram nasazení

12 3.7 Návrh implementace Vnitřní architektura implementace Prezentační vrstva Databázový subsystém Platnost a verzování Pravidla implementace entit Dynamické formuláře, uložení dat Našeptávač při psaní textu Statistická validace Oprávnění a bezpečnost Import Export Proces registrace Návrhové vzory Přehled technologií Datový konceptuální model Návrh uživatelského rozhraní Layout Základní prvky Realizace Popis a struktura implementace Nestandardní části řešení Generování XML výstupu pomocí Groovy skriptu Použití AJAX formuláře Uložení dat žáka Verzování Integrace Nastavení prostředí Aplikační server Databázový server Zabezpečení Zálohování a obnova dat Ukázka systému Testování Unit testing Zátěžové testování Konfigurace systému Přehled výsledků testů Testy použitelnosti Testovací scénáře Výsledky testů Závěr Příloha

13 1. Úvod 1.1 Kontext zadání Vzdělávací systém v České republice prošel v posledních letech řadou změn. Společně s pokrokem v oblasti informatizace se i v něm přistupuje k hledání efektivnějších metod na jeho řízení a nových možností sdílení informací. To má různou podobu od zpřístupnění klasifikace žáků jejích rodičům ve webových aplikacích, přes virtuální školní komunity až po výměnu dat s orgány státní správy. Milníkem z legislativního hlediska je bezpochyby rok 2004, kdy byl přijat nový školský zákon č. 561/2004 Sb., který mimo jiné zavádí pojem školní matrika a zmocňuje MŠMT1, resp. jím zřízenou organizaci, ke sdružování údajů z evidence škol a školských zařízení pro statistické účely a plnění dalších povinností, např. stanovování rozpočtu. Školní matrikou nazývá evidenci dětí, žáků a studentů škol a školských zařízení, které tuto matriku vedou. Okruh údajů vedených ve školní matrice, vymezuje 28 školského zákona (viz kapitola 2.3). Její formu a způsob vedení dále upravuje vyhláška č. 364/2005 Sb., ve znění pozdějších předpisů. Důsledků této úpravy je hned několik. Vzhledem k tomu, že údaje o jednotlivých žácích se předávají do centra k dalšímu zpracování v elektronické podobě, potřebný okruh údajů musí být veden elektronicky. Elektronická data mají tedy větší prioritu než data tištěná či psaná. Největší změnou je povinnost školy vést o každém žáku přesnou evidenci jeho působení v během jeho školní docházky. Tato data musí být stále aktuální, např. data za žáky prvních ročníků musí být navedeny k 1.9., čili na začátku školního roku. Škola má dále povinnost data chránit ve smyslu zákona o ochraně osobních údajů2 a také proti možné ztrátě. Povinností škol je tedy hned několik. Jejích analýze se věnuje kapitola 2.Analýza současného stavu. Nový zákon a jeho následné úpravy přinesly zásadní změnu oproti předchozímu stavu, a tak nebylo možné tento nový způsob předávaní dat aplikovat na celý systém vzdělávání plošně. Zavádění této povinnosti tak bylo rozděleno do několika fází. Školy se rozdělovaly zpravidla na ty, které předávaly individuální údaje studentů a na ty, které tyto údaje předávaly v agregované formě. Právě agregovaná forma v podobě listinných výkazů byla do té doby jedinou formou komunikace školy s orgánem státní správy. Prvním druhem škol, které se zapojily do předávání individuálních údajů byly ve školním roce 2005/2006 Vyšší odborné školy. V následujícím školním roce 2006/2007 se k 1 MŠMT Ministerstvo školství mládeže a tělovýchovy 2 Jedná se o zákon č. 101/2000 Sb. 1

14 nim postupně přidaly střední školy a konzervatoře. Od školního roku 2007/2008 také základní školy. V roce 2008/2009 se předávání individuálních údajů týkalo všech výše uvedených škol, tedy všech, které poskytují stupeň vzdělání. V praxi to znamená, že školy musí zajistit vedení svých evidencí tak, aby obsahovaly všechny stanovené údaje a umožňovaly předávání dat v požadovaném tvaru. Zároveň musí být splněny požadavky na soulad vedených, resp. předávaných údajů se závaznými standardy číselníky a předepsanými datovými formáty (kapitola a 2.2.2). To můžou zajistit buď aktualizací svých stávajících evidenčních programů na novější verze, které tuto funkcionalitu podporují, nebo pořízením nových, které budou tyto požadavky splňovat a zároveň vyhovovat škole či školnímu zařízení z hlediska jejích vlastních potřeb. Právě v tomto kontextu, kdy také základní školy potřebují vést svou evidenci tak, aby její výstup odpovídal zákonem definované struktuře, se tato diplomová práce zabývá analýzou potřeb této kategorie školských zařízení, návrhem a vytvořením aplikační podpory pro tento proces. Výsledkem práce je softwarový produkt pro školy, pomocí kterého budou schopny evidovat potřebné údaje v rámci školní matriky a vytvářet výstup, který předávají k centralizovanému sběru přes rozhraní definované MŠMT. 1.2 Vymezení cílů a rozsahu řešení Vymezení cílů a rozsahu je možné rozdělit do tří skupin cíle analýzy současného stavu, cíle ve smyslu návrhu realizace matriky (co a jak se evidovat) a cíle s ohledem na způsob realizace (jak systém naprogramovat a jak systém provozovat). Jak již bylo zmíněno, cílem této diplomové práce je vytvořit softwarový produkt informační systém školy pro evidenci matriky: E-škola. Aby bylo možné realizaci provést, musíme vycházet z reálných procesů, které se sběrem dat souvisí. Tyto procesy jsou popsány v zákonech a pro jejích lepší pochopení existuje i řada metodických pokynů. Dle zákona mají od školního roku 2008/2009 povinnost k předávání dat ze školní matriky všechna zařízení v českém systému školství poskytující stupeň vzdělání. Bereme-li v úvahu, že pro každý typ zařízení je tato povinnost specifikována jinak ať už strukturou, okruhem údajů nebo termínem a způsobem odevzdání, navrhnout a naprogramovat informační systém s podporou pro všechny typy zařízení je netriviální problém. U existujících řešení je zaužívané, že ačkoliv potřebnou funkcionalitu implementovanou mají, legislativní úprava nutí jejich dodavatelé své aplikace přeprogramovat, školám rozdistribuovat upgrade a sestavit metodické pokyny, jak a co upravit, aby systém opět fungoval v mezích zákona. To může vést k problémům v samotných školách od zavedení nové verze až po případy, kdy v nových verzích byla evidence rozšířena o nové povinné 2

15 položky a škola tuto nekonzistenci musí řešit pro každého žáka vedeného v matrice samostatně. V této souvislosti chce tato práce nabídnout produkt, který bude flexibilní vůči legislativním úpravám. Tuto flexibilitu je možné dosáhnout vhodným návrhem evidenčního mechanizmu pomocí dynamických formulářů pro evidenci individuálních záznamů studentů škol, nebo také škol samotných. Výsledkem nemá být pouze nějaký program, který je schopen pokrýt evidenci pro nyní platnou vyhlášku, ale bude to platforma, pro centralizovanou správu formulářů, číselníků a procesů s ohledem na možné legislativní změny. Platforma proto, aby bylo zdůrazněno, že se jedná o systém rozšiřitelný a obsahující vlastní rozhraní pro svojí customizaci. Analýza a návrh realizace (kapitola 2 a 3) se bude vztahovat k povinnosti předávání údajů školní matriky základní školy a základní školy speciální, která je stanovena v Čl. 5 vyhlášky č. 226/2007 Sb., kterou se mění vyhláška č. 364/2005 Sb. V praxi tato vyhláška uložila základním školám povinnost předávání individuálních údajů z jejích školních matrik a dokumentace. Důvodem výběru tohoto typu školy je skutečnost, že právě základní školy mají ve školní soustavě největší zastoupení, předmětná povinnost jim nastala pouze nedávno a ne všechny školy disponují potřebným softwarovým vybavením. Neznamená to však, že výsledný produkt bude použitelný pouze pro základní školy. Cílem je realizovat ho tak, aby bylo možné nastavit procesy dynamicky i pro jiné typy škol. Analýza se však redukuje pouze na školy základní. Z hlediska realizace je cílem výsledný software provozovat jako multitenant3 SaaS4 (viz kapitola 3.1), neboli službu, do které se školy budou schopné zaregistrovat a využívat ji během několika minut bez jakékoliv ové nebo telefonické komunikace s dodavatelem systému. V tomto ohledu musí systém vykazovat prvky bezpečnosti, škálovatelnosti a vysoké dostupnosti. Konkrétní funkční a nefunkční požadavky systému jsou popsány v kapitole 3.2. Práce neřeší problematiku informačních systémů z hlediska jejich účelu a potřeby a také se nezabývá vysvětlováním pojmů a principů z oblasti softwarového inženýrství u kterých předpokládá, že jsou čitateli známé. 1.3 Metodika Způsobů jak se dostat do ze startu do cíle bývá někdy mnoho, někdy právě jeden. Vývoj softwarového produktu a celé softwarové inženýrství pozná několik konceptů závislých na různých faktorech od velikosti projektu, přes velikost realizačního týmu až po časový 3 Multitenant odpovídá principu v softwarové architektuře, kdy jedna instance programu běží na jediném serveru a je společná pro vícero klientských organizací (angl. tenants) 4 SaaS zkratka pro Software as a Service, čili software jako služba 3

16 rozsah. V poslední době se hodně hovoří o agilních a iterativních metodikách vývoje. Ty jsou zaměřené na přizpůsobení vývoje vzniklým okolnostem během procesu vývoje, čím můžou podstatně snížit potencionální dopad rizik. Iterativní vývoj je takový přístup ke tvorbě softwaru, jehož cyklus je složen z několika iterací v pořadí. Každá takováto iterace je v podstatě soběstačný mini projekt, skládající se ze všech očekávaných fází analýza, návrh, realizace a testování. Výsledkem každé iterace je stabilní, integrovaný, testovaný a částečně kompletní systém. Na základě zpětné vazby a zjištěných nedostatků se další iterace přizpůsobí potřebám. Iterativní koncept pozná vícero implementací scrum, evo, extreme programing, unified process a jiné. Jiný přístup k vývoju softwaru je popsán modelem vodopádu. Jedná se o sekvenční proces, který má přesně definované výstupy každé fáze: Analýza a specifikace požadavků Návrh řešení (design) Implementace a integrace Testování Údržba Výstup každé fáze tvoří vstupní podmínky fáze následující a při drobné dávce fantazie, si tento tok můžeme představit právě jako vodopád. Jak již bylo zmíněno, výběr metodiky závisí od vícero faktorů, které pro tento konkrétní případ mají tuto podobu: analýzu, implementaci a vývoj provede jedna osoba rizika spojené s nesprávným návrhem jsou nízké, protože se jedná o známou problematiku, části které jsou dokonce přesně definovány zákonem relativně menší rozsah práce (v porovnání s komerčními projekty) by při použití iterativní metodiky vývoj projektu znepřehledňoval a prodlužoval Na základě těchto faktů byl pro realizaci této práce vybrán model vodopád. 1.4 Struktura práce Práce je s ohledem na zvolenou metodiku vývoje rozdělena na tři částí analytickou, návrhovou a realizační. Po představení problematiky a specifikaci cílů následuje analýza a návrh řešení. Poté je popsána realizační fáze a testování. V závěru práce jsou zhodnocené dosažené výsledky a přínos aplikace pro cílovou skupinu uživatelů. 4

17 1.5 Přehled cílů Zde je stručný přehled cílů diplomové práce: Analytická část analýza aktuálního stavu procesu sběru dat pro základní školy okruhy údajů vedených ve školní matrice a související procesy formáty a struktura souborů číselníky způsob předání a termíny analýza pokrytí existujícími aplikacemi stanovení kriterií vyhodnocení Návrhová část stanovení požadavků na systém případy užití výběr programovacího jazyka a vývojových nástrojů návrh architektury klient-server model návrh implementace zaměření na složitější části výběr vhodných frameworků sestavení datového konceptuálního modelu návrh GUI layout, základní prvky Realizační část provedení implementace dle návrhu popis implementace struktura nestandardní části řešení implementační a integrační testování realizace a popis jednotkové testování výkonností testování testování použitelnosti vyhodnocení splnění cílů a přínosu 5

18 2. Analýza současného stavu 2.1 Struktura škol a školských zařízení V České republice má vzdělávací soustava zákonem určenou hierarchii. Každá škola, jak ji chápeme v běžném životě, je z právního hlediska začleněna do určité složitější struktury. V kontextu sběru dat ÚIV stačí, že tuto strukturu budeme chápat tak, jak to ilustruje obrázek 1: Ilustrace 1: Schéma školského zařízení činnost školy, nebo školského zařízení vykonává právnická osoba, která je v resortu školství identifikována pomocí identifikátoru REDIZO. Tato právnická osoba se někdy označuje jako ředitelství. Její statutárním orgánem je ředitel a může být zřízena MŠMT, krajem, obcí, fyzickou nebo jinou právnickou osobu. právnická osoba, neboli ředitelství, se skládá ze součástí, které představují konkrétní školy, nebo školské zařízení. Součásti ředitelství jsou identifikované pomocí IZO. každá součást může mít jedno nebo více míst výkonu činnosti. Jedná se o fyzické místa, kde se činnost reálně provozuje. Např. hlavní budova nebo různá detašovaná pracoviště. V dalším textu budeme pojmem škola nebo školské zařízení označovat součást právnické osoby. Výraz právnická osoba budeme volně zaměňovat s pojmem ředitelství. 6

19 2.2 Proces sběru dat ÚIV V současné době se údaje školních matrik předávají elektronicky zabezpečeným způsobem na ministerstvem stanovený server. Údaje předávané školou jsou rozdělené na agregované a individuální. Účelem je potřeba hodnocení vývoje vzdělávací soustavy České republiky, získání podkladů pro poskytování prostředků státního rozpočtu na činnost škol a školských zařízení a pro zpracování rozpisů rozpočtů právnických osob vykonávajících činnost škol a školských zařízení krajskými úřady na návrhů těchto rozpisů úřady obcí s rozšířenou působností, získání podkladů pro výroční zprávy o stavu a rozvoji vzdělávací soustavy a pro informace poskytované mezinárodní organizacím, zejména EUROSTAT, UNESCO a OECD 5. Účel je tedy pro oba typy údajů společný. Rozdíl spočívá v tom, že individuální údaje představují sadu dat za konkrétního žáka (viz kapitola 2.3.2). Naopak agregované údaje představují součty za definované kategorie, např. počet žáků v prvních ročnících (podrobnější popis je kapitole 2.3.1). Kromě dělení výkazů z hlediska granularity údajů, ÚIV dělí výkazy dle jejích povahy na tři další kategorie6: Kategorie Výkonové výkazy Výkazy Agregované Individuální S 53-01, S 1-01, Z 2-01, S 3-01, S M 3, M 8, M , S 4c-01, S 5-01, S 9-01, R 1301, Z 14-01, Z 15-01, Z 17-01, S 18-01, Z 19-01, R 22-01, Z 23-01, S 24-01, S 26-01, Z 27-01, Z 33-01, Z 34-01, U Výkazy PAM7 P 1-04, P 1a-04, P 1b-04 Výkazy pro VŠ V 06-99, V 11-01, V 16-01, V 2001, V V Tabulka 1: Přehled výkazů ve školství Agregované údaje předávají školy a školská zařízení zřizované obcí prostřednictvím obecního úřadu krajskému úřadu, krajský úřad předává tyto údaje MŠMT, resp. ÚIV, které je ministerstvem zřízené. Ostatní školy a školská zařízení s výjimkou škol zřizovaných přímo MŠMT, předávají tyto údaje prostřednictvím krajského úřadu. Školy zřizované MŠMT předávají tyto údaje přímo ÚIV. Základní školy předávají výkaz S 3-01 Výkaz o základní škole (ukázka je v příloze). Termíny odevzdání jsou uvedeny v kapitole Web MŠMT [on-line] - Příloha 2 k vyhlášce č. 364/2005 Sb odstavec Předávání agregovaných údajů 6 Web ÚIV [on-line] informace k PAM - Práce a Mzdy 7

20 Ilustrace 2: Diagram procesu sběru agregovaných dat Individuální údaje ze školních matriky předávají přímo na ministerstvem stanovený server ÚIV pomocí webové aplikace Matrika8. Škola po úspěšném importu individuálních dat zkontroluje vygenerované přehledové sestavy, porovná je s agregovanými údaji, které má v aplikaci k dispozici ze své evidence, opraví nebo okomentuje zjištěné nesrovnalosti. V případě základních škol a speciálních základních škol se jedná o výkaz M 3 Výkaz o základní škole podle stavu k Analýze procesu importu dat do aplikace Matrika se věnuje následující kapitola Import dat do aplikace Matrika Základní školy importují data ze školní matriky do systému Matrika, který je provozován jako webová aplikace organizací ÚIV. Dle metodického doporučení10 si je možné proces importu zjednodušeně představit takto: Přihlášení do aplikace Matrika Nastavení části školy Import dat (nahrání souborů) Export sestav výkaz a přehledka11 Práce s daty prohlížení vět12 a doplnění komentářů k nesrovnalostem Odeslání dat na správní úřad Po odeslání následuje proces na straně správního úřadu, který předaná data zkontroluje. Může však nastat situace, kdy správní úřad objeví nesrovnalosti a odeslaná data 8 Jde o webovou aplikaci, kterou provozuje ÚIV za účelem sběru dat. Je k dispozici na 9 Tento výkaz je generován aplikací Matrika po importu dat ze školní matriky 10 Jde o pracovní materiál ÚIV postup předávání dat z matrik základních škol - je k dispozici na platný k Speciální typ souhrnného výkazu pro kontrolu agregovaných údajů 12 Větou se rozumí jeden importovaný řádek s individuálními údaji žáka 8

21 vrátí škole zamítne je. V tomto případě musí škola najít důvody nesrovnalostí a data upravit nebo u sporných položek zadat komentář. Komentáře lze připojit pouze ke sporným větám. K tomuto procesu je v systému Matrika vytvořena aplikační podpora 13. Stav odeslání dat školou tak může nabývat těchto hodnot: nezjištěno data dosud za dané IZO a rozhodné datum14 sběru nebyly importovány rozpracováno stav, kdy byl importován soubor alespoň za jednu část školy, sestava ale nebyla odeslána správnímu úřadu nebo byla správním úřadem vrácena škole k opravě odesláno školou data byla importována za všechny části, byly doplněny případné komentáře na základě připomínek předchozího odeslání, a sestava byla odeslána správnímu úřadu Ilustrace 3: Ukázka ze systému Matrika výběr součásti Cyklus zamítnutí a doplnění probíhá až do finálního schválení odeslaných dat správním úřadem do stavu, kdy neexistují takové věty, které by potřebovali vysvětlení. Po jejích akceptaci správní úřad předá data do centrální databáze a škola již nemá možnost znovu data importovat nebo je měnit. V případě dodatečně odhalené chyby či opětovného předání dat z jiného důvodu se musí tato situace řešit organizačním opatřením. V aplikaci Matrika pro tento případ neexistuje podpora. 13 Metodické doporučení je k dispozici na 14 Odpovídá koncovému datu sběrného období. Toto datum stanovuje zákon. 9

22 Ilustrace 4: Diagram procesu předávání individuálních dat Ilustrace 5: Ukázka ze systému Matrika - práce s daty Formát a struktura souborů Data jsou k centralizovanému sběru předávána ve formátu XML15 v kódování Windows Dle zákona platí, že individuální údaje se pro další zpracování předávají ve 15 Dle specifikace Extensible Markup Language (XML) 1.0 (Fifth Edition) 10

23 dvou souborech: 1. základní soubor všech žáků (dále jen základní soubor) 2. anonymizovaný16 soubor žáků se speciálními vzdělávacími potřebami (dále jen anonymizovaný soubor) Název souboru a jeho hlavička musí být vytvořené dle pravidel, které vydává ÚIV. Ve školním roce 2010/2011 jsou pravidla specifikována takto: Dnnnnnnnnn_cc.xml základní soubor Dnnnnnnnnn_cca.xml anonymizovaný soubor kde D bude nahrazeno písmenkem V pro VOŠ, K pro konzervatoř, S pro střední školu a Z pro základní školu. nnnnnnnnn je IZO školy cc je číslo části školy (části ZŠ); nečlení-li se škola (v rámci druhu) na části, uvádí se 01. Za jednotlivé části školy se předávají samostatné soubory, resp. dvojice souborů. Agregovaná data ve formě výkazů se předávají elektronicky ve formátu PDF, nebo v tištěné podobě. Příklad výkazu je v příloze. Obsah souborů závisí od okruhu údajů, které musí obsahovat. Ty jsou popsány v kapitole Každý soubor však má společnou strukturu hlavičky informační blok na začátku souboru. Po něm následují věty obsahující individuální data žáka. Struktura všech XML souborů je následující: <?xml version="1.0" encoding="windows-1250"?> <Vykaz verze="kon.002"> <Vygen>Vlastní_evidence</Vygen> <autor>jan Novak</autor> <telefon> </telefon> < >jnovak@skola.cz</ > <soubor>k _01</soubor> <vytvoreno> :23:57</vytvoreno> <veta> </veta> </Vykaz> Příklad XML souboru je v příloze (Příloha C) Termíny předání dat V souvislosti s termíny odevzdání se setkáváme s pojmy rozhodné a kritické datum. Rozhodnému datu odpovídá koncové datum období, pro které se zjišťování provádí. Údaje za 16 Rozumí se anonymita žáků obsažených v souboru jejich záznamy jsou vedeny pod identifikačním číslem, nikoliv pod jménem nebo rodným číslem 11

24 žáka se tedy nepředávají pouze ty, které jsou platné k rozhodnému datu, ale všechny za celé období. Ve výstupních souborech tak může být pro jednoho žáka záznamů více. Data se předávají v následujících obdobích: rozhodné datum 30.9., tj. podle stavu k období od předchozího roku do aktuálního školského roku rozhodné datum 31.3., tj. podle stavu k 31.3 období od 1.9. do aktuálního školského roku Termíny předání dat ze školních matrik jsou tedy dva podzimní a jarní. Konkrétní data se liší v závislosti na typu školy. Pro základní školy jsou relevantní dva výkazy S 3-01, obsahující agregovaná data a M 3 obsahující data individuální. Ve školním roce 2010/2011 jsou tyto termíny stanoveny takto: Výkaz Podzimní termín Rozhodné datum Jarní termín Kritické datum Rozhodné datum Kritické datum S M Tabulka 2: Přehled termínů pro předání výkazů ve školním Kritickým datem se rozumí poslední den, kdy je možné údaje odevzdat. 2.3 Okruhy údajů vedených v dokumentaci školy Jak již víme, v současné době se předpokládá předávání individuálních dat ze školních matrik všech škol poskytujících stupeň vzdělání. Ostatní školské zařízení17 mají povinnost matriku vést, ale i nadále se u nich předpokládá sběr dat prostřednictvím standardních agregovaných výkazů Struktura agregovaných údajů pro předání ÚIV Dle zákona18 předává základní škola nebo základní škola speciální agregované údaje v této struktuře: - údaje za uplynulý školní rok a) ukončení povinné školní docházky a odchody do středních škol v členění na běžné a speciální třídy podle pohlaví 17 Například jazykové školy ty neposkytují stupeň vzdělání 18 Web MŠMT [on-line] - Příloha 2 k vyhlášce č. 364/2005 Sb. odstavec 3. Předávání agregovaných údajů ze školní matriky a dokumentace základní školy základní školy speciální (výkaz S 3-01). 12

25 b) zotavovací pobyty - údaje za příslušný školní rok c) třídy a žáci podle ročníků a podle pohlaví v členění na běžné a speciální třídy d) opakující a převedení žáci do vyšších ročníků e) výuka cizích jazyků v členění na běžné a speciální třídy f) rozšířená výuka některých předmětů nebo skupin předmětů v členění podle tříd a skupin a podle vzdělávacích oboru uvedených v příslušném rámcovém vzdělávacím programu g) individuálně integrovaný žáci se zdravotním postižením podle druhu postižení h) speciální třídy podle druhu postižení/znevýhodnění i) individuální vzdělávací plány pro nadané a postižené žáky podle ročníků j) integrované děti připravované podle vzdělávacího programu přípravného stupně základních škol speciálních k) žáci plnící povinnou školní docházku v zahraničí nebo v zahraniční škole na území ČR podle ročníků l) kurzy pro získání základního vzdělání a kursy pro získání základů vzdělání m) přípravné třídy pro děti se sociálním znevýhodněním n) žáci podle státního občanství o) cizinci podle režimu pobytu p) věkové složení žáků v členění na běžné a speciální třídy q) volitelné předměty podle ročníků r) výuka předmětů v cizím jazyku Této specifikaci odpovídá výkaz S Ne všechny údaje jsou ale ve školní matrice obsažené a proto jeho vytváření podléhá také ručnímu vložení některých údajů jedná se o body b), l), m) a o). Ukázka tohoto výkazu je v příloze (Příloha B) Struktura individuálních údajů pro předání ÚIV Konkrétní individuální údaje žáka upravuje již zmiňovaná vyhláška 364/2005 Sb., podle které školy vedou údaje o průběhu studia a výsledcích žáka a obsahují tyto údaje: a) b) c) d) e) f) jméno a příjmení, rodné číslo, státní občanství a místo trvalého pobytu údaje o předchozím vzdělávání, včetně dosaženého stupně vzdělání obor, formu a délku vzdělávání, jde- li o střední a vyšší odbornou školu datum zahájení vzdělávání ve škole údaje o průběhu a výsledcích vzdělávání ve škole, vyučovací jazyk údaje o tom, zda je dítě, žák nebo student zdravotně postižen, včetně 13

26 údaje o druhu postižení, nebo zdravotně znevýhodněn; popřípadě údaj o tom, zda je dítě, žák nebo student sociálně znevýhodněn, pokud je škole tento údaj zákonným zástupcem dítěte nebo nezletilého žáka nebo zletilým žákem či studentem poskytnut g) údaje o zdravotní způsobilosti ke vzdělávání a o zdravotních obtížích, které by mohly mít vliv na průběh vzdělávání h) datum ukončení vzdělávání ve škole, údaje o zkoušce, jíž bylo vzdělávání ve střední nebo vyšší odborné škole ukončeno i) jméno a příjmení zákonného zástupce, místo trvalého pobytu a adresa pro doručování písemností, telefonické spojení Záznam nebo změna údaje ve školní matrice se musí provést neprodleně po rozhodné události. Individuální údaje se předávají ve formě XML souborů, jehož struktura byla popsána v kapitole Ta obsahuje datové věty, které se skládají z konkrétních položek představující výše popsané oblasti údajů. Definice struktury je označována verzemi. Pro školní rok 2010/2011 je pro základní školy platná verze ZS.004. Základní a anonymizovaný soubor údajů je rozdělen do dvou XML souborů, které se v některých položkách odlišují. Následující tabulka nabízí přehled společných položek obou souborů. Jednotlivé položky kromě kódu a popisu významu obsahují také odkaz na číselník (viz kapitola 2.3.3), pokud se jedná o položku, které kód odpovídá hodnotě z číselníku. Odkaz na číselník je veden ve formě jeho kódu. Z technického hlediska je důležitý datový typ položky, který má tento význam: Č. C alfanumerický znak v kódování Windows V závorce je uvedena délka řetězce znaků. D datum ve formátu DDMMYYYY Kód položky Význam a obsah položky Rozhodné datum sběru (datum, ke kterému se zjišťování provádí) 2 IZO IZO vykazující školy 3 CAST Číslo části školy 5 POHLAVI Pohlaví žáka 6 DAT_NAROZ Rok a měsíc narození 7 KSTPR Kvalifikátor státního občanství 8 STPR Státní občanství žáka 9 OBECB Kód obce trvalého pobytu žáka 2) 10 OKRESB Okres trvalého pobytu žáka 2) 1 Číselník RDAT 14 Typ (délka) D RAPO RAKO RAST RAUJ RAOR C(9) C(2) C(1) C(6) C(1) C(3) C(6) C(6)

27 11 ODHL ZAHDAT KOD_ZAH UKONDAT KOD_UKON LET_PSD ROCNIK PRIZN_ST ST_SKOLY TRIDA 21 ZPUSOB 22 JAZYK_O 23 JAZ1 24 P_JAZ1 25 JAZ2 26 P_JAZ2 27 JAZ3 28 P_JAZ3 29 JAZ4 30 P_JAZ4 31 JAZYK_PR1 32 POCET_PR1 33 POCET_H1 34 JAZYK_PR2 35 POCET_PR2 36 POCET_H2 37 FIN 38 OBOR 39 DELST Předchozí vzdělávání (vzdělávací program) žáka ZŠ Datum zahájení docházky do ZŠ Kód zahájení docházky do ZŠ Datum ukončení docházky do ZŠ Kód ukončení docházky do školy Počet let splněné povinné školní docházky Ročník, ve kterém se žák vzdělává Příznak vzdělávání, opakování ročníku Stupeň školy Identifikace třídy ( 23 školského zákona) Způsob plnění povinné školní docházky (např. v zahraničí, individuální vzdělávání podle 41) Vyučovací jazyk třídy Kód 1. cizího jazyka, kterému se žák učí Příznak, zda jde o výuku jazyka jako povinného, volitelného nebo nepovinného předmětu Kód 2. cizího jazyka, kterému se žák učí Příznak, zda jde o výuku jazyka jako povinného, volitelného nebo nepovinného předmětu Kód 3. cizího jazyka, kterému se žák učí Příznak, zda jde o výuku jazyka jako povinného, volitelného nebo nepovinného předmětu Kód 4. cizího jazyka, kterému se žák učí Příznak, zda jde o výuku jazyka jako povinného, volitelného nebo nepovinného předmětu První cizí jazyk, v němž se vyučují předměty RAPD RAZD RAUD RARO RAPV RASS C(1) RAJO RACJ C(2) C(2) RAVJ C(1) RACJ C(2) RAVJ C(1) RACJ C(2) RAVJ C(1) RACJ C(2) RAVJ C(1) RACJ C(2) I(2) I(2) Druhý cizí jazyk, v němž se vyučují předměty RACJ 15 D C(1) D C(1) I(1) C(1) C(1) C(1) C(1) RASD Počet předmětů, které se vyučují prvním cizím jazykem Počet hodin vyučovaných v prvním cizím jazyce Počet předmětů, které se vyučují druhým cizím jazykem Počet hodin vyučovaných ve druhém cizím jazyce Financování žáka požadavek na zvýšené výdaje pro žáka Kód oboru (RVP) Délka vzdělávacího programu C(3) C(2) I(2) I(2) RAFZ C(1) RASO RADS C(8) C(2)

28 40 KOD_ZMEN 41 ZMENDAT 42 KOD_VETY 43 PLAT_ZAC 44 PLAT_KON Kód změny Datum uskutečněné změny Kontrolní rozlišení, zda jde o větu o absolventovi školy, o žákovi či žákovi, který odešel na jinou školu Začátek platnosti věty Konec platnosti věty RAKZ C(1) D RAKV C(1) D D Tabulka 3: Přehled individuálních údajů žáka společný základ Základní soubor obsahuje navíc informaci o rodném čísle žáka: Č. Kód položky Význam a obsah položky 1 RODC Rodné číslo žáka Číselník Typ (délka) C(10) Tabulka 4: Položka základního souboru Anonymizovaný soubor obsahuje specifické údaje ve vztahu k postižení žáka. Anonymita je dosažena vynecháním rodného čísla žáka RODC, které je nahrazeno položkou KOD_ZAKA. Tento kód je unikátní a pomocí něho je možné žáka jednoznačně určit. Č. Kód položky 1 KOD_ZAKA 2 3 POSTIZ1 POSTIZ2 4 VICE_VAD 5 INDI 6 NADANI Význam a obsah položky Číselník Jednoznačný identifikační kód žáka určený školou s vyloučením možnosti duplicit u různých žáků školy Druh prvního zdravotního postižení RAZP Druh druhého zdravotního postižení RAZP Příznak souběžného postižení více vadami (na základě speciálně pedagogického popř. psychologického vyšetření školským poradenským zařízením). 0 není postižen více vadami 1 je postižen více vadami Individuální vzdělávací plán. 0 nevzdělává se podle individuálního vzdělávacího plánu 1 vzdělává se podle individuálního vzdělávacího plánu Rozlišení pro mimořádně nadaného žáka. 0 není mimořádně nadaný 1 je mimořádně nadaný Tabulka 5: Položky anonymizovaného souboru Detailní vysvětlení jednotlivých položek je k dispozici v příloze (Příloha D). 16 Typ (délka) C(10) C(2) C(2) C(1) C(1) C(1)

29 2.3.3 Číselníky Hodnoty některých předávaných položek jsou čerpány z číselníků. ÚIV jich eviduje celkem 39 a jsou definované zákonem. Hodnoty číselníků se v čase můžou měnit, proto se definuje také jejích platnost. Kód číselníku RACJ RADO RADS RADV RADZ RAFS RAFZ RAIP RAJO RAKK RAKO RAKV RAKZ RAOR RAPD RAPO RAPS RAPV RAPZ RARO RARV RASD RASO RASS RAST RATT RAUD RAUJ RAUN RAUV RAVM RAVJ RAVZ RAZD RAZP RAZV Název číselníku Vyučovaný cizí jazyk Příznak vzdělávání ve druhém hlavním oboru Délka vzdělávacího programu Druh vzdělávání na SŠ/VOŠ/konzervatoři Druh vykonané zkoušky Forma vzdělávání Financování žáka/studenta Číselník pro rozlišení důvodů vytvoření IVP Vyučovací jazyk oboru Kategorie dosaženého vzdělání podle KKOV Resortní kvalifikátor státního občanství Kód věty Kód změny Číselník NUTS 4 Předchozí vzdělávání (vzděl. prog. žáka ZŠ) Pohlaví Předchozí působiště studenta Průběh vzdělávání Předchozí působiště žáka SŠ / konzervatoře Číselník ročníků Vzdělávací obory v rozšířené výuce Způsob plnění školní docházky na ZŠ Resortní číselník oborů vzdělání (AKSO) Stupeň školy Číselník státy Typ třídy / studijní skupiny Ukončení školní docházky na ZŠ Základní územní jednotky (obce) Úspěšnost Ukončení vzdělávání na SOŠ / VOŠ / konzervatoři Volitelná maturitní zkouška Příznak výuky cizího jazyka Vykonaná zkouška Zahájení docházky do školy Zdravotní postižení Zahájení vyučování na SŠ / VOŠ / konzervatoři Tabulka 6: Seznam číselníků platný k

30 2.3.4 Platnost a historie změn údajů Časté změny v legislativních úpravách mají za následek také změny v evidenci matriky provozované školou. Dle 4 vyhlášky č. 364/2005 Sb. popisy struktur se zveřejní nejpozději 3 měsíce před kritickým dnem, číselníky se zveřejní nejpozději 6 měsíců před prvním termínem předávání individuálních údajů. Z hlediska sestavování dat k odevzdání v aktuálním období tyto změny nepředstavují žádný problém, protože dodavatelé systémů, nebo školy samotné mají dostatek času na případné úpravy svých evidencí. Chceme-li mít systém, který dokáže zpětně zobrazit data tak, jak byly platné v předchozím období, musíme v návrhu realizace kromě platnosti údajů a relací uvažovat také o způsobu evidence změn bez ohledu na jejích platnost. Tuto funkcionalitu budeme dále nazývat verzování Procesy ve školní matrice Školní matrika eviduje všechny události, které během školní docházky žáka můžou nastat. Veškeré změny musí být řádně evidovány a aplikačně podporovány, protože mají na evidenci matriky a předávané údaje vliv. Pro žáky základních školy se jedná o tyto situace: zahájení a ukončení studia odchod žáků ze školy během studia opakování ročníku neabsolvování ročníku přeřazení žáka nástup do vyššího ročníku přerušení studia, nástup či ukončení po přerušení vícenásobný pohyb žáka žák plní povinnou školní docházku v zahraničí nebo v zahraniční škole individuální vzdělávací plány žáků evidence bývalých žáků (absolventů) Postup pro řešení těchto situací je definován v zákoně a také existují metodické pokyny pro jejich aplikaci. Konkrétní popis funkcí je k dispozici v kapitole Funkční požadavky. 2.4 Analýza existujících řešení V této kapitole se budeme věnovat existujícím řešením jak si s problematikou matriky škol poradili v jiných aplikacích. Zaměříme se na ty aspekty, které jsou pro řešenou problematiku relevantní. Na českém trhu existuje několik řešení informačního systému škol. Z hlediska evidence školní matriky se však zaměříme na dva nejrozšířenější systémy: Škola OnLine a 18

31 Bakaláři Kriteria analýzy Abychom mohli existující řešení analyzovat a vyhodnotit, musíme stanovit kriteria, na základě kterých tuto analýzu provedeme. Z existujících řešení musíme zjistit, ve kterých ohledech mají aplikace nedostatky a naopak, které jsou vhodné pro inspiraci. Uvědomme si, že cílem této práce je vytvořit systém, který splňuje stejný účel jako tyto dva zmiňované systémy, avšak způsob jeho implementace, užívání a provozu bude zcela unikátní. A právě z tohoto důvodu je potřeba již vyřešené problémy neřešit vlastní cestou, ale nechat se inspirovat. Inspirovat ne ve smyslu kopírovat stejnou funkčnost, ale brát na již realizované funkčnosti v existujících řešeních během návrhu ohled. Pro řešenou problematiku evidence školní matriky je vhodné rozdělit další bádání do následujících oblastí. Funkce matriky Předpokládáme, že obě aplikace evidují zákonem předepsané položky a podporují všechny potřebné procesy. I přesto však aplikace můžou nabízet některé funkcionality pro zjednodušení a urychlení práce. Kromě analýzy a popisu způsobu realizace matriky v obou aplikacích, se budeme věnovat i těmto otázkám: Existuje podpora hromadného importu záznamů z jiných aplikací? Jaké jsou podporované formáty a které oblasti dat je možné importovat? Je import konfigurovatelný? (např. nastavení mapování importovaných sloupců na položky matriky) Jak jsou podporované procesy specifikované v kapitole 2.3.5? Existuje podpora pro hromadné změny v záznamech matriky? Je podporováno verzování19 záznamů žáků? Jsou k dispozici přehledové sestavy? Je podporován export? Jaký rozsah má správa číselníků? Jsou konfigurovatelné? Jakým způsobem je podporovaná aktualizace číselníků a platnost jejích záznamů? Jaké jsou možnosti customizace (např. vlastní položky nebo formuláře) a rozšiřitelnosti? Reflektování změn v legislativě Cílem je zjistit, jakým způsobem jsou v aplikacích reflektovány legislativní změny, co 19 Verzováním záznamů je myšlena evidence veškerých změn hodnot a vztahů formou verzí. Např. některé údaje můžou být změněny bez ohledu na to, že se změnil datum jejích platnosti. Jedná se například o opravu překlepů v osobních údajích žáků, které nemají mít vliv na předávaní individuálních údajů na ÚIV. 19

32 všechno tento proces obnáší na straně školy, jaké jsou rizika a možnosti podpory. Budeme hledat odpovědi na otázky: Jakým způsobem je změna v zákonech promítnuta do aplikací? Musí uživatel provést nastavení samostatně? Jaká je podpora ze strany dodavatele? Jak jsou řešeny případné chyby vzniklé nesprávným postupem na straně školy? Existuje zkušební mód aplikace, ve kterém si uživatelé postup otestují? Ovladatelnost V této oblasti se zaměříme na způsob realizace uživatelského rozhraní, zejména ve vztahu k evidenci matriky. Jaká je úroveň implementace inteligentního GUI? Existují našeptávače při psaní, detekce chyb na základě statistiky již vložených dat a podobně? Existuje on-line kontextová nápověda20? Technická realizace Cílem je zjistit, jakým způsobem jsou aplikace realizované z hlediska instalace, zabezpečení a provozu. Jak jsou aplikace provozované? SaaS nebo on-premise21? Jakým způsobem jsou aplikace zabezpečeny? (SSL, šifrování dat, vysoká dostupnost22,...) Jaká je škálovatelnost aplikací? Jaké jsou možnosti zálohy a obnovy dat? Jaké jsou HW a SW požadavky? Cena a způsob autorizace Jelikož se jedná o komerční produkty, zajímavý je také pohled na cenu, za kterou si tyto systémy můžou školy pořídit. Dále nás zajímá i způsob autorizace užívání produktu. Jakým způsobem jsou aplikace autorizovány k užívání? Jak se dá pořídit licence? Jaké nabízí dodavatel tarify nebo licence? Existuje zkušební tarify nebo licence? Co je v zakoupených balíčcích zadarmo? 20 On-line kontextovou nápovědou se myslí nápověda ve formě HTML dokumentu s navigací. Odkaz na tuto nápovědu je k dispozici v řešeném kontextu (např. otevřená stránka nebo okno). 21 Je instalovaná a provozovaná na počítačích školy na rozdíl od SaaS, který je provozován v cloudu, nebo v hostingu. 22 Vysokou dostupností, neboli také HA (high availability), se myslí garance provozu 24/7 ke základním metodám dosažení patří horizontální škálovatelnost, failover metody a jiné. 20

33 Jak rychlo je možné nainstalovat a provozovat on-premise aplikaci? Jak rychlo se je možné zaregistrovat do SaaS aplikace a začít ji naplno využívat (počet kroků, složitost)? Bakaláři Jedná se o komplexní školní informační systém pokrývající veškeré evidenční potřeby školy. Patří k nejstarším a nejrozšířenějším aplikacím pro základní a střední stupeň v českém systému školství. Základní črtou systému je způsob jeho provozu jde o desktopovou aplikaci určenou pro 32-bitové prostředí MS Windows. Systém se skládá z několika modulů, které nabízejí aplikační podporu pro specifické činnosti školy. Kromě modulu pro evidenci matriky, systém Bakaláři nabízí tyto moduly23: evidence zaměstnanců klasifikace - včetně grafického zpracování přehledů a výsledků žáků a tříd třídní kniha evidence docházky žáků s možností tiskových výstupů tématické plány správa tématických plánů pro třídy a předměty rozvrh hodin automatické generování rozvrhu, suplování, plán akcí školy přijímací zkoušky podpora zpracování přijímacích zkoušek na SŠ a pro zápis žáků do 1. ročníků ZŠ inventarizace modul pro evidenci majetku rozpočet školy modul pro evidenci příjmů a výdajů školy knihovna zahrnuje klasickou evidenci knih a systém pro půjčování s propojením na žáky a zaměstnance školy rozpis maturit možnost sestavení rozvrhu maturit webová aplikace jedná se o separátní modul určený pro komunikaci školy s rodiči poskytující přístup k vybraným údajům o žákovi zejména k jeho klasifikaci, docházce a rozvrhu. Nabízí také možnost základní automatizované komunikace mezi školou a rodiči formou elektronické pošty a SMS zpráv. Pro užívání tohoto modulu je však potřeba nainstalovat a nakonfigurovat běhové prostředí na škole a mít k dispozici dedikovaný server permanentně připojený do sítě internet včetně veřejné IP adresy. Funkce matriky Evidence žáků a studentů je z historického hlediska nejdůležitější funkcí v tomto systému. Všechny ostatní moduly jsou na této základní evidenci postaveny. To samé platí pro podporu číselníků. Po přijetí nového školského zákona autoři v podstatě doplnili chybějící položky a přijali nové označení této evidence Matrika. Všechny specifické situace popsané v kapitole jsou podporované. Matrika je realizována vedením údajů na takzvané kartě žáka (viz 23 Kompletní přehled včetně popisu je k dispozici na 21

34 obrázek níže), která obsahuje veškeré potřebné údaje. Ilustrace 6: Karta žáka v aplikaci Bakaláři Pro potřeby škol do 100 žáků nabízí dodavatel také aplikaci minimatrika 24. Ta je určena pro malé základní školy, které z různých důvodů nechtějí evidovat klasifikaci, docházku a podobně a potřebují pouze zpracovat údaje, které se předávají na ÚIV. Tato aplikace je jednoduchá avšak funkčnostmi postačuje opravdu pouze pro školy s desítkami žáků. V další analýze se touto aplikací zabývat nebudeme. Hromadný import záznamů z jiných aplikací je podporován pouze částečně vložení osobních údajů v pevně definované podobě ve formátu CSV25. Ostatní údaje žáka ve vztahu k matrice musí škola zadat ručně. Konfigurovatelný import není podporován. Dodavatel aplikace však nabízí možnost úpravy dat z různých evidencí škol (např. evidence žáků v XLS26 formátu) do požadované struktury27. Co se týče možnosti hromadných změn záznamů, podpora v evidenci školní matriky zcela chybí. Hromadné změny jsou možné pouze v případě evidence klasifikace, docházky a číselníků místností a učitelů. Verzování záznamů žáka je podporováno pouze ve smyslu sledování historie změn Více na Textový soubor obsahující hodnoty oddělené čárkou, nebo jiným oddělovačem (Comma Separated Values) Soubor ve formátu Microsoft Excel Dle informací na k

35 záznamů u znakových položek (např. jméno a příjmení žáka). Obsah položek v kartě žáka zachycuje aktuální stav. Pokud je evidence historie změn požadována, je ji potřebné aktivovat. Systém nabízí možnost vytvoření přehledových statistických sestav ke kontrole. Zákonem požadovaná sestava S 3-01 však chybí a je tudíž nutné ji vyplnit za pomocí elektronických statistických sestav ručně. Export sestav a údajů z matriky je možný do formátů PDF, XLS a XML. Číselníky používané pro evidenci údajů ve vztahu k předávaní dat do ÚIV není možné modifikovat. Pro změnu číselníku je potřeba instalace nové verze programu. Je podporována pouze aktuální hodnota číselníků. Systém neumožňuje customizace systému evidovaných údajů formou vlastních formulářů nebo číselníků. Reflektování změn v legislativě S legislativní změnou je vždy nutné pořídit novou verzi systému a provést instalaci. Nové verze jsou k dispozici na webových stránkách dodavatele a na CD-ROM médiu, které lze objednat. Dodavatel poskytuje návod ve formě PDF dokumentu a telefonickou podporu. Možnost zkušební provedení požadovaných změn v datech neexistuje, aplikace však podporuje návrat k zálohovanému stavu. Ovladatelnost Z hlediska uživatelského komfortu aplikace nabízí srovnatelné prostředí s jinými aplikacemi podobného zaměření28. Validace vstupních údajů je provedena standardním způsobem29. Z pohledu principů inteligentního uživatelského rozhraní nejsou k dispozici žádné funkce, jako například našeptávače při psaní nebo kontrola vstupu na základě statisticky již vložených údajů. Aplikace pro vykreslování uživatelského rozhraní využívá prostředků operačního systému Windows. Aplikace nemá k dispozici on-line nápovědu propojenou s kontextem, ve kterém uživatel pracuje. On-line je k dispozici nápověda k celým oblastem funkčností ve formě PDF dokumentu, který je dostupný na webových stránkách dodavatele. V současné době je k dispozici rozpracovaná podoba on-line nápovědy pouze k modulu Webová aplikace. Technická realizace Aplikace je realizovaná jako on-premise. Dodavatel nabízí na svých stránkách ke stažení binární distribuci obsahující instalátor. Aplikace nedisponuje integrovaným datovým 28 Jsou myšleny systémy pro vedení různé evidence, např. Microsoft Dynamics CRM, Ekonomický systém Pohoda a podobné. 29 Ověření rozsahu a typu vstupních dat a referenčních vztahů. 23

36 úložištěm a data ukládá do separátního databázového serveru. SW požadavky30 na systém jsou následovní: operační systém: Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP, Windows 2003, Windows 2008, Windows Vista 32-bit, Windows 7 32-bit pro uložení dat je možné využít souborový server (pouze starší verze) nebo SQL server: MS SQL 2000 (postačuje MSDE), MS SQL 2005 (postačuje MS SQL 2005 Express) nebo MySQL, optimální verze 4.1 a vyšší, podpora však byla ukončena verzí 08/09 instalace modulu Webová aplikace je podmíněná instalací těchto systémů: Windows 2000, Windows XP Pro, Windows 2000 server, Windows 2003 server, Windows 2008 server, Internet Information Services (IIS) verze 5.0 nebo vyšší a.net Framework verze 1.1 včetně SP1 Bezpečnost aplikace s hlediska přístupů je realizována přihlášením oprávněných uživatelů. Z hlediska uložení dat v databází je možné využit pouze SSL spojení s databázovým serverem. Zabezpečení připojení na modul Webová aplikace přes síť Internet formou SSL je možné realizovat nastavením v ISS. Aplikace nabízí možnosti pravidelného automatického zálohování, obnovy dat a kontrolu konzistence. Z hlediska škálovatelnosti desktopové aplikace je možná pouze vertikální, dosažitelná zvýšením výkonu pracovní stanice, na které se aplikace provozuje. Cena a způsob autorizace Používání aplikace je autorizováno licencí ve formě licenčního klíče. Zakoupení licence není možné formou elektronického obchodu ale pouze formou odeslání objednávky. Komunikace pak probíhá formou elektronické pošty. Cena licence závisí na počtu žáků a vybraných modulech, které chce škola využívat. Pro naše potřeby se zaměříme pouze na ty moduly, které potřebujeme k evidenci matriky a předávaní dat na ÚIV. 30 Dle informací na webu k

37 Cena licence v Kč31 Počet žáků Společné prostředí Evidence + Bakalář Celkem do do do do do do do do do do do do Tabulka 7: Přehled cen licencí aplikace Bakaláři Novým zákaníkům se navíc účtuje manipulační poplatek ve výši 220 Kč. Zakoupená licence se vztahuje na instalace na všech počítačích školy. Pokud se jedná o upgrade, např. který si škola musí pořídit při každé legislativní změně, je cena výslední cena 20% z ceny za novou licenci. Licenci za větší počet žáků lze dokoupit za rozdíl ceny.32 Prodávané licenční balíky neobsahují žádné položky zdarma navíc Škola OnLine Škola OnLine představuje celé portfólio řešení pro školy dostupné přes síť Internet. Nad tímto systémem převzalo záštitu MŠMT, což je nespornou výhodou oproti konkurenčním systémům a také jakousi garancí kvality a správnosti nabízených služeb. Tento systém není na české trhu novinkou, provozuje se už od roku Jeho základní črtou je skutečnost vyplývající ze samotného způsobu provozu škola nemusí nic instalovat, stačí jí internetové připojení. Škola OnLine se dělí na tyto aplikace: KATEDRA Je aplikace určená mateřským, základním, středním a vyšším odborným školám k vedení školní matriky a elektronické agendy spojené s provozem školy. Mezi nejdůležitější funkce patří elektronická třídní kniha, učební plány, zápisy do 1. tříd, 31 ceník platí od 12. listopadu 2010, uvedené ceny jsou včetně 20% DPH 32 Dle informací na k

38 přijímací řízení, docházka a suplování, tisk vysvědčení, školní knihovna, evidence skladu, inventarizace, plánování školních akcí, exporty pro ÚIV, MŠMT, VZP, ČSSZ a další. ŽÁKOVSKÁ Je nadstavbou aplikace KATEDRA určená žákům, rodičům a učitelům k přístupu k datům vedených v této aplikaci. Prakticky se jedná o elektronickou žákovskou knížku, která obsahuje veškeré potřebné informace přehled o průběžných a celkových výsledcích žáka, jeho docházce či chování. AKADEMIE Jedná se o aplikaci určenou vysokým školám poskytující elektronickou správu školní agendy. Mezi její nejdůležitější funkce patří: školní matrika, elektronický index, přijímací řízení, evidence bakalářských a diplomových prací, závěrečné zkoušky, studijní programy a plány, rozvrhy, e-learningová výuka, podpora publikační činnosti, plánování školních akcí a další33. SPISOVKA Jde o aplikací spisové služby určenou pro potřeby škol a vzdělávacích organizací. Tato služba nabízí široké možnosti v oblasti evidence a oběhu elektronických dokumentů, od jejích příjmu a vytváření až po jejích archivaci a skartaci. OLAT Tato aplikace v sobě sdružuje systém pro řízení výuky (LMS - Learning management systém) a systém pro tvorbu, sdílení a distribuci výukového obsahu (LCMS Learning content management systém). Pro účely analýzy ve vztahu ke školní matrice se dále budeme zabývat pouze aplikací KATEDRA. Funkce matriky Školní matrika je podobně jako u systému Bakaláři jednou ze základních funkcí systému KATEDRA. Realizace je provedena formou karty žáka. 33 Další informace jsou k dispozici on-line na 26

39 Ilustrace 7: Karta žáka v aplikace Škola OnLine Systém nabízí rozsáhlé možnosti importu z jiných aplikací. Import je možné konfigurovat pomocí šablon importu a naplnit tak veškeré oblasti údajů. Podporované formáty importu jsou CSV, XLS a DBF34. Import dat je proveden vícekrokově nahrání dat, náhled, případná úprava a potvrzení, po kterém je import skutečně proveden. Specifické procesy popsané v kapitole jsou podporovány formou změny příslušných hodnot v polích. V mnohých případech se jedná vícekrokové operace. Neexistují dedikované operace, které požadovanou operaci provedou atomicky. Aplikace nabízí možnost hromadné změny vybraného pole pro vícero žáků najednou. Skupinu žáků, pro které chceme provést hromadnou změnu vybrané položky, je možné omezit filtrem. 34 Soubor ve formátu dbase. Do tohoto formátu jsou podporovány také exporty se systému Bakaláři. 27

40 Ilustrace 8: Hromadné nastavení položek v aplikaci Škola OnLine Verzování není podporováno. Ke změně údajů se vždy váže i změna platnosti. Změny údajů ke stejnému datu nejsou rozlišovány. Existence rozdílných dat platnosti u evidovaných položek má dopad na obsah exportu individuálních údajů pro předání na ÚIV. V aplikaci existuje podpora pro generování výkonových výkazů, zejména S Také je možné vytvoření vlastních sestav. Export je podporován do formátu PDF a XLS. Jeho podoba je konfigurovatelná výběrem položek a formátem. Export individuálních údajů pro předání na ÚIV je doplněn o funkci kontroly správnosti údajů. Číselníky používané pro evidenci údajů ve vztahu k předávaní dat do ÚIV je možné uživatelsky konfigurovat je možné přidávat a upravovat hodnoty v nich. Aplikace nenabízí možnost vlastních formulářů. Reflektování změn v legislativě Úprava na základě změn v legislativě je provedena dodavatelem aplikace v pravidelných nových verzích systému. Ty kromě úprav ve vztahu k legislativě zahrnují také opravy chyb hlášených uživateli a nové funkce. Nová verze zpravidla vychází jednou měsíčně. Jelikož se jedná o multitenant řešení, je dostupná všem najednou. V případě, že se na straně škol musí v souvislosti s novou verzí dojít k určitým opatřením, dodavatel aplikace poskytuje on-line nápovědu a telefonickou podporu. Ovladatelnost Z pohledu uživatelského rozhraní Škola OnLine nabízí plnohodnotné interaktivní prostředí odpovídající trendům v programování webových v posledních letech. Opět je možné přirovnání k existujícím ERP aplikacím Např. Microsoft Dynamics CRM 28

41 Systém nabízí také on-line kontextovou nápovědu36. Odkazy na ní jsou umístěné přímo v aplikaci. Inteligentní uživatelské rozhraní ve formě našeptávačů při psaní nebo statistické validace není podporováno. Technická realizace Jak již bylo zmíněno, aplikace je provozována jako SaaS. Existují však případy onpremise řešení např. nasazení pro školy spadající pod magistrát města Plzeň. Aplikace je postavena na technologiích od společnosti Microsoft: aplikační server: IIS provozovaný na MS Windows 2003 Server běhové prostředí:.net 2.0 databázový server: MS SQL 2005 Aplikace je zabezpečena SSL šifrováním spojení mezi serverem a klientský webovým prohlížečem. Pro přístup do aplikace je potřebné mít nainstalovaný také klientský certifikát, který je dostupný na stránkách dodavatele. Zajímavá je také možnost přihlášení pomocí účtu Microsoft Live@edu37. Informace ohledně zálohováni a obnovy, HA a load-balancingu nejsou k dispozici. Na straně klienta musí být k dispozici internetový prohlížeč Internet Explorer 7 a vyšší. Cena a způsob autorizace Autorizace k užívání aplikace je realizována formou tarifů. Jeho cena závisí na počtu žáků a vybraných funkčnostech, které chce škola využívat. Pro naše potřeby se zaměříme pouze na ty, které k evidenci matriky a předávaní dat na ÚIV školy potřebují. Cena za kalendářní rok v Kč38 Počet žáků Jádro systému Školní matrika, Export dat pro (povinné) evidence osob ÚIV Celkem do do do do do do On-line nápověda je k dispozici na 37 Jedná se o sadu služeb a aplikací pro podporu komunikace žáků, rodičů a učitelů, více na 38 ceník platí od 1. září 2010, uvedené ceny jsou včetně 20% DPH 29

42 do do do do Tabulka 8: Přehled cen tarifů aplikace Škola OnLine Registraci do aplikace KATEDRA je možné provést pouze prostřednictvím telefonu. Škola dodavateli sdělí název, adresu a jméno ředitele školy. Poté bude škole umožněn přístup do zkušební verze, která je však sdílena mezi všemi zájemci. Pokud se škola rozhodne systém používat, musí se opět obrátit na dodavatele a požádat o dohodu o zkušebním provozu. Po podepsání této dohody bude mít přístup do aplikace na 2 měsíce zdarma. Po uplynutí této doby musí zaplatit částku dle ceníku Shrnutí Obě zkoumané aplikace nabízejí v souvislosti s evidencí matriky a následného předávání dat funkční a využitelné řešení. Odlišnosti nacházíme zejména v oblastech způsobu realizace, v oblasti funkcionality a služeb. Mnohé rozdíly jsou implikovány způsobem jejích provozu SaaS a on-premise. V předchozích kapitolách byly oba systémy podrobeny detailní analýze zaměřené na porovnatelné aspekty řešení. Zde je jejích shrnutí: Funkce matriky Přehled všech údajů vedených v rámci matriky je v obou aplikacích realizován formou karty žáka. Jak již bylo zmíněno, v otázkách rozsahu evidovaných dat a jejích předání na ÚIV jsou obě aplikace shodné. Ovšem existují i rozdíly: Oblast Bakaláři Škola OnLine Hromadný import Omezený, pouze osobní údaje Ano, pokrývá všechny oblasti dat Formáty importu CSV CSV, XLS, DBF Konfigurovatelný import Ne Ano, včetně ručních úprav importovaných dat před provedením importu Hromadné změny v záznamech Ne Ano, pouze jedna položka Podpora procesů specifikovaných v Ano, změnou údajů v kapitole příslušných polích Ano, změnou údajů v příslušných polích Přehledové sestavy Ano, včetně agregovaných výkazů S Ano, bez agregovaných výkazů S

43 3-01 Správa číselníků Ne Ano s možností úprav Platnost záznamů číselníků Vždy pouze aktuální verze Vždy pouze aktuální verze Verzování a historie záznamů Verzování ne, historie záznamů ano Verzování ne, historie záznamů ano Export PDF, XLS, DBF PDF, XLS Možnosti customizace Ne Ne Tabulka 9: Porovnání funkcí matriky v existujících řešeních Reflektování změn v legislativě Dodavatelé obou systémů garantují reflektování legislativních úprav v dodávaných aplikacích. Liší se zejména v způsobu distribuce nových verzí s požadovanými změnami a úrovni poskytované podpory. Oblast Bakaláři Škola OnLine Způsob promítnutí změn do aplikací Nová verze, nutno stáhnout a nainstalovat Nová verze, nasazení zajišťuje dodavatel Samostatné provedení změn v aplikaci dle změn v zákoně Ano, pokud není možné automatická aplikace Ano, pokud není možné automatická aplikace Podpora ze strany dodavatele Ano, návod v PDF a telefonická podpora Ano, návod v PDF a telefonická podpora Řešení chyb vzniklých nesprávným postupem školy Obnovení dat ze zálohy Musí se řešit individuálně s dodavatelem Tabulka 10: Porovnání reflektování změn v legislativě v existujících aplikacích Ovladatelnost Na porovnání ovladatelnost aplikací se můžeme dívat z různých uhlů pohledu. Uživatelské rozhraní je realizované ve dvou odlišných technologiích. Oblast Kvalita GUI 39 Bakaláři 4 2 Úroveň implementace inteligentního Žádná GUI On-line kontextová nápověda Škola OnLine Žádná Ne, pouze nápověda v Ano aplikaci a PDF dokument na webu dodavatele 39 Hodnocení stupni 1-5, kde 1 je nejlepší. (dle mého subjektivního názoru autora) 31

44 Tabulka 11: Porovnání ovladatelnosti existujících aplikací Technická realizace Oblast Bakaláři Škola OnLine Způsob provozu aplikací On-premise, desktopová aplikace pro jednu školu Multitenant SaaS webová aplikace pro více škol Bezpečnost Pouze omezením přístupu do aplikace zabezpečen formou přihlášení, hesla uložena v hash40 formátu SSL pro spojení mezi serverem a klientem, klientský certifikát, přístup do aplikace zabezpečen přihlášením, hesla uložena v hash formátu Škálovatelnost Pouze vylepšením hardwaru Dle možností aplikačního a databázového serveru HA, load-balancing, clustering jsou použitými technologiemi možné realizovat Záloha a obnova dat Ano, uživatelsky spravovaná Ano, ale pouze formou individuálního zásahu dodavatele HW požadavky Nepřesahují HW požadavky OS, existuje dokonce i 16-bitová verze Nejsou k dispozici SW požadavky operační systém MS Windows 95, 98, NT, MS Windows 2003, , XP, 2003, 2008,Vista 32-bit, Windows 7 32-bit SW požadavky databázový server MS SQL 2000, MS SQL MS SQL , MySQL 4.1+ SW požadavky běhové prostředí - IIS,.NET 2.0 SW požadavky klient - Internet Explorer 7+ Tabulka 12: Porovnání technické realizace existujících aplikací Musím zkonstatovat, že veřejně dostupných informací ohledně technického zastřešení aplikací existuje příliš málo. Je na škodu, když se potencionální zákazníci nemohou dozvědět více o bezpečnosti jejich dat, nebo o způsobu a garancích provozu. V případě Škola OnLine 40 Např. MD5 šifrování 32

45 je rovněž zarážející, že ačkoliv dodavatel všude přehlašuje, že veškerá komunikace probíhá zabezpečeným HTTPS protokolem, přihlašovací stránka je dostupná pouze přes HTTP protokol a tudíž se citlivé přihlašovací údaje odesílají v nešifrované podobě a jsou jednoduše zneužitelné. Cena a způsob autorizace Je všeobecně známo, že školství má problémy s financemi a proto je otázka ceny za pořízení a používaní softwaru na místě. Díky způsobu autorizace formou licence, která platí neomezeně se může zdát, že systém Bakaláři se z tohoto pohledu oplatí více. Uvážíme-li však skutečnost, že změny v zákonech si vyžadují vždy nové a nové verze, školy jsou musí nové verze nakupovat a platit za ně v podstatě paušálně. V obou případech se cena za pořízení, resp. provoz, odvíjí od počtu žáků, které školu navštěvují a vybraném rozsahu funkčností, neboli modulů. Aby mělo porovnání vypovídající hodnotu, byly vybrány pouze ty moduly, které jsou potřebné pro evidenci školní matriky a bude uvažována škola, která má do 600 žáků. To odpovídá 18 třídám (2 pro každý ročník) po 30 žácích. Oblast Bakaláři Škola OnLine Forma autorizace Časově neomezená licence Roční tarif Náklady na 3 letý provoz, každý rok 2x upgrade Pořízení: 1x = Kč Upgrade: 6x 0,20x = Kč Náklady na žáka: ca 17 Kč na žáka a rok Provoz: 3x = Kč Upgrade: 0 Kč Náklady na žáka: ca 20 Kč na žáka a rok Náklady na 5 letý provoz, každý rok 2x upgrade Pořízení: 1x = Kč Upgrade: 10x 0,20x = Kč Náklady na žáka: ca 17,5 Kč na žáka a rok Provoz: 5x = Kč Upgrade: 0 Kč Náklady na žáka: ca 20 Kč na žáka a rok Další náklady Náklady na výpočetní Žádné. techniku ve škole a její servis. U síťového využití navíc náklady na konfiguraci infrastruktury. Položky navíc zdarma Žádné Uživatelská podpora Standard, propojení se službami Windows Live@edu, aplikace ŽÁKOVSKÁ Složitost pořízení Není automatizované. Nutno Není automatizované. Nutno 33

46 vyplnit a odeslat objednávku, dodavatel školu kontaktuje a zašle jí zkušební licenci. Po zaplacení faktury dodavatel odešle škole požadovanou plnohodnotní licenci. kontaktovat dodavatele telefonicky. Potom bude mít škola k dispozici demo verzi společnou pro všechny zájemce. Po závazné písemní objednávce dodavatel škole zpřístupní plnohodnotnou verzi aplikace. Tabulka 13: Porovnání nákladů na provoz existujících aplikací Důvodem analýzy existujících řešení bylo kromě jejích vzájemného porovnání také zjištění jejích předností a nedostatků, které bude možné při specifikaci požadavků na systém zohlednit. Jako hlavní pozitivum lze jednoznačně brát ujasnění způsobu vedení evidence matriky v reálných prostředích. Dalšími zajímavými a inspirujícími oblastmi jsou: konfigurace importů pomocí šablon v systému Škola OnLine způsob organizace údajů a zavedení pojmu karta žáka v obou systémech hromadné změny položek v systému Škola OnLine Nicméně bylo zjištěno i několik oblastí, které u obou systému nejsou podporovány vůbec, nebo nedostatečně: Zcela absentuje inteligentní GUI např. našeptávače, statistická validace I přesto, že Škola OnLine nabízí interaktivní GUI přibližující se standardům Web 2.0, má aplikace v této oblasti hodně rezerv (např. našeptávače při psaní, plovoucí okna,...) Cena aplikací školy v těžké ekonomické situaci nejsou schopné platit ani relativně nízké ceny. Tvrzení známého českého podnikatele že zadarmo je nic bohužel nelze na školství zcela aplikovat. E-škola bude zdarma. Škola OnLine se sice tváří jako SaaS, objednávka systému telefonicky však patří ještě do minulého století a se SaaS nemá co dočinění. E-škola nabídne automatickou registraci během několika minut. Platnost číselníků ani jeden systém nezohledňuje platnost číselníků ve smysli zpětného zobrazení údajů žáka tak, jak by vypadaly v minulosti Vlastní formuláře ani jeden systém nepodporuje konfigurovatelný rozsah evidovaných údajů na kartě žáka. U obou systému zcela chybí popis, jak je řešena bezpečnost jejích dat. Slabé možnost škálovatelnosti 34 vlastní formuláře a

47 3. Analýza a návrh realizace 3.1 Software jako služba Před samotným návrhem architektury je vhodná krátká diskuse ohledně způsobu provozování výsledného produktu. Cílem práce je vytvořit produkt dostupný jako SaaS, čili jako službu na internetu. Co to ale ve skutečnosti znamená? Software poskytovaný v takovéto formě je kompletně hostován na serverech dodavatele a je dostupný pomocí internetového prohlížeče nebo proprietární klientské aplikace. SaaS z pohledu zákazníků je spojen s téměř nulovými náklady na pořízení informačního systému (pomineme-li náklady na zaškolení zaměstnanců apod. - samotná aplikace nic nestojí). Za využívání služby se platí pravidelné paušální poplatky dle tarifů a náklady jsou tak rozloženy v čase. Současně jsou náklady díky pravidelným paušálním poplatkům velmi dobře předvídatelné, bez neočekávaných nákladů při provozu a pokud se využívání software nevyplácí, lze používání kdykoliv ukončit. Další výhodou je automatická aktualizace software na nejnovější verzi bez jakýchkoliv dodatečných nákladů. To může být současně i nevýhodou, protože při rozsáhlejší aktualizaci mohou být uživatelé novou verzí aplikace zmateni. Skutečný SaaS nabízí také další služby spojené s provozem, např. on-line nápovědu, registraci do služby, placení za služby on-line a další. SaaS v ČR bohužel není příliš využívaným ani rozšířeným konceptem. Do ČR se totiž nedostává každý nový koncept, který je úspěšný v zahraničí a nebo se tato inovace přenáší výrazně pomaleji. SaaS se do firemního i veřejného prostředí dostává velmi pomalu a nedá se hovořit o tom, že by tu tento koncept v oblasti standardních podnikových informačních systémů (ERP, CRM) nabíral na síle. V porovnání se světovým děním je zde velký rozdíl, protože např. Salesforce.com41 začalo svůj provoz už v roce Jaké jsou ale konkrétní důvody tohoto stavu? Jsou to problémy s infrastrukturou? Hraje roli obava o bezpečnost svých interních údajů? Je to velikost trhu nebo přílišný vliv několika velkých hráčů na trhu a nasycenost trhu v oblasti některých řešení? Nebo je to absence kvalitních a opravdových SaaS aplikací? Doufám, že i tato práce přispěje k tomu, aby se povědomí o tomto konceptu zvýšilo. 3.2 Požadavky na systém Tato část práce se věnuje analýze a specifikaci požadavků na implementovaný systém. Oblasti evidence matriky škol je zainteresovaným stranám dobře známé, navíc přesně vymezené zákonem. Formulace požadavků je tak založena na analýze současného stavu v 41 On-line CRM systém provozovaný v USA. Více na je on-line na 35

48 kapitole 2. Důraz je kladen také na ty funkce nebo schopnosti, které v existujících řešeních zcela chybí, nebo jsou řešeny nedostatečně. Kromě toho jsou zde popsány požadavky na integraci a provozování systému ve smyslu on-line služby pro školy. Doporučené postupy pro specifikaci požadavků na software, jsou popsány v IEEE Tato norma popisuje možnou strukturu, žádoucí obsah a kvality softwarové specifikace požadavkům. Nicméně pro rozsah této práce postačuje vymezení funkčních a nefunkčních požadavků na základě vysbíraných informací o procese evidence matriky a sběru dat na ÚIV. Výsledkem je tedy taková sada požadavků, které činí výsledný produkt unikátním i přesto, že se jedná o známou problematiku Funkční požadavky V softwarovém inženýrství funkční požadavky definují očekávanou funkcionalitu systému nebo jeho komponent. Tyto požadavky jasně a přesně určují úkony, aktivity a akce, které musí systém podporovat. V našem případě se specifikace funkčních požadavků vztahuje na funkčnosti evidence školní matriky v tom rozsahu, který byl analyzován v kapitole 2. Při návrhu těchto požadavků byla zohledněna také analýza již existujících a používaných řešení. Jedná se především o oblasti funkcí, ve kterých analyzované systémy vykazovaly nedostatky. Požadavky na funkčnost jsou rozděleny do 3 skupin nástroje pro evidenci školy a žáků, nástroje pro administraci uživatelů, číselníků, formulářů a požadavky ve vztahu k registračnímu procesu. Jejich struktura má formu základního popisu požadovaných operací a z popisu polí, pokud jsou pro popisovanou funkčnost relevantní Nástroje pro evidenci školy a žáků evidence právnické osoby Právnická osoba, neboli ředitelství, vykonává vzdělávací činnosti a po právní stránce zastřešuje všechny provozované součástí školy např. základní školu, jídelnu a podobně. Ve vzdělávacím systému je jednoznačně identifikována pomocí REDIZO. Právnické osoby je možné vytvářet, upravovat a rušit. Rušením se rozumí nastavení příznaku zrušeno. Aplikace bude podporovat vyhledávání v seznamu právnických osob. evidované údaje: název, REDIZO, IČO, DIČ, právní forma, adresa evidence součásti právnické osoby Součást právnické osoby představuje školu, nebo školní zařízení určitého typu, 36

49 například základní školu. Je jednoznačně identifikována pomocí IZO. Právnická osoba nemůže mít vícero součástí stejného typu. Každá škola eviduje jedno nebo více míst výkonu činnosti - jde o adresy, na kterých se činnost školy reálně provozuje. Každá škola může být dále členěna na několik částí. Většina škol bude mít pouze jednu část. Pokud však škola vznikla například sloučením dříve samostatných subjektů, nacházejících se na několika různých adresách, případně používá-li škola ještě jiný evidenční program atp., je vhodné školu rozdělit na několik separátních částí. Toto dělení má následně dopad na vytváření výkazů pro sběr dat. Školu lze založit, upravovat a zrušit ve smyslu označit za zrušenou. Aplikace bude podporovat vyhledávání v seznamu součástí právnických osob. evidované údaje: název, IZO, typ součásti (číselník typů součástí), vyučovací jazyk (číselník RAVJ), místa výkonu činnosti (název a adresa) evidence žáka (matrika) Údaje žáka jsou kategorizovány dle významu na tzv. kartě žáka. Žáka lze vytvořit ve vybrané škole zadáním jeho jména, příjmení a rodného čísla. Další položky jsou vymezeny ve struktuře předávaných individuálních údajů v kapitole Karta žáka bude obsahovat položky třída, navštěvované předměty a všechny položky definované v centrální správě údajů. Kromě zadávání hodnot do evidovaných polí budou podporované tyto procesy: zahájení a ukončení studia vyplnění hodnot v položkách KOD_ZAH (číselník RAZD), KOD_UKON (číselník RAUD), resp. IZOZ (IZO školy, odkud žák přišel) odchod žáka ze školy během studia, přerušení studia úprava položky KOD_UKON (číselník RAUD) opakování, neabsolvování ročníku, přeřazení žáka, nástup do vyššího ročníku úprava položky třída a průběh vzdělání PRIZN_ST (číselník RAPV) individuální vzdělávací plány žáka nastavení poli INDI (viz kapitola 2.3.2) Při každé změně údajů na kartě žáka bude mít uživatel možnost vybrat volbu Nezohledňovat změnu v exportu pro ÚIV, což bude mít za následek ignorování této změny ve vztahu k exportu dat na ÚIV. Jedná se např. o případ překlepů nebo změny jména, která nemá na výkaz M 3 žádný vliv. Aplikace bude podporovat vyhledávaní v seznamu žáků vybrané školy s možností filtrace podle všech evidovaných položek. platnost a verzování Každý evidovaný údaj na kartě žáka bude evidovat platnost a verzi. Platností se 37

50 rozumí interval, pro který je údaj platný, např. žák navštěvoval ve školím roce 2008/2009 třídu 3.B a v roce 2009/2010 třídu 4.B. Záznam o navštěvované třídě bude v evidenci 2 krát jednou s platností od do a podruhé s platností od do Jedná se tedy o platnost, která ovlivňuje export dat na ÚIV. Všechny údaje budou navíc verzovány bez ohledu na platnost. Např. u žáka Jan Novák se při zadávaní udělal překlep v jeho jménu. Platnost jeho jména po opravě zůstává nezměněná, systém však bude evidovat také předchozí hodnotu a její platnost. centrální správa údajů evidovaných v matrice Položky zobrazované na kartě žáka budou centrálně konfigurovatelné. Každá takováto konfigurace bude vztažena k typu školy (dle číselníku typů škol). U každé položky karty žáka bude definovaná také platnost, po kterou bude tato položka k dispozici. Položky se dle typu evidovaných dat budou dělit na: výběr jedné hodnoty z číselníku výběr 1 z N hodnot z číselníku (s definicí minimálního a maximálního počtu) výběr hodnot 1 z N (hodnoty lze předdefinovat) textové pole textová oblast zaškrtávací box U každé položky bude možné nastavit základní typ validace: povinná položka, délka hodnoty, hodnota obsahující/neobsahující, minimální a maximální hodnota, regulérní výraz. Další volbou bude povolení evidence změn v hodnotách položky. Bude podporovaná také kategorizace položek, to znamená, každou položku bude možno přidělit do vytvořené kategorie (definované jménem). Položky v jednotlivých kategoriích budou na kartě žáka navzájem odlišeny formou záložek. import Data obsažené na kartě žáka bude možné importovat. Formát souboru bude CSV nebo XLS (verze MS Excel 2003+). Import bude konfigurovatelný bude možné zvolit, který sloupec odpovídá vybrané položce v evidenci údajů žáka. Import bude vícekrokový načtení souboru, přiřazení významů sloupců, případná úprava a potvrzení provedení operace. Při importu bude možné nastavit platnost pro všechny importované záznamy. hromadné změny položky Řada vyplňovaných údajů je vždy společná určité skupině žáků. Například obor 38

51 vzdělání či zaměření může být stejný pro všechny žáky ve třídě. Za tímto účelem bude aplikace podporovat změnu vybrané položky pro více žáků najednou. Při změně položky bude možné hromadně nastavit platnost. Také bude podporovaná změna platnosti pro všechny položky ve vybrané kartě žáka najednou. export Základní funkce exportu bude spočívat ve výběru položek z karty žáka nebo ze seznamu žáků a výběru formátu. Podporované formáty budou XML, CSV a PDF. Export do formátu XML dle specifikace výkazu M 3, tedy pro účel předání individuálních údajů žáků do ÚIV bude řešen speciální operací Export pro ÚIV. U tohoto typu exportu bude možné zvolit období. Název exportovaného souboru bude vytvořen dle pravidel uvedených v kapitole statistická validace Validace hodnot položek na kartě žáka bude podléhat také statistické validaci. Tím je myšlena validace ve smyslu porovnání rozsahu s nejčastěji se vyskytujícími již vyplněnými hodnotami. V případě neshody bude uživatel upozorněn, zápis jím zadané hodnoty však bude následně umožněn. našeptávač Vložení hodnot do textových polí na kartě žáka bude podporovat takzvané našeptávání. Jedná se o funkci, která na základě vstupu uživatele navrhne možnosti, ze kterých uživatel může vybrat. Tyto možnosti jsou nabízené na základě již vyplněných dat Nástroje pro administraci formulářů, číselníků a uživatelů číselníky Číselníky budeme rozlišovat na lokální a globální. Lokální číselníky jsou vztaženy ke škole. Jedná se o číselník tříd a předmětů. Globální číselníky jsou společné pro všechny školy. V aplikaci bude podporováno vytvoření nového číselníku a úprava hodnot existujících číselníků. Každý číselník obsahuje kód, název a popis. Kód číselníku je unikátní. Hodnoty číselníku obsahují také kód, název a popis. Každá změna bude mít za následek úpravu platnosti záznamu. Číselník tříd navíc obsahuje položky vyučovací jazyk třídy (číselník RAJO), typ třídy (číselník RATT) a číslo ročníku (číselník RARO). Číselník předmětů navíc obsahuje jazyk, ve kterém je vyučován (číselník RACJ). Aplikace bude podporovat zobrazení seznamu číselníků a jejích hodnot a nástroje pro jejich správu vytvoření, úpravu a změnu platnosti. 39

52 Uživatelé, vazby a role Uživatelé mají možnost upravit svůj profil. U uživatelů jsou evidovány tyto položky: jméno, přímení, , adresa, telefon a mobil. Každý uživatel má vazbu na jednu nebo vícero škol. Úroveň oprávnění závisí na roli, kterou uživatel pro danou asociaci má. V aplikaci budeme rozlišovat tyto role: administrátor, správce ředitelství, správce součásti (školy). Uživatelé lze vytvářet, upravovat a nastavovat vazby a role na vybrané školy. Aplikace bude podporovat vyhledávaní v seznamu uživatelů Požadavky na registrační proces Neregistrovaná osoba ve formuláři vyplní název školy, REDIZO, adresu, své jméno, a heslo. Aplikace na zadaný odešle aktivační odkaz, který musí žadatel otevřít. Platnost potvrzovacího u bude 48 hodin od založení požadavku o registraci. Po potvrzení se v aplikaci založí právnická osoba (ředitelství). Zároveň se registrovanému uživateli vytvoří uživatelský účet s vazbou na nově vytvořenou právnickou osobu a bude mu přidělena role pro správu školy. Uživatelským jménem pro přihlášení do aplikace bude , zadaný při registraci. Po dokončení tohoto procesu mu aplikace odešle s potvrzením o zřízení služby Nefunkční požadavky Nefunkční požadavky jsou takové požadavky, které kladou omezení na design a provedení (například požadavky na výkonnost, standardy kvality, nebo designové omezení). aplikaci realizovat jako multitenant SaaS použití opensource technologií použití technologií a nástrojů spadající pod GPL škálovatelnost Aplikace musí být škálovatelná horizontálně i vertikálně. zálohování a obnova možnost monitoringu Monitoring aplikace formou aplikačního logu. bezpečnost Připojení mezi serverem a klienty musí být realizováno HTTPS protokolem pomocí SSL. Hesla uživatelů budou ukládány v nečitelné podobě, např. ve formě MD5 hash. 40

53 3.3 Případy užití Cílová skupina uživatelů a role Aplikaci budou využívat pouze oprávněné osoby na škole. Mezi ně patří zejména administrativní pracovníci, ředitelé, popřípadě pověřeni učitelé. V každém případě ve vztahu k evidenci matriky budou vystupovat ve stejné roli uživatelé školy. Pro správu školy (uživatelských účtů, šablon importu a lokálních číselníků) bude existovat také role správce školy. Správcem školy může být kterýkoliv uživatel školy. Kromě těchto osob bude mít do aplikace přístup také servisní uživatel pro správu globálních číselníků a formulářů, popřípadě škol a uživatelů hlavní administrátor. Tyto tři role představují autorizované uživatelé. Osoby, které se do systému ještě nezaregistrovali, registraci nepotvrdili, nebo nejsou přihlášené označujeme jako neregistrované, resp. nepřihlášené Diagram případů užití Účelem této specifikace je vyjádření jednotlivých užití systému. Užití systému je vědomá činnost uživatele za účelem dosažení výsledku. Výsledkem můžeme chápat funkční požadavky specifikované v kapitole 3.2.1, to znamená interakci uživatele s aplikací prostřednictvím uživatelského rozhraní. Do případů užití nebudeme zahrnovat ty, které nevznikli vědomou činností, např. statistickou validaci a našeptávač Evidence právnické osoby, součástí a žáků Ilustrace 9: Diagram případů užití - právnická osoba 41

54 Administrátor může zobrazit seznam a karty existujících právnických osob, může vytvořit novou právnickou osobu a zrušit existující. Správce školy může zobrazit kartu své právnické osoby, upravovat ji a vytvářet její součásti. Ilustrace 10: Diagram případů užití - součást právnické osoby Administrátor zobrazuje karty součástí právnických osob. Uživatel školy může zobrazit karty součástí své právnické osoby Správce školy může zobrazovat, upravovat a rušit součást své právnické osoby, může upravovat místa výkonů činností a části školy. Ilustrace 11: Diagram případů užití - evidence žáků Uživatel školy, správce školy spravuje šablony importu a provádí import dat, exportuje data pro ÚIV, zobrazuje seznam a karty žáků ve své škole, může upravovat údaje vedené ve školní matrice své školy. 42

55 Administrace formulářů, číselníků a uživatelů Ilustrace 12: Diagram případů užití - správa položek formulářů a exportu Administrátor spravuje definice položek karty žáka a také kategorie položek, spravuje konfiguraci exportu pro ÚIV. Ilustrace 13: Diagram případů užití - správa číselníků Administrátor spravuje globální číselníky a může nahlédnout do číselníků školy. Správce školy spravuje číselníky školy a může nahlédnout do globálních číselníků. Uživatel školy může zobrazovat globální číselníky a číselníky školy 43

56 Ilustrace 14: Diagram případů užití - správa uživatelů Neregistrovaní uživatelé Aplikace neumožňuje neautorizovaný přístup. Neregistrované osoby můžou vykonávat pouze níže ilustrované operace. Ilustrace 15: Diagram případů užití neregistrovaní uživatelé neregistrovaný uživatel vyplňuje a odesílá registrační formulář neaktivní uživatel již odeslal registraci, ale zatím ji nepotvrdil 44

57 nepřihlášený uživatel má možnost se do systému přihlásit zadáním jména a hesla 3.4 Programovací jazyk Výběr programovacího jazyka je implikován typem aplikace. Jelikož se jedná o multitenant webovou aplikaci, čili klient-server architekturu, je zapotřebí implementaci provést tak, aby byla serverová část aplikace maximálně spolehlivá, zabezpečená, škálovatelná a spravovatelná. Klientská část musí nabízet interaktivní a atraktivní prostředí pro práci. Všechny tyto aspekty jsou znakem produkčního enterprise 42 nasazení, co je také cílem této práce. Běhové prostředí, které je pro vybraný programovací jazyk dostupné, musí tyto vlastnosti splňovat. Další podmínkou výběru jazyka je existence těch knihoven a frameworků43, které jsou z hlediska implementace důležité: generování HTML stránek s podporou layoutu a komponent (prezentační vrstva) podpora technologie AJAX knihovny pro realizaci persistenčního mechanizmu logování a real-time monitoring aplikace export do XML a PDF rozšiřitelnost ve vztahu k SOA44 Dalším hlediskem je potřeba zabezpečení kontinuálně udržitelného vývoje. K němu bezpochyby přispívá komunitní podpora, dokumentace, otevřenost zdrojového kódu, neustálý další vývoj jazyka a možnosti strukturalizace zdrojového kódu v případě, že se jedná o robustní projekt, což je v tomto případě splněno. Výběr programovacího jazyka se tedy zredukoval na kvalitativní požadavky na běhové prostředí, nabízené knihovny řešící některé implementační oblasti a možnosti udržitelnosti vývoje. Z tohoto hlediska se nabízejí dva technologické směry : jazyk z rodiny.net C#, J#, F#, Visual Basic nebo Dephi, tedy jazyky a technologie společnosti Microsoft programovací jazyk Java (a platformy JSE, JEE) Další programovací jazyky, jako jsou PHP, Python, Perl, C/C++ nebo LISP jsou sice použitelné a určitě v odborné veřejnosti existují jejích zastánci, nicméně úroveň vlastního programování některých podpůrných komponent by bylo bezpochyby komplikovanější (nativní AJAX podpora, webové služby, práce s exporty), nebo v některých případech zcela 42 Rozumí se podnikové nasazení. V našem případě je podnikem škola. 43 Na rozdíl od knihovny, která obvykle obsahuje funkce, které vykonají určitou činnost a kontrolu vrátí volajícímu, framework sám řeší určité komplexní činnosti, např. perzistenční mechanizmus, nebo prezentační vrstvu. 44 SOA označuje Service Oriented Architecture neboli architekturu orientovanou na služby, která je v poslední době často používaná. Je dosažena např. webovými službami. 45

58 nemožné (real-time monitoring, persistenční mechanizmus,...). Důvodem je absence knihoven a vývojář by musel některé oblasti programovat sám. Pro implementaci byl zvolen programovací jazyk JAVA. Podobně jako.net je v poslední době rozšířenou a preferovanou platformou pro vývoj webových aplikací. Jeho nevýhodou oproti platformě JAVA je uzavřenost (JAVA je opensource45), slabší integrovatelnost s webovými servery (např. Apache) a také možnosti monitoringu běhového prostředí. Dlouholetá paradigma nepřenositelnosti.net mezi OS již díky softwarové platformě Mono46 neplatí. Cílem této krátké diskuse však není rozhodnout, který je lepší nebo horší. Musíme vycházet z účelu, ze stanovených cílů a v neposlední řadě také z osobních zkušeností a preferencí. 3.5 Vývojové prostředí, nástroje softwarového inženýrství Pro vývoj bylo použito vývojové prostředí Eclipse, které kromě standardní výbavy47 nabízí veškeré podpůrné rozšíření použité během implementace AspectJ48, Subclipse49 nebo RunJetty50. Pro vytváření UML modelů a diagramů byl použit nástroj Visual Paradigm for UML Standard Edition. Vývoj softwarového produktu probíhá v určitých cyklech. Ve standardním případě se ho účastní také vícero osob. To znamená, že samotní zdrojový kód je v průběhu vývoje modifikován, v mnoha případech i vícerými vývojáři najednou. Zdrojový kód v rámci vývoje této práce bude tedy umístěn v systému VCS (Version Control System), čili v systému pro správu verzí. Jedná se o centralizované úložiště souborů s podporou jejích verzování a vztažených procesů (např. porovnání, řešení konfliktů, atd.). Jelikož se na implementaci v současné době podílí pouze jedna osoba, nebudou využity benefity sdílení a paralelního přístupu. Na druhou stranu je programátorovi k dispozici přehled historie změn v kódu a tím pádem může vidět co, kdy a za jakým účelem v kódu změnil nebo přidal. Pokud bychom uvažovali o zapojení dalších osob do vývoje, takovýto systém by byl jeho nutným předpokladem. Pro účely projektu je použit systém SVN. Ve vývojovém prostředí Eclipse je podporován již zmíněným rozšířením Subclipse Jak z hlediska dostupnosti zdrojového kódu tak z hlediska legální dostupnosti licencí Více na Editor zdrojového kódu, kompilátor, debugger, coding assistant Prostředí pro práci s aspekty. Více informací je on-line na Podpora pro připojení na Subversion (SVN) systém. Více onformací je on-line na 50 Podpora pro integraci servlet kontejneru Jetty do prostředí Eclipse. Více informací je k dispozici na 46

59 3.6 Návrh architektury Návrh architektury se skládá ze dvou částí návrh z aplikačního hlediska (vnitřní struktura implementace, knihovny, návrhové vzory tomu se věnuje kapitola 3.7) a z hlediska integračního (běhové prostředí, databáze, operační systém, ). V této kapitole se zaměříme na architekturu z hlediska integrace na její návrh a výběr vhodných technologií, pomocí kterých bude sestavena. Aplikace bude realizovaná v architektuře server-klient, která počítá s netriviální infrastrukturou. Ta se skládá z běhového prostředí, aplikačního serveru a separátní databáze běžícím na GNU/Linux operačním systému Běhové prostředí a aplikační server Běhové prostředí pro jazyk JAVA představuje JVM (Java Virtual Machine). Za předpokladu, že systém bude využíván větším počtem uživatelů (multitenant), co má za následek větší nároky na systémové prostředky, zejména operační paměť, byla zvolena 64-bitová varianta. Důvodem je rozsah alokované virtuální paměti pro jeden proces v 32-bitovém systému je možné alokovat virtuální paměť pouze do výšky 2^32 B, co představuje velikost <4GB (zpravidla kolem 3GB, protože něco si rezervuje jádro systému). V 64-bitovém máme k dispozici více než 1TB. Aplikace bude realizovaná jako Java Servlet51, který pro svůj běh potřebuje servlet kontejner. Kromě toho počítá s podporou JDBC52 a JNDI. Pro produkční účely vhodným aplikačním serverem splňujícím požadavky na monitoring a konfiguraci webového serveru (např. SSL) je GlassFish53. Aplikace E-Škola poběží na distribuci jdk_1.6.0_22 od společnosti Oracle (dříve SUN Microsystems) a na aplikačním serveru GlassFish Databázový server Při výběru databázového serveru bylo nutné zohlednit několik faktorů, zejména podporu nativního ukládání XML souborů a základní operace na tímto typem dat. Dalším faktorem je podpora ze strany frameworku Hibernate, existence JDBC ovladače a GPL. Z hlediska rozšíření, podpory a referencí v komerčních nasazeních (např. PostgreSQL je využíván jako databáze pro službu Skype) byly uvažovány databáze MySQL a PostgreSQL. 51 Specifikace JSR-315, JavaTM Servlet 3.0, on-line k dispozici na 52 Java Database Connectivity je API definující jednotné rozhraní pro přístup k relačním databázím v programovacím jazyku Java. 53 Více informací on-line na 47

60 Díky lepší podpoře konfigurace s ohledem na způsob provozu (cache, indexace, atd.), lepší možnosti strukturalizace (tablespaces, schémata) a lepší podpoře pro XML (více funkcí) je vhodnější varianta PostgreSQL. Aplikace bude využívat databázový server PostgreSQL Operační systém Ačkoliv provozování běhového prostředí a databázového serveru je možné na celé řadě operačních systémů (těch, na kterých je možné tyto komponenty nainstalovat), aplikace bude provozována na operačním systému z rodiny GNU/Linux. Předpokladem je, že server bude umístěn v hostingovém centru a tudíž veškerá jeho zpráva bude možná pouze vzdáleně, pomocí terminálu. Pro správu, konfiguraci, deploymenty a monitoring je tato volba optimálním řešením. Aplikace E-Škola bude provozována na 64-bitovém operačním systému SUSE Linux Diagram nasazení Ilustrace 16: Diagram nasazení 48

61 3.7 Návrh implementace Tato část práce se věnuje návrhu požadovaných funkcí z programovacího hlediska co a jak implementovat, aby realizace splnila účel. Součásti návrhu je výběr vhodných technologií, kterými bude implementace provedena. Rutinním záležitostem, jako například vytvoření školy, nebo uživatele pomocí odeslání formuláře se návrh nevěnuje. V textu nejsou vysvětlovány základní pojmy z oblasti programování a návrhu struktur (objekt, rozhraní, ). Návrh se také nevěnuje technologiím jako jsou např. HTML, CSS nebo JavaScript. Jejích účel a způsob užití je považován za známý. Za známé jsou považovány také základní koncepty z oblasti návrhu webových stránek (např. že aplikace musí mít menu, jak má vypadat přihlašovací proces,...) Vnitřní architektura implementace Vnitřní architektura implementace bude organizována do vrstev dle strukturálního návrhového vzoru MVC (více v kapitole Návrh vychází z obecní strategie implementace moderních webových aplikací, která představuje oddělenou prezentační, logickou a datovou část. Model bude představovat entity reprezentující např. uživatele, školu, žáka, formulář společně se základní logikou a operacemi, jako jsou zrušení, nastavení platnosti nebo nastavení nových hodnot. Součástí modelu je také mechanizmus ukládání jeho reprezentace do databáze (viz kapitola 3.7.3). Komponenty VIEW a CONTROLLER přestavují prezentační vrstvu zabezpečující potřební logiku ve vztahu k interakci uživatele s aplikací a budou realizované vybraným frameworkem (viz další kapitola). Základní podmínkou bude dodržení pravidel o nezávislosti nižší vrstvy od vrstvy vyšší. V praxi to bude znamenat, že model a databázový subsystém nebudou ovlivněny prezentační logikou a naopak, prezentační logiky bude využívat jejích služeb ke své činnosti (viz obrázek níže). Složitější logika a datový subsystém budou představovat separátní vrstvy aplikace. Jednotlivé služby těchto vrstev budou reprezentovány metodami tříd, které jsou sdruženy do objektů podle sémantiky a předmětu jejích zaměření (např. Service). Zpravidla jsou bezstavové a vykonávají komplexnější operace nad modelem entit (viz také ). 49

62 Ilustrace 17: Schéma navrhované struktury implementace Prezentační vrstva Prezentační vrstva bude implementovaná ve frameworku Tapestry54. Jedná se o moderní technologii pro tvorbu webových aplikací, který doplňuje a navazuje na standard Java Servlet55. Použití komponent umožňuje výrazně zvýšit produktivitu vývoje webu - to je také důvod, proč všechny nové frameworky, včetně Java Server Faces, a ASP.NET, jsou založené na komponentově orientovaném přístupu. Tapestry je navíc snadno integrovatelný s jakýmkoliv druhem backendu, včetně Spring a Hibernate (viz kapitola 3.7.3). Obrovskou výhodou je nativní podpora pro technologii AJAX a také zabudovaná validace formulářových dat. Tapestry přináší skutečný objektově orientovaný přístup do tvorby webových aplikací v jazyce JAVA. Z hlediska implementace rozdělíme prezentační vrstvu do dvou kategorií stránky (page objekty) a komponenty56. Stránky složené z komponent budou odpovídat struktuře uživatelského rozhraní. Prezentační vrstva z pohledu GUI bude realizovaná pomocí layoutu základním rozložení všech stránek (menu, tělo, nadpisy více v návrhu GUI kapitola 3.9). Interakce s uživatelem bude vedena pomocí plovoucích dialogových oken realizovaných technologií 54 Základní popis a informace jsou k dispozici on-line na 55 Dle specifikace JSR JavaTM Servlet Více v uživatelské příručce on-line na a 50

63 AJAX57. Tato technologie bude využita i u dalších komponent, např. našeptávač při psaní textu (viz kapitola 3.7.7). Implementace bude počítat také s lokalizací58. Stránky a komponenty budou obsahovat klíče, které budou Tapestry přeložené do požadovaného jazyka dle jejích definice. Součástí bude také mechanizmus ověřování oprávnění (viz kapitola 3.7.9). Tato vrstva bude zapouzdřovat základní logiku a řídit workflow. Návrh uživatelského rozhraní je diskutován v kapitole Databázový subsystém Databázový subsystém, nebo také perzistenční mechanizmus, bude realizován frameworkem Hibernate59. Umožňuje tzv. objektově-relační mapování, kdy jsou perzistentní objekty mapovány na relační tabulky ve skutečné databázi. Tato technologie zapouzdřuje veškerou potřebnou funkčnost v souvislosti s uložením dat v databázi, včetně připojení, komunikace a transakčního zpracování. Mapování objektů bude realizováno XML mapovacím souborem60. Hibernate umožňuje připojení na celou řadu různých databází, včetně pro tuto implementaci použitou PostgreSQL. Přizpůsobení různým syntaxím a funkcím těchto databází je realizováno takzvaným dialektem61. Z pohledu implementace bude jeho použití zapouzdřeno v DAO vrstvě. Každá entita bude mít vlastní sadu DAO objektů (např. objekt User bude mít UserDAO a podobně). Paralelní přístupy a změny stejných záznamů budou vyřešeny principem optimistického uzamykání (více v kapitole ), které Hibernate implementuje. Z hlediska správy transakcí a připojení do databáze bude využito konceptu OpenSessionInView ten reprezentuje takový cyklus databázových transakcí, že jsou dostupné během celého životního cyklu uživatelského požadavku, ne pouze v DAO vrstvě a tím je databázová transakce k dispozici i během generování HTML stránek. Tento koncept je implementován frameworkem Spring62. Díky tomuto přístupu bude možné provést tzv. lazy natahování data se fyzicky z databázi načtou až v případě, že jsou potřeba tomuto způsobu se říká on-demand. Transakce nebudou realizované deklarativní formou, ale budou spravované transakčním manažerem. 57 AJAX je v Tapestry výborně podporován, viz 58 Texty budou zobrazované v závislosti na jazyku uživatele (nastavení v prohlížeči).více informací je na 59 Více informací on-line na Hibernate existují i jiná řešení, např. TopLink nebo ibatis. 60 Kromě XML mapování to jsou k dispozici také anotace na úrovni modelu entity. Více informací on-line na 61 Hibernate podporuje i další dialekty. Jejích seznam je k dispozici na 62 Více na 51

64 Ilustrace 18: Sekvenční diagram popisující chování OpenSessionInView filtru Pro generování identifikátoru instancí objektů (ID) bude použito sekvencí (ve vybrané databázi jsou podporovány) Platnost a verzování V aplikaci rozlišujeme platnost a verzování objektu. Platností rozumíme interval, ve kterém je daný objekt platný ve vztahu k evidenci matriky, např. informace o třídě žáka. Realizace bude provedena evidencí položek platnost od a platnost do. Každý perzistentní objekt bude navíc verzován. Verzování představuje evidenci všech předchozích hodnot polí tohoto objektu v čase. Realizace bude provedena fyzicky v databázi a pro databázový subsystém bude transparentní: pro každou tabulku v databázi bude existovat její dvojče obsahující historii změn. Například tabulka USER bude mít USER_HISTORY. Primární klíč první tabulky bude obsahovat pouze ID, ve druhé tabulce to bude ID a VERSION. každá takováto dvojice tabulek bude obsahovat také VIEW (pohled) obsahující všechny položky definované v Hibernate mapování. Tento pohled bude pojmenován jako USER_V. V definici mapování bude uveden jako cílová tabulka pro daný perzistentní objekt. 52

65 v databázi se vytvoří trigger, který bude zachytávat pokusy o vložení a změnu dat v pohledu USER_V. Při vložení zapíše nový řádek do obou tabulek USER i USER_HISTORY. Při změně hodnoty v tabulce, zapíše do USER_HISTORY nový řádek a záznam v tabulce USER upraví dle požadavků. Realizace je popsána v kapitole Pravidla implementace entit Jak již bylo zmíněno, pod pojmem entita si můžeme přestavit kódovou abstrakci školy, žáka, uživatele, číselníků nebo formulářů. Entity budou implementovány ve stylu POJO63. Instance těchto objektů budou reprezentovat konkrétní školu, žáka, učitele atd. Implementace každého objektu se bude řídit těmito pravidly: každý objekt bude kromě výchozího konstruktoru obsahovat také konstruktor, ze všemi povinnými proměnnými k proměnným objektu se bude přistupovat výlučně přes getter a setter metody64. Setter metody proměnných pouze ke čtení budou kvalifikovány jako protected. Getter metody na měnitelné objekty (např. kolekce) budou také protected a pro přístup k ním budou použiti speciální metody, které budou vracet jejich nezměnitelné kopie65. Možno využít implementaci z Apache Commons Lang. id, version identifikátor a verze objektu pokud objekt obsahuje kolekce, přidávání nebo odstraňování položek z nich bude provedeno výlučně metodami add(..) resp. remove(). metoda int hashcode() - každý objekt bude schopen o sobě sdělit unikátní číselnou reprezentaci. Možno využít implementaci z Apache Commons Lang. metoda boolean equals(object other) každý objekt bude schopen vyhodnotit, jestli odpovídá objektu uvedeném v parametru. Společně s metodou hashcode() jde o nutnou součást implementace při použití frameworku Hibernate ale také pro možnost použití instancí takovýchto objektů v různých seznamech nebo hašovacích tabulkách Dynamické formuláře, uložení dat Položky evidované na kartě žáka bude možné centrálně konfigurovat. Každá takováto definice bude vztažena ke konkrétním typům škol. Definice položky bude bude obsahovat: 63 Jedná se o třídy reprezentující entity (školu, žáka,...), nikoliv služby, JavaBeans, Servlet a jiné. K instančním proměnným se přistupuje pomocí get a set metod. 64 Jsou myšleny metody setvariable(...) a getvariable(), kde variable je název instanční proměnné. 65 Možné realizovat použitím metody java.util.collections.unmodifiableset, Map, List,... 53

66 název povolení statistické validace typ (text, datum, výběr 1 z N) referenci na číselník (volitelné) definici validace kategorii popis odkaz na kontextovou nápovědu platnost Karta žáka bude takto definované položky zobrazovat podle kategorií. Volbou zobrazit k datu bude možné zobrazit i již neplatné položky. Uložení bude realizováno ve formátu XML. Aby bylo uložení vůči prezentační vrstvě transparentní, bude vytvořena implementace pro automatickou transformaci dat z POJO do XML a obráceně. Struktura uložených dat bude vypadat následovně: <?xml version= 1.0 encoding= Windows-1250?> <data person-id= 1234 changed-when= cas zmeny changed-by= username > <entry field-id= id definice code-book= kod ciselniku type= typ polozky > <value changed-when= cas zmeny changed-by= username >HODNOTA</value> <value changed-when= cas zmeny changed-by= username >HODNOTA2</value> <value changed-when= cas zmeny changed-by= username >HODNOTA3</value> </entry> <entry field-id= id definice code-book= kod ciselniku type= typ polozky > <value changed-when= cas zmeny changed-by= username >HODNOTA</value> <value changed-when= cas zmeny changed-by= username >HODNOTA2</value> <value changed-when= cas zmeny changed-by= username >HODNOTA3</value> </entry>... </data> Našeptávač při psaní textu Díky nativní podpoře technologie AJAX ve frameworku Tapestry je možné implementovat uživatelsky příjemnou funkci, která při zadávaní hodnot do textového pole uživateli nabídne možné hodnoty. Tyto hodnoty budou nabízeny dle statistiky nebudou se natahovat z databáze. Statistika se bude vytvářet pro každou položku formuláře zvlášť a bude vztažena ke konkrétní škole. Statistika se bude vést ve formě vlastní databázové tabulky. Z důvodu optimalizace systému bude aktualizace statistiky provedena pouze jedenkrát denně nebo ručním spuštěním Statistická validace Využití statistiky popsané v předcházejícím odstavci bude i v oblasti validace. Pokud bude mít položka povolenou statistickou validaci, systém ověří, že zadaný vstup v určité toleranci odpovídá nejčastějším vkládaným hodnotám. Např. pokud uživatel zadá datum narození žáka 54

67 na , systém ho před zapsáním tohoto údaje varuje. Validace bude obsahovat několik variant v závislosti na datovém typu číselná, datumová a textová Oprávnění a bezpečnost Důležitou součástí aplikace je její bezpečnost. Jelikož se jedná o multitenant řešení, tato otázka je obzvlášť důležitá. Oprávnění bude v aplikaci reprezentováno asociacemi mezi uživatelem a školou. Asociace bude obsahovat také soubor rolí. V každém objektu stránky bude před jeho odesláním klientovi vyhodnoceno, jestli má přihlášený uživatel daný kontext (např. URL s parametrem ID konkrétní školy) právo zobrazit. Tím bude vyřešena možnost podhození URL s jinými parametry (např. změna parametru ID školy). Také komponenty pro vykreslování hypertextových odkazů budou funkčnost ověření oprávnění implementovat. V případě, že uživatel nebude mít pro zobrazení odkazovaného kontextu oprávnění, odkaz se mu nezobrazí. Co se týče bezpečnosti uživatelských hesel, ty budou uloženy v nečitelném formátu jako MD5 hash. Při přihlášení uživatele se jím zadané heslo ve převede na tento formát a porovná se s uloženým Import Hromadné navedení dat bude realizované formou importu a bude se vztahovat pouze na položky z karty žáka. Podporované formáty importu budou XLS (Microsoft Excel 2003+) a CSV. U každého importu bude možné nastavit kódování. Proces importu bude vypadat následovně: 1. výběr šablony importu a volba typu souboru (CSV, XLS) a oddělovače 2. nastavení významu sloupců mapování na položky karty žáka. Definice musí obsahovat identifikaci žáka rodné číslo nebo kombinací jména a příjmení. Podle toho, která volba je vybrána, definice musí obsahovat buď mapování na sloupec s rodným číslem nebo na kombinaci jméno a příjmení. 3. po odeslání formuláře se zobrazí náhled importovaných řádků. Zde bude možnost jednotlivé záznamy procházet a upravovat. Nastavit bude možné také platnost. Před finálním potvrzením importu bude možné zvolit volby aktualizovat data nebo přepsat data. 4. provedení importu a zobrazení výsledků. Aplikace dále nabídne uživateli, jestli chce definici mapování importu uložit jako šablonu k dalšímu použití 55

68 Pro práci s CSV souborem bude použit framework opencsv, který zapouzdřuje nástroje pro jeho zpracování. Pro XLS formát využijeme Apache POI. Ilustrace 19: Diagram procesu importu Export Export v aplikaci rozlišujeme na dvě skupiny export do XML pro předání dat na ÚIV a export zobrazených údajů (např. karty žáka nebo různé seznamy). Export pro předání dat na ÚIV je nedílnou součástí aplikace. Jeho struktura bude konfigurovatelná pomocí Groovy skriptu, který bude možné do aplikace nahrát. Groovy skript bude obsahovat definici hlavičky a generátor vět. Vstupem generátoru vět bude kolekce transfer objektů reprezentujících individuální údaje žáka. V skriptu budou k dispozici proměnné představující položky karty žáka a údaje o přihlášeném uživateli nebo škole. Jednotlivé definice budou obsahovat název a platnost, např. Export pro sběr dat na ÚIV k Z důvodu větší paměťové náročnosti bude export asynchronní použitím PipedOutputStreamu66. Dalším typem exportu je PDF výstup zobrazených dat karty školy, karty žáka nebo seznamu žáků. Export do PDF bude realizován použitím frameworku itext konverzi upraveného HTML výstupu Proces registrace Registrační proces představuje dva kroky uživatel vyplní a odešle registrační formulář, 66 Více informaci on-line na 56

69 následně mu přijde potvrzovací , ve kterém musí otevřít obsažený aktivační odkaz. Po jeho otevření se mu zřídí účet. Odesláním formuláře se v aplikaci vytvoří záznam o požadavku na registraci a vygeneruje se ověřovací kód, šifrován v MD5. Tento ověřovací kód bude parametrem odkazu v aktivačním u. Požadavek na registraci bude platný 48 hodin. Do té doby nebude možné vytvořit novou žádost o registraci na stejný . Pokud uživatel do 48 svůj neaktivuje, může vytvořit požadavek nový. Ilustrace 20: Diagram procesu registrace bude odesílán v plain-text formátu. Pro generování u budou použity šablony, napsané ve skriptovacím jazyku Groovy (návrhy textů ů jsou v příloze). Podpora jeho interpretace v jazyku JAVA je zajištěna příslušnou knihovnou Návrhové vzory Různé přístupy k programování, ať už to jsou objektově, procedurálně nebo funkcionálně orientované koncepty mají jedno společné. Postupem času se zjistilo, že během implementace se stejné, nebo podobné problémy pořád opakují. Návrhové vzory představují obecné řešení těchto problémů. Dělím je na strukturální popisují možnosti dekompozice a hierarchie implementace (např. Facade, Adapter, Decorator), dále vzory zaměřené na procesní stránku a chování (např. Observer, Visitor, Iterator) a nakonec vzory pro různé způsoby vytváření instancí objektů (např. Factory, Prototype). Návrhový vzor není knihovnou nebo částí zdrojového kódu pouze popisuje princip řešení. Konkrétní implementaci už musí vývojář provést sám. Protože chceme, aby výslední produkt po implementační stránce netrpěl dětskými 57

70 nemocemi, implementaci provedeme dle používaných vzorů pro vývoj podobných aplikací. Vyhneme se tak problémům, které můžou nastat v průběhu implementace např. budeme chtít použít jiný perzistenční mechanizmus a díky nesprávnému návrhu struktury modelu budeme muset přepisovat veškerý zdrojový kód. Oblíbeným je také příklad se změnou frameworku prezentační vrstvy pokud k tomu dojde, model a datový subsystém by se vůbec neměl změnit. S ohledem na zvolené technologie a návrh, během implementace použijeme tyto návrhové vzory: MVC Model-View-Controller celková vnitřní architektura základem je oddělení prezentační vrstvy od modelu a vnitřní logiky aplikace (viz obrázek níže). V našem případě komponentu View budou představovat komponenty a.tml soubory. Controller bude reprezentován page objekty a jejích metody společně s interní logikou aplikace. Ilustrace 21: Schéma návrhového vzoru MVC Domain model organizace modelu - každý objekt reprezentuje smysluplnou entitu a zapouzdřuje její základní chování (např. právnická osoba objekt Facility obsahující metodu discard()) Data mapper způsob realizace propojení modelu a databázového subsystému, tak aby byly na sobě nezávislé. Ilustrace 22: Schéma návrhového vzoru Data Mapper 58

71 Optimistic locking řešení paralelního přístupu ke stejným záznamům. Zabraňuje konfliktům mezi paralelně běžícími transakcemi nad stejným doménovým objektem. Detekuje konflikt a implementuje návrat (rollback) problémové transakce. Facade složitější logika včetně integrace mailové služby a přístupu do databázového subsystému budou zapouzdřovat objekty Facade, kterých služeb bude prezentační vrstva využívat. Kromě návrhových vzorů existují i návrhové anti-vzory ty mají naopak za cíl odhalit možné konceptuální rizika v návrhu. Zkoumání návrhu v tomto ohledu však provedeno nebude Přehled technologií Název Verze Použití Hibernate 3.5 Databázový subsystém, uložení formulářových dat ve formě XML Tapestry 5.1 Prezentační vrstva, AJAX AspectJ Databázové transakce, OpenSessionInView Spring konfigurace aplikace, IoC67 Log4j Vytváření systémového logu Apache Commons 1.8 itext Export do PDF Groovy ové notifikace a definice exportu na ÚIV opencsv 2.1 Import CSV souborů POI 3.6 Import XLS souborů Tabulka 14: Přehled použitých technologií 3.8 Datový konceptuální model Tento model ilustruje existenci a vzájemné logické propojení primárních entit, které jsou v aplikaci evidované. Jedná se o konceptuální model, ve kterém není zohledněna podpora verzování a historie změn záznamů. Způsob implementace této funkčnosti je popsán v kapitole Inversion of control 59

72 Ilustrace 23: Datový konceptuální model Právnická osoba (ředitelství) Představuje entitu stojící na vrcholu hierarchie evidence školy. Každý registrovaný uživatel je asociován s právnickou osobu. Jejím unikátním identifikátorem je REDIZO. Každá právnická osoba má jednu a více součástí. Součást právnické osoby Součást představuje školu, nebo školské zařízení (dále jen škola), které je podřízeno právnické osobě, která ji zřizuje. Škola může mít jedno nebo více míst výkonu činnosti a žádnou nebo více částí. Část školy Představuje logickou část školy. Může odpovídat místu výkonu činnosti nebo rozdělení na 1. a 2. stupeň. 60

73 Místo výkonu činnosti Představuje název a adresu místa, kde je vykonávaná vzdělávací činnosti. Např. laboratoře, sportoviště atd. Třídy Každá škola eviduje seznam aktuálně platných tříd. Šablona importu Každá škola má možnost definovat šablony importu, které může při importech opakovaně použít. Položky šablony importu Šablona importu se skládá s definic jednotlivých položek názvu a definice mapování na položky z karty žáka Žák Každá škola eviduje žáky. Žák je jednoznačně určen rodným číslem, jménem a příjmením. Žák nemusí být zařazen do třídy. Školní rok je evidován pomocí nastavení platnosti přiřazení záznamu třídy. Data žáka (karta žáka) Data žáka, neboli jeho karta, představuje evidenci všech potřebných položek. Jelikož jsou evidované položky konfigurované dynamicky, data jsou uložena jako XML soubor (viz 3.7.6). Každá karta žáka má svou globální definici. Definice formuláře Formulář představuje samotnou evidenci údajů žáka. Do budoucna se počítá s využitím také ve spojitosti s jinými evidovanými entitami, např. se školou, nebo pro vlastní definici evidovaných dat. Z tohoto důvodu neredukujeme definici formuláře na definici údajů evidovaných na kartě žáka, ale obecně, na definici formuláře. Položka formuláře Položka formuláře specifikuje typ dat které jsou pomocí ní evidované (viz 3.7.6). Kategorie položek formuláře Každá položka formuláře může být součástí kategorie, která slouží pro lepší organizaci formulářových dat na kartě žáka. 61

74 Lokální číselník Představuje číselník, který je vztažen ke konkrétní škole. Každá škola má vlastní lokální číselníky, které si spravuje. Číselník je jednoznačně určen svým kódem. Globální číselník Jedná se o číselníky, které jsou společné pro všechny školy v aplikaci. Číselník je jednoznačně určen svým kódem. Položka číselníku Číselníky obsahují položky. Je to seznam hodnot, které jsou použity při samotné evidenci. Položka formuláře se vztahuje k číselníku (např. Vyučovací jazyky ), ale hodnoty, které je možné do této položky vyplnit, jsou např. Český jazyk. Tato hodnota představuje položku číselníku Vyučovací jazyky. Uživatel Uživatel představuje osobu, která aplikaci využívá. Pokud byl uživatel vytvořen registrací, je evidován také jeho registrační požadavek. Asociace uživatel škola Každý uživatel může být asociován s jednou nebo vícero školami. Každá asociace obsahuje také roli, kterou uživatel v asociované škole má. Registrační požadavek Registrační požadavky evidují pokusy neregistrovaných uživatelů o registraci do aplikace. 62

75 3.9 Návrh uživatelského rozhraní Návrh uživatelského rozhraní musí vycházet z primárního účelu aplikace evidence údajů. Zaměříme se na základní zobrazovací a ovládací prvky, ze kterých bude aplikace po grafické stránce skládat Layout Layout aplikace pozůstává ze sedmi hlavních bloků a je využit na každé zobrazované stránce aplikace přihlášenému uživateli. Ilustrace 24: Návrh layoutu aplikace 1. Hlavní menu a podmenu Obsahuje odkazy pro přechod do jiných částí aplikace. Položky se vztahují k aktuální pracovní ploše a vedou na přehledové stránky jednotlivých funkcí. Podoba menu je závislá na přístupových právech uživatele. 2. Údaje o účtu uživatele Informuje o tom, kdo je v aplikaci aktuálně přihlášen. Po najetí myší lze zvolit odkaz pro přechod na stránku Upravit profil, nebo Změnit heslo, jenž jsou automaticky dostupné pro každého přihlášeného uživatele. 63

76 3. Odhlášení Slouží k bezpečnému manuálnímu odhlášení z aplikace. 4. Kontext Obsahuje název zařízení, ve kterém je uživatel zaregistrován a aktuálně se nachází. V případě, že je uživatel součástí více zařízení, je pak tento kontext závislý na aktuálním přihlášení uživatele. 5. Obsah stránky Obsahuje jednotlivá okna, tlačítka či ikony s údaji, položkami a funkcemi, které má uživatel na aktuální pracovní ploše k dispozici. Obsah vždy závisí na konkrétní činnosti uživatele a zobrazené jsou položky relevantní k dané činnosti. 6. Navigační lišta Slouží pro navigaci uživatele v aplikaci. Zobrazena je vždy celá aktuální cesta z hlavní pracovní plochy (nástěnky) uživatele až k právě zobrazované stránce. 7 Patička Na tomto místě budou umístěny odkazy na podporu, podmínky užívání a deklarace bezpečnosti Základní prvky Základní grafické prvky jsou: Seznamy Seznamy budou obsahovat maximálně 20 položek. Pokud bude položek více, pod seznamem se zobrazí panel pro ovládání stránkování. Každý seznam může obsahovat filtr, který bude umístěn nad ním. Ilustrace 25: Zobrazení seznamu 64

77 Evidenční karta žáka Evidenční karta slouží k přehlednému zobrazení evidovaných údajů. Skládá se ze záložek, které reprezentují jednotlivé kategorie dat. Každá karta žáka bude kromě zobrazených údajů obsahovat také možnosti rychlé navigace v evidenci osob výběr třídy, výběr jiného žáka a také možnost zobrazení k zvolenému datu. Ilustrace 26: Návrh zobrazení karty žáka Aktivní textové pole, našeptávač Některé vstupní pole formuláře jsou aktivní, co znamená, že při uživatelském vstupu aplikace provede nějakou operaci. Jedná se například o zadávání data nebo našeptávač při psaní textu. Pro první případ bude zobrazen kalendář pro pohodlný výběr roku, měsíce a dne, v případě našeptávače se zobrazí seznam maximálně 10 položek pod vstupním polem. Ilustrace 27: Aktivní pole formuláře 65

78 Plovoucí okna Některé formuláře se zobrazují v plovoucích oknech. Plovoucí okno bude možné bez uložení zavřít pomocí tlačítka Zpět nebo stiskem klávesy ESC. Ilustrace 28: Návrh plovoucího okna 66

79 4. Realizace Realizace byla provedena na základě návrhu architektury a implementace popsaném v kapitole 3.7. Tato část se věnuje popisu struktury programu a některým zajímavým aspektům z implementačního a integračního hlediska. Zdrojový kód včetně příručky programátora 68 je k dispozici na přiloženém CD médiu (viz také kapitola Obsah přiloženého CD). 4.1 Popis a struktura implementace Struktura implementace zohledňuje návrh implementace a také použité návrhové vzory. Všechny použité názvy v rámci implementace jsou psané anglicky. Projekt má následující strukturu (obrázek vlevo): src adresář obsahující veškerý zdrojový kód aplikace util adresář obsahující zdrojový kód nástrojů, které jsou obecné a použitelné i v jiných implementacích resources obsahuje non-java soubory, např. šablony ů, klíče, Hibernate XML mapování a jiné konfigurační soubory db obsahuje skripty pro vytvoření databázového schématu lib obsahuje knihovny použité při implementaci web obsahuje soubory a adresáře webové části aplikace včetně.tml souborů, lokalizačních klíčů, CSS a JavaScript. Adresář src obsahuje balíčky zdrojového kódu, které jsou organizované následovně: cz.lmicko.eskola základní balík, obsahující společné třídy pro celý projekt, hlavně konstanty a pomocné objekty. cz.lmicko.eskola.auth obsahuje třídy Ilustrace 29: Struktura projektu pro autentizaci uživatelů, ověřování oprávnění a řízení přístupu k zabezpečeným 68 V přeneseném slova smyslu javadoc 67

80 stránkám aplikace. - tento balík obsahuje POJO třídy reprezentující entity cz.lmicko.eskola.dao balík představuje vrstvu implementující databázový subsystém cz.lmicko.eskola.facade.* - obsahuje třídy zapouzdřující složitější logiku cz.lmicko.eskola.web.base obsahuje základní sadu objektů Tapestry stránek cz.lmicko.eskola.web.components obsahuje třídy Tapestry komponent cz.lmicko.eskola.web.pages.*- obsahuje implementaci Tapestry stránek cz.lmicko.eskola.web.services.* - obsahuje služby, jako např. Service cz.lmicko.eskola.biz.* 4.2 Nestandardní části řešení Na tomto místě by se hodilo zmínit celou řadu zajímavých implementačních částí, přesahovalo by to však rozumný rozsah práce. Proto se blíže podíváme na 4 zajímavé řešení: generování XML použitím Groovy skriptu použití AJAX formuláře uložení dat žáka evidenci historie změn v databázových tabulkách, které je transparentní vůči datové vrstvě aplikace Generování XML výstupu pomocí Groovy skriptu Aby export nebyl implementačně závislý, struktura je výstupu je konfigurovaná pomocí Groovy skriptu. Tento skript je možné spouštět v rámci JVM a jeho interpretace a kompilace je možná za běhu systému bez potřeby restartu. Skript je uložený v databázi a je kdykoliv možné nahrát nový, kterým bude export proveden. Nyní se podíváme, jak je implementace provedena. V první fázi jsou připraveny údaje, které se budou exportovat. Ty jsou obsažené v objektu RowTO: public class RowTO { private String id; private Map<String, String> data;... public String get(string key) { data.get(key); }... } Data jsou obsažené v mapě, co odpovídá podpoře dynamické definice evidovaných dat. Klíče v mapě odpovídají kódům položek, použitých při jejích definici. Export zabezpečuje třída UIVExportService, konkrétně její metoda perform(...): 68

81 public void perform(string groovyscript, School school, User user, List<RowTO> rows, OutputStream os) throws ExportException { try { log.info("performing UIV export for " + school.getizo()); UIVExportTemplate t = groovycl.parseclass(groovyscript).newinstance(); os.write(t.init()); os.write(t.createinfoblock(school, user)); for (RowTO r : rows) { os.write(t.createrow(r); } os.write(t.finish()); log.info("export finished"); } catch (CompilationFailedException e) { log.error("export failed script is not valid", e); throw new ExportException("Export failed", e); } catch (Throwable e) { log.error("export failed due to unknown exception", e); throw new ExportException("Export failed", e); } } je interface, který definuje chování šablony použité pro vygenerování exportu. Třída definovaná v Groovy skriptu tento interface implementuje. Zde je ukázka skriptu, pro vytvoření exportu : UIVExportTemplate public class UIVExportTemplateImpl implements cz.lmicko.eskola.facade.uivexporttemplate { public String init() { return """ <?xml version="1.0" encoding="windows-1250"?> <Vykaz verze="zs.004">""" } public String createinfoblock(school school, User user) { def vytvoreno = new org.joda.datetime().tostring('dd.mm.yyyy HH:mm:ss') return """ <Vygen>E-Skola</Vygen> <autor>'$user.name' '$user.surname'</autor> <telefon>'$user.phone'</telefon> < >'$user. '</ > <soubor>z'$school.izo'_'$school.part'</soubor> <vytvoreno>'vytvoreno'</vytvoreno>""" } public String createrow(rowto row) { return """ <veta> <RDAT>'$row.get("RDAT")'</RDAT> <IZO>'$school.izo'</IZO> <CAST>'$school.part'</CAST> <RODC>'$row.get("RODC")'</RODC>... </veta>""" } } Použití AJAX formuláře Interakce s uživatelem systému je vedena pomocí plovoucích oken, které se zobrazují nad otevřeným obsahem. To je dosaženo použitím technologie AJAX, pro kterou má framework 69

82 Tapestry nativní podporu. Až na několik málo úprav CSS a JavaScriptu, je možné implementaci provést tímto způsobem: Do šablony stránky nebo komponenty(.tml) umístíme tag, který vygeneruje potřebný odkaz a javascriptovou funkci pro jeho obsluhu: <t:ajaxlink t:action="useredit" t:context="user" t:zone="popupzone"> upravit uživatele </t:ajaxlink> definuje název obsluhující akce, t:context definuje parametry operace, v tomto případě objekt uživatele a t:zone definuje zónu jedná se o blok (<div> tag), ve kterém se cílový obsah zobrazí. Obsah bloku formulář je definován takto (kód je k dispozici v souboru PanelTools.tml): t:action <t:ajaxform t:id="edituserform" t:context="user" t:zone="popupzone"> <t:popuplayout title="uživatelský profil"> <t:errors/> <table class="layouter"> <tr> <th><t:label for="name"/>:</th> <td><t:textfield t:id="name" value="user.name" t:validate="required" t:label="jméno"/></td> </tr> <tr> <th><t:label for="surname"/>:</th> <td><t:textfield t:id="surname" value="user.surname" t:validate="required" t:label="příjmení"/></td> </tr>... </table> <fieldset class="sendpanel"> <input class="next" type="submit" value="uložit"/> <input type="reset" value="zrušit"/> </fieldset> </t:popuplayout> </t:ajaxform> Tento kód zabezpečí vygenerování HTML obsahu a obslužného JavaScript kódu. Obsluha událostí formuláře, čili jeho kontrola a odeslání, je provedeno ve třídě, která odpovídá šabloně, ve které je formulář definován. V tomto případě se jedná o třídu PanelTools.java: public Object onvalidateformfromedituserform() { if (edituserform.isvalid()) { User ex = userdao.loaduserby (user.get ()); if (ex!= null &&!ex.equals(user)) { edituserform.recorderror("uživatel s tímto em již existuje"); } } return edituserform.isvalid()? null : edituserform; = false) public void onsuccessfromedituserform() { userdao.update(user); } Můžeme si všimnout, že veškerá základní validace již byla provedena automaticky podle 70

83 definice v atributu t:validate Uložení dat žáka Jak již bylo zmíněno v návrhu implementace, uložení formulářových dat je realizováno pomocí XML. Pro prezentační vrstvu je to však transparentní a přistupuje k nim stejným způsobem jako k proměnným POJO tříd. Pro zpracování XML dokumentu, byl použit framework JDOM, který tuto práce usnadňuje. Hibernate mapování je realizováno v souboru FormData.hbm.xml: <class name="cz.lmicko.eskola.biz.formdata" table="form_data"> <id name="id" column="data_id"> <generator class="sequence"> <param name="sequence">seq_form_data_id</param> </generator> </id> <property name="entries" column="data_entries" type="cz.lmicko.eskola.dao.hibernate.formdatausertype"/>... </class> Třída cz.lmicko.eskola.dao.hibernate.formdatausertype vypadá takto: package cz.lmicko.eskola.dao.hibernate; /** Lubomir Micko */ public class FormDataUserType implements UserType, Serializable { public Object nullsafeget(resultset rs, String[] names, Object arg2) throws HibernateException, SQLException { String text = (String) rs.getobject(names[0]); List<FormEntryTO> result = new ArrayList<FormEntryTO>(); if (text!= null) { Reader reader = new StringReader(text); try { Document document = new SAXBuilder().build(reader); for (Object obj : document.getrootelement().getchildren()) { Element row = (Element) obj; Integer index = Integer.valueOf(row.getAttributeValue(ROW_INDEX_ATTR)); String author = row.getattributevalue(row_author_attr);... FormEntryTO entry = new FormEntryTO(index, author, date); for (Object robj : row.getchildren()) { Element rowvalue = (Element) robj; String key = rowvalue.getname(); entry.addvalue(key, rowvalue.gettexttrim()); } result.add(entry); } } catch (JDOMException e) { 71

84 throw new HibernateException("JDOM exception occured", e); } catch (IOException e) { throw new HibernateException("IO exception occured", e); } finally { try { reader.close(); } catch (Exception e) { //do nothing } } } return result; } public void nullsafeset(preparedstatement st, Object value, int index) throws HibernateException, SQLException { List<FormEntryTO> entries = (List<FormEntryTO>) value; if ((entries == null) (entries.isempty())) { st.setnull(index, SQL_TYPES[0]); } else { Element root = new Element(ROOT_ELEMENT_NODE); Document document = new Document(root); for (FormEntryTO entry : entries) { Element row = new Element(ROW_ELEMENT); row.setattribute(row_index_attr, entry.getindex().tostring()); row.setattribute(row_author_attr, entry.getauthor()); for (FormEntryValueTO val : entry.getvalues()) { Element rowvalue = new Element(val.getKey()); rowvalue.settext(val.getvalue()); row.addcontent(rowvalue); } root.addcontent(row); } try { st.setobject(index, new XMLOutputter().outputString(document)); } catch (Exception e) { SQLException ex = new SQLException("Could not covert Document to String"); ex.initcause(e); throw ex; } } } } Pro přístup k položkám ve stylu POJO, to znamená pomocí get a set metod byl použit aspekt (AspectJ), který bytecode za běhu doplní o ty metody, které umožňují přístup k položkám v XML souboru Verzování Verzování, jako způsob evidence změn v evidovaných datech je použito pro všechny podstatné entity: User, Facility, School, Student, StudentData, ImportTemplate, ImportTemplateField, FormDefinition a FormDefinitionField. Pro ukázku implementace se podíváme na entitu User. Entita je reprezentovaná jako POJO package cz.lmicko.eskola.biz; 72

85 ... /** Lubomir Micko */ public class User Comparable<User> { protected Integer id; protected Long version; protected String username; protected String encodedpassword; protected String name; protected String surname; protected String ; protected String phone; } a je mapován pomocí XML definice User.hbm.xml <hibernate-mapping> <class name="cz.lmicko.eskola.biz.user" table="user_v"> <id name="id" column="id"> <generator class="sequence"> <param name="sequence">seq_user_id</param> </generator> </id> <version name="version" type="long" column="version"/> <property name="username" column="username" not-null="true" unique="true"/> <property name="encodedpassword" column="pwd"/> <property name="name" column="name"/> <property name="surname" column="surname"/> <property name=" " column="title"/>... </class> </hibernate-mapping> V databázi byly vytvořeny dvě tabulky: create table USER (ID int4 NOT NULL,, PRIMARY KEY(ID)) create table USER_HISTORY (ID int4 NOT NULL, VERSION int8 NOT NULL,, PRIMARY KEY(ID, VERSION)) Tabulka USER představuje skutečnou relační tabulku a obsahuje aktuálně platný údaj a tabulka USER_HISTORY obsahuje historii změn včetně verzí. V ukázce XML mapování byla entita User namapována na tabulku USER_V. Nejedná se ale o tabulku, ale o pohled (view proto přípona _V): create or replace view USER_V (ID, VERSION, NAME,...) as select U.ID as ID, (select max(h.version) from USER_HISTORY H where H.ID = I.ID) as VERSION, I.NAME as NAME,... from USER U Tímto způsobem z tabulky USER_HISTORY získáme vždy řádek z nejvyšší verzí. Jelikož se jedná o read-only pohled, pokus o zápis nebo změnu dat v něm by skončil chybou. Řešení tohoto problému vyřešíme tak, že zachytíme insert, update a delete událostí a provedeme zápis do správných tabulek: create or replace trigger USER_INSERT instead of insert on USER_V begin 73

86 insert into USER(ID, NAME, ) values (:n.id, :n.name,...); insert into USER_HISTORY(ID, VERSION, NAME, ) values (:n.id, :n.version,...); end; create or replace trigger USER_UPDATE instead of update on USER_V begin update USER set NAME = :n.name, SURNAME = :n.surname, where ID = :n.id; insert into USER_HISTORY(ID, VERSION, NAME, ) values (:n.id, :n.version,...); end; 4.3 Integrace Aplikace je distribuována jako WAR (web archive) a její instalace spočívá v deploymentu tohoto souboru do aplikačního serveru GlassFish. Před prvním deploymentem je potřeba provést několik nastavení, které jsou popsány v následující kapitole Nastavení prostředí Aplikační server Aplikační server GlassFish před spuštěním aplikace E-Škola vyžaduje některé nutné konfigurační zásahy: dodání ovladače pro připojení do databáze: soubor postgresql-jdbc4.jar nahrát do /data/glassfish/domain1/lib knihovny vyžadované Tapestry: soubory stax2-api.jar a woodstox-core-asl.jar je potřeba nahrát do /data/glassfish/domain1/lib/ext nastavit classpath-prefix přidat položky: /data/glassfish/domain1/lib/ext/stax2-api.jar /data/glassfish/domain1/lib/ext/woodstox-core-asl.jar Je to tak z toho důvodu, že Tapestry nepodporuje implementaci stax2 a asl dodávanou společně s aplikačním serverem GlassFish JVM je potřebné spouštět s těmito parametry: -XX:MaxPermSize=512m a -Xmx1024m je potřebné vytvořit JDBC connection pool69 a nastavit připojení do databáze, doporučuji použít typ javax.sql.connectionpooldatasource. Další oproti výchozímu stavu odlišná nastavení jsou maximumpoolsize = 64 a povolena Connection Validaction (kvůli podpoře znovupřipojení v případě odstávky db). je potřebné vytvořit JDBC resource s názvem jdbc/eskola_db, na který se aplikace bude připojovat. Na ten se aplikace připojí pomocí JNDI, do kterého ho GlassFish 69 Vytvoření connection pool je popsáno v administrátorské příručce, která je on-line k dispozici na 74

87 pod zadaným jménem zaregistruje Databázový server Databázový server PostgreSQL 8.4 nevyžaduje specifickou konfiguraci. Byla provedena pouze optimalizace některých jeho nastavení70, které mají význam pro provoz v multitenant módu. Nastavení závisí na velikosti RAM. Tato konfigurace je dimenzována pro 2GB. Kromě výchozího nastavení v souboru /data/postgres/postgresql.conf byly změněny tyto položky: Název parametru max_connections shared_buffers temp_buffers Hodnota Poznámka 100 JDBC resource pool je nastaven na max. 64, 36 je rezerva pro zálohování atd GlassFish. 512MB Doporučeno 1/4 objemu RAM 2MB Pro každou session work_mem 10MB Alokuje se pro každé připojení maintenance_work_mem 64MB effective_cache_size 512MB Tabulka 15: Specifická konfigurace databázového serveru PostgreSQL Zabezpečení Komunikace je zabezpečena SSL připojením. Na straně serveru byl vytvořen self-signed certifikát. Ověření certifikační autoritou nebylo provedeno. Operační systém, na kterém aplikace běží má aktivní IP filter (firewall) s povolenými porty 80 a 443, které slouží pro komunikaci přes HTTP a HTTPS protokol. Databázový server je konfigurován pouze pro lokální připojení přes unix-socket a tudíž SSL není pro komunikaci mezi aplikačním a databázovým serverem potřeba Zálohování a obnova dat Zálohování dat je realizováno shell skriptem, který je v pravidelných intervalech (jednou denně) spouštěn aplikací cron. Pro zálohování databáze je použit tento příkaz: pg_dump -U eskola -F c -v -f "/data/backup/eskola.backup-$year$month$day" eskola_db Obnova dat ze zálohy je možná spuštěním příkazu: pg_restore -v -c -O -d eskola_db -U eskola /data/backup/eskola.backup Dle doporučení popsaném on-line na 75

88 4.4 Ukázka systému Demoverze aplikace je k vyzkoušení na Přihlášení je možné pod účtem ucitel/test pro roli uživatel školy. Rovněž je možné se do aplikace zaregistrovat a získat přístup tímto způsobem. Následující obrázky prezentují finální vzhled aplikace. Na prvním obrázku můžeme vidět úvodní a zároveň přihlašovací stránky do aplikace. Pro neregistrované uživatele je zde odkaz na formulář pro zřízení účtu. Ilustrace 30: Ukázka aplikace přihlašovací stránka Další obrázky zobrazují prostředí přihlášeného uživatele. V prvním případě se jedná o ukázku realizace plovoucího AJAX formuláře pro vytvoření součásti právnické osoby (školy). Na pozadí je možné vidět layout aplikace a kartu právnické osoby (ředitelství). Další ilustrace obsahuje ukázku z evidence osob, která také nabízí pohled na realizaci aktivního pole pro zadání data. 76

89 Ilustrace 31: Ukázka aplikace karta ředitelství a formulář pro vytvoření součásti Ilustrace 32: Ukázka aplikace seznam evidovaných osob v matrice 77

90 Poslední ukázka nabízí pohled na definici položek, které jsou zobrazené na kartě žáka. Takovýmto způsobem je možné dynamicky definovat to, co se ve školní matrice eviduje. Ilustrace 33: Ukázka aplikace definice položek karty žáka 78

91 5. Testování Tato kapitola se věnuje popisu způsobu a průběhu testování aplikace E-Škola. Provedeny byly celkem tři různé testování unit testing, zátěžové a aplikační testování. První dva byly provedeny pomocí frameworků, aplikační testy proběhly dle testovacího scénáře člověkem. 5.1 Unit testing Unit testing - toto slovní spojení se při programování používá jako pojem a v českém jazyce zatím nemá ustálený překlad. Jde o činnost související s vývojem aplikací. Zahrnuje metodiku a nástroje, jejichž cílem je ověření správné funkčnosti části zdrojového kódu. Hlavní motivací proč vlastně zdrojový kód takovýmto způsobem testovat, je myšlenka dynamického programování optimalizací menších částí dostáváme optimální také celek. V našem případě jsou menší části reprezentovány jednotlivými oddělenými vrstvami a moduly. Tomuto způsobu testování byla podrobena část implementace, která zabezpečuje dynamickou konfiguraci formulářů a provádí ukládání dat ve formě XML (viz kapitola 4.2.3). Návrh testů se zakládá na prověření nejpravděpodobnějších situací, které můžou vzniknout a to jak korektním chováním tak chybou. Základní struktura každého testu vypadá takto: konfigurace objektů (vytvoření instancí, potřebných nastavení hodnot) definice očekávaných výsledků provedení testované operace ověření, zda výsledky splnily očekávaní Zde je ukázka kódu jednoduchého testu vložení a načtení formulářových dat (pro implementaci testů byl použit framework public void testloadformdata() throws Exception { FormData data = preparetestingdata(); formdatadao.insertdata(data); tx.commit(); FormData result = formdatadao.loadbyid(data.getid()); assertequals(data, result); } Tímto způsobem bylo dohromady provedeno 23 testů, které kompletně pokrývají komponenty zapouzdřující ukládání formulářových dat. Přehled s výsledky je k dispozici v příloze. 5.2 Zátěžové testování Tento test byl zaměřen na délku odezvy aplikace při simulovaném volání středně 79

92 náročných operací (mezi voláními je nastavena přiměřeně náhodná časová prodleva - tzv. think time). Testování bylo realizováno nástrojem Apache JMeter po dobu 24 hodin, který simuluje současné přihlášení více uživatelů. Doba testu je dostatečně dlouhá, aby se zde projevily případné problémy se stabilitou či výkonovou stálostí. Jako testovací operace byla zvolena sekvence: přihlášení uživatele, zobrazení karty školy, zobrazení seznamu žáků a zobrazení karty žáka Konfigurace systému Název Hodnota/Popis Operační systém Open SUSE 11.3, 64-bit CPU 1 x Intel Pentium4 3Ghz, bez HT Paměť 2GB DDR 333, CL2.5 Chipset Intel 865PE Síťové připojení 100Mbps Aplikační server GlassFish 2.1:1 (bez clusteringu) Databázový server PostgreSQL 8.4 Běhové prostředí Oracle JDK 1.6.0_22, 64-bit Tabulka 16: Konfigurace systému pro zátěžové testování Přehled výsledků testů Bylo provedeno celkem 4 různé testovací konfigurace, které se odlišovali v počtu paralelních volání aplikace (threads) a v počtu opakování (loops). Test 1 Test 2 Test 3 Test 4 Počet vláken Počet opakování Počet vzorků Délka odezvy Max. [ms] Min. [ms] ,6 160,6 718,6 1816,6 Průměrná [ms] Tabulka 17: Přehled výsledků zátěžových testů Z výsledků vyplývá, že pro zvolený počet uživatelů je aplikace velice stabilní a přístupná. Vzhledem k relativně průměrného vytížení procesoru, které se pohybovalo okolo 80

93 50%, je doporučeno (při současné konfiguraci) využívat aplikaci méně než 600 uživateli během 1 hodiny. Tento limit by měl zajistit dostupnost aplikace i v přístupových špičkách a mimořádných situacích. Přehled jednotlivých testů je v příloze (Příloha E). 5.3 Testy použitelnosti Poslední testování aplikace proběhlo formou testů použitelnosti (usability tests). Testování provedla jedna osoba s průměrnou počítačovou gramotností, která má z problematiky školství zkušenosti. Testovací scénáře byly zaměřeny na nejdůležitější funkce registrace do aplikace, vytvoření součásti právnické osoby a vytvoření a editace žáka v rámci školní matriky Testovací scénáře Úkol 1 registrace do aplikace Uživatelská role: neregistrovaný uživatel Postup: 1. Uživatel otevře stránku 2. Otevře odkaz registrovat se do aplikace 3. Vyplní a odešle registrační formulář 4. Potvrdí registraci otevřením odkazu, který mu přišel na zadaný 5. Přihlásí se do aplikace Očekávaný výsledek: získání přihlašovacích údajů a přihlášení do aplikace Úkol 2 vytvoření součásti právnické osoby Uživatelská role: správce školy Předpokladem je úspěšné zvládnutí úkolu 1. Postup: 1. Uživatel otevře stránku 2. Vyplní přihlašovací údaje získané v úkolu 1 3. Na pracovní ploše vidí kartu právnické osoby 4. Otevře odkaz vytvořit součást 5. V plovoucím okně vyplní povinné údaje a formulář odešle 6. Po odeslání formuláře se zobrazí karta součásti Očekávaný výsledek: vytvoření součásti Úkol 3 vytvoření a úprava žáka 81

94 Uživatelská role: správce školy Předpokladem je úspěšné zvládnutí úkolu 2. Postup: Uživatel otevře stránku Vyplní přihlašovací údaje získané v úkolu 1 Otevře odkaz číselník -> třídy v hlavním menu a následně vytvořit třídu Vyplní požadované položky a formulář odešle Otevře odkaz Matrika v hlavním menu, čím se mu zobrazí seznam evidovaných žáků 6. Otevře odkaz založit nového žáka 7. V plovoucím okně vyplní povinné údaje a formulář odešle. Jako cílovou součást zvolí tu, která byla vytvořena v úkolu Po odeslaní se zobrazí karta žáka 9. Kliknutím vybere kartu vzdělání 10. U položky třída otevře odkaz zapsat do třídy 11. V plovoucím okně vybere vytvořenou třídu, zvolí datum nástupu a formulář odešle 12. Po odeslaní se zobrazí karta žáka s informací o zařazení žáka ve třídě 13. Otevře odkaz historie změn 14. V seznamu vidí záznam o vytvoření žáka a jeho zařazení do třídy. Platnost údajů by měla odpovídat zadanému datu ve formulářích.očekávaný výsledek: vytvoření evidence žáka a zobrazení historie záznamů Výsledky testů Úkol 1 registrace do aplikace Testovací scénář byl proveden bez problémů s očekávanými výsledky. Úkol 2 vytvoření součásti právnické osoby Testovací scénář byl proveden bez problémů s očekávanými výsledky. Úkol 3 vytvoření a úprava žáka Testovací scénář byl proveden bez problémů s očekávanými výsledky. Je možné konstatovat, že testování základní funkcionality aplikace proběhlo bez problémů. Jelikož se ale jednalo o jednoduché operace, prováděné zkušenou osobou, jiný výsledek se neočekával. Nicméně je nutné provést další testování zejména procesů ve vztahu k exportu dat, k jejích předání na ÚIV a k různým procesům ve školní matrice. Pro testování předávání dat na ÚIV je zapotřebí získat přístup k testovacímu prostředí aplikace Matrika. 82

95 6. Závěr Závěr této práce je věnován krátkému slovnímu zhodnocení všech částí projektu s přihlédnutím na deklarované cíle. Úkolem bylo seznámení se s procesem centralizovaného sběru dat na ÚIV ve vztahu k provozování evidence matriky na základních školách, zmapování současného stavu a analýza existujících řešení. Na základě těchto informací měl být proveden návrh realizace produktu E-Škola, který by byl provozován jako služba na internetu (SaaS) s možností samostatné registrace škol. Důležitou součástí implementace byl také požadavek na zohlednění častých legislativních změn. Díky výběru vodopádové metodiky vývoje projektu, jsou všechny části diplomové práce ucelené, srozumitelné a navazují na sebe. Analýza splnila účel a jejím výsledkem byly poznatky z procesu elektronického sběru dat na straně základní školy a částečně i správního úřadu. Rešerší existujících řešení evidence matriky na školách byly identifikované jak nedostatky tak i inspirativní prvky. Obě dvě kategorie se odzrcadlily v návrhu realizace. Samotný návrh představil několik řešení, pomocí kterých byla dosažená požadovaná funkčnost, zejména v oblasti reflektování změn v zákonech a v pokročilé evidenci změn údajů vedených ve školní matrice. Jedná se o funkce dynamických formulářů, konfigurovatelného exportu a aplikací detekce a ukládání změn v záznamech. Kromě implementačních prvků byla navržena také architektura a infrastruktura, která nabízí stabilní a bezpečný provoz aplikace. Důraz byl kladen také na možnosti škálovatelnosti, jak horizontální tak i vertikální. V tomto ohledu je výsledná aplikace a běhové prostředí výborně připraveno. Realizační fáze proběhla bez závažných problémů podle návrhu. Během implementace nebyly odhalené žádné nesrovnalosti, které by vyžadovali jeho přehodnocení. Integrace do cílového prostředí proběhla podle plánu, demoverze aplikace běží v hostingu na dedikovaném serveru a je dostupná na adrese Ověření funkčnosti a stability řešení bylo provedeno třemi odlišnými způsoby unit tests, výkonovým testováním a testováním použitelnosti. Rozsah byl sice menší, pokryl však důležité části aplikace. Ačkoliv se cíle práce podařilo splnit, existuje celá řada dalších úkolů, kterým se je nezbytné věnovat, aby systém E-Škola byl plně funkční, využívaný a úspěšný. Mezi ně určitě patří doladění implementace (import, export, ověřování oprávnění), komplexnější testování pokrývající větší část funkcí aplikace, on-line uživatelská příručka a v neposlední řadě také propagace aplikace mezi školy samotné. Nezbytné je také provést kroky z právního hlediska sestavit podmínky užití systému a provést registraci na Úřadě pro ochranu osobních údajů. 83

96 7. Příloha Seznam tabulek Přehled výkazů ve školství...7 Přehled termínů pro předání výkazů ve školním...12 Přehled individuálních údajů žáka společný základ...16 Položka základního souboru...16 Položky anonymizovaného souboru...16 Seznam číselníků platný k Přehled cen licencí aplikace Bakaláři...25 Přehled cen tarifů aplikace Škola OnLine...30 Porovnání funkcí matriky v existujících řešeních...31 Porovnání reflektování změn v legislativě v existujících aplikacích...31 Porovnání ovladatelnosti existujících aplikací...32 Porovnání technické realizace existujících aplikací...32 Porovnání nákladů na provoz existujících aplikací...34 Přehled použitých technologií...59 Specifická konfigurace databázového serveru PostgreSQL...75 Konfigurace systému pro zátěžové testování...80 Přehled výsledků zátěžových testů

97 Seznam ilustrací Schéma školského zařízení...6 Diagram procesu sběru agregovaných dat...8 Ukázka ze systému Matrika výběr součásti...9 Diagram procesu předávání individuálních dat...10 Ukázka ze systému Matrika - práce s daty...10 Karta žáka v aplikaci Bakaláři...22 Karta žáka v aplikace Škola OnLine...27 Hromadné nastavení položek v aplikaci Škola OnLine...28 Diagram případů užití - právnická osoba...41 Diagram případů užití - součást právnické osoby...42 Diagram případů užití - evidence žáků...42 Diagram případů užití - správa položek formulářů a exportu...43 Diagram případů užití - správa číselníků...43 Diagram případů užití - správa uživatelů...44 Diagram případů užití neregistrovaní uživatelé...44 Diagram nasazení...48 Schéma navrhované struktury implementace...50 Sekvenční diagram popisující chování OpenSessionInView filtru...52 Diagram procesu importu...56 Diagram procesu registrace...57 Schéma návrhového vzoru MVC...58 Schéma návrhového vzoru Data Mapper...58 Datový konceptuální model...60 Návrh layoutu aplikace...63 Zobrazení seznamu...64 Návrh zobrazení karty žáka...65 Aktivní pole formuláře...65 Návrh plovoucího okna...66 Struktura projektu...67 Ukázka aplikace přihlašovací stránka...76 Ukázka aplikace karta ředitelství a formulář pro vytvoření součásti...77 Ukázka aplikace seznam evidovaných osob v matrice...77 Ukázka aplikace definice položek karty žáka

98 Literatura [1] LARMAN, CRAIG. Agile & Iterative development, Addison - Wesley, 2004 [2] GAMA E., HELM R., JOHNSON R., VLISEDES J. Design Patterns, Addison Wesley, 1995 [3] McGREGOR J., SYKES D. A practical guide to testing object oriented software, Addison -Wesley, 2004 [4] FOWLER M. Patterns of enterprise application architecture, Addison Wesley, 2006 [5] web:infodp. K336 Info pokyny pro psaní diplomových prací. stav k [6] Vícero přispívatelů. CS a EN wikipedia. a stav k [7] web:bakaláři. Dokumentace a informace k produktu Bakaláři. stav k [8] web:škola online. Dokumentace a informace k produktu KATEDRA. stav k [9] web:úiv. Metodické pokyny a informace pro sběr dat na ÚIV. stav k [10] web:matrika. Metodické pokyny a dokumentace aplikace Matrika. stav k [11] web:hibernate. Dokumentace frameworku Hibernate. stav k [12] web:tapestry. Dokumentace frameworku Tapestry. stav k [13] web:sbírka zákonů. Elektronická sbírka zákonů ČR. stav k [14] web:glassfish: Administrační příručka aplikačního serveru GlassFish v stav k [15] web:postgresql: Uživatelská příručka databázového serveru PostgreSQL stav k

99 Příloha A Schéma českého systému školství 87

100 Příloha B Ukázka výkazu S