bc.dvi

Prepis

1 Univerzita Karlova v Praze Matematicko-fyzikální fakulta BAKALÁŘSKÁ PRÁCE Peter Valentovič Informační systém pro školu Ústav formální a aplikované lingvistiky Vedoucí bakalářské práce: Mgr. Jan Raab Studijní program: Informatika, Programování 2008

2 Na tomto mieste by som chcel poďakovať môjmu vedúcemu Mgr. Janovi Raabovi za jeho rady a pripomienky počas tvorby tejto práce. Zvlášť chcem poďakovať aj mojej rodine, ktorá mi počas celého štúdia rôznym spôsobom pomáhala a podporovala ma. A nakoniec chcem poďakovať môjmu Bohu, od ktorého pochádza všetko, čo mám, a ktorý požehnáva moje úsilie. Prohlašuji, že jsem svou bakalářskou práci napsal samostatně a výhradně s použitím citovaných pramenů. Souhlasím se zapůjčováním práce a jejím zveřejňovaním. V Praze dne 8. dubna 2008 Peter Valentovič 2

3 Obsah Abstrakt 5 1 Úvod Cieľ Čo je WCMS? Implementácia Technológia AJAX Čo systém obsahuje Príklad použitia AJAX-u Bezpečnosť prihlasovania Modularita systému Modul pre generovanie školského rozvrhu Rozvrhovanie Zložitosť Klasifikácia rozvrhovacieho problému Vyučovacie hodiny Miestnosti Učitelia Triedy a skupiny študentov Tvrdé obmedzenia na rozvrh Mäkké obmedzenia na rozvrh Problém splňovania podmienok Terminológia Použitie CSP pri rozvrhovaní Knihovňa csp.lib.php Lokálne prehľadávanie Terminológia lokálneho prehľadávania

4 3.5.2 Algoritmus lokálneho prehľadávania Tabu search Priebeh a výsledky testov Záver Ako by išlo systém ešte vylepšiť (Ne)interaktivita generátoru rozvrhu Zhrnutie Literatura 30 A Užívateľská dokumentácia 32 A.1 Systémové požiadavky A.2 Inštalácia A.3 Správa menu položiek A.4 Správa obsahu A.5 Správa užívateľov A.6 Správa tried A.7 Správa modulov A.8 Chat A.9 Generátor rozvrhu A.9.1 Správa predmetov A.9.2 Správa dostupnosti vyučujúcich A.9.3 Správa položiek rozvrhu A.9.4 Správa generovaných rozvrhov B Obsah priloženého CD 50 4

5 Název práce: Informační systém pro školu Autor: Peter Valentovič Katedra (ústav): Ústav formální a aplikované lingvistiky Vedoucí bakalářské práce: Mgr. Jan Raab vedoucího: raab@ufal.mff.cuni.cz Abstrakt: V predloženej práci študujeme tvorbu informačného systému pre školy, ktorý umožňuje správu webového obsahu. Najprv sa v práci zaoberáme implementáciou samotného systému, ktorého prednosťou je jeho modulárnosť. Potom nasleduje podstatná časť, ktorou je popis implementácie jedného z modulov, a to modulu pre automatické generovanie školského rozvrhu. V tejto časti vysvetľujeme použité algoritmy a heuristické metódy. Ide hlavne o algoritmy použité na riešenie problému splňovania podmienok a o použitý algoritmus lokálneho prehľadávania známy ako tabu search. Klíčová slova: školský informačný systém, redakčný systém, školské rozvrhovanie, programovanie s obmedzujúcimi podmienkami, zakázané hľadanie Title: Information system for school Author: Peter Valentovič Department: Institute of Formal and Applied Linguistics Supervisor: Mgr. Jan Raab Supervisor s address: raab@ufal.mff.cuni.cz Abstract: In the present work we study creation of the school information system providing management of website. First, in this work, we deal with the implementation of system, whose advantage is its modularity. Then, the following essential part is description of the implementation of module, namely module for the automated school timetabling. In that part we explain used algorithms and heuristic s methods. Mainly, it consists of algoritms used for solving of constraint satisfaction problem and of used algorithm of local search known as tabu search. Keywords: school information system, content management system, school timetabling, constraint programming, tabu search 5

6 Kapitola 1 Úvod 1.1 Cieľ Mojím hlavným cieľom bolo pokúsiť sa sám vytvoriť informačný systém, a to taký, ktorý by raz naozaj mohol byť použitý v reálnom živote. S nápadom vytvoriť informačný systém pre školy prišiel môj bývalý učiteľ informatiky z gymnázia, ktorý ma oslovil, či by som nevytvoril systém pre jednoduchú úpravu webovej stránky školy. A pretože samotný systém na úpravu webového obsahu by na bakalársku prácu nestačil, rozhodol som sa zamerať pri implementácii aj na bezpečnosť prihlasovania (oddiel 2.4), modularitu systému (oddiel 2.5) a systém naviac rozšíriť o modul na generovanie rozvrhu pre základné resp. stredné školy (3.kapitola). Zároveň táto práca bola pre mňa aj veľkou výzvou, vzhľadom k tomu, že s vývojom webových aplikácií som doteraz skúsenosti nemal. 1.2 Čo je WCMS? Základným cieľom projektu bolo vytvoriť informačný systém pre školu umožňujúci jednoduchú úpravu webového obsahu (systému známeho ako WCMS Web Content Management System), preto uvediem základnú definíciu WCMS [14]. WCMS je systém pre správu obsahu obvykle implementovaný ako webová aplikácia, slúžiaci pre tvorbu a správu HTML obsahu, úpravu menu webovej stránky a správu dokumentov a webových obrázkov. Administrácia systému je obvykle vykonávaná cez webový prehliadač (tenký klient). 6

7 WCMS obvykle poskytuje aj ďalšie vlastnosti ako používanie šablón pre zmenu vzhľadu webovej stránky, používanie WYSIWYG (What You See Is What You Get) editoru umožňujúceho tvorbu a úpravu obsahu bez znalosti programovacích jazykov, rozšírenie funkcionality systému pomocou plug-inov alebo modulov, workflow management proces zverejnenia webového obsahu. 7

8 Kapitola 2 Implementácia 2.1 Technológia AJAX Počas práce som mal možnosť zoznámiť sa s technológiou AJAX (Asynchronous JavaScript and XML). Jedná sa o webovú technológiu, ktorá dovoľuje komunikáciu medzi klientom a serverom na pozadí, zatiaľčo užívateľ ďalej pokračuje vo svojej práci s aplikáciou. Ďalšia veľká výhoda používania tejto technológie je v tom, že stránka sa po prijatí odpovedi zo serveru nemusí znova načítať celá, ale iba jej časť, ktorej sa požiadavka týkala. Práve tieto prednosti sa dajú využiť na zlepšenie funkcionality webových aplikácií a pre lepšie pohodlie práce užívateľov. Technológiu AJAX využíva aj niekoľko známych služieb ako napríklad Google Suggest, GMail, Google Maps, vyhľadávač A9 od spoločnosti Amazon, webová služba na zdieľanie fotografií Flickr a mnoho iných. 2.2 Čo systém obsahuje Z typických prvkov WCMS (oddiel 1.2), som pre veľkú rozsiahlosť práce neimplementoval všetky. Chýba predovšetkým workflow management a správa webového materiálu (obrázky, audio súbory, elektronické dokumenty) na servery. Systém obsahuje nasledujúcu funkcionalitu: Správa menu položiek. Správa obsahu webovej stránky. Pre pohodlné vytváranie obsahu, som do systému integroval WYSIWYG editor. 8

9 Správa užívateľov spolu s validáciou ich údajov, špeciálne som sa zameral na bezpečnosť prihlasovania užívateľov. Správa tried. Správa modulov. Ako príklad modulov som vytvoril modul chat a modul pre automatické generovanie rozvrhu použité techniky sú popísané v 3.kapitole. Vo všetkých prípadoch, správa poskytuje základnú funkcionalitu - pridanie, úpravu a mazanie položiek danej správy a ich následné zobrazovanie v stránkovanom zozname (data grid). 2.3 Príklad použitia AJAX-u V niektorých prípadoch je potrebná aj validácia vstupných údajov. Ide predovšetkým o správu užívateľov, kde je potrebné kontrolovať jedinečnosť užívateľského mena, zhodu hesla a jeho potvrdenia, validitu dátumu narodenia alebo správnu formu ovej adresy. A práve na toto je výhodné použiť AJAX. Zatiaľčo užívateľ prechádza webový formulár a vyplňuje údaje, na pozadí prebieha kontrola zadaných údajov. Akonáhle systém zistí, že zadaný údaj je nevalidný, vedľa formulárového poľa s neplatným údajom sa objaví obrázok výkričníka a po prechode myšou ponad tento výkričník sa zobrazí chybová správa. Okrem implementácie AJAX validácie, sú údaje z webového formuláru validované aj na strane serveru po potvrdení a odoslaní celého formuláru. Záverečná validácia na strane serveru je vždy nevyhnutná. Ak niekto zakáže použitie JavaScriptu vo webovom prehliadači, AJAX validácia na strane klienta nebude fungovať a systém by sa preto stal zraniteľným voči útokom na poškodenie dát na servery (napríklad pomocou SQL injection). 9

10 Obrázek 2.1: Validácia vykonávaná na pozadí, zatiaľčo užívateľ pokračuje vo svojej aktivite. AJAX validácia nastáva zakaždým, keď formulárové pole stráca fókus (udalosť onblur). Hodnota pola je zaslaná na server, ktorý validuje data a vracia výsledok (0 pre neúspech, 1 pre úspech). Na server potrebujeme posielať asynchrónne požiadavky, kedykoľvek užívateľ opustí vstupné pole. Problém môže nastať, ak užívateľ prechádza medzi vstupnými polami veľmi rýchlo alebo ak je spojenie so serverom pomalé. Tento problém som vyriešil ukladaním požiadaviek do fronty (FIFO). Požiadavky sú zasielané na server, keď XMLHttpRequest je schopný komunikácie. Fronta zaručí, že požiadavky sú zasielané v očakávanom poradí. PHP validácia nastáva po odoslaní formulára. 10

11 2.4 Bezpečnosť prihlasovania Nie vždy sa dá zabezpečiť priebeh komunikácie cez zabezpečený protokol HTTPS. Ak komunikácia prebieha cez nezabezpečený protokol HTTP, tak aj citlivé data (napríklad heslo) sú posielané nešifrované (vo forme plain textu). Počas komunikácie medzi klientom a serverom môžu byť citlivé data útočníkom zachytené, a ak sa jedná o nezabezpečenú komunikáciu, aj následne zneužité. Útočník sa pritom snaží "odpočúvať" danú sieť, na ktorej prebieha komunikácia. Takýto útok sa nazýva sniffing. Bezpečné prihlasovanie sa dá zabezpečiť aj na nezabezpečenom protokole pomocou techniky výzva-odpoveď (challenge-response authentication) [13, 12]. Funguje tak, že server pošle klientovi výzvu. Klient k tejto výzve pripojí svoje heslo pomocou HMAC (keyed-hash Message Authentication Code) a vypočítanú hodnotu pošle serveru. Server vykoná rovnaký výpočet a obe výsledky porovná. Pokiaľ sa výsledky zhodujú, tak užívateľ dostane prístup do systému, inak ho odmietne. Pre výpočet HMAC sa dá použiť akákoľvek kryptografická hashovacia funkcia. Ja som použil MD5 (Message- Digest algorithm 5) z JavaScriptovej knihovni od Paul Johnstona [10]. 2.5 Modularita systému Modul je samostatná časť systému, ktorá sa využíva na rozšírenie jeho funkcionality. Pretože prezentovaný systém poskytuje iba základnú funkcionalitu, rozhodol som sa, že bude modulárny, a pri implementácii som sa špeciálne sústredil práve na správu modulov. V prípade potreby je možné do systému rozšírenia pridávať alebo ich uberať. Oboje je pre užívateľa jednoduché a o úspešnosti vykonanej akcie informuje systém zobrazením správy. Detailný postup sa dá nájsť v užívateľskej dokumentácii. Postup pre vytvorenie modulu a potrebné API zase v programátorskej dokumentácii. Rôzne školy môžu vyžadovať rôznu funkcionalitu systému. Môže to byť napríklad klasifikácia študentov, fotoalbum, chat, diskusné fórum, kniha návštev alebo generátor školského rozvrhu, ktorého možná implementácia je popísaná v nasledujúcej kapitole. 11

12 Kapitola 3 Modul pre generovanie školského rozvrhu 3.1 Rozvrhovanie Rozvrhovanie definoval Anthony Wren [15] ako problém priradenia aktivít na zdroje v čase vzhľadom k danej množine obmedzení tak, aby bolo splnených čo najviac podmienok. Pre rozvrhovanie definované ako timetabling je charakteristické najmä určenie času aktivít, pre rozvrhovanie definované ako scheduling je okrem určenia času dôležité aj usporiadanie aktivít. Známa je celá rada rozvrhovacích problémov, ako napríklad rozvrhovanie zamestnancov, vlakové jazdné poriadky, rozvrhovanie športových aktivít, rozvrhovanie vysokoškolských skúšok alebo školské rozvrhovanie (school timetabling, tiež známe ako class-teacher model). V ďalšom texte sa budem zaoberať práve školským rozvrhovaním, teda rozvrhovaním predmetov pre triedy a učiteľov. Aktivity teda predstavujú jednotlivé vyučované predmety; zdroje tvoria vyučujúci a miestnosti. Časom budeme rozumieť určitú množinu časových intervalov alebo tiež časových slotov, v ktorých môžu byť predmety vyučované. Obmedzenia pre rozvrh sú špecifické pre každú školu. Typickým príkladom obmedzení je napríklad obmedzenie pre učiteľa, ktorý môže vyučovať iba jeden predmet v danom čase, alebo že predmet môže byť vyučovaný iba v miestnosti s dostatočnou kapacitou. Pri školskom rozvrhovaní teda prideľujeme každému vyučovanému predmetu vyučujúceho, študentskú skupinu, miestnosť a časový interval, tak aby sa minimalizoval počet porušených obmedzení. 12

13 3.2 Zložitosť Zložitosť rozvrhovania zavisí od podmienok, ktoré sú kladené na konkrétnu úlohu rozvrhovania. Niektoré rozvrhovacie úlohy sa dajú riešiť s polynomiálnou zložitosťou 1. Obecne je problém školského rozvrhovania klasifikovaný ako NP-úplný problém. Gotliebova formulácia tvorby školského rozvrhu predpokladá, že každá vyučovaná hodina zahrňuje práve jednu študentskú skupinu, jedného učiteľa a voľný výber času z časových slotov [9]. Csima ukázal, že Gotliebov problém má polynomiálnu zložitosť, ak sú učitelia dostupný v ľubovolnom čase [4]. Even, Itai a Shamir zase ukázali, že v opačnom prípade je problém NP-úplný [7]. Zložitosť úlohy rastie s narastajúcim výberom predmetov pre študentov, s možnosťou stanoviť rôzny počet hodín pre vyučované predmety a rozložiť ich v rôznych dňoch počas týždňa. Už nájdenie vhodných vyučovacích časov pre všetky hodiny, ktoré sa týkajú paralelných študentských skupín, je NPúplný problém. Dôkaz o NP-úplnosti problému školského rozvrhovania podávajú T. Cooper a J. Kingston [5] prevodom známych NP-úplných problémov na problémy školského rozvrhovania (GRAPH K-COLOURABILITY, BIN PACKING, EXACT COVER BY 3-SETS, THREE DIMENSIONAL MATCHING). 3.3 Klasifikácia rozvrhovacieho problému V tomto module som sa zameral na problém generovania rozvrhu pre základné a stredné školy. Samozrejme generátor rozvrhu nebude vyhovovať všetkým školám (predovšetkým niektorým špecializovaným stredným školám) a ich požiadavkám na rozvrh. Z tohto dôvodu modul umožňuje zadať iba základné požiadavky na rozvrh Vyučovacie hodiny Pre náš rozvrhovací problém budem brať v úvahu vyučovacie hodiny, ktoré sa skladajú z predmetu, učiteľa, miestnosti, skupiny študentov (obyčajne sa jedná o celú triedu), dĺžky hodiny a z počtu hodín za týždeň. Vyučovacie hodiny sú rozvrhované do timeslotov, ktoré sú očíslované (1...počet dní * 1 Zoznam takýchto úloh sa dá nájsť v knihe Scheduling Algorithms [3]. 13

14 počet hodín). Vzťahy medzi jednotlivými entitami sú znázornené na obrázku 3.1. Obrázek 3.1: Vzťahy medzi entitami tvoriacimi jednu vyučovaciu hodinu. Pretože jedna vyučovacia hodina môže byť vyučovaná niekoľkokrát za týždeň, pre rozvrhovanie je potreba identifikovať každý výskyt tejto hodiny v rozvrhu. Každý výskyt vyučovacej hodiny nazvem položkou rozvrhu a identifikovať ich budem ešte naviac aj poradovým číslom v rozvrhu (1...počet hodín za týždeň) Miestnosti Na základnej škole je bežné, že predmet je vyučovaný v miestnosti, ktorá patrí danej triede. Pravdaže existujú predmety, ktoré vyžadujú špecifické pomôcky alebo zariadenia pre svoje vyučovanie a teda je potrebné pri tvorbe rozvrhu brať v úvahu, že potrebujú byť priradené do špeciálnych miestností. Takýmito predmetmi môže byť napríklad telesná výchova alebo informatika. Podobných predmetov s požiadavkami na špeciálne miestnosti je však málo. Preto som sa rozhodol, že priradenie miestností k vyučovaným predmetom počas generovania rozvrhu nebudem implementovať. Modul však umožňuje prideliť miestnosť pre vyučovaciu hodinu ručne. 14

15 3.3.3 Učitelia Nie všetci učitelia môžu byť dostupný ktorúkoľvek vyučovaciu hodinu. Niektorých učiteľov škola zamestnáva iba na polovičný úväzok. Potrebné je teda dovoliť nastaviť dostupnosť pre každého učiteľa. Dostupnosť učiteľa je možné nastaviť pre každú vyučovaciu hodinu každého dňa, počas ktorého prebieha vyučovanie (pondelok až piatok) Triedy a skupiny študentov Na základných resp. stredných školách sa väčšina predmetov vyučuje pre všetkých študentov danej triedy. Teda študentskú skupinu často tvoria všetci žiaci jednej triedy. Niektoré predmety však vyžadujú rozdelenie žiakov jednej triedy do podskupín, ako napríklad vyučovanie telesnej výchovy vyžaduje rozdelenie žiakov na skupinu dievčat a skupinu chlapcov. Alebo vyučovanie cudzieho jazyka vyžaduje rozdelenie na skupinu začiatočníkov a skupinu pokročilých. Pravdaže pre takéto podskupiny treba povoliť aj ich paralelnú výuku Tvrdé obmedzenia na rozvrh Pre riešenie rozvrhovania sa často používa programovanie s obmedzujúcimi podmienkami (constraint programming). Obmedzenia na vytváraný rozvrh sa rozdeľujú na tvrdé (hard constraint) a mäkké (soft constraint). Aby bol rozvrh prípustný, tvrdé obmedzenia nesmú byť porušené. V tomto module som implementoval nasledujúce tvrdé obmedzenia: každý učiteľ môže vyučovať v určitý okamžik najviac jeden predmet, každý učiteľ učí iba v čase, keď je dostupný, žiadna študentská skupina nesmie mať dve vyučovacie hodiny v rovnaký čas, žiadna študentská skupina nesmie mať jeden predmet viackrát za deň Mäkké obmedzenia na rozvrh Mäkké obmedzenia môžu byť porušené a obvykle odpovedajú určitým kritériám, ktoré sa snažíme minimalizovať alebo maximalizovať. Riešením je po- 15

16 tom rozvrh, ktorý splňuje všetky tvrdé obmedzenia a určitým spôsobom maximalizuje splnenie mäkkých obmedzení. V tejto časti rozvrhovania sa snažím už prípustný rozvrh zlepšovať, aby viac vyhovoval študentom resp. triedam. Mäkké obmedzenia kladené na rozvrh sú nasledujúce: snaha rozvrhnúť vyučovanie v dopoludňajších hodinách snaha minimalizovať počet voľných hodín v rozvrhu tried Mäkké obmedzenia vyjadrím pomocou ohodnocovacej funkcie, ktorá je súčtom ohodnotení rozvrhov tried pre každý deň v týždni. Táto funkcia bude mať tvar f + n 1 1, kde f je prvá hodina daného dňa v rozvrhu a suma predstavuje počet voľných hodín, ktoré tvoria medzery v rozvrhu. Hodnotu takejto ohodnocovacej funkcie sa snažím minimalizovať. 3.4 Problém splňovania podmienok Terminológia Problém splňovania podmienok (CSP - constraint satisfaction problem) sa skladá z konečnej množiny premenných a z konečnej množiny obmedzení nad týmito premennými. Každá premenná nadobúda hodnoty z určitej domény z konečnej množiny hodnôt. Obmedzenia určujú, ktoré kombinácie (n-tice) hodnôt môžu byť priradené premenným. Ak každá premenná má priradenú určitú hodnotu z jej domény, hovoríme o úplnom priradení premenných, v opačnom prípade hovoríme o čiastočnom priradení premenných. Priradenie sa nazýva konzistentné, ak sú splnené všetky obmedzenia, ktoré sa týkajú ohodnotených premenných. V opačnom prípade ide o nekonzistentné priradenie. Riešením CSP je úplné konzistentné priradenie, t.j. úplné priradenie premenných, pre ktoré sú splnené všetky obmedzenia Použitie CSP pri rozvrhovaní Existuje niekoľko reálnych problémov, ktoré ide formulovať ako CSP. Aj problém školského rozvrhovania sa často rieši prevodom na problém CSP. Pre riešenie CSP som vytvoril obecnú knihovňu v jazyku PHP. Pomocou knihovni získavam prípustné riešenie, ktoré je zároveň počiatočným riešením pre algoritmus lokálneho prehľadávania ja som implementoval tabu search. 16

17 Problém školského rozvrhovania som formuloval nasledovne. Za premenné som vzal položky rozvrhu (oddiel 3.3.1), ich doménami sú jednotlivé timesloty rozvrhu (maximálna veľkosť domény = počet dní * počet hodín). Doménou každej premennej sú iba tie timesloty, v ktorých je dostupný učiteľ, ktorý danú položku vyučuje. Za obmedzenia stačí vziať iba tvrdé obmedzenia na rozvrh (oddiel 3.3.5), pretože na začiatok je potrebný ľubovoľný prístupný rozvrh, ktorý ešte nemusí byť optimalizovaný s ohľadom na mäkké obmedzenia kladené na rozvrh Knihovňa csp.lib.php Knihovňu som vytvoril v jazyku PHP za účelom riešenia problému CSP. Mojím zámerom bolo vytvoriť obecnú knihovňu, ktorá sa bude dať použiť aj na iné problémy, nie len na problém rozvrhovania. V tejto kapitole popíšem algoritmy a techniky použité v knihovni. Za základný algoritmus pre riešenie CSP som zvolil backtracking, ktorý systematicky prehľadáva stavový priestor do hĺbky (tiež známe ako DFS = Depth First Search). Stavy v stavovom priestore sú konzistentné čiastočné priradenia premenných. Prechod medzi stavmi predstavuje rozšírenie čiastočného priradenia o ďalšiu premennú (labeling). Počiatočným stavom je prázdne priradenie, ktoré je algoritmom postupne rozširované. Keď nastane situácia, kedy nejde rozšíriť určité čiastočné priradenie na iné konzistentné priradenie (fail alebo dead-end), dochádza k backtrackingu algoritmus sa vracia k najbližšiemu predchádzajúcemu stavu, u ktorého existuje nejaký nepreskúmaný nasledovník. Algoritmus končí buď nájdením úplného konzistentného priradenia, alebo dokázaním nekonzistencie zadaného problému, pokiaľ nebolo nájdené žiadne riešenie. Backtracking má tri základné nedostatky: trashing opakovanie neúspechu z rovnakého dôvodu redundancy nepamätá si hodnoty premenných, ktoré spôsobujú konflikty late detection of the conflict nedokáže odhaliť konflikt predtým ako skutočne nastane Existuje niekoľko metód, ktoré sa snažia vyhnúť týmto nedostatkom a tak zvýšiť efektivitu backtrackingu. 17

18 Efektivita vyhľadávania môže byť významne ovplyvnená poradím, v ktorom sú vyberané premenné alebo ich hodnoty. Usporiadanie premenných určuje, o ktorú premennú backtracking rozšíri súčasné čiastočné priradenie premenných v nasledujúcom kroku. Usporiadanie hodnôt premenných hovorí, v akom poradí budú skúšané jednotlivé hodnoty premenných. Vhodné usporiadanie premenných môže výrazne znížiť veľkosť prehľadávaného stavového priestoru, zatiaľčo vhodné usporiadanie hodnôt premenných vedie spravidla k skoršiemu nájdeniu riešenia problému. Usporiadanie môže byť určené iba pred začatím prehľadávania (static ordering), alebo sa môže aj meniť v priebehu prehľadávania (dynamic ordering). Heuristiky DVO (Dynamic Variable Ordering) dovoľujú vybrať premennú i po spätnom kroku namiesto pokračovania s premennou, s ktorou spätný krok nastal. V knihovni som použil kombináciu metód známych ako minimum remaining values (MRV) a degree heuristic (DH). Obe heuristiky sa snažia o to isté - a to, aby bola najprv priradená premenná, pri ktorej je najväčšia pravdepodobnosť, že spôsobí nezdar v prehľadávanej vetve. Heuristika MRV dynamicky usporiada premenné podľa vzrastajúcej mohutnosti ich domén vyberá premennú s najmenšou doménou. Degree heuristic zase vyberá nepriradenú premennú, ktorá sa v definovaných podmienkach vyskytuje najčastejšie. Táto heuristika sa použije pri rovnako veľkých doménach v prípade, keď nejde použiť MRV. 18

19 Algorithm 1 Backtracking function Backtracking (X, D, C) d(i) D i pre 1 i n {kopíruj domény} i 1 while 1 i n do preusporiadaj premenné x 1,...,x n podľa heuristiky DVO x i SELECT_VALUE() if x i je NULL then {doména je prázdna} if i > 1 then obnov d(i) do stavu, kedy do x i 1 bola naposledy priradená hodnota end if i i 1 {krok späť} else i i + 1 {krok dopredu} end if end while if i = 0 then return "CSP nemá riešenie" else return hodnoty priradené do x 1,...,x n end if end Backtracking Efektivita algoritmu môže byť ďalej výrazne vylepšená pomocou konzistentných techník. V knihovni som implementoval heuristiku známu ako forward checking (FC). FC spolupracuje s heuristikou MRV po vykonaní FC sa spustí heuristika MRV. Postupnosť krokov techniky forward checking je nasledujúca: 1. Do premennej X je priradená hodnota. 2. Skontroluj každú nepriradenú premennú Y, ktorá je spojená s premennou X s nejakou podmienkou. 3. Zmaž všetky hodnoty z domény premennej Y, ktoré nie sú konzistentné s priradením premennej X. 4. (a) Ak je nejaká premenná Y, ktorá má prázdnu doménu, zruš toto priradenie vykonaj krok späť (backtrack). 19

20 (b) Inak vykonaj MRV. Technika FC ale kontroluje konzistenciu iba medzi priradenými a nepriradenými stavmi pri prehľadávaní odstraňuje z nepriradených premenných tie hodnoty, ktoré sú nekonzistentné s aktuálnym priradením, tj.udržuje iba tzv lokálnu konzistenciu. Názvy niektorých konzistentných techník sú odvodené od grafovej notácie CSP. Problém CSP môže byť reprezentovaný ako graf obmedzení 2, kde vrcholy odpovedajú premenným a hrany podmienkam. Takáto reprezentácia vyžaduje binárnu formu CSP 3. Konzistentná technika nazývaná arc consistancy (hranová konzistencia) detekuje aj také nekonzistencie, ktoré nie sú detekované samotným FC - AC kontroluje konzistenciu aj medzi dvoma nepriradenými premennými. Algoritmy AC opakovane zužujú domény premenných, pokiaľ všetky hrany nie sú konzistentné. Robia to tak, že prechádzajú každú hranu v grafe podmienok a odstraňujú tie hodnoty jednej premennej, ktoré nie sú konzistentné so žiadnou hodnotou druhej premennej. Zmenšujú tak priestor možných priradení, ktorý je treba prehľadať. Algoritmov pre zaistenie hranovej konzistencie existuje niekoľko, no najznámejší z nich je AC-3, ktorý je implementovaný aj v tejto knihovni. Zúženie jednej z domén môže spôsobiť vznik nekonzistencie hrany, ktorá bola predtým konzistentná. Algoritmus AC-3 kontroluje iba tie hrany, ktorých konzistencia môže byť zmenšením domény premennej narušená, tj. hrany, ktoré vedú do inkriminovanej premennej. Naviac, hranu vedúcu z premennej, ktorá zmenšenie domény spôsobila nie je nutné kontrolovať. 3.5 Lokálne prehľadávanie Terminológia lokálneho prehľadávania stav s ohodnotenie všetkých premenných evaluácia E hodnota objektívnej funkcie (počet nesplnených podmienok počet konfliktov) globálne optimum stav s najlepšou evaluáciou 2 Tiež známy ako constraint network. 3 Nie je zložité ukázať, že ľubovolný problém CSP sa dá transformovať na ekvivalentnú binárnu formu[2]. 20

21 lokálna zmena zmena hodnoty jednej premennej okolie o množina stavov líšiaca sa od daného stavu o jednu lokálnu zmenu lokálne optimum stav, v ktorého okolí nie sú stavy s lepšou evaluáciou striktné lokálne optimum - stav, v ktorého okolí sú stavy s horšou evaluáciou ne-striktné lokálne optimum lokálne optimum, ktoré nie je striktné plateau množina stavov s rovnakou evaluáciou Obrázek 3.2: Terminológia lokálneho prehľadávania Algoritmus lokálneho prehľadávania. Hlavná myšlienka je pre všetky algoritmy lokálneho prehľadávania rovnaká. Algoritmy pracujú s úplnými nekonzistentnými priradeniami. Pri prehľadávaní sa prechádza medzi priradeniami tak, že nasledujúce priradenie vznikne malou lokálnou zmenou predchádzajúceho priradenia. Lokálnou zmenou môže byť napríklad zmena hodnoty jednej premennej. Prevedené zmeny by mali viesť k zlepšeniu priradenia, teda mali by odstrániť nekonzistencie v priradení alebo znížiť hodnotu objektívnej funkcie. Metóda lokálneho prehľadávania nezaručuje nájdenia optimálneho riešenia (napr. môže uviaznuť v lokálnom optime), a ani podla nej nejde dokázať, že neexistuje žiadne riešenie. 21

22 Algoritmy lokálneho prehľadávania majú spoločnú kostru. Algorithm 2 Local Search function LocalSearch (MaxPokusov, MaxZmien) s náhodné ohodnotenie premenných {počiatočné riešenie} pokusov 0 while pokusov < MaxP okusov && GP odmienka do zmien 0 while zmien < MaxZmien && LP odmienka do if E(s) = 0 then return s end if vyber δ z o(s) if δ je akceptovateľné then s = δ end if zmien = zmien + 1 end while s = novystav(s) pokusov = pokusov + 1 end while return najlepšie s end LocalSearch Medzi najznámejšie algoritmy lokálneho prehľadávania patrí metóda najväčšieho stúpania (hill climbing), náhodná prechádzka (random walk), simulované žíhanie (simulated annealing), povolený prah (threshold acceptance), metóda zakázaného hľadania (tabu search) a genetické algoritmy. Jednotlivé algoritmy sa líšia riešením problému zacyklenia (uviaznutie v lokálnom optime) Tabu search Metóda tabu search bola navrhnutá koncom 80-tých rokov Gloverom ako určité zovšeobecnenie hill climbing algoritmu pre riešenie zložitých optimalizačných úloh [8]. Táto metóda prehľadáva priestor riešení problému posunom z riešenia s i získaného v iterácii i do najlepšieho možného riešenia s i+1 v podmnožine 22

23 N(s i ) nazývanej okolie (neighborhood) riešenia s i. Okolie N(s) definujeme ako množinu riešení, ktoré môžme získať aplikáciou lokálnych zmien alebo posunov na aktuálne riešenie s, teda N(s) = {riešenia získané aplikáciou jednoduchých lokálnych zmien na s}. Mohutnosť N(s) môže byť veľmi veľká, čo môže spôsobiť výrazné spomalenie prehľadávania. Z tohto dôvodu sa obvykle používa iba časť celkového okolia aktuálneho riešenia. Metódy simulated annealing a threshold acceptance síce umožňujú vyskočiť z lokálneho optima, ich nevýhodou je ale to, že je možné dostať sa do stavu už navštíveného. To môže viesť k oscilácii okolo lokálneho optima a teda k situácii, kedy väčšina výpočtového času je braná v úvahu iba malá časť z množiny riešení. Práve metóda tabu search ponúka spôsob ako sa vyhnúť tomuto problému. Posledne navštívené riešenia ukladá do zoznamu dátovej štruktúry pevnej dĺžky nazývanej tabu list. Tabu zoznam je obyčajne implementovaný ako fronta (FIFO first-in-first-out), stará položka je zmazaná pri vkladaní novej položky. Práve z uvedených dôvodov som sa rozhodol pre implementáciu tabu search algoritmu. Algorithm 3 Tabu Search function TabuSearch (MaxMoves) tt = new Timetable() tt.getinitialtimetable() tabu_list.init() num_moves = 0 while tt.getscore() > 0 && num_moves < MaxMoves do N1 = tt.getneighbourhood1(p) N2 = tt.getneighbourhood2(p) best_move = najlepší presun z N1 N2, ktorý nie je v tabu_list alebo splňuje aspiračné kritérium tt.applymove(best_move) tabu_list.insert(best_move) tabu_list.deleteoldestmove() num_moves = num_moves + 1 end while return tt end TabuSearch 23

24 Pri rozvrhovaní budeme riešením rozumieť ľubovolný rozvrh. Na začiatku algoritmu získame počiatočné riešenie pomocou knihovne csp.lib.php (tt.getinitialtimetable()). Počas algoritmu sa budeme v iteráciách snažiť vylepšovať aktuálny rozvrh - v každej iterácii vyberieme a vykonáme najlepší presun z okolia súčastného riešenia (tt.applymove(best_move)). Práve vhodne zvolené okolie má významný vplyv na kvalitu lokálneho prehľadávania. Ukladať do okolia celé susedné riešenia (teda rozvrhy) by bolo zbytočné, preto sú do okolia ukladané iba jednotlivé presuny, ktoré vedú k susednému riešeniu. Okolie N definujeme ako zjednotenie dvoch okolí N1 a N2: N1 ako presuny položky z jedného timeslotu do iného voľného timeslotu (N1 = tt.getneighbourhood1(p)), N2 ako výmeny položiek medzi dvomi rôznymi timeslotmi (N2 = tt.getneighbourhood2(p)). Položky k presunu alebo výmene sú do okolí vyberané s pravdepodobnosťou P. Od tohto parametru teda závisí, aká časť okolia súčastného riešenia bude braná v úvahu. Prednosť pri výbere však majú položky porušujúce najviac tvrdých podmienok, aby sa tak znížil počet kolízií v rozvrhu. Takéto položky rozvrhu sú ukladané v prioritnej fronte podľa počtu tvrdých podmienok, ktoré porušujú. Ak už v rozvrhu neexistuje žiadna položka porušujúca tvrdú podmienku, algoritmus pokračuje znižovaním hodnoty ohodnocovacej funkcie mäkkých podmienok. Do tabu zoznamu je následne ukladaná buď presunutá položka spolu s timeslotom, z ktorého bola presunutá alebo obe položky, ktoré boli vzájomne vymenené medzi timeslotmi. V každej iterácii algoritmu sú povolené iba presuny, ktoré nie sú v tabu zozname alebo presuny splňujúce aspiračné kritérium 4. Za aspiračné kritérium som zvolil nasledujúcu podmienku: presun z tabu zoznamu sa vykoná, iba ak zlepšuje doteraz nájdené najlepšie riešenie. 4 odtabuizovanie presunu - presun možno uskutočniť, aj keď sa nachádza v tabu zozname; napríklad, ak presun vedie k celkovému zlepšeniu rozvrhu. 24

25 3.6 Priebeh a výsledky testov Pri testovaní generátora som sa zameral na sledovanie kvality rozvrhu pri zmene hodnôt parametrov algoritmu tabu search. Kvalitu som posudzoval podľa počtu medzier v rozvrhu. Ako testovacie dáta som použil dáta Gymnázia F.Švantnera (Nová Baňa) s nasledujúcim popisom: 8 tried - 4 ročníky po 2 triedy 17 učiteľov 274 položiek rozvrhu 2328 podmienok na učiteľov (učiteľ nemôže vyučovať dve hodiny naraz) 4717 podmienok na triedy a študentské skupiny (jedna trieda nemôže mať dve hodiny v rovnaký čas) 266 podmienok na predmety (predmet nemôže byť vyučovaný viackrát za jeden deň) Pretože vstupné dáta boli vždy rovnaké (menili sa iba parametre algoritmu tabu search), ani výsledky počiatočného riešenia generovaného knihovňou csp.lib.php sa nemenili: Čas výpočtu: 52s Počet kolízií v rozvrhu: 0 (pre problém CSP som zadal všetky tvrdé podmienky, preto výsledkom je rozvrh bez kolízií - prípustné riešenie) Počet medzier v rozvrhu: 32 Výsledky algoritmu tabu search sa pri zmenách jeho parametrov výrazne menili. Priebeh a výsledky sú zaznamenané v nasledujúcej tabuľke: 25

26 Čas Presun 6 Parametre výpočtu 120s 300s R 5 (čas presunu) M=10000, T=20, P=0.1 00:08: M=7500, T=15, P=0.2 00:20: (00:12:32) M=3000, T=15, P=0.3 00:12: (00:07:20) M=2500, T=15, P=0.4 00:13: (00:08:57) M=2000, T=15, P=0.5 00:13: (00:12:40) M=2000, T=15, P=0.6 00:15: (00:10:35) M=2000, T=15, P=0.7 00:18: (00:15:03) 771. M=2000, T=15, P=0.8 00:21: (00:08:45) 995. M=1500, T=15, P=0.9 00:16: (00:11:26) Parametre algoritmu tabu search predstavujú počet presunov (M), veľkosť tabu zoznamu (T) a pravdepodobnosť výberu presunu do okolia (P). Z vykonaných testov vyplýva, že na priebeh a výsledok algoritmu má podstatný vplyv nastavenie parametru P. Ten určuje ako veľké bude okolie, ktoré sa bude prehľadávať. Čím väčšia hodnota P, tým viac presunov bude braných v úvahu pre zlepšenie aktuálneho riešenia. Samozrejme sa tým zväčší prehľadávaný priestor, a tak porastie aj čas na vykonanie algoritmu. Čas, potrebný na vykonanie algoritmu, sa dá znížiť zmenou hodnoty parametru M, ktorý udáva počet uskutočnených presunov. Zmena dĺžky tabu zoznamu neznamenala výraznejšie zmeny výsledkov. Všetky testy boli uskutočnené na počítači s procesorom Intel Centrino Duo 1.83 GHz, 1 GB RAM, Windows XP. 5 R = result - počet medzier vo výslednom rozvrhu. 6 Udáva poradové číslo posledného presunu, ktorý znamenal zlepšenie rozvrhu. 26

27 Kapitola 4 Záver 4.1 Ako by išlo systém ešte vylepšiť Mnohé užitočné vylepšenia systému, ktorými by išlo projekt doplniť, nebolo možné implementovať pre veľkú rozsiahlosť projektu. Niektoré z nich by však výrazne uľahčili prácu užívateľov. Ide predovšetkým o tieto vylepšenia: Správa súborov (dokumentov a médií). Work-flow management. Správa zámkov. Môže nastať situácia, keď v danej chvíli dvaja užívatelia chcú editovať rovnakú položku (či už obsah, menu položku,...). Prvý z nich položku zmení a uloží do databázy. Druhý z nich, ktorý má ešte starý obsah položky, položku tiež zmení a uloží. Týmto prepíše zmenu prvého užívateľa bez toho, aby o tom vôbec vedel. Pre takéto situácie je potrebná správa uzamykania (check in) a odomykania (check out) práve editovaných položiek. Správa jazykov. Superadministrátorovi by dovolila zmenu jazyka systému a aj prípadné pridanie nových jazykov. Pridanie filtrov do správy užívateľov. Najmä študentov býva obvykle veľký počet, preto by bolo vhodné poskytnúť možnosť filtrovať užívateľov podľa mena, užívateľskej skupiny alebo triedy. Aj vyhľadávanie užívateľov bude týmto jednoduchšie. Poskytnúť vyhľadávanie vytvoreného obsahu podľa zadaných kritérií. 27

28 4.2 (Ne)interaktivita generátoru rozvrhu Dôležitým požiadavkom na generátor rozvrhu býva obvykle jeho interaktivita. Užívateľ má možnosť sledovať priebeh vytvárania rozvrhu a v prípade potreby do jeho tvorby zasahovať. Takýmto zásahom môže byť presunutie položky do iného timeslotu alebo výmena položiek medzi dvoma timeslotmi, prípadne oslabenie niektorých podmienok. To vyžaduje, aby generátor dokázal pokračovať so zmeneným zadaním a nezačínal vždy rozvrhovať od začiatku. Práve kvôli tejto požiadavke je implementácia interaktívneho generátoru, ktorého logika by bola umiestnená na webovom servery a ktorý by bol obsluhovaný cez webové rozhranie, dosť zložitá. V takomto prípade by bolo potrebné zaistiť zastavenie vykonávaného php skriptu (algoritmus tabu search), uloženie stavu výpočtu (napríklad do session premenných), uloženie zmien vykonaných užívateľom a pokračovanie výpočtu v pozastavenom stave. Ďalším problémom zvoleného prístupu, ktorý už nesúvisí priamo s interaktivitou, môže byť dĺžka vykonávania skriptu. Algoritmus generovania rozvrhu trvá aj niekoľko minút, naproti tomu obvyklá hodnota parametru max_execution_time 7 je 30 sekúnd. Jednou z možných alternatív by bolo vytvoriť generátor rozvrhu ako tučného klienta (fat client) v jazyku, ktorý podporuje prácu s vláknami. Takýmito jazykmi sú napríklad C# alebo Java. Podpora vlákien je veľmi užitočná práve pre implementáciu interaktivity - vlákno ide kedykoľvek pozastaviť, vykonať zmeny a potom pokračovať vo výpočte. Vygenerovaný rozvrh by bol týmto programom následne vyexportovaný do vhodného formátu (XML). Pre systém by sa vytvoril modul, ktorý by slúžil iba na import rozvrhu z XML a potom aj na jeho následné zobrazenie na webovej stránke. Tento modul by už rozvrh negeneroval. 4.3 Zhrnutie Bakalárska práca sa zaoberá tvorbou webovej aplikácie poskytujúcej správu obsahu webovej stránky. Prvé dve kapitoly sú zamerané na implementáciu samotného systému. Systém umožňuje základnú správu webového obsahu, správu užívateľov a špeciálny dôraz je kladený na jeho modularitu. 7 Parameter max_execution_time stanovuje hornú medzu doby v sekundách, po akú sa môže vykonávať jeden php skript. 28

29 V ďalšej kapitole je predstavený modul pre automatické generovanie rozvrhu pre základné alebo stredné školy. Umožňuje zadať iba základné požiadavky ako je dostupnosť učiteľov alebo rozdelenie tried do skupín. Algoritmus generovania rozvrhu je kombináciou technik na riešenie problému splňovania podmienok a algoritmu tabu search. Modul je možné rozšíriť novými požiadavkami podľa potreby konkrétnej školy a tiež implementovať iné algoritmy lokálneho prehľadávania. Za prínos považujem vytvorenie knižnice na riešenie problému splňovania podmienok, pretože sa dá použiť na rôzne problémy CSP, nie len na problém rozvrhovania. Naviac ako osobný prínos vidím to, že som získal skúsenosti s tvorbou webovej aplikácie a teoretické aj praktické znalosti o probléme rozvrhovania. Počas práce na projekte som získal skúsenosti, ktoré sa mi v budúcnosti určite budú hodiť. 29

30 Literatura [1] Barták R.: Constraint Programming What is behind?. In Figwer J. (editor): Proceedings of the Workshop on Constraint Programming in Decision and Control, Poľsko, jún [2] Barták R.: On-line Guide to Constraint Programming. ( ) [3] Brucker P.: Scheduling Algorithms, Springer, Osnabrück, [4] Csima J.: Investigations on a Time-Table Problem, Ph.D. thesis, School of Graduate Studies, University of Toronto, [5] Cooper T., Kingston J.: The Complexity of Timetable Construction Problems. ( ) [6] Darie C., Bogdan B., Cherecheş-Toşa F., Bucica M.: AJAX and PHP Building Responsive Web Applications, Packt Publishing, Birmingham,2006. [7] Even S., Itai A. and Shamir A.: On the complexity of timetable and multicommodity flow problems, SIAM Journal on Computing 5, str , [8] Glover F., Laguna M.: Tabu Search, Kluwer Academic Publishers, Boston, [9] Gotlieb C.: The Construction of Class-Teacher Time-Tables, In Proc. IFIP Congress, str , [10] Johnston P.: JavaScript MD5. ( ) 30

31 [11] Rossi-Doria O., Sampels M., Birattari M., Chiarandini M., Dorigo M., Gambardella L. M., Knowles J., Manfrin M., Mastrolilli M., Paechter B., Paquete L., Stutzle T.: A comparison of the performance of different metaheuristics on the timetabling problem. In Burke E., De Causmaecker P. (editors): Proceedings of the 4th international conference on the Practice And Theory of Automated Timetabling (PATAT 2002), str , Gent, [12] Vrána J.: Bezpečné přihlašování uživatelů, ( ) [13] Wikipedia: Challenge-response authentication. ( ) [14] Wikipedia: Web content management system. ( ) [15] Wren A.: Scheduling, timetabling and rostering a special relationship?, In Burke E., Ross P. (editors): Practice and Theory of Automated Timetabling, str , Springer-Verlag LNCS 1153,

32 Príloha A Užívateľská dokumentácia A.1 Systémové požiadavky Minimálne požiadavky, ktoré musí splňovať Váš webový server alebo poskytovateľ webhostingu: PHP 5.0.x alebo vyššie s rozšíreniami mysqli a gd2: MySQL 5.0.x alebo vyššie: Apache 2.0.x alebo vyššie: SIandCMS bol testovaný na systémoch Windows XP a Gentoo Linux, mal by však fungovať aj na iných platformách, ktoré splňujú uvedené minimálne požiadavky. Systém je optimalizovaný pre webové prehliadače Internet Explorer 7, Firefox 2 a Opera 9. A.2 Inštalácia Po uploade súborov na webový server pokračujte inštaláciou systému cez webový prehliadač. Zadajte URL systému spolu s inštalačným súborom installation/install.php (napríklad: Zobrazí sa stránka s požiadavkami na systém: 32

33 Obrázek A.1: Požiadavky na inštaláciu. Pokiaľ je daná požiadavka splnená, správa o nej sa zobrazí zelenou farbou, v opačnom prípade bude správa červená (ak je požiadavka nevyhnutná pre fungovanie celého systému) alebo oranžová (ak je požiadavka nevyhnutná iba pre fungovanie časti systému moduly, upload obrázkov,...). Po stlačení tlačítka Ďalej» inštalácia pokračuje nastavením MySQL spojenia: Obrázek A.2: Nastavenie spojenia MySQL databázy. 33

34 Pre nastavenie MySQL spojenia je nevyhnutné zadať názov hostiteľa, užívateľské meno a názov databázy. V prípade označenia políčka Naplniť demo dátami, budú do novovytvorenej databázy nahrané aj demo dáta. Po stlačení tlačítka Ďalej», pokiaľ nedôjde k chybe, sa vytvorí databáza s tabuľkami, pohľadmi a procedúrami; prípadne naplnená demo dátami. Nakoniec sa zobrazí formulár o úspešnom priebehu inštalácie: Obrázek A.3: Výsledok inštalácie. Zobrazia sa prihlasovacie údaje a varovanie, aby bol zmazaný adresár installation/. A.3 Správa menu položiek Je prístupná cez hlavné menu: Správa menu Umožňuje: Pridať novú menu položku(2) Zmazať menu položku(9) Vnorovať menu položky(1, 4, 3) Zmeniť názov menu položky(8 => 4) Zmeniť poradie menu položiek(8 => 5) 34

35 Zverejniť/nezverejniť menu položku(8 => 6) Nastaviť prístup pre obsah menu položky(8 => 7) Stránkovanie menu položiek(10) Obrázek A.4: Správa menu položiek. V prípade nastavenia prístupu(7) menu položky na hodnotu Internet, bude mať prístup k príslušnému obsahu menu položky každý návštevník webovej stránky. V prípade nastavenia prístupu menu položky na hodnotu Intranet, bude mať prístup k príslušnému obsahu menu položky iba registrovaný užívateľ. Ak je nastavená hodnota Zverejniť(6), daná menu položka sa zobrazí v menu na webovej stránke; v opačnom prípade sa nezobrazí. 35

36 A.4 Správa obsahu Je prístupná cez hlavné menu: Správa obsahu Umožňuje: Pridať obsah(1) Upraviť obsah(2 alebo 6) Zmazať obsah(7) Obrázek A.5: Správa obsahu. Stránkovanie zoznamu vytvorených obsahov(8). Každá položka zoznamu obsahuje okrem vlastného názvu(2) aj názov menu položky(3), pod ktorou sa daný obsah na webovej stránke zobrazí; meno autora(4), ktorý vykonal poslednú zmenu obsahu a aj dátum poslednej zmeny(5) Pre pridanie nového obsahu(1) alebo zmenu existujúceho obsahu(2 alebo 6) sa zobrazí nasledujúce okno: 36

37 Obrázek A.6: Editor pre vytváranie webového obsahu. V tomto okne môžete: Zadať názov obsahu(3) Prideliť obsah k menu položke, pod ktorou sa bude daný obsah zobrazovať na webovej stránke(4) Upraviť obsah(5) prostredníctvom WYSIWYG(What You See Is What You Get) editora TinyMCE ( v ktorom je integrovaný plugin pre jednoduhšiu správu a vkladanie obrázkov do webovej stránky Ajax File/Image Manager ( Manager/). Uložiť zmeny urobené v obsahu(1) Zrušiť zmeny urobené v obsahu(2) 37

38 A.5 Správa užívateľov Je prístupná cez hlavné menu: Správa užívateľov SIandCMS umožňuje priradiť užívateľa do jednej z troch užívateľských skupín: 1. Užívateľ nemá prístup do systému, ale má prístup na webovej stránke k obsahu, ktorý je v systéme pridelený k menu položke s prístupom Intranet(obyčajný návštevník webovej stránky k takémuto obsahu prístup nemá). 2. Administrátor má obmedzený prístup do systému. Má prístup k správe menu, k správe obsahu, a ak sa jedná o učiteľa, aj k správe žiakom, ktorým on je triednym učiteľom. 3. Superadministrátor má neobmedzený prístup do systému. Správa užívateľov sa delí na: správu učiteľov(1) správu žiakov(2) Obrázek A.7: Správa užívateľov. Oba zoznamy pre učiteľov aj pre žiakov majú rovnakú štruktúru. 38

39 Obrázek A.8: Zoznam učiteľov. Umožňuje: Pridať užívateľa(1). Upraviť informácie o užívateľovi(2 alebo 7). Zmazať užívateľa(8). Stránkovanie zoznamu vytvorených užívateľov(9) abecedne usporiadaný podľa celého mena užívateľa. Každá položka zoznamu obsahuje celé meno užívateľa(2), jeho login(3), užívateľskú skupinu(4), do ktorej patrí, triedu(5) a ovú adresu(6). Pre pridanie nového užívateľa(1) alebo zmenu už existujúceho(2 alebo 7) sa zobrazí nasledujúce okno: 39

40 Obrázek A.9: Zmena údajov o užívateľovi. Tlačitka 1 a 2 slúžia na uloženie resp. neuloženie prevedených zmien. Údaje o užívateľovi sú rozdelené do 4 skupín a niekoľkých polí. Údaje označené hviezdičkou sú povinné: 1. Prihlasovacie údaje (a) Login musí byť unikátny a jeho dĺžka musí byť aspoň 5 znakov. (b) Nové heslo jeho dĺžka musí byť aspoň 5 znakov. Ak chcete zmeniť niektoré údaje ale heslo chcete ponechať, tak nechajte prázdne pole. (c) Potvrď heslo musí sa zhodovať so zadaným heslom. 2. Práva (a) Skupina užívateľská skupina, do ktorej užívateľ patrí. (b) Trieda trieda, do ktorej žiak patrí alebo ktorej je učiteľ triednym. Zmeniť triedneho učiteľa pre danú triedu ide iba cez Správu tried!! 40

41 (c) Blokovať užívateľa možnosť zablokovať existujúcemu užívateľovi akýkoľvek prístup do systému alebo na webový obsah, ktorý sa zobrazuje pod menu položkou s prístupom Intranet. 3. Osobné údaje (a) Titul možnosť zadať titul je iba pre učiteľov, pri študentoch sa táto možnosť neobjaví. (b) Meno (c) Priezvisko (d) Dátum narodenia (e) (f) Telefón 4. Adresa (a) Ulica (b) Mesto (c) PSČ (d) Okres U žiakov sú naviac ďalšie dve skupiny údajov: 5. Rodič 1 (a) Titul (b) Meno (c) Priezvisko (d) (e) Telefón 6. Rodič 2 (a) Titul (b) Meno (c) Priezvisko (d) (e) Telefón 41

42 A.6 Správa tried Je prístupná cez hlavné menu: Správa tried. Správa tried sa delí na: Správu tried(1). Správu miestností(2). Správa miestností umožňuje: Pridať miestnosť(1). Obrázek A.10: Správa tried a miestností. Upraviť informácie o miestnosti(4). Zmazať informácie o miestnosti(5). Stránkovanie zoznamu miestností(6). Každá položka zoznamu obsahuje názov miestnosti(2) a kapacitu miestnosti(3). 42

43 Správa tried umožňuje: Pridať triedu(1). Upraviť informácie o triede(6). Zmazať informácie o triede(7). Obrázek A.11: Správa miestností. Stránkovanie zoznamu tried(8). Každá položka zoznamu obsahuje meno triedy(2), ročník(3), miestnosť(4) a meno triedneho učiteľa(5). Obrázek A.12: Správa tried. 43

44 A.7 Správa modulov Je prístupná cez hlavné menu: Správa modulov. Moduly rozširujú funkcionalitu SIandCMS. Takýmito rozšíreniami môžu byť kniha návštev, fórum, kalendár, fotoalbum, klasifikácia študentov,... Pre ukážku som vytvoril a zdokumentoval modul chat a modul slúžiaci na automatické generovanie rozvrhu pre základne alebo stredné školy. Každý modul sa skladá z dvoch častí: administrátorská časť zobrazuje sa v systéme. webová časť časť, ktorá sa zobrazuje na webovej stránke zobrazuje sa na mieste webového obsahu. Správa modulov umožňuje: Upload modulu z lokálneho počítača na server a inštaláciu modulu na serveri(1). Modul musí byť zbalený v archíve typu tgz, tbz, tar, zip, gz, gzip, bz2, bzip2. O tom, či bol modul nainštalovaný úspešne alebo či počas inštalácii došlo k chybe, sa superadministrátor dozvie zo správy, ktorá sa zobrazí tesne nad zoznamom nainštalovaných modulov. Administráciu modulu(2 alebo 4). Odinštalovanie modulu(5). Stránkovanie zoznamu nainštalovaných modulov(6). Každá položka zoznamu obsahuje názov modulu(2) a názov menu položky(3), pod ktorou sa bude na webovej stránke daný modul zobrazovať. 44

45 Obrázek A.13: Správa modulov. A.8 Chat Administrátorská časť modulu umožňuje: Zmeniť názov modulu. Priradiť modul k menu položke, pod ktorou sa bude na webovej stránke zobrazovať. Mazať správy chatu. Webová časť modulu umožňuje: Prístup iba pre registrovaných užívateľov. Základnú komunikáciu odosielanie a prijímanie správ chatu. Získavanie informácie zo serveru o užívateľoch, ktorí sú práve online. Výber užívateľa zo zoznamu online užívateľov, ktorému je správa určená. Nastaviť farbu odosielaných správ. A.9 Generátor rozvrhu Administrátorská časť modulu pozostáva z niekoľkých správ. 45

46 A.9.1 Správa predmetov Umožňuje: Zmeniť názov modulu. Obrázek A.14: Správa predmetov. Priradiť modul k menu položke, pod ktorou sa bude na webovej stránke zobrazovať. Mazať správy chatu. Pridať, mazať a upraviť vyučované predmety. 46

47 A.9.2 Správa dostupnosti vyučujúcich Obrázek A.15: Správa dostupnosti vyučujúcich. Umožňuje upraviť dostupnosť vyučujúcich počas dní v týždni. A.9.3 Správa položiek rozvrhu Obrázek A.16: Správa položiek rozvrhu. Umožňuje pridať, mazať a upravovať položky rozvrhu pre každú triedu. Pre každú položku sa vyberá predmet, učiteľ, miestnosť, dĺžka hodiny, počet hodín za týždeň, prípadne paralelne vyučované položky a popis tejto položky. 47

48 A.9.4 Správa generovaných rozvrhov Umožňuje: Obrázek A.17: Správa generovaných rozvrhov. Vykonať nové generovanie rozvrhov(1) spustiť nový výpočet. Zobraziť vygenerované rozvrhy daného výpočtu(2 alebo 8). Vymazať rozvrhy daného výpočtu(9). Vybrať rozvrhy výpočtu, ktorý je aktuálny(10) práve tieto rozvrhy budú prístupné na webovej stránke. Stránkovanie zoznamu vygenerovaných výpočtov(11). Každá položka zoznamu obsahuje id výpočtu(2), počet nesplnených tvrdých podmienok(3), počet nesplnených mäkkých podmienok(4), začiatok výpočtu(5), koniec výpočtu(6) a stav výpočtu(7). Po kliknutí na 2 alebo 8 sa zobrazí nasledujúce okno, kde sa dá vybrať rozvrh pre triedu alebo učiteľa. Rozvrh sa dá zobraziť aj v režime celej obrazovky. 48

49 Obrázek A.18: Rozvrh. 49