Technická univerzita v Liberci
FAKULTA PŘÍRODOVĚDNĚ-HUMANITNÍ A PEDAGOGICKÁ
Katedra: Ústav nových technologií a aplikované informatiky Studijní program: M7503 Učitelství pro základní školy
Studijní obor Učitelství informatiky pro 2. stupeň základní školy
Informační systém pro evidenci zkoušek Exam information system
Diplomová práce: 12-FP-NTI-001
Autor: Podpis:
Petr Bechyně
Vedoucí práce: Mgr. Milan Keršláger
Počet
stran grafů obrázků tabulek pramenů příloh
96 0 27 3 20 1
V Liberci dne 27. 4. 2012
Podepsané zadání
Čestné prohlášení
Název práce: Informační systém pro evidenci zkoušek Jméno a příjmení autora: Petr Bechyně
Osobní číslo: P06100313
Byl/a jsem seznámen/a s tím, že na mou diplomovou práci se plně vztahuje zákon č. 121/2000 Sb. o právu autorském, právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon), ve znění pozdějších předpisů, zejména § 60 – školní dílo.
Prohlašuji, že má diplomová práce je ve smyslu autorského zákona výhradně mým autorským dílem.
Beru na vědomí, že Technická univerzita v Liberci (TUL) nezasahuje do mých autorských práv užitím mé diplomové práce pro vnitřní potřebu TUL.
Užiji-li diplomovou práci nebo poskytnu-li licenci k jejímu využití, jsem si vědom povinnosti informovat o této skutečnosti TUL; v tomto případě má TUL právo ode mne požadovat úhradu nákladů, které vynaložila na vytvoření díla, až do jejich skutečné výše.
Diplomovou práci jsem vypracoval/a samostatně s použitím uvedené literatury a na základě konzultací s vedoucím diplomové práce a konzultantem.
Prohlašuji, že jsem do informačního systému STAG vložil/a elektronickou verzi mé diplomové práce, která je identická s tištěnou verzí předkládanou k obhajobě a uvedl/a jsem všechny systémem požadované informace pravdivě.
V Liberci dne: 27. 4. 2012
Petr Bechyně
Poděkování
Mgr. Milanu Keršlágerovi patří největší osobní poděkování za odborné vedení a lidský přístup, bez něhož by práce nemohla vzniknout.
Dále děkuji své rodině, partnerce, mým přátelům a kolegům za podporu, čas a prostor, který mi během vytváření této diplomové práce poskytli.
Anotace
Cílem této diplomové práce je vytvoření evidence zkoušek pro vyšší odborné školy včetně návrhu aplikace, databázového modelu, autentizace uživatelů a otestování funkčnosti portálu. Byla zvolena realizace formou webové aplikace, která je pro dané použití nejvhodnější. K zobrazení a používání aplikace není třeba instalace žádných klientských programů ani doplňků, a postačí jakýkoliv prohlížeč webových stránek.
Díky tomu lze aplikaci používat na různých operačních systémech i na mobilních zařízeních a tabletech.
Obsahem webové aplikace je pak správa jednotlivých předmětů v daném školním roce, vypisování termínů zkoušek, přihlašování studentů na zkoušky a následné hodnocení v podobě udělování zápočtů a známek. Aplikace rozlišuje různé úrovně uživatelského přístupu a přiděluje jim příslušná oprávnění. Další funkcí aplikace je generování rozvrhů pro jednotlivé ročníky a přehledů předchozího studia studenta.
Klíčová slova
Evidence zkoušek, tvorba webové aplikace, přihlašování studentů na zkoušky, evidence hodnocení studentů, generování rozvrhů.
Summary
The aim of this thesis is to create exam information system for Further Education College including application and project plan, database model, user authorisation and usability tests. The application is in a form of online website, which is suitable for the purpose. There is no need of additional software or plugin at client’s side and the application is rendered in any internet browser so that it could be accessed from mobile devices or tablets and from any operating system.
The application consists of semester administration, which is represented in different subjects, exams registry, student enrolment and evaluation. There are several levels of user access with appropriate permissions. The application also generates timetables for different school years and provides an overall summary of student’s study career.
Keywords
Exams registry, web application, online data access, student enrolment, student assessment registry, timetable generator.
Obsah
Seznam použitých zkratek a symbolů ... 10
1. Úvod ... 13
2. Návrh aplikace ... 14
2.1 Návrh uživatelského rozhraní ... 14
2.1.1 Volba výstupního formátu aplikace ... 14
2.1.2 Návrh layoutu stránek ... 18
2.1.3 Návrh obsahu stránek ... 20
2.1.4 Koncept formulářových tabulek ... 22
2.1.5 Konkrétní řešení problémů uživatelského rozhraní ... 23
2.2 Návrh aplikační úrovně ... 26
2.2.1 Volba vhodné platformy ... 26
2.2.2 Volba serverového skriptovacího jazyka ... 27
2.2.3 Klientský skriptovací jazyk ... 48
2.3 Návrh databázového modelu ... 52
2.3.1 Volba databázového systému ... 52
2.3.2 Specifika MySQL databáze ... 53
2.3.3 Relační databáze ... 54
3. Autentizace a uživatelské přístupy ... 63
3.1 Způsob záznamu uživatelské informace ... 63
3.1.1 Cookies a Sessions ... 64
3.1.2 Specifika SESSIONS ... 65
3.2 Algoritmus přihlášení ... 65
3.2.1 Způsob ukládání hesel ... 70
4. Kontrola provedených změn ... 71
4.1 Obsah záznamu ... 71
4.2 Způsob evidování změn ... 71
4.3 Kontrola operací v reálném čase ... 72
5. Přístupnost a použitelnost online aplikace ... 75
5.1 Obsah webových stránek je dostupný a čitelný ... 75
5.2 Práci s webovou stránkou řídí uživatel ... 76
5.3 Informace jsou srozumitelné a přehledné ... 77
5.4 Ovládání webu je jasné a pochopitelné ... 77
5.5 Kód je technicky způsobilý a strukturovaný ... 79
5.6 Prohlášení o přístupnosti webových stránek ... 80
6. Popis hotového řešení ... 81
6.1 Veřejná část ... 81
6.1.1 Úvodní stránka ... 81
6.1.2 Přihlášení do systému ... 81
6.1.3 Přehled rozvrhů ... 82
6.2 Přihlášený uživatel ... 83
6.2.1 Pracovní plocha ... 83
6.2.2 Nastavení uživatele ... 83
6.3 Specifika rozhraní pro správce ... 84
6.3.1 Správa předmětů ... 84
6.3.2 Správa termínů zkoušek ... 85
6.3.3 Zadávání známek ... 85
6.3.4 Správa uživatelských účtů ... 86
6.3.5 Správa semestrů ... 87
6.3.6 Správa rozvrhů ... 87
6.4 Specifika rozhraní pro učitele ... 88
6.5 Specifika rozhraní pro studenty ... 88
6.5.1 Předměty ... 88
6.5.2 Termíny zkoušek ... 89
7. Uživatelské testování ... 90
7.1 Výstupy z uživatelského testování ... 91
8. Závěr ... 92
8.1 Zhodnocení technického zpracování ... 92
8.2 Možnosti dalšího vývoje ... 92
9. Seznam použitých zdrojů ... 93
10. Seznam použitých obrázků ... 95
11. Přílohy ... 96
Seznam použitých zkratek a symbolů
.NET Dotnet je zastřešující název pro soubor technologií pro web na platformě Microsoft Windows
AJAX Z anglického Asynchronous Javascript and XML. Obecné označení pro technologie vývoje interaktivních webových aplikací, které mění části obsahu svých stránek bez nutnosti jejich opětovného načítání.
ASP Active Server Pages je skriptovací platforma společnosti Microsoft, primárně určená pro dynamické zpracování webových stránek na straně serveru.
CGI Common Gateway Interface je protokol pro propojení externích aplikací s webovým serverem.
CSRF Cross-site Request Forgery je jedna z metod útoku do internetových aplikací
CSS Z anglického Cascading Style Sheets. Kaskádové styly jsou jazykem pro popis způsobu zobrazení stránek napsaných v jazycích HTML, XHTML nebo XML.
DOM Z anglického Document object model, je objektově orientovaná reprezentace XML nebo HTML dokumentu.
DTD Z anglického document type description, tedy norma pro zápis určitého typu dokumentu.
FOREACH Řídící struktura počítačového programu, která při své činnosti postupně projde všechny prvky v poli, uvedeném jako argument.
GET Dotazovací metoda HTTP protokolu pro získání webové stránky ze serveru, která využívá URI dokumentu.
HTML Z anglického HyperText Markup Language, tedy značkovací jazyk pro hypertext.
HTTP Z anglického HyperText Transfer Protocol je protokol v sítí internet, původně vytvořený pro výměnu
hypertextových dokumentů ve formátu HTML.
JAVA Objektově orientovaný programovací jazyk vyvíjený firmou Sun Microsystems od roku 1995.
JRE Zkratka pro Java Runtime Environment, tedy běhového rozhraní potřebné ke spouštění programů a skriptů v jazyce Java.
JS Zkratka pro JavaScript, objektově orientovaný skriptovací jazyk pro tvorbu klientských skriptů.
JVM Zkratka Java Virtual Machine pro sadu počítačových programů a datových struktur, která využívá modul virtuálního stroje ke spuštění počítačových programů a skriptů vytvořených v jazyce Java.
MVC Zkratka model-view-controller pro architekturu softwaru často používanou pro webové aplikace.
Podrobně vysvětlená je v kapitole 2.2.2.3.
PERL Perl je interpretovaný programovací jazyk pro tvorbu CGI skriptů.
PHP Rekurzivní zkratka z anglického Hypertext Preprocessor pro skriptovací programovací jazyk.
POST Dotazovací metoda HTTP protokolu pro získání webové stránky ze serveru, využívající metaproměnných
z webového formuláře.
PYTHON Python je dynamický objektově orientovaný skriptovací programovací jazyk.
URL Z anglického Uniform Resource Locator je řetězec znaků s přesně definovanou strukturou,
který slouží k identifikaci umístění dokumentů či služeb na internetu.
VBScript Je akronym pro skriptovací jazyk Microsoft Visual Basic Scripting Edition pro vkládání kódu do webových stránek.
WYSIWYG Je akronym anglického What you see is what you get, tedy způsobu editace dokumentů, při které je zobrazena vzhledově totožná verze s výslednou podobou dokumentu.
XHTML Z anglického Extensible Hypertext Markup Language, což je rozšířená verze jazyka HTML.
XML Z anglického Extensible Markup Language je obecný značkovací jazyk pro serializaci dat.
XSS Je označení pro Cross-site scripting, což je metoda narušení webové stránky či aplikace využitím bezpečnostních mezer ve skriptech.
1. Úvod
Během zkouškového období na vyšších odborných školách vzniká potřeba evidovat různé údaje jako například vypsané termíny či seznamy jmen studentů, kteří se na ně přihlásili. Před rozvojem elektronických evidencí se termíny zkoušek zveřejňovaly na vývěsce v budově školy a studenti se tak museli osobně dostavit pro zápis na termín zkoušky či jeho dodatečné vyškrtnutí. Aktuální přehled o termínech mimo prostor školy, například z domova, pak chyběl úplně.
Z těchto důvodů vznikla celá řada online aplikací, které tyto problémy řeší, a které jsou již hojně využívány na vysokých či některých vyšších odborných školách.
Tyto aplikace sice obsahují celou řadu přidružených funkcí, ale často bývají pro potřebu vyšší odborné školy příliš komplikované a představují v rozpočtu menší školy nezanedbatelnou částku, a to nejen na pořízení, ale i provoz. Další problémy jsou spojeny s údržbou serveru, pokud se škola stará o hostování aplikace sama.
Cílem této diplomové práce je navrhnout a realizovat jednoduchý a přehledný systém, který bude evidovat základní informace o průběhu zkouškového období na vyšší odborné škole, bude snadno obsluhovatelný, přehledný a levný na údržbu.
Součástí návrhu bude volba vhodné platformy, serverových skriptů, databáze, její struktury a v neposlední řadě také uživatelského rozhraní.
Důležitou součástí informačního systému pro veřejné instituce je přístupnost webového rozhraní a bezpečnost aplikace. Proto se již návrh aplikace věnuje nejčastějším bezpečnostním rizikům spojeným se zvolenou platformou a posuzuje výstupní webové stránky z pohledu novely zákona č. 365/2000 Sb. o informačních systémech veřejné správy, provedenou zákonem č. 81/2006 Sb.
2. Návrh aplikace
Jak již bylo naznačeno v úvodu, mezi hlavní požadavky na aplikaci byla volba takové platformy, která bude v rozpočtu školy představovat minimální náklady na provoz i pořízení a zároveň bude snadná na správu.
Byla tedy vybrána jedna z nejpoužívanějších platforem, a to webový server Apache HTTP Server. Tento HTTP server je možné provozovat na široké paletě operačních systémů, jako jsou unixové FreeBSD, Linux, Solaris a Mac OS X či Microsoft Windows a existuje k němu nespočet bezplatných návodů dostupných na internetu.
Webový server je poskytován s licencí Apache Licence, která umožňuje volné použití tohoto open-source softwaru. Toto je výhoda oproti řešení od firmy Microsoft v podobě IIS, které je navíc nutné provozovat pouze na serveru s operačním systémem Windows, a představuje tak další nezanedbatelnou položku v rozpočtu.
Z výběru operačních systémů byla pro vývoj aplikace zvolena nejlevnější varianta, a to unixový operační systém Linux, konkrétně jeho distribuce CentOS, založená na Red Hat Enterprise Linuxu. Za předpokladu, že si budou školy hostovat aplikaci na svém vlastním serveru, není volba operačního systému nijak závazná a jde tedy pouze o doporučení.
Pro projekt evidence zkoušek na platformě Apache HTTP server je dále nutné zvolit vhodný serverový skriptovací jazyk, databázi a výstupní formát pro uživatelské rozhraní. Tyto tři základní aspekty aplikace jsou blíže popsány v následujících podkapitolách.
2.1 Návrh uživatelského rozhraní
Jednou z nejviditelnějších částí aplikace je její uživatelské rozhraní, a proto je celá aplikace hodnocena uživateli na základě zkušenosti s prací v tomto prostředí.
Dobře promyšlený návrh uživatelského rozhraní webu je také schopný do jisté míry zakrýt nevhodnou strukturu databáze či aplikační vrstvy. Proto je této části aplikace věnováno dostatek prostoru v této diplomové práci.
2.1.1 Volba výstupního formátu aplikace
První část této kapitoly se zabývá volbou vhodného formátu pro výstupní text a to z hlediska značkovacího jazyka, hlaviček dokumentu a kódování českého jazyka.
Pro projekt evidence zkoušek byl zvolen výstupní formát v podobě dokumentu, tedy
webové stránky. Další možností by bylo celou aplikaci vytvořit v jedné z aplikačních platforem pro webové prohlížeče, a to v prostředí Adobe Flash či Microsoft Silverlight.
Obvykle se však tyto aplikace vkládají do webové stránky jako vložený objekt, pomocí HTML elementu object. Nevýhodou těchto objektů je nutnost alternativního zobrazení pro klientské zařízení, které tyto platformy z nějakého důvodu nepodporují.
To by v případě projektu evidence zkoušek znamenalo kompletní převod aplikace do serverového skriptovacího jazyka, a proto je tedy tato varianta zbytečně komplikovaná a spíše teoretická.
2.1.1.1 Volba značkovacího jazyka a hlaviček dokumentu
V případě výstupu online aplikace v podobě webové stránky neexistuje v současnosti žádná alternativa ke značkovacímu jazyku HTML, který slouží ke strukturování textu webu. Existuje však celá řada variant jazyka HTML, prezentovaných ve formě norem, vydávaných konsorciem W3. Vývoj jazyka HTML prošel celou řadou změn od svého prvotního vydání na počátku 90. let minulého století. Především však přešel od komplexního formátování textu k oddělení významových značek a samotného vzhledu dokumentu, zapsaného v externím stylopisu v jazyce CSS. Toto řešení má několik výhod, a to například
• dosažení snadnějšího strojového zpracování dokumentů,
• možnost definování různých stylů pro různá výstupní zařízení,
• jednodušší a efektivnější možnosti změn v definici,
• zrychlení načítání stránek za použití cache prohlížeče.
Následně vznikla rozšířitelná verze jazyka HTML, tzv. eXtensible HTML, tedy XHTML. Původně se předpokládalo, že tento jazyk nahradí původní jazyk HTML, který nebyl od verze 4.01 dále vyvíjen, a přinese nové možnosti. Nicméně tento původní záměr nebyl uskutečněn, protože v praxi přinesl spíše omezení, než skutečné přínosy.
V současné době by již bylo možné jazyk XHTML možné považovat na překonaný, protože chystaný nástupce, jazyk HTML 5, přinese spoustu inovací, které již měly být dávno samozřejmostí. Bohužel je stále ve stádiu návrhu organizací W3C a na jeho plnou podporu budou vývojáři webových aplikací muset chvíli počkat. Inovace se zaměřily na multimediální obsah, redefinovaní struktury webu pomocí nových
sémantických značek, ale také například nových typů formulářových vstupů. Současně s normou HTML 5 bude vydána nová XML serializace, a to XHTML 5.
Jazyk XHTML představuje kombinaci HTML a jazyka XML, a jako takový převzal sadu značek z HTML 4.01, které však svým zápisem odpovídají jazyku XML tak, aby jej mohl zpracovat XML parser prohlížeče. K tomu, aby prohlížeč dokument vykreslil prostřednictvím XML parseru, by však bylo nutné zaslat hlavičku dokumentu ve formátu application/xhtml-xml, namísto standardního text/html. Ve skutečnosti se s takovou hlavičkou setkáme jen velice zřídka a XHTML dokumenty jsou v prohlížeči vykreslovány HTML parserem. To způsobuje, že jsou chyby dle DTD jazyka XHTML ignorovány a fakticky se stránka chová naprosto identicky, jako kdyby byla napsána v jazyce HTML 4.01.
Důvodem, proč se tento formát v praxi neprosadil, je přílišný důraz XML parseru na DTD. Pokud například vinou drobné chyby v algoritmu serverového skriptu dojde ke křížení značek, případně nebude některá z nepárových značek uzavřená zpětným lomítkem, stránka se v jednom z nejrozšířenějších prohlížečů současnosti, ve Firefoxu, vůbec nezobrazí, protože nastane chyba parsování XML. Při odeslání hlavičky s Content-Type ve formátu text/html bude tato chyba ignorována, protože je dokument vyhodnocen HTML parserem, který se snaží vykreslit stránku za každou cenu. Paradoxem je, že ačkoliv je kód stránky nevalidní, plný sémantických i syntaktických chyb, bude funkční v případě, kdy je odesílaný s hlavičkou text/html. Návštěvník tedy informace dohledá i přesto, že je formátování stránky nekorektní.
V opačném případě, kdy dodržíme standard dle W3C a odesíláme hlavičky s obsahem definovaným jako application/xhtml-xml, může skončit zpracování kódu chybovou hláškou XML parseru i v případě tak drobného nedostatku jako je například neukončená párová značka. Toto je však mnohdy špatně ovlivnitelné ze strany vývojáře webových stránek, protože stačí, aby některý z doplňků do prohlížeče či operačního systému automaticky vložil nestandardní skript na konec dokumentu. Podobné skripty vkládají do stránek například komunikační programy, některé antiviry nebo akcelerátory stahování stránek. Poslední z důvodů je fakt, že starší verze Internet Exploreru nabízí stránku s hlavičkou application/xhtml-xml ke stažení, místo aby ji vykreslily.
Samotné stránky konsorcia W3, které tento standard popisují, jsou deklarovány v jazyce XHTML 1.1 strict, ale hlavička dokumentu obsahuje content-type
ve formátu text/html.
Jak bylo uvedeno v prvním odstavci kapitoly, od HTML čtvrté verze byl pro účel definice vzhledu dokumentů zaveden jazyk CSS, který lze použít nejen pro webové stránky v jazyce HTML ale i pro popis zobrazení dokumentů XML. Nevýhodou kaskádových stylů je různá interpretace jazyka v různých prohlížečích a mnohdy omezená podpora některých konstrukcí. V posledních několika letech však dochází k výraznému zlepšení v podpoře CSS, a to zejména díky rychlému rozvoji nových zařízení, které již od výrobce obsahují přeinstalovanou jednu z aktuálních verzí internetových prohlížečů.
Pro projekt Evidence zkoušek studentů bylo na základě výše uvedených důvodů zvoleno řešení v podobě jazyka XHTML 1.0 strict, který je z hlediska čistoty kódu dostatečně striktní. Pro definici vzhledu pomocí kaskádových stylů byl dodržován standard úrovně CSS 2.1, s využitím některých prvků z CSS 3, jako například vlastností
border-radius pro zaoblení rohů či pseudotřídy nth-of-type(even) pro zvýraznění lichých řádků tabulek. Tyto prvky jsou stále ve fázi návrhu, nicméně jsou již hojně podporovány napříč prohlížeči a byla by škoda jich nevyužít k zatraktivnění vzhledu.
V minulosti se efektů jako je například vržený stín či zaoblení rohů používaly obrázky na pozadí. Toto řešení však zvyšovalo datové nároky, zpomalovalo vykreslování a v neposlední řadě představovalo riziko v případě, kdy se z nějakého důvodu obrázky nezobrazily. Poté se velice často stávalo, že nebylo písmo čitelné z důvodu malého kontrastu pozadí – tedy background-color a barvy popředí color. Nové prvky z třetí úrovně CSS nepředstavují problém ani pro starší verze prohlížečů, protože tyto jim neznámé vlastnosti ignorují.
Výstupní dokument ve formátu XHTML je klientovi zasílán s hlavičkou obsahující klauzuli content-type ve formátu text/html, což zaručí výpis stránek za jakýchkoliv okolností, byť za cenu možnosti výstupu s poškozeným formátováním. Existuje však vysoká pravděpodobnost, že bude cíl v podobě předání informace klientovi či naopak od klienta směrem k serveru splněn i v případě nekorektního zobrazení.
Dalším důležitým bodem návrhu výstupního formátu je rozdělení definice vzhledu do několika stylopisů, a to z důvodu dalšího vývoje aplikace a její využití na více vyšších školách současně. Později totiž vznikne potřeba aktualizovat některé části aplikace, a proto je vhodné stylopisy rozdělit dle několika kritérií jako například frekvence očekávaných změn, míra univerzálnosti a dále do skupin dle typu formátovaného prvku.
Obsah Layout
Backend backend.css page.content.default.css page.content.custom.css
Frontend
page.content.default.css page.content.custom.css
frontend.css
page.layout.css page.layout.elements.css
Tisk print.css
Tabulka č. 1: rozdělení definice vzhledu do stylopisů
2.1.1.2 Kódování českého jazyka
Vzhledem k tomu, že český jazyk obsahuje znaky, které nejsou zahrnuty ve standardní ASCII tabulce, jež je dále nerozšiřitelná, protože je velikost znaku omezená velikostí jednoho bajtu, je nutné volit odlišné kódování pro horní polovinu znaků ASCII tabulky, tj. pro znaky od pozice 128 do 255. Bohužel nebyl vývoj v tomto ohledu jednotný, a vzniklo tak několik druhů kódování, které zahrnuje české znaky.
Z palety kódování vhodných pro češtinu, zahrnující například starší kódování firmy Microsoft windows-1250, jeho obdobu pro emailové servery, operační systémy Unix a Linux, tedy ISO 8859-2 a nejnovější tzv. Unicode kódování UTF-8, byl zvolen poslední jmenovaný. Kódování Unicode poskytuje bezpečí zápisu jakéhokoliv potřebného znaku, protože má posloupnost znaků rozšířenou až na 4 bajty. V případě, že bude na škole vyučován předmět vyučujícím z východních zemí, nebude činit zápis jeho jména v originálním znění žádný problém. Další výhodou je fakt, že je výchozí znakovou sadou pro jazyk XML, a tedy i pro značkovací jazyk XHTML. Není tedy třeba před definicí typu dokumentu uvádět také kódování jazyka XML.
2.1.2 Návrh layoutu stránek
Při návrhu webových stránek je vhodné rozmyslet, jaké klíčové prvky bude nutné rozmístit a vzít v úvahu jejich důležitost a vzájemnou kombinovatelnost. V případě evidence zkoušek to byly zejména tyto prvky:
• hlavička stránek
• hlavní navigační lišta
• přihlašování uživatelů a panel přihlášeného uživatele
• obsahový blok
• patička stránek
V případě přihlašování uživatelů a panelu uživatele je evidentní, že tyto dva prvky nebudou zobrazovány současně, a proto bude využito jednoho společného prostoru, který vždy jeden z těchto dvou prvků zobrazí. Celý obsah stránek byl poté rozdělen do dvou sloupců v poměru 4:1, kdy menší z těchto dvou sloupců obsahuje přihlašování a zbytek prostoru tvoří obsahový blok. Ostatní prvky byly umístěny na obvyklá místa.
Horní část je tvořena hlavičkou stránek, obsahující nadpis a hlavní navigační nabídku, spodní pak tvoří patička stránky.
Obr. 1: Návrh layoutu stránek
Pro celkové rozložení stránek byl zvolen tzv. fluidní layout, který se roztahuje na šířku okna prohlížeče, a to z důvodu maximálního využití prostoru pro zobrazení tabulek v obsahovém bloku. Okolo celé stránky byly zvoleny minimální vnější okraje. Protože budou obsahové bloky obsahovat poměrně široké tabulky s několika sloupci, bylo výhodné definovat minimální šířku stránky. Při zmenšení okna prohlížeče pod tuto mez se tedy stránka dále nezmenšuje na šířku, ale na místo toho se zobrazí horizontální posuvník. Při volbě této minimální šířky bylo počítáno s nejobvyklejším rozlišením
obrazovky, od kterého bylo odečteno cca 50 obrazovkových bodů, které mohou činit okraje okna prohlížeče, včetně postranních panelů. Dle statistik toplist.cz a w3schools.com činí minimální šířka okna prohlížeče v celoobrazovkovém režimu 1024 obrazovkových bodů. Tento stav je platný již několik let a podíl tohoto rozlišení činí 97 %. Navíc, celých 85 % zařízení má v současné době vyšší rozlišení. Zvolená minimální šířka 980 pixelů je tedy v současnosti zobrazitelná v celé šíři bez horizontálních posuvníků a bude poskytovat dostatek prostoru k zobrazení vnořeného obsahového bloku.
2.1.3 Návrh obsahu stránek
Pro jednotlivé stránky aplikace bylo nutné navrhnout rozložení prvků uvnitř obsahového bloku, a proto jsou součástí návrhu tzv. wireframe schémata. Průběžnými změnami bylo dosaženo jednotného konceptu uživatelského rozhraní, které bude pro studenty i učitele lépe pochopitelné. V horní části obsahového bloku je vždy umístěno filtrování obsahu, tedy prvky definující to, co má být dále zobrazeno. Pro tyto filtry byly zvoleny formulářové pole typu select, protože jsou velice přehledné a šetří prostor na stránce, na rozdíl od záložek či seznamů s odrážkami.
Pod prostorem pro filtrování obsahu vždy následuje formulář pro interakci s uživatelem, pro který byl navržen koncept formulářových tabulek, který je popsán v následující kapitole. V rámci těchto tabulek se tedy zobrazuje vytříděný obsah dle výše uvedených filtrů, seřazený podle potřeby jednotlivých sekcí. V některých případech není obsah sekce limitován na jednu formulářovou tabulku, ale obsahuje více prvků. Příkladem odlišného rozložení uvnitř těla stránek může být sekce pro správu předmětů či zobrazení rozvrhů, které jsou blíže popsány v níže uvedených wireframech a také v kapitole představující samotnou aplikaci.
Obr. 2: wireframe sekce předměty
Na výše uvedeném obrázku je patrné rozložení většiny sekcí. Ty se liší nejen filtrováním, ale také jednotlivými sloupci v tabulce. Příkladem odlišného rozložení prvků je sekce rozvrhy. V případě, kdy není uživatel přihlášen, nejsou změny ve spodní tabulce povoleny a slouží tak jako přehled jednotlivých přednášek či cvičení.
Obr. 3: wireframe sekce rozvrhy
2.1.4 Koncept formulářových tabulek
Pro správu obsahu i zobrazení informací bylo využito jednoduchých tabulek, které v řádcích zobrazují jednotlivé položky jako například uživatelské účty nebo předměty.
V případě, že má přihlášený uživatel oprávnění data měnit, zobrazuje se mu také editační řádek. Ten je ve výchozím stavu na poslední pozici a slouží k vytvoření nové položky. Vyplněním všech formulářových prvků v jednotlivých sloupcích tabulky a potvrzením tlačítka pro vložení, dojde k opětovnému načtení stránky a vložení nového záznamu. U každé položky se dále zobrazuje v posledním sloupci seznam akcí, které je možné s řádkem provádět, tedy například jej upravit či smazat. V případě, že uživatel zvolí editaci záznamu, přesune se přidávací řádek na pozici editovaného záznamu a vyplní se všechny hodnoty vstupních polí. Uživatel má možnost změnit údaje vztahující se k danému řádku a potvrzením je uložit do databáze. Přitom je opět přesměrován do výchozího stavu.
Tyto akce je možné nastavit pro každou tabulku individuálně a liší se také podle úrovně přístupu. V tabulce termínů zkoušek má například administrátor či učitel možnost termín změnit či smazat, zatímco studentovi tyto akce nejsou umožněny.
Naopak je mu zpřístupněna možnost se na termín přihlásit či odhlásit.
S podobným konceptem se setkáváme v různých administracích webu poměrně často, nicméně tyto tabulky obsahují pouze výpis položek, které se poté upravují v samostatném formuláři pro editaci záznamu. Ten bývá zpřístupněn poté, co uživatel v přehledu položek zvolí akci pro přidání nového záznamu například v jednom z rohů obsahového pole. Při vkládání nového záznamu je však poněkud omezující, že uživatel v tu chvíli nemá přehled o ostatních vložených záznamech. Návrh konceptu formulářových tabulek vzal v úvahu, jak tento poměrně známý koncept tabulek zlepšit tak, aby měl uživatel při každé úpravě záznamů přehled o ostatních položkách, které by ale zároveň neodváděly pozornost od upravovaného řádku.
Řešení problému bylo inspirováno tabulkami v programu Microsoft Access, které podobné rozložení zavedly již od počátku. V prostředí webové aplikace, kdy je nutné každé změny odesílat na server, byla omezena možnost úpravy pouze na jeden řádek.
Při možnosti úpravy více řádků současně by mohlo snadno dojít k nechtěným úpravám, které by byly fakticky nevratné. Optimalizací kódu pak bylo dosaženo rychlého zpracování požadavků tak, aby toto omezení uživatele nijak nezdržovalo při práci.
Obr. 4: formulářová tabulka
2.1.5 Konkrétní řešení problémů uživatelského rozhraní
V této kapitole jsou uvedeny různé způsoby řešení přehledných formulářových tabulek a také tiskových výstupů.
2.1.5.1 Přehlednost formulářových tabulek
Důležitým aspektem, který zásadním způsobem ovlivňuje komfort při práci s editačními tabulkami, je definice jejich vzhledu. Pro zachování přehlednosti dat v tabulce je nezbytné vykreslit různá zbarvení pozadí sudých a lichých řádků tabulky, definovat odlišnou barvu pro hlavičku a v neposlední řadě také pro samotný editační řádek. Tyto barvy musí být dostatečně kontrastní tak, aby nemohlo dojít k záměně prvků. Pro výchozí vzhled byla zvolena kombinace bílých a šedých řádků pro tělo tabulky, tmavě modrá barva pro hlavičku a černá barva s bílým písmem pro editační řádek.
Obr. 5: formulářová tabulka při editaci záznamu
Za účelem zlepšení orientace v těle tabulky bylo zvoleno dobře známé řešení, kdy při CSS události hover, tedy přejetí kurzorem nad řádkem tabulky, nastane obarvení celého řádku do jiné barvy, která ve stávajícím schématu nefiguruje.
Tato barva musí být světlá, aby bylo tmavé písmo dobře čitelné. Proto byla zvolena světle modrá barva.
Pro realizaci těchto vizuálních úprav bylo využito pouze kaskádových stylů. Při řešení zbarvení lichých řádků se nabízela možnost přidělení třídy pro lichý řádek v průběhu generování tabulky serverovým skriptem. Při procházení jednotlivých řádků tabulky je totiž možné testovat, zda je iterátor pole záznamů modulo dvěma kongruentní s jednou, a v takovém případě řádku přidělit třídu pro lichý řádek. Zápis této logické operace by vypadal jako následovně:
if ($i%2) { … }
Uvnitř bloku této podmínky by poté byl výpis třídy pro lichý řádek. Podmínka je totiž platná pouze v případě, kdy bude výsledek roven 1, tedy v případě jazyka PHP roven true, což nastane v případě lichých čísel.
Obdobně by bylo možné sudé hodnoty iterátoru testovat bitovou operací. Je obecně známo, že lichá čísla mají na nejnižším bitu jedničku. Lze tedy využít operace bitový součin k detekci lichého řádku následujícím způsobem:
if ($i & 1) { … }
Bitový součin iterátoru a jedničky vrátí hodnotu 1 pouze tehdy, když bude na poslední pozici binárního vyjádření iterátoru taktéž jednička. Tedy v případě, že půjde o lichá čísla. Všechny předcházející pozice v binárním čísle budou vždy nulové, protože má jednička na všech ostatních pozicích mimo poslední nulu, což při použití operace AND nemůže vrátit jiný výsledek.
číslo řádku
v binárním tvaru 1 0 0 1 1
Maska 0 0 0 0 1
Výsledek operace 0 0 0 0 1
Tabulka č. 2: binární operace AND
Proto bude celá podmínka vyhodnocena jako pravdivá v případě, že bude iterátor liché číslo. Uvedené zápisy platí pro jazyk se slabou typovou kontrolou, jako je například PHP. Konkrétní příklad operace binárního součinu je uveden v tabulce č. 2.
Obě tato řešení mají ale několik nevýhod. Hlavním důvodem, proč nebylo toto řešení aplikováno, je fakt, že pole záznamů je procházeno cyklem foreach, který nevyžaduje explicitní vyjádření iterátoru a bylo by tedy nutné je v každém běhu cyklu inkrementací vyjadřovat. V případě logické operace vzniká další problém s obtížností výpočtu modulo, který by zbytečně zpomaloval výstup, byť jen v řádu desetin vteřiny.
Analogicky by bylo možné obarvení realizovat pomocí klientského skriptu v jazyce JavaScript, nicméně toto řešení navíc přináší další komplikace v podobě kompatibility na různých zařízeních. Komplikované by byly i případné přesuny řádků metodou drag
& drop, se kterými je třeba v budoucích verzích administrace počítat. Při každé změně pořadí řádků by totiž bylo nutné opětovně přidělit třídy odpovídající novému pořadovému číslu.
Z výše uvedených důvodů bylo tedy rozhodnuto přenechat obarvení řádků čistě na kaskádových stylech, konkrétně využitím pseudotřídy nth-of-type z třetí úrovně CSS.
Ta je již podporována napříč všemi prohlížeči, včetně Internet Exploreru. Podmínkou je však jedna z aktuálních verzí, což již v současné době vysokorychlostního připojení k internetu a automatických aktualizací nepřestavuje vážnou překážku. V případě starších prohlížečů bude tato konstrukce ignorována. Pseudotřída může nést několik argumentů, které poté platí pouze pro určité řádky. Tím mohou být nejen všechny sudé či liché instance třídy, ale také jednotlivé jejich jednotlivé reprezentace určené pořadím v dokumentu.
2.1.5.2 Tiskové výstupy
Další z výhod odděleného stylopisu je možnost definování různého vzhledu stránek pro jednotlivé výstupy. Rozpoznávané výstupní zařízení jsou například
• obrazovka počítače,
• tiskové výstupy,
• projektory,
• zařízení typu handheld,
• čtečky pro nevidomé, TV či terminálové obrazovky apod.
Pro projekt evidence zkoušek byly definovány dva výchozí vzhledy, a to tiskový výstup pro tisk rozvrhů, přehledů studentů či předmětů a výstup pro obrazovky a projektory. Je předpokládáno, že aplikace bude promítána na projektoru zaměstnancům či studentům za účelem proškolení obsluhy aplikace na běžných počítačích, a proto bude vhodné, když bude vzhled jednotný. Navíc je vzhled pro běžný monitor či obrazovku přenosného zařízení přehledný a dostatečně kontrastní, a proto není třeba definovat vyšší kontrast pro projekci.
Stylopis pro tisk však vyžadoval poněkud odlišný přístup. Z layoutu stránek byl vyňat veškerý text mimo blok s identifikátorem pagecontent, který v sobě nese celý obsah sekce. Tento jediný vykreslovaný blok byl zarovnán na formát A4 s minimálním okrajem. Tabulkám byla určena šířka přes celou stránku, dále byla odstraněna barva pozadí buněk a písmo bylo naopak nastaveno na černou barvu. Každému elementu v dokumentu bylo nastaveno patkové písmo, které se lépe čte v tištěné podobě. Poslední z úprav bylo odstranění nadbytečných sloupů s akcemi a editační řádek, čímž vzniklo více prostoru pro obsah, který je v případě tisku nejdůležitějším výstupem.
V případě ostatních typů výstupních zařízení se prozatím nepočítá s jejich použitím.
Pokud však v budoucnu taková potřeba nastane, stačí definovat nový stylopis s atributem media, odpovídajícím danému typu zařízení. Tyto stylopisy se vkládají do hlavičky dokumentu, případně importují do již existujících stylopisů klauzulí @import.
2.2 Návrh aplikační úrovně
Tato kapitola se zabývá návrhem aplikační úrovně evidence zkoušek. Jednotlivé aspekty návrhu jsou analyzovány na konkrétních příkladech z této aplikace.
Pro názornost jsou jednotlivé metody zjednodušeny a obsahují pouze klíčové operace.
2.2.1 Volba vhodné platformy
Skriptovací jazyk byl zvolen s ohledem na platformu a do výběru tak byly zařazeny jazyky podporované Apache HTTP serverem. Většina z těchto jazyků jsou dynamicky interpretovány. To znamená, že zdrojové kódy nejsou před spuštěním kompilovány překladačem do podoby strojového kódu, ale jsou interpretovány takzvaným interpretem.
Výhodou tohoto řešení je výborná přenositelnost napříč různými platformami, které aplikují svůj vlastní interpret. Autor skriptů je také ušetřen nutnosti správy paměti,
protože nemusí být proměnné vázány na fyzickou adresu v operační paměti, což umožňuje přemapování proměnných. Samotný zdrojový kód je také dobře laditelný, protože je stav interpretu jednoznačně definován a není třeba zvláštních optimalizací, které by mohly původní strukturu kódu překrývat či pozměňovat. Tyto výhody jsou pro projekt evidence zkoušek o to silnějším argumentem, když má být aplikace snadno přenositelná a rozšiřitelná, za cenu minimálních nákladů. Největší nevýhodou těchto interpretovaných jazyků je nižší efektivita, s jakou jsou aplikace vykonávány.
Vzhledem k rozsahu projektu by však tato nižší efektivita neměla způsobovat žádné komplikace a rychlost serverových skriptů by měla být dostatečná. Pro potřeby projektu evidence zkoušek byl zařazen do užšího výběru jazyk PHP, Perl a Python.
2.2.2 Volba serverového skriptovacího jazyka
Při volbě serverového skriptovacího jazyka byly nejprve sestaveny kritéria, podle kterých byl následně jazyk zvolen.
Důležitým vodítkem byla rozšířenost jazyka. Výhodou rozšířených jazyků je, že pro ně existuje mnoho podnětných diskuzí, návodů a článků, které mohou zefektivnit práci či pomoci při rozhodování klíčových bodů návrhu některých částí aplikace.
V tomto bodě by tedy získal náskok jazyk PHP, který je dle přehledů W3Techs v současné době nejčastější volbou vývojářů webových aplikací PHP, s podílem cca 77 % [1]. Další výhodou je také velice dobrý manuál [2], dostupný online.
Ten obsahuje nejen spoustu detailních informací pro každou funkci, operaci či konstrukci jazyka, ale také přímo v detailním popisu každé funkce zahrnuje podnětnou a dobře moderovanou diskuzi, vedenou mnohdy řadu let. Pečlivě je zde zaznamenán vývoj jazyka, doporučení pro použití a detailní popis limitů, vzájemných referencí, vstupů i výstupů.
Dalším kritériem, které je nutné vzít v potaz, je způsob práce s objekty. Jazyky PHP, Perl i Python jsou multiparadigmatické, to znamená, že umožňují více než jedno programovací paradigma, a všechny zároveň umožňují objektově orientované programování.
Další, do jisté míry subjektivní aspekt, je způsob zápisu jazyka. Zde hrají roli také individuální preference a předchozí zkušenosti programátora. V případě začínajících programátorů má velikou výhodu jazyk Python, který byl již od počátku navrhnut tak, aby byl velice dobře čitelný pro člověka [3]. Syntax jazyků PHP a Perl k sobě mají
poměrně blízko, což potvrzuje i zmínka v oficiálním manuálu k PHP [2], která popisuje, že se vývojáři jazyka při vytváření syntaxe inspirovali jazyky C, Java a Perl. Pokud má programátor dostatek zkušeností například z Javy, C#, JavaScriptu a jiných jazyků založených na syntaxi C, zorientuje se v PHP velice rychle.
V neposlední řadě byla hodnocena efektivita jednotlivých jazyků na zvolené platformě. Dle dostupných srovnání efektivity různých programovacích jazyků na OS Linux jsou všechny tři jazyky v podstatě rovnocenné, s mírným náskokem PHP [4].
Testy byly prováděny prostřednictvím 14 různých algoritmů, jako je například alokování binárního stromu, či různé operace s DNA šroubovicemi. Na internetu lze nalézt celou řadu benchmarků [5], tedy srovnání výkonnosti programovacích jazyků, založených na prostém opakování základních operací. Takové testy však nelze brát v potaz, protože jde o uměle vytvořené testy, které nevypovídají o rychlosti reálných operací. Záleží tedy spíše na dobré optimalizaci samotné aplikace, než na zvoleném programovacím jazyce.
Na základě těchto kritérií byl zvolen serverový skriptovací jazyk PHP, který je nejen rozšířený, ale také dostatečně dobře popsaný. Z hlediska programovacích paradigmat umožňuje objektový přístup a pokryje všechny potřeby webové aplikace, protože obsahuje řadu potřebných knihoven. Samotný jazyk byl totiž navržen přímo pro tvorbu skriptů webových stránek, na rozdíl od ostatních řešení.
2.2.2.1 Specifika objektově orientovaného programování
Jak bylo zmíněno v úvodu kapitoly, z důvodu lepší přehlednosti aplikace byl zvolen objektově orientovaný programovací přístup.
Základním paradigmatem OOP je totiž snaha modelovat řešení úloh za použití principů reálného světa, pokud možno jedna ku jedné. V reálném světě tedy například otevíráme dveře pořád stejným způsobem, bez ohledu na to, zda jsou dřevěné nebo laminované, zda mají kukátko, bezpečnostní vložku nebo řetízek. Stejně tak se můžeme dívat na televizi, přepínat programy i přesto, že nevíme vůbec nic o principech jejího fungování. Analogicky při vývoji informačních systémů mohou vývojáři používat již vytvořené komponenty, podle potřeby si je trochu upravit nebo je používat jako stavebnici pro sestavování důmyslnějších a složitějších objektů [6].
Obecně řečeno, objektově orientované programování je založeno na myšlence, že jsou jednotlivé prvky modelované reality v programu seskupeny do entit,
nazývaných objekty. Objekty si pamatují svůj stav a navenek poskytují operace, které jsou přístupné jako metody pro volání.
Objekty jsou organizovány stromovým způsobem, kdy objekty nějakého druhu mohou dědit z jiného druhu objektů, čímž přebírají jejich schopnosti, ke kterým pouze přidávají svoje vlastní rozšíření, případně překrývají některou ze stávajících. Tato myšlenka se obvykle implementuje pomocí rozdělení objektů do tříd, přičemž každý objekt je instancí nějaké třídy. Každá třída pak může dědit od jiné třídy [6].
Příkladem dědičnosti a překrytí v aplikaci evidence zkoušek je základní kontejnerová třída. Ta zahrnuje všechny dostupné vazby na moduly a akce, a v případě dalšího vývoje bude dále pozměňována. Pokud by ovšem implementace aplikace na některé ze škol vyžadovala odlišné základní funkce, nastal by poté problém s aktualizací této třídy.
Proto byla zavedena třída customFunctionSet, která je potomkem basicFunctionSet.
class customFunctionSet extends basicFunctionSet { public function generatePasswordHash($string) {
if ($string != "") {
return md5($string);
} else {
return false;
} }
public function customDate() {
return date('j. n. Y, H:i:s');
} }
Třída customFunctionSet je pak v aplikaci inicializována vždy namísto basicFunctionSet, a proto nebude třeba žádných zvláštních opatření v případě individuálních změn v aplikaci pro potřeby jednotlivých škol. Postačí tedy zanést
změny do vlastní kontejnerové třídy a základní třídu ponechat nezměněnou. Instance základní třídy je tedy vytvořena následovně.
$FC = new customFunctionSet($CFG);
Na příkladě třídy customFunctionSet je definována vlastní kontejnerová třída, která obsahuje dvě metody. Metoda customDate není v základní třídě basicFunctionSet definována, a jde tedy o metodu přímo na míru pro konkrétní implementaci na jedné ze škol. Pokud bude nějaká metoda specifická pro konkrétní školu, není nutné, aby byla redundantně definována pro všechny kopie systému v základní třídě.
Druhá metoda generatePasswordHash je příkladem překrytí, protože již byla definována v základní kontejnerové třídě. K překrytí dojde za podmínky, že je metoda nebo atribut třídy z hlediska viditelnosti public či protected, tedy viditelná minimálně z potomků třídy. V této metodě je generována hash pro uložení hesla do databáze odlišným způsobem, než v případě standardní funkce z třídy basicFunctionSet.
O standardním způsobu generování hashe se blíže zmiňuji v kapitole autentizace a uživatelské přístupy, resp. v podkapitole způsob hashování hesel.
Další koncepcí objektově orientovaného programování je skládání objektů, tedy samotná architektura aplikace. Skládáním jednotlivých objektů pak vzniká kompletní aplikace. V případě aplikace pro evidenci zkoušek byla implementována následující metoda, která provede vložení PHP kódu s příslušnou třídou a vytvoří její instanci se stejným názvem.
public function loadModules($args) {
foreach ($args as $module => $parametres) {
if (include("/custom/modules/" . $module . ".php")) {
$this->modules[$module] = new $module($parametres, $this);
} else if ("/modules/" . $module . ".php")) {
$this->modules[$module] = new $module($parametres, $this);
} }
}
Tato metoda je volána vždy v každé instanci kontejnerové třídy a jako argument je předáno pole z objektu nastavení, které obsahuje názvy jednotlivých modulů. Toto pole navrací metoda getmodules z třídy config. Zápis tohoto volání metody tedy vypadá následovně, kde proměnná CFG je instancí objektu config.
$FC->loadModules($CFG->getmodules());
Pro obsluhu těchto modulů byla zavedena metoda getModuleHandler, pomocí které je předána instance třídy modulu pomocí klauzule return. Tato reference je uložena v atributu základní kontejnerové třídy s názvem modules, který je tvořen asociativním polem.
public function getModuleHandler($module) { if ($this->modules[$module]) {
return $this->modules[$module];
} else {
… }
Poté je možné volat metody z daného modulu například následujícím zápisem, který slouží k ověření administrátorských práv aktivního uživatele, prostřednictvím metody Authorized z modulu register.
$this->fc->getModuleHandler('register')->Authorized('admin');
Tímto způsobem je aplikace rozdělena na několik samostatných modulů. V případě, že volaný modul neexistuje, je navrácena chybové hlášení o nutnosti aktivace či doinstalování modulu. Pokud je volána metoda, která neexistuje, je také navráceno patřičné varování, což je realizováno metodou __call() v hlavní kontejnerové třídě basicFunctionSet, která byla již zmíněna. Tato architektura umožňuje snadnou rozšiřitelnost systému, nezávisle na výstupu či ostatních modulech. Pokud je vyžadována spolupráce určitých modulů, je toto spojení patřičně ošetřené prostřednictvím metody getModuleHandler. Výše uvedené příklady metod byly zjednodušeny pro potřeby snazšího pochopení principu.
Metoda Authorized třídy register je také vhodným příkladem OOP principu zapouzdření. To zaručuje, že jsou vnitřní operace a atributy objektu nepřístupné pro ostatní moduly. Každý objekt v aplikaci navenek poskytuje jen určité metody, které tvoří jakési komunikační rozhraní, které je zároveň ochrannou bariérou proti přímému přístupu ostatních objektů k atributům či vnitřním operacím objektu. Nijak neomezený přístup by totiž mohl vést k nekonzistentním stavům objektu. Při návrhu třídy objektů je třeba mít vždy na paměti, že cizí objekt nikdy nesmí přímo změnit hodnotu proměnné, která implementuje stav objektu. Pro takové modifikace jsou vždy používány funkční členy a je nutné zvážit, zda neexistuje způsob, jak by se mohl objekt dostat do nekonzistentního stavu [7].
OOP přístup tedy umožňuje nejen přirozenější skladbu aplikace, ale také například MVC architekturu, o níž se zmiňuji v jedné z následujících kapitol, a která by byla v případě imperativního programování velice obtížně implementovatelná.
2.2.2.2 Specifika serverového skriptovacího jazyka PHP 5
Jazyk PHP je dynamicky typovaný, to znamená, že datový typ proměnné je určen teprve při přiřazení hodnoty, na rozdíl silně typovaných jazyků jako je C, Java či Perl.
Jazyk PHP do verze 4.2.0 ve výchozím nastavení automaticky přejímal veškeré proměnné poslané jakoukoliv metodou (POST, GET, HTTP cookie, ale i ze zabudovaného mechanismu sessions) a umožňoval s nimi dále pracovat jako s globálními – tato možnost však představovala bezpečnostní riziko [8 s. 22], kdy bylo možné například obejít autentizační proces, při kterém je v poli sessions vytvořen záznam o přihlášení uživatele, a vnutit tak aplikaci hodnotu těchto proměnných voláním příslušného GET požadavku. Volání, kdy bychom v superglobálním poli session drželi přihlášeného uživatele v proměnné user, by vypadalo například takto.
http://www.domena.tld/?_SESSION[user]=admin
Protože byl zvolen jazyk PHP verze 5, ve kterém byl tento problém již vyřešen kontrolou původu proměnné, není třeba zavádět žádné další opatření.
Výhodou této verze je také podstatné vylepšení práce s objekty. Předchozí verze jazyka PHP sice již umožňovali vytvářet třídy i instance objektů, nicméně v páté verzi doznal jazyk několika důležitých změn. Mezi nimi je například způsob zápisu konstruktoru třídy, který je již jednotně pojmenován __construct(), na rozdíl od předchozích verzí, které vyžadovaly metodu se stejným názvem, jako je název třídy.
To mohlo způsobovat určité nejednoznačnosti v případě vícenásobné dědičnosti, která byla popsána v kapitole o objektově orientovaném programování.
Další unikátní novinkou jsou výchozí metody třídy jako je například dvojice
__get() a __set(). Metoda __get() se volá automaticky tehdy, kdy se pokusíme zjistit hodnotu datového členu, který neexistuje. Metoda __set() je naopak volána tehdy, kdy se pokusíme nastavit hodnotu neexistujícího datového členu. Tyto metody tedy můžeme využít na odchytávání přístupů do neexistujících datových členů a nastavit tak specifické chování jednotlivým třídám. [9] V aplikaci pro evidenci zkoušek nebylo tohoto chování jazyka PHP využito, protože jsou atributy objektu privátní a byly pro ně zavedeny vlastní metody, které obsluhují hodnoty datových členů, tzv. gettery a settery, které jsou pro objektově orientované programování typické.
Vhodným příkladem může být objekt config, uvedený níže, který nese základní konfiguraci aplikace, a na který se dotazují ostatní objekty prostřednictvím getteru get, který navrací hodnotu příslušného datového členu. Druhá metoda, setter s názvem set, je volán přímo v konfiguračním souboru, a prostřednictvím dvou argumentů, pomocí kterých nastavuje hodnotu argumentu val datovému členu cfg. Zde je také využita specifická vlastnost PHP, a to proměnné s proměnnými názvy. V programovacích jazycích, které toto neumožňují, by byly implementovány jednotlivé hodnoty do asociativního pole.
class config { …
public function set($cfg, $val) {
$this->$cfg = $val;
} …
public function get($cfg) {
return $this->$cfg;
} … }
Stejně tak jako můžeme použít metody __get() a __set() pro odchytávání přístupů k neexistujícím datovým členům, metodu __call() lze použít pro odchytávání přístupů k neexistujícím metodám v rámci dané třídy. Této možnosti bylo využito v základní kontejnerové třídě basicFunctionSet. Tato základní třída do sebe přejímá instance všech ostatních tříd, tj. akcí a modulů. Dá se předpokládat, že v průběhu dalšího vývoje aplikace může nastat situace, kdy bude volána neexistující metoda některého z modulů, což by znamenalo, že nastane výjimka a vykonávání skriptu bude ukončeno. Takovým stavům je však nutné v produkční verzi aplikace zabránit, na výstup vypsat pokud možno co nejvíce zpracovatelného obsahu a zapsat záznam o chybějící metodě do logu či záznamové konzole. Protože byla v aplikaci evidence zkoušek zavedena tzv. ladicí konzole, je při této události volána chybová hláška následujícím způsobem.
class basicFunctionSet {
…
function __call($nazev, $parametry) { if (!method_exists($this, $nazev)) { $this->call(
'args were ' . var_export($parametry, true), 'method ' . $nazev . ' n. found',
'e' );
return false;
} }
… }
Při každém volání metody v rámci základní kontejnerové třídy jsou této metodě
__call() předány dva argumenty; název volané metody a argumenty tohoto volání.
Protože je nejprve volána metoda __call(), můžeme ověřit existenci této metody
pomocí funkce method_exists(), a v případě, kdy nebude existovat, odeslat návratovou hodnotu prostřednictvím klauzule return, čímž zamezíme vykonávání původně volané neexistující metody. Návratovou hodnotou je false, a to protože ověřujeme provedení metody oproti návratové hodnotě. Protože bude tato podmínka vyhodnocena jako nepravda, bude proveden blok příkazů, který následuje v případě chyby či nevykonání operace. Součástí základní třídy je také metoda call, který slouží pro záznam do ladící konzoly, a které je věnováno více prostoru v samostatné kapitole.
Tato metoda tedy nemá nic společného s výchozí __call().
Poslední ze standardních metod objektů je metoda __destruct(), která umožňuje definovat chování při ztrátě reference na objekt. Tato metoda, nazývaná jako destruktor, patří také mezi novinky v PHP verze 5. Za normálních okolností se při ukončení skriptu zavolají interní funkce ukončující PHP moduly, které např. zavřou soubory nebo ukončí připojení do databáze, ukončí bufferování a zapíše session proměnné [10]. Destruktory tak umožní definici chování objektu při ukončování aplikace či ztrátě reference.
Pro potřeby evidence zkoušek však nebylo této možnosti jazyka využito.
2.2.2.3 Softwarová architektura MVC
Při návrhu aplikační úrovně projektu byla dodržována softwarová architektura MVC, tedy model-view-controller. Tato architektura se velice často používá v souvislosti s návrhem struktury webových aplikací a skládá se ze tří vrstev, kdy odděluje datový model aplikace, uživatelské rozhraní a řídící logiku do tří nezávislých komponent.
Cílem tohoto oddělení je snazší správa aplikace. Úlohu modelu v tomto případě plní databáze MySQL, jejíž návrh je blíže specifikován v kapitole 2.3, a několik přidružených funkcí obsažených v hlavním kontejnerové třídě basicFunctionSet. View je reprezentován soubory v adresáři struct, které představují šablony pro jednotlivé sekce, ale zároveň také pro jednotlivé prvky layoutu. Controller je pak definován v inicializaci aplikace init.php, a prostřednictvím metod kontejnerových tříd, které zpracovávají jednotlivé akce či stránky.
Obr. 6: diagram MVC aplikace
2.2.2.4 Konkrétní realizace serverových skriptů
V této kapitole budou analyzována vybraná řešení specifických problémů, které vznikly během návrhu aplikace a které byly řešeny na aplikační úrovni.
Základním prvkem aplikace bylo určení, jakým způsobem budou zpracovány všechny vstupy i výstupy z aplikace a jaká bude souborová struktura aplikace. Pomocí prvků, které jsou v této kapitole představeny, jsou všechny požadavky, které vyžadují serverové skriptování, směřovány do souboru index.php. Ten je také výchozím souborem dle nastavení PHP, který je zpracován v případě zobrazení kořenového adresáře, a je v něm načteno několik základních souborů celé aplikace:
• konfigurační soubor config.php v kořenovém adresáři
• předpisy kontejnerových tříd:
o function.basic.php pro základní třídu
o functions.custom.php pro třídu specifickou pro různé kopie aplikace o functions.frontend.php pro základní funkce výstupních stránek
• inicializaci aplikace init.php, která obsluhuje vstup a výstup
Obsahem souboru config.php je pak předpis třídy config, která určuje nastavení aplikace, jako je například URL adresa webserveru, lokální cesta k souborům, výchozí sůl pro hesla či údaje potřebné k připojení k databázi či FTP.
V souborech pro předpisy kontejnerových tříd jsou poté všechny dostupné základní metody aplikace, které jsou představovány v jednotlivých kapitolách této diplomové práce. Ty jsou poté využívány v jednotlivých modulech.
Inicializace aplikace v souboru init.php určuje, zda je vyžádaná stránka vstupní či výstupní, a volá příslušné metody z kontejnerových tříd. Vstupní stánky, které zpracovávají určitá data od klienta, jsou pro potřeby projektu pojmenovány akce (actions). Výstupní stránky, které nepřijímají a nezpracovávají žádná data, ale naopak vypisují obsah určité sekce, jsou nazývány stránky (pages).
V případě, že jsou uživatelem vyžádány akce, je volána metoda handleAction, instance třídy basicFunctionSet, resp. customFunctionSet, které jsou předány identifikátory modulu a jeho metody jako argumenty. V případě vyžádání výstupních stránek je vytvořena nová instance třídy frontEnd, definovaná v souboru functions.frontend.php, dále je nastavena cache a nakonec vypsán její obsah.
if ($sh['mod'] == "action") {
…
$FC->handleAction($sh['id'], $sh['oid']);
} else if ($sh['mod'] == "pages") {
$FE = new frontEnd($sh['id'], $FC);
…
$FE->setCache($CFG->iscached($sh['mod'], $sh['id']));
$FE->compileFrontend();
}
Metoda handleAction, volaná v případě když uživatel odešle požadavek ke zpracování dat z formuláře, funguje následujícím způsobem.
public function handleAction($aid, $oid) { $variables = $this->getAssignedVariables();
if (include("/exec/" . $aid . "/" . $aid . ".class.php")) { $this->actions[$aid] = new $aid($variables, $this);
if ($oid) {
$this->actions[$aid]->$oid();
} } }
V adresáři exec, umístěném v kořenu aplikace, je vyhledán podadresář obsahující stejnojmenný soubor se zdrojovým kódem třídy dané akce. Pokud takový soubor existuje, je následně vložen do kódu aplikace, zpracován a do asociativního pole s názvem actions, které je atributem základní kontejnerové třídy, je vložena reference na instanci této třídy. Konstruktoru této třídy je předána reference na základní kontejnerovou třídu (proměnná this) a pole s hodnotami, které uživatel odeslal prostřednictvím metody POST. Toto pole je získáno metodou getAssignedVariables, která je rovněž součástí základní kontejnerové třídy. Samotné zpracování požadavku je tedy dále řízeno konstruktorem třídy.
Metoda compileFrontend, volaná v případě vyžádání výstupních stránek, má na starost vykreslit HTML kód stránek. Zdrojový kód metody je následující.
public function compileFrontend() { $this->generateFiles();
if (file_exists($this->cacheFile)) {
return $this->useCache();
} else {
$this->outputFrontend();
} }
