1 Zde bude zadání práce2 23 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Diplomová práce E škola Bc. Ľubomír Mičko V...
Č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 2011 3
4
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
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).
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
Obsah 1.Úvod........................................................................................................................................1 1.1 Kontext zadání................................................................................................................1 1.2 Vymezení cílů a rozsahu řešení.......................................................................................2 1.3 Metodika.........................................................................................................................3 1.4 Struktura práce................................................................................................................4 1.5 Přehled cílů.....................................................................................................................5 2.Analýza současného stavu.......................................................................................................6 2.1 Struktura škol a školských zařízení................................................................................6 2.2 Proces sběru dat ÚIV......................................................................................................7 2.2.1 Import dat do aplikace Matrika...............................................................................8 2.2.2 Formát a struktura souborů...................................................................................10 2.2.3 Termíny předání dat...............................................................................................11 2.3 Okruhy údajů vedených v dokumentaci školy..............................................................12 2.3.1 Struktura agregovaných údajů pro předání ÚIV...................................................12 2.3.2 Struktura individuálních údajů pro předání ÚIV..................................................13 2.3.3 Číselníky...............................................................................................................17 2.3.4 Platnost a historie změn údajů..............................................................................18 2.3.5 Procesy ve školní matrice.....................................................................................18 2.4 Analýza existujících řešení...........................................................................................18 2.4.1 Kriteria analýzy.....................................................................................................19 2.4.2 Bakaláři.................................................................................................................21 2.4.3 Škola OnLine........................................................................................................25 2.4.4 Shrnutí...................................................................................................................30 3.Analýza a návrh realizace......................................................................................................35 3.1 Software jako služba.....................................................................................................35 3.2 Požadavky na systém....................................................................................................35 3.2.1 Funkční požadavky...............................................................................................36 3.2.1.1 Nástroje pro evidenci školy a žáků................................................................36 3.2.1.2 Nástroje pro administraci formulářů, číselníků a uživatelů..........................39 3.2.1.3 Požadavky na registrační proces...................................................................40 3.2.2 Nefunkční požadavky...........................................................................................40 3.3 Případy užití..................................................................................................................41 3.3.1 Cílová skupina uživatelů a role.............................................................................41 3.3.2 Diagram případů užití...........................................................................................41 3.3.2.1 Evidence právnické osoby, součástí a žáků...................................................41 3.3.2.2 Administrace formulářů, číselníků a uživatelů..............................................43 3.3.2.3 Neregistrovaní uživatelé................................................................................44 3.4 Programovací jazyk......................................................................................................45 3.5 Vývojové prostředí, nástroje softwarového inženýrství...............................................46 3.6 Návrh architektury........................................................................................................47 3.6.1 Běhové prostředí a aplikační server......................................................................47 3.6.2 Databázový server.................................................................................................47 3.6.3 Operační systém....................................................................................................48 3.6.4 Diagram nasazení..................................................................................................48 11
3.7 Návrh implementace.....................................................................................................49 3.7.1 Vnitřní architektura implementace........................................................................49 3.7.2 Prezentační vrstva.................................................................................................50 3.7.3 Databázový subsystém..........................................................................................51 3.7.4 Platnost a verzování..............................................................................................52 3.7.5 Pravidla implementace entit..................................................................................53 3.7.6 Dynamické formuláře, uložení dat........................................................................53 3.7.7 Našeptávač při psaní textu....................................................................................54 3.7.8 Statistická validace................................................................................................54 3.7.9 Oprávnění a bezpečnost........................................................................................55 3.7.10 Import..................................................................................................................55 3.7.11 Export..................................................................................................................56 3.7.12 Proces registrace.................................................................................................56 3.7.13 Návrhové vzory...................................................................................................57 3.7.14 Přehled technologií.............................................................................................59 3.8 Datový konceptuální model..........................................................................................59 3.9 Návrh uživatelského rozhraní.......................................................................................63 3.9.1 Layout...................................................................................................................63 3.9.2 Základní prvky......................................................................................................64 4.Realizace................................................................................................................................67 4.1 Popis a struktura implementace....................................................................................67 4.2 Nestandardní části řešení..............................................................................................68 4.2.1 Generování XML výstupu pomocí Groovy skriptu..............................................68 4.2.2 Použití AJAX formuláře........................................................................................69 4.2.3 Uložení dat žáka....................................................................................................71 4.2.4 Verzování...............................................................................................................72 4.3 Integrace........................................................................................................................74 4.3.1 Nastavení prostředí...............................................................................................74 4.3.1.1 Aplikační server.............................................................................................74 4.3.1.2 Databázový server.........................................................................................75 4.3.2 Zabezpečení..........................................................................................................75 4.3.3 Zálohování a obnova dat.......................................................................................75 4.4 Ukázka systému............................................................................................................76 5.Testování................................................................................................................................79 5.1 Unit testing....................................................................................................................79 5.2 Zátěžové testování........................................................................................................79 5.2.1 Konfigurace systému.............................................................................................80 5.2.2 Přehled výsledků testů..........................................................................................80 5.3 Testy použitelnosti........................................................................................................81 5.3.1 Testovací scénáře..................................................................................................81 5.3.2 Výsledky testů.......................................................................................................82 6.Závěr......................................................................................................................................83 7.Příloha....................................................................................................................................84
12
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
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 2.3.3 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
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 emailové 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
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: 1. 2. 3. 4. 5.
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
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
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
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 10 4-01, 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 41-01
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 21-01 V 37-01 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 2.2.3. 5 Web MŠMT [on-line] - http://www.msmt.cz/uploads/soubory/sb125_05.pdf – Příloha 2 k vyhlášce č. 364/2005 Sb odstavec „Předávání agregovaných údajů“ 6 Web ÚIV [on-line] – http://www.uiv.cz, informace k 1.1.2011 7 PAM - Práce a Mzdy
7
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 30.9.“9. Analýze procesu importu dat do aplikace Matrika se věnuje následující kapitola.
2.2.1 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: 1. 2. 3. 4. 5. 6.
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 https://matrika.uiv.cz 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 https://matrika.uiv.cz/matrikas/napoveda_Z.pdf, platný k 1.1.2011 11 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
„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 https://matrika.uiv.cz/matrikas/napoveda_U.pdf 14 Odpovídá koncovému datu sběrného období. Toto datum stanovuje zákon.
9
Ilustrace 4: Diagram procesu předávání individuálních dat
Ilustrace 5: Ukázka ze systému Matrika - práce s daty
2.2.2 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-1250. 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) http://www.w3.org/TR/REC-xml/
10
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 2.3.2. 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í: Vlastní_evidenceJan Novak123 456 789 <e-mail>[email protected] <soubor>K062157213_01 18.04.2007 12:23:57 …
Příklad XML souboru je v příloze (Příloha C).
2.2.3 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
žá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 30.9. - období od 1.10. předchozího roku do 30.9. aktuálního školského roku
•
rozhodné datum 31.3., tj. podle stavu k 31.3 – období od 1.9. do 31.3. 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 3-01
30.9.2010
30.10.2010
31.3.2011
15.5.2011
M3
30.9.2010
15.10.2010
-
-
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ů.
2.3.1 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] - http://www.msmt.cz/uploads/soubory/sb125_05.pdf – 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
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 3-01. 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).
2.3.2 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
ú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 2.2.2. 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-1250. 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
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
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)
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 1.1.2011
17
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í.
2.3.5 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 3.2.1 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
Bakaláři.
2.4.1 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
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
•
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)?
2.4.2 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 2.3.5 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 http://www.bakalari.cz
21
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 24 25 26 27
Více na http://www.bakalari.cz/minimatrika.aspx 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 http://www.bakalari.cz k 1.1.2011
22
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
ú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 www.bakalari.cz k 1.1.2011
24
Cena licence v Kč31
Počet žáků Společné prostředí
Evidence + Bakalář
Celkem
do 100
2000
1900
3900
do 200
2300
3400
5700
do 300
2600
5100
7700
do 400
2900
6800
9700
do 600
3500
9500
13000
do 800
3800
11400
15200
do 1000
4100
13300
17400
do 1200
4400
15200
19600
do 1400
4700
17100
21800
do 1600
5000
19000
24000
do 1800
5300
20900
26200
do 2000
5600
22800
28400
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.
2.4.3 Š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 2002. 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 http://www.bakalari.cz k 1.1.2011
25
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 www.skolaonline.cz/akademie
26
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 2.3.5 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
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 3-01. 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ím35. 35 Např. Microsoft Dynamics CRM
28
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 100
1300
800
600
2700
do 200
2139
1316
992
4442
do 300
3397
2090
1668
7055
do 400
3397
2090
1668
7055
do 600
5431
3342
2506
11279
do 800
6731
4142
3106
13979
36 On-line nápověda je k dispozici na https://aplikace.skolaonline.cz/dokumentace/KS/katedra/ 37 Jedná se o sadu služeb a aplikací pro podporu komunikace žáků, rodičů a učitelů, více na http://www.microsoft.com/cze/liveatedu/skola.mspx 38 ceník platí od 1. září 2010, uvedené ceny jsou včetně 20% DPH
29
do 1000
6731
4142
3106
13979
do 1200
8681
5342
4006
18029
do 1400
8681
5342
4006
18029
do 2000
10316
6348
4762
21426
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.
2.4.4 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 2.3.5 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 3-01 30
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
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, 2008 2000, XP, 2003, 2008,Vista 32-bit, Windows 7 32-bit
SW požadavky – databázový server MS SQL 2000, MS SQL MS SQL 2005 2005, 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
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í: 1x13.000 = 13.000 Kč Upgrade: 6x 0,20x13.000 = 15.600 Kč Náklady na žáka: ca 17 Kč na žáka a rok
Provoz: 3x11.279 = 33.837 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í: 1x13.000 = 13.000 Kč Upgrade: 10x 0,20x13.000 = 26.000 Kč Náklady na žáka: ca 17,5 Kč na žáka a rok
Provoz: 5x11.279 = 56.395 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
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
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 1999. 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 http://salesforce.com
35
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 830-1998. 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.
3.2.1 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í.
3.2.1.1 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
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 2.3.2. 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
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 1.9.2008 do 31.8.2009 a podruhé s platností od 1.9.2009 do 31.8.2010. 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
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 2.2.2.
•
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.
3.2.1.2 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
•
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í, email, 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ů.
3.2.1.3 Požadavky na registrační proces Neregistrovaná osoba ve formuláři vyplní název školy, REDIZO, adresu, své jméno, email a heslo. Aplikace na zadaný email odešle aktivační odkaz, který musí žadatel otevřít. Platnost potvrzovacího emailu 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 email, zadaný při registraci. Po dokončení tohoto procesu mu aplikace odešle email s potvrzením o zřízení služby.
3.2.2 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
3.3 Případy užití 3.3.1 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é.
3.3.2 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č.
3.3.2.1 Evidence právnické osoby, součástí a žáků
Ilustrace 9: Diagram případů užití - právnická osoba 41
•
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
3.3.2.2 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
Ilustrace 14: Diagram případů užití - správa uživatelů
3.3.2.3 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
•
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
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.
45 46 47 48 49
Jak z hlediska dostupnosti zdrojového kódu tak z hlediska legální dostupnosti licencí Více na http://www.mono-project.com/ Editor zdrojového kódu, kompilátor, debugger, coding assistant Prostředí pro práci s aspekty. Více informací je on-line na http://www.eclipse.org/aspectj/ Podpora pro připojení na Subversion (SVN) systém. Více onformací je on-line na http://subversion.tigris.org/ 50 Podpora pro integraci servlet kontejneru Jetty do prostředí Eclipse. Více informací je k dispozici na http://code.google.com/p/run-jetty-run/
46
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.
3.6.1 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 2.1.1.
3.6.2 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 http://jcp.org/aboutJava/communityprocess/final/jsr315/index.html 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 http://glassfish.java.net/
47
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 8.4.
3.6.3 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 11.3.
3.6.4 Diagram nasazení
Ilustrace 16: Diagram nasazení
48
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, ...).
3.7.1 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 3.7.13. 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ř. EmailService). Zpravidla jsou bezstavové a vykonávají komplexnější operace nad modelem entit (viz také 3.7.13).
49
Ilustrace 17: Schéma navrhované struktury implementace
3.7.2 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 http://cs.wikipedia.org/wiki/Tapestry 55 Dle specifikace JSR-000315 JavaTM Servlet 3.0 http://jcp.org/aboutJava/communityprocess/final/jsr315/index.html 56 Více v uživatelské příručce on-line na http://tapestry.apache.org/tapestry5.2-dev/guide/componentclasses.html a http://tapestry.apache.org/tapestry5.2-dev/guide/lifecycle.html
50
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 3.9.
3.7.3 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 3.7.13), 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 http://tapestry.apache.org/tapestry5.2-dev/guide/ajax.html 58 Texty budou zobrazované v závislosti na jazyku uživatele (nastavení v prohlížeči).Více informací je na http://tapestry.apache.org/tapestry5.2-dev/guide/localization.html 59 Více informací on-line na http://www.hibernate.org/about/orm.Kromě 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 http://docs.jboss.org/hibernate/core/3.3/reference/en/html/mapping.html. 61 Hibernate podporuje i další dialekty. Jejích seznam je k dispozici na http://docs.jboss.org/hibernate/core/3.3/reference/en/html/session-configuration.html 62 Více na http://springtips.blogspot.com/2007/07/open-session-in-view.html
51
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).
3.7.4 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
•
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 4.2.4.
3.7.5 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.
3.7.6 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
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ě: • • • • • • • • •
3.7.7 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.
3.7.8 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
na 27.2. 1894, 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á.
3.7.9 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.
3.7.10
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
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
3.7.11
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 30.9.2010“. 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.
3.7.12
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 http://download.oracle.com/javase/1.4.2/docs/api/java/io/PipedOutputStream.html
56
následně mu přijde potvrzovací email, 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 emailu. Požadavek na registraci bude platný 48 hodin. Do té doby nebude možné vytvořit novou žádost o registraci na stejný email. Pokud uživatel do 48 svůj neaktivuje, může vytvořit požadavek nový.
Ilustrace 20: Diagram procesu registrace
Email bude odesílán v plain-text formátu. Pro generování emailu budou použity šablony, napsané ve skriptovacím jazyku Groovy (návrhy textů emailů jsou v příloze). Podpora jeho interpretace v jazyku JAVA je zajištěna příslušnou knihovnou.
3.7.13
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
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
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. •
3.7.14
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
1.6.2
Databázové transakce, OpenSessionInView
Spring
2.5.6
konfigurace aplikace, IoC67
Log4j
1.2.14
Vytváření systémového logu
Apache Commons
1.8
iText
2.1.7
Export do PDF
Groovy
1.7.4
Emailové 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 3.7.4.
67 Inversion of control
59
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
•
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
•
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
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.
3.9.1 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
• •
•
•
•
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.
3.9.2 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
•
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
•
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
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 emailů, 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
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ř. EmailService 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
4.2.1 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
public void perform(String groovyScript, School school, User user, List 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 """ """ } public String createInfoBlock(School school, User user) { def vytvoreno = new org.joda.DateTime().toString('dd.MM.yyyy HH:mm:ss') return """ E-Skola'$user.name' '$user.surname''$user.phone' <e-mail>'$user.email' <soubor>Z'$school.izo'_'$school.part' 'vytvoreno'""" } public String createRow(RowTO row) { return """ '$row.get("RDAT")''$school.izo''$school.part''$row.get("RODC")' ... """ } }
4.2.2 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
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: upravit uživatele
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 (
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
:
:
...
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.loadUserByEmail(user.getEmail()); if (ex != null && !ex.equals(user)) { editUserForm.recordError("Uživatel s tímto emailem již existuje"); } } return editUserForm.isValid() ? null : editUserForm; } @Transactional(readOnly = false) public void onSuccessFromEditUserForm() { userDAO.update(user); }
Můžeme si všimnout, že veškerá základní validace již byla provedena automaticky podle 70
definice v atributu t:validate.
4.2.3 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:
Třída cz.lmicko.eskola.dao.hibernate.FormDataUserType vypadá takto:
package cz.lmicko.eskola.dao.hibernate; … /** * @author 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 result = new ArrayList(); 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
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 entries = (List) 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.
4.2.4 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
... /** * @author 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 email; protected String phone; … }
a je mapován pomocí XML definice User.hbm.xml <param name="sequence">seq_user_id <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="email" column="TITLE"/> ...
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
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.
4.3.1 Nastavení prostředí 4.3.1.1 Aplikační server Aplikační server GlassFish 2.1.1 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
Je to tak z toho důvodu, že Tapestry nepodporuje implementaci stax2 a asl dodávanou společně s aplikačním serverem GlassFish 2.1.1. 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 http://docs.sun.com/app/docs/doc/820-7692
74
pod zadaným jménem zaregistruje.
4.3.1.2 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
4.3.2 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.
4.3.3 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-20100102
70 Dle doporučení popsaném on-line na http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server
75
4.4 Ukázka systému Demoverze aplikace je k vyzkoušení na https://www.e-skola.net. 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
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
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
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 TestNG): • • • •
@Test 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
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.
5.2.1 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í
5.2.2 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
5
10
50
100
Počet opakování
50
50
20
20
Počet vzorků
250
500
1000
2000
Délka odezvy Max. [ms]
259
356
1282
4760
Min. [ms]
59
59
62
77
79,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
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.
5.3.1 Testovací scénáře Úkol 1 – registrace do aplikace Uživatelská role: neregistrovaný uživatel Postup: 1. Uživatel otevře stránku https://www.e-skola.net 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ý email 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 https://www.e-skola.net 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
Uživatelská role: správce školy Předpokladem je úspěšné zvládnutí úkolu 2. Postup: 1. 2. 3. 4. 5.
Uživatel otevře stránku https://www.e-skola.net 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 2. 8. 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ů
5.3.2 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
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 https://www.e-skola.net. 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
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 1.1.2011.........................................................................................17 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ů...........................................................................................80
84
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.......................................................................78
85
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í. https://info336.felk.cvut.cz/clanek.php?id=400, stav k 1.1. 2011 [6] Vícero přispívatelů. CS a EN wikipedia. http://cs.wikipedia.org a http://en.wikipedia.org, stav k 1.1. 2011 [7] web:bakaláři. Dokumentace a informace k produktu Bakaláři. http://www.bakalari.cz, stav k 1.1. 2011 [8] web:škola online. Dokumentace a informace k produktu KATEDRA. http://www.skolaonline.cz, stav k 1.1. 2011 [9] web:ÚIV. Metodické pokyny a informace pro sběr dat na ÚIV. http://www.uiv.cz, stav k 1.1. 2011 [10] web:Matrika. Metodické pokyny a dokumentace aplikace Matrika. https://matrika.uiv.cz, stav k 1.1. 2011 [11] web:Hibernate. Dokumentace frameworku Hibernate. http://www.hibernate.org/docs, stav k 1.1. 2011 [12] web:Tapestry. Dokumentace frameworku Tapestry. http://tapestry.apache.org/, stav k 1.1. 2011 [13] web:Sbírka zákonů. Elektronická sbírka zákonů ČR. http://www.sbcr.cz/, stav k 1.1. 2011 [14] web:GlassFish: Administrační příručka aplikačního serveru GlassFish v2.1.1. http://docs.sun.com/app/docs/doc/820-4335/ablsw?a=browse, stav k 1.1. 2011 [15] web:PostgreSQL: Uživatelská příručka databázového serveru PostgreSQL 8.4.http://www.postgresql.org/docs/8.4/static/release-8-4.html, stav k 1.1. 2011
86
Příloha A Schéma českého systému školství
87
Příloha B Ukázka výkazu S 3-01
88
Příloha C Ukázka obsahu individuálního souboru – M 3 Vlastni_evidenceJan Novak123 456 789 <e-mail>[email protected] <soubor>K062157213_01 18.04.2007 12:23:5730.09.200606215721301830104X00111983013 <STPR>112 596612CZ0615109107870738 <STUPEN>3 01.09.2003A93108245M0010414010 <JAZYK_O>20 <JAZ1>02 <JAZ2>16 1201.09.2005101.09.2005 ... ... ...
89
Příloha D Detailní význam evidovaných položek •
• • •
• •
•
• • •
• •
RDAT – datum, ke kterému se předávají data pro školní matriku. Odpovídá koncovému datu sběrného období, které je vždy aktuálně přednastaveno na formuláři Export dat pro ÚIV. IZO – resortní identifikátor školy, která data vykazuje. CAST – označení části školy si určuje škola sama. Vždy začínáme od čísla 01 pro jednu část školy, 02 pro druhou část školy, 03 pro další část školy atd RODC – jednoznačný identifikátor fyzické osoby, ze kterého lze vyčíst datum narození a pohlaví příslušné osoby. Žáci/studenti narození po roce 1954 mají desetimístné rodné číslo, které je vždy dělitelné číslem 11. Žáci/studenti narození před rokem 1954 mají devítimístné rodné číslo s třímístnou koncovkou, které nesplňuje podmínku dělitelnosti jedenácti. U osob, kterým dosud nebylo našimi státními úřady přiděleno rodné číslo, se tento identifikátor „vypočítá“ dle data narození a pohlaví, za lomítko se uvede „X“+ trojmístné pořadové číslo přidělené jednoznačně školou. Každý žák/student na škole s takto přiděleným rodným číslem má jiné trojmístné pořadové číslo (čísla se nesmějí opakovat). POHLAVI – na základě této položky se třída dělí na chlapce a dívky. KSTPR – tento údaj je určen na základě státní příslušnosti a nastavujeme ho ve spolupráci se státem trvalého bydliště žáka/studenta. Pro občany České republiky nastavujeme „Občan ČR“, pro ostatní občany vybíráme kvalifikátor podle daných okolností. STPR – z číselníku ÚIV vybereme stát, jehož občanem je daný žák/student. Pokud má žák/student dvojí nebo vícenásobné státní občanství a jedním z nich je státní občanství ČR, je považován za občana ČR a k jinému státnímu občanství se nepřihlíží. OBECB – kód obce trvalého pobytu studenta - obec je základní jednotkou veřejné správy a samosprávy. OKRESB – okres trvalého pobytu studenta - okres je označení typu územně-správní jednotky menší než kraj a větší než obec. ODHL – předchozí působiště nově přijetého žáka - Položky jsou vybrány z číselníku ÚIV. Jedná se o školu, kterou žák/student navštěvoval, než začal studovat na naší škole. ZAHDAT - jedná se o datum začátku studia na škole, která vykazuje data. KOD_ZAH – informace, která udává způsob přijetí uchazeče. Uplatňují se 90
• • •
• • • •
• •
•
následující druhy kódů zahájení studia: • „zahájení 1. ročníku v ZŠ v řádném termínu“ • ·„zahájení 1. ročníku v ZŠ s jednoletým odkladem“ • ·„zahájení 1. ročníku v ZŠ s dvouletým odkladem“ • ·„zahájení 1. ročníku v ZŠ - jiné“ • ·„přestup z jiné školy“ • ·„žák/student pokračuje ve vzdělávání“ • ·„přijetí do 1. ročníku“ • ·„přijetí do 3. ročníku 6letého gymnázia“ • ·„přijetí do 5. ročníku 8letého gymnázia“ • ·„přijetí do vyššího ročníku (podle § 63 resp. § 95 ŠZ)“ – např. student navštěvuje 2. ročník SŠ, podá si žádost na přestup na jinou SŠ a na této škole začne studovat rovnou od 2. ročníku • ·„přestup z jiné školy (podle § 66 odst. 4 resp. § 95 odst. 5 ŠZ)“ • ·„přestup z nižšího stupně víceletého gymnázia do 4letého oboru gymnázia“ • ·„žák/student pokračuje ve vzdělávání“ UKONDAT – jedná se o datum ukončení studia na škole, která vykazuje data. KOD_UKON – kód ukončení vzdělávání na škole LET_PSD – počet let povinné školní docházky. Na počátku školního roku má mít žák ZŠ správně nastaven počet let povinné školní docházky o jedničku menší, nežli je počet let jeho studia na ZŠ. Např. pokud má žák klasický průběh vzdělávání a nyní je v sedmém ročníku ZŠ, bude mít na počátku roku vyplněnou hodnotu "6". Pokud je student ve 3. třídě ZŠ a již 2x propadl, uvádí se mu jako počet let splněné školní docházky 5 let. Maximální počet let splněné povinné školní docházky je 9 let (kromě výjimečných případů, jakými je např. studium na speciální ZŠ, studium nadprůměrně inteligentních žáků/studentů – zde může být uvedena jiná hodnota než 9). ROCNIK – ročník, ve kterém se student vzdělává PRIZN_ST – příznak vzdělávání, opakování a přerušení vzdělání ST_SKOLY – stupeň školy PRERUS – Celková doba přerušení daného druhu vzdělávání v měsících v dané škole (včetně prázdnin, počítá se každý započatý měsíc). Pokud žák přerušil studium vícekrát, celková doba přerušení je dána součtem jednotlivých dob přerušení. TRIDA – jedná se o název třídy/studijní skupiny. TYP_TR – typ třídy – určujeme, zda se jedná o běžnou třídu, o třídu pro žáky/studenty se speciálními vzdělávacími potřebami, s rozšířeným vyučováním, mimořádně nadané apod. OBOR – obor vzdělání v dané škole 91
• • • • •
• • • • • •
•
•
DELST – délka vzdělávacího programu. Na ZŠ se vyplňuje kód pro 9letou nebo 10letou školní docházku a to i v případě, že jedná o školu jen s prvním stupněm. P JAZYK_X – Jazyk, ve kterém je vyučován daný obor studia, ve kterém probíhá výuka. JAZX – kódy 1. - 4. cizího studovaného jazyka P_JAZX – příznak, zda se jedná o výuku jazyka povinného, volitelného nebo nepovinného předmětu INDI – ředitel školy může s písemným doporučením školského poradenského zařízení povolit nezletilému žákovi se speciálními vzdělávacími potřebami nebo s mimořádným nadáním na žádost jeho zákonného zástupce a zletilému žákovi nebo studentovi se speciálními vzdělávacími potřebami nebo s mimořádným nadáním na jeho žádost vzdělávání podle individuálního vzdělávacího plánu. Ve středním vzdělávání nebo vyšším odborném vzdělávání může ředitel školy povolit vzdělávání podle individuálního vzdělávacího plánu i z jiných závažných důvodů. Tato skutečnost je indikována tímto příznakem. NADANI – rozlišení pro mimořádně nadaného studenta FIN – požadavek na zvýšené výdaje pro studenta PLAT_ZAC – začátek platnosti věty PLAT_KON – konec platnosti věty KOD_ZAKA – jednoznačný identifikační kód studenta určený školou s vyloučením možnosti duplicit u různých studentů školy. POSTIZ_1, POSTIZ_2 – tělesné, mentální, duševní, smyslové nebo kombinované postižení, jehož dopady činí nebo mohou činit osobu závislou na pomoci jiné osoby. Evidujeme ho na základě příslušného potvrzení především z důvodu financování žáka/studenta. VICE_VAD – příznak souběžného postižení více vadami (na základě speciálněpedagogického případně psychologického vyšetření školským poradenským zařízením). ZPUSOB – tento údaj informuje o tom, jakým způsobem je plněna školní docházka.
92
Příloha E Výsledky zátěžových testů •
Test 1 počet vláken: 5, počet opakování: 50, pauza před startem požadavku: 10s 300
Test 2 počet vláken: 10, počet opakování: 50, pauza před startem požadavku: 10s 400
350
300
Request time [ms]
•
250
200
150
100
50
0 0
100
200
300 Sample #
93
400
500
600
•
Test 3 počet vláken: 50, počet opakování: 20, pauza před startem požadavku: 10s 1600
1400
Request time [ms]
1200
1000
800
600
400
200
0 0
200
400
600
800
1000
1200
Sample #
Test 4 počet vláken: 100, počet opakování: 20, pauza před startem požadavku: 10s
6000
5000
4000 Request time [ms]
•
3000
2000
1000
0 0
500
1000
1500 Sample #
94
2000
2500
Příloha F Výsledky unit tests Třída cz.lmicko.eskola.dao.hibernate.FormDataTest
Name
Status
Time(s)
testInsert
Success
0.390
testInsert_missingRequiredFields
Success
0.407
testInsert_wrongDataRange
Success
0.187
testInsert_emptyData
Success
0.213
testInsert_oneDataRow
Success
0.172
testInsert_100DataRows
Success
0.281
testInsert_1000DataRows
Success
0.972
testUpdate
Success
0.387
testUpdate_missingRequiredFields
Success
0.266
testUpdate_wrongDataRange
Success
0.125
testUpdate_emptyData
Success
0.172
testUpdate_oneDataRow
Success
0.265
testUpdate_100DataRows
Success
0.673
testUpdate_1000DataRows
Success
1.134
testUpdate_versionConfict
Success
0.125
testLoad
Success
0.156
testLoad_emptyData
Success
0.187
testLoad_noHistory
Success
0.297
testLoad_withHistory
Success
0.109
testLoad_noSuch
Success
0.125
testList_one
Success
0.453
testList_more
Success
0.431
testList_empty
Success
0.239
* Tabulka byla vygenerována frameworkem TestNG
95
Příloha G Texty registračních emailů Aktivace registrace Dobrý den, děkujeme Vám za registraci do služby E-Škola. Pro potvrzení registrace klikněte na následující aktivační odkaz. (Nebo můžete zkopírovat adresu odkazu do prohlížeče manuálně: http://www.e-skola.net/cs/register:confirmRegistrationRequest? reqId=2&code=tUUFxVuPdBJBE1uNpzs9nrQqqiJ6D5oElF57UYmZxjiLhq8axf). Když tak neučiníte do dvou dnů, Vaše žádost o registraci pozbude platnosti.
Potvrzení registrace Dobrý den, proces registrace do služby E-Škola SaaS byl úspěšně dokončen. Službu nyní můžete okamžitě začít používat na https://www.e-skola.net. Děkujeme, že jste si vybrali produkt E-Škola!
96
Příloha H Obsah přiloženého CD Adresář/Soubor
Obsah
/text
Text diplomové práce ve formátu PDF
/javadoc
Vývojářská dokumentace k projektu
/eskola
Kompletní projekt (ve struktuře prostředí Eclipse), zdrojový kód, knihovny a nastavení
