univerza v ljubljani pedago ka fakultetapefprints.pef.uni-lj.si/4216/1/diploma-juresimon.pdf ·...

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.


• 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


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.


• 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


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.


• 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.


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).


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.


• 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,


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


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


• 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".


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


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


• �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


• 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.


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


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.


• 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.


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.


• 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.


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.


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


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


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 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:


• 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.


• 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.


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


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.


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


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.


� 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.


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




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.


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




nazaj na korak za urejanje podrobnega pregleda ure.

Zaslonske slike in seznam vnosnih polj se nahajajo v Prilogi 3.


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:


• 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-





• 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.


• 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-





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.


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.


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


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.


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


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).


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.

pdf

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

http://www.ambysoft.com/essays/agileManifesto.html

https://subversion.apache.org/docs/release-notes/

https://subversion.apache.org/docs/release-notes/

https://www.atlassian.com

https://www.atlassian.com

http://www.benderrbt.com/Bender-SDLC.pdf

http://www.benderrbt.com/Bender-SDLC.pdf

https://bitnami.com/stack/xampp

https://bitnami.com/stack/xampp

https://www.openhub.net/repositories/compare

https://www.openhub.net/repositories/compare

http://www.idesignstudios.com/blog/web-design/phases-web-design-development-process/#.Vt3bHObo47w

http://www.idesignstudios.com/blog/web-design/phases-web-design-development-process/#.Vt3bHObo47w

https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/SelectingDevelopmentApproach.pdf



http://www.uoitc.edu.iq/images/documents/informatics-institute/Competitive_exam/Systemanalysisanddesign.pdf



https://www.justice.gov/archive/jmd/irm/lifecycle/table.htm

https://www.justice.gov/archive/jmd/irm/lifecycle/table.htm

https://www.eclipse.org/

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

https://www.apachefriends.org/index.html

https://www.apachefriends.org/index.html

https://git-scm.com

https://netbeans.org/downloads/index.html

https://netbeans.org/downloads/index.html

https://netbeans.org/community/releases/roadmap.html

https://netbeans.org/community/releases/roadmap.html

http://sce.uhcl.edu/helm/REQ_ENG_WEB/My-Files/mod4/Software_Prototyping.pdf

http://sce.uhcl.edu/helm/REQ_ENG_WEB/My-Files/mod4/Software_Prototyping.pdf

https://software-security.sans.org/resources/paper/cissp/comparison-software-development-lifecycle-methodologies

https://software-security.sans.org/resources/paper/cissp/comparison-software-development-lifecycle-methodologies

https://angel.co/taiga-agile/activity

https://angel.co/taiga-agile/activity

https://en.wikipedia.org/wiki/Chaos_model

https://en.wikipedia.org/wiki/Chaos_model

https://en.wikipedia.org/wiki/Jira_(software)

https://en.wikipedia.org/wiki/Jira_(software)

https://en.wikipedia.org/wiki/NetBeans

https://en.wikipedia.org/wiki/NetBeans

https://en.wikipedia.org/wiki/Software_development_process

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

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


• 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


• Opazovani vidik ure � Tekstovno polje.

86 PRILOGE

• Opaºanja z opazovanim vidikom � Polje za vnos obogatenega besedila. Polje v


• 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


• 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


• 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


• 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


• 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.

univerza v ljubljani pedago ka fakultetapefprints.pef.uni-lj.si/4216/1/diploma-juresimon.pdf ·...

Documents