univerza v ljubljani pedago ka fakultetapefprints.pef.uni-lj.si/4216/1/diploma-juresimon.pdf ·...
TRANSCRIPT
UNIVERZA V LJUBLJANI
PEDAGO�KA FAKULTETA
DIPLOMSKO DELO
SIMON JURE
UNIVERZA V LJUBLJANI
PEDAGO�KA FAKULTETA
�tudijski program: Matematika in ra£unalni²tvo
Izdelava aplikacije za preverjanje
znanja in organizacijo prakti£nega
pedago²kega usposabljanja
DIPLOMSKO DELO
Mentor: dr. Joºe Rugelj Kandidat: Jure Simon
Ljubljana, avgust 2016
Zahvaljujem se mentorju dr. Joºetu Ruglju za pomo£ in nasvete pri izdelavi
diplomskega dela.
Zahvaljujem se tudi dr. Zlatanu Magajni za idejo za izdelavo aplikacije ter pomo£
in usmerjanje pri izdelavi njene zasnove.
Posebna zahvala gre tudi moji druºini, ºeni Aniti ter h£erkama Klari in Evi, ki
so me podpirale v £asu ²tudija in v zadnjih mesecih pisanja diplomske naloge.
Povzetek
V diplomskem delu je predstavljen potek razvoja spletne aplikacije, ki bo namenjena
preverjanju znanja in organizaciji pedago²kega usposabljanja. V prvem delu je pred-
stavljen postopek na£rtovanja aplikacije z opisom ºivljenjskega cikla razvoja sistema
in njegovimi razvojnimi fazami ter opisom posameznih najpogostej²ih razvojnih me-
todologij. Predstavljena je tudi izbrana metoda razvoja z obrazloºitvijo.
V osrednjem delu je predstavljena zasnova aplikacije s popisom uporabni²kih skupin
aplikacije in vseh ºelenih funkcionalnosti. Vsaka funkcionalnost je nato ²e dodatno
opredeljena.
V zadnjem delu je predstavljen potek razvoja in izdelave spletne aplikacije. Tu so
opisana vsa orodja, ki sem jih uporabil pri razvoju, predstavljeni so podatkovni model
aplikacije z opisom vseh entitet, datote£na struktura aplikacije ter popis vseh zaslon-
skih slik. Vsaka zaslonska slika poleg gra�£nega prina²a ²e opise vseh funkcionalnosti,
ki jih omogo£a, navigacijo med zasloni ter opise funkcij, metod in datotek, ki spadajo
zraven.
V zaklju£ku so predstavljeni vzdrºevanje aplikacije, hramba razvojne kode za poznej²o
uporabo in nadgrajevanje in evalvacija spletne aplikacije. Tu so opisana tudi orodja,
ki zagotavljajo organizacijo in zgodovino razvojne kode. V evalvaciji so predstavljena
mnenja o spletni aplikaciji in moºne raz²iritve in dopolnitve.
Klju£ne besede:
ºivljenjski cikel razvoja sistema, razvojni modeli, razvojne metodologije, spletna apli-
kacija za preverjanje znanja, organizacija PPU, hospitacija, u£na priprava
Abstract
This diploma thesis describes a course of development of web application, which will
be used for examination and organization of practical pedagogical training. In the
�rst part of the thesis, the planning process is presented and the system development
lifecycle and its development phases are described. Thesis also describes the most
common development methodologies and presents the selected method of develop-
ment and its justi�cation.
The central part of the thesis presents the design of applications with the list of
application user groups and the list of all the desired functionalities. Each functiona-
lity is then further de�ned.
The last part of the thesis, the course of the development of web application is pre-
sented. All the tools that have been used in the development are described, the data
model with the description of its entities, the �le structure of the application and the
list of all application screens are presented. In addition to the graphic representation
each screen contains the description of all functionalies, navigation between screens
and descriptions of the functions, methods, and �les that are connected with them.
The conclusion of thesis presents the maintenance aspects of the development, pre-
servation of code for later use and upgrading and evaluation of our web application.
Here are descriptions of tools that provide the organization and history of the develo-
ped code. In the evaluation user opinions and possible extensions and modi�cations
of our web application are presented.
Keywords:
system development life cycle, development models, development methodologies, web-
based application for the examination, organization practical pedagogical training,
attendance at lectures, teaching preparation
Kazalo
Uvod 1
1 Postopek na£rtovanja aplikacije 4
1.1 �ivljenjski cikel razvoja sistema . . . . . . . . . . . . . . . . . . . . . 4
1.2 Modeli razvoja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1 Model slapa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.2 Spiralni model . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.3 Izdelava prototipov . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.4 RAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.5 Agilni razvoj . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.6 Drugi modeli . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3 Izbira modela razvoja . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 Zbiranje informacij 16
2.1 Namen aplikacije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Cilj aplikacije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Ciljna publika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Funkcija aplikacije . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Izbira ogrodja in streºni²kega okolja aplikacije . . . . . . . . . . . . . 18
xi
3 Zasnova aplikacije 20
3.1 Uporabni²ke skupine . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Funkcionalnosti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.1 Vnosni obrazci . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Zasloni aplikacije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4 Izdelava aplikacije 27
4.1 Orodja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.1 Razvojna okolja . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.2 Streºni²ka infrastruktura . . . . . . . . . . . . . . . . . . . . . 31
4.1.3 Orodje za upravljanje podatkovnih baz . . . . . . . . . . . . . 33
4.1.4 Orodje za gra�£no oblikovanje . . . . . . . . . . . . . . . . . . 34
4.1.5 Programske knjiºnice . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Podatkovni model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.1 Opis tipov . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 Zgradba aplikacije . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.1 Drevesna struktura datotek . . . . . . . . . . . . . . . . . . . 37
4.3.2 Prijavno okno . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.3 Povezovanje na bazo . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.4 Meni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.5 Vstopna stran . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.6 Hospitacija . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.7 U£na priprava . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.8 Naloga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5 Vzdrºevanje 56
5.1 Dokumentacija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2 Vzdrºevanje in hramba izvorne kode . . . . . . . . . . . . . . . . . . . 57
5.2.1 JIRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.2 TAIGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.3 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2.4 SVN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6 Evalvacija 62
7 Zaklju£ek 67
Literatura 69
Seznam uporabljenih kratic in simbolov 71
Priloge 73
Priloga 1: Datote£na struktura . . . . . . . . . . . . . . . . . . . . . 73
Priloga 2: Podatkovni model . . . . . . . . . . . . . . . . . . . . . . . 78
Priloga 3: Popis vnosnih obrazcev . . . . . . . . . . . . . . . . . . . . 81
Slike
4.1 Okno Eclipse IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Okno Netbeans IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3 GUI-vmesnik za streºnik Apache Tomcat . . . . . . . . . . . . . . . 31
4.4 Nadzorna plo²£a orodja XAMPP . . . . . . . . . . . . . . . . . . . . 32
4.5 Okno phpMyAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.6 Okno MySQL Workbench . . . . . . . . . . . . . . . . . . . . . . . . 34
4.7 Prijavno okno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.8 Meni za profesorje . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.9 Meni za ²tudente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.10 Vstopna stran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.11 Stran s seznamom hospitacij . . . . . . . . . . . . . . . . . . . . . . 44
4.12 Stran s seznamom u£nih priprav . . . . . . . . . . . . . . . . . . . . 49
4.13 Stran s seznamom nalog . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.14 Stran s seznamom oddanih nalog . . . . . . . . . . . . . . . . . . . . 54
4.15 Primer oddane naloge s poljem za komentar . . . . . . . . . . . . . . 55
5.1 Osnovno okno sistema (vir: www.atlassian.com/software/jira) . . . . 58
5.2 Osnovno okno sistema ( vir: taiga.io) . . . . . . . . . . . . . . . . . . 59
7.1 Podatkovni model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.2 Vnos osnovnih podatkov o uri . . . . . . . . . . . . . . . . . . . . . . 82
xiv
7.3 Vnos opisa ure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.4 Vnos podatkov za opazovani vidik . . . . . . . . . . . . . . . . . . . 85
7.5 Vnos osnovnih podatkov ure . . . . . . . . . . . . . . . . . . . . . . . 86
7.6 Vnos zgradbe ure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.7 Vnos podrobnega pregleda ure . . . . . . . . . . . . . . . . . . . . . . 89
7.8 Vnos dejavnosti za u£no ²ibkej²e in u£no zmoºnej²e u£ence . . . . . . 90
7.9 Obrazec za izdelavo naloge . . . . . . . . . . . . . . . . . . . . . . . 91
Uvod
Prenosni ra£unalnik je nepogre²ljiv za vsakega ²tudenta, saj si u£enja brez njega ne
moremo ve£ predstavljati. Vse ve£ literature je na voljo v digitalni obliki. Prav tako
danes skoraj vsak predmet od ²tudentov zahteva, da imajo dostop do ra£unalnika za
pripravo poro£il in oddaje nalog.
Opredelitev podro£ja in opis problema
Pri Didaktiki matematike se za objavo in oddajo nalog ºe vrsto let uporablja spletna
stran (http://www.z-maga.si). �tudentje smo vse naloge oddajali v obliki datotek.
Pregledovanje teh nalog pa je lahko dolgotrajno oziroma nerodno, saj mora profesor
odpreti vsako datoteko posebej.
Tak na£in oddajanja datotek tudi za ²tudente ni najbolj pregleden, saj morajo sami
skrbeti za organizacijo oddanih datotek na svojem ra£unalniku. Ker se obi£ajno pred
oddajo zelo hiti, manj organizirani ²tudenti niso dovolj vestni, da bi datoteke uredili
na smiseln na£in in jih pozneje na²li, ko bi jih potrebovali. Tudi sam sem bil eden
tak²nih.
S podobnim vpra²anjem se je sre£eval ºe kolega s smeri Matematika in tehnika v
svojem diplomskem delu, ko je poizku²al raziskati moºnost prilagoditve odprtoko-
dnega sistema Drupal za uporabo pri Didaktiki tehnike. Glede na njegove zaklju£ke
ta ni najprimernej²i za uporabo pri omenjenem predmetu, saj je za to, da se njegova
uporabnost pribliºa uporabnosti nekega naprednega sistema LMS, treba namestiti
vrsto modulov. Pri tem se lahko pojavijo teºave zaradi verzije sistema ali teºave
pri name²£anju. Seveda obstaja tudi moºnost, da nekatere module sami razvijemo
(Ivan²ek, 2013).
1
2
Namen in cilji diplomskega dela
Namen diplomskega dela je preveriti in raziskati moºnost izdelave spletne aplikacije,
ki bi omogo£ala:
profesorjem:
• izdelovanje poljubnih nalog za ²tudente,
• enostavno preverjanje oddanih nalog ter podajanje povratnih informacij o
oddani nalogi,
• enostavno odkrivanje plagiatorstva s podatki iz te aplikacije,
• spremljanje ²tudentov med prakso,
• deljenje vsebin za potrebe izobraºevanja;
²tudentom:
• pregled nalog, ki so na voljo za oddajo,
• pregled ºe oddanih in zaklju£enih nalog ter komentarjev profesorjev,
• oddajo dnevnika prakse.
Obema skupinama uporabnikov pa bi aplikacija omogo£ala ²e:
• izdelavo in pregled lastnih u£nih priprav s pomo£jo prilagojenih obrazcev,
• izdelavo in pregled lastnih hospitacij s pomo£jo prilagojenih obrazcev,
• re�eksijo med uporabniki za izbrani tip dokumenta.
Cilji diplomskega dela so:
• preu£iti in opisati zasnovo prilagojene spletne aplikacije,
• na£rtovati in izdelati aplikacijo,
• opisati moºnosti namestitve,
• namestitev aplikacije na streºnik.
3
Potek razvoja aplikacije
Izvedba diplomskega dela bo potekala po naslednjih korakih:
• pridobivanje ustrezne literature,
• ²tudij literature,
• na£rtovanje spletne aplikacije (na£rtovanje tipskih strani, izdelava podatkovnega
modela, seznam funkcionalnosti, ki jih bo aplikacija ponujala, ipd.),
• raziskovanje tako imenovanih �framework� knjiºnic, ki omogo£ajo laºji razvoj z
ºe izdelanimi elementi za uporabo v aplikaciji,
• izdelava aplikacije,
• evalvacija ter priprava in ureditev projektne dokumentacije.
Pregled vsebine drugih poglavij
V prvem poglavju diplomskega dela bom raziskal in opisal postopek na£rtovanja apli-
kacije. Predstavil bom faze razvoja in razvojne metodologije.
V drugem poglavju bom predstavil na£rt aplikacije, na²tel bom nekaj moºnih ogrodij
aplikacije in predstavil razloge, zakaj sem se odlo£il za odprtokodno ogrodje ZK.
V tretjem poglavju bom predstavil zasnovo aplikacije s popisom uporabni²kih skupin
in vseh funkcionalnosti ter seznamom vnosnih obrazcev. V zadnjem delu poglavja
bom predstavil vse predvidene zaslonske slike aplikacije.
V £etrtem poglavju bom predstavil izdelavo aplikacije. Tu bo predstavljen podatkovni
model z opisi entitet, datote£no strukturo aplikacije ter gra�£no in funkcionalno iz-
vedbo vseh zaslonov aplikacije.
V petem poglavju bom predstavil vzdrºevalni vidik spletnih aplikacij in orodja, s ka-
terimi si pri tem lahko pomagamo.
V ²estem poglavju bom predstavil ugotovitve evalvacije aplikacije. Podal bom tudi
seznam moºnih raz²iritev.
V sedmem poglavju sledi zaklju£ek, kjer bom povzel ugotovitve diplomske naloge.
Sledili bodo ²e viri in priloge.
Poglavje 1
Postopek na£rtovanja aplikacije
Za izdelavo vsake dobre in kakovostne aplikacije je klju£nega pomena priprava. Z do-
bro pripravo bo aplikacija bolj kakovostna in u£inkovitej²a, predvsem pa jo bo laºje
vzdrºevati. Priprava vklju£uje zbiranje informacij ter dober na£rt in pregled funkci-
onalnosti, ki jih bo aplikacija omogo£ala.
1.1 �ivljenjski cikel razvoja sistema
�ivljenjski cikel razvoja sistema, v nadaljevanju SDLC (System development life
cycle), je sestavljen iz ve£ faz, ki jih razvijalci uporabljajo za na£rtovanje, izdelavo,
testiranje in dostavo informacijskih sistemov (Bender, 2003). Cilj je izdelati visoko-
kakovosten sistem, ki bo zadostil ali presegel pri£akovanja naro£nika.
Faze ºivljenjskega cikla se razlikujejo od sistema do sistema vendar vse v celoti opisu-
jejo cikel sistema od za£etka, ko se pojavi potreba oziroma priloºnost po spremembi,
do odstranjevanja starega sistema. Vmesni koraki so analiza zahtev in potreb, obliko-
vanje novega sistema in njegovega razvoj, testiranje, uvajanje uporabnikov, integracija
sistema v obstoje£e okolje ter vzdrºevanje.
Kot primer bom predstavil SDLC ameri²kega ministrstva za pravosodje. Njihov
SDLC vsebuje deset faz, v katerih sistem nastane oziroma se modi�cira obstoje£i
(DOJ, 2003). Proces dopu²£a moºnost, da se dolo£ene faze ne izvajajo zaporedno,
4
1.1 �ivljenjski cikel razvoja sistema 5
vendar pa so med seboj soodvisne in se lahko glede na kompleksnost sistema zdruºu-
jejo ali prekrivajo. Predlagajo naslednje faze:
• Za£etna faza:
Faza se za£ne s potrebo po spremembi. To je lahko potreba po nadgradnji ob-
stoje£ega sistema ali potreba po zamenjavi sistema. Namen faze je identi�cirati
priloºnost za izbolj²avo oziroma odpravo pomanjkljivosti obstoje£ega sistema
glede na potrebo podjetja. Identi�cirati je treba tudi domneve in omejitve re²i-
tve in preu£iti moºnosti alternativnih konceptov, ki bi zahteve oziroma potrebe
lahko uresni£ili. V tej fazi nastane predlog koncepta, ki se uporabi v kasnej²ih
fazah.
• Koncept sistema:
Ta faza se pri£ne po potrditvi predloga koncepta iz za£etne faze. Aktivnosti
nato vodijo v nadaljnjo analizo. V tej vazi se izvede analiza potreb, naredita se
na£rt in strategija projekta, analizirajo se tveganja in izvede se ocena stro²kov in
kadrovskih potreb. Na podlagi vseh aktivnosti v tej fazi nastanejo dokumenti,
ki se nato uporabijo v prihajajo£ih fazah.
• Na£rtovanje:
V tej fazi nastanejo na£rti, ki so pomembni za uspeh celotnega projekta. Nastali
dokumenti se nato prilagajajo in dopolnjujejo skozi preostale faze. V tej fazi se
pripravijo strategija in sistemski okvirji, analizirajo se £asovni okvirji, ustvari
se na£rt vodenja projekta, preu£ijo se moºne alternative, analizirajo in preu£ijo
se moºne varnostne posledice ter pripravi se koncept operacij sistema.
• Analiza zahtev:
V tej fazi se sistem podrobneje de�nira. Poudarek je na de�niciji funkcij, ki
so potrebne. Naredi se analiza, dokumentirajo se poslovne potrebe ter dolo-
£ijo funkcijske in podatkovne zahteve. Na osnovi teh podatkov se izdela logi£ni
model, ki opisuje osnovni proces in podatke, ki so potrebni za podporo funkci-
onalnostim sistema. Funkcionalnosti, opisane tu, so nadgrajene funkcionalnosti
iz faze, v kateri se je pripravil koncept sistema. Rezultati te faze so dokument
funkcionalnih zahtev, na£rt testiranja in na£rt evalvacije.
• Faza oblikovanja:
Cilj te faze je preoblikovati de�nirane funkcije v speci�kacijo, ki bo vodilo za
6 Postopek na£rtovanja aplikacije
razvojno fazo. Aktivnosti v tej fazi podrobno opisujejo sistemske funkcije, vme-
snik in podatkovne zahteve. Aktivnosti se izvajajo iterativno na na£in, da
najprej de�nirajo generalno obliko sistema, ki se nato dopolnjuje v podrobnej²i
opis s tehni£nimi podrobnostmi. V tej fazi se vzpostavi aplikacijsko okolje, iz-
dela se oblika aplikacije, pripravi se na£rt implementacije, izdela se priro£nik za
vzdrºevanje, pripravijo se strategije migracije oziroma prehoda na nov sistem,
izdelata se predlog uvajanja in ocena varnostnega tveganja.
• Faza razvoja:
V tej fazi se izvede razvoj informacijskega sistema na podlagi dokumentov, iz-
delanih v predhodnih fazah. Tu se sistem zgradi, testira in preverja, ali so
funkcionalne zahteve doseºene. Po koncu te faze je sistem pripravljen na inte-
gracijo in testiranje kon£nih uporabnikov ter name²£anje v produkcijsko okolje.
V tej fazi se pripravi tudi na£rt za primere nepredvidljivih teºav sistemov. Sem
spadajo izpadi sistema, izpad podpornih sistemov in podobno.
• Integracija in testiranje:
Namen te faze je preveriti, ali sistem vsebuje vse zahteve, de�nirane v doku-
mentu s popisom zahtevanih funkcionalnosti. Aktivnosti v tej fazi so vzposta-
vitev okolja za testiranje, izvedba integracijskih testov, izvedba testiranja in
preveritev, ali sistem zadostuje vsem zahtevanim funkcionalnostim.
• Implementacija:
Tu se sistem namesti na produkcijsko okolje za uporabo kon£nim uporabni-
kom. Aktivnosti v tej fazi obsegajo obve²£anje uporabnikov o implementaciji,
izvedbo uvajanja, vnos ali pretvorbo podatkov in izvedbo pregleda uspe²nosti
implementacije.
• Uporaba in vzdrºevanje:
Ta faza se izvaja ves £as, ko je sistem v uporabi, saj se nenehno pojavljajo novi
problemi in nove potrebe. Uporabni²ka podpora je tako nenehna aktivnost.
Poudarek je na zadovoljevanju potreb uporabnikov in na pravilnem delovanju
sistema. Ko se pojavijo teºave, se z njimi pojavijo tudi zahteve za njihovo
odpravo.
• Faza odstranjevanja:
Ta faza je zadnja faza vsakega ºivljenjskega cikla sistema. Namen te faze je,
da se zastareli sistem ali njegov ve£ji del odstrani oziroma preneha uporabljati.
1.2 Modeli razvoja 7
Pri tem je pomembno zagotoviti integriteto podatkov, ki so bili hranjeni v tem
sistemu, in jih ustrezno arhivirati in zapakirati za primer, £e bo treba sistem
ponovno uporabiti v primeru nepredvidljivih dogodkov pri novem sistemu.
Ena od aktivnosti v vsaki od teh faz je tudi pregled in dopolnitev vse dokumentacije,
ki je nastala v predhodnih fazah. Tako je vsak korak pri nastajanju novega sistema
dobro de�niran in dokumentiran.
1.2 Modeli razvoja
Z namenom laºjega razumevanja in implementacije faz SDLC so ustvarili razli£ne
metodologije oziroma modele razvoja. Ti nenehno nastajajo, saj nove tehnologije
ponujajo nove moºnosti (Purcell, 2016). Nekaj pogostej²ih modelov:
• model slapa (Waterfall model),
• izdelava prototipov (Software prototyping),
• spiralni model,
• RAD (Rapid application development),
• agilni razvoj (Agile software development),
• drugi modeli: model kaosa, po£asno programiranje, V-model in drugi,
• �naredi in popravi� (�Code and �x�).
1.2.1 Model slapa
Model slapa je ena najstarej²ih metod. Najbolj o£itna lastnost tega modela je se-
kven£ni proces korakov od analize zahtev do vzdrºevanja (Purcell, 2016). Osnovni
principi modela so na²teti spodaj.
• Projekt je razdeljen v ve£ zaporednih faz, kjer je dopu²£eno manj²e prekrivanje
in prehajanje nazaj med fazami.
8 Postopek na£rtovanja aplikacije
• Poudarek je na na£rtovanju, urnikih, ciljnih datumih, stro²kih in implementaciji
celotnega sistema do dolo£enega roka.
• Strog nadzor se vzdrºuje s pomo£jo pisanja obseºne dokumentacije, nenehnih
pregledov in potrjevanja trenutnega stanja pred prehodom na novo fazo (CMS,
2008).
Glavna slabost tega modela je, da po fazi zbiranja zahtev ni ve£ moºnosti, da bi
te zahteve dopolnili, £e se spremenijo med razvojnim procesom, ko se pojavijo nove
informacije. Ker pa se potrebe skoraj vedno spremenijo skozi dolgotrajni razvojni
proces, je produkt na koncu razvojnega cikla pogosto ºe zastarel in neuporaben.
Zato je ta model neprimeren za dalj²e in kompleksnej²e projekte oziroma projekte,
kjer zahteve niso natan£no de�nirane ºe na za£etku. Model je primernej²i za kratke
in enostavne projekte oziroma projekte, kjer je zahtev malo in so znane in to£no
de�nirane ºe na za£etku razvojnega cikla in je podro£je projekta ºe dobro znano
(Purcell, 2016).
1.2.2 Spiralni model
Spiralni model je nastal kot odziv na slabosti modela slapa. Model deluje tako, da
razvijalec za£ne z manj²im naborom zahtev in izvede vse faze razvojnega cikla pred
name²£anjem. Nato na podlagi pridobljenih znanj zavrtijo krog ²e enkrat in med
postopkom dodajajo nove funkcionalnosti na podlagi zahtev, ki so se med prej²njo
iteracijo pojavile. Na ta na£in se aplikacija dopolnjuje, dokler ne zadosti vsem zah-
tevam in je pripravljena na namestitev na produkcijsko okolje. Vsaka iteracija pred
produkcijsko verzijo je prototip aplikacije (Purcell, 2016).
Prednost tega modela v primerjavi z modelom slapa je, da iterativni pristop omo-
go£a, da se razvoj za£ne tudi, £e ²e niso znane vse zahteve projekta. S testiranjem
vsakega prototipa se na podlagi ugotovitev aplikacija prilagodi v naslednji iteraciji.
Vsaka iteracija prototipa odgovori na to, ali bo sistem uporaben ali ne (Purcell, 2016).
Osnovni principi modela so:
• Fokus je na oceni tveganja in na zmanj²anju tveganosti projekta z razdelitvijo na
manj²e segmente, kar omogo£i laºje spreminjanje in popravljanje med procesom
1.2 Modeli razvoja 9
razvoja ter moºnosti za evalvacijo tveganja in razmislek o ºivljenjskem ciklu
projekta.
• Vsak cikel vklju£uje prehode med enakim zaporedje korakov.
• Vsak obhod spirale ima ²tiri kvadrante: Dolo£itev ciljev, alternativ in omeji-
tve ponovitve; Evalvacija alternativ, identi�kacija tveganj in njihova odprava;
Razvoj in preverjanje izsledkov iteracije; Na£rtovanje naslednje iteracije.
• Vsak cikel se za£ne z identi�kacijo deleºnikov in njihovih pogojev za uspeh.
Vsak cikel se zaklju£i s pregledom, oceno in zavezanostjo k naslednjemu ciklu
-(CMS, 2008).
1.2.3 Izdelava prototipov
Model temelji na izdelavi prototipov aplikacije. To so nedokon£ane verzije aplikacije,
ki se razvija. Cilj je simulirati le nekaj vidikov aplikacije. Ti prototipi so lahko pov-
sem druga£ni od kon£nega izdelka.
Prednosti tega modela so, da lahko razvijalec od uporabnikov dobi odziv ºe zgodaj v
razvoju (CMS, 2008).
Osnovni principi tega modela so:
• Model ni samostojna razvojna metodologija ampak le del ve£je bolj tradicio-
nalne metodologije. Pogosto nastopa skupaj z inkrementalnim razvojem, RAD
ali spiralnim razvojem.
• Poizku²a razbiti projekt na manj²e, bolj obvladljive kose in pomaga pri eno-
stavnej²emu spreminjanju med samim razvojnim procesom.
• Kon£ni uporabnik oziroma primer kon£nega uporabnika je prisoten ves razvojni
proces.
• Razvijajo se manj²i kosi sistema. Ta se z vsako iteracijo razvija v popolnej²i
prototip, ki ustreza zahtevam uporabnikov.
• �eprav je ve£ina prototipov izdelanih z zavedanjem, da se bodo zavrgli, se
nekateri razvijejo v delujo£ sistem.
10 Postopek na£rtovanja aplikacije
• Pri pripravljanju prototipov mora biti razvijalec seznanjen z osnovno poslovno
problematiko, da se s tem izogne re²evanju napa£nih problemov (CMS, 2008).
Tipi prototipov:
• Izdelava prototipov, ki se po uporabi zavrºejo/Hitra izdelava proto-
tipov:
Temelji na modelu, ki se ga bo raje zavrglo, kot pa da bi postal del kon£ne
re²itve. Prototip nastane na podlagi pridobljenih prvotnih zahtev. Z njim se
vizualno prikaºe, kako naj bi bil videti kon£ni produkt. Ti prototipi nastanejo v
zgodnjih fazah razvoja. Najve£ji dejavnik tu je hitrost, s katero je model izdelan.
S pomo£jo teh prototipov kon£ni uporabniki laºje preverijo svoja pri£akovanj
in razjasnijo zahteve.
• Prototip, ki se razvija:
Glavni cilj tega tipa je izdelava prototipa, ki je strukturiran in ga je mogo£e
dopolnjevati. Prototip je jedro novega sistema, ki se bo nadgrajevalo v celovit
sistem. Sistem se nenehno izbolj²uje in prenavlja. Ta tehnika razvijalcem omo-
go£a, da dodajo funkcionalnosti ali spremembe, ki jih med na£rtovanjem ni bilo
mogo£e predvideti. Razlika v primerjavi s prej²njim tipom prototipov je ta, da
so ti prototipi delujo£i sistemi.
• Inkrementalni prototipi:
Aplikacija ali sistem se razdelita na ve£ manj²ih delov oziroma funkcionalnosti.
Za vsako funkcionalnost se pripravi svoj prototip. Na koncu pa se vsi prototipi
zdruºijo v delujo£ sistem, ki se ga ne spreminja razen v primeru napak (Puckett,
2001).
1.2.4 RAD
Model se je razvil s potrebo po hitrej²em razvoju programske opreme. Glavni novi
princip te metodologije v primerjavi s starej²imi SDLC-modeli je uporaba prototipov.
Prototip nastane po hitri fazi zbiranja zahtev in je predstavljen uporabnikom. Po-
vratna informacija teh uporabnikov nato nudi informacije, kako aplikacijo izbolj²ati.
Prednost tega modela je v skraj²anju £asa, potrebnega za objavo nove aplikacije, saj
presko£i veliko korakov tradicionalnih SDLC-modelov, da zagotovi hitrost in niºjo
ceno izdelave programske opreme. Slabost tega pa je, da je lahko ta proces v£asih
1.2 Modeli razvoja 11
prehiter in se lahko zgodi, da testiranje ni dovolj temeljito (Purcell, 2016).
Osnovni principi te metodologije so:
• Klju£ni cilj je hiter razvoj in posredovanje visokokakovostnega sistema pri rela-
tivno majhni investiciji.
• Poizku²a reducirati tveganje pri projektu tako, da raz£leni projekt na manj²e
segmente in nudi laºje vodenje sprememb skozi njihovo razvojno fazo.
• Cilj je hitro izdelovati visokokakovostne sisteme primarno skozi iterativne pro-
totipe, aktivno vklju£evanje uporabnikov in prilagojenih razvojnih orodjih, ki
razvijalcem pomagajo pri pisanju trivialne kode (seznam gradnikov, enostavnih
privzetih funkcij in knjiºnic ipd.).
• Glavni poudarek je na izpolnjevanju poslovnih potreb.
• Nadzor nad projektom vklju£uje dolo£anje prioritet razvoja in de�niranje rokov.
�e projekt za£ne odstopati od za£rtanih rokov, je poudarek na zmanj²anju
zahtev in ne prestavljanje rokov.
• Pomembna je prisotnost aktivnih uporabnikov.
• Izdelava potrebne dokumentacije za prihodnji razvoj in vzdrºevanje (CMS,
2008).
�tiri razli£ne faze procesa RAD:
• Faza na£rtovanja:
V tej fazi se izvede proces s katerim se ugotovi zakaj je sistem potrebno zgraditi
in kako se ga bo zgradilo. Faza se za£ne z iniciacijo, ko se pojavi potreba po
spremembi. Na podlagi te zahteve se izvede analiza izvedljivosti. Ko je predlog
potrjen se izvede ²e na£rtovanje projekta.
• Faza analize:
V tej fazi se poi²£e odgovore na vpra²anja, kdo bo sistem uporabljal, kaj bo
sistem omogo£aj ter kje in kdaj se ga bo uporabljalo. V tej fazi se postavi
zahteve na podlagi katerih nastane predlog koncepta sistema.
12 Postopek na£rtovanja aplikacije
• Faza oblikovanja:
V tej fazi se izvede oblikovanje sistema. V tej fazi nastane speci�kacija sistema,
ki opisuje, kako bo sistem deloval, kako bo zgrajen uporabni²ki vmesni, kak²na
bo podatkovna struktura in kak²na bo gra�£na zasnova.
• Faza implementacije:
V tej fazi se sistem izdela. V tej fazi se izvede konstrukcija sistema, name-
stitev in na£rt podpore. To je tudi najdalj²a faza v SDLC in zahteva najve£
pozornosti.(Dennis, Wixom, in Roth, 2011).
1.2.5 Agilni razvoj
Metodologija agilnega razvoja je skupina metodologij, ki so usmerjene v programira-
nje in imajo fokus na racionalizaciji SDLC. Ve£ina modeliranja in obseºne dokumen-
tacije je odstranjeno in nadome²£eno z osebno komunikcijo z naro£niki. Poudarek
je na iteracijah aplikacije, kjer je vsaka iteracija svoj projekt z vsemi fazami SDLC
(na£rtovanje, analiza zahtev, oblikovanje, pisanje programske kode, testiranje in do-
kumentiranje) (Dennis in sod., 2011).
Dvanajst principov metodologije:
1. Zadovoljstvo stranke z zgodnjim in nenehnim dostavljanjem programske opreme.
2. Spreminjanje zahtev celo v poznej²i stopnji razvoja je dobrodo²lo.
3. Delujo£a programska oprema je dostavljena pogosto.
4. Nenehno sodelovanje kon£nih uporabnikov in razvijalcev.
5. Projekti so zgrajeni v krogu motiviranih zaupanja vrednih posameznikov.
6. Najbolj²a je osebna komunikacija.
7. Delujo£a programska oprema je merilnik napredka.
8. Trajnostni razvoj, ki lahko zdrºi stalni tempo.
9. Preprostost je klju£na.
10. Stalna skrb za tehni£no kakovost in dobro oblikovanje.
1.2 Modeli razvoja 13
11. Najbolj²e arhitekture, zahteve in dizajn nastanejo v samostojnih organiziranih
skupinah.
12. Delovne skupine pogosto razmi²ljajo o tem, kako postati ²e bolj u£inkovit in se
temu prilagoditi (Ambler, 2014).
1.2.6 Drugi modeli
Model kaosa
Model kaosa pravi, da morajo vse faze ºivljenjskega cikla veljati za vse ravni projekta,
od celote do kode.
• Celoten projekt mora biti de�niran, implementiran in integriran.
• Sistem mora biti de�niran, implementiran in integriran.
• Moduli morajo biti de�nirani, implementirani in integrirani.
• Funkcije morajo biti de�nirane, implementirane in integrirane.
• Vrstice kode morajo biti de�nirane, implementirane in integrirane.
Ena od pomembnih sprememb v perspektivi je, ali projekt ²tejemo za enoto ali za
ve£ manj²ih kosov. Nih£e ne napi²e ve£ deset tiso£ vrstic kode naenkrat, pi²ejo jo
postopoma in jo sproti preverjajo.
Glavno pravilo strategije kaosa je ta, da se najpomembnej²e teºave vedno re²ujejo
prve.
Strategija kaosa je podoba na£ina dela, ki ga programerji uporabljajo proti koncu
projekta, ko imajo seznam napak za odpravit ter funkcionalnosti za ustvarit. Nava-
dno nekdo daje prednost preostalim nalogam, programerji pa jih popravljajo eno po
eno. Strategija kaosa pravi, da je to edini pravi na£in dela (Wikipedia, 2014).
14 Postopek na£rtovanja aplikacije
Naredi in popravi
Naredi in popravi oziroma s tujko �code and �x� je antivzorec. Razvoj ni izveden skozi
namerno strategijo oziroma metodologijo, ampak je pogosto rezultat £asovnega priti-
ska na razvojno ekipo. Razvijalci za£no kodo pisati brez vnaprej dolo£enega dizajna,
ki bi jih zadrºeval. Testiranje se za£ne med samim razvojem pogosto zelo pozno v
razvojnem ciklu. Pred izdajo programske opreme pa je treba odpraviti vse napake
oziroma tako imenovane hro²£e, ki so nastali med razvojem (Wikipedia, 2016c).
1.3 Izbira modela razvoja
Zaradi na£ina dela in pomanjkanja izku²enj ter samostojnega dela sem pri razvoju
uporabil ve£ tipov modelov. Na za£etku projekta sem uporabil elemente metode
RAD:
• Za£el sem z zbiranjem informacij. V tem koraku sem najprej poiskal in pregledal
dokumente, ki smo jih med ²tudijem oddajali na profesorjevi spletni strani.
Tako sem dobil seznam vseh tipov dokumentov oziroma nalog, za katere bo
aplikacija omogo£ala izdelavo oziroma oddajo. Preveril sem, kak²na programska
ogrodja obstajajo in ali bi katero od njih bilo primerno. Preu£il sem, katere
metode razvoja obstajajo in katera bi bila najprimernej²a za moj na£in dela.
• Izdelal sem idejno zasnovo aplikacije glede na zbrane podatke. Sem spadajo
seznam funkcionalnosti ter seznam zaslonov, ki jih bo vklju£eval, in izdelava
podatkovnega modela. Izrisal se tudi okvirno postavitev teh zaslonov.
• Dizajn aplikacije sem izdelal skupaj z delujo£im prototipom. Pri prvem proto-
tipu se ²e nisem osredoto£il na gra�£no zasnovo, ta je pri²la v kasnej²ih verzijah
prototipa. Pri prvem prototipu pa sem uporabil gradnike, ki mi jih je ºe ponu-
jalo izbrano programsko ogrodje (Framework).
Razen nekaj govorilnih ur, ko sem profesorjem na fakulteti predstavil prototip aplika-
cije, v razvoj nisem vklju£eval drugih kon£nih uporabnikov. Razvoj kode je potekal s
pomo£jo izdelave prototipov:
• Projekt sem razdelil na manj²e kose in razvil vsakega posebej. Naslednjega sem
se lotil, ko je bil prej²nji kon£an.
1.3 Izbira modela razvoja 15
• Uporabil sem metodo inkrementalnih razvijajo£ih se prototipov, saj so se ti na
koncu zdruºili v delujo£ sistem.
• Testiranje delovanja sem izvajal na vsakem kosu posebej.
Ko so bili vsi prototipi izdelani in zdruºeni v en sistem, sem izvedel evalvacijo celo-
tnega sistema ter na podlagi ugotovitev pripravil na£rt sprememb. Pri tem so funk-
cionalnosti ostale enake. Spremembe so bile vezane predvsem na gra�£no zasnovo ter
postavitev elementov na dolo£enih zaslonih.
Po uveljavitvi vseh sprememb sem sistem ponovno testiral. Vse ugotovljene teºave in
napake sem si zabeleºil. Za odpravo teh napak sem uporabil model kaosa:
• Najprej sem odkril in de�niral vse napake.
• Napake sem re²eval eno po eno.
• Najve£je oziroma najpomembnej²e napake sem odpravil prve.
Po odpravi vseh napak sem izdelal ²e seznam moºnih izbolj²av, ki pa jih prepu²£am
kasnej²im generacijam oziroma se lahko opravijo kasneje in ne bodo del te diplomske
naloge.
Poglavje 2
Zbiranje informacij
Informacije sem zbiral med ²tudijem, preko nalog, ki sem jih oddajal, ter preko raz-
li£nih orodij, ki sem jih uporabljal med ²tudijem in v prostem £asu.
Trenutno stanje oziroma stanje v £asu, ko sem pri£el izdelovati projekt:
• Profesor na spletni strani odpre nalogo z navodilom ter rokom, do katerega mora
biti naloga oddana.
• �tudentje datoteke oddajajo preko spletne strani v tekstovni obliki razli£nih
formatov.
• Slab²i pregled nad oddanimi datotekami. Uporabnik mora za bolj²i pregled nad
tem, kaj je kdaj oddal, poskrbeti sam, na lastnem ra£unalniku.
• Ni moºnosti deljenja in re�eksije med ²tudenti.
Med ²tudijem sem odkril veliko morebitnih izbolj²av trenutnega procesa, ki sem jih
ºelel vklju£iti v aplikacijo. Informacije o zahtevah in na£inu uporabe trenutnih re²itev
sem pridobil tudi od profesorjev.
Pri zbiranju sem si zastavil ²tiri vpra²anja (Bowlby, 2008):
• Kaj je namen aplikacije?
• Kaj je cilj aplikacije?
16
2.1 Namen aplikacije 17
• Kdo je ciljna publika?
• Kak²na bo vsebina oziroma funkcija aplikacije?
2.1 Namen aplikacije
Namen aplikacije je omogo£iti preglednej²i in bolj strukturiran pregled nad oddanimi
vsebinami in nalogami. Za laºje razumevanje problematike sem poiskal vse oddane
naloge in jih razdelil v dve kategoriji:
• Strukturirane vsebine
Sem spadajo vse vsebine, ki smo jih oddajali preko ºe pripravljenih obrazcev,
s katerimi nas je profesor usmerjal, da smo bili osredoto£eni oziroma da smo
opazovali s pravega zornega kota. Med te tipe vsebin spadajo poro£ila o hospita-
cijah, poro£ila o u£nih nastopih, u£ne priprave, dnevnik prakse, predde�nirane
naloge in podobno.
• Nestrukturirane vsebine
Sem spadajo vsebine, ki niso imele ºe vnaprej dolo£ene strukture in so imele
prosto obliko, torej raziskovalne naloge in poro£ila.
2.2 Cilj aplikacije
Cilj aplikacije je olaj²ati delo profesorjem in ²tudentom pri prakti£nem pedago²kem
usposabljanju. Profesorjem bo aplikacija omogo£ala laºjo pripravo nalog za ²tudente
ter laºje podajanje komentarjev na oddano vsebino. S pomo£jo strukturiranih obraz-
cev za posamezne tipe vsebin bo oddana vsebina bolj pregledna in laºja za vnos.
Omogo£ala bo enostaven pregled nad vsemi, tudi ºe oddanimi nalogami. S pomo£jo
aplikacije bo ²tudent imel vse naloge vedno na enem mestu.
Tu sem se osredoto£il predvsem na to, kako smo do sedaj oddajali datoteke, kako
je to re²eno drugje in kaj bi lahko izbolj²ali.
Pri Didaktiki matematike smo naloge oddajali preko profesorjeve spletne strani, pri
Didaktiki ra£unalni²tva preko LMS-orodja Moodle, pri predmetu Didaktika pa v pisni
obliki. Aplikacija mora omogo£ati, da se vsi trije na£ini oddaje zdruºijo. Omogo£ena
18 Zbiranje informacij
bo oddaja tekstovnih datotek, slik, oddaja in izpolnjevanje ºe de�niranih obrazcev
ter izdelava in oddaja poljubnih obrazcev, ki jih lahko izdelajo profesorji sami. Tako
bo profesorjem omogo£eno dovolj svobode, da lahko znanje preverjajo na na£in, ki
jim je najbliºji.
2.3 Ciljna publika
Ciljna publika so profesorji in ²tudentje pedago²ke fakultete. Dostop do aplikacije
bo omogo£en vsem. Vsak predmet bo imel svojo oznako, profesorji pa bodo dolo£ili,
kateri ²tudentje vidijo katero oznako. Zaradi laºjega upravljanja lahko slednje izvaja
administrator sistema. V tem primeru mora ta oseba dobiti seznam uporabnikov za
vnos ter dolo£iti, v katere predmete jih je treba dodeliti.
Zaradi moºnosti predelave aplikacije v bolj splo²no orodje pa so na nek na£in ciljna
publika tudi bodo£i profesorji in u£itelji.
2.4 Funkcija aplikacije
Funkcija aplikacije bo omogo£iti ²tudentom bolj²i pregled nad oddanimi vsebinami.
Omogo£ala bo elektronsko oddajo nalog in hranjenje drugih dokumentov za namene
²tudija (u£ne priprave, hospitacije, dnevnik prakse itd.). Vsebine bodo smiselno raz-
deljene glede na v aplikaciji ustvarjene predmete. Vsak profesor bo imel vpogled le
v svoje predmete, vsak ²tudent pa le v tiste, za katere bo dobil dovoljenje oziroma
potrditev s strani profesorjev.
Aplikacija bo omogo£ala, da se bodo dokumenti kreirali na streºniku. Zato jih bo
uporabnik lahko oddal s katerega koli ra£unalnika, ki bo imel dostop do interneta
oziroma do notranjega omreºja fakultete, £e aplikacija ne bo na voljo na svetovnem
spletu, ampak le v lokalnem omreºju.
2.5 Izbira ogrodja in streºni²kega okolja aplikacije
Drugi del zbiranja informacij je bilo iskanje primernega orodja in ogrodja (Fra-
mework), ki bi ju pri razvoju aplikacije lahko uporabil. Obstaja veliko odprtokodnih
ogrodij. Zaradi poznavanja programskega jezika Java sem izbiral med naslednjimi:
2.5 Izbira ogrodja in streºni²kega okolja aplikacije 19
• ogrodje Play (https://playframework.com/),
• ogrodje Grails (https://grails.org/),
• ogrodje ZK (https://www.zkoss.org/).
Odlo£il sem se za zadnjega, saj sta bili prvi dve v £asu za£etka projekta ²e v povojih
oziroma v nedodelanih verzijah. Prav tako je ogrodje ZK imelo vse elemente, ki sem
jih potreboval. Ogrodje je ºe vklju£evalo enostavno povezovanje na podatkovno bazo,
v²e£no gra�£no podobo osnovnih elementov, orodje za izdelavo tekstovnih dokumen-
tov glede na vnose v podatkovni bazi in druge elemente, ki so mi poenostavili razvoj
in mi omogo£ili hitro izdelavo prvega prototipa.
Odlo£itev za to programsko ogrodje so mi olaj²ali tudi pozitivni komentarji o izdelku
ter koli£ina ponujene in enostavno dostopne dokumentacije z nazornimi primeri in
izvorno kodo za posamezni primer, s katero sem si pomagal pri izdelavi aplikacije.
Zaradi oblike paketa bo aplikacijo mogo£e namestiti na ve£ino streºni²kih okolij, ki
poganjajo javanske aplikacije, saj je za namestitev dovolj, da se arhivska datoteka na-
mesti v ustrezno mapo in da se v okolju ustvarijo ustrezne spremenljivke, ki vsebujejo
podatke za povezavo na podatkovno bazo.
• Apache Tomcat,
• GlassFish,
• JBoss,
• Weblogic.
Zaradi laºjega razvoja in poznavanja podatkovnega okolja sem pri razvoju uporabil
podatkovno bazo MySql. Aplikacijo je mogo£e brez ve£jih teºav predelati tako, da
deluje tudi na kateri drugi podatkovni bazi.
Poglavje 3
Zasnova aplikacije
Na podlagi zbranih informacij sem pripravil zasnovo aplikacije. Zasnova vsebuje opise
uporabni²kih skupin uporabnikov, popis zahtev in funkcionalnosti ter popis vseh pred-
videnih zaslonskih slik aplikacije. Na podlagi te zasnove sem pri£el z razvojem. Med
razvojem sem zasnovo optimiziral. Nekatere zaslone in funkcionalnosti sem zdruºil,
nekatere pa izpustil in jih bom obravnaval kot morebitne izbolj²ave za nadgradnjo
aplikacije.
3.1 Uporabni²ke skupine
• Profesorji
Uporabniki so profesorji in asistenti na fakulteti. Tej uporabni²ki skupini je
omogo£eno, da pripravljajo naloge, vna²ajo hospitacije in u£ne priprave, pregle-
dujejo oddane naloge in podajajo komentarje, omogo£eno jim je pregledovanje
vseh oddanih nalog ²tudentov. Vsak od profesorjev lahko vodi enega ali ve£
predmetov.
• �tudentje
Uporabniki so ²tudentje. Tej uporabni²ki skupini je omogo£eno vna²anje ho-
spitacij in u£nih priprav ter pregled in oddaja pripravljenih nalog. Pregledujejo
lahko le svoje oddane naloge in vidijo komentarje profesorja o njihovih oddanih
nalogah. Vsak ²tudent je lahko slu²atelj enega ali ve£ predmetov.
• Administratorji
Administratorji so skupina uporabnikov, ki jim je omogo£eno, da kreirajo nove
20
3.2 Funkcionalnosti 21
predmete in jih dodeljujejo profesorjem ter uvaºajo in vna²ajo nove uporabnike.
Ostalih dostopov ne potrebujejo. Moºna funkcionalnost, ki jo administratorji
imajo, je impersonacija uporabnikov. Ta funkcionalnost pomaga pri identi�ka-
ciji teºav. Pustil jo bom za bodo£e nadgradnje sistema.
3.2 Funkcionalnosti
• Prijava v sistem in izbira predmeta
Uporabnik se preko prijavnega okna prijavi v sistem in izbere predmet. Na pod-
lagi uporabni²ke skupine, v katero je uvr²£en, se uporabniku izoblikuje glavni
meni ter seznam dokumentov glede na izbrani predmet.
• Pregled vnesenih/oddanih dokumentov glede na tip dokumenta
Uporabniku se na strani izpi²ejo vsi dokumenti za izbrani tip. Tip dokumentov
oziroma pogled uporabnik izbere v meniju. Dokument je opremljen s podatki o
naslovu ter datumu nastanka.
• Pregled vnesenih/oddanih dokumentov glede na status dokumenta
Ta funkcionalnost se nana²a na pregled nalog. Do tega pogleda uporabnik
dostopa preko menija. Naloge se razvrstijo glede na trenutno aktivne naloge
in zaklju£ene naloge. Profesorjem se poleg teh dveh statusov prikazujejo ²e
neaktivirane naloge oziroma osnutki nalog.
• Priprava nalog
Ta funkcionalnost je omogo£ena le profesorjem. Profesor s pomo£jo prilagoje-
nega obrazca izdela nalogo tako, da dolo£i vse njene elemente.
� Naslov naloge
� �as trajanja oziroma rok oddaje
� Uvod in navodilo naloge
� Vnosna polja
Po pripravi naloge ima profesor moºnost, da nalogo le shrani ali pa jo shrani
in aktivira. Ko se naloga aktivira, je ni ve£ mo£ popravljati. Poleg teh funkci-
onalnosti je omogo£en ²e predogled naloge za laºjo predstavo, kako bo naloga
videti, ko bo objavljena.
22 Zasnova aplikacije
• Oddaja nalog
Ta funkcionalnost je omogo£ena ²tudentom. Naloga se izdela glede na podatke,
ki jih je vnesel profesor. Naloga je aktivna le do datuma, ki ga je za rok oddaje
dolo£il profesor. Po preteku tega roka naloga dobi status ºaklju£ena"in je ni mo-
go£e ve£ oddati. �tudentom je do roka oddaje vedno omogo£eno spreminjanje
naloge.
• Oddaja dnevnika prakse Ta funkcionalnost je omogo£ena ²tudentom. Preko
pripravljene forme ²tudentje izberejo vnesene priprave in hospitacije ter ostale
podatke in poro£ila za dejavnosti, ki so jih izvajali med pedago²ko prakso.
• Deljenje vnesenih dokumentov z drugimi uporabniki
Uporabnikom je omogo£eno, da znotraj istega predmeta delijo vnesene doku-
mente z drugimi ²tudenti. Prejemnik deljene datoteke lahko na deljeno datoteko
poda komentar, kot je vpisano v naslednji funkcionalnosti.
• Dodajanje komentarjev k posameznemu dokumentu
Ta funkcionalnost omogo£a profesorjem, da podajo komentar na posamezno
oddano nalogo, funkcionalnost je omogo£ena ²ele potem, ko dobi naloga status
ºaklju£ena".
• Pripenjanje tekstovnih dokumentov in slik
Za namen oddajanja nalog je omogo£eno, da uporabnik pripne tekstovno dato-
teko ali datoteko s slikovnim gradivom. Za ta namen se na streºniku za vsakega
uporabnika ustvari nova mapa.
• Tiskanje dokumentov
Funkcionalnost omogo£a tiskanje oziroma shranjevanje dokumentov v format
tipa MS Word ali PDF. Uporabnik bo nato lahko dokument po ºelji ²e dopolnil.
• Orodje za odkrivanje "plagiatorstva"
Funkcionalnost omogo£a, da profesor preko vmesnika vna²a dalj²e nize besed in
preveri, ali se ti ve£krat pojavijo v sistemu. Glede na poizvedbo se pojavi ena
ali ve£ datotek. �e se pojavi ve£ datotek, se profesorju omogo£i, da jih odpre
in primerja med seboj.
3.3 Zasloni aplikacije 23
3.2.1 Vnosni obrazci
Na podlagi zbranih podatkov se za strukturirane vsebine pripravijo vnosni obrazci.
Ti so:
• Vnosni obrazec za hospitacijo
Obrazec omogo£a vnos osnovnih podatkov o u£ni uri, kot so datum, naslov ure,
ime u£itelja ali u£iteljice, podatki o mentorju, podatki to sklopu, temi in u£ni
enoti. Poleg osnovnih podatkov o uri obrazec omogo£a ²e vnos re�eksije, vezane
na opazovani vidik, mnenje o izvedbo ter cilje ure.
• Vnosni obrazec za u£no pripravo Obrazec omogo£a vnos osnovnih podatkov
o u£ni uri, kot so datum, mentor, naslov, tema, sklop, enota, speci�£ni u£ni cilji
ter pripomo£ki. Poleg osnovnih podatkov obrazec omogo£a ²e izdelavo zgradbe
ure ter izdelavo podrobne zgradbe ure.
• Vnosni obrazec za pripravo nalog Obrazec omogo£a enostavno izdelavo na-
loge. V obrazec se vna²a naslov, uvod, rok oddaje ter struktura naloge oziroma
postavitev in tipi vnosnih polj.
• Vnosni obrazec za oddajo naloge Obrazec se zgradi glede na podatke, vne-
sene v obrazec za pripravo naloge.
• Forma za oddajo dnevnika prakse Obrazec je namenjen oddaji dnevnika
prakse. Omogo£a vnos osnovnih podatkov o praksi, kot so podatki o ²oli, vnos
mentorja, urnik prakse in druge informacije. Poleg tega omogo£a ²e vklju£itev
dokumentov (hospitacije, u£ne priprave), ki jih ²tudent med prakso vna²a v
aplikacijo.
3.3 Zasloni aplikacije
• Prijavno okno
Zaslon vsebuje prijavno okno z vnosnimi polji za uporabni²ko ime in geslo ter
gumb za prijavo. Po kliku na gumb se preveri pravilnost vnesenih podatkov.
V primeru napa£nega gesla, ali £e uporabnik ne obstaja, se na zaslonu izpi²e
opozorilo, sicer pa je uporabnik preusmerjen na prijavno stran.
24 Zasnova aplikacije
• Doma£a stran
Zaslon vsebuje hitre povezave do posameznih seznamov dokumentov in nalog.
Moºna raz²iritev zaslona je, da se poleg povezav do seznamov dodajo ²e podatki
o uporabniku, kot so ime, priimek, vpisna ²tevilka, seznam predmetov, zadnji
komentarji in podobno.
• Stran s vnesenimi hospitacijami
Zaslon vsebuje seznam vseh vnesenih hospitacij za izbrani predmet. Dokumenti
so razporejeni od najnovej²ega do najstarej²ega. Vsak vnos vsebuje podatek o
naslovu ure, ter datumu hospitacije.
• Stran z vnesenimi u£nimi pripravami
Zaslon vsebuje seznam vseh vnesenih u£nih priprav za izbrani predmet. Do-
kumenti so razporejeni od najnovej²ega do najstarej²ega. Vsak vnos vsebuje
podatek o naslovu ure ter datum u£nega nastopa.
• Stran z nalogami
Zaslon vsebuje seznam vseh nalog in je razdeljen glede na status. V vsakem
razdelku so naloge razporejene od najnovej²e do najstarej²e. Vsak vnos vsebuje
podatek o naslovu naloge ter roku oddaje. Razdelki pa so:
� Neaktivne naloge. Ta razdelek se prikazuje le profesorjem in vsebuje se-
znam ²e neaktivnih nalog. Te naloge lahko profesor ²e spreminja in pre-
gleduje.
� Aktivne naloge. Ta razdelek prikazuje seznam vseh aktivnih nalog. �tu-
dentje lahko tu naloge izpolnjujejo, ko pa so te izpolnjene, jih lahko do
spremembe statusa ²e spreminjajo. Profesorji pa lahko do spremembe sta-
tusa to nalogo ro£no zaklju£ijo.
� Zaklju£ene naloge. Ta razdelek vsebuje seznam zaklju£enih nalog. �tuden-
tje lahko s klikom na posamezni vnos pregledujejo vnose, ki jih ne morejo
spreminjati. Poleg vnosov se prikaºe tudi komentar profesorja, £e je ta ºe
vnesen. Profesor s klikom na nalogo odpre seznam vseh oddanih vnosov
za izbrano nalogo.
• Stran za vnos hospitacije
Zaslon oziroma obrazec se razdeli na tri korake.
3.3 Zasloni aplikacije 25
� Prvi korak vsebuje vnosna polja za vpis osnovnih podatkov ure, ki jo upo-
rabnik hospitira. To so naslov ure, izvajalec, mentor/-ica (o²/s²), datum,
ura, razred, ²ola, u£na tema, u£ni sklop in u£na enota.
� Drugi korak (Vidik A) vsebuje vnosna polja za opis ure, to so kratek opis
u£ne ure, pristop, vpra²anje, ki bi ga zastavili u£iteljici, ter mnenje o or-
ganizaciji.
� Tretji korak pa omogo£a opis in vnos opaºanj glede opazovanega vidika.
Podatki, ki se tu vnesejo, so opaºanja, mnenje, kako bi ravnali, razlaga
opaºanj, zakaj je vidik pomemben ter razlaga za vse vnesene premisleke.
• Stran za vnos u£ne priprave
Zaslon oziroma obrazec se razdeli na ²tiri korake.
� Prvi korak vsebuje vnosna polja za vpis osnovnih podatkov o uri u£nega
nastopa. To so naslov ure, izvajalec (²tudent), mentor/-ica (o²/s²), datum,
ura, razred, ²ola, u£na tema, u£ni sklop, u£na enota, speci�£ni u£ni cilji,
u£ni pristop, u£ne oblike, u£ne metode, u£na sredstva in pripomo£ki ter
viri.
� Drugi korak vsebuje vnosna polja za izdelavo zgradbe ure. Zgradba ure se
pripravi tabelari£no. Za vsak vnos v tabeli je potrebno vnesti naslednje
podatke: namen/cilj, £as (v min), ki ga bomo pri tem delu ure porabili,
metode/oblike, pripomo£ki, opis strategije doseganja ter na£in preverjanja
le-tega.
� Tretji korak vsebuje vnosna polja za izdelavo podrobnej²ega pregleda ure.
Pregled se prav tako pripravi tabelari£no. Za vsak vnos v tabeli je po-
trebno vnesti podatke o namenu oziroma cilju, dejavnosti u£itelja, dejav-
nosti u£enca in tabelski sliki.
� �etrti korak pa vsebuje vnosna polja za opis dejavnosti, ki so namenjene
u£no ²ibkej²im u£encem, ter opis dejavnosti, ki so namenjene u£no zmo-
ºnej²im u£encem.
• Stran za pripravo naloge
Zaslon vsebuje polja za vnos osnovnih podatkov o nalogi ter polja za vnos
zgradbe naloge. Osnovni podatki so naslov, datum zaklju£ka oziroma rok ter
navodilo. Zgradba naloge pa se prikaºe tabelari£no. Vsak vnos v tabeli vsebuje
podatek o tipu komponente (vnosno polje, izbirno polje, urejevalnik besedila,
26 Zasnova aplikacije
oddaja datoteke, oddaja priprave, oddaja hospitacije ...), ID-oznaki polja (za
vnos v podatkovno bazo) ter dodatno polje za dolo£itev dodatnih lastnosti polja
(spremni tekst, izbire za izbirno polje). Zaslon poleg gumba za shranjevanje
omogo£a ²e predogled ter gumb za aktiviranje naloge.
• Stran za predogled naloge
Preden profesor nalogo aktivira, ima moºnost, da pogleda njeno zgradbo. Na ta
na£in dobi predstavo, kako se bo naloga prikazovala. Do zaslona lahko profesor
dostopa s klikom na gumb za prikaz predogleda na zaslonu za pripravo naloge.
Odpre se novo okno, ki vsebuje vneseno zgradbo naloge.
• Stran za vnos in oddajo naloge
Ko profesor nalogo aktivira, se ta prikaºe v seznamu nalog tudi ²tudentom. S
klikom na vnos se odpre naloga glede na zgradbo, ki je bila za to nalogo vnesena
(prikaºe se enaka zgradba, kot jo profesor vidi v predogledu naloge).
• Stran s pregledom oddanih del za posamezno nalogo
Zaslon profesorjem za izbrano nalogo omogo£a tabelari£ni pregled ²tudentov, ki
so nalogo oddali. S klikom na vnos se odpre novo okno z vnesenimi odgovori.
Pod nalogo se prikaºe dodatno polje, kamor lahko profesor vnese komentar. Ta
komentar se nato prikaºe na nalogi, £e jo ²tudent odpre po tem, ko je bila naloga
ºe zaklju£ena.
Poglavje 4
Izdelava aplikacije
V tem poglavju bom opisal izdelavo aplikacije. Najprej bom opisal orodja, ki sem jih
pri razvoju uporabil, nato pa podrobno ²e zgradbo aplikacije.
4.1 Orodja
Pri izbiri orodja sem se osredoto£il na tista, ki sem jih ºe spoznal v £asu ²tudija in
²tudentskega dela.
4.1.1 Razvojna okolja
Zaradi dobrega poznavanja programskega jezika JAVA sem izbiral med orodjema
Eclipse in Netbeans. Z obema sem se ºe sre£al v £asu ²tudentskega dela. Obe orodji
sta brezpla£ni in imata dobro podporo. Vsako ima svoje prednosti in slabosti.
Eclipse
Prva verzija orodja je iz²la ºe leta 2004 z oznako Eclipse 3.0. Nova edicij od takrat iz-
ide vsak junij. Do danes je iz²lo ºe 13 edicij. Leto²nja se imenuje Neon (Eclipse, 2016).
27
28 Izdelava aplikacije
Slika 4.1: Okno Eclipse IDE
Eclipse je eno bolj priljubljenih razvojnih okolij, saj omogo£a razvoj v ²tevilnih pro-
gramskih jezikih. Nekateri od njih so:
• Java,
• C/C++,
• Python,
• Ruby,
• Perl,
• Fortran,
• COBOL,
• PHP,
• JavaScript.
Poleg zgoraj na²tetih pa omogo£a ²e pisanje dokumentov LaTeX s pomo£jo vti£nikov.
4.1 Orodja 29
Distribucija Eclipsa vklju£uje kar nekaj osnovnih verzij aplikacijskih streºnikov, glavni
med njimi je Apache Tomcat. Dodatno omogo£a ²e enostaven prenos in namestitev
drugih popularnih streºnikov za poganjanje aplikacij, razvitih v razli£nih programskih
jezikih.
Zaradi popularnosti orodja obstaja veliko ²tevilo vti£nikov, ki razvijalcu olaj²ajo delo.
Poleg vti£nikov pa obstaja ²e veliko prilagojenih orodij, ki izhajajo iz Eclipse oziroma
je to njihovo ogrodje. Nekateri od njih so:
• Adobe Flash builder � Orodje za razvoj Flash aplikacij.
• Aptana � Orodje za razvoj spletnih aplikacij.
• IBM Rational distribucije � Orodje za razvoj aplikacij v okoljih IBM. Po-
sebnost teh edicij je, da imajo prilagojene elemente in knjiºnice, ki so testno
povezani s produkti IBM, kot so Lotus Notes, IBM Websphere Aplication Ser-
ver, IBM Websphere Portal in drugi.
Povezava s podjetjem IBM ni naklju£je, saj je ekipa IBM sodelovala pri razvoju
prve verzije orodja.
• XMind � Orodje za izdelavo diagramov in miselnih vzorcev.
Seznam je dostopen na povezavi https://en.wikipedia.org/wiki/List_of_Eclipse-based_software.
Eno od teh orodij je tudi ZK studio, ki je namenjen razvoju aplikacij v program-
skem ogrodju ZK. Za enostavnej²i razvoj gra�£nega vmesnika orodje ponuja paleto
elementov, ki jih na na£in "povleci in spusti"postavimo na stran.
Namen teh orodij je, da uporabniku poenostavijo izdelavo aplikacij.
Netbeans
Alternativa Eclipsu je orodje Netbeans. Orodje je nastalo leta 1996 kot ²tudentski
projekt. Leta 1999 ga je kupilo podjetje SUN, ki ga je junija leta 2000 objavilo kot
odprtokodni sistem (Wikipedia, 2016b).
Tako kot Eclipse verzije orodja NetBeans izhajajo ve£inoma do dvakrat na leto in
30 Izdelava aplikacije
s tem skrbijo za odpravo napak ter dodajanje vedno novih funkcionalnosti (Netbe-
ans, 2016b).
Slika 4.2: Okno Netbeans IDE
Omogo£a razvoj v naslednjih programskih jezikih:
• Java (Web in EE),
• C/C++,
• PHP ,
• Groovy.
Na spletni strani ponujajo razli£ne verzije sistema glede na programski jezik razvoja.
Najobseºnej²i distribucijski paket, ki obsega vse funkcionalnosti, vklju£uje aplikacij-
ska streºnika Apache Tomcat in GlassFish (Netbeans, 2016a).
Ker gre za odprtokodno orodje, za NetBeans obstaja veliko ²tevilo uradnih in ne-
uradnih vti£nikov in knjiºnic, ki jih lahko sami namestimo v sistem in nam olaj²ajo
delo. Eden od teh vti£nikov je REM � modul za ZK, ki tako kot ZK studio ponuja
4.1 Orodja 31
paleto elementov za enostavnej²o izdelavo in razvoj gra�£nih vmesnikov in zalednih
funkcionalnosti.
4.1.2 Streºni²ka infrastruktura
• Apache Tomcat
Za aplikacijski streºnik sem izbral Apache Tomcat. Streºnik je tako del distri-
bucije Eclipse kot distribucije NetBeans in zado²£a za razvoj. Za produkcijsko
verzijo aplikacije za moºnosti vodenja kontrole nad izvajanjem aplikacije pa pre-
dlagam katero bolj celovito re²itev, kot je na primer Oracle Weblogic ali RedHat
JBoss. Slednja omogo£ata veliko ve£ funkcionalnosti ter gra�£ni vmesnik, ki
olaj²a pregled delovanja name²£enih aplikacij.
Apache Tomcat sicer prav tako omogo£a vpogled v delovanje aplikacij, ven-
dar ima le spletni gra�£ni vmesnik, ki je dokaj okoren in ne ponuja enostavnega
pregleda dogajanja. Zato se raje kot na spletni vmesnik zatekamo k pregledo-
vanju dnevni²kih datotek, ki jih poleg osnovnih dogodkov lahko polnimo tudi
sami s pomo£jo klicev dolo£enih metod v na²i aplikaciji.
Slika 4.3: GUI-vmesnik za streºnik Apache Tomcat
32 Izdelava aplikacije
• XAMPP Orodje, ki sem si ga izbral za poganjanje programske opreme po-
datkovne baze, je XAMPP. Kratica XAMPP pomeni �ross-patform Apache
MySQL PHP Perl". Orodje je mogo£e namestiti na razli£ne operacijske sisteme
in se uporablja za poganjanje spletnega streºnika Apache za spletna programska
jezika PHP in Perl ter za poganjanje podatkovnih baz MySQL (Friends, 2016).
Slika 4.4: Nadzorna plo²£a orodja XAMPP
Uporabil sem ga zato, ker omogo£a poganjanje podatkovnih baz MySQL. Ta-
k²na oblika dela mi je pohitrila delo, saj je orodje samo namestilo vse potrebno,
da sem podatkovne baze lahko pri£el uporabljati. V nasprotnem primeru bi
imel veliko dela s samo kon�guracijo podatkovne baze.
XAMPP je namenjen hitremu razvoju spletnih aplikacij in zato vklju£uje nekaj
osnovnih orodij, ki uporabniku olaj²ajo delo. Eno od teh orodij je orodje za
upravljanje podatkovnih baz phpMyAdmin. S pomo£jo modula Bitnami for
XAMPP pa omogo£imo, da lahko na orodje namestimo enega od popularnih
sistemov CMS in LMS ter druge uporabne spletne aplikacije (Bitnami, 2016).
Kljub zmogljivosti pa je streºnik namenjen razvoju in za uporabo kot produkcij-
ski streºnik, saj ne omogo£a avtomatskega posodabljanja posameznih elementov
in jih je potrebno posodobiti ro£no.
4.1 Orodja 33
4.1.3 Orodje za upravljanje podatkovnih baz
• phpMyAdmin
Orodje je del sistema XAMPP in omogo£a urejanje podatkov in strukture v
podatkovni bazi MySQL. PhpMyAdmin je spletna aplikacija, napisana v pro-
gramskem jeziku PHP in jo poganja aplikacijskih streºnik Apache.
Slika 4.5: Okno phpMyAdmin
Orodje je ºe nastavljeno in razvijalcu prihrani £as, ki bi ga zapravil z nasta-
vljanjem orodja. Pregleden in bogat uporabni²ki vmesnik uporabniku omogo£a
enostavno upravljanje podatkovnih baz. Tu lahko ureja strukturo posamezne
baze, ustvarja nove tabele, izvaja poizvedbe in ukaze SQL, upravlja uporabnike
in ²e mnogo drugih operacij.
• MySQL Workbench
Orodje je, tako kot phpMyAdmin, namenjeno pregledu in urejanju podatkovnih
baz MySQL. Poleg osnovnih operacij, kot so urejanje strukture podatkovne baze
ali sheme, izvajanje poizvedb in ukazov SQL, upravljanje uporabnikov in drugih
operacij, sistem omogo£a tudi naprednej²e operacije. To so:
� izdelava vizualizacije podatkovnega modela (model EER),
� migracija baze MySQL z enega streºnika na drugega,
� izvoz/uvoz baze,
� varnostno kopiranje baze,
� izdelava podatkovnega modela na podlagi obstoje£e baze oziroma tako
imenovani "Reverse engineering".
34 Izdelava aplikacije
Slika 4.6: Okno MySQL Workbench
Orodje mi je pomagalo pri izdelavi podatkovnega modela. Z njegovo pomo-
£jo sem si laºje predstavljal, katere tabele so soodvisne med seboj in po katerih
poljih jih lahko zdruºim. Z orodjem sem nato na podlagi vizualne sheme podat-
kovnega modela izdelal skript, s katerim sem nato na podatkovni bazi ustvaril
vse potrebne objekte.
4.1.4 Orodje za gra�£no oblikovanje
4.1.5 Programske knjiºnice
• ZK
ZK je ogrodje, ki vsebuje paleto ºe pripravljenih elementov, ki jih razvijalec
enostavno uvrsti na stran. Ogrodje temelji na programskem jeziku JAVA in
spletnem jeziku HTML in je namenjeno izdelavi spletnih aplikacij. Glavne la-
stnosti orodja:
� enostavni klici AJAX,
� vsebuje lastni UML (enotni jezik za modeliranje),
� uporabni²ki vmesnik je napisan v programskem jeziku JAVA,
� enostavno povezovanje spleta s podatkovno bazo (skriti klici AJAX in
JSON),
4.2 Podatkovni model 35
� lastni elementi za risanje grafov, prikaz tabel, razpredelnic in koledarja,
� veliko ²tevilo gradnikov,
� ²iroka podpora za brskalnike,
� ²tevilni prevodi v tuje jezike.
Na uradni spletni strani je poleg opisanih gradnikov tudi veliko ²tevilo prime-
rov z izvorno kodo, na podlagi katere lahko gradnike vklju£i² v svojo spletno
aplikacijo.
Dobra podpora pripomore k temu, da ga uporablja veliko ²tevilo znanih in
manj znanih podjetij, saj je poleg proste oz. brezpla£ne verzije CE (£ommunity
edition") na voljo tudi pla£ljiva verzija EE ("enterprise edition") za podjetja,
ki vklju£uje z dodatno podporo in prilagoditve.
• docx4j
Docx4j je odprtokodna javanska knjiºnica, ki se uporablja za ustvarjanje in
manipuliranje dokumentov DOCX, PPTX in XLSX, ki bi jih sicer izdelali s
pomo£jo orodja Micorosoft O�ce. Knjiºnica se v aplikaciji uporablja za tiskanje
u£nih priprav in poro£il o hospitirani uri.
• mysql-connector
Knjiºnica se uporablja za povezovanje zalednega sistema s podatkovno bazo in
izvajanje operacij. Povezava z bazo je potrebna za vnos novih podatkov ter
pridobitev podatkov za izpis na strani.
4.2 Podatkovni model
Podatkovni model sem ustvaril s pomo£jo orodja MySQL Workbench. Z orodjem se
izdelal model EER in ga nato izvozil v slikovni zapis PNG. S pomo£jo istega orodja
sem na podlagi modela nato ustvaril skript SQL, ki je na podatkovni bazi nato ustvaril
vse objekte. Relacije med objekti so podrobneje prikazane v Prilogi 2 na sliki 6.1.
4.2.1 Opis tipov
• Uporabniki: Tu so shranjeni uporabniki aplikacije. Vsak uporabnik je enoli£no
dolo£en z identi�katorjem, ki je v primeru ²tudentov vpisna ²tevilka, v primeru
36 Izdelava aplikacije
profesorjev pa mati£na ²tevilka ali druga enoli£na oznaka, pomembno je le, da
se nobeden od identi�katorjev ne ponovi.
• Uporabni²ka skupina: Tu so shranjeni podatki o uporabni²ki skupini.
• Profesorji: Tu so shranjeni osnovni podatki o profesorjih. Vnosi so preko polja
identi�kator povezani z entiteto Uporabniki.
• �tudentje: Tu so shranjeni osnovni podatki o ²tudentih. Vnosi so preko polja
identi�kator povezani z entiteto Uporabniki.
• �tudijski program: Tu se nahajajo nazivi ²tudijskih programov.
• Predmet: Tu so shranjeni podatki o predmetu. Vnosi so povezani z entitetama
Profesorji in �tudentje preko vmesnih tabel.
• Hospitacija: Tu so shranjeni podatki o hospitirani uri. Podatki, ki se vna²ajo,
opisujejo hospitirano uro, kdo je uro izvajal in temo ure. Vnosi so preko polja
identi�kator povezani z entiteto Uporabniki.
• Vidik A: Tu so shranjeni podatki o opisu ure. Podatki so povezani s podatki
v entiteti Hospitacija preko polja identi�kator.
• Vidik B: Tu so shranjeni podatki vezani na u£ni vidik, ki smo ga med uro
opazovali. Podatki povezani s podatki v entiteti Hospitacija preko polja iden-
ti�kator.
• U£na priprava: Tu so shranjeni podatki, ki zdruºujejo entitete, vezane na
podatke o u£ni pripravi in entiteto Uporabniki
• Podatki o uri: Tu so shranjeni podatki o uri u£ne priprave. Entiteta je preko
polja identi�kator povezana z entiteto U£na priprava.
• Cilji ure: Tu se hranijo cilji ure. Podatki so povezani z entiteto Podatki o
uri. Vsaka u£na priprava ima tu lahko ve£ kot en vnos.
• Zgradba ure: V tabeli Pregled ure se hranijo podatki o zgradbi ure za namen
£asovne razdelitve poteka. Vsaka u£na priprava ima v tej tabeli lahko ve£ kot en
vnos. Podatki se v aplikaciji prikazujejo tabelari£no glede na vrstni red vnosa.
4.3 Zgradba aplikacije 37
• Podrobni pregled ure: V tabeli Podrobni pregled ure se hranijo podrobni
podatki o zgradbi ure za namen £asovne razdelitve poteka in tabelske slike.
Vsaka u£na priprava ima v tej tabeli lahko ve£ kot en vnos. Podatki se v
aplikaciji prikazujejo tabelari£no glede na vrstni red vnosa.
• Naloge: Tu se hranijo osnovni podatki naloge in se preko polja identi�kator
uporabnika povezujejo z entiteto Uporabnik. Preko polja identi�kator pred-
meta pa se vnos poveºe z entiteto Predmet. Namen tega je, da se vsaka naloga
prikazuje le za to£no dolo£en predmet v sistemu in s tem to£no dolo£eni skupini
uporabnikov.
• Elementi naloge: Tu se hrani struktura posamezne naloge. Vsak vnos v
entiteti Naloge ima v tej tabeli lahko ve£ elementov. Podatki se v aplikaciji
prikazujejo tabelari£no glede na vrstni red vnosa. Za namen povezovanja z
entiteto Naloge pa se tu hrani ²e podatek identi�kator naloge.
• Oddane naloge: Ko se posamezna naloga aktivira, se za ta vnos v entiteti
Naloge ustvari nova tabela, ki ima stolpce enake strukturi v entiteti Elementi
naloge. Poleg teh stolpcev se tu hrani ²e podatek o identi�katorju uporab-
nika. Vsak uporabnik ima v tej tabeli lahko le en vnos.
Podrobnej²i opis entitetnega modela je predstavljen v Prilogi 2.
4.3 Zgradba aplikacije
4.3.1 Drevesna struktura datotek
Aplikacija vsebuje kon�guracijske datoteke, datoteke za uporabni²ki vmesnik in da-
toteke za zaledni sistem. Uporabni²ki vmesnik je spletna aplikacija, v zaledju pa se
izvaja javanska koda. Struktura in organizacija teh datotek sta predstavljeni v Prilogi
1.
Pri programskih razredih sem jih poizkusil poimenovati glede na njihovo vlogo in
na ta na£in zadostiti organizaciji, spletne datoteke pa sem razvrstil v mape glede na
njihov namen.
38 Izdelava aplikacije
4.3.2 Prijavno okno
Slika 4.7: Prijavno okno
Prijavno okno vsebuje vnosna polja za vpis uporabni²kega imena in gesla. Po kliku
na gumb Prijava se izvede klic AJAX na streºnik, kjer se preveri pravilnost oziroma
veljavnost kombinacije. To se stori tako, da se najprej vzpostavi povezava povezava s
podatkovno bazo in preveri ali v entiteti Uporabniki obstaja vnesena kombinacija.
�e ta obstaja, se v sejo uporabnika zapi²e njegov identi�kator in identi�kator upo-
rabni²ke skupine. Glede na uporabni²ko skupino se nato prikaºe prva stran in naloºi
ustrezni meni.
4.3.3 Povezovanje na bazo
Za povezovanje na bazo sem izdelal programski razred database. Objekt tega ra-
zreda kot atribut hrani povezavo na bazo. Povezava je javanskega tipa Connection.
Metoda, ki povezavo nastavi, je openDB. V to metodo se po²lje parametre uporabni-
²ko ime, geslo in URL povezava do podatkovne baze.
Po vzpostavljeni povezavi se pokli£e metoda Statement s parametri sql/string, sql
poizvedba in parametri sql poizvedbe. Ta metoda nato kot rezultat vrne rezultat me-
tode Prepare, ki kot rezultat vrne javanski objekt PreparedStatement. V metodo lahko
vnesemo bodisi celoten SQL-stavek ali pa le identi�kator in to ozna£imo z Boolovo
kombinacijo sql/string. �e smo v metodo poslali identi�kator SQL-stavka, se pokli£e
²e metoda getSqlString objekta sqlStavki, ki vrne ºeleno SQL-poizvedbo. V objektu
4.3 Zgradba aplikacije 39
sqlStavki se hranijo SQL-stavki za poizvedbe in SQL-stavki za manipulacijo s po-
datki.
SQL-stavek se nato poºene skupaj s podatki v spremenljivki parametri sql poizvedbe,
ki se vna²a kot mnoºica.
Po rezultatu poizvedbe se nato sprehajamo s kazalci.
Drugi na£in za pridobivanje podatkov iz podatkovne baze pa je uporaba programskih
predstavitev entitet. Ti razredi zdruºujejo vse moºne SQL-klice za izbrano entiteto.
4.3.4 Meni
Meni za profesorje
Slika 4.8: Meni za profesorje
Meni je razdeljen na tri podmenije:
• Datoteke: V podmeniju se nahajajo povezave do strani za izdelavo nove u£ne
priprave, strani za izdelavo nove hospitacije, strani s pregledom vseh u£nih
priprav profesorja in strani s pregledom vseh hospitacij profesorja. Poleg teh
povezav se v podmeniju nahajata ²e gumb za tiskanje in gumb za odjavo.
Gumb tiskanje se omogo£i na strani za vnos in urejanje u£ne priprave in na
strani za vnos in urejanje hospitacije.
S klikom na gumb Odjava se uporabnikova seja odstrani s streºnika in izpi²e iz
aplikacije tako, da zahteva ponovno prijavo.
• Naloge:
V podmeniju se nahajata povezavi do strani za izdelavo nove naloge in strani s
seznamom vseh nalog, ki jih je profesor ustvaril.
40 Izdelava aplikacije
• Pomo£:
V podmeniju se nahajata povezava za pomo£ in gumb za prikaz podatkov o
aplikaciji.
S klikom na povezavo Pomo£ se odpre povezava za elektronsko po²to na elek-
tronski naslov za podporo aplikacije.
S klikom na povezavo O programu pa se odpre prikazno okno, ki vsebuje osnovne
podatke o aplikaciji.
Meni za ²tudente
Slika 4.9: Meni za ²tudente
Meni je razdeljen na tri podmenije:
• Datoteke: V podmeniju se nahajajo povezave do strani za izdelavo nove u£ne
priprave, strani za izdelavo nove hospitacije. Poleg teh povezav se v podmeniju
nahaja ²e gumb za tiskanje in gumb za odjavo.
Gumb tiskanje se omogo£i na strani za vnos in urejanje u£ne priprave in na
strani za vnos in urejanje hospitacije.
S klikom na gumb Odjava se uporabnikova seja odstrani s streºnika in izpi²e iz
aplikacije tako, da zahteva ponovno prijavo.
• Pregled:
V podmeniju se nahajajo povezave do strani s pregledom vseh u£nih priprav
²tudenta, strani s pregledom vseh hospitacij ²tudenta in strani vseh nalog pred-
meta.
• Pomo£:
V podmeniju se nahaja povezava za pomo£ in gumb za prikaz podatkov o apli-
kaciji.
S klikom na povezavo Pomo£ se odpre povezava za elektronsko po²to na elek-
tronski naslov za podporo aplikacije.
4.3 Zgradba aplikacije 41
S klikom na povezav O programu pa se odpre prikazno okno, ki vsebuje osnovne
podatke o aplikaciji.
4.3.5 Vstopna stran
Slika 4.10: Vstopna stran
Vstopna stran je namenjena prikazu hitrih povezav do strani s pregledom vseh u£nih
priprav ²tudenta, strani s pregledom vseh hospitacij ²tudenta in strani vseh nalog
predmeta. Ta stran je enaka za profesorje in ²tudente.
4.3.6 Hospitacija
Aplikacija vsebuje dva tipa strani, vezanih na hospitacije. Prvi tip je vnosni obrazec,
drugi pa je stran s seznamom. Razredi, ki se tu uporabijo, so:
• Hospitacije: To je programska predstavitev entitete (entitetni razred) Hospi-
tacije v podatkovni bazi. Vklju£uje osnovne funkcije za nastavljanje parame-
trov hospitacije. S pomo£jo metode shrani pa se naredi nov vnos v bazo.
• HospitacijeJpaController: je avtomatsko ustvarjen JPA-upravitelj za enti-
tetoHospitacije. Tu so dodane funkcije za kreiranje seznamov za prikaz vnosov
v tej entiteti.
• HospitacijaVidikaA: in HospitacijaVidikAJpaController: To sta pro-
gramska entitentna razreda in JPA-upravitelj entiteteVidik A. Tu so shranjene
osnove funkcije in metode, ki laj²ajo in pohitrijo delo z entiteto. Avtomatsko
ustvarjenim poizvedbam in funkcijam lahko dodamo svoje.
42 Izdelava aplikacije
• HospitacijaVidikaB: in HospitacijaVidikBJpaController: To sta pro-
gramska entitentna razreda in JPA-upravitelj entiteteVidik B. Tu so shranjene
osnove funkcije in metode, ki laj²ajo in pohitrijo delo z entiteto. Avtomatsko
ustvarjenim poizvedbam in funkcijam lahko dodamo svoje.
• Hospitacija: To je razred za povezovanje zalednega sistema z obrazcem za
vnos. �e gre za shranjevanje hospitacije, se iz vnosnega obrazca preberejo vsi
vneseni podatki, na podlagi katerih se ustvari nov objekt entitetnega razreda.
S pomo£jo JPA-upravitelja pa se nato ta novi objekt pretvori v novi vnos v
entiteto na podatkovni bazi. �e objekt ºe obstaja, pa se ta le posodobi.
V nasprotnem primeru, £e uporabnik ºeli odpreti ºe obstoje£o hospitacijo, se na
podlagi identi�katorja hospitacije, ki ga aplikacija pridobi iz uporabnikove seje,
ustvari nov entitetni razred glede na podatke iz podatkovne baze za ta identi�-
kator. Podatki iz tega objekta se nato prenesejo v vnosna polja na obrazcu za
vnos.
• VidikA: To je razred za povezovanje zalednega sistema z obrazcem za vnos
podatkov o opisu ure hospitacije. Funkcionalnosti tega razreda so enake kot v
razredu Hospitacija, le da se tu upravlja entiteta Vidik A.
• VidikB: To je razred za povezovanje zalednega sistema z obrazcem za vnos
podatkov o opazovanem vidiku. Funkcionalnosti tega razreda so enake kot v
razredu Hospitacija, le da se tu upravlja entiteta Vidik B.
• HospitacijaPrint: To je razred, ki je namenjen pretvarjanju vnesenih podat-
kov o hospitaciji v tekstovno obliko za namen tiskanja. Za tiskanje se uporablja
knjiºnica docx4j. Ker je za kreiranje posameznega elementa v tekstovnem ele-
mentu kar veliko programske kode, sem za laºjo organizacijo pripravil podporna
programska razreda docx4jhelper in TableCell, s katerima sem ve£ji del program-
ske kode zapakiral v funkcije. Na ta na£in za kreiranje posameznega elementa
pokli£em le eno od funkcij z ºelenimi parametri. Elementi so lahko naslovi,
tekst, tabele, pod£rtovanje, na²tevanje in podobno.
Za izbrane entitete entitetne razrede in JPA upravitelje avtomatsko ustvari IDE-
urejevalnik glede na povezavo na podatkovno bazo in entitete. Pri njihovi izdelavi
nam pomaga enostavni vmesnik, ki je del IDE-urejevalnika.
4.3 Zgradba aplikacije 43
Obrazec za vnos
• Vnos osnovnih podatkov o uri: Tu se nahajajo vnosna polja, kjer se vnesejo
vsi osnovni podatki. Za navigacijo med vnosnimi obrazci se na dnu obrazca
nahajata gumba Zapri in Nadaljuj.
Ob kliku na gumb Nadaljuj se preverijo obvezni podatki. �e so vsi ti podatki
vneseni, se izvede nov zapis v bazo in odpre korak dva. Zaradi enostavnosti
vnosa je trenutno edini obvezni podatek Naslov ure.
Ob kliku na gumb Zapri pa se, £e imamo vnesene neshranjene podatke, odpre
pojavno okno, ki nas spra²uje, ali ºelimo hospitacijo shraniti. �e to potrdimo, se
izvede enaka akcija kot na gumbu Nadaljuj, le da se tu po shranjevanju obrazec
zapre. Hospitacijo lahko nato kadar koli urejamo.
• Vnos opisa ure: Tu se nahajajo vnosna polja za vnos odgovorov na vpra²anja
glede opisa ure. Za navigacijo med vnosnimi obrazci se na dnu obrazca nahajajo
gumbi Nazaj, Zapri in Nadaljuj. Ob kliku na gumb Nadaljuj se izvede nov zapis
v bazo in odpre tretji korak. Zaradi enostavnosti vnosa tu ni obvezen noben
podatek.
Ob kliku na gumb Zapri pa se, £e imamo vnesene neshranjene podatke, odpre
pojavno okno, ki nas spra²uje, ali ºelimo hospitacijo shraniti. �e to potrdimo, se
izvede enaka akcija kot na gumbu Nadaljuj, le da se tu po shranjevanju obrazec
zapre. Hospitacijo lahko nato kadar koli urejamo.
Ob kliku na gumb Nazaj nas v primeru, da imamo vnesene neshranjene podatke,
aplikacija na to opozori. �e potrdimo to opozorilo, nas sistem preusmeri nazaj
na korak za vnos osnovnih podatkov ure.
• Vnos podatkov v zvezi z opazovanim vidikom: Tu se nahajajo vnosna
polja za vnos odgovorov na vpra²anja glede opazovanega vidika. Za navigacijo
med vnosnimi obrazci in shranjevanje hospitacije se na dnu obrazca nahajajo
gumbi Nazaj, Zapri in Shrani. Ob kliku na gumb Shrani se izvede nov zapis v
bazo.
Ob kliku na gumb Zapri pa se, £e imamo vnesene ne shranjene podatke, odpre
pojavno okno, ki nas spra²uje, ali ºelimo hospitacijo shraniti. �e to potrdimo,
se izvede enaka akcija kot na gumbu Shrani, le da se tu po shranjevanju obrazec
zapre. Hospitacijo lahko nato kadar koli urejamo.
Ob kliku na gumb Nazaj nas v primeru, da imamo vnesene ne shranjene po-
datke, aplikacija na to opozori. �e potrdimo to opozorilo, nas sistem preusmeri
44 Izdelava aplikacije
nazaj na korak za vnos opisa ure.
Zaslonske slike in seznam vnosnih polj se nahajajo v Prilogi 3.
Stran s seznamom hospitacij
Datoteka /WebObrazci/Hospitacija/Preged.zul. Stran ponuja seznam shranjenih ho-
spitacij, razvr²£enih glede na datum hospitirane ure. Vsak vnos poleg datuma prika-
zuje ²e naslov ure. S klikom na vnos v seznamu se odpre stran za vnos in urejanje
hospitacije.
Slika 4.11: Stran s seznamom hospitacij
4.3.7 U£na priprava
Aplikacija vsebuje dva tipa strani, vezanih na u£ne priprave. Prvi tip je vnosni obra-
zec, drugi pa je stran s seznamom. Pri pisanju kode za ta tip vsebin sem uporabil
druga£en pristop k izdelavi. Programske razrede sem pripravil brez pomo£i IDE-
urejevalnika. Gre za starej²o kodo, saj sem jo pripravil pred kodo za hospitacije, kjer
mi je IDE-urejevalnik razrede ustvaril na podlagi entitet v podatkovni bazi. Tu na-
mesto JPA-upravitelja vnose v podatkovno bazo izvajam s pomo£jo SQL-stavkov iz
programskega razreda sqlSavki in javanskega objekta PreparedStatement, ki prepre£i
vnos SQL-kode, ki bi lahko kakor koli ²kodovala aplikaciji ali pa bi povzro£ila nepo-
obla²£en dostop do storitev. Tem SQL-poizvedbam se re£e tudi �QL Injection".
Razredi, ki se tu uporabijo, so:
4.3 Zgradba aplikacije 45
• UcnaPriprava: Tu se nahajajo funkcije in metode, ki upravljajo entitetoU£na
priprava, entiteto Cilji ure in entiteto Dodatne dejavnosti. Metode, ki
se tu nahajajo, so metoda za shranjevanje vnosa glede na vnesene podatke,
polnjenje obrazca v primeru, da se u£na priprava odpre za urejanje, in metoda
za preverjanje obveznih polj. Za upravljanje podatkov v podatkovni bazi se
uporabljata programski razred database in metoda Statement. SQL-stavki pa
se pridobijo s pomo£jo metode v programskem razredu slqStavki.
• PregledUre: To je razred za objekt vnosa v entiteti Zgradba ure v podat-
kovni bazi. Vklju£uje osnovne funkcije za nastavljanje parametrov posameznega
elementa. Razred nato uporabimo za kreiranje novih objektov tega tipa.
• PregledUrePodatki: Tu se nahajajo funkcije in metode, ki upravljajo objekt
iz razreda PregledUre. Metode, ki se tu nahajajo, so metoda za shranjevanje
vnosa glede na vnesene podatke, polnjenje obrazca v primeru, da se klikne na
vnos v tabeli, in metoda za preverjanje obveznih polj. Za upravljanje podatkov
v podatkovni bazi se uporabljata programski razred database in metoda Sta-
tement. SQL-stavki pa se pridobijo s pomo£jo metode v programskem razredu
slqStavki.
• PregledUreRender: Tu se nahajajo metode za upravljanje tabelari£ne pred-
stavitve vnosov. Tabela se uredi s pomo£jo ZK-elementa Grid. Metoda render
za vsak rezultat SQL-poizvedbe ustvari po eno vrstico s podatki glede na po-
izvedbo in ustvari sledenje klikov na tej vrstici. V primeru klika na vrstico se
napolnijo podatki v obrazcu za urejanje vnosa.
• PodrobniPregled: To je razred za objekt vnosa v entiteti Podrobni pregled
ure v podatkovni bazi. Vklju£uje osnovne funkcije za nastavljanje parametrov
vnosa. Razred nato uporabimo za kreiranje novih objektov tega tipa.
• PodrobniPregledPodatki: Tu se nahajajo funkcije in metode, ki upravljajo
objekt iz razreda PodrobniPregled. Metode, ki se tu nahajajo, so metoda za
shranjevanje vnosa glede na vnesene podatke, polnjenje obrazca v primeru, da se
klikne na vnos v tabeli, in metoda za preverjanje obveznih polj. Za upravljanje
podatkov v podatkovni bazi se uporabljata programski razred database in me-
toda Statement. SQL-stavki pa se pridobijo s pomo£jo metode v programskem
razredu slqStavki.
46 Izdelava aplikacije
• PodrobniPregledRender: Tu se nahajajo metode za upravljanje tabelari£ne
predstavitve vnosov. Tabela se uredi s pomo£jo ZK-elementa Grid. Metoda
render za vsak rezultat SQL-poizvedbe ustvari po eno vrstico s podatki glede
na poizvedbo in ustvari sledenje klikov na tej vrstici. V primeru klika na vrstico
se napolnijo podatki v obrazcu za urejanje vnosa.
• PripravaPrint: To je razred, ki je namenjen pretvarjanju vnesenih podatkov
u£ne priprave v tekstovno obliko za namen tiskanja. Za tiskanje se uporablja
knjiºnica docx4j. Ker je za kreiranje posameznega elementa v tekstovnem ele-
mentu kar veliko programske kode, sem za laºjo organizacijo pripravil podporna
programska razreda docx4jhelper in TableCell, s katerima sem ve£ji del program-
ske kode zapakiral v funkcije. Na ta na£in za kreiranje posameznega elementa
pokli£em le eno od funkcij z ºelenimi parametri. Elementi so lahko naslovi,
tekst, tabele, pod£rtovanje, na²tevanje in podobno.
Za izbrane entitete entitetne razrede in JPA upravitelje avtomatsko ustvari IDE-
urejevalnik glede na povezavo na podatkovno bazo in entitete. Za izdelavo teh nam
pomaga enostavni vmesnik, ki je del IDE-urejevalnika.
Obrazec za vnos
• Vnos osnovnih podatkov ure: Tu se nahajajo vnosna polja, kjer se vnesejo
vsi osnovni podatki. Za vnos u£nih ciljev je omogo£eno dinami£no dodajanje
dodatnih vnosnih polj. Za navigacijo med vnosnimi obrazci se na dnu obrazca
nahajata gumba Zapri in Nadaljuj.
Ob kliku na gumb Nadaljuj se preverijo obvezni podatki. �e so vsi ti podatki
vneseni, se izvede nov zapis v bazo in odpre korak 2. �e niso vneseni vsi obvezni
podatki, se na zaslonu prikaºe obvestilo s seznamom polj, ki jih je ²e potrebno
vnesti.
Ob kliku na gumb Zapri pa se, £e imamo vnesene neshranjene podatke, odpre
pojavno okno, ki nas spra²uje, ali ºelimo u£no pripravo shraniti. �e to potrdimo,
se izvede enaka akcija kot na gumbu Nadaljuj, le da se tu po shranjevanju
obrazec zapre. U£no pripravo lahko nato kadar koli urejamo.
• Vnos zgradbe ure: Zgradbo ure prikazujemo tabelari£no. Vsak vnos v tabeli
na levi strani je en od vnosov v entiteti Zgradba ure. Prikaz tabele in akcija
nad vnosi se izvajata s programskim razredom PregledUreRender. V tabeli
4.3 Zgradba aplikacije 47
se za vsak vnos prikazujeta podatek o cilju in podatek o £asu, ki je potreben za
izvedbo. Pod tabelo se nahajata dva gumba za urejanje vrstnega reda vnosov.
Ob kliku na vrstico v tabeli se v vnosna polja na desni strani prenesejo vre-
dnosti vnosa iz podatkovne baze. Pod vnosnimi polji se nahajajo ²tirje gumbi,
namenjeni upravljanju podatkov v obrazcu. To so:
� Odstrani izbrano � S klikom na ta gumb odstranimo izbrani vnos.
� Posodobi izbrano � S klikom na ta gumb za izbrano vrstico posodobimo
podatke v podatkovni bazi.
� Vstavi kot novo � S klikom na ta gumb se v podatkovni bazi v entiteti
Zgradba ure ustvari nov vnos, v tabeli pa se prikaºe nova vrstica. Ta se
v tabeli doda na zadnje mesto.
� Po£isti polja � S klikom na ta gumb izpraznimo vsa vnosna polja.
Na dnu obrazca se nahajajo gumbi Nazaj, Zapri in Nadaljuj, ki so namenjeni
navigaciji med obrazci. Ob kliku na gumb Nadaljuj se izvede nov zapis v bazo
in odpre drugi korak.
Ob kliku na gumb Zapri pa se, £e imamo vnesene neshranjene podatke, odpre
pojavno okno, ki nas spra²uje, ali ºelimo u£no pripravo shraniti. �e to potrdimo,
se izvede enaka akcija kot na gumbu Nadaljuj, le da se tu po shranjevanju
obrazec zapre. U£no pripravo lahko nato kadar koli urejamo.
Ob kliku na gumb Nazaj nas v primeru, da imamo vnesene neshranjene podatke,
aplikacija na to opozori. �e potrdimo to opozorilo, nas sistem preusmeri nazaj
na korak za vnos osnovnih podatkov ure.
• Vnos podrobnega pregleda ure: Podrobni pregled ure prav tako prikazu-
jemo tabelari£no. Vsak vnos v tabeli na levi strani je en od vnosov v enti-
teti Podrobni pregled ure. Prikaz tabele in akcija nad vnosi se izvajata s
programskim razredom PodrobniPregledRender. V tabeli se za vsak vnos
prikazuje podatek o namenu dejavnosti. Pod tabelo se nahajata dva gumba za
urejanje vrstnega reda vnosov.
Ob kliku na vrstico v tabeli se v vnosna polja na desni strani prenesejo vre-
dnosti vnosa iz podatkovne baze. Pod vnosnimi polji se nahajajo ²tirje gumbi,
namenjeni upravljanju podatkov v obrazcu. To so:
� Odstrani izbrano � S klikom na ta gumb odstranimo izbrani vnos.
48 Izdelava aplikacije
� Posodobi izbrano � S klikom na ta gumb za izbrano vrstico posodobimo
podatke v podatkovni bazi.
� Vstavi kot novo � S klikom na ta gumb se v podatkovni bazi v entiteti
Podrobni pregled ure ustvari nov vnos, v tabeli pa se prikaºe nova
vrstica. Ta se v tabeli doda na zadnje mesto.
� Po£isti polja � S klikom na ta gumb izpraznimo vsa vnosna polja.
Na dnu obrazca se nahajajo gumbi Nazaj, Zapri in Nadaljuj, ki so namenjeni
navigaciji med obrazci. Ob kliku na gumb Nadaljuj se izvede nov zapis v bazo
in odpre drugi korak.
Ob kliku na gumb Zapri pa se, £e imamo vnesene neshranjene podatke, odpre
pojavno okno, ki nas spra²uje, ali ºelimo u£no pripravo shraniti. �e to potr-
dimo, se izvede enaka akcija kot na gumbu Nadaljuj, le da se tu po shranjevanju
obrazec zapre. U£no pripravo lahko nato kadar koli urejamo.
Ob kliku na gumb Nazaj nas v primeru, da imamo vnesene ne shranjene po-
datke, aplikacija na to opozori. �e potrdimo to opozorilo, nas sistem preusmeri
nazaj na korak za urejanje zgradbe ure.
• Vnos dejavnosti za u£no ²ibkej²e in u£no zmoºnej²e u£ence: Na tem
obrazcu se vna²ajo dejavnosti za u£no ²ibkej²e in u£no zmoºnej²e u£ence. Po-
datka se nahajata na enaki entiteti kot osnovni podatki ure. Na dnu obrazca se
nahajajo gumbi Nazaj, Zapri in Shrani, ki so namenjeni navigaciji med obrazci
in shranjevanju u£ne priprave. Ob kliku na gumb Shrani se izvede nov zapis v
bazo.
Ob kliku na gumb Zapri pa se, £e imamo vnesene neshranjene podatke, odpre
pojavno okno, ki nas spra²uje, ali ºelimo u£no pripravo shraniti. �e to potr-
dimo, se izvede enaka akcija kot na gumbu Shrani, le da se tu po shranjevanju
obrazec zapre. U£no pripravo lahko nato kadar koli urejamo.
Ob kliku na gumb Nazaj nas v primeru, da imamo vnesene ne shranjene po-
datke, aplikacija na to opozori. �e potrdimo to opozorilo, nas sistem preusmeri
nazaj na korak za urejanje podrobnega pregleda ure.
Zaslonske slike in seznam vnosnih polj se nahajajo v Prilogi 3.
4.3 Zgradba aplikacije 49
Stran s seznamom u£nih priprav
Datoteka /WebObrazci/Priprava/Pregled.zul. Stran ponuja seznam shranjenih u£nih
priprav, razvr²£enih glede na datum nastopa. Vsak vnos poleg datuma prikazuje ²e
naslov ure. S klikom na vnos v seznamu se odpre stran za vnos in urejanje u£nih
priprav.
Slika 4.12: Stran s seznamom u£nih priprav
4.3.8 Naloga
Aplikacija vsebuje ²tiri tipe strani, ki se nana²ajo na naloge.
1. tip je vnosni obrazec za izdelavo naloge.
2. tip je stran s seznamom nalog.
3. tip je stran z nalogo.
4. tip je seznam oddanih nalog za izbran tip naloge.
Pri pisanju kode za ta tip vsebin sem uporabil kombinacijo pristopov izdelave, kot
sem ju uporabil pri pisanju kode za u£ne priprave in hospitacije. S pomo£jo IDE-
urejevalnika sem izdelal entitetne razrede, nato pa sem sam pripravil neke vrste JPA-
upravitelje. Vnose v podatkovno bazo izvajam s pomo£jo SQL-stavkov iz program-
skega razreda sqlStavki in javanskega objekta PreparedStatement, ki prepre£i vnos
SQL-kode, ki bi lahko kakor koli ²kodovala aplikaciji ali pa bi povzro£ila nepoobla-
²£en dostop do storitev. Tem SQL-poizvedbam se re£e tudi �QL Injection".
Razredi, ki se tu uporabijo, so:
50 Izdelava aplikacije
• Naloge: Tu se nahajajo funkcije in metode, ki upravljajo entiteto Naloge.
Metode, ki se tu nahajajo, so metoda za shranjevanje vnosa glede na vnesene
podatke, polnjenje obrazca v primeru, da se nalogo odpre za urejanje, metoda
za preverjanje obveznih polj in metode za prikaz seznamov aktivnih, neaktivnih
in zaklju£enih nalog. Za upravljanje podatkov v podatkovni bazi se uporabljata
programski razred database in metoda Statement. SQL-stavki pa se pridobijo
s pomo£jo metode v programskem razredu slqStavki.
• Naloga: To je entitetni razred za entitetoNaloga v podatkovni bazi. Vklju£uje
osnovne funkcije za nastavljanje parametrov u£ne priprave. Entitetni razred
nato uporabimo za kreiranje novih objektov tega tipa.
• NalogaData: Tu se nahajajo konstruktorji objekta NalogaData, ki se nato
uporabijo v drugih razredih.
• NalogaViewModel: Tu se nahajajo funkcije za pridobivanje seznamov nalog
glede na njihov status. Rezultati teh funkcij se nato uporabljajo za izpis na
zaslon.
• ElementiN: To je razred za objekt vnosa v entiteti Elementi naloge v podat-
kovni bazi. Vklju£uje osnovne funkcije za nastavljanje parametrov posameznega
elementa. Razred nato uporabimo za kreiranje novih objektov tega tipa.
• ElementiNPodatki: Tu se nahajajo funkcije in metode, ki upravljajo objekt
iz razreda ElementiN. Metode, ki se tu nahajajo, so metoda za shranjevanje
vnosa glede na vnesene podatke, polnjenje obrazca v primeru, da se izbere kli-
kne na vnos v tabeli, in metoda za preverjanje obveznih polj. Za upravljanje
podatkov v podatkovni bazi se uporabljata programski razred database in me-
toda Statement. SQL-stavki pa se pridobijo s pomo£jo metode v programskem
razredu slqStavki.
• ElementiNRender: Tu se nahajajo metode za upravljanje tabelari£ne pred-
stavitve vnosov. Tabela se uredi s pomo£jo ZK-elementa Grid. Metoda render
za vsak rezultat SQL-poizvedbe ustvari po eno vrstico s podatki glede na po-
izvedbo in ustvari sledenje klikov na tej vrstici. V primeru klika na vrstico se
napolnijo podatki v obrazcu za urejanje vnosa.
• OddaneNal: To je razred za objekt vnosa v entiteti Oddane naloge v po-
datkovni bazi. Vklju£uje osnovne funkcije za nastavljanje parametrov vnosa.
Razred nato uporabimo za kreiranje novih objektov tega tipa.
4.3 Zgradba aplikacije 51
• OddaneNalPodatki: Tu se nahajajo funkcije in metode, ki upravljajo objekt
iz razreda OddaneNal. Metoda, ki se tu nahaja, je metoda za osveºevanje
seznama oddanih nalog za izbrani tip naloge. Za upravljanje podatkov v po-
datkovni bazi se uporabljata programski razred database in metoda State-
ment. SQL-stavki pa se pridobijo s pomo£jo metode v programskem razredu
slqStavki.
• OddaneNalRender: Tu se nahajajo metode za upravljanje tabelari£ne pred-
stavitve vnosov. Tabela se uredi s pomo£jo ZK-elementa Grid. Metoda render
za vsak rezultat SQL-poizvedbe ustvari po eno vrstico s podatki glede na po-
izvedbo in ustvari sledenje klikov na tej vrstici. V primeru klika na vrstico se
napolnijo podatki v obrazcu za urejanje vnosa.
Obrazec za izdelavo naloge
Do tega pogleda lahko dostopajo le profesorji. Zgradbo naloge prikazujemo tabela-
ri£no. Vsak vnos v tabeli na levi strani je en od vnosov v entiteti Elementi naloge.
Prikaz tabele in akcijo nad vnosi se izvaja s programskim razredom ElementiNRen-
der. V tabeli se za vsak vnos prikazujeta podatek o identi�katorju komponente v
vrstnem redu, kot se morajo prikazovati. Pod tabelo se nahajata dva gumba za ure-
janje vrstnega reda vnosov.
Ob kliku na vrstico v tabeli se v vnosna polja na desni strani prenesejo vrednosti
vnosa iz podatkovne baze. Pod vnosnimi polji se nahajajo ²tirje gumbi, namenjeni
upravljanju s podatki v obrazcu. To so:
• Odstrani izbrano � S klikom na ta gumb odstranimo izbrani vnos.
• Posodobi izbrano � S klikom na ta gumb za izbrano vrstico posodobimo podatke
v podatkovni bazi.
• Vstavi kot novo � S klikom na ta gumb se v podatkovni bazi v entiteti Elemnti
naloge ustvari nov vnos, v tabeli pa se prikaºe nova vrstica. Ta se v tabeli
doda na zadnje mesto.
• Po£isti polja � S klikom na ta gumb izpraznimo vsa vnosna polja.
Na dnu obrazca se nahajajo gumbi Zapri, Shrani, Aktiviraj in Predogled. Ob kliku
na gumb Shrani se izvede nov zapis v bazo.
52 Izdelava aplikacije
Ob kliku na gumb Zapri pa se, £e imamo vnesene ne shranjene podatke, odpre pojavno
okno, ki nas spra²uje, ali ºelimo u£no pripravo shraniti. �e to potrdimo, se izvede
enaka akcija kot na gumbu Shrani, le da se tu po shranjevanju obrazec zapre. Nalogo
lahko nato kadar koli urejamo.
Ob kliku na gumb Aktiviraj nas v primeru, da imamo vnesene neshranjene podatke,
aplikacija na to opozori. �e potrdimo to opozorilo, se naloga aktivira. Prikaºe se
obvestilo, da je naloga uspe²no aktivirana, in nas preusmeri na doma£o stran. Ko se
naloga aktivira, se v podatkovni bazi ustvari nova entiteta, ki to nalogo predstavlja.
Vsak vnos v entiteti Naloge, ki je aktiven, ima tako svojo entiteto v podatkovni bazi.
Oznaka entitete na podatkovni bazi je sestavljena iz predpone nal_ in identi�katorja
te naloge.
S klikom na gumb Predogled se odpre naloga na na£in, kot bo videti, ko bo objavljena.
Stran s seznamom nalog
Datoteka /WebObrazci/Naloge/Pregled_oddaj.zul za ²tudente in Pregled_dodaj.zul za
profesorje. Stran ponuja seznam shranjenih nalog, razvr²£enih glede na datum in
status. Za status se prikazujejo trije lo£eni seznami:
• neaktivne naloge,
• aktivne naloge,
• zaklju£ene naloge.
Seznam neaktiviranih nalog se prikazuje le profesorjem. Druga dva pa se prikazujeta
tako profesorjem kot ²tudentom.
Vsak vnos poleg datuma prikazuje ²e naslov ure. S klikom na vnos v seznamu se
odpre stran za izpolnjevanje naloge.
4.3 Zgradba aplikacije 53
Slika 4.13: Stran s seznamom nalog
Primer naloge
Datoteka /WebObrazci/Naloge/OddajNalogo.zul. Stran vsebuje elemente, ki se za
identi�kator izbrane naloge nahajajo v entiteti Elementi naloge. �tudentu se na
dnu naloge prikazujeta gumba Zapri in Shrani, profesorju pa Zapri in Deaktiviraj.
S klikom na gumb Shrani se ustvari nov vnos v entiteti naloge.
S klikom na gumb Deaktiviraj se entiteta iz aktivne prestavi v neaktivno. Vsi vnosi, ki
so jih naredili ²tudentje za to nalogo v entiteto te naloge, so izgubljeni, saj se entiteta
izbri²e. Profesor lahko nato to nalogo popravi in ponovno aktivira.
�e ²tudent klikne na gumb Zapri se, £e imamo vnesene neshranjene podatke, odpre
pojavno okno, ki nas spra²uje, ali ºelimo u£no pripravo shraniti. �e to potrdimo, se
izvede enaka akcija kot na gumbu Shrani, le da se tu po shranjevanju obrazec zapre.
Nalogo lahko nato kadar koli urejamo.
�E profesor klikne na gumb Zapri se naloga le zapre.
�e je uporabnik v seznamu nalog kliknil na ºe zaklju£eno nalog, pa ima na voljo
54 Izdelava aplikacije
le gumb Nazaj ter komentar profesorja, £e ga je ta za to nalog vnesel.
Stran z oddanimi nalogami
Datoteka /WebObrazci/Naloge/Pregled_oddane.zul. Stran vsebuje seznam vseh vno-
sov v entiteti posamezne izbrane zaklju£ene naloge in jo lahko vidijo le profesorji. Do
strani dostopajo s klikom na zaklju£eno nalogo.
V tabeli se prikazuje identi�kator vnosa v entiteti, identi�kator uporabnika in komen-
tar profesorja. V vrstici vsakega vnosa se nahaja gumb za ogled naloge. S klikom na
gumb se odpre naloga z vnosi uporabnika.
Slika 4.14: Stran s seznamom oddanih nalog
Datoteka /WebObrazci/Naloge/OddanaNaloga.zul. Ko profesor klikne na gumb za
ogled oddane naloge, se odpre naloga z onemogo£enimi vnosnimi polji. Vrednosti
v poljih so tak²ne, kot jih je vnesel ²tudent. Pod nalogo se nahajata polje za vnos
komentarja in gumb za shranjevanje.
Ta pogled je enak, kot ga ima ²tudent, ko klikne na zaklju£eno nalogo, le da se pri
²tudentu pod nalogo komentar prikaºe zgolj v tekstovni obliki.
4.3 Zgradba aplikacije 55
Slika 4.15: Primer oddane naloge s poljem za komentar
Poglavje 5
Vzdrºevanje
V tem poglavju bom opisal orodja za vzdrºevanje in moºne raz²iritve sistema. Vzdr-
ºevanje je pomemben del vsakega razvojnega cikla in pripomore k nenehnemu izbolj-
²evanje sistema. Za namen laºjega pregleda in vodenje teh aktivnosti pa je pomembna
tudi dobra dokumentacija.
5.1 Dokumentacija
Z dokumentacijo poskrbimo, da lahko nekdo, ki ni bil prisoten pri projektu razvoja
sistema, razume, kako je aplikacija sestavljena, kako deluje in kak²ne funkcionalnosti
omogo£a. Pisanje dokumentacije je £asovno zelo zahteven postopek. Napisana mora
biti tako, da jo razume vsak, ki bo sistem uporabljal, vzdrºeval ali nadgrajeval. Ker
se sistem nenehno dopolnjuje, se mora nenehno dopolnjevati tudi sistemska dokumen-
tacija.
V mojem primeru kot dokumentacija sluºi ta diplomska naloga, saj so v poglavju
4 opisani vsi elementi sistema. Podani so opisi za:
• podatkovni model,
• strukturo datotek,
• opis vseh pomembnih razredov in njihovih funkcionalnosti ter
• opis vseh zaslonov in njihovega zaporedja.
56
5.2 Vzdrºevanje in hramba izvorne kode 57
5.2 Vzdrºevanje in hramba izvorne kode
Vzdrºevanje je pomemben vidik razvojnega cikla, saj tako skrbimo, da je aplikacija
vedno v koraku s £asom. V vzdrºevanje spadata dve vrsti sprememb:
• Popravki aplikacije � Odprava tako imenovanih hro²£ev, ki niso bili odkriti v
fazi testiranja. To se navadno dogaja, ker testno okolje ne more ponuditi vseh
moºnih situacij, ki se lahko zgodijo, ko je aplikacija v produkcijskem okolju, ali
pa jih uporabniki, ki so testirali aplikacijo, niso predvideli.
• Raz²iritve aplikacije � Ponudijo se predlogi za izbolj²ave sistema. Tu gre za
izdelavo novih funkcionalnosti sistema, zahteve za katere so se pojavile po tem,
ko je aplikacija ºe bila prenesena v produkcijsko okolje. Te zahteve so lahko
vezane tudi na samo uporabni²ko izku²njo in nimajo ni£ z na£inom poslovanja
oziroma z zalednim delom sistema.
Zahteve za oba tipa popravkov je potrebno smiselno in strukturirano beleºiti. Razvi-
jalci oziroma uporabniki zato uporabljajo tako imenovani sistem za beleºenje napak.
Obstaja vrsta takih orodij, ki so lahko pla£ljiva ali brezpla£na. Prestavil bom dve.
Za sledenje razvoju in zapisu sledi razvoja pa je pomembno tudi, da se hrani vsa
zgodovina in vse verzije razvite kode. Na ta na£in lahko zagotovimo sledljivost in
moºnost prehoda na starej²o verzijo sistema. Ta na£in dela nam tudi omogo£a, da
pripravimo ve£ kot eno razli£ico oziroma tako imenovano vejo sistema, ki imajo lahko
razli£ne funkcionalnosti. Umestitev kode na te sisteme omogo£ajo skoraj vsa napre-
dnej²a razvojna okolja in predstavlja del osnovnih funkcionalnosti. Tu bom prav tako
predstavil dve najpogosteje uporabljeni arhitekturi.
5.2.1 JIRA
JIRA je eden od popularnej²ih sistemov za vodenje in organizacijo zahtevkov spre-
memb in odprave napak. Razvilo ga je podjetje Atlassian in ima po njihovih besedah
okoli 25.000 uporabnikov v 122 drºavah po vsem svetu (Atlassian, 2016).
Najve£ji tekmec JIRI je sistem Bugzilla, ki je izdelek podjetja Mozilla Foundation
in obstaja ºe od leta 1998.
58 Vzdrºevanje
Prednost sistema JIRA pred sistemom Bugzilla je, da je prvi prilagodljivej²i. Bug-
zilla ima �ksni ºivljenjski cikel za napake, JIRA pa omogo£a, da lahko uporabniki ta
cikel sami prilagajajo glede na potrebe in organizacijo v podjetju. Tako je JIRA �eksi-
bilnej²i in se lahko uporablja tudi za splo²nej²e napake in zahteve (Wikipedia, 2016a).
Zaradi popularnosti sistema je na voljo veliko ²tevilo vti£nikov, ki s svojimi funkcio-
nalnostmi uporabnikom in razvijalcem laj²ajo delo in omogo£ajo izdelavo prilagojenih
poro£il za izdajanje ra£unov, izvedbe analiz optimizacije in podobno.
Verzija 7 omogo£a prilagojeno verzijo sistema za razvijalce. Sistem ima ºe vklju£en
vti£nik Agile, ki omogo£a poglede Scrum in Kanban, ki razvijalcem pomagajo pri
organizaciji dela. Orodje Scrum omogo£a izdelavo tako imenovanih sprintov. To je
mnoºica napak in zahtev, ki se obi£ajno izvedejo in zaklju£ijo v enem do ²tirih te-
dnih. Orodje Kanban pa omogo£a pregled vseh faz napake od prijave do izvedbe. V
vsakem trenutku lahko vidimo, kateri zahtevki so na kateri stopnji postopka. Celoten
postopek se vodi kot nekak²na zgodba. Sistem omogo£a, da uporabnik oziroma raz-
vijalec sam dolo£i te stopnje cikla. Primer stopenj je lahko prijava napake, obravnava
napake, v delu, v testu, name²£eno, zaklju£eno.
Slika 5.1: Osnovno okno sistema (vir: www.atlassian.com/software/jira)
5.2.2 TAIGA
Ker uporaba sistema JIRA ni brezpla£na, sem za namen vzdrºevanja sistema projekt
ustvaril na sistemu TAIGA. Projekt se nahaja na spletnem naslovu
5.2 Vzdrºevanje in hramba izvorne kode 59
https://tree.taiga.io/project/nomeaning25-aplikacija-pzopp/. �e uporabnik ºeli do-
dati zahtevo, se mora najprej prijaviti v sistem. Registracija je brezpla£na.
Prva verzija sistema je iz²la leta 2014, leta 2105 pa ji je portal Agile podelil prvo
nagrado za najbolj cenjeno agilno orodje tega leta (Taiga, 2016).
Tako kot sistem JIRA tudi TAIGA omogo£a orodji Scrum in Kanban za laºje vo-
denje zahtev. Poleg teh dveh vti£nikov pa ponuja ²e moºnost integracije z razli£nimi
sistemi za vodenje verzij aplikacije, vodenje dokumentacije projekta in druga upo-
rabna orodja. Za namen personalizacije pa omogo£a ²e uporabo vmesnika API, ki ga
razvijalci lahko uporabijo za razvoj novih prilagojenih funkcionalnosti.
Glede na podatke na uradni spletni strani sistem uporablja okoli 150.000 uporab-
nikov, ki uporabljajo skupaj okoli 120.000 projektov.
Slika 5.2: Osnovno okno sistema ( vir: taiga.io)
5.2.3 Git
GIT je sistem za vodenje nadzora nad verzijami aplikacije. Cilj sistema je hitrost, in-
tegriteta podatkov in podpora distribuiranemu nelinearnemu poteku dela (Git, 2016).
GIT se od drugih sistemov tipa klient-streºnik razlikuje v tem, da je vsaka GIT-mapa
60 Vzdrºevanje
na vsakem ra£unalniku popoln repozitorij s celotno zgodovino in polnimi zmoglji-
vostmi vodenja verzij, neodvisno od spletnega dostopa ali centralnega streºnika. To
razvijalcu omogo£a dostop do vse zgodovine in vseh sprememb razvite kode ter do
vseh vej kode, £eprav nima spletnega dostopa. Tako lahko aplikacijo razvija neodvi-
sno od drugih razvijalcev.
Prva verzija sistema je iz²la aprila leta 2005 in njegova popularnost raste vse od
takrat.
Zaradi popularnosti pa je na voljo kar nekaj orodij, ki omogo£ajo spletno hrambo
razvojne kode s sistemom GIT. Primeri teh sistemov so:
• GitHub,
• BitBucket,
• GitLab.
Razlike med njimi so v dostopnosti razvite kode. GitHub omogo£a hrambo neomeje-
nega ²tevila projektov vendar so vsi projekti vidni javnosti. �e ºelimo izvorno kodo
skriti, pa moramo izbrati pla£ljivi ra£un, kar stane od sedem dolarjev na mesec za
posameznike do 21 dolarjev na mesec za ve£ja podjetja. Ker je koda vidna na sve-
tovnem spletu, je ta tip uporabe primeren za uporabnike, ki pri razvoju potrebujejo
pomo£ in nasvete pri izvedbi. Pri tem lahko pri razvoju projekta sodeluje vsak.
Bitbucket je sistem, ki ga je razvilo isto podjetje kot sistem JIRA. Omogo£a hrambo
neomejenega ²tevila projektov, vendar pa so ti vidni le prijavljenim uporabnikov, ki
so del razvojne ekipe. Uporaba sistema je do ekipe velikosti do pet uporabnikov brez-
pla£na, ve£jim ekipam pa se obra£una po ceniku.
GitLab je po funkcionalnostih zelo podoben GitHub. Poleg spletni hrambi je sis-
tem namenjen tudi namestitvi na osebnem ra£unalniku. GitLab omogo£a neomejeno
hrambo tako zasebnih kot javnih repozitorijev z neomejenim ²tevilom zasebnih upo-
rabnikov. Omogo£a uvoz izvorne kode iz drugih sistemov. Med njimi sta tudi GitHub
in Bitbucket.
5.2.4 SVN
SVN oziroma Subvesrsion je glede na raziskave podjetja Black Duck eden najbolj
uporabljenih sistemov za hrambo razvojne kode in vodenje verzij (BlackDuck, 2016).
5.2 Vzdrºevanje in hramba izvorne kode 61
Prva razli£ica sistema je iz²la leta 2004 (Apache, 2016) in temelji na sistemu CVS (sis-
temu za hrambo so£asnih razli£ic), ki uporablja princip arhitekture "klient-streºnik".
Streºnik hrani trenutne verzije izvorne kode in vso zgodovino, uporabniki pa se s
pomo£jo klienta na streºnik povezujejo in si verzijo sistema "izposodijo", jo razvijajo
in nato "vrnejo² spremembami.
Razvijalci lahko eni verzijo razvijajo isto£asno. Da pa ne bi prihajalo do teºav pri
"vra£anju"verzije na streºnik, ta sprejme le najnovej²o izvorno kodo. Zato morajo
razvijalci skrbeti, da imajo vedno "izposojenoºadnjo verzijo kode. Kodo lahko med
£asom, ko jo imajo izposojeno, tudi posodobijo, £e je na streºniku novej²a verzija.
SVN je mogo£e namestiti na lastni streºnik in tam upravljati repozitorije. Nekaj
primerov orodij, ki to omogo£ajo:
• ColabNet,
• WANdisco,
• VisualSVN,
• OpenSVN.
Poglavje 6
Evalvacija
Namen evalvacije je preveriti, ali so bili cilji spletne aplikacije doseºeni. Da bi to
preveril, sem aplikacijo posredoval nekaj ciljnim uporabnikom in jim zastavil nekaj
vpra²anj, s katerimi sem ºelel pridobiti informacijo o uspe²nosti in ustreznosti aplika-
cije. Pro²nji so se odzvali ²tirje uporabniki: trije biv²i ²tudentje in asistentka. Prvim
trem se dodelil uporabni²ke pravice za ²tudente, asistentki pa sem omogo£il dostop
za oba tipa pro�lov.
Vpra²anja, ki sem jim jih zastavil, so se nana²ala na ºelene funkcionalnosti oziroma
naloge in probleme, ki jih aplikacija re²uje in odpravlja:
1. Kak²na se vam zdi izvedba aplikacije. Se vam zdi, da bi tak²na apli-
kacija lahko pripomogla pri preverjanju znanja?
Pri tem vpra²anju so bili uporabniki deljenih mnenj. Dva uporabnika sta po-
trdila ustreznost izvedbe, druga dva pa sta pri aplikaciji videla veliko pomanj-
kljivosti. Pomanjkljivosti, ki sta jih zaznala so:
• Nedodelan gra�£ni vmesnik, ki ni prijazen do uporabnika in ni dovolj di-
nami£en.
• Teºave z menijem. Tu gre za teºavo zaporednega dostopa do istih vsebin.
Pri drugem dostopu se vsebina ne prikaºe. Na primer: uporabnik je ºelel
izdelati dve nalogi. Po izdelavi prve naloge, se po zaklju£ku prikaºe osnovna
stran. Ponovni klik na povezavo za izdelavo naloge ne naredi ni£.
• Manjkajo uporabni²ka navodila oziroma pomo£.
62
63
• Pri uporabni²kemu tipu za profesorje, sta povezavi za izdelavo �hospitacij�
in �u£nih priprav� nepotrebni, saj sta ta dva obrazca namenjena ²tudentom.
Predlog asistentke je, da bi tu bilo bolje dodati moºnost urejanja in izdelave
novih prilagojenih obrazcev za ta dva tipa.
Mnenje asistentke je ²e, da je aplikacija kot prototip v redu, ni pa primerna za
uporabo s ²tudenti.
2. Kak²na se vam zdi uporabni²ka izku²nja aplikacije?
Vsi uporabniki so bili mnenja, da je uporabni²ka izku²nja v aplikaciji zadovo-
ljiva, vendar bi jo bilo potrebno ²e dodelati. Predvsem manjkajo uporabni²ka
navodila, ki bi ga usmerjala.
3. Kje vidite prednosti oziroma slabosti aplikacije v primerjavi s sistemi
LMS. Pri tem vpra²anju sem dobil ²tiri razli£na mnenja.
• Prvo mnenje je, da LMS sistemi omogo£ajo veliko ²tevilo funkcionalnosti,
ta aplikacija pa je narejena kot pripomo£ek in ima to£no dolo£eno funkci-
onalnost in je zato bolj pregledna.
• Drugo mnenje je, da so LMS sistemi uporabniku bolj prijazni in so dobro
dokumentirani.
• Tretji uporabnik aplikacije ni mogle primerjati z LMS sistemi.
• Asistentka pa je bila mnenja, da LMS sistemi ºe omogo£ajo funkcionalno-
sti, ki jih obravnavana aplikacija ponuja. Poleg tega ponujajo priro£nej²i
na£in ocenjevanja oddanih dokumentov in vra£anja dokumentov ²tuden-
tom za popravke. Edina prednost te aplikacije je, da omogo£a strukturi-
rano pisanje priprav neposredno v aplikacijo, pri LMS pa jih je treba pisati
v pripravljen dokument in ga nato oddati kot datoteko.
4. Ali bi vam tak²na aplikacija pri²la prav med opravljanjem pedago²ke
prakse? Trije uporabniki so pri tem vpra²anju pritrdili, da bi aplikacijo upo-
rabljali pri pedago²ki praksi. Eno od mnenje je bilo, da bi bil tak na£in dela
bolj prijazen, saj je neposreden vnos na streºnik veliko privla£nej²i od po²iljanja
velikih tekstovnih datotek po elektronski po²ti.
Asistentka pa je bila tu mnenja, da je aplikacija preve£ toga za uporabo in bi
za kaj takega raje uporabljali e-portfelj ali celo blog.
64 Evalvacija
5. Zagotovo bi ºeleli v aplikacijo vklju£iti ²e kak²no funkcionalnosti, ki
v trenutno verzijo ni vklju£ena. Katere?
Uporabniki so predlagali naslednje funkcionalnosti:
• Moºnost odpiranja aplikacije v ve£ kot enem zavihku.
• Doda naj se spisek operativnih u£nih stilov, njihovo doseganje in podobne
vsebine.
• Prikaz priprave na zaslonu. Prikaz naj bo na eni strani, za laºjo orientacijo
pri u£ni uri.
• Moºnost ustvarjanja svojega ocenjevalnega obrazca, s katerim bi se ocenilo
pripravo ali hospitacijski zapisnik.
• Moºnost ustvarjanja lastnega hospitacijskega obrazca.
• Moºnost ustvarjanja lastnega obrazca za u£no pripravo.
• Moºnost pred£asne oddaje nalog v pregled in ocenjevanje.
6. Bi katere od funkcionalnosti aplikacije uporabili pri pou£evanju za
lastno organizacijo dela? (Na primer kot u£itelj v ²oli.)
Trije od uporabnikov so pritrdili, da bi aplikacijo v okrnjeni obliki, uporabljali
tudi kot u£itelji. Eden od uporabnikov pa je mnenja, da aplikacija ni dovolj
dobro narejena, da bi jo uporabljal za ta namen. Uporabniki, ki bi jo uporabljali
pa bi uporabili predvsem funkcionalnost pisanja u£nih priprav.
Po mnenju enega od uporabnikov je aplikacija zanimiva in ima potencial, vendar jo je
treba nadgraditi. Ena od potrebnih nadgradenj je pri uporabni²kem vmesniku. Te-
ºava pri slednjem je, da je navigacija strani urejena tako, da se po prijavi odpre glavna
stran z menijem in objektom IFRAME, v katerem prikazujemo trenutno pod stran.
Vsi kliki na povezave v meniju nato v objektu IFRAME odpirajo nove povezave. Tako
se v primeru, da odpremo stran v aplikaciji v novem zavihku, zopet odpre prva stran
aplikacije. Pri taki postavitvi meni urejam le v eni datoteki, in £e je spremenjen na
enem mestu, je spremenjen povsod. Bolj²a re²itev bi bila, da bi se povezave v meniju
re²evale na ravni baze in bi se meni na vsaki strani gradil dinami£no s pomo£jo klicev
AJAX.
Glede rezultate evalvacije, ki sem jo izvedel sam in ki so jo izvedli uporabniki, tre-
nutna verzija aplikacije ²e ni primerna za namestitev na produkcijo, ampak je zgolj
65
prototip. Zaradi £asovne zahtevnosti projekta, nisem izdelal vseh predvidenih funkci-
onalnosti, ki sem jih opisal v poglavju ²tevilka 3. Te funkcionalnosti se lahko izvedejo
v naslednjem razvojnem ciklu.
Seznam manjkajo£ih funkcionalnosti ter raz²iritve in izbolj²ave, ki sem jih zaznal
med evalvacijo in ki so jih zaznali uporabniki, ki so aplikacijo preizkusili:
• Pri prijavi v sistem trenutno ne omogo£amo izbire predmeta: Aplika-
cija je ºe pripravljena na to funkcionalnost, ki je ºe predvidena tudi v podat-
kovnem modelu z entiteto Predmet. Predlog re²itve je, da se uporabniku po
prijavi odpre pojavno okno, v katerem mora izbrati predmet, ki ga ºeli odpreti.
�e ima v podatkovni bazi dodeljen le en predmet, se to pojavno okno ne pri-
kaºe. Pojavno okno za izbiro predmeta lahko nato prikli£e kadar koli v meniju
Datoteka.
• Manjka stran za administratorje: V aplikacijo je treba dodati stran za
administratorje. Tu mora biti omogo£eno dodajanje novih predmetov ter upra-
vljanje uporabnikov (dodelitev predmeta, vnos novega uporabnika, vnos paketa
uporabnikov).
• Oddaja dnevnika prakse: Funkcionalnost oddaje dnevnika prakse se je uma-
knila, saj je ta del mogo£e pripravi kot nalogo.
• Moºnost shranjevanja predlog nalog: Dobro bi bilo omogo£iti shranjevanje
naloge kot predloge ali pa pripraviti moºnost, da se na podlagi izbrane naloge
naredi nova z enakimi elementi. Na posamezni nalogi bi poleg trenutnih gumbov
profesorju ponudili ²e gumb Prekopiraj v novo. Ta gumb bi bil prikazan na
nalogah pri vseh statusih.
• Deljenje vsebin z drugimi uporabniki: V podatkovnem modelu bi bilo
treba ustvariti novo entiteto s pooblastili za posamezno vsebino. Na posamezni
vsebini se bi nato dodalo gumb Deli. S klikom na gumb bi se uporabniku
prikazalo okno z vnosnim poljem za vnos identi�katorja uporabnika, s katerim
ºelimo deliti vsebino. Na strani s seznamom vsebin bi se nam v primeru, da je
z nami nekdo delil neko vsebino, pojavila nova rubrika Deljene vsebine. Pri teh
vsebinah se omogo£i ²e dodajanje komentarjev.
• Orodje za odkrivanje "plagiatorstva": Ustvari se nova stran, ki jo lahko
vidijo le profesorji. Na strani se nahaja vnosno polje, v katero profesor vnese
66 Evalvacija
ºeleni niz. Sistem nato z SQL-stavkom po vseh vsebinah, ki jih ima v bazi,
poi²£e tiste vnose, ki ta niz vsebujejo, in ga ozna£i. Profesor bi lahko nato
izbral dve vsebini in ju primerjal med seboj.
• Zaklep hospitacije ali u£ne priprave, £e je oddana preko naloge: Za
integriteto podatkov je treba v primeru, da uporabnik dolo£eno hospitacijo ali
u£no pripravo ozna£i, to vsebino zakleniti oziroma onemogo£iti vnos sprememb.
To je mogo£e narediti tako, da se v entiteti na podatkovni bazi doda ²e en stolpec
s statusom vsebine. Ta se spremeni, ko se naloga, na kateri je vsebina dodana,
zaklju£i.
• Moºnost pregleda oddanih nalog pred kon£nim rokom: Trenutno je
omogo£en pregled oddanih nalog ²ele potem, ko rok pote£e. Omogo£i se tudi
moºnost, da ²tudent pred£asno odda nalogo.
• Sprememba menija: Meni naj se doda v bazo in nato na vsaki strani dina-
mi£no ustvari s pomo£jo klicev AJAX glede na skupino uporabnika.
• Moºnost ustvarjanja ocenjevalnih obrazcev, na podlagi katerih bi se oce-
njevale hospitacije ali u£ne priprave.
• Moºnost ustvarjanja novega hospitacijskega obrazca
• Moºnost ustvarjanja novega obrazca za u£no pripravo
• Vpeljava uporabnih gradiv: V aplikacijo se dodajo povezave in uporabni
dokumenti. Na primer spisek operativnih u£nih ciljev, njihovo doseganje in
podobno.
Poglavje 7
Zaklju£ek
Namen diplomskega dela je bila preveriti in raziskati moºnost izdelave spletne apli-
kacije, ki bi s prilagojenimi obrazci olaj²ala delo ²tudentom in profesorjem. Izdelave
sem se lotil tako, da sem s pomo£jo ogrodja ZK framework pripravil aplikacijo, v
kateri lahko uporabniki izdelujejo poro£ila hospitiranih ur in pripravljajo priprave za
u£ne nastope. Profesorjem sem omogo£il, da s pomo£jo vnosnega obrazca pripravijo
poljubne naloge za ²tudente in nato na podajajo komentarje na kon£ne izdelke. Apli-
kacija vsebuje vse funkcionalnosti, ki jih profesor ºe uporablja na svoji spletni strani.
Kot sem navedel ºe v poglavju 1.3, sem pri razvoju uporabil kombinacijo razvoj-
nih modelov in od vsakega modela vzel del, ki se mi je zdel pomemben ali uporaben
za razvoj aplikacije. �e bi se za razvoj odlo£al znova, bi se glede na pridobljeno
znanje odlo£il le za enega. Odlo£il bi se za agilno metodo, saj bi tako zagotovil, da
bi uporabniki aplikacijo £im bolje sprejeli. Prav tako bi glede na pridobljene izku²nje
uporabil druga£en pristop k razvoju. Razvoj s pomo£jo ogrodja ZK framework bi
opustil, saj me je to le oviralo. Zaradi njegove uporabe sem bil na za£etku omejen
glede oblikovne zasnove aplikacije, ko sem to odpravil, pa mi je ostala le datoteka
za de�nicijo zaporedja komponent. Te strani bi lahko ustvaril tudi z datotekami
JSP (Java Server Pages), ki so ºe del programskega jezika JAVA in imajo enako ozi-
roma podobno funkcionalnost kot strani PHP. Vse entitetne programske razrede sem
ustvaril s pomo£jo orodja v IDE in bi jih nato dopolnil s potrebnimi funkcijami in
metodami. S tem bi poskrbel za pregledno strukturo programske kode.
Med razvojem aplikacije sem se veliko nau£il. Uporabil sem razli£ne principe iz-
delave programskih razredov, spoznal sem bistvo uporabe EJB (izdelava entitetnega
67
68 Zaklju£ek
razreda in razred upravitelja te entitete), spoznal sem razli£ne razvojne modele, ki
sem jih v diplomski nalogi nato tudi predstavil, in hrambe razvojne kode. Skozi razvoj
je vidno, da se oblika moje razvojne kode spreminja. Na za£etku je koda zelo neorga-
nizirana v dolgih in velikih programskih razredih, nato se je razdrobila, postala bolj
strukturirana, namesto funkcij pa sem pri£el uporabljati objekte in njihove metode.
Skoraj vsi cilji diplomskega dela so bili doseºeni. V drugem in tretjem poglavju
diplomskega dela sem preu£il in opisal zasnovo spletne aplikacije ter opisal na£rt, v
£etrtem poglavju sem opisal potek izdelave aplikacije in aplikacijo izdelal ter opisal
moºne na£ine namestitve. Cilj, ki ni bil doseºen, je namestitev aplikacije na streºnik,
saj aplikacija ni prestala testa sprejetosti (tako imenovai �Acceptance test�) kon£nih
uporabnikov in zato ni name²£ena na produkcijsko okolje v uporabo kon£nim upo-
rabnikom. Da bi zadostil vsem potrebam, bi bilo potrebno razvojni cikel zavrteti ²e
enkrat in odpraviti vse pomanjkljivosti trenutne verzije aplikacije.
Literatura
Ambler, S. W. (2014). Examining the Agile Manifesto. Pridobljeno 26. avgusta 2016,
http://www.ambysoft.com/essays/agileManifesto.html
Apache. (2016). Apache Subversion. Pridobljeno 25. avgusta 2016, https://subversion.
apache.org/docs/release-notes/
Atlassian. (2016). Atlassian. Pridobljeno 12. avgusta 2016, https://www.atlassian.
com
Bender. (2003). Systems Development Lifecycle: Objectives and Requirements. Ben-
der RBT In. Pridobljeno 31. avgusta 2016, http://www.benderrbt.com/Bender-
SDLC.pdf
Bitnami. (2016). Bitnami for XAMPP. Pridobljeno 30. julija 2016, https://bitnami.
com/stack/xampp
BlackDuck. (2016). Compare Repositories. Pridobljeno 12. avgusta 2016, https ://
www.openhub.net/repositories/compare
Bowlby, S. M. (2008). Six Phases of the Web Site Design and Development Process.
Pridobljeno 7. marca 2016, http://www.idesignstudios.com/blog/web-design/
phases-web-design-development-process/#.Vt3bHObo47w
CMS. (2008 marec). Selecting a development approach. CMS. Pridobljeno https :
//www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-
Technology/XLC/Downloads/SelectingDevelopmentApproach.pdf
Dennis, A., Wixom, B. H., & Roth, R. M. (2011). Systems Analysis and Design,
5th Edition. Pridobljeno 31. avgusta 2016, http://www.uoitc.edu.iq/images/
documents/informatics-institute/Competitive_exam/Systemanalysisanddesign.
DOJ. (2003 januar). Systems Development Life Cycle. The Department of Justice.
Pridobljeno 26. avgusta 2016, https ://www. justice .gov/archive/ jmd/irm/
lifecycle/table.htm
Eclipse. (2016). Eclipse. Pridobljeno 30. julija 2016, https://www.eclipse.org/
69
70 LITERATURA
Friends, A. (2016). Apache Friends. Pridobljeno 30. julija 2016, https : / / www .
apachefriends.org/index.html
Git. (2016). Git. Pridobljeno 25. avgusta 2016, https://git-scm.com
Ivan²ek, G. (2013). Diplomsko delo: Prilagoditev odprtokodnega sistema Drupal za
uporabo pri didaktiki tehnike (Magistrsko delo, Pedago²ka fakulteta Univerza v
Ljubljani).
Netbeans. (2016a). Netbeans. Pridobljeno 30. julija 2016, https : / /netbeans . org/
downloads/index.html
Netbeans. (2016b). NetBeans Release Roadmap. Pridobljeno 30. julija 2016, https:
//netbeans.org/community/releases/roadmap.html
Puckett, E. G. (2001). Methods for Software Prototyping. Pridobljeno 31. avgusta
2016, http : / / sce . uhcl . edu / helm /REQ_ENG_WEB/My - Files /mod4 /
Software_Prototyping.pdf
Purcell, J. E. (2016 avgust). Comparison of Software Development Lifecycle Me-
thodologies. Pridobljeno 26. avgusta 2016, https://software-security.sans.org/
resources/paper/cissp/comparison-software-development-lifecycle-methodologies
Taiga. (2016). Taiga Agile. Pridobljeno 31. avgusta 2016, https://angel.co/taiga-
agile/activity
Wikipedia. (2014). Chaos model. Pridobljeno 19. junija 2016, https://en.wikipedia.
org/wiki/Chaos_model
Wikipedia. (2016a). JIRA (software). Pridobljeno 12. avgusta 2016, https : / / en .
wikipedia.org/wiki/Jira_(software)
Wikipedia. (2016b). Netbeans. Pridobljeno 30. julija 2016, https://en.wikipedia.org/
wiki/NetBeans
Wikipedia. (2016c). Systems development process. Pridobljeno 7. maja 2016, https:
//en.wikipedia.org/wiki/Software_development_process
Seznam uporabljenih kratic in
simbolov
AJAX Asinhroni JavaScript in XML
API "Application programming interface". Programski vme-
snik.
CE �ommunity edition". Brezpla£na verzija sistema, name-
njena ²ir²i javnosti.
CMS �ontent Management System". Sistem za upravljanje
spletnih vsebin.
EE "Enterprise edition". Pla£ljiva verzija sistema, name-
njena podjetjem.
EER "Enhanced entity-relationship". Raz²irjeni konceptu-
alni model, uporaben za oblikovanje podatkovne baze.
GUI "Graphical user interface". Gra�£ni uporabni²ki vme-
snik.
HTML "Hyper Text Markup Language". Jezik za izdelavo sple-
tnih strani.
IDE "Integrated development environment". Integrirano
okolje za razvoj aplikacij. Vsebuje urejevalnik izvorne
kode, interpreter ter orodje za odkrivanje napak.
IT "Information technology". Kratica se uporablja, ko
ozna£ujemo oddelek znotraj podjetja, ki se ukvarja z
upravljanjem streºnikov, razvojem aplikacij in drugih
del, ki se nana²ajo na informacijske tehnologije.
71
72 SEZNAM UPORABLJENIH KRATIC IN SIMBOLOV
JPA "Java Persistence API". Javanski programski vmesnik
za upravljanje entitet na podatkovni bazi in njihovih
relacij.
JSON "JavaScript Object Notation". Format za izmenjavo po-
datkov, ki temelji na skriptnem jeziku JavaScript.
LATEX Sistem za pripravo tekstovnih dokumentov.
LMS "Learning management system". Spletni sistem za po-
mo£ pri izobraºevanju.
PHP kratica "PHP: Hypertext Preprocessor". PHP: predpro-
cesor za hipertekst.
PNG "Portable network graphics". Oznaka formata rastrskih
fotogra�j.
PPU Prakti£no pedago²ko usposabljanje.
RAD "Rapid application development". Metodologija hitrega
razvoja aplikacij.
SDLC �istem development life cycle". �ivljenjski cikel razvoja
sistema.
SQL �tructured Query Language". Strukturirani poizvedo-
valni jezik, ki se uporablja za poizvedbe na podatkovnih
bazah.
UML "Uni�ed modeling language". Enotni jezik za modelira-
nje.
Priloge
Priloga 1: Datote£na struktura
/src| /conf| | MANIFEST.MF| | persistence.xml| || /java| /dnevnik| | database.java| | Datoteke.java| | DatotekePodatki.java| | DatotekeRenderer.java| | ElementN.java| | ElementNPodatki.java| | ElementNRenderer.java| | Funkcije.java| | Hospitacija.java| | HospitacijaVidikA.java| | HospitacijaVidikAJpaController.java| | HospitacijaVidikB.java| | HospitacijaVidikBJpaController.java| | Hospitacije.java| | HospitacijeJpaController.java| | MyBindComposer.java| | Naloga.java| | NalogaData.java| | NalogaViewModel.java| | Naloge.java| | OddaneNal.java| | OddaneNalPodatki.java| | OddaneNalRenderer.java| | PodrobniPregled.java| | PodrobniPregledPodatki.java| | PodrobniPregledRenderer.java| | Predmet.java| | PregledUre.java| | PregledUrePodatki.java| | PregledUreRenderer.java| | Profesor.java| | SimpleRenderer.java| | Sola.java| | Sporocila.java| | sqlStavki.java| | Ucitelj.java| | UcnaPriprava.java
73
74 PRILOGE
| | Uporabniki.java| | UporabnikiPK.java| | UporSkupina.java| | VidikA.java| | VidikB.java| || /exceptions| | IllegalOrphanException.java| | NonexistentEntityException.java| | PreexistingEntityException.java| || /print| DocumentProcessing.java| docx4jhelper.java| HospitacijaPrint.java| PripravaPrint.java| NalogaPrint.java| TableCell.java|/web| index.zul| timeout.zul||/META-INF| context.xml| persistence.xml|/scripts| ck_config.js| ck_config_hosp.js| DB.zs| DodajNalogo.zs| Dodaj_nal_func.zs| fck.js| funkcije.zs| OddajNalogo.zs| PodatkiOuri.zs| smartgrid.js|/stil| | stil.css| || /slike| | aktiviraj.png| | Arrow-down.png| | Arrow-up.png| | calendar.png| | Deaktiviraj.png| | Dodaj.png| | Dodaj_1.png| | Dodaj_2.png| | Dodaj_hospitacijo.png| | Dodaj_pripravo.png| | Dodaj_refleksijo.png| | Gumb-datoteka-hover.png| | Gumb-datoteka.png| | Gumb-prva-stran-dn.png| | Gumb-prva-stran-Ho.png| | Gumb-prva-stran-na.png| | Gumb-prva-stran-ob.png| | Gumb-prva-stran-pr.png| | Gumb-prva-stran-sk.png
PRILOGE 75
| | Gumb-prva-stran.png| | gumb_cancel.png| | gumb_dodaj.png| | gumb_naprej.png| | gumb_ok.png| | gumb_preklici.png| | nadaljuj.png| | nazaj.png| | oddaj.pdn| | oddaj.png| | Odstrani.png| | Odstrani_1.png| | Odstrani_2.png| | predogled.png| | shrani.png| | shrani_in_nadaljuj.png| | Thumbs.db| | Uredi.png| | Vpogled.png| | zapri_1.png| || /icons| folder32.png| lightbulb32.png| linedpaperpencil32.png| notepencil32.png| papercheck32.png| paperpencil32.png| paperplus32.png| paperstar.png| pencil32.png| plug32.png| questionbook32.png| spanner32.png| Thumbs.db| users32.png| usersplus32.png|/WEB-INF| | sun-web.xml| | web.xml| || /lib| | docx4j-3.2.1.jar| | docx4j-ImportXHTML-3.2.1.jar| | itext-2.1.7.jar| | mysql-connector-java-5.0.8-bin.jar| | xhtmlrenderer-3.0.0.jar| || /docx4j| antlr-2.7.7.jar| antlr-runtime-3.3.jar| avalon-framework-api-4.3.1.jar| avalon-framework-impl-4.3.1.jar| batik-anim-1.7.jar| batik-awt-util-1.7.jar| batik-bridge-1.7.jar| batik-css-1.7.jar| batik-dom-1.7.jar| batik-ext-1.7.jar| batik-extension-1.7.jar| batik-gvt-1.7.jar| batik-js-1.7.jar
76 PRILOGE
| batik-parser-1.7.jar| batik-script-1.7.jar| batik-svg-dom-1.7.jar| batik-svggen-1.7.jar| batik-transcoder-1.7.jar| batik-util-1.7.jar| batik-xml-1.7.jar| commons-codec-1.3.jar| commons-io-1.3.1.jar| commons-lang-2.4.jar| docx4j-3.2.1.jar| docx4j-ImportXHTML-3.2.1.jar| fop-1.1.jar| guava-17.0.jar| itext-2.1.7.jar| jaxb-svg11-1.0.2.jar| jaxb-xmldsig-core-1.0.0.jar| jaxb-xslfo-1.0.1.jar| jcl-over-slf4j-1.7.5.jar| mbassador-1.1.10.jar| poi-3.8.jar| poi-scratchpad-3.8.jar| serializer-2.7.1.jar| slf4j-api-1.7.5.jar| stringtemplate-3.2.1.jar| wmf2svg-0.9.0.jar| xalan-2.7.1.jar| xhtmlrenderer-3.0.0.jar| xmlgraphics-commons-1.5.jar|/WebObrazci
| Index.zul| Prijava.zul|/Dialogi| dodaj_Combo_nal.zul| dodaj_Txt_nal.zul| dodaj_Vrstico.zul|/Hospitacija| Hospitacija.zul| PodatkiOuri.zul| Pregled.zul| VidikA.zul| VidikB.zul|/Naloge| AktNaloga.zul| DodajNalogo.zul| DodajNalogo_bkp.zul| OddajNalogo.zul| OddanaNaloga.zul| PredogledNaloge.zul| Pregled_aktivne.zul| Pregled_dodaj.zul| Pregled_oddaj.zul| Pregled_oddane.zul| Pregled_zakljucene.zul|/Priprava| DodatneDejavnosti.zul| PodatkiOuri.zul| PodrobniPregled.zul
PRILOGE 77
| Pregled.zul| PregledUre.zul| PregledUre_bkp.zul|/Profesorji| Index.zul| menu.zul| PrvaStranProfesorji.zul|/Studentje| Index.zul| menu.zul| PrvaStranStudentje.zul|/Templates
hospitacija-template.docx
78 PRILOGE
Priloga 2: Podatkovni model
Slika 7.1: Podatkovni model
PRILOGE 79
Opis tipov
• Uporabniki: Tu so shranjeni uporabniki aplikacije. Podatki, ki se vna²ajo, so
identi�kator uporabni²ko ime, geslo in identi�kator uporabni²ke skupine. Iden-
ti�kator je enoli£na oznaka uporabnika. V primeru ²tudentov je to vpisna ²te-
vilka, v primeru profesorjev pa je to lahko mati£na ²tevilka. Drugi uporabniki
imajo lahko poljubne identi�katorje, pomembno je le, da se nobeden od identi-
�katorjev ne ponovi.
• Uporabni²ka skupina: Tu so shranjeni podatki o uporabni²ki skupini. Po-
datka, ki se tu nahajata, sta identi�kator in naziv skupine. Vnos v polju iden-
ti�kator se ustvari avtomatsko glede na zaporedno ²tevilko vnosa.
• Profesorji: Tu so shranjeni osnovni podatki o profesorjih. Podatki, ki se
vna²ajo, so identi�kator, ime, priimek in e-po²tni naslov. Pri identi�katorju
je pomembno, da je enak tistemu, ki ga ima profesor v tabeli Uporabniki.
• �tudentje: Tu so shranjeni osnovni podatki o ²tudentih. Podatki, ki se vna-
²ajo, so identi�kator, ime, priimek, e-po²tni naslov in identi�kator ²tudijske
smeri. Pri identi�katorju ²tudenta je pomembno, da je enak tistemu v tabeli
Uporabniki.
• �tudijski program: Tu se nahajajo nazivi ²tudijskih programov. Sem se
vnesejo podatki o identi�katorju in nazivu ²tudijske smeri. Vnos v polju iden-
ti�kator se ustvari avtomatsko glede na zaporedno ²tevilko vnosa.
• Predmet: Tu so shranjeni podatki o predmetu. Vna²ajo se podatki o identi-
�katorju in nazivu predmeta. Vnos se nato poveºe z entitetama Profesorji in
�tudentje preko vmesnih tabel. Vnos v polju identi�kator se ustvari avtomat-
sko glede na zaporedno ²tevilko vnosa.
• Hospitacija: Tu so shranjeni podatki o hospitaciji. Podatki, ki se nana²ajo na
hospitirano uro, so identi�kator, ²ola, izvajalec, datum, ura, razred, naslov ure,
u£na tema, u£ni sklop, u£na enota. Vezano na opaºanja uporabnika, ki je uro
hospitiral, pa se vneseta ²e identi�kator uporabnika in mentor. Vnos v polju
identi�kator se ustvari avtomatsko glede na zaporedno ²tevilko vnosa.
• Vidik A: Tu so shranjeni podatki o opisu ure. To so kratek opis u£ne ure, pri-
stop, vpra²anje, ki bi ga zastavili u£iteljici, ter mnenje o organizaciji. Poleg teh
80 PRILOGE
podatkov se vnese ²e identi�kator hospitacije, s katerim se ti podatki poveºejo
s podatki v entiteti Hospitacija.
• Vidik B: Tu so shranjeni podatki, vezani na opazovani vidik. To so opaºanja,
mnenje, ravnanje v zvezi z vidikom, razlaga opaºanj, zakaj je vidik pomemben,
utemeljitev. Poleg teh podatkov se vnese ²e identi�kator hospitacije, s katerim
se ti podatki poveºejo s podatki v entiteti Hospitacija.
• U£na priprava: Tu so shranjeni podatki, ki zdruºujejo entitete, vezane na vnos
podatkov o u£ni pripravi. Podatki, ki se tu hranijo, so identi�kator, identi�kator
podatkov ure inidenti�kator uporabnika. Slednji podatek u£no pripravo povezuje
z entiteto Uporabnik. Vnos v polju identi�kator se ustvari avtomatsko glede
na zaporedno ²tevilko vnosa.
• Podatki o uri: Tu so shranjeni podatki o uri u£ne priprave. Podatki, ki se sem
vpisujejo, so identi�kator, ²ola, izvajalec, datum, ura, razred, naslov ure, u£na
tema, u£ni sklop, u£na enota, pristop, metode, pripomo£ki, viri, dejavnosti za
u£no ²ibkej²e u£ence ter dejavnosti za u£no zmoºnej²e u£ence. Poleg teh podat-
kov se tu hrani ²e identi�kator u£ne priprave, ki podatke povezuje z vnosom v
entiteti U£na priprava. Vnos v polju identi�kator se ustvari avtomatsko glede
na zaporedno ²tevilko vnosa.
• Cilji ure: Tu se hranijo cilji ure. Podatka, ki se tu hranita, sta naziv cilja in
identi�kator ure, ki je enak kot v entiteti Podatki o uri.
• Zgradba ure: V tabeli Pregled ure se hranijo podatki o zgradbi ure za na-
men £asovne razdelitve poteka. Vsaka u£na priprava ima v tej tabeli lahko
ve£ kot en vnos. Podatki, ki se tu hranijo, so identi�kator, identi�kator u£ne
priprave, cilj, strategija doseganja, na£in doseganja, uporabljene metode, £as in
pripomo£ki. Ker se podatki prikazujejo tabelari£no, pa se hrani ²e podatek zapo-
redna ²tevilka, ki se nastavi glede na zaporedje vnosa. Vnos v polju identi�kator
se ustvari avtomatsko glede na zaporedno ²tevilko vnosa.
• Podrobni pregled ure: V tabeli Podrobni pregled ure se hranijo podrobni
podatki o zgradbi ure za namen £asovne razdelitve poteka in tabelske slike.
Vsaka u£na priprava ima v tej tabeli lahko ve£ kot en vnos. Podatki, ki se tu
hranijo so identi�kator, identi�kator u£ne priprave, namen, dejavnost u£itelja,
dejavnost u£enca in tabelska slika. Ker se podatki prikazujejo tabelari£no, pa
se hrani ²e podatek zaporedna ²tevilka, ki se nastavi glede na zaporedje vnosa.
PRILOGE 81
Vnos v polju identi�kator se ustvari avtomatsko glede na zaporedno ²tevilko
vnosa.
• Naloge: Tu se hranijo osnovni podatki naloge. To so identi�kator, naslov,
opis, rok oddaje in status naloge. Podatki se preko polja identi�kator uporabnika
povezujejo z entiteto Uporabnik, ki ozna£uje uporabnika, ki je nalogo izdelal.
Preko polja identi�kator predmeta pa se vnos poveºe z entiteto Predmet. Vnos
v polju identi�kator se ustvari avtomatsko glede na zaporedno ²tevilko vnosa.
• Elementi naloge: Tu se hrani struktura posamezne naloge. Vsak vnos v en-
titeti Naloge ima v tej tabeli lahko ve£ elementov. Podatki, ki se tu hranijo,
so identi�kator, identi�kacijska oznaka elementa, tip elementa in vrednost ele-
menta. Ker se podatki prikazujejo tabelari£no, pa se hrani ²e podatek zaporedna
²tevilka, ki se nastavi glede na zaporedje vnosa. Za namen povezovanja z en-
titeto Naloge pa se tu hrani ²e podatek identi�kator naloge. Vnos v polju
identi�kator se ustvari avtomatsko glede na zaporedno ²tevilko vnosa.
• Oddane naloge: Za vsak vnos v entiteti Naloge se ustvari nova tabela, ki
ima stolpce enake strukturi v entiteti Elementi naloge. Poleg teh stolpcev se
tu hrani ²e podatek o identi�katorju uporabnika. Vsak uporabnik ima v tej
tabeli lahko le en vnos.
Priloga 3: Popis vnosnih obrazcev
Hospitacija
Vnos osnovnih podatkov o uri
Datoteka /WebObrazci/Hospitacija/PodatkiOuri.zul.
82 PRILOGE
Slika 7.2: Vnos osnovnih podatkov o uri
Seznam vnosnih polj:
• Naslov ure � tekstovno polje. Polje je obvezno
• Izvajalec � tekstovno polje
• Mentor/-ica (O�/S�) � tekstovno polje
• Datum � datumsko polje. Poleg ro£nega vnosa je omogo£ena ²e izbira datuma
s pomo£jo koledarja.
• Ura � tekstovno polje
• Razred � tekstovno polje
• �ola � tekstovno polje
• U£na tema � tekstovno polje
• U£ni sklop � tekstovno polje
• U£na enota � tekstovno polje
PRILOGE 83
Vnos opisa ure
Datoteka /WebObrazci/Hospitacija/VidikA.zul.
Slika 7.3: Vnos opisa ure
Seznam vnosnih polj:
• Kratek opis u£ne ure � Polje za vnos obogatenega besedila. Polje v bazo zapi²e
HTML-kodo vnosa.
84 PRILOGE
• Opis pristopa � Polje za vnos obogatenega besedila. Polje v bazo zapi²e HTML-
kodo vnosa.
• Vpra²anje u£iteljici � Polje za vnos obogatenega besedila. Polje v bazo zapi²e
HTML-kodo vnosa.
• Mnenje o organizaciji hospitacije � Polje za vnos obogatenega besedila. Polje v
bazo zapi²e HTML-kodo vnosa.
Vnos podatkov v zvezi z opazovanim vidikom
Datoteka /WebObrazci/Hospitacija/VidikAB.zul.
PRILOGE 85
Slika 7.4: Vnos podatkov za opazovani vidik
Seznam vnosnih polj:
• Opazovani vidik ure � Tekstovno polje.
86 PRILOGE
• Opaºanja z opazovanim vidikom � Polje za vnos obogatenega besedila. Polje v
bazo zapi²e HTML-kodo vnosa.
• Opis ravnanja z opazovanim vidikom � Polje za vnos obogatenega besedila.
Polje v bazo zapi²e HTML-kodo vnosa.
• Razlaga opaºanj � Polje za vnos obogatenega besedila. Polje v bazo zapi²e
HTML-kodo vnosa.
• Opis, zakaj je vidik pomemben � Polje za vnos obogatenega besedila. Polje v
bazo zapi²e HTML-kodo vnosa.
• Utemeljitev premislekov � Polje za vnos obogatenega besedila. Polje v bazo
zapi²e HTML-kodo vnosa.
U£na priprava
Vnos osnovnih podatkov o uri
Datoteka /WebObrazci/Priprava/PodatkiOuri.zul.
Slika 7.5: Vnos osnovnih podatkov ure
PRILOGE 87
Seznam vnosnih polj:
• Naslov ure � Tekstovno polje.
• Izvajalec � Tekstovno polje.
• Mentor/-ica (O�/S�) � Tekstovno polje.
• Datum � Datumsko polje. Poleg ro£nega vnosa je omogo£ena ²e izbira datuma
s pomo£jo koledarja.
• Ura � Tekstovno polje.
• Razred � Tekstovno polje.
• �ola � Tekstovno polje.
• U£na tema � Tekstovno polje.
• U£ni sklop � Tekstovno polje.
• U£na enota � Tekstovno polje.
• Speci�£ni u£ni cilji � Tekstovno polje. Poleg polja se nahaja gumb �+�, s katerim
se lahko dodajo dodatna vnosna polja za vnos ve£ kot enega cilja.
• U£ni pristop � Tekstovno polje.
• U£ne oblike � Tekstovno polje.
• U£na sredstva in pripomo£ki � Tekstovno polje.
• Viri � Tekstovno polje.
Vnos zgradbe ure
Datoteka /WebObrazci/Priprava/PregledUre.zul.
88 PRILOGE
Slika 7.6: Vnos zgradbe ure
Seznam vnosnih polj za vsak vnos v tabeli na levi strani:
• Namen/Cilj � Tekstovno polje.
• �as � Tekstovno polje.
• Metode/Oblike � Tekstovno polje.
• Pripomo£ki � Tekstovno polje.
• Strategija doseganja � Polje za vnos obogatenega besedila. Polje v bazo zapi²e
HTML-kodo vnosa.
• Na£in preverjanja � Polje za vnos obogatenega besedila. Polje v bazo zapi²e
HTML-kodo vnosa.
Vnos podrobnega pregleda ure
Datoteka /WebObrazci/Priprava/PodrobniPregled.zul.
PRILOGE 89
Slika 7.7: Vnos podrobnega pregleda ure
Seznam vnosnih polj za vsak vnos v tabeli na levi strani:
• Namen � Tekstovno polje.
• Dejavnost u£itelja � Polje za vnos obogatenega besedila. Polje v bazo zapi²e
HTML-kodo vnosa.
• Dejavnost u£enca � Polje za vnos obogatenega besedila. Polje v bazo zapi²e
HTML-kodo vnosa.
• Tabelska slika � Polje za vnos obogatenega besedila. Omogo£eno je dodajanje
slik. Polje v bazo zapi²e HTML-kodo vnosa.
90 PRILOGE
Vnos dejavnosti za u£no ²ibkej²e in u£no zmoºnej²e u£ence
Datoteka /WebObrazci/Priprava/DodatneDejavnosti.zul.
Slika 7.8: Vnos dejavnosti za u£no ²ibkej²e in u£no zmoºnej²e u£ence
Seznam vnosnih polj:
• Dejavnosti za u£no ²ibkej²e u£ence � Polje za vnos obogatenega besedila. Polje
v bazo zapi²e HTML-kodo vnosa.
• Dejavnosti za u£no zmoºnej²e u£ence � Polje za vnos obogatenega besedila.
Polje v bazo zapi²e HTML-kodo vnosa.
Naloge
Obrazec za izdelavo naloge
Datoteka /WebObrazci/Naloge/DodajNalogo.zul.
PRILOGE 91
Slika 7.9: Obrazec za izdelavo naloge
Seznam vnosnih polj:
• Naslov � Tekstovno polje.
• Datum zaklju£ka � Datumsko polje. Poleg ro£nega vnosa je omogo£ena ²e izbira
datuma s pomo£jo koledarja.
• Navodilo � Polje za vnos obogatenega besedila. Polje v bazo zapi²e HTML-kodo
vnosa.
Seznam vnosnih polj za vsak vnos v tabeli:
• Tip komponente � Spustni seznam.
• Id komponente za bazo � Tekstovno polje. Po potrditvi vnosa se preveri, ali tak
vnos v bazi za obstoje£o nalogo ºe obstaja.
92 PRILOGE
• Dodatno polje � Ve£vrsti£no vnosno polje.