1 Bankovní institut vysoká škola Praha Katedra informatiky a kvantitativních metod Programová podpora pro tvorbu rozvrhu Diplomová práce Autor: Bc. Lu...
Bankovní institut vysoká škola Praha Katedra informatiky a kvantitativních metod
Programová podpora pro tvorbu rozvrhu
Diplomová práce
Autor:
Bc. Lukáš Babický Informační technologie a management
Vedoucí práce:
Praha
Ing. Vladimír Beneš, Ph.D.
duben, 2014
Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval samostatně a v seznamu jsem uvedl veškerou použitou literaturu. Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.
V Praze, dne 23. dubna 2014
Lukáš Babický
Poděkování: Rád bych na tomto místě poděkoval Ing. Vladimíru Benešovi, Ph.D., za jeho cenné rady a odborné vedení při přípravě této práce. Děkuji také rodině a přátelům za jejich veškerou podporu během celého mého studia.
Anotace Diplomová práce se zabývá tvorbou rozvrhu na vysoké škole pomocí programového vybavení. Teoretická část pojednává o programovacích jazycích a jejich rozdílech při vytváření konkrétních aplikací. Dále se pak zabývá různými omezeními, která musíme vymezit pro praktickou tvorbu rozvrhu. Praktická část se zabývá kompletním postupem vzniku programové podpory při vytváření rozvrhů. V první části se řeší víceuživatelský systém, který je navržen, naprogramován a nasazen při „ostrém“ provozu. Druhá část praktické roviny práce se zabývá analýzou zpracování přiřazení studentů k jednotlivým rozvrhovým akcím a návrhem na zlepšení podpory ze strany informačních technologií, jež by měla být více zautomatizována. Závěr práce je věnován zhodnocení celého postupu při vytváření rozvrhů a přínosu podpory jednotlivých programů. Klíčová slova:
Annotation My diploma thesis deals with the creation of a college schedule with the help of a programme software. A theoretical part dissertates programming languages and shows their differences when creating particular applications. The next part deals with various limitations which are necessary to be defined for the practical creation of a schedule/timetable. A practical part deals with an unabridged procedure of programme support designing when schedules/timetables are created. The first part tries to find a solution to a multiuser system which is designed, pre-set and applied in real operation. The second part deals with the analysis of processing the steps that are necessary to match students with particular scheduled events and also a proposal how to improve the information technologies support. It will be more automated. The conclusion of the thesis shows the assessment of the whole procedure when schedules are created as well as benefits of support of individual programmes.
Key words:
college schedule, scheduled event, timetable, subject, lecturer, regional workplace, head office, schedule editing, export and import of schedules, CSV file, database back-up
Obsah Úvod .....................................................................................................8 1 Stávající stav ..................................................................................9 1.1
Program Access ........................................................................................................... 9
1.2
Program GenerovaniHTML ....................................................................................... 11
1.3
Návrh nového řešení .................................................................................................. 15
1.3.1
Úprava stávajícího systému ................................................................................ 15
1.3.2
Koupě nového řešení .......................................................................................... 15
1.3.3
Vytvoření nového řešení pomocí vlastních zdrojů ............................................. 17
2 Programovací jazyk ....................................................................18 2.1
Nižší programovací jazyky ........................................................................................ 18
2.2
Vyšší programovací jazyky ....................................................................................... 18
Výběr programovacího jazyka ................................................................................... 19
3 Programovací nástroje ...............................................................20 3.1
Testovací provoz ........................................................................................................ 20
3.1.1
Serverová část ..................................................................................................... 20
3.1.2
Uživatelská (administrátorská) část .................................................................... 21
3.2
„Ostrý“ provoz ........................................................................................................... 22
4 Omezující kritéria .......................................................................23 5 Návrh rolí, uživatelských účtů a jejich pravomocí ..................27 5.1
Role administrátor...................................................................................................... 27
5.2
Role user .................................................................................................................... 32
5.3
Role vyučující ............................................................................................................ 33 5
5.4
Role student ............................................................................................................... 34
12 Příprava výpočtu úvazků vyučujících .......................................69 13 Zhodnocení přínosu práce ..........................................................72 Závěr ..................................................................................................73 Seznam použité literatury ................................................................74 Knižní publikace ...............................................................................75 6
Seznam obrázků ................................................................................76 Seznam tabulek .................................................................................77 Přílohy ................................................................................................78
7
Úvod Příprava rozvrhu je jednou z nejkomplexnějších a nejdůležitějších úloh, jež je zpracovávána v rámci vysokoškolského studia. Tato problematika se řeší napříč vysokoškolskými studii na celém světě. Základní pravidla jsou pro všechny školy totožná, ale každá škola má svá specifika, která je třeba zahrnout do vytváření rozvrhových akcí. Tématy této diplomové práce jsou popis procesů probíhajících při přípravě rozvrhových akcí a navržení programové podpory pro realizaci zjištěných procesů na Bankovním institutu vysoké škole. Nejprve je nutné zmapovat současný stav přípravy rozvrhových akcí pro celou školu včetně regionálních pracovišť. V práci bude rozebrán celý tento postup a možnosti navázání programové podpory pro daný postup. První část práce tvoří teoretický základ, pomocí kterého se vyřeší, jaký programovací jazyk bude využit, a vytyčí se omezení, která musíme dodržet při přípravě rozvrhových akcí. Druhá část je věnována praktickému řešení, které se skládá z analýzy, naprogramování a vlastního nasazení do „ostrého“ provozu školy. Prvním z cílů práce je stanovit, jakým způsobem bude realizováno nové řešení oproti řešení stávajícímu, které bylo vyhodnoceno jako nedostačující. Pro splnění tohoto cíle je nutné vybrat programovací jazyk, který bude vyhovovat vybranému řešení tak, aby splňovalo podmínku víceuživatelského přístupu ke všem rozvrhovým akcím. Druhým cílem diplomové práce je vyhodnotit, jaké podpůrné prostředky jsou potřeba ke zvolenému řešení dané problematiky. Tím je myšleno, že musíme rozhodnout, jestli bude nutné pořídit hardwarové vybavení a koupit licence pro software, který bude případně využíván pro dané řešení. Všechna řešení, která jsou v této práci popisována, jsou zvolena na základě souhlasu vedení Bankovního institutu vysoké školy, které je seznámeno se všemi dopady jednotlivých navržených řešení. Při výběru řešení za použití vlastních prostředků je třetím cílem navržení, naprogramování a nasazení systému v „ostrém“ provozu. V této práci jsou zpracovány možnosti přípravy rozvrhu tak, aby byly podpořeny všechny procesy, které jsou spojeny s přípravou a využitím rozvrhového plánování pro studenty, vyučující, personální a ekonomické oddělení. V závěru práce je shrnut přínos vytvořeného systému pro rozvrhy, jenž může být využit nejen pro rozvrhové akce na Bankovním institutu vysoké škole, ale i pro rozvrhové akce v celé České republice.
8
1
Stávající stav
Práce se zabývá problematikou vytváření rozvrhů na Bankovním institutu vysoké škole, a.s. Tato škola má několik středisek. Centrála školy se nachází v Praze a další, regionální pracoviště školy nalezneme v Teplicích, v Písku, v Karlových Varech a v Břeclavi. Problematika plánování rozvrhových akcí je v Bankovním institutu vysoké škole řešena individuální formou, tj. na každém jednotlivém pracovišti včetně centrály. Rozvrhové akce v Praze mají přednost před ostatními regionálními pracovišti. Nejdříve jsou tedy vytvářeny rozvrhy pro Prahu, kde jsou k jednotlivým rozvrhovým akcím přiřazeni vyučující, a poté vznikají rozvrhy v ostatních regionálních pracovištích. Toto pravidlo je uplatňováno s ohledem na fakt, že výuka v Praze je realizována v jedenácti oborech, zatímco v regionálních pracovištích jsou vyučovány většinou dva až tři obory, a dále z důvodu maximálního využití místností a propojení výuky jednotlivých oborů. K přípravě všech rozvrhů se využívají program Access, program pro vytvoření HTML souborů s rozvrhy z TXT souboru – GenerovaniHTML a program Adobe Acrobat, který převádí HTML soubory do PDF souborů.
1.1
Program Access
V programu Access se pomocí tabulky ROZVRH (obrázek č. 1) upravuje celá struktura pro všechny obory, předměty, vyučující a místnosti. V této tabulce jsou i záznamy, které zde byly vytvořeny v průběhu několika let a jsou schovány pomocí jednoho sloupce. Kvůli schovaným rozvrhovým akcím se stává tabulka nepřehlednou. Každý řádek značí jednotlivou rozvrhovou akci, která se vždy upraví tak, že se upraví příslušný sloupec značící požadovanou položku v daném řádku.
9
Obrázek č. 1: Tabulka databáze Access
Zdroj: Ing. Luboš Svárovský1 Příkladem může být změna učebny, která je svou kapacitou nedostačující pro přednášku daného předmětu. Pomocí filtru se vybere požadovaný předmět v daný čas a s požadovaným vyučujícím. V tomto řádku se opraví učebna tak, že se přepíše. V této tabulce nemáme žádnou možnost kontroly, která by zaručila, že učebna se nachází v budově, proto zde může dojít při nepozornosti k chybám. Všechny změny v rozvrhových akcích se v této tabulce upraví stejným způsobem. Po tomto kroku přepneme program Access do výběru s dotazy (obrázek č. 2) a spustíme double-klikem myši dotaz 11exp_genhtm, který vybere neschovaná data z tabulky ROZVRH a vytvoří novou tabulku EXPORT, kde budou pouze „čisté záznamy“. Tím jsou myšleny záznamy, které jsou opravdu zachyceny v jednotlivých rozvrzích, a nejsou mezi nimi záznamy, které jsou schované.
1
Upravil autor.
10
Obrázek č. 2: Dotaz databáze Access
Zdroj: Ing. Luboš Svárovský2 Tabulka EXPORT se vyexportuje do souboru EXPORT.TXT, kde budou jednotlivé sloupce odděleny středníkem. Tento soubor se dále načte pomocí programu GenerovaniHTML.
1.2
Program GenerovaniHTML
Program GenerovaniHTML (dále jen generátor) je program vytvořený Ing. Lubošem Svárovským v programovacím jazyce Visual Basic. Tento program slouží k tomu, aby jednotlivé řádky z programu Access převedl do souborů HTML tak, že v každém HTML souboru se zobrazí tabulka, která bude mít v horním řádku vyučovací hodinu a čas výuky a v levém sloupci bude mít den. U tabulky s mapou místností se v levém sloupci zobrazí jednotlivé místnosti. Jak je vidět na obrázku č. 3, dá se v generátoru nastavit jak vstupní cesta, která slouží pro načtení exportovaného souboru z Accessu, tak i výstupní cesta, která slouží pro export HTML souborů. Do této složky se budou vždy generovat vybrané rozvrhy skupin (oborů), místností, vyučujících, předmětů a mapy místností. Tabulka s mapami místností vytiskne celý požadovaný den seřazený dle místností, kde každý řádek bude značit jednu místnost.
2
Upravil autor.
11
Obrázek č. 3: Import do GenerovaniHTML
Zdroj: Ing. Luboš Svárovský3 Na obrázku č. 4 je vidět položka kontrola. Tato položka by měla kontrolovat případné kolize, které nastanou v jednotlivých rozvrhových akcích. Příkladem kolize může být více předmětů umístěných do jedné místnosti. Tuto kolizi by měla kontrola odhalit a rozvrhář by ji měl upravit v programu Access a poté by měl znovu vytvořit soubor pro import a načíst ho do generátoru. Bohužel, jak je na obrázku vidět, jsou zde vypsány i kolize, které vlastně neexistují. Např. řádky 22, 32, 40. Vše se shoduje kromě skupin (oborů). Nejdená se o kolizi, ale o předmět propojený mezi obory, protože se vyučuje ve třech oborech. Tato kolize by neměla být zaznamenána. Řádek je v databázi uveden schválně 3x, protože je nutné při výpisu rozvrhů vždy zahrnout výuku pro skupiny (obory). Není možné napsat všechny tři skupiny do sloupce pro skupinu, protože by se u jednotlivých oborů tato rozvrhová akce nevypsala. Generátor neumožňuje výpis akce pro jednotlivé obory, když je ve sloupci uloženo více oborů. Akce by se vypsala tehdy, kdyby se zobrazil rozvrh pro skupinu spojenou z více oborů
3
Upravil autor.
12
se stejným názvem skupiny, který by byl uložen ve sloupci programu Access, což nikdy nenastane. Obrázek č. 4: Kontrola rozvrhových akcí
Zdroj: Ing. Luboš Svárovský4 Na obrázku č. 5 je vidět, jak bude vypadat vygenerovaný rozvrh. Generátor vytváří soubory v HTML. Pro lepší přehlednost a čitelnost jsou u všech uživatelů rozvrhové soubory převáděny do PDF formátu a jsou vystaveny v informačním systému školy – IS BIVŠ – v dokumentovém serveru, kam mají přístup jednotliví studenti i vyučující. Obrázek č. 5: Rozvrh HTML z generátoru
Zdroj: Ing. Luboš Svárovský5
4
Upravil autor.
13
Tento postup je velice zdlouhavý. Když chce vyučující nebo skupina studentů zařídit nějakou změnu, tak celý postup zabere nejméně půl hodiny. Jelikož se při vytváření rozvrhů objevuje během dne i více změn, provádějí se vždy pouze v databázi a na konci dne se provádějí export a nahrání nových PDF souborů na dokumentový server. Jelikož se v Praze využívá rezervování místností přes IS BIVŠ, je nutné, aby se z programu Access exportoval soubor s jinou strukturou, kterou požaduje pro import IS BIVŠ. Do IS BIVŠ se musí při každé změně v databázi Access zavést nový soubor s importem, který přepíše všechny dosud vložené rozvrhové akce. Je tomu tak z důvodu zamezení rezervace místnosti pro nějakou jinou akci, když v dané místnosti právě probíhá výuka. Tento postup je realizován pouze v Praze. Na regionálních pracovištích jsou jednotlivé rozvrhové akce přepsány jednotlivými rozvrháři do řádků v Excelu v přesně definovaném pořadí sloupců, které vyžaduje generátor. Po vyplnění všech rozvrhových akcí je soubor programu Excel zaslán z každého regionálního pracoviště e-mailem do Prahy, kde jsou pomocí generátoru vygenerovány rozvrhy a poté jsou převedeny do PDF souborů a jsou vloženy do dokumentového serveru IS BIVŠ do příslušných složek regionálních pracovišť. Po provedení všech těchto kroků se musí jednotlivé soubory pro import regionálních pracovišť upravit tak, aby bylo možné je vložit do IS BIVŠ. Dále se všechny soubory vytvořené pro import včetně Prahy sjednotí do jednoho generálního souboru pro import a ten se naimportuje do IS BIVŠ. Tímto krokem jsou v informačním systému zablokovány místnosti podle časů a dnů tak, aby nebylo možné zarezervovat místnost, když je v dané místnosti již naplánována výuka. Všechny změny v rozvrhu se provádějí offline. Změny jsou vždy prováděny pouze v programu Access. Na konci dne jsou pak prováděny změny generovaných rozvrhů a změny v systému IS BIVŠ. Změny v rozvrzích na regionálních pracovištích jsou prováděny maximálně 1x do týdne. Vždy je pro zimní i letní semestr stanoven termín, který ukončuje možné změny v rozvrhu. Po tomto termínu je možná úprava pouze z vážných důvodů – nemoc vyučujícího apod.
5
Upravil autor.
14
1.3
Návrh nového řešení
Celá koncepce je velice zdlouhavá, offline, nepropojená mezi všemi pracovišti a v rámci ní nejsou kontrolovány překlepy ani plánování rozvrhových akcí tak, aby nedocházelo ke kolizím − např. jeden vyučující má učit více předmětů v jeden den a čas. Jelikož se v nemalém množství stává, že rozvrhové akce musí být nahrazovány z různých důvodů, které vyplývají z celé koncepce přípravy rozvrhů, tak bylo rozhodnuto, že se musí celý koncept přepracovat. Řešení mohou být tři: 1) úprava stávajícího systému, 2) koupě nového řešení – nový systém pomocí externího dodavatele, 3) vytvoření nového řešení – nový systém pomocí vlastních zdrojů. Celkové řešení bylo navrženo tak, aby bylo možné přistupovat k jednomu systému pomocí několika možných druhů uživatelských účtů. Tím je myšleno hlavně to, že musí být umožněno vytvářet rozvrh nejen pro Prahu, ale zároveň i pro regionální pracoviště. Tím se odstraní 100 % kolizí v duplicitě jednotlivých rozvrhových akcí.
1.3.1
Úprava stávajícího systému
Úprava stávajícího řešení a jeho jednotlivých fází poukazuje hned na několik problémů. Prvním z nich je, že není možné automatickým způsobem zabezpečit zápisy bez překlepů u jednotlivých položek v databázi Access. Druhým neřešitelným problémem je, že je program GenerovaniHTML vytvořen pomocí Visual Basic a zkompilován. Zkompilovaný program není možné dále upravit. Třetí překážkou je nemožnost vytvoření přístupu do programu Access online pro jiné osoby, než je rozvrhář, a zároveň pro více uživatelů v daný čas. Toto řešení by bylo vhodné pro regionální pracoviště, aby mohla vytvářet rozvrhy rovnou v databázi Access. Kvůli těmto poznatkům bylo rozhodnuto, že se nebude realizovat řešení, které by stávající strukturu pouze upravilo.
1.3.2
Koupě nového řešení
Byla provedena studie, která zjistila, že každá vysoká škola v České republice řeší své rozvrhové akce individuálně. Některé školy, jako je např. Vysoká škola ekonomická v Praze, mají svůj informační systém, který umožňuje, aby rozvrhář vypsal rozvrhové akce přímo v tomto systému a jednotliví 15
studenti se k těmto akcím přihlašovali. Toto je možné pouze u velkých vysokých škol s velkým množstvím paralelních skupin u předmětů, kde jsou zároveň vypsané určité počty skupin. Pokud se student nepřihlásí po spuštění přihlašování k rozvrhu, tak na něj nemusí zbýt volné místo a možnost se na danou rozvrhovou akci přihlásit. Další možnost je taková, že vysoká škola má svůj vlastní program, ve kterém rozvrhář vytvoří rozvrhy a po korekturách je naimportuje do informačního systému, který daná škola využívá. Tato možnost je realizována přímo na míru např. Vysokému učení technickému v Brně, takže pro potřeby Bankovního institutu vysoké školy není možné toto řešení využít, protože procesy VÚT se neshodují s procesy BIVŠ. Při vyhledávání univerzálního rozvrhového programu bylo zjištěno, že na trhu je pouze jediný program, který zvládne vytvořit jednotlivé rozvrhy pro celou školu. Tento program se jmenuje ROGER.6 Je to program, který umí sám vytvořit rozvrhy. Do tohoto programu se vloží pouze omezující podmínky, jako jsou počty hodin, místnosti, vyučující a jejich požadavky na dny popř. hodiny, předměty atd. ROGER sám po kliknutí tlačítka vytvořit (generovat) vytvoří jednotlivé rozvrhy. Jelikož je toto řešení desktopové, není možné jej využívat online. To zapříčiní, že není možné využívat víceuživatelské prostředí a zároveň online přístup. Dalším problémem u tohoto řešení je jeho cena. Vedení Bankovního institutu vysoké školy rozhodlo, že se toto řešení nebude realizovat z důvodu vysoké pořizovací a následné roční ceny. Tabulka č. 1: Cena za licenci programu ROGER7
Počet rozvrhových akcí
Ceny
Počet uživatelů xxxxxxxx
0–5
6–10
11–20
21 a více
0–180
trial
trial
trial
trial
180–500
40 000 Kč
60 000 Kč
80 000 Kč
100 000 Kč
500–1 000
60 000 Kč
80 000 Kč
100 000 Kč
120 000 Kč
1 000 a více
80 000 Kč
100 000 Kč
120 000 Kč
140 000 Kč
Zdroj: http://www.time-tables.com/cs/cenik
6
Zdroj: http://www.time-tables.com/cs/index.
7
Zdroj: http://www.time-tables.com/cs/cenik.
16
Jelikož počet rozvrhových akcí Bankovního institutu vysoké školy na jeden semestr je přibližně 1 000, tedy 2 000 rozvrhových akcí za rok, musela by se koupit licence za 80 000 Kč a následně by se muselo platit 20 % z této částky. Tyto náklady nebyly schváleny vedením Bankovního institutu vysoké školy a řešení bylo tedy zamítnuto.
1.3.3
Vytvoření nového řešení pomocí vlastních zdrojů
Jelikož bylo první a druhé řešení zamítnuto, realizace musí být provedena pomocí vlastních zdrojů – naprogramováním systému na míru. Vedením Bankovního institutu vysoké školy bylo rozhodnuto, že toto řešení bude naprogramováno pomocí interního zaměstnance a rozvrháře.
17
2
Programovací jazyk
Na základě potřeby vytvořit takový systém, který bude mít možnost přístupu pod více uživatelskými účty a online (tedy přes internet), je nutné zvolit nejvhodnější programovací jazyk, který by tyto požadavky zabezpečil. Nejprve je potřeba roztřídit a vybrat programovací jazyky, ve kterých je možné program pro vytváření rozvrhů naprogramovat.
2.1
Nižší programovací jazyky
To jsou jazyky, které ovládají přímo procesor, pro který je daný program vytvářený. Velkou výhodou je, že je možné tyto programovací jazyky optimalizovat pro určitou platformu, ale velkou nevýhodou je nepřenositelnost na jiný hardware – procesor. Mezi tyto programovací jazyky patří Assembler a strojový kód. Pro účely této práce není možné tyto jazyky využít, jelikož k nim není možný online přístup.
2.2
Vyšší programovací jazyky
Mezi vyšší programovací jazyky patří všechny jazyky s výjimkou Assembleru a strojového kódu. Na základě zadání této práce byly vybrány tři programovací jazyky, které splňují požadavky na realizaci: 1) C# 2) Java 3) PHP Každý z těchto programovacích jazyků má své výhody a nevýhody. Pro účely Bankovního institutu vysoké školy je nutné, aby jednotlivé jazyky umožnily přístup klient–server, tedy online přístup na server, a to z jakéhokoliv místa. Dalším požadavkem je, aby systém, který bude vypisovat rozvrhové akce, běžel na jakémkoli webovém prohlížeči, který je k dispozici v budově Bankovního institutu vysoké školy, nebo na jakémkoli počítačovém či mobilním zařízení studentů a vyučujících. Systém musí mít možnost úpravy i po dokončení. Pokud bude potřeba v budoucnu změna některé jeho části, musí být pozměnitelný – nesmí být zkompilován (zapouzdřen).
2.2.1
C#
C# je jazyk, který vytvořila firma Microsoft. Přebírá některé části z programovacích jazyků C++ a Java. Je to objektově orientovaný jazyk, ve kterém mohou být naprogramovány 18
dynamické webové stránky, které komunikují přes webový prohlížeč u klienta s webovým serverem. Pro vytvoření nějakého programu se využívá vývojové prostředí Visual Studio od firmy Microsoft. Vývojové prostředí Visual Studio požaduje k využívání licenci, která není zdarma.
2.2.2
Java
Java je objektově orientovaný jazyk, který umožňuje programovat bez nutnosti znalosti OOP. Vyžaduje oproti ostatním programovacím jazykům vyšší hardwarové nároky. Proto se tento jazyk využívá ve většině případů pro velké a složité projekty, které jsou vždy podpořeny vysokým hardwarovým výkonem. Výhodou tohoto jazyka je, že je nezávislý na platformě. Nevýhodou tohoto programovacího jazyka je nutnost nainstalovat podporu na každém počítači, na kterém bude vytvořený program využíván. Bez této podpory není možné využívat žádné zařízení jako klienta, který se připojuje k serveru.
2.2.3
PHP
Programovací jazyk PHP využívá jak procedurální, tak objektově orientované programování. Umožňuje komunikaci klienta se serverem pomocí webového prohlížeče. Jako vývojové prostředí je možné využít jakýkoliv program pro psaní textu. Pro psaní PHP kódu se dá využít např. PSPad, který pomáhá kontrolovat syntaxi. Výhodou tohoto jazyka je nezávislost na platformě. Všechny dnešní webové prohlížeče podporují jazyk PHP.
2.3
Výběr programovacího jazyka
Jelikož byla jako hlavní priorita při tomto výběru zvolena minimalizace nákladů, musí se z výběru vyřadit jazyk C#, protože pro jeho chod a vývoj by bylo zapotřebí koupit vývojové prostředí a serverové licence od firmy Microsoft. Zbývá tedy jazyk Java a PHP. Rozhodování mezi těmito dvěma jazyky je jednoduché. Na základě bezpečnostních pravidel Bankovního institutu vysoké školy není možné na počítače instalovat jakýkoliv software bez povolení administrátora. Z tohoto důvodu byla Java jako programovací jazyk odstraněna z výběru. Naproti tomu PHP jazyk nepotřebuje placené vývojové prostředí, není nutné cokoli instalovat na koncové zařízení a není nutné zakoupit licenci na provoz serveru.
19
3
Programovací nástroje
Po zvolení PHP jako programovacího jazyka je potřeba specifikovat hardwarové a softwarové požadavky. Aby bylo možné začít programovat v PHP, je nutné vlastnit klientskou část, která zahrnuje vývojové prostředí a webový prohlížeč, a serverovou část, která zahrnuje server, kde je nainstalován Apache8 s podporou databáze MySQL, protože jednotlivé rozvrhové akce a další potřeby s nimi spojené budou uloženy v databázi. Celý systém pro rozvrhování akcí je nutné nejprve naprogramovat, testovat a teprve potom je možné zpřístupnit ho uživatelům. K tomuto účelu je nutné rozlišit „testovací“ a „ostrý“ provoz. „Ostrým“ provozem je myšlen realizovaný, otestovaný a funkční provoz pro žádoucí uživatele.
3.1
Testovací provoz
Testovací provoz slouží programátorovi k vytvoření nebo úpravě nějakého programu nebo jeho části. Testovací provoz je úplně oddělený od „ostrého“ provozu. Každý z těchto provozů má svůj server a své klienty. Funkční program je nejprve testován bez vědomí uživatelů v „ostrém“ režimu. Při počátku programování se využívá pouze testovací provoz, protože „ostrý“ provoz není zatím spuštěn.
3.1.1
Serverová část
Serverová část testovacího provozu se liší od serverové části „ostrého“ provozu tím, že není na vzdáleném serveru, ale je na stejném počítači jako uživatelská část. Server Apache s podporou databáze MySQL je možné nainstalovat na jakémkoli počítači. Nezáleží na platformě, protože každá platforma má možnost nainstalovat nějaký freewarový program, který nahradí vzdálený server. Pro programovací účely je zapůjčen notebook HP Compaq 6730s, s procesorem Intel Pentium Dual-Core T3400, s frekvencí 2,16 GHz, RAM 2 GB DDR2 800 MHz a operačním systémem Windows XP. Jelikož již byl v tomto operačním systému vyzkoušen rozvrhářem program XAMPP,9 který splňoval dvě kritéria – byl zdarma a byl plně funkční – byl zvolen jako testovací server. Program po instalaci vytvoří na disku C:
8
Apache je softwarový webový server, který dodává webové stránky klientům (internetovým prohlížečům).
složku „xampp“ a v této složce vytvoří složku „htdocs“. Jelikož je možné provozovat několik testovacích režimů najednou, je vhodné ve složce „htdocs“ vytvořit ještě jednu složku, kam se budou ukládat jednotlivé soubory programovaného systému k jednotlivým projektům. Ve složce „htdocs“ je tedy ještě vytvořena složka „rozvrh“.
3.1.2
Uživatelská (administrátorská) část
Po instalaci XAMPPu je možné přistupovat k němu pomocí webového prohlížeče, jako je tomu na obrázku č. 6. Obrázek č. 6: XAMPP – úvodní obrazovka
Zdroj: autor Při vypsání URL adresy „http://127.0.0.1/rozvrh“ se vyhledá soubor „index.html“ nebo „index.php“. Po nalezení jednoho z těchto souborů se zobrazí přihlašovací obrazovka, která bude požadovat „Login“ a „Heslo“. Pokud tento soubor není vytvořen, prohlížeč vypíše „Soubor nebyl nalezen“. Při programování jednotlivých součástí je využíván již zmíněný PSPad – textový editor, který je nápomocen s úpravou syntaktických chyb programovacího jazyka PHP, HTML a CCS. Tento program má tři nejdůležitější vlastnosti požadované od tohoto projektu – je zdarma, je vyzkoušen a je doporučen specialistou studentského informačního systému. Jak je vidět na obrázku č. 8, umožňuje PSPad nápovědu při psaní kódu.
21
Obrázek č. 7: PSPad
Zdroj: autor Pro lepší orientaci v kódu je umožněno např. při kliknutí kurzoru zobrazení párových tagů, jež jsou tak lépe viditelné ve víceřádkovém kódu.
3.2
„Ostrý“ provoz
„Ostrý“ provoz se od testovacího liší dvěma hlavními rozdíly. Serverová část je na vzdáleném pronajatém serveru a je přístupná všem uživatelům, kteří mají potřebný uživatelský účet. Vzdálený server pracuje podobně jako server testovací s tím rozdílem, že se musí na tento server nahrávat pomocí FTP klienta již otestované soubory. Pro nahrání otestovaných a funkčních souborů je využíván webový FTP klient. Pro nahrávání souborů je využíván webový FTP klient NET2FTP na adrese: http://www.net2ftp.com/index.php. Samotný „ostrý“ provoz je spuštěn na serveru „anastacia.gransy.com“ od společnosti G-Hosting.cz. Tato společnost byla zvolena ze tří důvodů. Webový hosting u této společnosti patří mezi nejlevnější na českém trhu. Díky předchozím projektům rozvrháře a programátora jsme získali slevu na další webový hosting, který bude založen u výše zmiňované společnosti. Posledním a nejpádnějším důvodem je vyzkoušená, 99% dostupnost a spolehlivost serveru od této společnosti.
22
4
Omezující kritéria
Jako u každého nového projektu je nutné před začátkem vytváření programu stanovit a připravit omezující pravidla, která budou řídit a modifikovat chod celého programu. Maximální počet učeben Při vytváření rozvrhu je nutné určit, kolik učeben je možné využít v jeden okamžik najednou. V BIVŠ je možné využít 16 klasických učeben a 2 počítačové učebny najednou. Bohužel toto není jediná podmínka vytvoření rozvrhu pro školu. Z 16 klasických učeben jsou 3 velké (120 míst), 3 střední (80 míst) a 10 malých (30–40 míst). Vedle této omezující podmínky je nutné znát počet studentů na daný kurz, aby se do učeben vešli. Na některých školách se občas rozvrhuje do místnosti větší počet studentů, než jaká je kapacita místnosti. O této možnosti studijní řád BIVŠ neuvažuje. Počet výukových dní Jelikož je velice neefektivní propojovat prezenční a kombinovanou výuku, prezenční výuka bude probíhat ve dnech pondělí až čtvrtek. Pro kombinovanou výuku tedy zbývají pátek a sobota, popř. neděle, jak to je již v praxi zavedeno na některých regionálních pracovištích. o Prezenční výuka
Semestr pro prezenční studium má 12 týdnů. Rozvrh pracuje s týdenní periodou.
o Kombinovaná výuka
Vedením BIVŠ bylo rozhodnuto, že kombinované studium může mít maximálně 12 vyučujících dní. Na každý týden prezenční výuky připadá z 90 % jeden vyučovaný den kombinované výuky. Tzn., že na každý týden připadá jeden pátek nebo sobota. Ve výjimečných případech se vyučují dva dny v týdnu. Počet pátků nesmí přesáhnout více než polovinu rozvrhových dní. Jelikož je výuka rozložena mezi více regionálních pracovišť, nejsou podmínky nastaveny pokaždé stejně. Na některých regionálních pracovištích se vyučuje i v neděli.
23
Předcházení kolizním situacím V původním programu nebyla možná jakákoli kontrola kolizních situací nebo zamezení jejich vzniku při rozvrhování akcí. Proto je nutné všechny možnosti vzniku kolizí specifikovat a zakomponovat je do návrhu. Podmínky pro eliminaci kolizních situací: 1) Zamezení zápisu rozvrhové akce vyučujícímu, který již v danou dobu má výuku. 2) Zamezení zápisu rozvrhové akce do místností, kde již je v danou dobu výuka plánována. 3) Zamezení zápisu rozvrhové akce pro skupinu (obor), která již má v danou dobu výuku naplánovánu. V třetím bodě při eliminaci je možné učinit výjimku. Týká se to jazyků, resp. povinně volitelných předmětů. Každý student si může zvolit pouze jeden povinně volitelný předmět, proto je možné, aby byly jazyky, resp. povinně volitelné předměty, vyučovány ve sdíleném čase. Manipulace s položkami v rozvrhu Pro celkový chod programu je nutné definovat, jaké bude obsahovat položky a jak se s nimi bude manipulovat. Položky, které jsou nutné k vytvoření rozvrhu: 1) místnosti, 2) předměty, 3) vyučující, 4) skupiny (obory), 5) budovy. Každá z uvedených položek umožňuje vytvoření, zrušení a modifikaci dané položky. Začátek a konec semestru Celý systém musí obsahovat letní i zimní semestr společně, aby položky 1–5 nemusely být duplikovány pro každý semestr zvlášť a nemusela být udržována duplikovaná databáze. Dalším důvodem, proč jsou v systému zaznamenány oba semestry, je výpočet úvazků, které se počítají v průběhu celého roku. Ze zmiňovaných důvodů je nutné začátek a konec semestru rozdělit na letní a zimní semestr. Každý ze semestrů je ještě dále dělen na jednotlivé ročníky, protože začátky a konce semestrů nejsou napříč ročníky stejné. Např. letní semestr třetího
24
ročníku bakalářského studia končí dříve než v prvním a druhém ročníku, protože je zkrácen o dva týdny z důvodu statní závěrečné zkoušky. Úprava dat pro nové časové období Tato položka je také rozdělena na zimní a letní semestr a je jednou z nejdůležitějších pro vytváření rozvrhů v následujících letech od zavedení systému. Pomocí přepočítání dat je možné vytvořit předběžnou stavbu rozvrhu nového semestru pomocí starého semestru během několika vteřin. Tím se rozumí přesun ze starého semestru do nového, kde budou srovnány začátky a konce semestrů s ohledem na jejich data, ale dny zůstanou stejné. Prohlížení, resp. editace rozvrhů Jako je tomu u přepočítání dat, je nutné i povolení editace a prohlížení rozvrhů rozdělit na letní a zimní semestr z důvodu chodu jednoho semestru a možných úprav druhého. Oba mají stejné položky, které zahrnují editaci semestru, povolení procházení rozvrhů pro studenty a vyučující. Když je semestr v přípravě rozvrhování, není žádoucí, aby byl rozvrh zveřejněn studentům a vyučujícím. Nejprve je připravován rozvrh pro Prahu, proto není možná editace v regionálních pracovištích. Po dokončení příprav v Praze se povolí editace rozvrhů v regionálních pracovištích. Vždy je stanoveno datum, do kterého musí být rozvrhové akce připraveny, aby bylo možné následně povolit náhled pro vyučující, kteří mohou požadovat od jednotlivých rozvrhářů změny. Období změn je také limitováno datem, do kterého jsou změny možné. Po tomto datu se rozvrh zveřejní i pro studenty. Pokud budou po zveřejnění rozvrhu studenti požadovat změny v rozvrhu, musí je povolit rektor školy. Zamezení zobrazení, resp. editace zimního semestru, je vždy provedeno před přípravou nového zimního semestru. Postup je stejný i v případě letního semestru. Identifikace výukové aktivity číselným kódem Každý rozvrhář z jednotlivých regionálních pracovišť má k dispozici omezenou množinu číselných kódů. Z logiky věci vyplývá, že celá množina číselných kódů bude obsahovat právě čtyři podmnožiny (viz tabulka č. 2). Tabulka č. 2: Kódování rozvrhových akcí
Kód
Forma studia
Rozvrhová akce
1)
01–10
prezenční
přednáška
2)
11–20
prezenční
cvičení
3)
21–30
kombinovaná
přednáška 25
4)
31–40
kombinovaná
cvičení Zdroj: autor
Byla provedena analýza předchozích let, z níž bylo zjištěno, že rozsah zobrazený v tabulce č. 2 je dostačující pro přípravu budoucích rozvrhů pro centrálu, resp. jedno regionální pracoviště. Dodatečné změny v rozvrhu: o Kombinované studium
Po zveřejnění rozvrhů pro studenty je možnost změny pouze v rámci dne, protože studenti si plánují dovolené, a není tedy žádoucí měnit naplánované dny. Je možné měnit výuku v rámci vypsaných dnů. Pouze v případech, kde neexistuje jiné východisko, je povoleno přidat či odebrat naplánovaný den. Toto není kontrolováno programově, ale pouze lidským faktorem.
o Prezenční studium
Pro prezenční studium je možné provádět změny v rámci dní pondělí– čtvrtek, ale není žádoucí, aby po přesunu vznikaly několikahodinové prostoje mezi jednotlivými hodinami. Vše je kontrolováno pouze rozvrhářem.
Zákaz spojení předmětu v letním semestru Důležitým aspektem je fakt, že není možné spojovat předměty třetích ročníků bakalářského studia s předměty nižších ročníků. Jelikož je třetí ročník ukončen o dva týdny dříve, než je tomu u nižších ročníků, není možné spojit identický předmět, protože látka pro třetí ročník musí být vysvětlena v deseti vyučovacích týdnech oproti nižším ročníkům, ve kterých jsou tyto předměty vyučovány ve dvanácti týdnech. Tato podmínka je uplatnitelná pouze pro prezenční studium. Kombinované studium je možné spojit, když se výuka naplánuje do konce desátého vyučovacího týdne. Další omezení Další omezující podmínky není nutné přesně specifikovat, protože ve většině případů jsou variabilní. Mezi tyto variabilní podmínky patří např.: o eliminace prostojů (v čase), o požadavky vyučujících. 26
5
Návrh rolí, uživatelských účtů a jejich pravomocí
Návrh rolí je nutné provést na začátku celého projektu. Celý systém je tvořen čtyřmi typy rolí: Tabulka č. 3: Role v systému
Role
Určeno pro uživatele
1)
Administrátor Administrátor systému
2)
User
Rozvrhář regionálního pracoviště
3)
Vyučující
Všichni vyučující
4)
Student
Všichni studenti Zdroj: autor
Každá z těchto rolí má přesně stanovené možnosti používání. Po celou dobu přihlášení jakékoliv role nebo uživatelského účtu bude v pravém horním rohu pod hlavičkou webu vypsaný červeným písmem účet, který je momentálně přihlášen.
5.1
Role administrátor
První role, která je využívána v systému pro vytváření rozvrhů, je role administrátor. Je nadřazena všem rolím a není možné ji smazat. Umožňuje zamezení přístupu do systému všem ostatním rolím, což je používáno v případě, kdy je nutné provést upgrade systému nebo rozsáhlou opravu. Umožňuje vytvářet další uživatelské účty do role user. Rolím pozorovatel a student může role administrátor zamezit zobrazení rozvrhů pro zimní i letní semestr. Uživatelským účtům pod rolí user nemůže zamezit zobrazení rozvrhů, ale může zamezit editaci. Hlavní funkcí role administrátor je řízení přípravy rozvrhů pro jednotlivé semestry. Celé řízení je rozděleno na čtyři části: Rozvrh V první části nazvané rozvrh jsou umožněny zobrazení, zápis, změna a smazání rozvrhových akcí. Pro tyto úkony slouží pět položek, které umožňují náhled vždy z jiného pohledu. Administrátorská role má neomezené možnosti pro editaci jakékoli rozvrhové akce. Všechny rozvrhové akce mohou být tímto uživatelským účtem změněny. Má možnost změnit
27
rozvrhové akce i pro všechna regionální pracoviště, tedy za roli user. Pohledy, ve kterých je možné rozvrhy měnit, jsou tyto: o Mapa místností
Slouží pouze pro zobrazení rozvrhů všech místností v centrále a na daných regionálních pracovištích v jeden konkrétní vybraný den.
o Místnost
Umožňuje zobrazení a editaci všech rozvrhových akcí ve vybraném semestru a místnosti po dobu celého semestru.
o Předmět
Umožňuje zobrazení a editaci všech rozvrhových akcí ve vybraném semestru a předmětu po dobu celého semestru.
o Skupina
Umožňuje zobrazení a editaci všech rozvrhových akcí ve vybraném semestru a skupině po dobu celého semestru.
o Vyučující
Umožňuje zobrazení a editaci všech rozvrhových akcí ve vybraném semestru a předmětu po dobu celého semestru.
Ve všech pohledech, které je možné editovat, bude výuka rozdělena na prezenční a kombinovanou formu, protože v prezenční a kombinované formě se budou lišit vyplnitelné položky. Po přepnutí do editace musí mít prezenční výuka rozsah mezi daty, a bude se tedy volit mezi každým sudým a lichým týdnem. Kombinovaná výuka musí mít oproti prezenční vždy přesné datum, proto se bude vybírat ze všech dat z celého semestru. V celém systému je rozložení barev u výpisu rozvrhu stejné. Modrá barva značí kombinované studium, žlutá barva prezenční výuku každý týden, oranžová barva výuku každý lichý týden a zelená barva výuku každý sudý týden. Sudý a lichý týden je řízen podle kalendářního týdne, nikoli podle číselného označení počtu týdne v semestru. Editace položek k rozvrhu Druhá část oprávnění administrátorské role slouží k vytvoření datové základny a organizace celého semestru pro jednotlivé rozvrhové akce. Pro vytvoření datové základny je využíváno pět položek, pro organizační řád celého semestru se využívá položka úprava semestru. o Budovy
28
Pro import do IS BIVŠ je nutné vždy evidovat, v jaké budově se vyučuje. Tím se oddělí všechna pracoviště. K jednotlivým budovám jsou dále přiřazeny místnosti, které se v těchto budovách nacházejí. Vše musí mít názvy shodné s názvy, jaké jsou uvedeny v IS BIVŠ.
o Místnost
Pro vytvoření místnosti je nutné znát položky: název, kapacita, typ místnosti (klasická nebo počítačová), projektor (ano, nebo ne), regionální pracoviště a budova. Je nutné zajistit, aby systém neumožnil místnost smazat, když bude v místnosti plánována alespoň jedna rozvrhová akce v letním nebo zimním semestru.
o Předmět
Pro vytvoření nového předmětu je nutné zadat kód a název předmětu, který je uložen v IS BIVŠ. Opět je nutná kontrola, která neumožní smazat předmět, který má plánovánu alespoň jednu rozvrhovou akci v zimním nebo letním semestru.
o Skupina
Pro vytvoření skupiny je nutné znát položky: název, typ (prezenční nebo kombinované studium) a pracoviště skupiny. Smazání nesmí být povoleno, pokud bude ke skupině přiřazena alespoň jedna rozvrhová akce v letním nebo zimním semestru.
o Vyučující
Pro vytvoření vyučujícího je nutné mít k dispozici položky: jméno, UČO (unikátní číslo osoby – generuje se při založení osoby v IS BIVŠ), katedra, pod kterou vyučující patří, a informace o tom, jestli je daný vyučující externista, nebo internista. Všechny informace jsou povinné. Jestliže bude požadováno smazání některého vyučujícího, je nutné zrušit všechny plánované akce, které jsou uloženy v zimním nebo letním semestru. Vyučující se velice často u výuky proměňují, proto je nutné jednou za rok po skončení letního semestru vymazat vyučující, kteří již nemají plánovanou žádnou výuku.
o Úprava semestru
Úprava semestru je vytvořena pro organizační řád obou semestrů. Úprava semestru musí být členěna na letní a zimní, aby byla zachována kontrola každého semestru zvlášť. 29
Zimní a letní semestr musí řešit tyto úkony: 1) Nastavení začátku a konce semestru o V zimním semestru je délka semestru napříč všemi ročníky stejná, ale je možnost uložit pro každý ročník výuky různý začátek a konec semestru. Tzn., že je povoleno nastavit začátek prvního ročníku např. o 14 dní déle než začátek zimního semestru v ostatních ročnících, a tím pádem bude i konec semestru pro první ročník posunut o 14 dní. o V letním semestru je u jednotlivých ročníků délka semestru různá v závislosti na typu studia (bakalářské nebo magisterské). Z tohoto důvodu je nutné rozlišit nejen začátek a konec jednotlivých ročníků, ale i jednotlivých ročníků vázaných na typ studia. V prvních ročnících neexistuje rozdíl, ale druhý ročník bakalářského studia má 12 týdnů oproti 10 týdnům ve druhém ročníku magisterského studia. Magisterské studium nemá třetí ročník a bakalářské studium ve třetím ročníku má také 10 týdnů jako druhý ročník magisterského studia. Z těchto důvodů je nutné evidovat začátek semestru nejen napříč ročníky, ale i napříč typem studia. 2) Migrace dat o Migrace dat umožní přesun starého semestru do nového, a tím vytvoří celý nový rozvrh pro nový semestr. Přesunovat se bude zimní semestr do zimního a letní do letního. 3) Povolení nebo zakázání editace semestru o Tato možnost bude využívána pro zamezení editace roli user – tedy všem uživatelským účtům v této roli. Toto bude využíváno pro přípravu organizace semestru. Po nastavení všech mezníků bude editace povolena. 4) Zobrazení nebo skrytí rozvrhů pro vyučující o Po domluvě s katedrami a všemi regionálními pracovišti je nutné zpřístupnit rozvrhy vyučujícím, kteří si mohou zažádat o změny. Zde bude možné rozvrhy pro vyučující zveřejnit. 5) Zobrazení nebo skrytí rozvrhů pro studenty o Po uplynutí data pro ukončení volných změn v rozvrhu je možné zveřejnit rozvrhy pro studenty, kteří také mohou požádat o nějaké změny. Jakmile jsou rozvrhy zveřejněny pro studenty, změna výuky může být již jen minimální a smí proběhnout pouze se souhlasem rektora. 6) Smazání rozvrhů regionálních pracovišť
30
o V minulosti byla praxe v regionálních pracovištích taková, že se vždy vytvářely rozvrhy nové. Nebylo tedy žádoucí, aby byly rozvrhy migrovány a upravovány z minulého období. Pokud bude toto vyžádáno z některého regionálního pracoviště, bude možnost veškeré rozvrhy daného regionálního pracoviště smazat. Zvláštní úkol, který je nutné řešit v zimním semestru, jsou vánoční svátky. Zde je nutné stanovit, od jakého do jakého dne nebude probíhat výuka, pokud bude konec výuky až v lednu. Tisk a výpis Třetí část role administrátor se zabývá importy do IS BIVŠ a tiskem rozvrhů pro zálohu. Do IS BIVŠ je nutné importovat tři soubory pro konečnou podobu rozvrhu. První soubor pro import je výpis všech skupin předmětů a k nim jsou přiřazeni vyučující. Druhý soubor je samotný rozvrh, který obsahuje k jednotlivým skupinám předmětů položky: budovu, místnost, typ výuky (prezenční či kombinovaná), čas výuky, den výuky a obory, pro které je předmět určen. Třetí soubor je pouze nápomocný pro poslední import do IS BIVŠ. Ze systému pro vytváření rozvrhů je nutné vytvořit seznam seminárních skupin předmětů s poznámkou o jednotlivé seminární skupině a oborem, ke kterému tato skupina patří. Ke každé jednotlivé seminární skupině předmětu je nutné v Excelu přiřadit skupinu studentů, kteří budou danou seminární skupinu navštěvovat. Systém IS BIVŠ přijme pouze soubory s koncovkou TXT nebo CSV a všechny importy musí mít přesnou strukturu, podle které probíhá kontrola a případné nahrávání do IS BIVŠ. Ostatní Poslední část pravomocí role administrátor slouží pro správu rolí a výpočtu úvazků vyučujících. Role administrátor umožňuje zamezit přístup všem ostatním rolím. Pro role student a vyučující je to jediná manipulace, kterou může role administrátor vykonávat. Pro roli user může administrátor změnit heslo, tak jako pro roli administrátor. Dále je pro roli administrátor žádoucí, aby mohla vytvářet nebo mazat uživatelské účty s rolí user. Pro kontrolu naplnění úvazků vyučujících je nutné vypisovat, kolik hodin kdo učí, na jakém regionálním pracovišti, v jakém jazyce a v jaké formě (prezenční nebo kombinovaná). Pro tyto účely je nutné mít možnost vytvořit CSV soubor se všemi těmito požadavky za každý semestr odděleně, ale i dohromady.
31
5.2
Role user
Role je vyhrazena pro rozvrháře v regionálních pracovištích. Každé regionální pracoviště (rozvrhář) potřebuje svůj vlastní user účet. Tento účet se skládá ze třech písmen, která charakterizují město daného regionálního pracoviště. Příkladem může být regionální pracoviště v Teplicích, jehož uživatelský účet bude vytvořen s názvem „tep“. Tímto způsobem jsou vytvořeny všechny účty v roli user pro všechny rozvrháře. Po přihlášení rozvrháře do systému je k dispozici pouze první část pravomocí role administrátora, a to tehdy, když je rolí administrátora povolena editace. Pokud není povolena editace, je po přihlášení uživatelského účtu role user první část pravomocí pouze v režimu prohlížení. Při povolené editaci bude moci daný uživatelský účet vytvářet nové rozvrhové akce. Editovat či mazat bude moci pouze takové rozvrhové akce, které jsou vytvořeny pod tímto uživatelským účtem. Tím se zamezí tomu, aby si rozvrháři upravovali navzájem nějaké naplánované akce. Jednotlivé úpravy rozvrhů bude možné dělat přes tyto pohledy: Vyučující o Ke každému vyučujícímu lze přidat novou rozvrhovou akci. Editovat nebo mazat bude možné pouze v případě, že byla vytvořena pod účtem, pod kterým je daný rozvrhář přihlášen. Předmět o Z pohledu předmětu jsou k dispozici všechny předměty v databázi. Jinak platí stejná pravidla pro editaci jako u pohledu vyučující. Místnost o Pro místnosti platí podobná pravidla jako pro pohled přes vyučujícího s tím rozdílem, že není možné zapisovat do všech místností, které obsahuje databáze. User může zapisovat pouze do místností, které má přiřazeny k danému uživatelskému účtu, resp. pracovišti. Skupina o Jelikož je skupina (obor) přiřazena k jednotlivým regionálním pracovištím, tak pokud bude zvolena skupina, která nepatří k pracovišti, pod jakým je user přihlášen, nebude možné tuto skupinu editovat. Všechny rozvrhové akce daného regionálního pracoviště jsou vždy upravitelné pouze v regionálním pracovišti, ke kterému jsou přiřazeny. 32
Další pravomocí, kterou má role user k dispozici, je zobrazení rozvrhů v konkrétní den. Přes tento pohled nebude možná editace, ale pouze zobrazení. Poslední pravomocí je možnost změny hesla. Při vytvoření uživatelského účtu pod rolí user se vytvoří účet s heslem 1234. Toto heslo může každý účet pod rolí user změnit.
5.3
Role vyučující
Pokud nebude zamezen přístup, bude se moci role vyučující přihlásit a na úvodní stránce si bude moci přečíst instrukce od role administrátor. Jestliže bude rolí administrátor povoleno zobrazení rozvrhů pro roli vyučující, bude možné zobrazit rozvrh z pěti pohledů. Každý pohled kromě mapy místností bude rozdělen na prezenční a kombinovanou výuku. Po navolení semestru si lze vybrat z těchto pohledů: Mapa místností o Z tohoto pohledu je možné zobrazit rozvrh konkrétního dne ve všech pracovištích a ve všech místnostech. Místnost o Pohled místnost umožní zobrazení vybrané místnosti po celou dobu vybraného semestru. Předmět o Při výběru z pohledu předmětu se zobrazí předmět v celém semestru v centrále a ve všech regionálních pracovištích. Skupina o Po výběru skupiny se zobrazí pohled na prezenční nebo kombinovanou formu pro celý semestr. Vyučující o Při výběru vyučujícího se zobrazí veškeré rozvrhové akce, které jsou vybranému vyučujícímu přiřazené v celém semestru. Pro všechny vyučující je společné přihlašovací jméno „pozorovatel“ a heslo „1234“. Název tohoto účtu pro vyučující byl úmyslně zvolen jako „pozorovatel“ z důvodu zamezení náhodnému přihlášení studentů pod názvem „vyucujici“. Nejedná se o velké omezení, ale pro účely BIVŠ postačí. Role vyučující bude vždy k nahlížení pro vyučující odemknuta dříve, než je tomu u role student. Je to z důvodu úprav rozvrhu, o které si vyučující mohou zažádat. Tyto žádosti 33
mohou být podávány i tehdy, kdy má již i role student povolené nahlížení do připravených rozvrhů. Konečné rozvrhy jsou vždy hotové 14 dní před začátkem semestru, ale předběžné rozvrhy jsou obvykle zveřejněny 2−3 měsíce před začátkem semestru pro vyučující a 1−2 měsíce před začátkem semestru pro studenty.
5.4
Role student
Pro roli student platí podobné pravomoci jako pro roli vyučující s rozdílem v hlavní obrazovce, kde jsou zobrazeny jiné pokyny od role administrátor. Ostatní pravomoci jsou totožné s pravomocemi role vyučující. Také pro tuto roli platí, že rolí administrátor musí být povoleno přihlášení do systému a zároveň musí být v daném semestru povoleno zobrazení rozvrhů. Přihlašovací jméno uživatele v roli student je „student“ a heslo „1234“. Přihlašovací účet je pro všechny studenty společný. Pokud budou studenti přistupovat k systému pro předběžné rozvrhy odkazem přes IS BIVŠ, nebude nutné se přihlašovat, budou přihlášeni automaticky.
34
6
Uživatelské webové rozhraní
Grafická podoba se dá hodnotit z více úhlů pohledů. Jedním z pohledů, který byl řešen, je pohled rozvrháře. Vzhledem k největší časové náročnosti využití systému rozvrhářem, je nutné vytvořit takový vzhled, který bude vyhovující pro práci v systému i po dobu několika hodin. První návrh BIVŠ byl ten, že půjde o kombinaci barev sytě zelená a bílá, neboť takové jsou i barvy celé školy. Tato kombinace byla později zamítnuta z důvodu dlouhodobého využití zmiňovanými rozvrháři. Ostatními uživateli bude systém využíván mnohonásobně kratší dobu. Konečný návrh webového rozhraní je kombinace světle oranžové, oranžovo-růžové a černé barvy. Celá struktura je rozdělena pomocí divů,10 které nabízí HTML jazyk. Ke každému z těchto divů je přiřazeno zobrazení nebo nějaký grafický design, jako jsou velikost či barva písma. Pomocí tohoto HTML kódu
který je uložen v souboru index.php, se odkazuje formátování na externí soubor jazyka CSS. Tento soubor se nazývá main.css a část je zobrazena níže. #main { width:1000px; background-image: url(img/menu_02.gif); overflow: auto; border-right: 1px rgb(0,51,0) solid; border-right-color: rgb(0,51,0); border-bottom: 1px rgb(0,51,0) solid; border-bottom-color: rgb(0,51,0); margin: 0 auto; font-family: Calibri; } #left{ width: 220px; float: left; text-align: center; margin-bottom: 10px; background-image: url(img/menu_04.gif); background-repeat: no-repeat; font-family: Calibri; height: 440 px; }
10
Pomocí tagu
je možné stránku HTML rozdělit na pomyslné čtverce či obdélníky, které mohou obsahovat text, tabulku nebo obrázek. Jednotlivé části mohou být jednotně formátovány.
35
Kódové zobrazení hlavní stránky, která slouží jako řídicí pro celé webové zobrazení, je vypsáno v příloze č. 1. Zeleně podbarvené PHP a HTML kód zobrazí v pravém horním rohu divu center tlačítko odhlásit, které se bude zobrazovat ve všech obsahových zobrazeních ve zmiňovaném divu. Celý systém je optimalizován pro rozlišení 1024 x 768 pro všechny webové prohlížeče. Jak je vidět na obrázku č. 8, zobrazení je poskládáno do pomyslných obdélníků, které jsou spravovány společně, nebo každý zvlášť. Obrázek č. 8: Konečný návrh grafické podoby
Zdroj: autor Hlavní div, který obsahuje všechny „pod-divy“, se jmenuje ESA. Rozdělení hlavního divu esa je následující: Div logo o Obdélník, který je zobrazen v horní části webových stránek. Div main 36
o Obdélník, který obsahuje další tři divy:
Div (left, left2 nebo left), center a pata: Jeden z divů left, left2 nebo left3 se zobrazí na základě přihlášení uživatelského účtu. Div center označuje největší zobrazovací plochu napravo od divu (left, left2 nebo left3). Div pata ukončuje celou webovou stránku zobrazením obrázku, který je pod divy (left, left2 nebo left3) a pata.
Div logo obsahuje logo školy a uprostřed je situován textově aktuální semestr, který se mění v závislosti na uloženém aktuálním semestru v databázi. Po přihlášení se mění podoba zobrazená vlevo od divu center. Pokud je požadováno přihlášení studenta nebo vyučujícího, zobrazí se div left, po přihlášení administrátora se zobrazí div left2 a po přihlášení uživatele z role user se zobrazí div left3. Každý z těchto divů má přesně dané položky menu, ale celková velikost (výška) se mění v závislosti na divu center – výšky divu (left, left2 a left3) a divu center jsou vždy totožné. Div center slouží pro zobrazení obsahu. Jeho velikost se mění na závislosti požadovaného vypsání obsahu jednotlivých položek. Zde se bude vždy zobrazovat vyhledávaný obsah, který bude daný uživatelský účet požadovat. Div pata slouží ke grafickému zakončení. Velikost tohoto divu se nemění, ale mění se situování od začátku zobrazení divu logo v závislosti na velikosti divu center.
37
7
Příprava databáze
Pro důslednou analýzu je nutné vymezit, jakým způsobem bude vypadat databáze, se kterou bude celý systém pracovat. Databáze je navržena tak, aby v příslušných tabulkách obsáhla všechny atributy potřebné pro chod celého systému. Některé tabulky nejsou napojeny na jiné, protože jejich využití je nevýznamné pro vytváření a zobrazení rozvrhu. Tzv. volné tabulky jsou využity pouze pro doprovodné nástroje, které napomáhají rozšířit systém o další funkce. Výčet všech používaných tabulek: rozvrh, rozvrh_ls, vyucujici, vanocni_svatky, ucty, skupiny, semestr_ls, semestr, schovani_vyucujici, schovani, predmety, mistnosti, editace, budovy, aktualni_semestr.
Schematické znázornění vytvořených tabulek a jejich vzájemných vazeb je na obrázku č. 9.
38
Obrázek č. 9: Schéma databáze
Zdroj: autor
39
rozvrh a rozvrh_ls Mezi tabulkami rozvrh a rozvrh_ls není v konstrukci žádný rozdíl. Rozdíl je v datech, která jsou v nich obsažena. V tabulce rozvrh jsou uložena data pro zimní semestr a v tabulce rozvrh_ls jsou uložena data pro letní semestr. Obě tyto tabulky jsou závislé na dalších tabulkách, jak je naznačeno na obrázku č. 9. Atributy těchto tabulek jsou: id_rozvrh, skupina, den_cislo, datum – nepovinný údaj, který se vyplňuje pouze při zápisu kombinované formy rozvrhové akce, mistnost, cas_od, cas_do, typ_s_l – značí, jestli jde o výuku prezenční či kombinované formy, a dále u prezenční formy, zdali se jedná o sudý či lichý týden, ucitel_uco, cviceni – určuje, zdali se jedná o cvičení či přednášku, poznamka, datum_od a datum_do – nepovinný údaj, který se vyplňuje pouze u prezenční výuky a rozlišuje se jím ročník (je doplněn pomocí tabulky semestr a semestr_ls), a kdo – povinný atribut, který značí, kdo z rozvrhářů rozvrhovou akci uložil. Vyučující Tabulka vyučující je vytvořena se třemi atributy – id_vyucujici, ucitel_uco a ucitel. Primárním klíčem je atribut ucitel_uco, který je využíván v tabulce rozvrh a rozvrh_ls. Není možné, aby byl nějaký vyučující smazán, pokud je zapsaný nějaký řádek v tabulce rozvrh nebo rozvrh_ls. Účty Tabulka účty je tvořena pěti atributy – login, id_ucet, heslo, pristup a cislo_skupiny. Primárním klíčem je zde login, který značí cizí klíč v tabulce rozvrh a rozvrh_ls pod atributem kdo. Atribut cislo_skupiny značí číslo, které je vždy násobeno čtyřiceti. Od vzniklého čísla se mohou vytvářet skupiny pro jednotlivé přednášky a cvičení. Je-li číslo uložené v atributu cislo_skupiny 4, bude rozvrhář daného čísla mít možnost začínat od 160 do 200 a bude využito pravidla, které je popsané v omezujících pravidlech. Každý nový účet pro dalšího rozvrháře bude mít číslo navýšeno od nejvyššího o čtyři. Skupiny Tato tabulka je sestavena pomocí čtyř atributů – skupina, id_skupina, prez_komb a pracoviste. Primární klíč v této tabulce je přiřazen atributu skupina. Atribut prez_komb určuje, zdali je skupina určena pro prezenční nebo kombinovanou formu studia. Atribut pracoviste je cizím klíčem z tabulky účty. Značí, pro které regionální pracoviště je vyhrazen.
40
Místnosti Tabulka místnosti je tvořena sedmi atributy – mistnost, id_mistnosti, kapacita, pocitace_s_bez, projektor_s_bez, pracoviste a budova. Primárním klíčem je mistnost. Atribut pocitace_s_bez je využíván pro záznam, který určí, jestli je místnost počítačová, nebo klasická. Atributy pracoviste a budova jsou cizí klíče z tabulek budovy a účty. Budovy V této to tabulce jsou obsaženy dva atributy – budova a id_budovy. Budova je primárním klíčem. V atributu budova je uložen název všech budov. Semestr Tabulka semestr je navržena s šesti atributy – id_semestr, semestr, zacatek, konec, rok a rocnik. Pomocí této tabulky je v rozvrhu vždy k prezenční výuce přiřazen začátek a konec podle ročníku, který se zapisuje. Pro kombinovanou výuku není nutné stanovit začátek a konec výuky v týdnech, protože kombinovaná výuka je vždy navržena na jeden konkrétní den. Semestr_ls Od tabulky semestr se tabulka semestr_ls liší pouze jedním atributem, který vyznačuje vedle ročníku ještě jednu podmínku – formu studia. Jelikož bakalářský a magisterský program nejsou ukončovány ve stejném ročníku, je nutné od sebe ještě odlišit druhý a třetí ročník. Třetí ročník není v magisterském studiu vyučován, a jelikož je u bakalářského studia ukončen stejně jako druhý ročník u magisterského studia, je nutné rozlišit druhý ročník magisterského a bakalářského studia. Z tohoto důvodu bylo nutné vytvořit další upřesňující atribut. Předměty Tabulka předměty je tvořena třemi atributy – kod_predmet, id_predmety a predmet. Kod_predmetu je přebírán z IS BIVŠ stejně jako predmet, kde je uložen identický název předmětu jako v IS BIVŠ. Primární klíč je definován jako kod_predmetu. Schování, schování_vyučující a editace Všechny tři tabulky jsou vytvářeny identicky se dvěma atributy – letni a zimni. Jsou to pouze pomocné tabulky, ve kterých jsou uloženy vždy pouze dvě možnosti – ano, či ne. Tabulka schování slouží ke zviditelnění nebo zamezení čtení rozvrhů pro studenty. Tato funkce je využívána při přípravě rozvrhu hlavně na počátku, kdy je rozvrh „překlopen“ a dosud není
41
neupraven, aby nebyly vidět neupravené rozvrhy pro studenty. Stejným způsobem je navržena i tabulka schování_vyučující, která je ale cílena na vyučující. Trochu odlišná, ale principiálně stejná je tabulka editace. Tato tabulka slouží k zamezení editace rozvrhů pro všechny rozvrháře, protože jinak by nebylo možné docílit konečných rozvrhů a změny by probíhaly i během výuky. Aktuální_semestr Tato tabulka je složena ze tří atributů – id_aktualni_semestr, semestr a rok. Není na hlavní část databáze nijak vázána, protože pouze vyznačuje, jaký je aktuální semestr v záhlaví systému – divu logo. Toto je nutné odlišit, protože systém slouží pro přípravu předběžných rozvrhů a studenti často nevědí, jaký semestr je aktuální. Vánoční_svátky Pokud je zimní semestr nastaven tak, že výuka probíhá ještě v lednových týdnech, je nutné vynechat dny, ve kterých je škola uzavřena, a proto není povoleno vytvářet v tyto dny přes Vánoce žádné rozvrhové akce. Tato tabulka zamezí v uloženém rozmezí vánočních svátků vkládat jakékoliv rozvrhové akce všem rozvrhářům a tyto dny se nezobrazují nikde ve výběru a prohlídce rozvrhu. Tabulka je tvořena třemi atributy – id_vanocni_svatky, zacatek a konec s primárním klíčem id_vanocni_svatky.
42
8 8.1
Algoritmizace a programování Algoritmizace
Algoritmizace celého systému není složitá. V celém systému se využívá standardních funkcí, které nabízí jazyk PHP a SQL. Příkladem pro využití standardní funkce jazyka PHP je funkce DATE, která nabízí převod čísla na datum, jak je to vidět v programovém kódu níže: $datum = Date("j.n.Y","$sekundy");
Do proměnné $datum se uloží datum, které se vypočítá z funkce DATE. Takovéto funkce napomáhají k jednodušší algoritmizaci celého systému. Nejčastější standardy SQL a databáze MySQL, které zajišťují chod celého systému, jsou SELECT, INSERT, UPDATE a DELETE. Při vytváření příkazu SELECT je využíváno většiny jeho klauzulí, jako je např. ORDER BY nebo WHERE. Běžné a nejjednodušší jednostupňové řazení je řešeno právě pomocí klauzule ORDER BY, která seřadí daný výsledek příkazu SELECT dle abecedy pomocí sloupce, který bude vybrán: select mistnost from mistnosti where budova = „Nárožní 2600, Praha 5“ order by mistnost
Výše vypsaný příkaz SELECT vybere z tabulky mistnosti všechny místnosti, které jsou v budově v Praze a seřadí je vzestupně podle abecedy.
8.2
Programování
Samotné programování je rozděleno do několika modulů, které se starají o chod celého systému. Všechny využívané moduly jsou: Modul připojení Modul připojení slouží k propojení systému s databází. Je to samostatný soubor jménem databaze.php, který se vždy importuje do jednotlivých částí systému pomocí PHP příkazu include.
Do proměnné $link se uloží připojení k databázovému serveru, zde pod názvem localhost, uživatelským jménem root a heslem 123321. Pokud dojde k nějaké chybě, příkaz die zaručí 43
ukončení připojování, aby nedošlo při pokračování chodu programu k nějaké neočekávané chybě, a nebyla tak např. znehodnocena data v databázi. include "../databaze.php"; $otazka = "select * from budovy order by budova"; $odpoved = mysql_query($otazka,$link); while ($bunka = mysql_fetch_array($odpoved)) { $id_budovy = $bunka["id_budovy"]; echo $budova = $bunka["budova"]; }
Pomocí proměnné $otazka se nadefinuje dotaz, který požaduje nějaká data z databáze. Příkaz mysql_query provede připojení pomocí proměnné $link, která je importována ze souboru databaze.php, a dále pomocí proměnné $otazka vybere požadovaná data. Jelikož se vybírají všechny budovy z tabulky budovy, bude nutné každou budovu uložit do jednotlivých buněk v poli, o které se postará cyklus while a příkaz mysql_fetch_array. Příkaz echo vypíše vždy v průchodu cyklem jednu budovu z tabulky. Stejným způsobem se využívá modul připojení i v příkazech INSERT, DELETE a UPDATE. include "../databaze.php"; $dotaz = "insert into budovy values('','$budova')"; $vysledek = mysql_query($dotaz,$link) or die("Nebylo možné vytvořit budou v databázi!");
include "../databaze.php"; $dotaz = "delete from budovy where id_budovy = '$budova'"; $vysledek = mysql_query($dotaz,$link)or die("Smazání budovy se nezdařilo !");
include "../databaze.php"; $dotaz="update budovy set budova = '$budova ' where id_budovy = '$id_budovy'"; $vysledek = mysql_query($dotaz,$link) or die("Změna názvu budovy se nezdařila !");
Modul zobrazení Modul zobrazení je k dispozici pro všechny role, pokud je v databázi povoleno zobrazení rozvrhů pro studenty a vyučující. Role user a administrátor mají tuto roli k dispozici vždy. Umožňuje zobrazení rozvrhových akcí z pěti pohledů – mapa místností, místnost, předmět skupina a vyučující. Náhled do programovacího kódu níže umožnuje zobrazení rozvrhových akcí z pohledu vyučujícího. S drobnými změnami je využíván modul zobrazení i pro ostatní pohledy. Programový kód je přiložen v příloze č. 2.
44
Modul editace rozvrhových akcí Modul editace rozvrhových akcí je propojen s modulem zobrazení. V programovém kódu vypsaném v modulu zobrazení je zároveň obsažen i kód pro modul editace rozvrhových akcí, protože se zjišťuje, kdo je v systému přihlášen, a podle toho se umožní nebo zamezí editace jednotlivých rozvrhových akcí. Pouze pokud je přihlášena role administrátor, je role pro tento modul vždy povolena. U každé rozvrhové akce se zobrazí dvě tlačítka – smazat a upravit. Po kliku na tato tlačítka se systém přesune do těchto modulů. Modul smazání rozvrhových akcí Modul smazání má vždy za úkol smazat požadované položky z databáze. Pro každý pohled je drobně poupraven. Pro pohled vyučujícího je využíván tento kód: echo "
Modul vytvoření a upravení položek k rozvrhovým akcím Modul vytvoření úpravy je jedním ze stavebních kamenů celého systému rozvrhování akcí. Zamezuje vzniku kolizí tak, že před každou změnou či vytvořením provede kontrolu všech povinných položek, jestli již nejsou využity pro jinou rozvrhovou akci. Kontrolují se tyto položky: -
vyučující,
-
předmět,
-
skupina předmětu,
-
den v týdnu,
-
oborová skupina,
-
místnost.
Všechny tyto položky se kontrolují v požadovaném čase nové či upravené rozvrhové akce. Z důvodu rozsáhlého programovacího kódu je ukázka modulu přidána až v příloze. Modul editace položek k rozvrhu
45
Modul editace obsahuje ještě pod-moduly vkládat, upravovat a mazat záznamy z databáze. Pod-modul smazat z pohledu předmětu je vypsán níže. Umožňuje smazat předmět, který není vázán na žádnou rozvrhovou akci. Programový kód je zobrazen v příloze č. 3. Pod-modul vytváření z pohledu předmětu umožňuje vytvoření nového předmětu do systému: Tento kód předmětu již je v databázi uložen !!!"; } else { include "../databaze.php"; $dot="insert into predmety values('','$kod_predmet','$nazev_predmet')"; $res=mysql_query($dot,$link)or die("Nebylo možné zapsat vyučujícího do databáze !"); echo "
Předmět byl vytvořen !!!
"; }} else { echo "
Některá z hodnot není vyplněna !!!
"; }} ?>
46
Pod-modul úprava z pohledu předmět umožnuje změnu názvu předmětu a jeho kódu. Při změně kódu předmětu se onen změní i ve všech navázaných tabulkách. Programový kód je zobrazen v příloze č. 4. Všechny pod-moduly z ostatních pohledů, které jsou stejné jako v případě modulu zobrazení, jsou naprogramovány na stejném principu s úpravami pro daný pohled. Modul editace rolí a uživatelských účtů Modul editace rolí a uživatelských účtů se také dělí na další pod-moduly. První pod-modul se zabývá právy jednotlivých rolí a přístupem do jednotlivých sekcí systému pro dané role, druhý se zabývá vytvářením a smazáním uživatelských účtů a jejich hesel a třetí se zabývá změnou hesla pro roli administrátor a user. Pod-modul zabývající se právy může zamezit přístup všem rolím, zamezit použití modulu zobrazení a zamezit editaci a smazání rozvrhových akcí. Zamezení či povolení jednotlivých práv naznačuje programový kód, který je zobrazen v příloze č. 5. Tímto bude zamezena, nebo povolena editace letního semestru pro roli user. Při stejném principu s pomocí úprav se využije pod-modul práv i pro zobrazení nebo nezobrazení rozvrhových akcí pro vyučující a studenty. Dále je v tomto pod-modulu kontrolován přístup jednotlivých rolí pomocí souboru sekceadmin.php. $poleSekci[282][0] $poleSekci[282][1] $poleSekci[114][0] $poleSekci[114][1] …
V tomto souboru jsou přesně definované sekce, do kterých smí dané role vstupovat. Pokud se pokusí role bez příslušných práv vstoupit do zakázané sekce, vypíše se hlášení o nepovoleném vstupu. Pokud se pokusí role vstoupit do neexistující sekce, bude navrácena na hlavní stránku, která je k roli přiřazena. Druhý pod-modul umožňuje vytvořit a smazat uživatelský účet v roli user. Programovací kód je přiložen v příloze č. 6. Tak je vytvořen nový účet pro nového rozvrháře daného střediska s přednastaveným heslem 1234. Smazání uživatelských účtů v roli user je možné pomocí podmodulu smazání účtů, který má zobrazen programovací kód v příloze č. 7. Vždy je možné smazat pouze účet z role user. Pod-modul změna hesla umožňuje změnu hesla roli administrátor a user. Role vyučující a student nemají možnost změny hesla, které je implicitně nastaveno na 1234. Programovací kód je zobrazen v příloze č. 8. 47
Modul migrace dat Programovací jazyk PHP disponuje s funkcionalitou, která umí předně i zpětně konvertovat z číselného kódu hodnotu datového typu datum (kód je generován inkrementací po sekundách od roku 1970). Proto je možné jakkoliv manipulovat s „časem“, a je tedy možné nechat všechny již vytvořené rozvrhové akce přečíslovat, a tím vytvořit celý nový rozvrh. K tomuto postupu je nutné vždy přesně definovat datum tak, aby se den, který je uložen z minulých let, shodoval se dnem, který bude vložen jako nový. Tento krok je nevratný. Proto je nutné řádně archivovat data. Celý tento postup je možný s pomocí modulu migrace dat, který má zobrazen programovací kód v příloze č. 9. Tento modul je z hlediska časové úspory nejdůležitější. Umožňuje během několika vteřin připravit hrubou šablonu rozvrhu pro celý semestr. Modul zápis do souboru Celý systém byl vytvořen proto, aby umožnil sestavit import, který se nahraje do systému IS BIVŠ. Pro výpis na obrazovku nabízí jazyk PHP příkaz echo. Tento způsob neumožní zápis do souboru. Proto bylo nutné vytvořit modul se zápisem do souboru, který se bude importovat vždy při nutnosti zápisu do nějakého souboru. header("Content-Description: File Transfer"); header("Content-Type: application/force-download"); header("Content-Disposition: attachment; filename=\"$nazev_souboru\"");
Do proměnné $nazev_souboru se zapíše název k dané situaci. Po spuštění kódu vypsaného výše se příkaz echo přesměruje z výpisu na obrazovku na zápis do souboru. Po skončení zápisu do souboru nabídne prohlížeč výběr místa uložení s požadovaným souborem.
48
9 9.1
Analýza zpracování rozvrhů Zpracování tabulky požadavků
Pro vytvoření kompletního rozvrhu pro celý semestr je potřeba učinit několik přesně definovaných kroků, které budou postupně v této práci zpracovány, aby bylo možné navázat vytvořeným systémem na celý proces přípravy rozvrhů a chod celého vyučovacího cyklu. Pro zimní semestr je nutné nejdříve vytvořit rozpis všech předmětů a jejich hodin. Každý předmět musí být zapsán formou, jaká je vidět v tabulce č. 4. Tabulka č. 4: Požadavky vyučujících Vyučující příjmení a jméno
Bakalářské
B102PKT/1
Právo kapitálových trhů
2/1 Prezenční Prezenční
Cvičení
B102PKT/12
Prezenční
Cvičení
12/0 Kombinované
Požadovaný Požaduje Požaduje den ze počítačovou projektor: strany učebnu: Ano/Ne vyučujícího Ano/Ne
Přednáška
B102PKT/11
B102PKT/21
Vyučující UČO
Přednáška
Zdroj: Autor Tento rozpis se tvoří pouze v prvním roce využívání programu, protože další semestry se budou již přepočítávat pomocí modulu migrace dat. Pro vytvoření rozpisu je nutné vědět, v kolika oborech se bude v daném semestru předmět vyučovat. Např. předmět Základy ekonomie I se vyučuje v pěti oborech současně a je nutné mít pro prezenční formu zajištěnou výuku v podobě cvičení pro všechny studenty. Proto se bude rozvrh odvíjet pouze od toho, kolik bude na daný předmět docházet studentů. Jestliže bude na předmět Základy ekonomie I docházet v prezenční formě 100 studentů, bude nutné vytvořit jednu přednášku ve velké místnosti a čtyři cvičení po 25 studentech. Rozsah kapacity cvičení je vždy definován mezi 20–30 studenty na cvičení. U jazykových kurzů je rozsah 16–20 studentů na cvičení. Stejným způsobem bude rozdělena i kombinovaná forma. Protože Základy ekonomie I v kombinované formě nemají cvičení, bude potřeba pouze jedna velká posluchárna, pokud nebude studentů více než 120. Jestliže bude studentů více než 120, bude nutné rozdělit přednášku na dvě. Stejným způsobem jako u Základů ekonomie I je nutné vytvořit tabulku pro všechny předměty, které se ve škole v daném regionálním pracovišti (centrále) vyučují. Dále je nutné
49
všechny předměty dělit podle kateder, protože jednotlivé tabulky pro požadavky od vyučujících se rozešlou vedoucím kateder, kteří mají za úkol vyplnit je podle požadavků svých vyučujících a vrátit je rozvrháři vyplněné s požadavky na vytvoření rozvrhu. Během navrácení tabulek od všech vedoucích kateder je nutné specifikovat váhu jednotlivých předmětů. Tím je myšleno, že je třeba zjistit, které předměty jsou společné pro nejvíce oborů. Příkladem je Anglický jazyk I, který mají všechny bakalářské obory dohromady. Tento předmět bude vkládán do rozvrhu jako první, protože bude mít nejvyšší váhu. Takto budou ohodnoceny všechny předměty. Do rozvrhu budou předměty vkládány postupně podle váhy od nejvyššího po nejnižší, což znamená, že první se budou vkládat předměty, které se vyučují napříč všemi obory, a poslední se budou vkládat předměty, které se vyučují pouze v jednom oboru, a proto je s nimi jednodušší manipulace. Tím je myšleno, že přesunutí předmětu, který se vyučuje v daném semestru ve všech oborech, je téměř nemožné z toho důvodu, že některý ze zainteresovaných oborů bude mít pravděpodobně nějakou jinou rozvrhovou akci ve dni a čase, kam se má předmět přesouvat. Naopak pokud bude předmět soustředěn pouze pro jeden obor, tak je jednoduché najít jiné volné místo v rozvrhu a výuku předmětu přesunout, jelikož se bude hledat volné místo pouze v rámci jednoho oboru.
9.2
Vytvoření datové základny
Po odeslání tabulky pro požadavky vznikne časový prostor. V systému se musí vytvořit všechny předměty a jejich atributy, všechny místnosti a jejich atributy, všechny budovy a všechny skupiny (obory). Po návratu vyplněných tabulek je možné doplnit i všechna jména a příjmení vyučujících. Ještě než se začne vytvářet rozvrh, je nutné také zkontrolovat, kteří vyučující požadují počítačovou učebnu, aby se předešlo případnému nedostatku počítačových učeben. Toto pravidlo způsobí posun některých předmětů na vyšší váhové místo. Po skončení tohoto kroku je možné začít vytvářet samotný rozvrh podle požadavků nasbíraných v tabulkách vrácených z kateder.
9.3
Vkládání rozvrhu
V prvním roce využívání systému nemusí být rozvrhy schovány u zimního semestru, protože vyučující ani studenti nejsou o této aplikaci informováni. Nejprve jsou rozvrhy vytvořeny v centrále v Praze a poté je povolena jejich editace ostatním regionálním pracovištím. Jelikož známe nyní vše, co je potřeba učinit pro vytvoření rozvrhu, je možné začít vkládat rozvrh dle váhy jednotlivých předmětů. Předměty s největší váhou se v budoucnu budou 50
posouvat minimálně, jelikož bude obtížné najít společné volné místo napříč několika obory. Pokud i přes tuto nevýhodu předmětu s velkou váhou bude nutné předmět přesunout, musí se uvolnit místo mezi předměty s menší váhou. Pro vložení rozvrhové akce je nutné mít k dispozici tyto informace: 1) Rozlišení prezenční a kombinované výuky. 2) Přiřazení vyučujícího. 3) Přiřazení předmětu. 4) Přiřazení skupiny předmětu. 5) Přiřazení skupiny (oboru) nebo skupin (oborů). 6) Přiřazení místnosti. 7) Přiřazení „času od“ a „času do“ – délka výuky. 8) Přiřazení typu výuky. 9) Zapsání případné poznámky. Při vkládání prezenční výuky je nutné znát ještě cyklus výuky – každý sudý nebo lichý týden. Oproti prezenční výuce je u kombinované výuky nutné znát přesné datum dne. Všechny tyto informace jsou uloženy v tabulkách s požadavky navrácených od vedoucích kateder. Nyní je nutné všechny naplánované rozvrhové akce zanést do systému. Postupné vkládání zabere přibližně tři týdny, proto je nutné, aby byla databáze vyplňována s předstihem.
9.4
Zveřejnění a povolení editace rozvrhů v regionálních pracovištích
Po vložení všech naplánovaných vyučovacích hodin jsou povoleny editace a vkládání jednotlivým regionálním pracovištím a předběžné rozvrhy jsou zviditelněny pro vyučující a studenty. Po tomto kroku jsou obesláni všichni vedoucí kateder, aby informovali své vyučující o zviditelnění a přístupu do předběžných rozvrhů. Pomocí IS BIVŠ jsou informováni také studenti v Praze o zviditelnění předběžných rozvrhů. Nyní plyne měsíční lhůta pro sběr požadavků na změny v rozvrhu, které shromažďují vedení jednotlivých kateder. Zároveň s tímto úkonem jsou doplňovány rozvrhy z regionálních pracovišť. Po doručení posledních požadavků se počítá lhůta 14 dní pro vyřešení požadavků. V těchto dnech je připraven konečný rozvrh, který je možné změnit pouze se souhlasem rektora nebo z vážného důvodu (např. nemoc vyučujícího).
51
10 Příprava exportů dat Příprava pro tisk a export rozvrhů do IS BIVŠ nebo do CSV souborů je jednou z nejdůležitějších součástí tohoto systému. Velice důležitá je záloha pro pozdější využití a rozdělení vyučujících podle kateder a výpis jejich rozvrhů pro jednotlivé vedoucí kateder, aby mohli zkontrolovat, zdali mají všichni vyučující patřící pod danou katedru správný předmět a správný rozsah hodin.
52
Obrázek č. 10: Zvolení tisku
Zdroj: Autor
10.1 Příprava tisku Každá role má možnost tisku. Tisknout je možné ze všech pohledů, které zobrazují rozvrh. Na obrázku č. 10 je zobrazen výpis rozvrhu pro roli administrátor. V pravém dolním rohu je tlačítko „>>> Tisk <<<“. Po stisku tlačítka je systém přesměrován na stránku s tiskem, kde bude vypsán pouze rozvrh bez divů logo, main, pata a editujících tlačítek, která jsou zobrazena na webovém zobrazení, jak je vidět na obrázku č. 11. Veškerá příprava tisku je 53
zobrazena pomocí modulu zobrazení s tím rozdílem, že není vypisována do divu center, ale do nového okna webového prohlížeče, které obsahuje pouze modul zobrazení bez loga, menu a paty. Obrázek č. 11: Připraveno pro tisk
Zdroj: Autor Tlačítko „Zpět“ je určeno pro návrat do webových stránek z menu. Pro tisk je určen atribut ne-tisknutelnosti. Tzn., že toto tlačítko se na tisknutém papíře neobjeví. Hlavním důvodem pro atribut tisknutelnost stránky a výpis v divu center je šetření barvy. Pro tisk barevného podkladu, který je vidět na obrázku č. 28 pod vysvětlivkami a dále pod jednotlivými rozvrhovými akcemi, je nutné vždy v jednotlivých prohlížečích nastavit zapnutí tisku i s pozadím, jinak se toto podbarvení nevytiskne. Barevné podbarvení je nutné hlavně v případě, že si vyučující chce vytisknout rozvrh, v němž bude zobrazeno dělení na sudý a lichý týden. V černobílém tisku toto rozlišení nebude vidět. Styl tisku je takto naprogramován pro všechny pohledy v menu – mapa místností, místnost, předmět, skupina (obor) a vyučující.
54
10.2 Hromadný tisk Jelikož dochází každý rok k přepočítání rozvrhů – k posunutí o rok dopředu a následným jednotlivým úpravám rozvrhových akcí, je nutné pro případné dohledávání rozvrhů minulých let zachovat konečnou formu rozvrhů neboli zálohu. K tomuto účelu je určena položka „Tisk rozvrhů“ v levé části menu systému. U tohoto tisku je využit také modul zobrazení, který se využívá v cyklu vždy podle zvolených kritérií a dahého pohledu. Po výběru této položky je k dispozici výběr letního a zimního semestru. Po zvolení semestru jdou k dispozici položky, které jsou zobrazeny na obrázku č. 12. Z důvodu velké náročnosti na výpočet a výpis má tuto možnost pouze role „admin“. Obrázek č. 12: Hromadný tisk
Zdroj: Autor Jak je vidět na obrázku č. 12, je možné hromadně vytisknout předměty, místnosti, skupiny a vyučující. Všechny hromadné tisky využívají modul zápis do souboru. Zmiňované položky s výjimkou vyučujících se tisknou za všechny katedry dohromady. Není nutné tyto položky dále dělit na katedry, protože jsou určeny pouze k záloze.
55
Oproti tomu u vyučujících je z důvodu potřeby kontroly ze strany vedení kateder nutné, aby bylo možné vytisknout všechny rozvrhové akce, které k jednotlivým katedrám patří. Proto je umožňen výběr jednotlivých kateder. Pro zálohu není nutné vybírat žádnou katedru, protože budou automaticky vybrány všechny katedry. Soubor po otevření vypadá stejně jako výpis pro tisk, který je vidět na obrázku č. 11, s tím rozdílem, že jsou vždy tisknuty všechny rozvrhy dané položky. Př.: pokud je zvolen „Tisk rozvrhů předmětů“, tak se vytvoří soubor „leto_predmety.html“, který bude mít v sobě uložené všechny předměty, rozvrhové akce a budou seřazené podle abecedy. Tímto způsobem jsou vytvořeny všechny hromadné rozvrhy a jsou seřazeny abecedně podle dané položky.
10.3 Exporty do CSV a TXT souborů Hlavním důvodem vzniku celého systému a zároveň této práce je konečný export všech naplánovaných rozvrhových akcí do IS BIVŠ, který dokáže všechny tyto akce importovat pomocí přesně dané struktury v CSV souboru.
10.3.1
Export pro seminární skupiny
První exportovaný soubor, který se importuje do IS BIVŠ, je soubor se seminárními skupinami. Tento export rozdělí všechny vyučované předměty v souboru do jednotlivých řádků. Každý řádek má tyto sloupce přesně v tomto pořadí: 1) Kód předmětu. 2) Označení seminární skupiny. 3) Volné pole. 4) Maximální počet studentů. 5) Přihlásit od. 6) Přihlásit do. 7) Odhlásit do. 8) Poznámka. 9) Vyučující dané seminární skupiny. 10) Povoleno násobné přihlášení. Všechny položky nemusí být vyplněny. Je nutné vyplnit položky 1, 2 a 9. Kód předmětu je jasně daný již při vytváření předmětu. Je vždy přebírán z IS BIVŠ, aby mohl být poté zase zpětně odkázán při importu.
56
Každý předmět je dále dělen na podskupiny – seminární skupiny. Např. u předmětu M101MSA/1. Číslo za znakem „/“ je vždy číslo, které bude uvedeno ve druhém sloupci. Ve volném poli je při exportu z IS BIVŠ uložen rozvrh. Importem seminární skupiny se tento údaj do IS BIVŠ vkládat nesmí a musí zůstat při importu seminárních skupin vždy volný! Obrázek č. 13: Výpis seminárních skupin
Zdroj: Autor Maximální počet studentů je omezen kapacitou jednotlivých místností, která je zadávána při vytváření místnosti, a toto číslo je vloženo do sloupce u každé rozvrhové akce. Systém IS BIVŠ umožňuje nechat tento sloupec prázdný, proto je možné v systému pro vytváření rozvrhů vybrat v položce „Vypnutí maximálního počtu studentů“ možnost „ano“ (zobrazeno na obrázku č. 13), a tím pádem bude tento sloupec prázdný. Položky „přihlásit od“, „přihlásit do“ a „odhlásit do“ nejsou na BIVŠ využívány, protože tyto položky značí, kdy se mohou studenti k jednotlivým skupinám přihlašovat a odhlašovat. Jelikož se studenti na BIVŠ nepřihlašují sami, ale jsou k jednotlivým akcím přiřazeni 57
rozvrháři, tak se export přizpůsobí a tyto položky se nevyplňují a zůstávají prázdné. Jak je vidět na obrázku č. 13, s možností přihlašování a odhlašování v režii studentů se do budoucna počítá, proto je již nyní tato možnost naprogramována. Z doporučení MUNI Brno je přihlášení a odhlášení možné naplánovat pro jednotlivé ročníky. Tento krok sníží vytíženost IS BIVŠ při přihlašování, protože jinak by bylo přihlášení v jeden okamžik povoleno pro všechny studenty. Do poznámky se zpravidla nemusí vkládat nic, ale je dobré, aby se zde zobrazovala minimálně poznámka s označením, ve kterém regionálním pracovišti se bude daná výuka vyučovat, popř. jestli se bude vyučovat v angličtině. Vyučující, resp. učo vyučujícího, dané seminární skupiny musí být vždy vyplněn. Je možné, aby zde bylo vyplněno více vyučujících, protože výuka jednoho předmětu může být rozdělena mezi více vyučujících. Každé učo vyučujícího musí být odděleno čárkou. Jestliže má předmět rozdělenu výuku na přednášku i cvičení, je nutné v položce „Povoleno násobné přihlášení“ uložit u dané přednášky předmětu znak „a“, aby bylo možné později při importu studentů k seminárním skupinám uložit jednoho studenta zároveň k přednášce a zároveň ke cvičení. Bez tohoto povolení by nebylo možné studenta uložit k více plánovaným akcím předmětu, protože by tyto akce byly považovány za duplicitní, a IS BIVŠ by nepovolil takového studenta přiřadit ke dvěma „stejným“ akcím. Celý zápis exportovaného souboru by mohl vypadat takto: B102PKT;2;;30;;;;Praha, BM v angličtině;14882; B102USY;102;;30;;;;Karlovy Vary;17360; B104UPS;1;;28;;;;Praha;19692,4150; …
Po vytvoření se tento soubor nahraje do IS BIVŠ, kde se u jednotlivých předmětů vytvoří seminární skupiny, ke kterým se v dalším exportu přiřadí rozvrh.
10.3.2
Export rozvrhů
Druhý export, který je soustředěn pro vytvoření rozvrhů v IS BIVŠ, je export rozvrhových akcí. Podobně, jako je tomu u exportu pro seminární skupiny, i tento export vytváří řádky, které značí jednotlivé rozvrhové akce s přesně danými sloupci, které jsou striktně určeny systémem IS BIVŠ. Přesný sled sloupců je do souboru TXT vypisován takto: 1) Fakulta: kód předmětu/číslo skupiny.
58
2) Typ výuky. 3) Číslo dne. 4) Čas výuky. 5) Budova a místnost. 6) Začátek a konec semestru nebo datum. 7) Skupiny, kterým výuka patří. 8) UČO vyučujícího. Jak je vidět na obrázku č. 14, je nutné při vytváření exportu ještě vybrat jednotlivé regionální pracoviště, popř. všechna, a zvolit fakultu. BIVŠ má dvě „fakulty“. Pod tímto označením se rozumí výuka v České a Slovenské republice. V budoucnu by měla být připojena do tohoto systému také všechna regionální pracoviště na Slovensku, aby byly všechny rozvrhy pohromadě za celou školu v jednom systému. Typem výuky je myšlena zkratka, která značí u prezenční výuky, jaký bude cyklus rozvrhové akce nebo zdali se jedná o kombinovanou výuku. Zkratky pro prezenční studium jsou tři – T (každý týden), S (sudý týden) a L (lichý týden). Kombinovaná výuka je značena zkratkou D. Číslo dne je značeno pouze v případě, že je rozvrhová akce soustředěna v prezenční výuce a to tímto značením – 1-7 pondělí–neděle. Rozvrhová akce v kombinované výuce má tento sloupec volný. Čas výuky je velice specifický. Začátek se vždy přebírá podle toho, jak jsou nastaveny začátky v IS BIVŠ, které jsou zobrazeny v tabulce 3, ale konec se musí upravit. Jelikož IS BIVŠ kontroluje také kolize v rozvrhu, tak se musí konce výuky trochu upravit. Pokud není mezi výukovými hodinami žádná mezera (např. mezi 3 a 4) a některá rozvrhová akce končí třetí výukovou hodinu, tak se musí konec nastavit o minutu dříve, protože by IS BIVŠ ihned hlásil kolizi v případě, že by další rozvrhová akce začínala čtvrtou výukovou hodinu.
59
Tabulka č. 5: Časový rozvrh výuky
0 07:15 – 08:00 8 14:00 – 14:45
1 08:00 – 08:45 9 14:45 – 15:30
2 08:45 – 09:30 10 15:45 – 16:30
3 09:45 – 10:30 11 16:30 – 17:15
4 10:30 – 11:15 12 17:30 – 18:15
5 11:30 – 12:15 13 18:15 – 19:00
6 7 12:15 13:05 – – 13:00 13:50 14 19:00 – 19:45
Toto považuje IS BIVŠ za kolizi a nepovolí vložení rozvrhu importem, pokud k této chybě dojde. Proto se musí vždy každá akce, která končí výukovou hodinou, kde není přestávka před začátkem navazující hodiny, upravit. Obrázek č. 14: Export rozvrhu
Zdroj: Autor Na obrázku č. 14 je také ještě zobrazen správný zápis do importovaného souboru, který slouží jako
kontrola
při
případném
hledání
a
60
opravě
nesrovnalostí
přímo
v souboru.
Konečný vyexportovaný soubor by měl vypadat asi takto: # ------------------------- Fakulta --------------------------fakulta=6110 # ------------------------- Období --------------------------obdobi=léto 2014 # ---------------- Atributy místností pro obory ---------atribut=1BK-BM:Výuka pro studijní skupinu (obor) 1BK-BM atribut=1BK-IT:Výuka pro studijní skupinu (obor) 1BK-IT … # ------------- Samotné rozvrhové akce -----------------rozvrh 6110:B105AJ2/11;T;1;12.15-13.49;PRA, Nárožní 2600/9, Praha 5, 158 00::NAR307;10.2.2014-3.5.2014;1BP-BM:1BP-IT:1BPMSP:1BP-OM:1BP-PA;4313; 6110:B105AJ2/13;T;1;14.00-15.29;PRA, Nárožní 2600/9, Praha 5, 158 00::NAR307;10.2.2014-3.5.2014;1BP-BM:1BP-IT:1BPMSP:1BP-OM:1BP-PA;4313; 6110:B105AJ2/15;T;1;15.45-17.14;PRA, Nárožní 2600/9, Praha 5, 158 00::NAR307;10.2.2014-3.5.2014;1BP-BM:1BP-IT:1BPMSP:1BP-OM:1BP-PA;4313; 6110:B105AJ2/12;T;1;12.15-13.49;PRA, Nárožní 2600/9, Praha 5, 158 00::NAR308;10.2.2014-3.5.2014;1BP-BM:1BP-IT:1BPMSP:1BP-OM:1BP-PA;15823; 6110:B101BPO/145;D;;8.45-12.14;PIS, K.Čapka 402::PIS004;22.3.2014;PIS-2BK-IT;4322; 6110:B101BPO/145;D;;14.00-17.14;PIS, K.Čapka 402::PIS005;2.5.2014;PIS-2BK-IT;4322; 6110:B101BPO/145;D;;8.45-12.14;PIS, K.Čapka 402::PIS004;3.5.2014;PIS-2BK-IT;4322; 6110:B101BPO/145;D;;8.45-12.14;PIS, K.Čapka 402::PIS004;3.5.2014;PIS-2BK-IT;4322; 6110:B101ZI1/61;D;;11.30-14.44;BRE, Dům školství, 17 listopadu 1a::BRE133;22.2.2014;BRE-1BK-PA;4538; 6110:B101ZI1/71;D;;14.45-18.14;BRE, Dům školství, 17 listopadu 1a::BRE133;22.3.2014;BRE-1BK-PA;4538; 6110:B101ZI1/71;D;;11.30-14.44;BRE, Dům školství, 17 listopadu 1a::BRE133;12.4.2014;BRE-1BK-PA;4538; …
61
10.3.3
Export pro přípravu importu studentů
Tak, jak již bylo napsáno v kapitole 8.2, je příprava tabulky požadavků na výuku od vyučujících zpracována pouze v prvním roce. Pro další roky bude využíván systém rozvrhů, který tuto tabulku nahradí. Vyučující již nebudou muset klást požadavky typu „Potřebuji počítačovou místnost“, protože tyto požadavky budou přenášeny z minulého akademického roku. Pro přiřazení studentů k rozvrhu je ale potřeba mít vypsány všechny rozvrhové akce. Proto je nutné vytvořit export CSV souboru, který bude složen z těchto sloupců – kód předmětu, skupina předmětu, poznámka (pro případ výjimky) a oborová skupina. Soubor po vyexportování může vypadat např. jako tabulka 4. Tabulka č. 6: Export pro přiřazení studentů k rozvrhu
Zdroj: Autor V této exportované tabulce budou všechny rozvrhové akce, které jsou naplánovány pro rozvrh na daný semestr. Toto platí pouze pro Prahu, protože rozvrhy pro regionální pracoviště jsou vytvářeny každý rok stejně, jako je popsáno v kapitole 8.2. Všechna regionální pracoviště se shodla, že chtějí vždy po ukončení semestru rozvrhy smazat, proto se nikdy export nevytváří pro jiné regionální pracoviště. Tento soubor CSV je dále nakopírován do souboru Excelu, ve kterém jsou připravené další listy pro přípravu konečného importu studentů k rozvrhu. Tento soubor je složen z pěti listů, 62
které obsahují všechny studenty z Prahy – list „import“, list „plán“, který obsahuje všechny vyučované předměty v jednotlivých oborech, pomocný list (slouží k pomocným výpočtům) a list se skupinami předmětů, kam se bude kopírovat podle názvů sloupců vyexportovaný soubor ze systému pro vytváření rozvrhů. Prvních pět zmíněných listů je potřeba pro rozdělení jednotlivých ročníků a zároveň rozdělení na magisterské a bakalářské studium. List se studenty bude vypadat podobně jako tabulka 5. Tabulka č. 7: List se studenty
Příjmení a jméno X XX XXX XXXX XXXXX XXXXXX XXXXXXX XXXXXXXX
Studijní skupina PRA_PAP PRA_MSPK PRA_PAP PRA_MKK PRA_PAP PRA_ZSSP PRA_MSPP PRA_PAK
Zdroj: Autor List se skupinami má přednastavené sloupce přesně pro nakopírování z exportovaného souboru. V tomto listu se dále bude u každé skupiny předmětu dopočítávat z listu pro import, kolik má daná rozvrhová akce nyní přiřazeno studentů. Toto slouží jako kontrola pro rozvrháře, který musí dodržet rozložení maximálního počtu studentů na cvičení do 30 a v počítačových učebnách do 24. Počet studentů na přednášku nesmí překročit 120 studentů na jednu rozvrhovou akci. List se skupinami předmětu bude vypadat přibližně jako tabulka 6. Tabulka č. 8: List se skupinami předmětů
Sloupec „X“ je dopočítáván pomocí funkce „COUNTIFS“ z listu „import“, který musí mít přesně stanovené sloupce pro import do IS BIVŠ. List „import“ je vytvářen ve formátu, který je zachycen v tabulce 7. Tabulka č. 9: List import
Zdroj: Autor Soubor list je vytvářen ručně rozvrhářem, který musí zajistit rozdělení podle listu se skupinami předmětů. Při tomto vytváření může snadno dojít k nějaké chybě, proto musí být rozvrhář opatrný. Pokud by ale stejně byla zjištěna nějaká chyba, tak kontrola při importu do IS BIVŠ tuto chybu vypíše a nepovolí import. Před samotným „ostrým“ importem dovoluje IS BIVŠ import na zkoušku, který vyzkouší importovaný předmět a ohlásí, co je v importovaném souboru špatně a import nikdy neprovede. Takto zpracovaný soubor je po odstranění všech případných chyb naimportován a studentům je zobrazen jejich vlastní rozvrh v IS BIVŠ v položce ROZVRH můj rozvrh. Každý student zde má svůj vlastní rozvrh včetně zařazení do skupin u cvičení, pokud je tak plánováno v jeho oboru u některého z předmětů. Jednotlivé exportované soubory se musí importovat vždy v pořadí – seminární skupiny, rozvrh a poslední studenti ke skupinám. V jiném pořadí nejsou importy povoleny IS BIVŠ, pro který je celý tento proces připravován. Resp. vše je připravováno proto, aby byly rozvrhy nastíněny studentům a vyučujícím dříve než týden před začátkem výuky, jako tomu bylo doposud. Ve fázi plánování a přípravy je řešení bez použití Excelu. Systém pro rozvrhy by měl v budoucnu mít nahrané plány výuky ve všech oborech a ročnících včetně rozdělení výuky na kombinovanou a prezenční formu. Toto by mělo stačit k rozdělení všech studentů, kteří by se 64
nahráli do systému se stejnými atributy, které by měl obor, aby mohlo být propočítáno, kolik by bylo potřeba skupin pro přednášky a cvičení, a zároveň by se tak zkontrolovalo, jestli je v rozvrhu naplánovaný dostatečný, nedostatečný nebo nadbytečný počet skupin pro jednotlivé předměty. Vše by sloužilo pro kontrolu a případnou úpravu. Po úpravě by se kliklo na tlačítko, které by spustilo script, který by vypočítal rozdělení do skupin a vytvořil by soubor pro import do IS BIVŠ. Analýza, programování, testování a následné „ostré“ spuštění zabere minimálně tři měsíce.
65
11 Zálohování programu, export a import databáze Záloha programu, export a import databáze jsou jedny z nejdůležitějších povinností správce systému pro vytváření rozvrhů.
11.1 Záloha programu Záloha programu je vlastně sama o sobě vytvářena vždy, když je nějaká úprava nahrána na webový hosting. Po nahrání se vytváří jedna verze na notebooku a druhá na webu. Pokud by se stalo, že nedopatřením hostingu se ztratí webová verze, je k dispozici ještě notebook. Toto je ale téměř nepravděpodobné, protože webový hosting má vždy nějakou zálohu serveru. Druhou možností je, že přestane pracovat notebook. Toto již není tak úplně nepravděpodobné. Pokud k tomuto problému dojde, je možné později na jiné zařízení stáhnout webovou verzi pomocí webového klienta FTP – net2ftp na adrese: http://www.net2ftp.com/index.php. Po přihlášení k tomuto klientovi se zobrazí celá struktura souborů začínající v root složce. Obrázek č. 15: Root složka net2ftp
Zdroj: Autor Při zaškrtnutí všech složek a souborů v rootu se klikne na tlačítko „Download“, jak je zobrazeno na obrázku č. 15, a tím se provede záloha do „*.zip“ souboru, kam je po uložení na zařízení, na kterém je program požadován, soubor uložen. Pokud by bylo nutné nějakým způsobem navrátit smazané soubory na webový hosting, je možné přes tlačítko „Upload“ zobrazené na obrázku č. 15 nahrát ztracené či smazané soubory.
66
Pomocí net2ftp je možné nahrávat i „*.zip“ soubory, které se po dokončení nahrávání na webovém serveru automaticky dekomprimují. Tímto způsobem je možné nahrát celý program na jiný webový hosting, pokud by to bylo nutné v budoucnu.
11.2 Export databáze Export databáze slouží jako záloha, která by se měla v době přípravy rozvrhů provádět minimálně 2x týdně, aby nedošlo při případné nehodě ke ztrátě všech provedených změn. Obrázek č. 16: Export pro phpMyAdmin
Zdroj: Autor Záloha se provádí pomocí databázového systému pro správu – phpMyAdmin. Po přihlášení do phpMyAdmin na adrese: https://mysql-g1.gransy.com/ se vybere databáze v levém rohu obrazovky a dále se zvolí záložka Export, která zobrazí možnosti exportu databáze, jak je to vidět na obrázku č. 16. Není potřeba nic měnit či nastavovat, protože standardně je přednastavená možnost SQL, což je kompaktní záloha, která je snadno přenositelná mezi 67
databázemi. V dolní části obrázku č. 16 je vidět, že je zaškrtnuta volba „Do souboru“. Tímto způsobem je zajištěno, že se nabídne uložení souboru s koncovkou „*.SQL“. Po stisknutí tlačítka „Proveď“ a následném uložení souboru na disk je záloha provedena.
11.3 Import databáze Import databáze je prováděna podobným způsobem jako export. Po přihlášení na webové adrese: https://mysql-g1.gransy.com/ je nutné vybrat záložku „Import“, která je zobrazena na obrázku č. 17. Před importováním pomocí dříve vyexportovaného souboru je nutné smazat všechny tabulky, jinak se neprovede import tabulek, které již v databázi jsou. Obrázek č. 17: Import pomocí phpMyAdmin
Zdroj: Autor Při kliknutí na tlačítko „Vybrat soubor“ je nutné vyhledat poslední uložený soubor „*.SQL“. V dalším kroku je nutné vybrat znakovou sadu, kterou je nutné nastavit na „latin1“. Toto nastavení je nutné pro správné zobrazení české diakritiky. Po kliknutí na tlačítko „Proveď“ se nahrají všechny tabulky, které daný soubor obsahuje, a celkové obnovení databáze je provedeno.
68
12 Příprava výpočtu úvazků vyučujících Celý systém pro vytváření rozvrhů neslouží pouze studentům a vyučujícím. V konečné fázi návrhu rozvrhů pomáhá také personálnímu a ekonomickému oddělení, kterým je vyexportován seznam všech vyučujících, kteří na BIVŠ vyučují. V tomto souboru jsou veškeré nezbytné informace, které jsou potřeba pro výpočet úvazku pro jednotlivé vyučující a kontrolu, zdali mají dostatečný či nedostatečný počet vyučovaných hodin, podle normy BIVŠ. Výsledkem výpisu vyučujících je CSV soubor, který obsahuje tyto informace o vyučujícím: 1) Jméno a příjmení. 2) UČO vyučujícího. 3) Katedra vyučujícího. 4) Internista/externista. 5) Přednášky či cvičení. 6) Prezenční či kombinovaná výuka. 7) Regionální pracoviště. 8) Výuka v angličtině. Všechny tyto informace jsou vypsány ve zmiňovaných sloupcích a každý vyučující má celý řádek, jak je to zobrazeno v tabulce č. 10. Jelikož každé oddělení vyžaduje jiný a specifický výběr informací, tak je nutné rozepsat u všech vyučujících všechny úvazky. Pro přepočítání úvazku je nutné vždy u jednotlivých vyučujících sečíst všechny hodiny kombinované formy včetně všech regionálních pracovišť, vydělit je dvanácti a k tomuto číslu připočíst sečtené hodiny prezenční výuky ve všech regionálních pracovištích. Tento výpočet udává, kolik hodin vyučuje vyučující za týden. Jelikož normy BIVŠ stanovují, kolik hodin musí jednotlivý vyučující dle svého pracovního zařazení učit za týden, tak je předešlý výpočet postačující.
Ambrožová Bronislava Anděl Jiří Andrášek Marek Babinská Ivana Baběradová Helena Bajer Josef Benda Josef Benda Karel Bendová Nataša Beneš Vladimír Beňová Kamila Beran Theodor Biedermann Denis Běhůnek Vladimír …
Je možné vypsat všechny vyučující, nebo může být zvolen jednotlivý vyučující, jak je to vidět na obrázku č. 18. Obrázek č. 18: Výpis hodin vyučujících
Zdroj: Autor Soubor, který zobrazuje tabulka č. 10, může být vypsán za zimní, letní nebo za oba semestry dohromady. Záleží na tom, co se právě žádá a jaký je účel vypsání výuky pro vyučujícího. Pro přezkoumání úvazku vyučujícího je nutné vybrat oba semestry dohromady, protože úvazek se průměruje za oba semestry dohromady. Pokud bude záměrem vedoucího nebo tajemníka katedry prozkoumat, kolik hodin a kde jeho vyučující vyučují, budou pravděpodobně požadovat všechny tři varianty a je nutné uložit zimní, letní a oba semestry dohromady do samostatného souboru CSV.
71
13 Zhodnocení přínosu práce Při srovnání nynějšího a minulého stavu přípravy rozvrhů pomocí hardwarové a softwarové techniky je největší přínos viditelný z hlediska času. Pro vyučující jsou předběžné rozvrhové akce zveřejněny dříve než před zavedením provozu nového systému a je možné provádět změny bez nutnosti nějaké časové prodlevy. Jsou tedy okamžitě upraveny a zveřejněny pro všechny uživatelské role. Zpřístupnění rozvrhových akcí pro studenty je možné asi dva měsíce před zahájením výuky oproti pouhému jednomu týdnu, který umožňoval starý systém. Studenti kombinovaného studia si tedy mohou plánovat dovolenou pro výuku podle předběžných rozvrhových akcí. Zdlouhavé změny rozvrhových akcí, které jsou požadovány na regionálních pracovištích, jsou po zavedení nového systému minulostí. Každé regionální pracoviště si změny provádí okamžitě, kdy jsou vyžadovány. Pro všechna regionální pracoviště i centrálu je největší časovou úsporou modul migrace dat. V minulosti bylo nutné vytvářet každý rok nový plán rozvrhových akcí. Tato činnost trvala přibližně tři týdny. V současné době je možné vytvořit předběžný plán rozvrhových akcí zhruba za dvacet minut. Největším přínosem celé práce je tedy časová úspora a možnost přípravy time managementu pro všechny uživatelské role, které jsou v systému využívány.
72
Závěr Jedním z cílů práce bylo navrhnout řešení celého systému ze softwarového a hardwarového hlediska tak, aby bylo možné efektivně schválené prostředky využít. Všechny navžené postupy byly využity, otestovány a některé byly pozměněny na základě zjištění nových poznatků. Nezbytnou součástí řešení cíle diplomové práce bylo programování a testování systému z hlediska všech uživatelských rolí. Navržené postupy, které byly využity v programování, byly správé, a proto nebyly nutné časté změny programovacího kódu. Systém pro rozvrhování akcí byl nasazen, testován a po připomínkování všemi uživatelskými rolemi drobně poupraven. Nasazení bylo provedeno během podzimu roku 2013. Zimní a letní semestr je v databázi zaveden a připraven k využití pro další období. Pro přípravu plánu pro následující roky bude systém již plně využívat veškeré funkce, které jsou zhotoveny na základě této práce. Jelikož se požadavky na funkčnost mění, je možné, že v budoucích letech bude systém ještě upravován. Všechny cíle, které byly stanoveny na počátku práce, byly s drobnými změnami splněny. V průběnu vypracování ještě přibyly nějaké úkoly, které by měl systém zpracovat. Nynější podoba systému neumožňuje změnu začátků a konců vyučovacích hodin. V budoucnosti se počítá s tím, že se všechny hodiny a pauzy sjednotí. Proto bude nutné některé moduly poupravit tak, aby vyhovovaly budoucím požadavkům školy.
73
Seznam použité literatury [1]
Java na www serveru - závěr. Výhody a nevýhody servletů, CGI, JSP a ASP[online]. 2006 [cit. 2014-02-18]. Dostupné z: http://www.ms.mff.cuni.cz/~kuceo9am/summary.html.
[2]
C Sharp - Wikipedie. C Sharp[online]. 2007 [cit. 2014-02-19]. Dostupné z: http://cs.wikipedia.org/wiki/C_Sharp.
[3]
ASP.NET - Wikipedie. ASP.NET [online]. 2000-2014 [cit. 2013-03-18]. Dostupné z: http://cs.wikipedia.org/wiki/ASP.NET.
TATROE Kevin, Peter MACINTYRE a Rasmus LERDORF. Programming PHP. 3rd Edition. Sebastopol, O'Reilly Media, 2013. 540 s. ISBN 978-1-4493-9277-2.
[2]
GILMORE Jason W. Velká kniha PHP 5 a MySQL. 3. vyd. Brno, Zoner Press, 2011, 736 s. ISBN 978-80-7413-163-9.
[3]
SHELDON Robert. SQL - začínáme programovat. Praha: Grada, 2005, 500 s. ISBN 80-247-0999-6.
[4]
MOHAMMED J. Kabir. Apache Server 2 - kompletní příručka administrátora. Praha: Computer Press, 2004, 722 s. ISBN 80-251-0319-6.
75
Seznam obrázků Obrázek č. 1: Tabulka databáze Access ................................................................................... 10 Obrázek č. 2: Dotaz databáze Access ....................................................................................... 11 Obrázek č. 3: Import do GenerovaniHTML ............................................................................. 12 Obrázek č. 4: Kontrola rozvrhových akcí................................................................................. 13 Obrázek č. 5: Rozvrh HTML z generátoru ............................................................................... 13 Obrázek č. 6: XAMPP – úvodní obrazovka ............................................................................. 21 Obrázek č. 7: PSPad ................................................................................................................. 22 Obrázek č. 8: Konečný návrh grafické podoby ........................................................................ 36 Obrázek č. 9: Schéma databáze ................................................................................................ 39 Obrázek č. 10: Zvolení tisku .................................................................................................... 53 Obrázek č. 11: Připraveno pro tisk ........................................................................................... 54 Obrázek č. 12: Hromadný tisk .................................................................................................. 55 Obrázek č. 13: Výpis seminárních skupin ................................................................................ 57 Obrázek č. 14: Export rozvrhu ................................................................................................. 60 Obrázek č. 15: Root složka net2ftp .......................................................................................... 66 Obrázek č. 16: Export pro phpMyAdmin ................................................................................. 67 Obrázek č. 17: Import pomocí phpMyAdmin .......................................................................... 68 Obrázek č. 18: Výpis hodin vyučujících .................................................................................. 71
76
Seznam tabulek Tabulka č. 1: Cena za licenci programu ROGER ..................................................................... 16 Tabulka č. 2: Kódování rozvrhových akcí................................................................................ 25 Tabulka č. 3: Role v systému.................................................................................................... 27 Tabulka č. 4: Požadavky vyučujících ....................................................................................... 49 Tabulka č. 5: Časový rozvrh výuky .......................................................................................... 60 Tabulka č. 6: Export pro přiřazení studentů k rozvrhu ............................................................. 62 Tabulka č. 7: List se studenty ................................................................................................... 63 Tabulka č. 8: List se skupinami předmětů ................................................................................ 63 Tabulka č. 9: List import .......................................................................................................... 64 Tabulka č. 10: Tabulka pro výpočet úvazků ............................................................................ 70
"; $myquery="select DISTINCT datum from rozvrh_ls where ucitel_uco = '$ucitel_uco_v' and typ_s_l = 'D' order by datum"; $myresult=mysql_query($myquery,$link); while ($row=mysql_fetch_array($myresult)) { $d = $row["datum"]; $datum_v = Date("j.n.Y","$d"); $mujdotaz="select * from rozvrh_ls where ucitel_uco = '$ucitel_uco_v' and typ_s_l = 'D' and datum = '$d' order by datum"; $mujvysledek=mysql_query($mujdotaz,$link); while ($how=mysql_fetch_array($mujvysledek)) { $id_predmet_v1 = $how["id_rozvrh"]; $den_cislo_v_1 = $how["den_cislo"]; } if($id_predmet_v1 == "") {} else { echo "
"; if ($den_cislo_v_1 == 1){$den_1 = "< Po > $datum_v";} if ($den_cislo_v_1 == 2){$den_1 = "< Út > $datum_v";} if ($den_cislo_v_1 == 3){$den_1 = "< St > $datum_v";} if ($den_cislo_v_1 == 4){$den_1 = "< Čt > $datum_v";} if ($den_cislo_v_1 == 5){$den_1 = "< Pá > $datum_v";} if ($den_cislo_v_1 == 6){$den_1 = "< So > $datum_v";} if ($den_cislo_v_1 == 0){$den_1 = "< Ne > $datum_v";} echo "
Příloha č. 3 if (isset($_POST['smazat'])){ if($_POST['name']!=""){ $name = $_POST['name']; include "../databaze.php"; $query="select * from rozvrh where kod_predmet like '$name/%'"; $result=mysql_query($query,$link); while ($row=mysql_fetch_array($result)) { $id_rozvrh_vv = $row["id_rozvrh"]; } include "../databaze.php"; $query="select * from rozvrh_ls where kod_predmet like '$name/%'"; $result=mysql_query($query,$link); while ($row=mysql_fetch_array($result)) { $id_rozvrh_vv_ls = $row["id_rozvrh"]; } if($id_rozvrh_vv == "" and $id_rozvrh_vv_ls == ""){ include "../databaze.php"; $quer="delete from predmety where kod_predmet = '$name'"; $resulta=mysql_query($quer,$link)or die("Smazání rozvrhového záznamu z databáze se nezdařilo !"); echo "
Předmět byl smazán z databáze !!!
"; } else{ echo "
Předmět nemůže být smazán, protože má v databázi rozvrhů uloženou nějakou akci. Vymažte všechny rozvrhové akce a potom smazání předmětu opakujte !!!
"; } } else { echo "
Není vyplněno jméno předmětu!
"; } } ?> Zdroj: vlastní tvorba autora
2
Příloha č. 4 Předmět $predmet_jmeno -
1
$kod_predmet byl upraven včetně rozvrhových akcí v databázi rozvhů !!!"; }else{ echo "
Příloha č. 6 Tento účet je již v databázi vytvořen !!!"; } else { include "../databaze.php"; $dot="insert into ucty values('','$login_ucty','$heslo_ucty','$pristup_ucty','$max_zapis')"; $res=mysql_query($dot,$link)or die("Nebylo možné zapsat účet do databáze !"); echo "
Účet byl vytvořen !!!
"; }}else{ echo "
Některá z hodnot není vyplněna !!!
"; }} ?> Zdroj: vlastní tvorba autora
2
Příloha č. 7 Uživatelský účet byl smazán z databáze !!!"; }else{ echo "
Účet nemůže být smazán, protože má v databázi rozvrhů uloženou nějakou akci. Vymažte všechny rozvrhové akce a potom smazání účtu opakujte !!!
"; }}else{ echo "
Není vybrán uživatelský účet!
"; }} ?> Zdroj: vlastní tvorba autora
2
Příloha č. 8 Heslo je změněno!"; }else{ echo "
Nová hesla se neshodují!
"; }}else{ echo "
Špatné staré heslo!
"; }}else{ echo "
Některá z hodnot není vyplněna!
"; } } ?> Zdroj: vlastní tvorba autora
1
Příloha č. 9 Datumy jsou přečíslovány !!!"; }else{ echo "
