Systém pro evidenci hospitací v Ruby on Rails Roz²i°te prototyp aplikace pro evidenci hospitací (http://kvalitavyuky.felk.cvut.cz/) tak, aby jej bylo moºné nasadit do reálného provozu na VUT FEL. Systém implementujte na platform¥ Ruby on Rail. Vývoj provád¥jte iterativním zp·sobem a postupn¥ zapracovávejte poºadavky zadavatele. Celý vývoj °ádn¥ dokumentujte a výsledky své práce otestujte. Funk£nost systému demonstrujte na hospitacích, které budou probíhat v programu STM v LS 2011/2012.
i
ii
eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·
Bakalá°ská práce
Systém pro evidenci hospitací v Ruby on Rails
Tomá² Turek
Vedoucí práce:
Ing. Martin Komárek
Studijní program: Softwarové technologie a management, Bakalá°ský
Obor: Softwarové inºenýrství
23. kv¥tna 2012
iv
v
Pod¥kování Cht¥l bych pod¥kovat vedoucímu práce panu Ing. Martinovi Komárkovi za rady a pomoc p°i tvorb¥ bakalá°ské práce. Dále bych cht¥l pod¥kovat Danielovi Kr¦»elokovi za poskytnutí cenných informací a prototypu aplikace. Rovn¥º pat°í m·j dík rodin¥ za podporu p°i studiu.
vi
vii
Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn¥ a pouºil jsem pouze podklady uvedené v p°iloºeném seznamu. Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu 60 Zákona £. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon· (autorský zákon).
V Praze dne 22. 5. 2012
.............................................................
viii
Abstract The purpose of this work is to design and develop a system for evidence inspections of classes. This application will be used at the CTU in Prague Faculty of Electrical Engineering. Reason to create the system is to relieve the administrative burden that increases with increase in the number of observations. The application is based on the existing processes of management inspections for the study program STM. The application is created on the platform of Ruby on Rails and builds on a prototype application. The real development of the application is headed by an iterative method of software development. The resulting application is deployed at https://kvalitavyuky.felk.cvut.cz. I have demonstrated the functionality of the on-going observation in the summer semester 2011/2012.
Abstrakt Ú£elem této práce je navrhnout a vytvo°it systém pro evidenci hospitací. Tato aplikace bude pouºívaná na VUT v Praze Fakult¥ elektrotechnické. D·vodem vzniku systému je uleh£it administrativní zát¥º, která se zvy²uje s nár·stem po£tu hospitací. Aplikace je zaloºena na jiº existujících procesech správy hospitací pro studijní obor STM. Aplikace je vytvo°ená na platform¥ Ruby on Rails a navazuje na prototyp aplikace. Samotný vývoj aplikace je veden iterativní metodou vývoje softwaru. Výsledná práce je nasazená na adrese https://kvalitavyuky.felk.cvut.cz. Funk£nost jsem demonstroval na probíhajících hospitací v letním semestru 2011/2012.
ix
x
Obsah 1 Úvod
1
2 Popis problému, speci kace cíle
3
2.1 2.2 2.3
Motivace . . . . . . . . . . . . . . . . . . . Cíle práce . . . . . . . . . . . . . . . . . . Re²er²e . . . . . . . . . . . . . . . . . . . 2.3.1 Prototyp . . . . . . . . . . . . . . . 2.3.2 Postupy pro kontrolu kvality výuky 2.3.2.1 Administrátor hospitací . 2.3.2.2 Plánování hospitací . . . 2.3.2.3 Typy hospitací . . . . . . 2.3.2.4 Provedení hospitace . . . 2.3.2.5 Hodnocení výuky . . . . .
3 Analýza 3.1
3.2
3.3
3.4
Poºadavky . . . . . . . . . . . . 3.1.1 Obecné poºadavky . . . 3.1.2 Funk£ní poºadavky . . . Uºivatelské role . . . . . . . . . 3.2.1 Nep°ihlá²ený uºivatel . . 3.2.2 P°ihlá²ený uºivatel . . . 3.2.3 Hospitovaný . . . . . . . 3.2.4 Hospitující . . . . . . . 3.2.5 Administrátor hospitací 3.2.6 Administrátor . . . . . . Doménový model . . . . . . . . 3.3.1 Entity v KOSapi . . . . 3.3.2 Entity aplikace . . . . . Pr·b¥h hospitace . . . . . . . . 3.4.1 Vytvo°ení . . . . . . . . 3.4.2 Plánování . . . . . . . . 3.4.3 Hodnocení . . . . . . . . 3.4.4 Ukon£ená . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . xi
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 3 3 4 4 4 4 4 5 5
7
7 7 7 8 9 9 9 9 9 9 10 10 10 12 12 12 12 12
xii
OBSAH
4 Návrh 4.1
4.2
4.3
Technologie a sluºby . . . . . . . . 4.1.1 Ruby on Rails . . . . . . . . 4.1.1.1 Balí£kovací systém 4.1.2 KOSapi . . . . . . . . . . . 4.1.3 FELid . . . . . . . . . . . . 4.1.4 Aplika£ní server . . . . . . . 4.1.5 Databáze . . . . . . . . . . Architektura . . . . . . . . . . . . 4.2.1 MVC . . . . . . . . . . . . . 4.2.1.1 Model . . . . . . . 4.2.1.2 View . . . . . . . 4.2.1.3 Controller . . . . . 4.2.2 DRY . . . . . . . . . . . . . 4.2.3 CoC . . . . . . . . . . . . . 4.2.4 REST . . . . . . . . . . . . Struktura aplikace . . . . . . . . .
5 Realizace 5.1
5.2
5.3
5.4
. . . . . . . . . . . . . . RubyGems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
První iterace . . . . . . . . . . . . . 5.1.1 Zadání . . . . . . . . . . . . . 5.1.2 Postup . . . . . . . . . . . . . 5.1.2.1 Datová vrstva . . . 5.1.2.2 Autentizace . . . . . 5.1.2.3 Autorizace . . . . . 5.1.2.4 Role . . . . . . . . . 5.1.2.5 Uºivatelské prost°edí 5.1.3 Výstup . . . . . . . . . . . . Druhá iterace . . . . . . . . . . . . . 5.2.1 Zadání . . . . . . . . . . . . . 5.2.2 Postup . . . . . . . . . . . . . 5.2.2.1 Datová vrstva . . . 5.2.2.2 Hodnotící formulá°e 5.2.3 Výstup . . . . . . . . . . . . T°etí iterace . . . . . . . . . . . . . . 5.3.1 Zadání . . . . . . . . . . . . . 5.3.2 Postup . . . . . . . . . . . . . 5.3.2.1 Nasazení aplikace . 5.3.2.2 FELid . . . . . . . . 5.3.2.3 Zálohování databáze 5.3.3 Výstup . . . . . . . . . . . . tvrtá iterace . . . . . . . . . . . . . 5.4.1 Zadání . . . . . . . . . . . . . 5.4.2 Postup . . . . . . . . . . . . . 5.4.2.1 Autentizace . . . . . 5.4.2.2 Emaily . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
15 15 15 15 16 16 16 16 16 17 17 17 17 17 17 18
21
21 21 21 21 22 22 22 23 23 23 23 23 23 24 26 26 26 26 26 27 27 27 28 28 28 28 28
xiii
OBSAH
5.4.3
5.4.2.3 Generátor obsahu emailových zpráv . . . . . . . . . . . . . . 28 5.4.2.4 Odesílání email· . . . . . . . . . . . . . . . . . . . . . . . . . 30 Výstup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6 Testování 6.1
6.2 6.3
Automatické testování 6.1.1 Testovací data 6.1.2 Unit testing . . 6.1.3 Functional tests Manuální testování . . Systémové testování .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
31
31 31 31 31 32 32
7 Záv¥r
35
A Seznam pouºitých zkratek
39
B UML diagramy a obrázky
41
C Dynamické formulá°e
45
D Test Cases
47
E Instala£ní a uºivatelská p°íru£ka
51
F Obsah p°iloºeného CD
53
7.1 7.2 7.3
Zhodnocení spln¥ní cíl· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Osobní p°ínos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Moºnosti pokra£ování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
B.1 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
E.1 Instalace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 E.2 Kon gurace a p°íprava aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . 52 E.3 Spu²t¥ní aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
xiv
OBSAH
Seznam obrázk· 3.1 3.2 3.3
Akté°i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Doménový model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Pr·b¥h hospitace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1
Struktura aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1 5.2 5.3 5.4 5.5 5.6
Dekompozice pomocí polymorfní asociace Doménový model dynamických formulá°· P°íklad stromové struktury formulá°e . . . P°íklad uloºených dat . . . . . . . . . . . Diagram nasazení . . . . . . . . . . . . . . Struktura zna£ky . . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
24 25 26 26 27 30
B.1 B.2 B.3 B.4 B.5 B.6
Use Use Use Use Use Use
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
41 42 42 43 43 44
case case case case case case
-
nep°ihlá²ený uºivatel . p°ihlá²ený uºivatel . . hospitovaný . . . . . . hospitující . . . . . . . administrátor . . . . . administrátor hospitací
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
C.1 Hodnotící formulá° A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 F.1 Obsah CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
xv
xvi
SEZNAM OBRÁZK
Seznam tabulek 5.1 5.2
Reprezentace rolí v bitové masce . . . . . . . . . . . . . . . . . . . . . . . . . 22 Popis atribut· tabulky PeopleRelated . . . . . . . . . . . . . . . . . . . . . . 24
6.1
Výsledky systémového testování . . . . . . . . . . . . . . . . . . . . . . . . . . 33
C.1 Seznam podporovaných typ· element· . . . . . . . . . . . . . . . . . . . . . . 45
xvii
xviii
SEZNAM TABULEK
Kapitola 1
Úvod Na FEL VUT byl zaveden pro studijní program STM (Softwarové technologie a management) systém pro ov¥°ování kvality výuky. Cílem tohoto systému je zkvalitnit vyu£ované p°edm¥ty. Jedním ze zdroj· informací jsou kontrolní náv²t¥vy ve výukách1 . Ú£elem t¥chto náv²t¥v je získání komplexního obrazu o kvalit¥ výuky pro garanty jednotlivých p°edm¥t· a zárove¬ slouºí pro pedagogy jako zp¥tná vazba z p°edná²ek a cvi£ení. Cílem mé práce je navrhnout a vytvo°it informa£ní systém pro správu hospitací na FEL VUT, který zjednodu²í a zrychlí administrativu, ke které se doposud pouºívala emailová komunikace a www stránky Rady programu [25]. Systém je postaven na moderním frameworku Ruby on Rails, který je ur£en pro vývoj moderních webových aplikací. Systém vyuºívá dv¥ falkultní aplikace FELid a KOSapi.
1
zkrácen¥ hospitace
1
2
KAPITOLA 1.
ÚVOD
Kapitola 2
Popis problému, speci kace cíle 2.1 Motivace Jak jsem uvedl v úvodu, tak v sou£asné dob¥ probíhá jakákoliv administrativní £innost okolo hospitací p°eváºn¥ pomocí emailové komunikace. Zaji²´uje jí garantem studijního oboru p°i°azený administrátor kontroly výuky, který je dále uvád¥n jako administrátor, nebo administrátor hospitací. Jeho úkolem je starat se o plánování hospitací a vystavování dokument· na stránkách rady studijního programu [25]. P°i naplánování hospitace musí administrátor ru£n¥ obeslat emailem informaci o naplánované hospitaci v²em zainteresovaným osobám. To jsou hospitovaní, hospitující, p°edná²ející a garanti p°íslu²ného p°edm¥tu. Po provedení hospitace je pot°eba shromáºdit a vystavit ve²keré dokumenty na webových stránkách Rady programu. Administrátor musí hlídat tok dokument· a rozesílat vzniklé dokumenty mezi ú£astníky hospitace. Tento systém sice funguje, ale je administrativn¥ a £asov¥ náro£ný p°i zvy²ujícím se po£tu hospitací jak pro administrátora hospitací, který se stará o komunikaci mezi ú£astníky, tak i pro zú£astn¥né strany hospitace. Proto byl podán poºadavek na vytvo°ení systému pro evidenci hospitací, který zautomatizuje vnit°ní procesy pro správu hospitací.
2.2 Cíle práce Hlavním cílem mé práce je roz²í°it prototyp aplikace pro evidenci hospitací, tak aby bylo moºné ji nasadit do reálného provozu na FEL VUT. V pr·b¥hu letního semestru 2011/2012 se bude postupn¥ demonstrovat její funk£nost na realizovaných hospitacích v daném semestru.
2.3 Re²er²e Hospitace, jak uº jsem nastínil v motivaci, je zavedený vnit°ní proces kontroly kvality výuky na VUT FEL. Informace proto £erpám ze dvou hlavních zdroj·. Prvním zdrojem je dokument Postupy pro kontrolu kvality výuky [23], který de nuje jak se mají hospitace 3
4
KAPITOLA 2.
POPIS PROBLÉMU, SPECIFIKACE CÍLE
provád¥t. A druhým zdrojem je prototyp aplikace z rozpracované bakalá°ské práce Návrh a implementace systému pro správu hospitací [26]. 2.3.1
Prototyp
Jako referen£ní °e²ení práce jsem obdrºel prototyp aplikace napsaný v Ruby on Rails. Ten se skládá z dokumentace a z rozpracované webové aplikace. Dokumentace k prototypu obsahuje analýzu a návrh aplikace, coº mi pomohlo p°i vývoji aplikace a také pochopení problematiky hospitací. Práce se samotnou aplikací byla jiº obtíºn¥j²í, protoºe verze, kterou jsem obdrºel, byla velmi rozpracovaná a ne²la spustit. Po zprovozn¥ní aplikace do spustitelného stavu jsem zjistil, ºe aplikace umí získávat data ze sluºby KOSapi1 a plánovat hospitace. Zp·sob plánování hospitací je v prototypu uºivatelsky nep°ív¥tivý. Pro naplánování hospitace musí uºivatel vybírat p°edm¥t a hospitujícího pomocí roletkových seznam· bez moºnosti ltrování. S tisíci záznamy v seznamu je skoro nemoºné najít ten správný záznam. V nedostate£ném stavu byly i hodnotící formulá°e. Prototyp sice obsahuje formulá°e, ale nebyla k nim implementována funkcionalita. D·vod pro£ navazuji na rozpracovanou práci je ten, ºe p·vodní autor se rozhodl kompletn¥ p°ejít na jinou technologii neº je Ruby on Rails. Nakonec, po hlub²í analýze prototypu programu, jsem se rozhodl p°evzít z prototypu aplikace pouze p°ipojení ke KOSapi a zbytek ud¥lat od základ· nový. 2.3.2
Postupy pro kontrolu kvality výuky
V této £ásti kapitoly popisuji hlavní procesy p°i vykonávání hospitací. Tyto informace £erpám z jiº zmín¥ného dokumentu Postupy pro kontrolu kvality výuky [23], kde jsou obsaºeny ve²keré pot°ebné informace o pr·b¥hu hospitací.
2.3.2.1 Administrátor hospitací Ke kaºdému studijnímu programu je p°id¥lena ur£itá osoba, kterou vybírá garant studijního oboru. Tato osoba se stará o hospitace pro studijní obor, ke je p°i°azena. Hlavními úkoly administrátora jsou plánování a °ízení hospitací.
2.3.2.2 Plánování hospitací Pro naplánování hospitace musí administrátor hospitací nade novat p°edm¥t, paralelku a datum hospitace. Hospitace m·ºe probíhat jak na p°edná²kách, tak i na cvi£eních. Do plánování pat°í i p°i°azení hospitujících2 , kte°í provedou kontrolní náv²t¥vu ve výuce.
2.3.2.3 Typy hospitací Administrátor také ur£uje typ hospitace. Jsou zavedeny t°i druhy, které se p°edev²ím rozli²ují z hlediska hospitovaného. Jsou to: 1 2
viz. 4.1.2 typicky je to dvojce pedagog· jeden zku²ený a druhý za£ínající
2.3.
REERE
5
P°edem ohlá²ené na konkrétní datum
u tohoto typu hospitace jsou ve°ejné v²echny informace o naplánování hospitace. Proto je pot°eba, aby administrátor naplánoval hospitaci s p°edstihem a informoval o tom hospitovaného.
P°edem ohlá²ené bez konkrétního termínu
tento typ hospitace na rozdíl od p°ede²lého typu nemá pevn¥ stanovený datum hospitace. Hospitovaný sice ví o naplánované hospitaci, ale není zve°ejn¥n datum, kdy prob¥hne.
P°edem neohlá²ené
tento typ hospitace se pouºívá jen z°ídka a to u problémových p°edm¥t·, nebo p°i °e²ení váºných stíºností na vyu£ujícího. Proto u tohoto typu hospitace je p°edem informován pouze garant, zástupce garanta a administrátor výuky.
2.3.2.4 Provedení hospitace Hospitace se vykoná kontrolní náv²t¥vou hospitujících ve výuce, o které sepí²í dokument Hodnocení výuky. V n¥m zdokumentují pr·b¥h hodiny a její hodnocení.
2.3.2.5 Hodnocení výuky Po vykonání hospitace následuje hodnotící fáze. Ta se skládá ze £ty° druh· dokument·, které zhodnotí prob¥hlou výuku. V²echny dokumenty musí být p°edány administrátorovi hospitací. Ten je vystaví na privátní £ásti webových stránek Rady programu [25]. Po sepsání a vystavení v²ech dokument· je hospitace ukon£ená. Dokumenty pouºívané p°i hodnocení: A Hodnocení výuky p°i hospitaci - ten dokument je písemný výstup z hospitace. Hlavním ú£elem tohoto dokumentu je slovn¥ popsat pr·b¥h výuky. Dokument se skládá z dokumenta£ní £ásti a z hodnotící £ásti. Tento formulá° vypl¬uje kaºdý hospitující sám za sebe. B Slovní hodnocení hospita£ní náv²t¥vy hospitujícím(mi) - tento dokument sepí²e po provedení hospitace jeden z hospitujících a ú£elem tohoto dokumentu je slovn¥ zhodnotit výuku. C Stanovisko hodnoceného u£itele k názor·m hospitujícího - tímto dokumentem se m·ºe hospitovaný, garant p°edm¥tu a vedoucí katedry vyjád°it k slovnímu hodnocení. Proto tento dokument lze sepsat aº po vystavení formulá°e B. D Záv¥re£né shrnutí hospitujícím - je poslední a nejd·leºit¥j²í dokument ze v²ech. Sepí²e ho jeden z hospitujících. Tento dokument slouºí jako výstup hodnocení hospitace. Dokument obsahuje klady, zápory, navrºená opat°ení a záv¥r. Je také jediným ve°ejným dokumentem a proto je pot°eba ho vytavit na voln¥ p°ístupných stránkách.
6
KAPITOLA 2.
POPIS PROBLÉMU, SPECIFIKACE CÍLE
Kapitola 3
Analýza Tato kapitola pojednává o analýze aplikace. Výstupem této £ásti jsou funk£ní, obecné poºadavky, doménový model, akté°i a k nim p°ípady uºití.
3.1 Poºadavky Poºadavky na systém se d¥lí na dv¥ sekce: obecné a funk£ní poºadavky. Poºadavky na systém jsem p°evzal z prototypu aplikace [26] a roz²í°il jsem je o roz²i°ující speci kace zadavatele. Tyto poºadavky mi de nují návrh aplikace a technologie pot°ebné pro implementaci systému. 3.1.1
Obecné poºadavky
Obecné poºadavky se netýkají funk£nosti, ale celkového návrhu a pouºitých technologií. 1. Systém bude postaven na webovém frameworku Ruby on Rails. 2. Systém bude webovou aplikací. 3. Systém bude pouºívat webovou sluºbu KOSapi. 4. Systém bude pro autentizaci pouºívat aplikaci FELid. 3.1.2
Funk£ní poºadavky
Tato sekce se zabývá poºadavky na funk£nost systému. 1. Systém umoºní pr·b¥ºn¥ plánovat hospitace. 2. Systém umoºní hospitujícímu i hospitovanému prohlíºet hospitace. 3. Systém umoºní vystavit záv¥re£né hodnocení na ve°ejné £ásti aplikace. 4. Systém umoºní hospitovanému sepsat stanoviska k názor·m hospitujícího. 7
8
KAPITOLA 3.
ANALÝZA
5. Systém umoºní hospitujícímu nahrát naskenovaný dokument Hodnocení výuky. 6. Systém umoºní hospitujícímu napsat slovní hodnocení z výuky. 7. Systém umoºní hospitujícímu napsat záv¥re£né shrnutí hospitace. 8. Systém bude odesílat informa£ním emailem zprávy p°i vypln¥ní hodnotícího dokumentu. 9. Systém umoºní vyhledávat p°edm¥ty z KOSapi. 10. Systém umoºní vyhledávat osoby z KOSapi. 11. Systém umoºní upravovat strukturu hodnotících formulá°·. 12. Systém umoºní spravovat emailové ²ablony. 13. Systém umoºní generovat emailové zprávy z emailových ²ablon. 14. Systém bude automaticky zálohovat databázi.
3.2 Uºivatelské role V systému je celkem 7 uºivatelských rolí. De noval jsem £ty°i základní uºivatelské role, které jsou základem systému: nep°ihlá²ený uºivatel, p°ihlá²ený uºivatel, administrátor hospitací a administrátor. Dal²í dv¥ role hospitovaný a hospitující se p°id¥lují v rámci konkrétních hospitací. Na obrázku 3.1 jsou jednotliví akté°i a jejich zobecn¥ní. V dal²í £ásti této sekce rozeberu jednotlivé role a k nim p°ípady uºití, ty jsem roz²í°il z prototypu aplikace [26]. P°ípady uºití jsou obsaºeny v p°íloze B.1 tohoto dokumentu.
Use cases
neboli p°ípady uºití je nástroj pro popsání chování, jak by m¥l systém spolupracovat s koncovým uºivatelem. Popisuje v²echny zp·soby, jak uºivatel komunikuje se systémem.
Obrázek 3.1: Akté°i
3.2.
UIVATELSKÉ ROLE
3.2.1
9
Nep°ihlá²ený uºivatel
Nep°ihlá²ený uºivatel je role pro hosty na²í aplikace. V systému má ze v²ech rolí nejmen²í pravomoc. V tomto stavu je kaºdý uºivatel, který se doposud nep°ihlásil do systému. P°ípady uºití pro nep°ihlá²eného uºivatele jsou na obrázku B.1. 3.2.2
P°ihlá²ený uºivatel
P°ihlá²ený uºivatel vychází z role nep°ihlá²eného uºivatele. Je to uºivatel, který se do systému p°ihlásil. Jedná se o základní roli pro v²echny dal²í role, které ji roz²i°ují. P°ípady uºití pro p°ihlá²eného uºivatele jsou na obrázku B.2. 3.2.3
Hospitovaný
Hospitovaný je role pro p°ihlá²eného uºivatele v systému. Je p°id¥lena automaticky pro kaºdého vyu£ujícího, který vyu£uje p°edm¥t, na n¥mº byla naplánovaná hospitace a tato hospitace prob¥hla. P°ípady uºití pro hospitovaného jsou na obrázku B.3. 3.2.4
Hospitující
Hospitující je role pro p°ihlá²eného uºivatele v systému. P°id¥luje se automaticky osobám, které mají za úkol vykonat hospitaci p°edm¥tu. P°ípady uºití pro hospitujícího jsou na obrázku B.4. 3.2.5
Administrátor hospitací
Hlavním úkolem této role je plánovat hospitace na p°edm¥ty a posléze je spravovat. P°ípady uºití pro administrátora jsou na obrázku B.6. 3.2.6
Administrátor
Administrátor je super uºivatel, který má nejvy²²í pravomoc v systému. Má p°ístup ke v²em zdroj·m aplikace a m·ºe aplikaci spravovat. P°ípady uºití pro administrátora jsou na obrázku B.5.
10
KAPITOLA 3.
ANALÝZA
3.3 Doménový model Doménový model na obrázku 3.2 reprezentuje entity v systému a jejich vzájemné vztahy. Doménový model z prototypu [26] jsem musel p°ed¥lat, protoºe v n¥m byla spousta návrhových chyb a byl nedostate£ný. Popis jednotlivých entit jsem pro p°ehlednost rozd¥lil podle zdroje na dv¥ základní skupiny. V první skupin¥ jsou entity, které jsem p°evzal z RESTful rozhraní KOSapi1 a druhou skupinou jsou entity speci cké pro moji aplikaci. Detailní popis jednotlivých entit s doménovým modelem je k dispozici v elektronické p°íloze [8]. 3.3.1
Entity v KOSapi
• Person - je osoba v KOSu. Kaºdá osoba m·ºe být u£itelem a studentem. • Semester - semestr vyu£ovaný na FEL. • Course - p°edm¥ty vyu£ované na FEL. • CourseInstance - jsou instance p°edm¥tu vypsané v konkrétním semestru. • Parallel - je vypsaná rozvrhová paralelka pro instanci p°edm¥tu. • Room - místnost na FEL. 3.3.2
Entity aplikace
• Observation - je hospitace. Obsahuje informace o naplánování hospitace. • Note - je textová poznámka k plánování hospitace. • Evaluation - reprezentuje informace pro hodnocení z prob¥hlé hospitace hospitace, jsou to informace o datu vykonání hospitace, hospitujícím, p°edm¥tu a garantovi. • Attachment - je p°íloha s s datovým souborem k hodnocení hospitace. • FormTemplate - ²ablona pro tvorbu formulá°·. De nuje vlastnosti jakým se budou vytvá°et hodnotící formulá°e. • EntryTemplate - poloºka reprezentuje jednotlivé segmenty formulá°e. Tyto segmenty pak v celku de nují strukturu formulá°e. • Form - vypln¥ný hodnotící formulá°. • Entry - je poloºka s hodnotou vypln¥ného formulá°e. • EmailTemplate - ²ablona emailu ze které se budou generovat emailové zprávy.
1
viz. 4.1.2
3.3.
11
DOMÉNOVÝ MODEL
Obrázek 3.2: Doménový model
12
KAPITOLA 3.
ANALÝZA
3.4 Pr·b¥h hospitace Cílem této £ásti analýzy je popsat pr·b¥h hospitace od jejího vytvo°ení po ukon£ení. Pr·b¥h hospitace je gra cky zobrazený na diagramu 3.3. 3.4.1
Vytvo°ení
ivotní cyklus hospitace za£íná jejím vytvo°ením. V této fázi ú£inkuje pouze aktér administrátor hospitací. P°i vytvá°ení hospitace je pot°eba de novat: p°edm¥t, semestr a typ hospitace2 . Po úsp¥²ném vytvo°ení hospitace následuje fáze plánování. 3.4.2
Plánování
P°i plánování je také hlavním aktérem administrátor hospitace. V této £ásti ºivotního cyklu administrátor ur£í paralelku p°edm¥tu a datum uskute£n¥ní hospitace. V této fázi musí administrátor hospitací p°id¥lit hospitujícího. 3.4.3
Hodnocení
Po vykonání kontrolní náv²t¥vy za£íná nová fáze hodnocení vyu£ování. V této fázi jiº neú£inkuje administrátor hospitace, ale p°icházejí na scénu akté°i hospitovaný a hospitující. Hodnocení probíhá postupným vypl¬ováním hodnotících formulá°·. 1. Hospitující musí vyplnit, nebo nahrát naskenovaný formulá° Hodnocení výuky p°i hospitaci. Tento formulá° slouºí k dokumentaci pr·b¥hu hospitace. 2. Jeden z hospitujících sepí²e Slovní hodnocení hospita£ní náv²t¥vy. 3. Pokud se chce hospitovaný vyjád°it k hospitaci, m·ºe vyplnit formulá° Stanovisko hodnoceného k názor·m hospitujícího. 4. Jeden z hospitujících sepí²e formulá° Záv¥re£né shrnutí. 3.4.4
Ukon£ená
Po vypln¥ní posledního formulá°e Záv¥re£né shrnutí je hospitace ve stavu ukon£ená a tím kon£í i její ºivotní cyklus.
2
de nuje zp·sob zviditeln¥ní, pro ostatní aktéry v aplikaci
3.4.
13
PRB
H HOSPITACE
Obrázek 3.3: Pr·b¥h hospitace
14
KAPITOLA 3.
ANALÝZA
Kapitola 4
Návrh 4.1 Technologie a sluºby Tato £ást popisuje jednotlivé technologie a sluºby pot°ebné pro implementaci aplikace.
4.1.1
Ruby on Rails
Ruby on Rails [15], zkrácen¥ Rails, je jedno z implementa£ních omezení, které se nachází v zadání práce. Jedná se o moderní framework ur£ený pro vývoj webových aplikací napojených na rela£ní databázi. Framework je napsán ve skriptovacím interpretovaným programovacím jazyku Ruby [14]. Rails pouºívá návrhový vzor Model-view-controller viz 4.2.1. Mezi základní my²lenky a lozo í frameworku pat°í dva principy. Prvním principem je Convention over Con guration viz 4.2.3 a druhým je Don't Repeat Yourself viz 4.2.2.
4.1.1.1 Balí£kovací systém RubyGems Protoºe jsou Rails postaveny na jazyku Ruby lze pouºívat balí£kovací systém RubyGems, kde je velké mnoºství jiº existujících °e²ení, které jsou dostupné jako knihovny1 .
4.1.2
KOSapi
KOSapi je ²kolní webová sluºba poskytující aplika£ní rozhraní v podob¥ RESTful webové sluºby 4.2.4. Je ur£ená pro vznik ²kolních aplikací, které pot°ebují mít p°ístup k dat·m souvisejících s výukou. P°i vývoji aplikace pouºívám stabilní verzi 2 API. Z této sluºby aplikace £erpá hlavn¥ data p°edm¥t· a osob v KOSu. Pro p°ipojení ke KOSapi pouºívám jiº existující knihovnu napsanou v Ruby ze ²kolního projektu VyVy[18]. 1
v RubyGems se knihovna nazývá Gem
15
16
KAPITOLA 4.
4.1.3
NÁVRH
FELid
FELid [9] je globální autentiza£ní a autoriza£ní systém pro webovské aplikace na síti FEL. Poskytuje jednotný a bezpe£ný zp·sob p°ihlá²ení uºivatel· a p°enos jejich údaj· do r·zných aplikací na webu. Zárove¬ podporuje jednorázové p°ihlá²ení (tzv. single sign-on). Znamená to, ºe se uºivatel p°ihla²uje pouze do první pouºité aplikace a u dal²ích aplikací uº nemusí zadávat svoje p°ihla²ovací údaje. Tuto sluºbu pouºívám pro autentizaci uºivatel· do systému. Pro zprovozn¥ní aplikace FELid je nutné splnit technické poºadavky, které jsou vystaveny na o ciálních stránkách [10]. 4.1.4
Aplika£ní server
Pro zprovozn¥ní aplikace do reálného provozu jsem pouºil webový server Apache HTTP server 2.4 [21]. Tento aplika£ní server jsem musel zvolit, abych mohl splnit dva obecné poºadavky aplikace. Aplikace musí být napsaná v Ruby on Rails a vyuºívat aplikaci FELid pro autentizaci. Tato verze webového serveru totiº dovolí nainstalovat zásuvné moduly Passenger [27] a Shibboleth [24]. Passenger umoº¬uje nasazení Rails aplikací na aplika£ním serveru. Druhý modul Shibboleth zprost°edkovává single sign-on autentizaci mezi aplika£ním serverem a sluºbou FELid. 4.1.5
Databáze
Ruby on Rails poskytuje moºnost p°ipojení k r·zným databázovým systém·m prost°ednictvím adaptér·. Díky tomu není aplikace závislá na databázovém systému. Tuto vlastnost pouºívám p°i vývoji a testování aplikace, kde vyuºívám jednoduchý a snadno kon gurovatelný databázový systém SQLite [22], který pro tyto ú£ely bohat¥ posta£í. Pro samotné nasazení aplikace do provozu uº pouºívám databázový systém MySQL [20].
4.2 Architektura V této £ásti popisuji pouºité architektonické vzory a konvence, které dodrºuji p°i implementaci aplikace. 4.2.1
MVC
MVC (Model-view-controller) [12] je softwarová architektura, která rozd¥luje datový model aplikace, uºivatelské rozhraní a °ídicí logiku do t°í nezávislých komponent2 tak, ºe modi kace n¥které z nich má minimální vliv na ostatní. Tento architektonický vzor obsahuje ve svém jádru Ruby on Rails, proto pro implementaci tohoto vzoru vycházím z fungování frameworku. 2
models, views a controllers
4.2.
ARCHITEKTURA
17
4.2.1.1 Model Model reprezentuje informace v aplikaci a pravidla pro práci s nimi. V p°ípad¥ Rails jsou modely primárn¥ vyuºívány pro interakci s p°íslu²nou tabulkou v databázi a pro ukládání pravidel této interakce. Ve v¥t²in¥ p°ípad· odpovídá jedna tabulka v databázi jednomu modelu aplikace. Modely obsahují v¥t²inu aplika£ní logiky.
4.2.1.2 View Pohledy, neboli views reprezentují uºivatelské rozhraní aplikace. V Rails jsou views obvykle HTML soubory s vloºenými £ástmi Ruby kódu, který provádí pouze úkony týkající se prezentace dat. Views mají na starosti poskytování dat webovému prohlíºe£i, nebo jinému nástroji, který zasílá va²í aplikaci poºadavky.
4.2.1.3 Controller Kontrolory fungují jako zprost°edkovatel mezi modely a views. V Rails slouºí kontrolory k zpracování poºadavk·, které p°icházejí z webového prohlíºe£e, získávání dat z model· a k odesílání t¥chto dat do views, kde budou zobrazeny. 4.2.2
DRY
DRY (Don't repeat yourself) [7] je princip vývoje softwaru zam¥°ený na sníºení opakování psaní stejného kódu, £ímº se zvy²uje £itelnost a znovupouºitelnost kódu. To znamená, ºe informace se nacházejí na jednozna£ném míst¥. Pro p°íklad Ruby on Rails získává de nici atribut· pro t°ídu modelu p°ímo z databáze. 4.2.3
CoC
CoC (Convention over Con guration) [6] je dal²í princip pouºívaný v Rails pro zlep²ení £itelnosti a znovupouºitelnosti kódu. Tento princip znamená, ºe konvence má p°ednost p°ed kon gurací a to tak, ºe Rails p°edpokládá to, co chcete ud¥lat místo toho, aby vás nutil speci kovat kaºdou drobnost v kon guraci. 4.2.4
REST
REST (Representational State Transfer) [13] je architektonický vzor pro webové aplikace. Je zaloºen na HTTP protokolu a hlavní my²lenkou je poskytovat p°ístup ke zdroj·m dat. V²echny zdroje jsou identi kovány p°es URI. REST de nuje £ty°i základní metody pro p°ístup ke zdroj·m. Jsou známé pod ozna£ením CRUD3 . Tyto metody jsou implementovány pomocí odpovídajících metod HTTP protokolu. Jednotlivé metody rozeberu na p°íkladech pro zdroj observations 4 . 3 4
create, retriece, update a delete zdroj aplikace pro práci s hospitacemi
18
KAPITOLA 4.
NÁVRH
Create
je poºadavek, který pomocí metody POST vytvo°í nový záznam. P°íklad pro vytvo°ení nové hospitace.
POST /observations
Retrieve
je poºadavek pro p°ístup ke zdroj·m. Funguje stejným zp·sobem jako b¥ºný poºadavek na stránku pomocí GET metody. První p°íklad vrátí seznam v²ech hospitací. Druhý p°íklad vrátí podrobnosti o konkrétní hospitaci.
GET /observations GET /observations/1
Update
je poºadavek, pro upravení konkrétního záznamu p°es metodu PUT.
PUT /observations/1
Delete
je poºadavek, který smaºe konkrétní záznam pomocí DELETE metody.
DELETE /observations/1
4.3 Struktura aplikace V této sekci popí²i základní strukturu aplikace. Struktura aplikace je vygenerovaná pomocí generátoru v Ruby on Rails. Proto nepopí²i celou strukturu, ale pouze £ásti aplikace, které jsou nejd·leºit¥j²í pro její vývoj. Na obrázku 4.1 je popsána struktura nejd·leºit¥j²ích sloºek a popis jejich obsahu.
4.3.
STRUKTURA APLIKACE
19
Hospitace/ app/ ........................................................ jádro MVC aplikace assets/ images/ ................................................. gra ka a obrázky javascripts/ ..................................... JavaScriptové knihovny stylesheets/ ............................................. kaskádové styly controllers/ .............................................controllers aplikace helpers/ ....................................... pomocné metody pro ²ablony inputs/ ..................... vytvo°ené vstupní pole pro knihovnu SimpleForm mailers/ ................................t°ídy které generují a odesílají emaily models/ ..................................................... modely aplikace views/ ...................................................... ²ablony aplikace lib/.............................................. knihovny a moduly pro aplikaci email_templates/ ...............................modul pro generování email· tasks/ ...........................................................rake scripty kosapi/ ....................................knihovna pro p°ipojení ke KOSapi will_paginate/ ......................... roz²í°ení pro knihovnu will_paginate public/ .............................. obsahuje statické soubory p°ístupné z webu config/ ........................................ kon gura£ní soubory a sm¥rování db/ ....................................... schéma databáze a databázové migrace test/ ........................ testy, testovací data a nástroje pro testování aplikace Obrázek 4.1: Struktura aplikace
20
KAPITOLA 4.
NÁVRH
Kapitola 5
Realizace Po dohod¥ s vedoucím práce byl zvolen itera£ní vývoj aplikace. Za ú£elem postupného vývoje £ástí aplikace, tak aby bylo moºné testovat aplikaci na letním semestru 2011/2012. V této kapitole popisuji jednotlivá zadání kaºdé iterace. Jak jsem postupoval k vy°e²ení zadání a výstupy z jednotlivých iterací. Jednotlivé iterace byly prezentovány na konzultacích s vedoucím práce.
5.1 První iterace 5.1.1
Zadání
Tato iterace pat°ila k nejobsáhlej²ím ze v²ech iterací. Jedním z d·vod· bylo seznámení se s novou technologii Ruby on Rails. První iterace m¥la za cíl navrhnout a vytvo°it základní architekturu aplikace s napojením na KOSapi viz. 4.1.2 a k tomu vytvo°it funk£ní £ást aplikace pro plánování hospitací tak, abych mohl prezentovat funk£nost.
5.1.2
Postup
5.1.2.1 Datová vrstva Protoºe aplikace vyuºívá dva datové zdroje KOSapi a databázi aplikace, bylo pot°eba nejd°ív vy°e²it jak se p°ipojit ke KOSapi. V této £ásti vycházím z prototypu aplikace pro správu hospitací. Ta vyuºívá jiº naprogramovanou knihovnu z projektu VyVy [17]. Poté bylo pot°eba vytvo°it modely tak, aby umoºnily komunikaci mezi KOSapi a databází aplikace. P°i implementování knihovny do aplikace jsem musel vy°e²it lokalizaci jazykových konstant v datech získaných z API. e²ení bylo jednoduché, sta£ilo roz²í°it knihovnu o podporu knihovny i18n1 , který je sou£ástí Rails. 1
lokalizace softwaru pro r·zné jazyky a jejich místních zvyklostí
21
22
KAPITOLA 5.
REALIZACE
5.1.2.2 Autentizace Pro autentizaci, v této fázi vývoje, pouºívám knihovnu Authlogic, kterou jsem zprovoznil pomocí návodu [3]. Tuto knihovnu pouºívám jen do£asn¥ po dobu vývoje aplikace. Ve nální fázi bude nahrazena autentiza£ní sluºbou FELid viz. 4.1.3, kterou lze zprovoznit jen na serveru, kde bude aplikace nasazena.
5.1.2.3 Autorizace Autentizace v hospitacích je jedna z kritických oblastí, kterou bylo pot°eba vy°e²it hned na za£átku vývoje. V aplikaci pot°ebuji autorizovat uºivatele jak podle role, tak i podle vztahu k hospitaci. Proto jsem hledal modul, který by dokázal nade novat pravidla autorizace. Knihovna, kterou jsem pouºil, se jmenuje CanCan [5] . Tato knihovna má velmi jednoduchý, ale i p°esto exibilní zápis pravidel. Tyto pravidla umí ltrovat jak podle zdroje, tak i podle jednotlivých instancí záznam·. Dokáºe také ltrovat metody v kontrolorech i celé zdroje aplikace. Ve²kerá pravidla jsou de nována na jednom míst¥2 aplikace. P°íklad zapsaného pravidla pro administrátora hospitací pomocí knihovny CanCan ve t°íd¥ modelu Ability. První pravidlo can umoºní zobrazovat, vytvá°et, upravovat a mazat ze zdroje Observation. Zárove¬ druhé pravidlo cannot zakáºe operace pro správu záznam·, které administrátor hospitací nevytvo°il.
def admin can :manage, Observation cannot :manage, Observation do |ob| !(ob.created_by==current_user) end end
5.1.2.4 Role Role pro jednotlivé uºivatele uchovávám v modelu Role, kde jednotlivé role uºivatele ukládám do jednoho atributu roles_mask pomocí bitové masky. V bitové masce jsou reprezentovány role £ísly mocniny 2. Díky tomu lze skládat role pomocí bitové operace OR. V tabulce 5.1 je p°ehled rolí s £íslem reprezentujícím bitovou masku pro roli.
Role
Administrátor hospitací Hospitující Hospitovaný Admin
Bitová maska 1 2 4 8
Tabulka 5.1: Reprezentace rolí v bitové masce
2
model Ability
5.2.
DRUHÁ ITERACE
23
5.1.2.5 Uºivatelské prost°edí Pro vytvo°ení uºivatelského prost°edí jsem pouºil jiº existující knihovnu Bootstrap [4]. Tuto knihovnu jsem pouºil z d·vodu usnadn¥ní implementace uºivatelského prost°edí. Knihovna obsahuje kompletní CSS tak i JavaScriptové moduly. Mezi dal²í výhody pat°í opensource licence a dal²í výhodou je známé uºivatelské prost°edí pouºívané ve webové aplikaci Twitter. Pro usnadn¥ní implementace knihovny Bootstrap do aplikace jsem pouºil dal²í dv¥ knihovny. První je modul SimpleForm [16], který slouºí k vytvá°ení formulá°·. Základním cílem je nade novat rozvrºení v²ech formulá°· na jednom míst¥. Druhým modulem je WillPaginate [19] pro stránkování dat. 5.1.3
Výstup
Výstupem z první iterace vznikla £ást aplikace, která um¥la plánovat hospitace a um¥la získávat data z webové sluºby KOSapi.
5.2 Druhá iterace 5.2.1
Zadání
Zadáním druhé iterace bylo naimplementovat hodnotící formulá°e hospitací. Poºadavkem byla moºnost upravovat formulá°e bez zásahu do zdrojového kódu aplikace. Dal²ím cílem byla pot°eba vy°e²it problém s KOSapi, který vznikl p°i p°echodu na nový semestr. Sluºba neudrºuje data instancí p°edm¥t· z minulých semestr·, proto nebylo moºné získat v²echny pot°ebné informace pro hospitace z t¥chto semestr·. 5.2.2
Postup
5.2.2.1 Datová vrstva Problém se ztrátou dat byl velmi váºný, proto bylo nutné tento problém rychle vy°e²it, abych mohl pokra£ovat dále ve vývoji. Musel jsem proto p°ed¥lat datovou £ást. Roz²í°il jsem databázi o entity z kapitoly 3.3 tak, aby data z KOSapi byla uloºena v databázi. Data je pot°eba synchronizovat v databázi s KOSapi. O synchronizaci se starají rake 3 scripty, které p°idávají nové záznamy, nebo je aktualizují. Synchroniza£ní scripty se spou²t¥jí kaºdý den pomocí programu Cron 4 . Po p°idání nových entit bylo pot°eba naimplementovat asociace mezi novými entitami. V modelu KOSapi je spousta asociací mezi entitami osoba - paralelka a osoba - instance p°edm¥tu. V aplikaci jich celkem pouºívám ²est. V²echny tyto asociace5 mají kardinalitu N:M. Pokud bych pouºil klasickou dekompozicí p°es pomocnou tabulku, která rozloºí asociace na 1:N a 1:M, vzniklo by mi ²est pomocných tabulek. Proto jsem se rozhodl pouºít jiný rake je sada nástroj· pouºívaná pro vývoj a nasazení Rails aplikací Cron je program, který na pozadí opera£ního systému spou²tí naplánované úlohy 5 asociace garant, p°edná²ející, vyu£ující, instruktor a zkou²ející. 3 4
24
KAPITOLA 5.
REALIZACE
zp·sob dekompozice p°es polymorfní asociace [11] v Ruby on Rails. Výhodou tohoto °e²ení je redukce po£tu pomocných tabulek. Polymorfní asociace zredukovala po£et z ²esti na jednu tabulku viz obrázek 5.1. V tabulce 5.2 jsou popsány jednotlivé atributy pomocné tabulky PeopleRelated s p°íklady hodnot.
Obrázek 5.1: Dekompozice pomocí polymorfní asociace
Atribut
P°íklad Popis
relation people_id
teachers 100
related_id related_type
1 Parallel
cizí klí£ záznamu, který je v asociaci s osobou jméno modelu ke kterému pat°í cizí klí£ v attributu related_id název asociace cizí klí£ pro osobu
Tabulka 5.2: Popis atribut· tabulky PeopleRelated
5.2.2.2 Hodnotící formulá°e Z d·vodu moºné zm¥ny hodnotících formulá°· v budoucnosti, jsem vytvo°il návrh, který umoºní vytvá°et nové typy formulá°·, nebo upravovat jiº existující. Formulá°e se de nují ²ablonou. Tato ²ablona de nuje základní vlastnosti: minimální, maximální po£et vypln¥ní, název a kdo m·ºe formulá° vyplnit. Samotný obsah ²ablony formulá°e se skládá z poloºek. Poloºkou formulá°e m·ºe být hodnotící tabulka, nadpis, hodnocení, text a jiné. Na obrázku 5.2 je doménový model dynamických formulá°·. Hodnotící formulá°e se generují podle ²ablony formulá°e získané z databáze. ablona je reprezentovaná modelem FormTemplate. Obsahuje ve²keré informace pot°ebné pro formulaci chování formulá°e. Mezi základní vlastnosti, které de nuje ²ablona, pat°í název, popis a kód. Kód ²ablony je velmi d·leºitá vlastnost, de nuje skupinu kam pat°í formulá°. Skupiny formulá°· jsou rozd¥leny podle druhu formulá°e a ty popisuji v sekci hodnocení výuky 2.3.2.5. Rozd¥lení formulá°· do skupin s kombinací data vytvo°ení vyuºívám pro verzování ²ablon. ablony musím verzovat, jinak by mi p°i úprav¥, nebo smazání existující ²ablony, mohla nastat ztráta dat z d°íve vypln¥ných formulá°·. ablona formulá°e de nuje také postupné hodnocení. Pro otev°ení dal²ího typu formulá°e se musí splnit n¥kolik podmínek:
5.2.
DRUHÁ ITERACE
25
Obrázek 5.2: Doménový model dynamických formulá°·
1. Povinný formulá° musí být vypln¥n a také musí splnit podmínku pro minimální po£et. V jiném p°ípad¥ není pot°eba vyplnit ºádný jiný formulá°. 2. Minimální po£et lze de novat bu¤ p°esným po£tem, nebo dynamicky podle asociace. Kde minimální po£et mi de nuje po£et instancí v asociaci. Po£et vytvo°ených formulá°· se po£ítá pouze z jednoho hodnocení hospitace. 3. Hospitující i hospitovaný m·ºe vyplnit maximáln¥ jeden formulá°. U dynamických formulá°· jsem musel také °e²it jejich chování pro r·zné role v systému. Proto jsem p°idal do ²ablony dva atributy s bitovými maskami rolí. Jedna maska je pro role, které mohou zobrazit formulá° a druhá maska je pro vypln¥ní formulá°e. Pouºívám stejný zp·sob rozli²ování rolí v bitové masce jako u rolí pro uºivatele viz 5.1.2.4. Obsah formulá°e generuji pomocí poloºek, ty jsou reprezentovány modelem EntryTemplate. Poloºky formulá°e de nují, co se má vykreslit a kde. Umíst¥ní jednotlivých poloºek v dokumentu je de nované ve stromové struktu°e, kde ko°enem stromu je ²ablona formulá°e a ta se postupn¥ v¥tví p°es instance modelu EntryTemplate. Co se má vykreslit je de nované atributem typ elementu. Na obrázku 5.3 je zobrazen p°íklad stromové struktury s typy element·. P°íloha C dokumentu obsahuje seznam v²ech podporovaných typ· element· a jejich vlastnosti v tabulce a obrázek se sestaveným formulá°em s rozloºením typ· element·. Samotné generování obsahu není sloºitý proces. Celý formulá° se sestaví hierarchicky i s hodnotami z modelu Entry. Nesta£í nám pouze vygenerovat formulá°, ale pot°ebujeme i uloºit jeho hodnoty do databáze. O to se starají modely Form a Entry. Model Form slouºí pro identi kaci konkrétního vypln¥ného formulá°e. Jednotlivé hodnoty z vypln¥ného formulá°e jsou uloºeny v Entry viz obrázek 5.4.
26
KAPITOLA 5.
REALIZACE
FormTemplate
EntryTemplate (text)
EntryTemplate (ranking_table) EntryTemplate (ranking)
EntryTemplate (label)
EntryTemplate (ranking)
Obrázek 5.3: P°íklad stromové struktury formulá°e Form Entry (A)
Entry (B)
Entry (text)
Obrázek 5.4: P°íklad uloºených dat 5.2.3
Výstup
Výstupem této iterace byla aplikace, která jiº vyuºívala pouze svoji databázi pro zdroj dat z KOSu a dynamické formulá°e s nade novanými ²ablonami formulá°·.
5.3 T°etí iterace 5.3.1
Zadání
Zadáním t°etí iterace bylo p°ipravit server pro sluºbu FELid. Dal²ím poºadavkem bylo zprovozn¥ní automatického zálohování databáze. 5.3.2
Postup
5.3.2.1 Nasazení aplikace Na diagramu nasazení 5.5 jsou znázorn¥ny komponenty pot°ebné pro nasazení aplikace. Protoºe na serveru byl nainstalován pouze webový server Apache HTTP Server a databázový systém Mysql, bylo nutné nainstalovat platformu Ruby a framework Ruby on Rail. K instalaci Ruby jsem se rozhodl pouºít software RVM. Instalaci jsem provedl podle návodu pro víceuºivatelskou instalaci [1]. Tento program dovolí nainstalovat r·zné platformy Ruby na jednom po£íta£i. Dal²ím p°ínosem je spravování gemsets6 , díky nimº lze zprovoznit n¥kolik aplikací soub¥ºn¥ na jednom po£íta£i. Do nainstalovaného webového serveru bylo pot°eba 6
balíky knihoven mezi kterými lze p°epínat pro r·zné aplikace
5.3.
27
TETÍ ITERACE
je²t¥ p°idat zásuvný modul, který umoºní nasadit Rails aplikace. Modul se jmenuje Passanger (mod_rails) a instaloval jsem ho do Apache podle návodu na o ciálních stránkách [27].
5.3.2.2 FELid Pro zprovozn¥ní sluºby FELid, bylo pot°eba splnit n¥kolik poºadavk·. Tyto poºadavky jsou umíst¥ny na o ciálních stránkách sluºby [10]. Jeden z nich vyºaduje zprovozn¥ní programu, který zajistí komunikaci se sluºbou FELid. Tento program se jmenuje Shibboleth a obsahuje zásuvný modul mod_shib do webového serveru. P°i kon guraci programu jsem postupoval podle návodu, který se nachází na wiki stránkách FELid [9]. Po spln¥ní v²ech poºadavk· sta£ilo jen zaºádat o registraci aplikace.
Obrázek 5.5: Diagram nasazení
5.3.2.3 Zálohování databáze Pro automatické zálohování databáze jsem pouºil existující °e²ení Ruby aplikace Backup pro zálohování databází. Tato aplikace kaºdý den vytvo°í zálohu databáze, kterou uloºí na disk. Na disku uchovává 300 záloh databáze. P°i p°ekro£ení po£tu záloh se star²í zálohy nahrazují novými. Výhodou tohoto °e²ení je podpora r·zných databázových systém· a moºnost ukládat zálohy na externí uloºi²t¥7 . Záloha se spou²tí pravideln¥ pomocí programu Cron kaºdý den brzy ráno p°íkazem:
backup perform --trigger backup 7
pro p°íklad Amazon Simple Storage Service (S3)
28
KAPITOLA 5.
5.3.3
REALIZACE
Výstup
V této iteraci se mi poda°ilo zprovoznit aplikaci na serveru a otestovat její funk£nost. Také jsem pracoval na programu, který jsem upravoval podle p°ipomínek získaných od zadavatele z minulých iterací.
5.4 tvrtá iterace 5.4.1
Zadání
Tato iterace je poslední, proto v¥t²inu zadání tvo°ily p°ipomínky od zadavatele. V této iteraci pat°í mezi hlavní úkoly vytvo°ení modulu, který bude generovat emailové zprávy po vypln¥ní hodnotícího formulá°e a integrovat autentizaci p°es FELid. 5.4.2
Postup
5.4.2.1 Autentizace V této fázi vývoje byla aplikace zaregistrována ve FELid. P°ed integrováním autentizace p°es FELid, je pot°eba otestovat aplikaci. Nejd·leºit¥j²í je otestovat správnou funk£nost autorizace u v²ech rolí v celém systému. Po zprovozn¥ní autentizace p°es FELid není moºné jednodu²e testovat aplikaci pod r·znými uºivateli. Od zprovozn¥ní nebudu mít totiº kontrolu nad autentizací. Integrace do aplikace je pak velmi jednoduchá. Sta£í jen odstranit do£asný zp·sob autentizace, který jsem implementoval v první iteraci. Aplikace FElid poskytuje aplikaci informace o p°ihlá²eném uºivateli prost°ednictvím atribut· v prom¥nné request.env. Pro identi kaci p°ihlá²eného uºivatele pouºívám atribut felid-uid, ve kterém se nachází uºivatelské jméno. O autentizaci v aplikaci se stará jen jedna funkce current_user_session.
def current_user_session return @user if defined?(@user) if not request.local? and not request.env["felid-uid"].nil? and @user.nil? then @user = People.find_by_username request.env["felid-uid"] end return @user end
5.4.2.2 Emaily Jedením z poºadavk· bylo odesílání emailových zpráv po vypln¥ní hodnotícího formulá°e. Sou£ástí zadání je generování email· ze ²ablon. ablona se skládá z p°edm¥tu, textu zprávy a názvu akce. Akce v systému mohou být r·zných druh·. Na základ¥ zadání sta£ilo pouze implementovat akce pro vytvo°ení formulá°·. P°i vykonání akce se vygeneruje emailová zpráva ze ²ablony emailu.
5.4.
TVRTÁ ITERACE
29
5.4.2.3 Generátor obsahu emailových zpráv Protoºe je pot°eba generovat do emailu prom¥nná data z hospitací, musel jsem vytvo°it knihovnu EmailTemplates pro generování obsahu email·. Úkolem modulu je nahradit zna£ky v textu za skute£ná data. Pro vloºení generovaných dat se pouºívá zápis %zna£ka% do textu zprávy. P°íklad vygenerování jednoduchého emailu se zna£kou pro kód p°edm¥tu.
text %course_code% => text A7B36ASS P°i vývoji modulu jsem si dal za cíl vytvo°it takovou knihovnu, která by umoºnila jednodu²e nastavit podporované zna£ky. Nejv¥t²ím zádrhelem v generování obsahu zprávy je získání dat z hospitací. Protoºe pro vstup do generátoru pouºívám pouze instanci ²ablony a hodnocení hospitace, musím tak n¥která data získat p°es n¥kolik relací mezi modely. Knihovna obsahuje dva moduly. První £ástí je modul ModelHelper, který slouºí pro roz²í°ení libovolné t°ídy modelu v aplikaci. Roz²í°enému modelu umoºní pomocí statické metody attrs_tagged(*args) povolit atributy, ze kterých bude generátor získávat data. P°íklad jednoduchého nastavení modelu Person, které umoºní generátoru vkládat jméno, emailovou adresu a uºivatelské jméno.
class Person < ActiveRecord::Base include EmailTemplates::Tagged::ModelHelpers attrs_tagged :name, :email, :username end Druhou £ástí je modul EmailBuilder. Tento modul slouºí pro vytvo°ení vlastního generátoru pomocí jednoduchého nastavování. Pro tyto ú£ely modul poskytuje statickou metodu source(model,name,*path), ta slouºí pro nastavení zdroje dat. Metoda dynamicky roz²í°í t°ídu o metodu, která dokáºe získat data z aplikace. Vyuºívá k tomu nastavení z modelu roz²í°eného pomocí ModelHelper a cesty k instancím modelu s daty. Cesta je de nována posloupností názv· asociací mezi modely. P°íklad implementace jednoduchého generátoru EmailBuilder, který dokáºe vkládat do email· informace o hospitovaném u£iteli.
class EmailBuilder include Tagged::EmailBuilder source Person, :teacher, :evaluation, :teacher end Tento generátor bude podporovat t°i zna£ky %teacher_name%, %teacher_email% a %teacher_username%. Tímto zp·sobem lze jednodu²e nade novat velké mnoºství zna£ek.
30
KAPITOLA 5.
REALIZACE
%teacher_name% teacher
name
(zdroj)
(atribut)
Obrázek 5.6: Struktura zna£ky Struktura zna£ky 5.6 se skládá ze dvou základních £ástí, ze jména zdroje a jména atributu, ze kterého generátor získá data pro nahrazení zna£ky. Výhodou této knihovny je krátký a jednoduchý zápis pro vytvo°ení vlastního generátoru, který dokáºe p°es asociace mezi modely získávat data. V aplikaci jsem celkem nade noval pro dev¥t zdroj· 32 zna£ek.
5.4.2.4 Odesílání email· Dle zadání sta£ilo implementovat odesílání zpráv po vytvo°ení hodnotícího formulá°e. Podle druhu hodnotícího formulá°e se vygeneruje zpráva a ode²le se administrátorovi hospitace, hospitujícím, hospitovaným, garantovi p°edm¥tu a vedoucímu katedry. Do budoucna lze roz²í°it v aplikaci odesílání email· i p°i jiných akcích. Nap°íklad se mohou odesílat p°i naplánování nové hospitace. Emailový server pro odesílání email· se mi z £asových d·vod· a také pro technické problémy nepoda°ilo zprovoznit, proto do£asn¥ pouºívám emailový ú£et kvalitavyuky.gmail.com na Gmail. 5.4.3
Výstup
Výstupem z této iterace je nální aplikace, která spl¬uje v²echny hlavní poºadavky na funk£nost.
Kapitola 6
Testování Cílem testování bylo otestovat reálnou funk£nost aplikace a odhalit chyby p°i návrhu a vývoji aplikace. Aplikaci jsem testoval dv¥ma zp·soby: manuáln¥, kde jsem musel ru£n¥ procházet aplikaci a zkou²et její funk£nost, a automaticky pomocí testovacích nástroj· v Ruby on Rails. Aplikaci jsem testoval v pr·b¥hu celého vývoje.
6.1 Automatické testování Pro automatické testování jsem pouºil testovací nástroje v Ruby on Rails [2]. V Rails se testy d¥lí do t°í kategorii: Unit, Functional a Integration. Jednotlivé kategorie test·, které jsem pouºil, popí²i dále v textu. Testy jsem tvo°il jen na kritických £ástech aplikace, kde byla velká pravd¥podobnost vzniku chyb p°i úpravách funkcionality a návrhu aplikace. 6.1.1
Testovací data
Testovací nástroje pot°ebují pro svou funk£nost testovací data. Tyto data se nacházejí ve struktu°e programu ve sloºce tests/ xtures. Zde jsou soubory s testovacími daty pro jednotlivé modely. Data jsou uloºená ve formátu YAML1 . P°ed spu²t¥ním test· se tato data nahrají do testovací databáze. V mém p°ípad¥ je to lokální databáze SQLite. Díky odd¥lené databázi nemá testování vliv na produk£ní databázi. 6.1.2
Unit testing
Unit testy slouºí k testování samostatných £ástí program·. V Rails se tyto testy pouºívají hlavn¥ pro testování funk£nosti model·. Testuje se hlavn¥ validace vstup· a perzistence dat. Tyto testy mi odhalily spoustu chyb, které vznikly p°i úpravách entit v aplikaci. 6.1.3
Functional tests
Tyto testy testují r·zné £innosti v jednotlivých controllerech aplikace. Controllery zpracovávají p°íchozí webové poºadavky a nakonec odpov¥dí vyrendrovanou ²ablonou [2]. 1
YAML je formát pro serializaci strukturovaných dat
31
32
KAPITOLA 6.
TESTOVÁNÍ
Tento typ test· testuje: • Byl webový poºadavek úsp¥²ný? • Byli jsme p°esm¥rováni na správnou stránku? • Byli jsme úsp¥²n¥ p°ihlá²eni? • Byl objekt vloºen do správné ²ablony? • Byla zobrazena správná hlá²ka uºivateli?
6.2 Manuální testování Manuáln¥ jsem testoval ty £ásti aplikace, u kterých se ²patn¥ vytvá°ejí testy, nebo bylo pot°eba pouºít lidský úsudek. Tyto vlastnosti spl¬uje testování uºivatelského rozhraní a testování autorizace. Nejrozsáhlej²í testování bylo vºdy p°ed koncem kaºdé iterace. D·vodem bylo rozsáhlé testování reálné funk£nosti aplikace. Více v kapitole 6.3.
6.3 Systémové testování Systémové testy jsou hlavní a nejd·leºit¥j²í sou£ástí testování. Smyslem tohoto testování je ov¥°it funk£nost aplikace a zjistit, zda byly pokryty v²echny poºadavky dané zadavatelem. Nej£ast¥ji tyto testy bývají provád¥ny p°ed nasazením do reálného provozu. Tento druh test· jsem provád¥l vºdy p°ed koncem kaºdé iterace, neº jsem prezentoval sv·j postup. Uji²´oval jsem se o stavu nové verze, zda není rozbitá a také jsem tím získal zp¥tnou vazbu o postupu vývoje. P°i systémovém testování aplikace jsem netestoval v²echny funkce aplikace, ale pouze ty nejd·leºit¥j²í. Jsou to scéná°e, které simulují b¥ºnou práci uºivatele. P°i testování funk£nosti jsem simuloval pr·b¥h hospitací pomocí reálných dat získaných z probíhajících hospitací v letním semestru 2011/2012. V p°íloze dokumentu D jsou popsány jednotlivé testovací p°ípady pro systémové testování. Výsledky t¥chto test· jsou znázorn¥ny v tabulce 6.1. V jednotlivých iteracích je znázorn¥no, zda aplikace testem pro²la. Lze z ní také vy£íst i postupný vývoj aplikace. V poslední iteraci byly spln¥ny v²echny systémové testy, proto bylo moºné aplikaci nasadit.
6.3.
33
SYSTÉMOVÉ TESTOVÁNÍ
ID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Test
P°ihlásit se Odhlásit se Seznam hospitací Seznam hodnocení Záv¥re£né hodnocení Seznam hospituji Zahájit hodnocení Formulá° A Nahrát p°ílohu Formulá° B Formulá° C Formulá° D Odesílání email· Seznam hospitován Vytvo°it hospitaci P°i°adit hospitujícího Naplánovat hospitaci Napsat poznámku P°i°adit roli
1. iterace 2. iterace 3. iterace 4. iterace X
X
X
X X X
X X X X
X X X
X X X X X X X X X X
X X X X X
X X X X X X
X X X X X X X X X X X X X X X X X X X
Tabulka 6.1: Výsledky systémového testování
Struktura tabulky 6.1: ID Test
Identi kátor testovacího p°ípadu, ten lze podle ID dohledat v p°íloze dokumentu D. Hlavní cíl testu.
Iterace
Obsahuje výsledky, zda byl test spln¥n v jednotlivých iterací.
34
KAPITOLA 6.
TESTOVÁNÍ
Kapitola 7
Záv¥r 7.1 Zhodnocení spln¥ní cíl· Cílem bakalá°ské práce bylo vytvo°it webovou aplikaci pro evidenci hospitací, která by navazovala na jiº d°íve vytvo°ený av²ak nefunk£ní prototyp. Musí být vytvo°ena a dolad¥na tak, aby ji ²lo pouºít v reálném provozu na VUT Fakult¥ elektrotechnické. Hlavním ú£elem vytvo°ení této aplikace byla snaha o sníºení administrativní zát¥ºe p°i správ¥ hospitací. Aplikace má usnadnit práci p°i neustále se zvy²ujícím po£tu hospitací. Poda°ilo se mi vytvo°it aplikaci, která slouºí k tomuto ú£elu a je implementována na platform¥ Ruby on Rails, coº je jeden z nejmodern¥j²ích framework· pro vývoj webových aplikací. Pro nasazení aplikace do reálného provozu pouºívám dv¥ fakultní aplikace. Pro autentizaci je pouºita aplikace FELid, coº je globální autentiza£ní systém pro webové aplikace FEL. Druhou aplikací je KOSapi, ta poskytuje aplika£ní rozhraní k p°ístupu dat v KOSu. Sou£ástí práce bylo i vytvo°ení dvou rozsáhlých £ástí aplikace. V první £ásti jsou dynamické formulá°e, které umoº¬ují vytvá°et formulá°e s moºností editace struktury. V druhé £ásti aplikace je knihovna, která umoº¬uje generovat obsah informa£ních email·. K vygenerování obsahu jsou vyuºívány ²ablony a získaná data z hospitací. Výsledná aplikace je nasazena na serveru http://kvalitavyuky.felk.cvut.cz a p°ipravena k pouºití v reálném provozu.
7.2 Osobní p°ínos P°i °e²ení této práce jsem získal spoustu v¥domostí a zku²eností, protoºe obsah práce byl obsáhlý a rozmanitý. Práce zahrnovala implementaci aplikace a její nasazení v£etn¥ instalace a nastavení serveru. Nejv¥t²ím p°ínosem pro mne je poznání nového a zajímavého programovacího jazyka Ruby a moderního frameworku Ruby on Rails. P°i tvorb¥ jsem narazil i na problémy s externími aplikacemi, které jsem musel °e²it, coº m¥ p°im¥lo hloub¥ji se touto problematikou zabývat.
7.3 Moºnosti pokra£ování Moºností pokra£ování v práci je n¥kolik. Vhodné by bylo vy°e²it provizorní odesílání informa£ních emailových zpráv nainstalováním a nastavením emailového serveru. 35
36
KAPITOLA 7.
ZÁV
R
Lze také pokra£ovat ve vývoji dynamických formulá°·. Jelikoº jsem neimplementoval uºivatelské prost°edí pro jejich nastavování, je moºné p°ed¥lat jádro t¥chto formulá°· do samostatné knihovny. V budoucnu bude ú£elné roz²í°it aplikaci o podporu nové verze KOSapi, která je momentáln¥ ve vývoji. Tato nová verze jiº bude obsahovat data z Bílé knihy1 a tudíº bude moºné aplikaci roz²í°it o podporu studijních program· i s obory.
1
je to dokument, který obsahuje informace o organizací studijních plán·
Literatura [1] Installing RVM [online]. [cit. 2012-04-07]. install/>.
Dostupné z:
[2] A Guide to Testing Rails Applications [online]. [cit. 2012-05-17]. Dostupné z:
. [3] Authlogic: documentation [online]. [cit. 2012-04-07]. Dostupné z: . [4] Bootstrap, from Twitter [online]. 2012-04-07. Dostupné z: . [5] CanCan: Getting Started [online]. 2012. Dostupné z: . [6] Convention over con guration. In: Wikipedia: the free encyclopedia [online]. St. Petersburg (Florida): Wikipedia Foundation, 20.9.2007, last modi ed on 10.12.2011. [cit. 2012-03-05]. Dostupné z: . [7] Don't repeat yourself. In: Wikipedia: the free encyclopedia [online]. St. Petersburg (Florida): Wikipedia Foundation, 1.12.2005, last modi ed on 9.2.2012. [cit. 2012-03-05]. Dostupné z: . [8] Analíza aplikace v programu Enterprise Architect. [CD]. Dostupné z: <EA/hospitace. ear>. [9] O systému FELid [online]. [cit. 2012-02-15]. Dostupné z: . [10] Poºadavky FELid [online]. 2012-02-15. Dostupné z: . [11] A Guide to Active Record Associations [online]. [cit. 2012-04-07]. Dostupné z: . [12] Modelviewcontroller. In: Wikipedia: the free encyclopedia [online]. St. Petersburg (Florida): Wikipedia Foundation, 5.11.2003, last modi ed on 5.4.2012. [cit. 2012-04-06]. Dostupné z: . 37
38
LITERATURA
[13] Representational state transfer. In: Wikipedia: the free encyclopedia [online]. St. Petersburg (Florida): Wikipedia Foundation, 17.8.2004, last modi ed on 3.4.2011. [cit. 201203-05]. Dostupné z: . [14] Ruby [online]. Dostupné z: . [15] Ruby on Rails [online]. [cit. 2011-12-15]. Dostupné z: . [16] SimpleForm: Rails forms made easy [online]. [cit. 2012-04-07]. Dostupné z: . [17] Aplikace Vykazování výuky [online]. 2012. Dostupné z: . [18] Stránky projektu VyVy [online]. 2012. vykazovani-vyuky-cvut/>.
Dostupné z:
[19] Will_paginate: documentation [online]. 2012-04-07. Dostupné z: . [20] ORACLE CORPORATION. MySQL 5.5 [software]. Dostupné z: . [21] APACHE SOFTWARE FOUNDATION. Apache HTTP server 2.4 [software]. [p°ístup 2012-04-07]. Dostupné z: . [22] D. RICHARD HIPP. download.html>.
SQLite [software].
Dostupné z:
[23] HLAVÁC, V. KOSTLIVÁ, J. Postupy pro kontrolu kvality výuky: nejen pro studijní program STM. verze 04. 19. listopadu 2010. Dostupné z: . [24] INTERNET2. Shibboleth SP 2.4 [software]. internet2.edu/downloads.html>.
Dostupné z:
[25] KOMÁREK, M. Kontrola kvality výuky [online]. [cit. 2012-01-17]. Dostupné z: . [26] KRELOK, D. Návrh a implementace systému pro správu hospitací. Bakalá°ská práce, eské vysoké u£ení technické v Praze, Fakulta elektrotechnická, Praha, 2010. [27] PHUSION. Passenger [software]. Dostupné z: .
P°íloha A
Seznam pouºitých zkratek API
Application Programming Interface
CoC
Convention over Con guration
CRUD CSS
Create Retriece Update Delete
Cascading Style Sheets
VUT DRY
eské vysoké u£ení technické v Praze
Don't repeat yourself
FEL
Fakulta elektrotechnická
i18n
Internationalization and localization
KOS
Komponenta studium
LS
Letní semestr
MVC
Model-view-controller
HTML
HyperText Markup Language
REST
Representational State Transfer
RVM
Ruby Version Manager
SAML STM URI
Security Assertion Markup Language
Softwarové technologie a management Uniform Resource Identi er
VyVy
Vykazování Výuky
WWW
WorldWideWeb
YAML
Ain't Markup Language
39
40
PÍLOHA A.
SEZNAM POUITÝCH ZKRATEK
P°íloha B
UML diagramy a obrázky
B.1 Use cases
Obrázek B.1: Use case - nep°ihlá²ený uºivatel
41
42
PÍLOHA B.
UML DIAGRAMY A OBRÁZKY
Obrázek B.2: Use case - p°ihlá²ený uºivatel
Obrázek B.3: Use case - hospitovaný
B.1.
43
USE CASES
Obrázek B.4: Use case - hospitující
Obrázek B.5: Use case - administrátor
44
PÍLOHA B.
UML DIAGRAMY A OBRÁZKY
Obrázek B.6: Use case - administrátor hospitací
P°íloha C
Dynamické formulá°e
Typ
label integer text text/ le
Návratová hodnota Popis £íslo text text
ranking_table column_table ranking ranking_scale note
[A,B,C,D,E,F]
text
textový popisek vstupní element pro £ísla formulá° pro psaní text· formulá° pro psaní text· s moºností nahrání souboru s naskenovaným formulá°em tabulka pro hodnocení, m·ºe obsahovat n¥kolik element· typu ranking tabulka do které se vkládají jiné elementy po sloupcích vstupní element pro zadávání známek od A do F tabulka s hodnotící stupnicí vstupní element pro zápis textové poznámky
Tabulka C.1: Seznam podporovaných typ· element·
45
46
PÍLOHA C.
DYNAMICKÉ FORMULÁE
Obrázek C.1: Hodnotící formulá° A
P°íloha D
Test Cases Test Case ID:
1
Co: P°ihlá²ení uºivatele do systému. Role: Nep°ihlá²ený uºivatel Poºadavky: Musí být zprovozn¥na sluºba FELid. O£ekávaný výsledek: Uºivatel je p°ihlá²ený. Test Case ID:
2
Co: Odhlá²ení uºivatele ze systému. Role: P°ihlá²ený uºivatel Poºadavky: Musí být zprovozn¥na sluºba FELid. O£ekávaný výsledek: Uºivatel není p°ihlá²ený. Test Case ID:
3
Co: Seznam naplánovaných hospitací. Role: V²echny O£ekávaný výsledek: Zobrazil se seznam naplánovaných hospitací a obsahuje v²echny hospitace typu ohlá²ená a plovoucí.
Test Case ID:
4
Co: Seznam hodnocení s ltrováním dle: p°edm¥tu, u£itele, garanta a semestru. Role: V²echny Poºadavky: Existují hodnocené hospitace. O£ekávaný výsledek: Zobrazil se seznam a lze v n¥m ltrovat záznamy. Test Case ID: Co:
5
P°ístup k formulá°i Záv¥re£né hodnocení hospitace. 47
48
PÍLOHA D.
TEST CASES
Role: V²echny Poºadavky: Existuje ukon£ená hospitace. O£ekávaný výsledek: Zobrazil se formulá°. Test Case ID:
6
Co: Seznam hospituji. Role: Hospitující O£ekávaný výsledek:
Zobrazil se seznam a jsou v n¥m v²echny hospitace, které uºivatel hospituje v daném semestru.
Test Case ID:
7
Co: Zahájení hodnocení hospitace. Role: Hospitující a administrátor hospitací Poºadavky: Naplánovaná hospitace O£ekávaný výsledek: Bylo úsp¥²n¥ zahájeno hodnocení. Test Case ID:
8
Co: Vyplnit hodnotící formulá° A Role: Hospitující Poºadavky: Zahájené hodnocení hospitace O£ekávaný výsledek: Hodnotící formulá° byl úsp¥²n¥ uloºen. Test Case ID:
9
Co: Nahrát p°ílohu k hodnotícímu formulá°i A Role: Hospitující Poºadavky: Vypln¥ný formulá° A O£ekávaný výsledek: P°íloha je uloºená a lze ji stáhnout. Test Case ID:
10
Co: Vyplnit hodnotící formulá° B Role: Hospitující Poºadavky: Zahájené hodnocení hospitace, vypln¥né v²echny formulá°e A O£ekávaný výsledek: Hodnotící formulá° byl úsp¥²n¥ uloºen. Test Case ID:
11
Co: Vyplnit hodnotící formulá° C Role: Hospitovaný
49
Poºadavky: Zahájené hodnocení hospitace, vypln¥ný formulá° B O£ekávaný výsledek: Hodnotící formulá° byl úsp¥²n¥ uloºen. Test Case ID:
12
Co: Vyplnit hodnotící formulá° D Role: Hospitující Poºadavky: Zahájené hodnocení hospitace, vypln¥ný formulá° B O£ekávaný výsledek: Hodnotící formulá° byl úsp¥²n¥ uloºen a hospitace je ve stavu ukon£ená.
Test Case ID:
13
Co: Odesílání email· po uloºení hodnotícího formulá°e. Role: Systém Poºadavky: Existuje emailová ²ablona pro druh hodnotícího formulá°e. O£ekávaný výsledek: Email byl správn¥ sestavený a doru£ený do emailové schránky. Test Case ID:
14
Co: Seznam hospitován. Role: Hospitovaný O£ekávaný výsledek: V seznamu jsou v²echny hospitace, které mají zahájené hodnocení a uºivatel je s nimi ve vztahu hospitovaný.
Test Case ID:
15
Co: Vytvo°it hospitaci Role: Administrátor hospitací O£ekávaný výsledek: Hospitace byla uloºena. Test Case ID:
16
Co: P°i°adit hospitujícího k hospitaci Role: Administrátor hospitací Poºadavky: Existuje vytvo°ená hospitace, kterou uºivatel spravuje. O£ekávaný výsledek: K hospitaci byl úsp¥²n¥ p°i°azen hospitující. Test Case ID:
17
Co: Naplánovat hospitaci Role: Administrátor hospitací Poºadavky: Existuje vytvo°ená hospitace, kterou uºivatel spravuje.
50
PÍLOHA D.
O£ekávaný výsledek: Test Case ID:
Hospitace je ve stavu naplánovaná.
18
Co: Napsat poznámku k hospitaci Role: Administrátor hospitací Poºadavky: Existuje vytvo°ená hospitace, kterou uºivatel spravuje. O£ekávaný výsledek: Poznámka byla vytvo°ena a lze ji zobrazit. Test Case ID:
19
Co: P°i°adit roli osob¥ Role: Administrátor O£ekávaný výsledek:
Osob¥ byla úsp¥²n¥ p°i°azena role.
TEST CASES
P°íloha E
Instala£ní a uºivatelská p°íru£ka Instala£ní p°íru£ka je napsaná pro zprovozn¥ní aplikace v prost°edí development. Návod je ur£ený pro opera£ní systém Ubuntu 11.10. Pro zprovozn¥ní aplikace musíme nainstalovat tyto programy:
• Ruby 1.9.3 • RubyGems 1.8.13 • Ruby on Rail 3.2.1 • Databázový systém Mysql 5.5 nebo SQLite 3 • Git
E.1 Instalace Nejprve je pot°eba nainstalovat platformu Ruby do systému. S ruby nainstalujte i balík build-essential a git-core kv·li knihovnám, které jsou pot°eba pro zprovozn¥ní aplikace.
sudo apt-get install ruby1.9.3-full build-essential git-core Dále nainstalujte balí£kovací systém RubyGems a aktualizujte ho na poslední podporovanou verzi.
sudo apt-get install rubygems1.8 sudo gem update --system V poslední fázi je pot°eba nainstalovat Ruby on Rails pomocí balí£kovacího programu rubygems.
sudo gem install rails 51
52
PÍLOHA E.
INSTALANÍ A UIVATELSKÁ PÍRUKA
Po nainstalování Ruby on Rails je pot°eba doinstalovat v²ech závislosti aplikace. Nejprve musíme n¥kam do systému zkopírovat aplikaci nap°. do domovského adresá°e. Ve v²ech dal²ích krocích se budeme pohybovat v adresá°i aplikace. Druhý p°íkaz slouºí k instalaci závislostí aplikace.
cd ~/Hospitace bundle install
E.2 Kon gurace a p°íprava aplikace P°ed spu²t¥ním aplikace je d·leºité nastavit p°ístupové údaje k databázi. Nastavení databáze se nachází v souboru con g/database.yml, který se nalézá v aplikaci. Pro zavedení databáze pak sta£í jen spustit p°íkazy:
rake db:create rake db:migrate Máme vytvo°enu databázi, je nutné ji naplnit naplnit daty z KOSapi. Pro tento ú£el slouºí p°íkaz:
rake import
E.3 Spu²t¥ní aplikace Pro spu²t¥ní aplikace pouºijte webový server Webrick, který je sou£ástí Ruby on Rails. Po spu²t¥ní bude aplikace b¥ºet na portu 3000. P°íkaz pro spu²t¥ní:
rails server
P°íloha F
Obsah p°iloºeného CD /
EA/ hospitace.ear................analýza aplikace v programu Enterprise Architect prototyp/...................................................... prototyp aplikace src/..................................................zdrojové kódy prototypu BP.pdf.........................................text prototypu ve formátu PDF src/.......................................................zdrojové kódy aplikace text/ thesis.pdf ........................................ text práce ve formátu PDF thesis/ ................................... zdrojová forma práce ve formátu LATEX figures/............................................... obrázky pro text práce readme.txt ............................................. stru£ný popis obsahu CD Obrázek F.1: Obsah CD
53
