název práce Elektronická přihláška ke studiu na ČVUT Electronic application for study on CTU katedra obhajoby katedra počítačů

název práce Elektronická přihláška ke studiu na ČVUT Electronic application for study on CTU katedra obhajoby katedra počítačů obor Výpočetní technika (bakalářský) studijní program Bakalářský vedoucí Mannová Božena Ing., Ph.D. katedra počítačů (13136) http://cs.felk.cvut.cz/webis/people/mannova.html [email protected] rozvrh na FEL vedoucí na udb.feld oponent Šípek Herbert Ing. katedra počítačů (13136) externista, VIC ČVUT [email protected] student Souček Zbyněk (studuje) - zadáno [email protected] Výpočetní technika (bakalářský) studijní plán: Výpočetní technika- strukturované studium (BVT-D) katedra obhajoby podle studijního plánu: katedra počítačů literatura Dodá vedoucí práce pokyny Seznamte se s problematikou přihlášek ke studiu na ČVUT a na dalších vybraných školách. Navrhněte aplikaci přihlášky na ČVUT, která nahradí stávající. Základní funkcionality nové aplikace by měly pokrývat tyto připady užití: registrace, osobní informace, kontaktní informace, studium na ČVUT, předchozí vzdělání, tisk přihlášky. Navrženou aplikaci implementujte jako prototyp, s použitím vhodných technologií a s dodržením pravidel GUI aplikací

1

ČVUT. Prototyp otestujte a zhodnoťte výsledky. Při návrhu a realizaci dodržujte pravidla nakládání s osobními údaji.

2

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Bakalářská práce

Implementace elektronické přihlášky na ČVUT Zbyněk Souček

Vedoucí práce:

Ing. Božena Mannová, Ph.D.

Studijní program: Elektrotechnika a informatika. Obor: Výpočetní technika 30. května 2012

3

4

Poděkování Zejména bych chtěl poděkovat vedoucí práce za trpělivé a fundované vedení a rodině za trpělivost, kterou se mnou po dobu mého studia měla.

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). V Praze dne 30. 5. 2012

7

8

Abstract This work aims to design a prototype of a new application to study at ČVUT. The work concerns a proposal of a new system of collecting, storing and handling data of applicants that are required by colleges, registers and UIV. The essence of the work is a design of a prototype of electronic application form, which acts as an independent part of IS. The prototype follows the rules of web applications and is designed as a model for the needs of the Faculty of Electrical Engineering of ČVUT. The text part contains an analysis of the law on protection of personal data concerning this topic. The result of this work is tested and working prototype, which exists as an independent part of the IS, and all communication is based on a standard database interface.

Abstrakt Tato práce si klade za cíl vytvořit prototyp nové aplikace přihlášky ke studiu na ČVUT. Jedná se o návrh nového systému sbírání, ukládání a nakládání s daty uchazečů o studium, které jsou vyžadovány fakultami, matrikou a UIV. Podstatou práce je návrh prototypu elektronické přihlášky ke studiu, která funguje jako nezávislá součást IS. Prototyp respektuje pravidla tvorby webových aplikací a je vytvořen jako vzor pro potřeby elektrotechnické fakulty ČVUT. Textová část práce obsahuje analýzu ustanovení zákona o ochraně osobních údajů týkajících se tohoto tématu. Výsledkem této práce je tedy vyzkoušený a funkční prototyp, který existuje jako nezávislá součást IS s tím, že veškerá komunikace je založena na standardním databázovém rozhraní.

9

10

Obsah Úvod.................................................................................................................. 14 Popis problému a specifikace cíle ..................................................................... 15 Změny v návrzích přihlášky .......................................................................... 15 Srovnání přihlášek na vysoké školy .............................................................. 17 Analýza sběru, ukládání dat a popis zvolené technologie ................................ 24 Právní ochrana zpracování osobních údajů ................................................... 24 Vymezení pojmů ........................................................................................... 27 Správce a zpracovatel ................................................................................ 27 Osobní údaj ................................................................................................ 28 Citlivý údaj ................................................................................................ 28 Registry evidence osobních údajů ................................................................. 28 Přihláška ke studiu ..................................................................................... 29 Matrika studentů ........................................................................................ 30 Obecně o zvolené technologii ....................................................................... 31 Databáze .................................................................................................... 32 Co je Cluster .............................................................................................. 32 Cluster s vysokou dostupností ................................................................... 32 Cluster s rozložením zátěže ....................................................................... 32 Úložný cluster ............................................................................................ 33 Aplikační server ............................................................................................ 33 GlassFish ................................................................................................... 33 Apache Tomcat .......................................................................................... 34 Realizace návrhu ............................................................................................... 36 Implementace ................................................................................................ 36 Implementační prostředí ............................................................................ 36 Implementace aplikace .............................................................................. 36 Založení nového uživatele ......................................................................... 37 Formulář přihlášky .................................................................................... 37 Načítání informací do formuláře z databáze ............................................. 38

11

Tisk přihlášky ............................................................................................ 38 Struktura ........................................................................................................ 39 Příklady užití .............................................................................................. 40 Použitá technologie ....................................................................................... 49 Technologie stránek ................................................................................... 49 JSF ............................................................................................................. 49 JSP ............................................................................................................. 50 Princip činnosti .......................................................................................... 51 Výhody JSP ................................................................................................... 51 XEP ............................................................................................................... 52 Testování ........................................................................................................... 54 Srovnání se současnou přihláškou ................................................................. 55 Závěr ................................................................................................................. 56 Literatura ........................................................................................................... 58 Přílohy ............................................................................................................... 60

12

Seznam obrázků Obrázek 1: Přihláška ke studiu na ČVUT v r. 2009 ......................................... 16 Obrázek 2: Výstup přihlášky na ČVUT v r. 2009 ............................................ 17 Obrázek 3: Univerzita Karlova v Praze ............................................................ 19 Obrázek 4: Masarykova Univerzita v Brně ...................................................... 19 Obrázek 5: Univerzita Palackého v Olomouci ................................................. 20 Obrázek 6: Univerzita Pardubice ...................................................................... 20 Obrázek 7: Technická Univerzita v Liberci ...................................................... 21 Obrázek 8: VUT v Brně .................................................................................... 21 Obrázek 9: VŠE v Praze ................................................................................... 22 Obrázek 10: VŠFS v Praze ............................................................................... 22 Obrázek 11: UJAK............................................................................................ 23 Obrázek 12: Aplikační server Glassfish ........................................................... 34 Obrázek 13: Aplikační server Apache-Tomcat ................................................ 35 Obrázek 14: Schema transformace XML do PDF ............................................ 39 Obrázek 15: Návrh Grafického výstupu v2 ...................................................... 53

13

Kapitola 1

Úvod V zadání je uvedeno, že na základě seznámení se s problematikou přihlášek ke studiu na vybraných vysokých školách mám navrhnout aplikaci přihlášky na ČVUT. V intencích těchto pokynů jsem se začal zabývat tématem elektronické přihlášky již v roce 2009. V tu dobu probíhal ve Výpočetním a informačním centru (dále jen „VIC ČVUT“) projekt, jehož náplní bylo prozkoumat stávající elektronickou přihlášku a navrhnout novou. Problémem jsem se zabýval zejména po stránce strukturální. Projekt pro mne skončil vypracovanými analýzami, návrhem struktury a grafického výstupu. Myslím si, že řešení přihlášky pomocí technologie ORACLE Forms není zrovna nejšťastnější, vzhledem k tomu, že nejde o výrazné zlepšení předchozího stavu. Jedním z problémů je i správné právní ukotvení a příliš těsné provázání na databázi IS KOS. Současná webová aplikace přihláška ke studiu neodpovídá zavedenému MVC modelu. Proto navrhuji novou formu elektronické přihlášky na ČVUT, která bude odpovídat standardu webových aplikací používajících MVC. Po konzultaci s oponentem bakalářské práce, jsme zkonstatovali, že rozsah prací je příliš obsáhlý a z časových důvodů neproveditelný. Proto jsem se rozhodl omezit se pouze na vzorový formulář pro fakultu elektrotechnickou s tím, že počítám s rozšířením práce v navazující magisterské diplomové práci. V teoretické části uvádím základní právní rámec problematiky ochrany osobních dat a rozpracování grafického rozhraní přihlášky. Toto téma má velmi široký záběr, a proto předpokládám navazující diplomovou práci na toto téma, rozvíjející zde načrtnutou myšlenku. Odstranění stávajících vazeb na IS KOS a nahrazení standardním JDBC rozhraním pokládám za přínos projektu. Po této změně bude možné webovou aplikaci připojit k jakékoli databázi ORACLE.

Po dohodě s vedoucí práce je rozsah bakalářské práce omezen na prototyp vytvořený pro elektrotechnickou fakultu ČVUT. Prototyp jsem otestoval na lokálním disku.

14

Kapitola 2 Popis problému a specifikace cíle Změny v návrzích přihlášky V současné době používaná elektronická přihláška na ČVUT nevyhovuje současné úrovni vývoje v mnoha směrech. Každá fakulta ČVUT má pro přihlášku ke studiu vytvořený jiný formulář, lišící se obsahem, který reflektuje rozdílné požadavky fakult. Cílem této práce je navrhnout nový systém sbírání, ukládání a nakládání s daty uchazečů o studium na ČVUT. Tato práce si klade za cíl vytvořit webovou aplikaci respektující současné trendy vývoje takového druhu systémů pomocí perspektivních technologií. Současná verze přihlášky byla vytvořena na základě mnou provedených analýz z roku 2009. Předtím byla přihláška graficky velmi nudná a nepřehledná. Projít přihlášku znamenalo proklikávat se postupně zdlouhavou řadou formulářů, aniž bychom se mohli rozumným způsobem podívat zpět. Po stránce grafického zpracování působila přihláška tehdy již poněkud zastaralým dojmem, protože v situaci, kdy ostatní univerzity, či vysoké školy již užívaly multimediální prezentace a jejich přihlášky ke studiu se opíraly o spoustu flashových nebo skriptovaných aplikací. Přihláška používala pouze dvě barvy (modrou a šedivou). Tehdy i grafický výstup pomocí fontu 8 či 9 byl zcela nepřehledný a těžko čitelný. Na základě mých analýz byl opraven obsah formuláře, který byl rozčleněn do 6 bloků (stránek), které jsou tematicky zaměřeny a grafický výstup vychází z podoby papírové přihlášky od firmy SEVT, který byl designově upraven pro potřeby ČVUT.

15

Přes tyto změny, využívá současná elektronická přihláška ke studiu v podstatě stejnou technologii, jako předchozí řešení. Protože si myslím, že tato situace není dlouhodobě udržitelná a zcela vhodná, přicházím s návrhem postavení elektronické přihlášky ke studiu na standardu webových aplikací používajících MVC. Odstraněním stávajících vazeb na IS KOS a jejich nahrazení standardním JDBC rozhraním pokládám za elegantnější a dlouhodobě praktičtější. Po této změně bude možné webovou aplikaci přihláška ke studiu, připojit k jakékoli databázi ORACLE, která bude obsahovat patřičné tabulky atd. Bakalářská práce je rozčleněna do čtyř částí: 1) 2) 3) 4)

popis problému a specifice cílů; analýza sběru, ukládání dat a popis zvolené technologie; realizace návrhu; testování.

Není mi známo, že by kdokoli zpracoval existující implementaci tohoto projektu. Pro představu uvádím níže několik podob přihlášky v průběhu analýz:

Obrázek 1: Přihláška ke studiu na ČVUT v r. 2009

16

Obrázek 2: Výstup přihlášky na ČVUT v r. 2009

Srovnání přihlášek na vysoké školy Provedl jsem srovnání existujících elektronických přihlášek na většině vysokých škol u nás z hlediska uživatelsky přívětivého rozhraní, profesionality naprogramování a informací, které o zájemcích o studium jednotlivé školy sbírají. Výsledky tohoto srovnání mě dovedly k zamyšlení nad tím, jakým způsobem a kam směřovat vývoj nové verze elektronické přihlášky na ČVUT. Použití stávající technologie, kterou mimo ČVUT používala již jen ZČU, TUL či Univerzita v Pardubicích, se ukázala jako neudržitelná. Přihláška na ČVUT v porovnání s ostatním přihláškami propadla jak po stránce designu, tak i po stránce uživatelského komfortu. Vzhledem k tomu, že technické univerzity lze považovat za průkopníky nových technologií a zvláště v případě, že disponují specializovanými pracovišti a připravují studenty v oborech IT, byla přihláška

17

na ČVUT v porovnání s ostatními školami spíše odrazující, než aby poukázala na vysokou úroveň technické vyspělosti univerzity. Přihlášky univerzit s humanitními obory působí daleko lepším dojmem a jsou uživatelsky příjemnější a přehlednější. V současné době, kdy dochází k rozvoji nového oboru HCI a stále více je kladen důraz na uživatelsky přívětivá rozhraní, je důležité, aby i ČVUT využila sdružení znalostí více specializovaných disciplín, jakými jsou například informační věda, psychologie, sociologie, antropologie, design, lingvistika, ergonomika a použila je pro svou prezentaci a zlepšení uživatelského přístupu. Pro srovnání1 jsem si vybral ukázky elektronických přihlášek na osm prestižních státních2 univerzit a dvě soukromé3 v ČR. A jak jsem již uvedl výše tak výsledky mého srovnání dopadly pro vybrané technické univerzity s výjimkou VUT v Brně žalostně. Pro porovnání uvedu několik obrázků přihlášek univerzit.

1

Žádné oficiální (Ministerstvem školství vyhotovené) srovnání vysokých škol v ČR neexistuje. Každoročně je však v únoru v Hospodářských novinách uveřejněn žebříček nejlepších fakult v devíti žádaných oborech. Ve svém srovnání jsem vycházel z žebříčku z let 2011 a 2012. (viz: http://hn.ihned.cz/c1-54661180-univerzita-karlova-vzala-vse-primat-v-ekonomii) 2

Univerzita Karlova v Praze, Univerzita Palackého v Olomouci, Masarykova univerzita v Brně, Vysoká škola ekonomická v Praze, VUT v Brně, Univerzita Pardubice, Technická Univerzita v Liberci, Univerzita v Hradci Králové. 3

Vysoká škola finanční a správní (VŠFS) a Univerzita Jana Amose Komenského v Praze (UJAK).

18

Obrázek 3: Univerzita Karlova v Praze

Obrázek 4: Masarykova Univerzita v Brně

19

Obrázek 5: Univerzita Palackého v Olomouci

Obrázek 6: Univerzita Pardubice

20

Obrázek 7: Technická Univerzita v Liberci

Obrázek 8: VUT v Brně

21

Obrázek 9: VŠE v Praze

Obrázek 10: VŠFS v Praze

22

Obrázek 11: UJAK

Jak je z výše uvedených obrázků patrné tak i soukromé univerzity jako je UJAK jsou schopny nabídnout zájemcům o studium zajímavější a přehlednější přihlášku ke studiu, proto jsem se rozhodl změnit stávající formu přihlášky od základu.

23

Kapitola 3

Analýza sběru, ukládání dat a popis zvolené technologie Sběrem a uchováváním dat jsem se začal zabývat ve chvíli, kdy jsem zjistil, že by nebylo zcela od věci ukládat data zájemců o studium z důvodu zachování informací při eventuálním nepřijetí uchazeče ke studiu (a to nejen kvůli jeho dalšímu zájmu o studium na ČVUT, ale i kvůli zpracování dat pro výstupy manažerského systému). Díky možnosti dalšího zpracování dat, by mohly tyto informace dále sloužit univerzitě, jako podklad pro přehled, z jakých středních škol se hlásí nejvíce uchazečů (procento úspěšnosti jednotlivých škol) atd. Informace tohoto typu by byly užitečné nejen pro ČVUT při oslovování a získávání nových potenciálních zájemců o studium, ale i jako zpětná vazba pro střední školy a zájemce o studium na nich (informace o tom, na které střední škole je nejlépe připraví na přijetí ke studiu na ČVUT). Narazil jsem však na problém s ochranou tzv. osobních dat, u kterých je požadována maximální míra zabezpečení. Z tohoto důvodu bych chtěl níže stručně rozebrat problém uchovávání dat z pohledu práva.

Právní ochrana zpracování osobních údajů Rozvoj a šíření IT technologií kromě výhod otevírá bohužel i možnost monitorování soukromí fyzických osob, vnikání do něj a následně i jeho narušování. Informace o občanech jsou systematicky sbírány již od doby Marie Terezie, kdy jsou organizovaně vedeny matriky. Zvláštnost ve sbírání informací pak spočívá v tom, že jde o neoddělitelné a nezcizitelné vlastnictví každého člověka bez ohledu na jeho ekonomickou situaci či společenské postavení. V případě, že tyto informace získá někdo jiný, může profil osoby

24

vytvořit určitou reputaci, či pověst, která je výrazem lidské důstojnosti a jeho hodnocení ve společnosti s pozitivními či negativními důsledky. Před masivním rozvojem IT technologií bylo soukromí těchto informací chráněno především časem a prostorem. S rozvojem počítačové techniky se stávají informace dostupné v podstatě komukoli, kdo i díky běžnému softwaru může informace rychle třídit, vybírat a analyzovat. Protože tento vývoj přináší dříve neznámá potenciální nebezpečí, společnost si nastavila nová pravidla, která mají vymezit nové hranice soukromí. Historicky první zákon na světě upravující tuto oblast, byl přijat v roce 1973 ve Švédsku a Rada Evropy připojila Úmluvu4 v roce 1981. Ve chvíli, kdy byla vydána Listina základních práv a svobod (dále jen „Listina“)5, bylo právo na soukromí explicitně vyjádřeno i v českém právním řádu. Navíc v roce 1995 přijaly Evropský parlament a Rada Směrnici č. 95/46/ES6. V nejširší povinné podobě jsou tyto principy promítnuty v současně platném zákoně č. 101/2000 Sb.7, o ochraně osobních údajů a změně některých zákonů (dále jen „zákon“). Podle zákona se zpracováním osobních údajů rozumí jakákoliv operace nebo soustava operací, které správce nebo zpracovatel systematicky provádějí s osobními údaji, tedy zejména shromažďování, ukládání na nosiče, úprava

4

Úmluva č. 108 na ochranu osob ve vztahu k automatizovanému zpracování dat. Z této Úmluvy pak vyšel zákon č. 256/1992 Sb., o ochraně osobních údajů v informačních systémech. Jak uvádí V. Šmíd, byl tento zákon převratný, ale byly mu vytýkány nepřesné definice pojmů, úzká působnost a neoperativnost při domáhání se práv dotčených osob. Zákon hlavně předpokládal ustavení orgánu, jehož posláním by byla ochrana osobních údajů jednotlivců, ale ten nebyl za účinnosti tohoto zákona zřízen.

5

Usnesení předsednictva České národní rady č. 2/1993 Sb., o vyhlášení Listiny základních práv a svobod jako součásti ústavního pořádku České republiky. Listina v čl. 7 ustanovuje právo na nedotknutelnost osoby a jejího soukromí a v čl. 10 odst. 3 upravuje právo každého na ochranu před neoprávněným shromažďováním, zveřejňováním nebo jiným zneužíváním údajů o své osobě.

6

Směrnice Evropského parlamentu a Rady č. 95/46/ES ze dne 24. října 1995, o ochraně fyzických osob v souvislosti se zpracováním osobních údajů v informačních systémech a o volném pohybu těchto údajů, v čl. 6 odst. 1 písm. b) uvádí, že osobní údaje mohou být shromažďovány pro stanovené účely, volně vyjádřené a legitimní.

7

V zákoně č. 101/2000 Sb., je výrazně zjednodušená základní definice pojmu osobní údaj, nově rozlišuje dvě kategorie subjektů zpracovávajících osobní údaje: správce a zpracovatele. Došlo také k upřesnění zacházení s citlivými údaji. Na základě tohoto zákona byl zřízen Úřad na ochranu osobních údajů.

25

nebo pozměňování, třídění, vyhledávání, používání, předávání, šíření, uchovávání, výměna, zveřejňování, blokování a likvidace.8 Zpracováním osobních údajů dochází k zásahu do soukromí jejich nositele. Proto směrnice Evropského parlamentu a Rady č. 95/46/ES, i zákon, stanoví obecné pravidlo, že zpracování osobních údajů se může dít pouze se souhlasem jejich nositele, právní terminologií subjektu údajů (s výhradou některých výjimek, v českém právním řádu upravených v § 5 odst. 2 zákona). Z tohoto důvodu je institut souhlasu se zpracováním osobních údajů jedním z nejvýznamnějších v celé oblasti ochrany osobních údajů. Směrnice jej upravuje takto: „Pro účely této směrnice se rozumí ´souhlasem dotčené osoby´ jakýkoli svobodný, výslovný a vědomý projev vůle, kterým dotčená osoba přijímá, aby osobní údaje, které se jí týkají, byly předmětem zpracování.“ „Ten, kdo hodlá zpracovávat osobní údaje (správce), musí dle ustanovení § 5 odst. 4 zákona, informovat subjekt údajů včas a řádně o tom, že o něm shromažďuje údaje, v jakém rozsahu a pro jaký účel (s jakým cílem), jaké osobní údaje budou zpracovávány (konkrétní kategorie údajů a jejich rozsah), kdo je bude zpracovávat (správce se musí jednoznačně identifikovat) a jak dlouho (na jakou dobu je souhlas s tímto konkrétním zpracováním osobních údajů poskytován). Rovněž musí subjekt údajů poučit o tom, zda je podle zákona povinen pro zpracování osobní údaje poskytnout, jaké důsledky budou vyvozeny, pokud tak neučiní, a kdy je oprávněn odmítnout poskytnutí osobních údajů, nebo zda poskytnutí osobních údajů je dobrovolné. Pouze takové zpracování, o němž je subjekt údajů dostatečně poučen, může řádně posoudit a rozhodnout se, zda s ním bude souhlasit.“9 Při shromažďování osobních údajů musí být subjekt údajů dále poučen o tom, komu mohou být jeho osobní údaje zpřístupněny, a také o svých právech dle § 12 a § 21 zákona.

8

Předchozí právní úprava (zák. č. 256/1992 Sb.) se týkala pouze automatizovaného zpracování osobních dat v informačních systémech, nová norma se vztahuje na jakékoliv osobní údaje zpracovávané jak automatizovaně, tak i manuálně.

9

Viz stanovisko č. 2/2008 Úřadu pro ochranu osobních údajů, ze září 2008. http://www.uoou.cz/files/stanovisko_2008_2.pdf

26

Správce má rovněž podle zákona povinnost jednou za kalendářní rok10 bezplatně poskytnout subjektu údajů na základě písemné žádosti informace o osobních údajích o něm zpracovávaných. V zákoně byla rozšířena a upřesněna práva subjektů údajů v situaci, kdy při zpracování dat došlo k porušení povinností. Pokud tak učinil správce nebo zpracovatel, má subjekt údajů právo požadovat:    

aby se správce či zpracovatel zdržel takového jednání, odstranil vzniklý stav či poskytl na své náklady omluvu nebo jiné zadostiučinění subjektu údajů; aby správce či zpracovatel provedl opravu nebo doplnění osobních údajů tak, aby byly pravdivé a přesné; aby osobní údaje byly zablokovány nebo zlikvidovány; zaplacení peněžité náhrady, jestliže tím bylo porušeno jeho právo na lidskou důstojnost, osobní čest, dobrou pověst či právo na ochranu jména.

Vymezení pojmů Správce a zpracovatel Podle § 4 odst. j) zákona je správcem „každý subjekt, který určuje účel a prostředky zpracování osobních údajů, provádí zpracování a odpovídá za něj. Zpracováním osobních údajů může správce zmocnit nebo pověřit zpracovatele“, kterým je podle § 4 odst. k) zákona „subjekt zmocněný buď na základě zvláštního zákona, nebo na základě pověření správcem“. Správcem databáze obsahující osobní údaje je tedy kdokoliv, kdo v rámci výkonu své práce systematicky spravuje databázi s osobními a citlivými údaji.

10

Správce je povinen poskytnout tuto informaci kdykoli subjektu údajů na základě písemné žádosti za přiměřenou úhradu nepřevyšující náklady nezbytné na poskytnutí informace.

27

Osobní údaj Dle § 4 odst. a) zákona jde o jakoukoliv informaci, díky níž se „subjekt údajů považuje za určený či určitelný...11“. Nejznámějším příkladem osobního údaje je rodné číslo12. V současné době se začíná využívat i jiných nezaměnitelných identifikátorů.13 Stejně tak může být považován za informaci identifikující subjekt např. PIN k platební kartě nebo mobilní telefonní číslo, jak je uvedeno v rozsudku Nejvyššího správního soudu.

Citlivý údaj Dle § 4 odst. b) zákona jde o „osobní údaj vypovídající o národnostním, rasovém nebo etnickém původu, politických postojích, náboženství, zdravotním stavu14 a sexuálním životě subjektu údajů, který umožňuje přímou identifikaci nebo autentizaci subjektu údajů“.

Registry evidence osobních údajů Každý, kdo v ČR sbírá osobní data a nakládá s nimi, musí být registrovaný15 u Úřadu na ochranu osobních údajů a jasně deklarovat účel pro který je bude

11

Podle rozsudku Nejvyššího správního soudu ze dne 12. 2. 2009 (čj. 9 As 34/2008 – 68) je „plná identifikace osoby v současných podmínkách technologicky vyspělé společnosti ... ve své podstatě neznamená nic jiného, než možnost tuto osobu určitým způsobem kontaktovat, aniž by bylo nutno znát místo jejího aktuálního pobytu. Proto se výklad pojmu osobní údaj nemůže omezit jen na znalost např. rodného čísla, adresy či pracoviště subjektu údajů.“ – viz www.nssoud.cz 12 Jedná se o národní identifikátor, regulovaný zákonem č. 133/2000 Sb., o evidenci obyvatel a rodných číslech. 13 Jedná se o tzv. agendové identifikátory, které fyzickou osobu určí jen pro omezený okruh oprávněných osob. Byly zavedeny do právního řádu zákonem č. 111/2009 Sb., o základních registrech. Dalším novým kódem je tzv. bezpečnostní osobní kód podle § 8a zákona č. 328/1999 Sb., o občanských průkazech. 14 Za tento údaj se nepovažuje obecná informace: „je zdráv“. 15

ČVUT je zaregistrováno pod reg. č. 00001546 u Úřadu na ochranu osobních údajů.

28

užívat.16 Jediné dva registry, kde mohou být na vysokých školách evidovány osobní údaje studentů, jsou: přihlášky ke studiu17 a matrika studentů18.

Přihláška ke studiu Zákon č. 111/1998 Sb., o vysokých školách a o změně a doplnění dalších zákonů uvádí v § 17 odst. 2 písm. c) že „podmínky přijetí ke studiu a způsob podávání přihlášek“ obsahuje statut vysoké školy. V § 49 odst. 5 tohoto zákona je umožněno vysoké škole zvolit si způsob podání přihlášky ke studiu, a to buď písemnou, či elektronickou formou. Matrika studentů je naplňována informacemi, které jsou získávány z přihlášky a ověřovány na studijním oddělení. V současné době se tak děje formou fyzické kontroly osobních materiálů, ale od 1. července 2012 by se v případě osobních údajů mělo ověřování zrychlit a zjednodušit díky uvedení do provozu Základních registrů (registr obyvatel). V současné době již funguje testovací prostředí, na kterém je možné si tuto funkcionalitu vyzkoušet a naučit. Přihláška ke studiu na ČVUT, kterou navrhuji, je strukturovaná do pěti částí. První částí je registrace uchazeče. Ve druhé části jsou osobní informace včetně rodného čísla, čísla občanského průkazu a informací o narození. Třetí část obsahuje kontaktní informace a čtvrtá fakultu a druh studia, o který uchazeč usiluje včetně projevení zájmu o kolej (kde je uveden citlivý dotaz na zdravotní postižení uchazeče z důvodu zvláštních podmínek a výhod pro tyto uchazeče v průběhu studia). Pátá část se zaměřuje na předchozí vzdělání a studijní výsledky v předem daných parametrech.

16

Úmluva č. 108, která myšlenkově navazuje na princip ochrany soukromí obsažený v Evropské úmluvě o ochraně lidských práv a základních svobod z r. 1950. V současné době ji naprostá většina států ratifikovala, nebo alespoň podepsala.

17

Způsob podávání přihlášek je v obecné rovině upraven v § 17 odst. 2 zákona č. 111/1998 Sb., o vysokých školách. Přijímací řízení je podle § 50 odst. 1 téhož zákona zahájeno doručením písemné přihlášky ke studiu vysoké škole nebo její součásti, která uskutečňuje příslušný studijní program.

18

Náležitosti matriky studentů jsou upraveny v § 88 zákona č. 111/1998 Sb., o vysokých školách.

29

Druhou, a třetí část a díl čtvrté části, týkající se zdravotního postižení, lze pokládat za místa s citlivými údaji. Je proto nezbytně nutné tyto informace ukládat a uchovávat odděleně se zvýšenou ochranou dat. Po dotazu na Úřad pro ochranu osobních údajů jsem z přihlášky vypustil položku „národnost“. Jde o citlivý údaj, který dle komentáře k zákonu19 a dobrozdání úřadu není vyžadován. Některé školy, aby se vyhnuly problémům, vynechaly i kolonku „státní příslušnost“. Protože studijní oddělení stále vyžaduje doplnění státní příslušnosti i občanství, ponechal jsem tyto položky. Jejich ověřování probíhá stejným způsobem, jako ověření ostatních elektronicky sdělovaných údajů, tedy následným překontrolováním s písemnými doklady. Od 1. 7. 2012 za účinnosti Základních registrů již tento údaj nebude vyžadován a nebude jej možné ani v registrech ověřovat.

Matrika studentů Zákon č. 111/1998 Sb., o vysokých školách a o změně a doplnění dalších zákonů, uložil vysokým školám v ustanovení § 101 odst. 4 povinnost zapisovat veškeré studenty na nich studující od 1. 1. 1999 do matriky studentů a dle § 88 téhož zákona tuto evidenci dále vést. Matrika studentů byla zřízena proto, aby sloužila „k evidenci o studentech a k rozpočtovým a statistickým účelům“.20 Podle § 87 písm. i) zákona byla v rámci definice působnosti Ministerstva školství, mládeže a tělovýchovy ČR (dále jen „MŠMT“) stanovena možnost sdružovat a využívat informace o uchazečích o přijetí ke studiu, absolventech celoživotního vzdělávání a informace z matriky studentů jednotlivých vysokých škol.21

19

BARTÍK, V., JANEČKOVÁ, E. Zákon o ochraně osobních údajů s komentářem. s. 39.

20

Šlo vlastně o realizaci projektu Databáze Sdružených Informací Matrik Studentů (zkráceně SIMS) na něž vypsalo MŠMT v r. 1998 výběrové řízení, které vyhrála Masarykova univerzita v Brně, která byla pověřena jeho realizací. Cílem projektu bylo definovat rozhraní mezi zdroji dat a centrálním systémem SIMS, zprůchodnit zabezpečený přenos informací přes tato rozhraní a zajistit jejich centrální zpracování a diferencovanou přístupnost. K základním požadavkům patřilo i zajištění autenticity uživatelů a nepopiratelnosti dat.

21

Jde o veřejné i soukromé vysoké školy. Jediný rozdíl je jen v tom, že v případě státních vysokých škol je tato působnost speciálně svěřena příslušnému ministerstvu.

30

Matrika vychází z principu sběru jen údajů nezbytně nutných k danému účelu. Data sbíraná pro matriku se skládají do věty o 46 datových položkách, z nichž 42 bylo odvozeno ze zákonné definice matriky studentů. Další čtyři položky22 byly požadovány MŠMT jako nezbytné pro rozpočtové a dotační účely. Položky záznamů matriky tvoří tři okruhy: údaje o osobě studenta, studijní záznamy a údaje o historii studia. Student je v matrice identifikován rodným číslem, což s sebou nese všechny problémy tradičně spojené s fenoménem použití rodného čísla, včetně problému identifikace studentů-cizinců. Osobní údaje dále obsahují příjmení, kód okresu bydliště, kód státu a kód předchozího vzdělání – poslední tři údaje jsou nutné pro základní výstupy SIMS. „Základní informační jednotkou matriky jsou data o studentovi ve spojení se studijním programem, který studuje na dané škole/fakultě. Pro automatizovaný sběr dat do sdružené matriky jsou tato data linearizována tak, že jeden záznam předávaný mezi vysokými školami a MŠMT je záznamem jedné etapy historie konkrétního studia konkrétního studenta na konkrétní vysoké škole.“23 ČVUT udržuje údaje o studentech v nezávislém informačním systému KOS. Sdružená matrika určuje pouze minimální informační obsah tohoto IS. Pro předávání dat mezi lokálními IS vysokých škol a systémem SIMS je definováno jednotné rozhraní, jímž je textový soubor s ministerstvem definovanou strukturou, obsahem a formátem. Každý záznam odpovídá jedné etapě historie studia, jednotlivými položkami jsou atributy historie studia.

Obecně o zvolené technologii Návrh na ukládání dat a jejich zabezpečení proti cizímu vniknutí a zneužití je jedním z klíčových prvků systému. Veškerá data osobního i neosobního charakteru by byla ukládána do databázových tabulek na databázových serverech. Všechny tyto servery jakož i servery aplikační by byly umístěny na uzavřeném segmentu sítě kam je znemožněn přístup z internetu, ale i z centrální sítě ČVUT Tento segment, by představoval jakousi demilitarizovanou zónu uvnitř sítě ČVUT. Přístup do této zóny by byl omezen pouze na správce

22

Jde o položky: „Ubytování“, „Místo výuky“, „Financování“ a „Národnost“. Poslední položka patří mezi citlivé údaje 23 Viz Šmíd, V. a Kohoutková, J.: Matriky studentů vysokých škol a ČR a jejich informační hodnota. s. 2

31

systému a servery které by zajištovaly samotný chod aplikace. To znamená servery IS KOS, který by byl zdrojem dat a číselníků, a možných dalších serverů které zpracovávají data z přihlášek do různých statistik. Veškerý přístup k těmto strojům by byl zajištěn pouze přes SSL komunikaci tak, aby byla zajištěna bezpečnost přenosu dat pomocí šifrování. Přístup k aplikaci by byl zajištěn tak, že by služba aplikace E-přihláška byla nabízena na jedné z veřejných adres a odtud by byly požadavky přenášeny přes server zajištující oddělení segmentu a vyvažovač na aplikační servery na kterých by běžela nabízená služba.

Databáze Veškerá databáze by byla uložena na ostrém DB serveru postaveném nejspíše na technologii IBM Blade. Na této technologii je dnes vytvořen Cluster, na kterém jsou provozovány jak databázové servery informačního systému, tak i některé servery aplikační.

Co je Cluster Tedy Cluster je seskupení volně vázaných počítačů, které spolu úzce spolupracují, takže navenek mohou pracovat jako jeden počítač. Obvykle jsou propojeny strukturou počítačové sítě. Clustery jsou obvykle nasazovány pro zvýšení výpočetní rychlosti nebo spolehlivosti s větší efektivitou než by mohl poskytnout jediný počítač, přičemž jsou levnější než jediný počítač o srovnatelné rychlosti nebo spolehlivosti.

Cluster s vysokou dostupností Cluster s vysokou dostupností (High-availability či failover) je systém, který zajišťuje pomocí několika počítačů nepřetržité poskytování nějaké služby i při výpadku počítače z důvodu hardwarové závady nebo plánované údržby. Službu poskytuje jeden počítač, který je v případě výpadku automaticky zastoupen jiným počítačem.

Cluster s rozložením zátěže Cluster s rozložením zátěže (load ballancing či scallable) je systém, který snižuje možnou míru zátěže tím, že službu poskytuje několik počítačů, které mají stejný obsah (služba je poskytována paralelně). Stejný obsah je zajištěn

32

replikací obsahu mezi všechny propojené specializovaného centrálního úložiště.

počítače

nebo

existencí

Úložný cluster Úložný cluster (Storage cluster) zprostředkovává přístup k diskové kapacitě, která je rozložena mezi více počítačů z důvodu dosažení vyššího výkonu nebo pro zajištění vyšší spolehlivosti. Toho je dosahováno speciálními souborovými systémy, které jsou schopny zajistit rozložení zátěže, redundanci dat, pokrytí výpadků jednotlivých uzlů, distribuovaný mechanismus zamykání souborů a další doprovodné služby.

Aplikační server Aplikační server by mohl být postaven na propojení technologií APACHE – TOMCAT a nebo lze použít technologii od společnosti SUN tzv. GLAS FISH. V celkovém pojetí a funkci se jedná o velmi podobné systémy, které jsou určeny pro hostování webových aplikací. Technologie od SUN má z našeho pohledu možnou výhodu neboť je celý tento systém postaven na technologii Java. Což znamená, že je plně optimalizován na hostování aplikací vytvořených na stejné platformě. Pro technologii APACHE – TOMCAT zase hovoří dlouhodobé používání a zkušenosti z mnoha funkčních nasazení v rámci celé univerzity.

GlassFish Jedná se o aplikační server vyvinutý společností Sun Microsystems pro platformu Java EE. GlassFish se řadí mezi open source podléhající licencím GPL a CDDL. GlassFish je referenční implementace, to znamená, že není primárně určen pro provoz aplikací, ale slouží především jako ukázka implementace nových rysů v poslední specifikaci platformy JAVA EE. Současná verze serveru GlassFish je 3.0.1 a slouží jako referenční implementace proj Javu EE6. Existuje rovněž komerční verze, která nese označení Oracle GlassFish Sever 3.0.1. Obě verze se ve funkcionalitě téměř neliší, hlavní rozdíl je především v podpoře a automatickém stahování aktualizací.

33

Obrázek 12: Aplikační server Glassfish

Apache Tomcat Je jedním z nejznámějších a nejpoužívanějších aplikačních serverů. Je vyvíjený jako opensource. Je rovněž založen na jazyce java, javových servletech, JSP (Java Server Pages) a EJB (Enterprise JavaBeans). Je srovnatelný s komerčními produkty, z nichž nejznámější jsou „WebSphere Application Server“ od IBM, „Web Logic Aplikation Server“, „GlassFish“ od Oracle a další. Tyto komerční produkty oproti Tomcatu poskytují zpravidla větší robustnost a lépe propracovanou bezpečnostní stránku. Oproti tomu Tomcat vyniká jednoduchostí, transparentností, menší náročností na výpočetní výkon a podstatně rychleji se v něm vyvíjí. Já sám pomocí něho provozuji několik systémů v rámci informačního systému ČVUT.

34

Obrázek 13: Aplikační server Apache-Tomcat

35

Kapitola 4 Realizace návrhu Implementace Implementační prostředí Pro implementaci projektu E-přihláška jsem si vybral prostředí ECLIPSE, které je uživatelsky příjemné a jednoduché. Instalace tohoto prostředí spočívá v rozbalení instalačního balíčku do předem připraveného adresáře. Jakmile se balíček rozbalí, je možné rovnou začít používat vývojové prostředí. Pro mé účely jsem však do prostředí doinstaloval modul MAVEN který slouží ke kompilaci projektů a zároveň umožnuje velmi dobře pracovat s kódem při tzv. „debugování“ tedy vyhledávání chyb v kódu. Abych mohl vyvíjet aplikaci, musel jsem stáhnout a nainstalovat databázový server od ORACLE. Aby člověk mohl použít jakýkoli produkt od této firmy a to i pouhý JDBC ovladač musí se na jejich stránkách zaregistrovat.Stáhl jsem tedy a nainstaloval db server ORACLE XE. Na tomto serveru jsem vytvořil nového uživatele VPR a do něho jsem vložil databázové tabulky, které mi laskavě poskytl pan Ing. Šípek. Jedná se o dump databáze současné aplikace elektronické přihlášky ke studiu. Dále bylo ještě nezbytné nainstalovat aplikační server, po svých zkušenostech jsem zvolil aplikační server APACHE-TOMCAT 6. Tím jsem měl sestaveno vše potřebné a mohl začít s implementací aplikace.

Implementace aplikace V prostředí ECLIPSE jsem založil nový projekt pod Mavenem, pomocí kterého projekt kompiluji do souboru pro aplikační server. V projektu jsem vytvořil adresářovou strukturu projektu a začal s implementací aplikace. Pro implementaci jsem použil jeden z javovských Frameworků nazvaný SPRING,

36

který je přímo určen pro vývoj a implementaci webových projektů pomocí technologie jsp. Při implementaci jsem se snažil dodržet zásady vývoje webových aplikací a držel se tzv. MVC (Model View Controler) modelu. To znamená, že jsem sestavil několik modelů, obsahujících jednotlivé položky formulářů, které jsou zobrazovány na jednotlivých stránkách aplikace. Tyto modely jsou volány pomocí kontrolérů, které zároveň obsahují odkazy na validátory formulářových položek. Při ukládání informací do databáze se volá jdbc ovladač ve kterém je nastaveno spojení na databázový server.

Založení nového uživatele Aplikace zobrazí stránku newUser.jsp, která obsahuje jednoduchý formulář. Tento formulář je propojen kontrolérem NewUserControler.java s modelem NewUser,java. Po odeslání dojde k validaci dat pomocí validátoru a pokud je vše v pořádku jdou data zapsána do databáze pomocí JDBC.Java.

Formulář přihlášky Formulář samotné přihlášky je vytvořen pomocí Multipage formu. Jedná se o vícestránkový formulář24, výhodou tohoto formuláře je, že jej kontroluje pouze jediný kontrolér ApplicationFormControler, tak jako je tomu u jednoduchých formulářů. Dole pod formulářem jsou umístěny tři typy tlačítek:   

_finish: (Uložit) které spustí proceduru validace a uložení formuláře _cancel: (Zrušit) které zruší či přeruší práci s formulářem _targetx: (Další, Zpět) které určují cílové stránky formuláře. Výchozí stránka má hodnotu 0.

Tento formulář funguje tak, že ukládá informace z polí do paměti kde má uloženu vazbu proměnná-hodnota a tady pokud se uživatel formulářem pohybuje vpřed či vzad zobrazuje formulář dříve vyplněné hodnoty. Jakmile

24

Viz: kniha Spring Recipes A Problém-Solution Approach kapitola 8-11.

37

uživatel přechází z jedné strany formuláře na další stranu, aplikace automaticky provádí validaci informací konkrétní části formuláře.

Načítání informací do formuláře z databáze Načítání dat do formuláře, v našem případě studijní programy a obory je řešeno pomocí AJAX skriptů. Jedná se tzv. Asynchronní Javové skripty, které se používají pro vytváření interaktivních webových aplikací. A které mění obsah svých stránek bez nutnosti jejich znovu načítání. Na rozdíl od klasických webových aplikací poskytují uživatelsky příjemnější prostředí, ale vyžadují použití moderních webových prohlížečů.

Tisk přihlášky Tisk přihlášky jsem se rozhodl realizovat pomocí XEP25. Tento systém umí provádět převody dokumentů ve formě XML do PDF či PostSciptu. K převodu potřebuje mít soubor s daty XML a informaci o transformační šabloně, která je uložena ve formátu XSL26 či XSL-FO27. Jakmile tento transformační procesor dostane potřebné informace, provede konverzi dat z XML do PDF, které vypadá tak jak je nadefinováno v transformační šabloně.

25

XEP: jedná se o formátovací stroj od společnosti RENDERX, který umí provádět konverze xml dokumentů do pdf či postskriptu. Více informací je na stránkách výrobce: http://www.renderx.com/tools/xep.html 26

XSL – eXtenzible Stylesheet Language. Jedná se o jazyk, pomocí kterého vytváříme formátovací šablony, které slouží k převodu XML dokumentů na jiné XML dokumenty či například pdf nebo postscript. 27

XSL-FO Jedná se o rozšíření XSL jazyka o tzv. formátovací objekty Jedná se o sadu speciálních objektů, které slouží k popisu textového dokumentu a které se dají použít pro náš převod.

38

Obrázek 14: Schema transformace XML do PDF

Struktura Strukturu samotné přihlášky jsem od počátku několikrát změnil. Nejprve jsem zkoušel vymyslet rozložení všech částí přihlášky nějakým rozumným způsobem. Nakonec jsem dospěl k závěru, že se mi jako ideální jeví rozložit přihlášku do pěti po sobě jsoucích záložek, které by byly tematicky seřazeny a obsahovaly všechny požadované informace v dané oblasti. Vývoj struktury přihlášky: první návrh obsahoval celkem pět záložek: 1. registraci 

registrace



login

2. osobní informace 

obecné informace



info o narození

3. kontaktní informace

39



kontakt



adresu trvalého bydliště



kontaktní adresu

4. studium 

studium na ČVUT



zdravotní postižení

5. předchozí vzdělání 

střední škola a obor



studijní výsledky



předchozí studia na VŠ

Postupem času se změna struktury přihlášky měnila tak jak se objevovaly připomínky vzešlé z připomínkování na součástech ČVUT. Takže se změnilo pořadí jednotlivých záložek a jejich obsah. Jako první se vyprofilovala záložka studia, ze které zmizela část dotazníku na zdravotní postižení uchazeče. Naopak registrace byla začleněna jako druhá, zbytek zůstal víceméně beze změn. Během návrhu struktury byly do přihlášky zakomponovány všechny informace, které jsou požadovány systémem SIMS a UIV. Dále informace, které jednotlivé součásti ČVUT považovaly za povinné.

Příklady užití Zde bych rád uvedl některé případy užití přihlášky. Případy užití byly vytvořeny podle knihy Writing Effective USE CASES (USE CASES – Jak efektivně modelovat aplikace) od Alistaira Cockburna. Tento autor popisuje případy užití formou textu a nikoli obrázků. Neboť tato forma zápisu umožňuje snadno porozumět této části návrhu všem a nikoli jen specialistům z oboru. Jedná se o konkrétní případy užití nové přihlášky. V těchto případech, je definován postup, jak by měl uživatel procházet jednotlivé části formuláře. Tyto případy definují vstupní a výstupní podmínky pro úspěšný průběh každého jednotlivého případu.

40

UC Registrace Rozsah: Registrace do systému Úroveň: uživatelský cíl Aktér: Zájemce o studium Uživatelé a zájmy: Zájemce os studium je rozhodnut pro studium na ČVUT a chce se zaregistrovat k vyplnění přihlášky. Systém chce založit uživatele, aby bylo možno zajistit bezpečný přístup opravdového zájemce k přihlášce a zajištění bezpečnosti jeho osobních dat. Vstupní podmínky: Zájemce musí mít přístup k internetu a musí disponovat aktivním emailovým účtem Minimální záruky: existující minimální přihlašovací informace aby byl systém schopen detekovat zájemce jako registrovaného uživatele či detekovat chyby vzniklé při pokusu o přihlášení. Záruka úspěchu: funkční databáze na serveru ČVUT, která eviduje všechny registrované uživatelé systému.

Hlavní úspěšný scénář: 1.

systém zobrazí stránku pro registraci s formulářem a textem (T1)

2.

Zájemce vyplní volbu studoval jsem* na ČVUT

3.

Zájemce vyplní registrační formulář

4.

Systém přesměruje zájemce na stránku s přihlášením

Rozšíření: *a. jazykové mutace aplikace zatím pouze CZ/EN uživatel má možnost vybrat si jazyk přímo v aplikaci. *b. Uživatel má možnost se z aplikace kdykoli odhlásit

41

*c.

pod uvítacím textem je zobrazen dotaz na současné studium na ČVUT a pod ním registrační formulář

*2a. Zájemce potvrdí volbu studuji studoval jsem 2a1. Systém upraví formulář a dotáže se na username 2a2. Zájemce vyplní username a potvrdí volbu odeslat 2a3. Systém ověří username proti SSU 2a3.1. Systém nalezl shodu 2a3.1.1. Systém zobrazí text (T2). 2a3.1.2. Systém založí uživatele v DB 2a3.2. Systém nenalezl shodu 2a3.2.1. Systém zobrazí text (T3) 2b. Zájemce nepotvrdí volbu 2b1. Systém ponechává zobrazen původní formulář a text.

3a. Zájemce nestuduje /nestudoval na ČVUT či nebyl ověřen 3a1. Systém zobrazí pole (email, heslo, captcha) 3a2. Zájemce vyplní formulář 3a3. Systém provede validaci formuláře (UC – Validace reg. formuláře) 3a3.1. Formulář je validní 3a3.1.1. Systém odešle na email zájemce reg. Klíč 3a3.1.2. Systém zobrazí zprávu (T4). 3a3.1.3 Systém uloží zájemce do DB. 3A3.2. Formulář není validní

42

3a3.2.1 Systém požádá o opětovné vyplnění formuláře

* rozšíření o identifikaci studentů ČVUT není v současné verzi podporováno. Jeho zavedení bude doplněno jako rozšíření v návaznosti na IS. Zobrazené texty a zprávy: T1:

Vážený zájemče o studium,

k vyplnění a uložení Vaší přihlášky je nutná registrace do našeho systému. Jinak nebudeme schopni zaručit Vám uložení a opětovné nahrání Vaší přihlášky. Pro provedení registrace zadejte do níže připraveného pole Váš aktivní email a potvrďte volbu „odeslat“. Po zpracování vám náš systém automatiky odešle na zadaný email registrační klíč, který použijete při přihlášení do systému.

T2:

Vážený uživateli,

Vaše identita byla úspěšně ověřena, pokračujte prosím přihlášením do systému.

T3:

Vážený uživateli,

Vaše identita nebyla úspěšně ověřena. Žádáme Vás o vyplnění níže uvedeného formuláře. T4: Děkujeme Vám za registraci do našeho systému, na Váš email byla odeslána zpráva s registračním klíčem.

Tento případ užití byl dosti jednoduchý, proto zde uvedeme jeden trošku rozsáhlejší

43

UC předchozí vzdělání Rozsah: Vyplnění formuláře část předchozí vzdělání Úroveň: Uživatelský cíl Primární aktéři: Uživatel systému Uživatelé a zájmy: Uživatel má zájem vyplnit formulář přihlášky. Systém načítá hodnoty do formulářů a u avlidovaných položek provádí validace a zobrazuje následující možnosti splňující uvedené podmínky. Po vyplnění formuláře a odeslání systém ukládá vyplněnou kombinaci do DB. Vstupní podmínky: uživatel zná své registrační údaje a musí být zaregistrován do systému. Minimální záruky: Záruka úspěchu: funkční databáze na serverech ČVUT, ve kterých jsou vedena zobrazovaná data a registrovaní uživatelé systému.

Hlavní úspěšný scénář: 1. Systém zobrazí uživateli stránku s patřičnou částí formuláře 2. systém ověří vybraný „typu studia“ a vybere, které položky ve formuláři zobrazí jako aktivní a které nikoli. 1. bakalářské studijní obory 1. systém ověří dle státní příslušnosti, o kterého studenta se jedná a nabídne číselníkové položky vybraných atributů nebo je nechá jako volná pole k vyplnění 2. systém nabídne pole „kód střední školy“ 1. číselníková hodnota 2. volné pole 3. uživatel vybere/vyplní pole „kód střední školy“ 4. systém nabídne pole „kód oboru na SŠ“ 1. číselníková hodnota 2. volné pole

44

5. uživatel vybere/vyplní pole „kód oboru na SŠ“ 6. systém nabídne pole rok maturity 1. číselníková hodnota 7. 8. uživatel vybere/vyplní položku „rok maturity“ 9. uživatel vyplní položku „ročníkové průměry“ 10. systém ověří dle vybrané fakulty požadované předměty a zobrazí patřičné položky 11. uživatel vyplní požadované předměty 12. systém se dotáže na předchozí VŠ 13. systém provede kontrolu položky 1. zpřístupní pole poslední VŠ, rok absolvování VŠ, akademický titul 1. systém nabídne pole „poslední VŠ“ 2. systém nabídne pole „rok absolvování VŠ“ 3. systém nabídne pole „akademický titul“ 4. uživatel vyplní pole „poslední VŠ“ 5. uživatel vyplní polle „rok absolvování VŠ“ 6. uživatel vyplní pole „akademický titul“ 2. systém nezpřístupní položky

1. magisterské navazující a doktorské studijní obory 1. systém ověří dle státní příslušnosti, o kterého studenta se jedná a nabídne číselníkové položky vybraných atributů nebo je nechá jako volná pole k vyplnění 2. systém nabídne pole „poslední VŠ“ 3. systém nabídne pole „rok absolvování VŠ“ 4. systém nabídne pole „akademický titul“ 5. uživatel vyplní pole „poslední VŠ“ 6. uživatel vyplní polle „rok absolvování VŠ“

45

7. uživatel vyplní pole „akademický titul“ 2. uživatel zvolí možnost „tisk přihlášky“ 3. uživatel zvolí „uložit přihlášku“ 4. systém zobrazí stránku s potvrzením souhlasu se zpracováním osobních dat s možností „ANO/NE“

Rozšíření: 2. kontrola položky „typ studia“ 1. typ studia „bakalářský “ 2. typ studia „magisterský navazující“ 3. typ studia „doktorský“ 2.1.2 „kód střední školy“ 1. jestliže Státní příslušnost = ČR pak systém zobrazí výběr z číselníku 2. jestliže Státní příslušnost ≠ ČR pak systém zobrazí volné pole 2.1.3 „kód oboru na SŠ“ 1. jestliže Státní příslušnost = ČR pak systém zobrazí výběr z číselníku 3. jestliže Státní příslušnost ≠ ČR pak systém zobrazí volné pole 2.1.9 známky z předmětů 1. FEL 1. Matematika 2. Fyzika 3. Informatika 2. FS 1. v přihlášce z měsíce 06/09 nepožaduje

46

3. FJFI 1. Matematika 2. Fyzika 3. Chemie 4. Informatika/Výpočetní technika 5. Angličtina 4. FD 1. v přihlášce z měsíce 06/09 nepožaduje 5. Fsv 1. Matematika 2. Fyzika 6. FA 1. v přihlášce z měsíce 06/09 nepožaduje 7. FBMI 1. Matematika 2. Fyzika 3. Biologie 4. Infoematika (pouze u oboru Optika a optometrie) 8. FIT 1. Matematika 9. MÚVS 1. v přihlášce z měsíce 06/09 nepožaduje 2.1.11 „studoval jste nějakou vysokou školu“ 1. jestliže je potvrzeno „ANO“ systém zpřístupní následující pole k vyplnění 1. „poslední VŠ“ 2. „rok absolvování VŠ“ 3. „akademický titul“ 2. jestliže není potvrzeno „ANO“ systém nechá položky nedostupné

47

2.2.2 systém ověří státní příslušnost a nabídne možnosti: 1. jestliže Státní příslušnost = ČR pak systém zobrazí výběr z číselníku 2. jestliže Státní příslušnost ≠ ČR pak systém zobrazí textové pole 3. „tisk přihlášky“ Zde bude vytvořen samostatný systémový UC – Tisk

5. „souhlas s § 4 odst. b) zákona č. 101/2000 Sb.“ 1. uživatel zvolí „ANO“ 1. systém uloží přihlášku do DB, zapíše časovou značku a zobrazí hlášení (T1) 2. systém zobrazí hlášení „přihláška + „kód přihlášky“ + uložena“ 2. uživatel zvolí „NE“ 1. systém zobrazí varování (Z1) 1. systém nabídne znovu možnost souhlasu „ANO/NE“ 1. uživatel zvolí „ANO“ 1. systém uloží přihlášku do DB, zapíše časovou značku a zobrazí hlášení (T1) 2. systém zobrazí hlášení: „přihláška + „kód přihlášky“ + uložena“ 1. uživatel zvolí „NE“ 2. systém zobrazí hlášení (T2) 2. f

Zobrazované texty a zprávy:

48

T1 – Děkujeme Vám ... (poděkování za důvěru atd.) T2 – Je nám velice líto, ale Vámi vyplněná přihláška nebyla uložena a veškeré Vámi vyplněné informace byly vymazány. Z1 – Je nám líto, ale bez Vašeho souhlasu nemůžeme ukládat Vaše informace k dalšímu zpracování. Nebudete se moci k přihlášce vrátit a jakkoli s ní manipulovat neboť veškerá data budou smazána. Nechcete si svoji volbu rozmyslet?

Použitá technologie Jasným problémem se ukázalo použití původní technologie, která je již dnes naprosto nevyhovující.

Technologie stránek Aplikace jsem navrhl postavit na technologii JSF či JSP. Tato technologii se mi jeví jako perspektivní.

JSF Java Server Faces je komponentově orientovaný webový rámec (pull-based), je tedy jiného typu než klasický přístup Struts či Stripes. V klasickém pojetí je stránka obsluhována jako celek, je zde velký důraz na usnadnění obsluhy paradigmu HTTP Request-Response. Komponentový přístup JSF deleguje obsluhu stránky jako takové na jednotlivé komponenty, které si svoje místečko na webové stránce obhospodařují samy. JSF, stejně jako většina webových frameworků, je postaveno na Servlet API a JSP. JSP jako view vrstva může být ovšem nahrazena prakticky čímkoliv. Pro JSP jsou k dispozici dvě knihovny značek (taglib). Jednou z nejčastěji kritizovaných vlastností JSF je obecnost, se kterou lze v JSF vyměnit prakticky kteroukoliv podčást za jinou. Ve spojení s jednoduchostí použití (o což se JSF snaží) je pod povrchem JSF schováno hodně kódu, který je těžké pochopit a při chybě těžké opravit.

49

Výhody (proč ano):     

tzv. "standard", tj. je součástí Java EE podpora od výrobců vývojových nástrojů efektivní při základním použití dostatek dokumentace v rámci komunity používané <==> vyžadováno sw společnostmi

Nevýhody (proč ne):    

je nutné doplnit o dva další frameworky (Seam, Facelets) aby bylo použitelné komplikované až těžkopádné při snaze využít specialitek JSF renderery si musí vypomáhat JavaScriptem navigace je založena jen na POST

Dále bychom mohli rozebrat celý systém funkce JSF. Pro JSF existuje jeden obslužný servlet FacesServlet, který zajišťuje, že všechny komponenty projdou definovaným životním cyklem během života HTTP požadavku. Pro jednoduchý náhled můžeme dále uvažovat již jen o životním cyklu a o komponentách.

JSP Jedná se o technologií JavaServer Pages, založenou na Javě, která umožňuje vývoj dynamických webových stránek. JSP vyvinula společnost Sun Microsystems, za účelem vývoje aplikací na straně serveru. JSP soubory jsou vlastně HTML stránky, do kterých jsou vloženy speciální tagy obsahující javovský zdrojový kód. Tento kód potom vytváří dynamický obsah stránky. To znamená, že se napíše HTML dokument způsobem a s pomocí stejných nástrojů jako doposud. Potom se vytvoří a uzavře do speciálních značek (tagů <% %>) kód určený pro dynamickou část. Použiť JSP je vhodné hlavně tehdy, když většinu stránky tvoří statický obsah. V opačném případě je vhodné použít na vytvoření stránek technologii servletů.

50

Princip činnosti Zdrojový kód stránky JSP je překládaný na servlet a následně kompilovaný. Výsledkem je servlet, který generuje HTML. Ten je poslán klientovi, jako odpověď na jeho požadavek. Na této jednoduché stránce je vidět propojenost klasického HTML a Java kódu, uzavřeného mezi tagy <%= a %>. Příkaz new java.util.Date() vytvoří instanci třídy Date a vloží ji do stránky. <TITLE>Dnešní datum. Dnešní datum:
<%= new java.util.Date() %>

Výhody JSP Oddělení statické části od dynamického obsahu má řadu výhod, dokonce i proti technologii servletů. Přístup, který se používá na stránkách JSP nabízí několik výhod i v porovnání s konkurenčními technologiemi, například ASP, PHP, ColdFusion, CGI, SSI atd. Výhodou JSP proti ASP je, že dynamická část je napsaná v Javě, oproti VBScriptu nebo jinému jazyku určenému pro ASP. Java je komplexnější, robustnější a bezpečnější jazyk, který se hodí na tvorbu znovu použitelných komponent. A dále, Java je přenositelná, znamená to, že nejste limitování použitým operačním systémem nebo serverem. Výhoda JSP proti PHP znovu spočívá v tom, že JSP jsou psané v Javě, kterou většina programátorů zná, anebo se s ní alespoň setkala během výuky na některé z vysokých škol. Java nám poskytuje rozsáhlé třídy na práci se sítí, databázemi, elektronickou poštou atd. Výhody JSP proti Servletom - JSP nedokáže nic, co by se nedalo v podstatě vyrobit i pomocí servletů. Ve skutečnosti to však funguje tak, že stránka JSP se nejdříve automaticky přeloží do servletu. A až tento servlet je potom vykonáván na straně serveru. Jak již bylo uvedeno výše v případě, že se nemění kompletně obsah celé stránky, ale je vhodnější použít JSP. Výhodou je, že oddělím prezentaci od dynamického obsahu.

51

XEP Jedná se o převodník, který je založen na užití tzv. formátovacích objektů. Ty umožňují specifikovat transformaci výchozího XML souboru do stránkového popisu, který vyhovuje i náročnějším typografickým požadavkům. K převodu do tohoto popisu neslouží samotný program XEP, existuje však pro něj poměrně dost jiných produktů, a to i třídy freeware. Možnosti použití tohoto převodníku jsou velmi široké Proto se mi tento systém jeví jako velmi vhodný pro podobné využití. Tedy jako jakýsi centrální systém, který je vybaven seznamem šablon, které zahrnují nejen tiskové výstupy z aplikace elektronické přihlášky, ale i ostatních systémů, A kterému stačí dodat vstupní data ve formátu XML. Který je schopen zaručit, že všechny vytištěné formuláře budou stejné. Tento systém je od výrobce vybaven systémem doplňkových modulů, které rozšiřují jeho možnosti. Mezi nejrozšířenější patří moduly k transformaci XML dat pomocí XSL-FO šablon do formátu PDF. V blízké budoucnosti by měl XEP podle informací výrobce zajišťovat výstup do řady dalších formátů, jako například PostScript, HTML či PCL.

Tomuto systému aplikace po stisknutí příslušného tlačítka odešle všechny informace potřebné k vytištění formuláře elektronické přihlášky. V záhlaví dokumentu je zároveň nastaveno, kterou šablonu je třeba použít, abychom dostali požadovaný výstup. Výsledkem odeslání dat na tiskový procesor spolu se specifikací výstupu je odpověď serveru ve formě PDF či PS dokumentu, Standardně je používána transformace do PDF. Který se ukládá na serveru a je zároveň odeslán, jako odpověď na žádost z počítače na kterém je vyplňována přihláška. Uživatel tedy obdrží jako výsledek PDF dokument, který obsahuje veškerá data jako univerzální formulář papírový. Jediným rozdílem je návrh grafického designu, který jsem vytvořil a který byl prezentován p. Ing Kalikou na schůzce proděkanů a jako takový byl schválen. Níže je připojen zdrojový kód XSL-FO šablony tak jak byla navržena, odzkoušena a v konečném důsledku prezentována. Součástí je i XML struktura plnící XSL šablonu. Pro představu uvedu podobu grafického výstupu.

52

Obrázek 15: Návrh Grafického výstupu v2

Další modifikace výstupu, které jsou zakotveny v kódu XSL šablony, jakož i vstupní soubory jsou součástí příloh.

53

Kapitola 5 Testování Aplikace byla testována pouze na lokálním počítači. Z toho vyplývají jistá omezení při testování aplikace. Velká část testování aplikace probíhala při samotném vývoji a ladění aplikace, kdy docházelo k pádům aplikace z různých důvodů. Většinou se jednalo o chyby při ukládání dat do tabulky TPRPRIHL, neboť jsem musel přizpůsobit formát jednotlivých ukládaných atributů skutečnému stavu. Během procesu ladění ukládání atributů se mi podařilo odladit všechny problémy s ukládáním. Problém s ukládáním se projevil nejvíce u číselníkových položek v adresách, které bohužel nemám k dispozici a které jsou velikostně omezeny formátem číselníku. V rámci testování bylo vyzkoušeno, jak aplikace funguje a zda nedochází k pádům aplikace v důsledku špatných směrování při načítání jednotlivých stránek. Což se neprojevilo. Dále bylo testováno zakládání nových uživatelů, a to jak vyplnění formuláře, jeho validace tak i zpětná kontrola databáze, zda byli uživatelé skutečně vytvořeni. Přihlašování uživatelů a ověřování jejich identit se dělo prakticky po celou dobu vývoje aplikace, neboť jsem aplikaci po každé změně v kódu musel znovu zkompilovat a přihlašovat se jako uživatel pokud jsem chtěl vyplňovat přihláškový formulář. Testování pokračovalo zkoušením vyplnění formuláře přihlášky, schopností uchovávat data při procházení formulářem vpřed i vzad. V databázi bylo kontrolováno, zda aplikace ukládá data do tabulky TPRPRIHL. Rovněž bylo testováno načítání dat z tabulek TOBORY, TPROGRAMY, které obsahují informace o studijních oborech a programech.

54

Stabilitu aplikace v případě zatížení velkým počtem současných přístupů nebylo možné ověřit, neboť jsem nebyl schopen simulovat současný přístup více uživatelů.

Srovnání se současnou přihláškou V porovnání se současnou verzí přihlášky působí prototyp poněkud strohým a nepřitažlivým dojmem. Formulář je zobrazen jako statický a načítají se do něj jen některá data z číselníků. Na rozdíl od současné přihlášky, která vypadá velmi svěže a jejíž formulář je sestaven jako dynamický. Současná verze prototypu neobsahuje v plném rozsahu textové nápovědy, které jsou podstatnou součástí formuláře přihlášky. Vzhledem k tomu, že obě aplikace ukládají data do stejné tabulky, lze snad tvrdit, že aplikace fungují velmi podobným způsobem.

55

Kapitola 6 Závěr V rámci tvorby aplikace jsem dosáhl a splnil cíle, které jsou v zadání bakalářské práce. Prototyp aplikace umožňuje přihlašování k aplikaci včetně kontroly přihlašovacích údajů. Aplikace umožnuje vytvořit nového uživatele pomocí formuláře, kde nový uživatel vyplní údaje nezbytné pro přihlášení k aplikaci. Aplikace umožnuje vyplnit formulář přihlášky a uložit jej do databáze. Umožňuje rovněž úpravu neodeslaných přihlášek a zamezuje úpravě přihlášek označených jako odeslané. Náročnost a rozsah aplikace je velmi široký a vytvořit zcela bezchybnou aplikaci, která by splňovala všechny představy uvedené ve struktuře přihlášky, není možné z časových důvodů realizovat. Zvláštní pozornost by si zasloužil design přihlášky, který je samostatnou kapitolou. Nejde zde jen o využití základního rámce, který je dán grafickým manuálem ČVUT a korporátním vzhledem aplikací. Myslím, že tvorba designu přihlášky by si zasloužila spolupráci s lidmi, kteří se profesionálně zabývají designem. Z této spolupráce by jistě vznikl zajímavý a poutavý design, kterým by bylo možné přihlášku oživit. Rovněž by se dalo využít množství číselníků, které by oživily formuláře. Přínosem této práce je odzkoušení perspektivních technologií, které jsou schopny oddělit jednotlivé vrstvy webové aplikace. Mám na mysli vrstvu presentační, vrstvu aplikační logiky a vrstvy, která pracuje s daty, ve smyslu dodržení struktury MVC. Bylo by tedy možné, vytvořit celou aplikaci Epřihlášky jako nezávislý modul či jako jednu ze součástí celého informačního systému, která by byla nezávislá na používané technologii či verzích databází. Rovněž si myslím, že správa a úpravy takovéto aplikace by byly jednodušší. Nebyl by například problém, upravit prezentační vrstvu a přizpůsobit ji tak na míru představám, aniž by se musely nějakým způsobem upravovat ostatní části aplikace. Samozřejmě má i toto řešení svá úskalí. Jazyk Java disponuje zvláště ve verzi EE (Enterprise Edition) mnoha součástmi, které mají specifické určení a které vyžadují dobré znalosti konkrétní části Nelze tak s jistotou tvrdit, že člověk, který programuje v Javě, bude znát použitý Framework. Rovněž přehlednost aplikace je trochu složitější, neboť se jedná množství malých

56

souborů, které se na sebe navzájem odkazují a různě spolu spolupracují. Já sám jsem s touto technologií zvláště s frameworkem SPRING přišel do kontaktu poprvé. Již jsem pracoval s technologií servletů, ale toto je pro mne zcela nová zkušenost, která mi přinesla mnoho pozitivních zkušeností s vývojem webových aplikací a zvláště se strukturou MVC. Jsem rád, že se mi podařilo vytvořit aplikaci a rád bych ji rozšířil do plného rozsahu v navazujícím magisterském studiu.

57

Literatura BARTÍK, V., JANEČKOVÁ, E. Zákon o ochraně osobních údajů s komentářem. Praha, ANAG 2010, 1. vyd. ISBN: 978-80-7263-613-6. COCKBURN, A. USE CASES – Jak efektivně modelovat aplikace. CP Books, Brno, 1st edition, 2005. In Czech. 262 s. ISBN: 80-251-0721-3. SCHELLE, K.; ŠMÍD, V. Rodné číslo v informačních systémech. Právní rádce: Měsíčník hospodářských novin, Praha, 2004. Vol. XII, no. 11, s. 44-47. ISSN: 1210-4817. ŠMÍD. V. Geneze zákona č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů. Brno, 2004. Masarykova univerzita v Brně, s. 45. ŠMÍD. V. Ostatní právní prostředky ochrany dat. Computerworld, Praha: International Data Group, 1997, 20. Seriál Bezpečnost pro všechny. soukromí pro každého. ISSN: 1210-9924, s. 1-4. ŠMÍD. V. Právní režim informačních systémů obsahujících osobní údaje. In: Tvorba softwaru 2003. Sborník příspěvků. Ostrava, 2003. TANGER, s. r. o. ISBN: 80-85988-84-6, s. 196-206. ŠMÍD. V. Zákon o ochraně osobních údajů na vysokých školách. In: EUNIS´2001. Sborník příspěvků. Nečtiny, 2001. EUNIS-CZ. s. 1-6.

Odkazy: http://tomcat.apache.org/ http://glassfish.java.net/ http://www.renderx.com/ http://is.cuni.cz/studium/login.php http://newportal.upol.cz/wps/myportal/prihlaska/ http://is.muni.cz/prihlaska http://isis.vse.cz/prihlaska/

58

https://is.ujak.cz/prihlaska.php

59

Přílohy Příloha č. A – Seznam použitých zkratek Příloha č. B – UML diagramy Příloha č. C – Instalační a uživatelská příručka Příloha č. D – PDF dokument Eprihlaska_v01 Příloha č. E – PDF dokument Eprihlaska_v01bakalar bez VS Příloha č. F – PDF dokument Eprihlaska_v01bakalar s VS Příloha č. G – PDF dokument Eprihlaska_v01Doktor Příloha č. H – PDF dokument Eprihlaska_v01Magistr z VS Příloha č. CH – XML soubor Eprihlaska_v01 Příloha č. I – XSL šablona eprihlaska_v02 Příloha č. J – XSL šablona eprihlaska_v03 Příloha č. K – Podklady pro grafiku v3 Příloha č. L – Obsah přiloženého CD

60

Příloha A Seznam použitých zkratek AJAX Asynchronous JavaScripts and XML API Aplication Programing Interface ASP Active server pages CGI Common Gateway Interface ČVUT České vysoké učení technické DB data base EJB Enterprise java beans HCI Human computer interaction IBM International Bussines Machines Corporation IS Informační systém JDBC Java Database Connectivity JSP Java server pages JSF Java server faces KOS Komponenta studium MŠMT Ministerstvo školství, mládeže a tělovýchovy MVC Model View Controler PCL Point Cloud Library PDF Portable Document Format PHP Hypertext Preprocessor SIMS databáze Sdružených Informací matrik studentů

61

SSI Server side includes TUL Technická univerzita v Liberci UC use case UIV Ústav pro informace ve vzdělávání UJAK Univerzita Jana Amose Komenského VB Script Visual Basic Scripting Edition VŠFS Vysoká škola finanční správní VUT Vysoké učení technické XML Extensible Markup language XSL Extensible Stylesheet Language XSL-FO Extensible Stylesheet Language Formating Objects ZČU Západočeská univerzita v Plzni

62