DIPLOMSKO DELO

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

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

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

• reeksijo 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 modicira 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 identicirati priloºnost za izbolj²avo oziroma odpravo pomanjkljivosti obstoje£ega sistema glede na potrebo podjetja. Identicirati 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 denira. Poudarek je na deniciji 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 denirane funkcije v specikacijo, 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 denirajo 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, denirane 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 deniran in dokumentiran.

1.2 Modeli razvoja

Z namenom laºjega razumevanja in implementacije faz SDLC so ustvarili razli£ne metodologije oziroma modele razvoja. Ti nenehno nastajajo, saj nove tehnologije ponujajo nove moºnosti (Purcell, 2016). Nekaj pogostej²ih modelov:

• model slapa (Waterfall model),

• izdelava prototipov (Software prototyping),

• spiralni model,

• RAD (Rapid application development),

• agilni razvoj (Agile software development),

• drugi modeli: model kaosa, po£asno programiranje, V-model in drugi,

• naredi in popravi (Code and x).

1.2.1 Model slapa

Model slapa je ena najstarej²ih metod. Najbolj o£itna lastnost tega modela je se- kven£ni proces korakov od analize zahtev do vzdrºevanja (Purcell, 2016). Osnovni principi modela so na²teti spodaj.

• Projekt je razdeljen v ve£ zaporednih faz, kjer je dopu²£eno manj²e prekrivanje in prehajanje nazaj med fazami.

8 Postopek na£rtovanja aplikacije

• Poudarek je na na£rtovanju, urnikih, ciljnih datumih, stro²kih in implementaciji celotnega sistema do dolo£enega roka.

• Strog nadzor se vzdrºuje s pomo£jo pisanja obseºne dokumentacije, nenehnih pregledov in potrjevanja trenutnega stanja pred prehodom na novo fazo (CMS, 2008).

Glavna slabost tega modela je, da po fazi zbiranja zahtev ni ve£ moºnosti, da bi te zahteve dopolnili, £e se spremenijo med razvojnim procesom, ko se pojavijo nove informacije. Ker pa se potrebe skoraj vedno spremenijo skozi dolgotrajni razvojni proces, je produkt na koncu razvojnega cikla pogosto ºe zastarel in neuporaben.

Zato je ta model neprimeren za dalj²e in kompleksnej²e projekte oziroma projekte, kjer zahteve niso natan£no denirane º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 denirane ºe na za£etku razvojnega cikla in je podro£je projekta ºe dobro znano (Purcell, 2016).

1.2.2 Spiralni model

Spiralni model je nastal kot odziv na slabosti modela slapa. Model deluje tako, da razvijalec za£ne z manj²im naborom zahtev in izvede vse faze razvojnega cikla pred name²£anjem. Nato na podlagi pridobljenih znanj zavrtijo krog ²e enkrat in med postopkom dodajajo nove funkcionalnosti na podlagi zahtev, ki so se med prej²njo iteracijo pojavile. Na ta na£in se aplikacija dopolnjuje, dokler ne zadosti vsem zah- tevam in je pripravljena na namestitev na produkcijsko okolje. Vsaka iteracija pred produkcijsko verzijo je prototip aplikacije (Purcell, 2016).

Prednost tega modela v primerjavi z modelom slapa je, da iterativni pristop omo- go£a, da se razvoj za£ne tudi, £e ²e niso znane vse zahteve projekta. S testiranjem vsakega prototipa se na podlagi ugotovitev aplikacija prilagodi v naslednji iteraciji.

Vsaka iteracija prototipa odgovori na to, ali bo sistem uporaben ali ne (Purcell, 2016).

Osnovni principi modela so:

• Fokus je na oceni tveganja in na zmanj²anju tveganosti projekta z razdelitvijo na manj²e segmente, kar omogo£i laºje spreminjanje in popravljanje med procesom

1.2 Modeli razvoja 9 razvoja ter moºnosti za evalvacijo tveganja in razmislek o ºivljenjskem ciklu projekta.

• Vsak cikel vklju£uje prehode med enakim zaporedje korakov.

• Vsak obhod spirale ima ²tiri kvadrante: Dolo£itev ciljev, alternativ in omeji- tve ponovitve; Evalvacija alternativ, identikacija tveganj in njihova odprava;

Razvoj in preverjanje izsledkov iteracije; Na£rtovanje naslednje iteracije.

• Vsak cikel se za£ne z identikacijo deleºnikov in njihovih pogojev za uspeh.

Vsak cikel se zaklju£i s pregledom, oceno in zavezanostjo k naslednjemu ciklu -(CMS, 2008).

1.2.3 Izdelava prototipov

Model temelji na izdelavi prototipov aplikacije. To so nedokon£ane verzije aplikacije, ki se razvija. Cilj je simulirati le nekaj vidikov aplikacije. Ti prototipi so lahko pov- sem druga£ni od kon£nega izdelka.

Prednosti tega modela so, da lahko razvijalec od uporabnikov dobi odziv ºe zgodaj v razvoju (CMS, 2008).

Osnovni principi tega modela so:

• Model ni samostojna razvojna metodologija ampak le del ve£je bolj tradicio- nalne metodologije. Pogosto nastopa skupaj z inkrementalnim razvojem, RAD ali spiralnim razvojem.

• Poizku²a razbiti projekt na manj²e, bolj obvladljive kose in pomaga pri eno- stavnej²emu spreminjanju med samim razvojnim procesom.

• Kon£ni uporabnik oziroma primer kon£nega uporabnika je prisoten ves razvojni proces.

• Razvijajo se manj²i kosi sistema. Ta se z vsako iteracijo razvija v popolnej²i prototip, ki ustreza zahtevam uporabnikov.

• ƒeprav je ve£ina prototipov izdelanih z zavedanjem, da se bodo zavrgli, se nekateri razvijejo v delujo£ sistem.

10 Postopek na£rtovanja aplikacije

• Pri pripravljanju prototipov mora biti razvijalec seznanjen z osnovno poslovno problematiko, da se s tem izogne re²evanju napa£nih problemov (CMS, 2008).

Tipi prototipov:

• Izdelava prototipov, ki se po uporabi zavrºejo/Hitra izdelava proto- tipov:

Temelji na modelu, ki se ga bo raje zavrglo, kot pa da bi postal del kon£ne re²itve. Prototip nastane na podlagi pridobljenih prvotnih zahtev. Z njim se vizualno prikaºe, kako naj bi bil videti kon£ni produkt. Ti prototipi nastanejo v zgodnjih fazah razvoja. Najve£ji dejavnik tu je hitrost, s katero je model izdelan.

S pomo£jo teh prototipov kon£ni uporabniki laºje preverijo svoja pri£akovanj in razjasnijo zahteve.

• Prototip, ki se razvija:

Glavni cilj tega tipa je izdelava prototipa, ki je strukturiran in ga je mogo£e dopolnjevati. Prototip je jedro novega sistema, ki se bo nadgrajevalo v celovit sistem. Sistem se nenehno izbolj²uje in prenavlja. Ta tehnika razvijalcem omo- go£a, da dodajo funkcionalnosti ali spremembe, ki jih med na£rtovanjem ni bilo mogo£e predvideti. Razlika v primerjavi s prej²njim tipom prototipov je ta, da so ti prototipi delujo£i sistemi.

• Inkrementalni prototipi:

Aplikacija ali sistem se razdelita na ve£ manj²ih delov oziroma funkcionalnosti.

Za vsako funkcionalnost se pripravi svoj prototip. Na koncu pa se vsi prototipi zdruºijo v delujo£ sistem, ki se ga ne spreminja razen v primeru napak (Puckett, 2001).

1.2.4 RAD

Model se je razvil s potrebo po hitrej²em razvoju programske opreme. Glavni novi princip te metodologije v primerjavi s starej²imi SDLC-modeli je uporaba prototipov.

Prototip nastane po hitri fazi zbiranja zahtev in je predstavljen uporabnikom. Po- vratna informacija teh uporabnikov nato nudi informacije, kako aplikacijo izbolj²ati.

Prednost tega modela je v skraj²anju £asa, potrebnega za objavo nove aplikacije, saj presko£i veliko korakov tradicionalnih SDLC-modelov, da zagotovi hitrost in niºjo ceno izdelave programske opreme. Slabost tega pa je, da je lahko ta proces v£asih

1.2 Modeli razvoja 11 prehiter in se lahko zgodi, da testiranje ni dovolj temeljito (Purcell, 2016).

Osnovni principi te metodologije so:

• Klju£ni cilj je hiter razvoj in posredovanje visokokakovostnega sistema pri rela- tivno majhni investiciji.

• Poizku²a reducirati tveganje pri projektu tako, da raz£leni projekt na manj²e segmente in nudi laºje vodenje sprememb skozi njihovo razvojno fazo.

• Cilj je hitro izdelovati visokokakovostne sisteme primarno skozi iterativne pro- totipe, aktivno vklju£evanje uporabnikov in prilagojenih razvojnih orodjih, ki razvijalcem pomagajo pri pisanju trivialne kode (seznam gradnikov, enostavnih privzetih funkcij in knjiºnic ipd.).

• Glavni poudarek je na izpolnjevanju poslovnih potreb.

• Nadzor nad projektom vklju£uje dolo£anje prioritet razvoja in deniranje rokov.

ƒe projekt za£ne odstopati od za£rtanih rokov, je poudarek na zmanj²anju zahtev in ne prestavljanje rokov.

• Pomembna je prisotnost aktivnih uporabnikov.

• Izdelava potrebne dokumentacije za prihodnji razvoj in vzdrºevanje (CMS, 2008).

’tiri razli£ne faze procesa RAD:

• Faza na£rtovanja:

V tej fazi se izvede proces s katerim se ugotovi zakaj je sistem potrebno zgraditi in kako se ga bo zgradilo. Faza se za£ne z iniciacijo, ko se pojavi potreba po spremembi. Na podlagi te zahteve se izvede analiza izvedljivosti. Ko je predlog potrjen se izvede ²e na£rtovanje projekta.

• Faza analize:

V tej fazi se poi²£e odgovore na vpra²anja, kdo bo sistem uporabljal, kaj bo sistem omogo£aj ter kje in kdaj se ga bo uporabljalo. V tej fazi se postavi zahteve na podlagi katerih nastane predlog koncepta sistema.

12 Postopek na£rtovanja aplikacije

• Faza oblikovanja:

V tej fazi se izvede oblikovanje sistema. V tej fazi nastane specikacija sistema, ki opisuje, kako bo sistem deloval, kako bo zgrajen uporabni²ki vmesni, kak²na bo podatkovna struktura in kak²na bo gra£na zasnova.

• Faza implementacije:

V tej fazi se sistem izdela. V tej fazi se izvede konstrukcija sistema, name- stitev in na£rt podpore. To je tudi najdalj²a faza v SDLC in zahteva najve£

pozornosti.(Dennis, Wixom, in Roth, 2011).

1.2.5 Agilni razvoj

Metodologija agilnega razvoja je skupina metodologij, ki so usmerjene v programira- nje in imajo fokus na racionalizaciji SDLC. Ve£ina modeliranja in obseºne dokumen- tacije je odstranjeno in nadome²£eno z osebno komunikcijo z naro£niki. Poudarek je na iteracijah aplikacije, kjer je vsaka iteracija svoj projekt z vsemi fazami SDLC (na£rtovanje, analiza zahtev, oblikovanje, pisanje programske kode, testiranje in do- kumentiranje) (Dennis in sod., 2011).

Dvanajst principov metodologije:

1. Zadovoljstvo stranke z zgodnjim in nenehnim dostavljanjem programske opreme.

2. Spreminjanje zahtev celo v poznej²i stopnji razvoja je dobrodo²lo.

3. Delujo£a programska oprema je dostavljena pogosto.

4. Nenehno sodelovanje kon£nih uporabnikov in razvijalcev.

5. Projekti so zgrajeni v krogu motiviranih zaupanja vrednih posameznikov.

6. Najbolj²a je osebna komunikacija.

7. Delujo£a programska oprema je merilnik napredka.

8. Trajnostni razvoj, ki lahko zdrºi stalni tempo.

9. Preprostost je klju£na.

10. Stalna skrb za tehni£no kakovost in dobro oblikovanje.

1.2 Modeli razvoja 13 11. Najbolj²e arhitekture, zahteve in dizajn nastanejo v samostojnih organiziranih

skupinah.

12. Delovne skupine pogosto razmi²ljajo o tem, kako postati ²e bolj u£inkovit in se temu prilagoditi (Ambler, 2014).

1.2.6 Drugi modeli

Model kaosa

Model kaosa pravi, da morajo vse faze ºivljenjskega cikla veljati za vse ravni projekta, od celote do kode.

• Celoten projekt mora biti deniran, implementiran in integriran.

• Sistem mora biti deniran, implementiran in integriran.

• Moduli morajo biti denirani, implementirani in integrirani.

• Funkcije morajo biti denirane, implementirane in integrirane.

• Vrstice kode morajo biti denirane, implementirane in integrirane.

Ena od pomembnih sprememb v perspektivi je, ali projekt ²tejemo za enoto ali za ve£ manj²ih kosov. Nih£e ne napi²e ve£ deset tiso£ vrstic kode naenkrat, pi²ejo jo postopoma in jo sproti preverjajo.

Glavno pravilo strategije kaosa je ta, da se najpomembnej²e teºave vedno re²ujejo prve.

Strategija kaosa je podoba na£ina dela, ki ga programerji uporabljajo proti koncu projekta, ko imajo seznam napak za odpravit ter funkcionalnosti za ustvarit. Nava- dno nekdo daje prednost preostalim nalogam, programerji pa jih popravljajo eno po eno. Strategija kaosa pravi, da je to edini pravi na£in dela (Wikipedia, 2014).

14 Postopek na£rtovanja aplikacije Naredi in popravi

Naredi in popravi oziroma s tujko code and x je antivzorec. Razvoj ni izveden skozi namerno strategijo oziroma metodologijo, ampak je pogosto rezultat £asovnega priti- ska na razvojno ekipo. Razvijalci za£no kodo pisati brez vnaprej dolo£enega dizajna, ki bi jih zadrºeval. Testiranje se za£ne med samim razvojem pogosto zelo pozno v razvojnem ciklu. Pred izdajo programske opreme pa je treba odpraviti vse napake oziroma tako imenovane hro²£e, ki so nastali med razvojem (Wikipedia, 2016c).

1.3 Izbira modela razvoja

Zaradi na£ina dela in pomanjkanja izku²enj ter samostojnega dela sem pri razvoju uporabil ve£ tipov modelov. Na za£etku projekta sem uporabil elemente metode RAD:

• Za£el sem z zbiranjem informacij. V tem koraku sem najprej poiskal in pregledal dokumente, ki smo jih med ²tudijem oddajali na profesorjevi spletni strani.

Tako sem dobil seznam vseh tipov dokumentov oziroma nalog, za katere bo aplikacija omogo£ala izdelavo oziroma oddajo. Preveril sem, kak²na programska ogrodja obstajajo in ali bi katero od njih bilo primerno. Preu£il sem, katere metode razvoja obstajajo in katera bi bila najprimernej²a za moj na£in dela.

• Izdelal sem idejno zasnovo aplikacije glede na zbrane podatke. Sem spadajo seznam funkcionalnosti ter seznam zaslonov, ki jih bo vklju£eval, in izdelava podatkovnega modela. Izrisal se tudi okvirno postavitev teh zaslonov.

• Dizajn aplikacije sem izdelal skupaj z delujo£im prototipom. Pri prvem proto- tipu se ²e nisem osredoto£il na gra£no zasnovo, ta je pri²la v kasnej²ih verzijah prototipa. Pri prvem prototipu pa sem uporabil gradnike, ki mi jih je ºe ponu- jalo izbrano programsko ogrodje (Framework).

Razen nekaj govorilnih ur, ko sem profesorjem na fakulteti predstavil prototip aplika- cije, v razvoj nisem vklju£eval drugih kon£nih uporabnikov. Razvoj kode je potekal s pomo£jo izdelave prototipov:

• Projekt sem razdelil na manj²e kose in razvil vsakega posebej. Naslednjega sem se lotil, ko je bil prej²nji kon£an.

1.3 Izbira modela razvoja 15

• Uporabil sem metodo inkrementalnih razvijajo£ih se prototipov, saj so se ti na koncu zdruºili v delujo£ sistem.

• Testiranje delovanja sem izvajal na vsakem kosu posebej.

Ko so bili vsi prototipi izdelani in zdruºeni v en sistem, sem izvedel evalvacijo celo- tnega sistema ter na podlagi ugotovitev pripravil na£rt sprememb. Pri tem so funk- cionalnosti ostale enake. Spremembe so bile vezane predvsem na gra£no zasnovo ter postavitev elementov na dolo£enih zaslonih.

Po uveljavitvi vseh sprememb sem sistem ponovno testiral. Vse ugotovljene teºave in napake sem si zabeleºil. Za odpravo teh napak sem uporabil model kaosa:

• Najprej sem odkril in deniral 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 reeksije 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, preddenirane 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 deniranih 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 identika- 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 reeksije, vezane na opazovani vidik, mnenje o izvedbo ter cilje ure.

• Vnosni obrazec za u£no pripravo Obrazec omogo£a vnos osnovnih podatkov o u£ni uri, kot so datum, mentor, naslov, tema, sklop, enota, speci£ni u£ni cilji ter pripomo£ki. Poleg osnovnih podatkov obrazec omogo£a ²e izdelavo zgradbe ure ter izdelavo podrobne zgradbe ure.

• Vnosni obrazec za pripravo nalog Obrazec omogo£a enostavno izdelavo na- loge. V obrazec se vna²a naslov, uvod, rok oddaje ter struktura naloge oziroma postavitev in tipi vnosnih polj.

• Vnosni obrazec za oddajo naloge Obrazec se zgradi glede na podatke, vne- sene v obrazec za pripravo naloge.

• Forma za oddajo dnevnika prakse Obrazec je namenjen oddaji dnevnika prakse. Omogo£a vnos osnovnih podatkov o praksi, kot so podatki o ²oli, vnos mentorja, urnik prakse in druge informacije. Poleg tega omogo£a ²e vklju£itev dokumentov (hospitacije, u£ne priprave), ki jih ²tudent med prakso vna²a v aplikacijo.

3.3 Zasloni aplikacije

• Prijavno okno

Zaslon vsebuje prijavno okno z vnosnimi polji za uporabni²ko ime in geslo ter gumb za prijavo. Po kliku na gumb se preveri pravilnost vnesenih podatkov.

V primeru napa£nega gesla, ali £e uporabnik ne obstaja, se na zaslonu izpi²e opozorilo, sicer pa je uporabnik preusmerjen na prijavno stran.

24 Zasnova aplikacije

• Doma£a stran

Zaslon vsebuje hitre povezave do posameznih seznamov dokumentov in nalog.

Moºna raz²iritev zaslona je, da se poleg povezav do seznamov dodajo ²e podatki o uporabniku, kot so ime, priimek, vpisna ²tevilka, seznam predmetov, zadnji komentarji in podobno.

• Stran s vnesenimi hospitacijami

Zaslon vsebuje seznam vseh vnesenih hospitacij za izbrani predmet. Dokumenti so razporejeni od najnovej²ega do najstarej²ega. Vsak vnos vsebuje podatek o naslovu ure, ter datumu hospitacije.

• Stran z vnesenimi u£nimi pripravami

Zaslon vsebuje seznam vseh vnesenih u£nih priprav za izbrani predmet. Do- kumenti so razporejeni od najnovej²ega do najstarej²ega. Vsak vnos vsebuje podatek o naslovu ure ter datum u£nega nastopa.

• Stran z nalogami

Zaslon vsebuje seznam vseh nalog in je razdeljen glede na status. V vsakem razdelku so naloge razporejene od najnovej²e do najstarej²e. Vsak vnos vsebuje podatek o naslovu naloge ter roku oddaje. Razdelki pa so:

Neaktivne naloge. Ta razdelek se prikazuje le profesorjem in vsebuje se- znam ²e neaktivnih nalog. Te naloge lahko profesor ²e spreminja in pre- gleduje.

Aktivne naloge. Ta razdelek prikazuje seznam vseh aktivnih nalog. ’tu- dentje lahko tu naloge izpolnjujejo, ko pa so te izpolnjene, jih lahko do spremembe statusa ²e spreminjajo. Profesorji pa lahko do spremembe sta- tusa to nalogo ro£no zaklju£ijo.

Zaklju£ene naloge. Ta razdelek vsebuje seznam zaklju£enih nalog. ’tuden- tje lahko s klikom na posamezni vnos pregledujejo vnose, ki jih ne morejo spreminjati. Poleg vnosov se prikaºe tudi komentar profesorja, £e je ta ºe vnesen. Profesor s klikom na nalogo odpre seznam vseh oddanih vnosov za izbrano nalogo.

• Stran za vnos hospitacije

Zaslon oziroma obrazec se razdeli na tri korake.

3.3 Zasloni aplikacije 25 Prvi korak vsebuje vnosna polja za vpis osnovnih podatkov ure, ki jo upo- rabnik hospitira. To so naslov ure, izvajalec, mentor/-ica (o²/s²), datum, ura, razred, ²ola, u£na tema, u£ni sklop in u£na enota.

Drugi korak (Vidik A) vsebuje vnosna polja za opis ure, to so kratek opis u£ne ure, pristop, vpra²anje, ki bi ga zastavili u£iteljici, ter mnenje o or- ganizaciji.

Tretji korak pa omogo£a opis in vnos opaºanj glede opazovanega vidika.

Podatki, ki se tu vnesejo, so opaºanja, mnenje, kako bi ravnali, razlaga opaºanj, zakaj je vidik pomemben ter razlaga za vse vnesene premisleke.

• Stran za vnos u£ne priprave

Zaslon oziroma obrazec se razdeli na ²tiri korake.

Prvi korak vsebuje vnosna polja za vpis osnovnih podatkov o uri u£nega nastopa. To so naslov ure, izvajalec (²tudent), mentor/-ica (o²/s²), datum, ura, razred, ²ola, u£na tema, u£ni sklop, u£na enota, speci£ni u£ni cilji, u£ni pristop, u£ne oblike, u£ne metode, u£na sredstva in pripomo£ki ter viri.

Drugi korak vsebuje vnosna polja za izdelavo zgradbe ure. Zgradba ure se pripravi tabelari£no. Za vsak vnos v tabeli je potrebno vnesti naslednje podatke: namen/cilj, £as (v min), ki ga bomo pri tem delu ure porabili, metode/oblike, pripomo£ki, opis strategije doseganja ter na£in preverjanja le-tega.

Tretji korak vsebuje vnosna polja za izdelavo podrobnej²ega pregleda ure.

Pregled se prav tako pripravi tabelari£no. Za vsak vnos v tabeli je po- trebno vnesti podatke o namenu oziroma cilju, dejavnosti u£itelja, dejav- nosti u£enca in tabelski sliki.

ƒetrti korak pa vsebuje vnosna polja za opis dejavnosti, ki so namenjene u£no ²ibkej²im u£encem, ter opis dejavnosti, ki so namenjene u£no zmo- ºnej²im u£encem.

• Stran za pripravo naloge

Zaslon vsebuje polja za vnos osnovnih podatkov o nalogi ter polja za vnos zgradbe naloge. Osnovni podatki so naslov, datum zaklju£ka oziroma rok ter navodilo. Zgradba naloge pa se prikaºe tabelari£no. Vsak vnos v tabeli vsebuje podatek o tipu komponente (vnosno polje, izbirno polje, urejevalnik besedila,

26 Zasnova aplikacije oddaja datoteke, oddaja priprave, oddaja hospitacije ...), ID-oznaki polja (za vnos v podatkovno bazo) ter dodatno polje za dolo£itev dodatnih lastnosti polja (spremni tekst, izbire za izbirno polje). Zaslon poleg gumba za shranjevanje omogo£a ²e predogled ter gumb za aktiviranje naloge.

• Stran za predogled naloge

Preden profesor nalogo aktivira, ima moºnost, da pogleda njeno zgradbo. Na ta na£in dobi predstavo, kako se bo naloga prikazovala. Do zaslona lahko profesor dostopa s klikom na gumb za prikaz predogleda na zaslonu za pripravo naloge.

Odpre se novo okno, ki vsebuje vneseno zgradbo naloge.

• Stran za vnos in oddajo naloge

Ko profesor nalogo aktivira, se ta prikaºe v seznamu nalog tudi ²tudentom. S klikom na vnos se odpre naloga glede na zgradbo, ki je bila za to nalogo vnesena (prikaºe se enaka zgradba, kot jo profesor vidi v predogledu naloge).

• Stran s pregledom oddanih del za posamezno nalogo

Zaslon profesorjem za izbrano nalogo omogo£a tabelari£ni pregled ²tudentov, ki so nalogo oddali. S klikom na vnos se odpre novo okno z vnesenimi odgovori.

Pod nalogo se prikaºe dodatno polje, kamor lahko profesor vnese komentar. Ta komentar se nato prikaºe na nalogi, £e jo ²tudent odpre po tem, ko je bila naloga ºe zaklju£ena.

Poglavje 4

Izdelava aplikacije

V tem poglavju bom opisal izdelavo aplikacije. Najprej bom opisal orodja, ki sem jih pri razvoju uporabil, nato pa podrobno ²e zgradbo aplikacije.

4.1 Orodja

Pri izbiri orodja sem se osredoto£il na tista, ki sem jih ºe spoznal v £asu ²tudija in

²tudentskega dela.

4.1.1 Razvojna okolja

Zaradi dobrega poznavanja programskega jezika JAVA sem izbiral med orodjema Eclipse in Netbeans. Z obema sem se ºe sre£al v £asu ²tudentskega dela. Obe orodji sta brezpla£ni in imata dobro podporo. Vsako ima svoje prednosti in slabosti.

Eclipse

Prva verzija orodja je iz²la ºe leta 2004 z oznako Eclipse 3.0. Nova edicij od takrat iz- ide vsak junij. Do danes je iz²lo ºe 13 edicij. Leto²nja se imenuje Neon (Eclipse, 2016).

27

28 Izdelava aplikacije

Slika 4.1: Okno Eclipse IDE

Eclipse je eno bolj priljubljenih razvojnih okolij, saj omogo£a razvoj v ²tevilnih pro- gramskih jezikih. Nekateri od njih so:

• Java,

• C/C++,

• Python,

• Ruby,

• Perl,

• Fortran,

• COBOL,

• PHP,

• JavaScript.

Poleg zgoraj na²tetih pa omogo£a ²e pisanje dokumentov LaTeX s pomo£jo vti£nikov.

4.1 Orodja 29 Distribucija Eclipsa vklju£uje kar nekaj osnovnih verzij aplikacijskih streºnikov, glavni med njimi je Apache Tomcat. Dodatno omogo£a ²e enostaven prenos in namestitev drugih popularnih streºnikov za poganjanje aplikacij, razvitih v razli£nih programskih jezikih.

Zaradi popularnosti orodja obstaja veliko ²tevilo vti£nikov, ki razvijalcu olaj²ajo delo.

Poleg vti£nikov pa obstaja ²e veliko prilagojenih orodij, ki izhajajo iz Eclipse oziroma je to njihovo ogrodje. Nekateri od njih so:

• Adobe Flash builder Orodje za razvoj Flash aplikacij.

• Aptana Orodje za razvoj spletnih aplikacij.

• IBM Rational distribucije Orodje za razvoj aplikacij v okoljih IBM. Po- sebnost teh edicij je, da imajo prilagojene elemente in knjiºnice, ki so testno povezani s produkti IBM, kot so Lotus Notes, IBM Websphere Aplication Ser- ver, IBM Websphere Portal in drugi.

Povezava s podjetjem IBM ni naklju£je, saj je ekipa IBM sodelovala pri razvoju prve verzije orodja.

• XMind Orodje za izdelavo diagramov in miselnih vzorcev.

Seznam je dostopen na povezavi https://en.wikipedia.org/wiki/List_of_Eclipse-based_software.

Eno od teh orodij je tudi ZK studio, ki je namenjen razvoju aplikacij v program- skem ogrodju ZK. Za enostavnej²i razvoj gra£nega vmesnika orodje ponuja paleto elementov, ki jih na na£in "povleci in spusti"postavimo na stran.

Namen teh orodij je, da uporabniku poenostavijo izdelavo aplikacij.

Netbeans

Alternativa Eclipsu je orodje Netbeans. Orodje je nastalo leta 1996 kot ²tudentski projekt. Leta 1999 ga je kupilo podjetje SUN, ki ga je junija leta 2000 objavilo kot odprtokodni sistem (Wikipedia, 2016b).

Tako kot Eclipse verzije orodja NetBeans izhajajo ve£inoma do dvakrat na leto in

30 Izdelava aplikacije s tem skrbijo za odpravo napak ter dodajanje vedno novih funkcionalnosti (Netbe- ans, 2016b).

Slika 4.2: Okno Netbeans IDE Omogo£a razvoj v naslednjih programskih jezikih:

• Java (Web in EE),

• C/C++,

• PHP ,

• Groovy.

Na spletni strani ponujajo razli£ne verzije sistema glede na programski jezik razvoja.

Najobseºnej²i distribucijski paket, ki obsega vse funkcionalnosti, vklju£uje aplikacij- ska streºnika Apache Tomcat in GlassFish (Netbeans, 2016a).

Ker gre za odprtokodno orodje, za NetBeans obstaja veliko ²tevilo uradnih in ne- uradnih vti£nikov in knjiºnic, ki jih lahko sami namestimo v sistem in nam olaj²ajo delo. Eden od teh vti£nikov je REM modul za ZK, ki tako kot ZK studio ponuja

4.1 Orodja 31 paleto elementov za enostavnej²o izdelavo in razvoj gra£nih vmesnikov in zalednih funkcionalnosti.

4.1.2 Streºni²ka infrastruktura

• Apache Tomcat

Za aplikacijski streºnik sem izbral Apache Tomcat. Streºnik je tako del distri- bucije Eclipse kot distribucije NetBeans in zado²£a za razvoj. Za produkcijsko verzijo aplikacije za moºnosti vodenja kontrole nad izvajanjem aplikacije pa pre- dlagam katero bolj celovito re²itev, kot je na primer Oracle Weblogic ali RedHat JBoss. Slednja omogo£ata veliko ve£ funkcionalnosti ter gra£ni vmesnik, ki olaj²a pregled delovanja name²£enih aplikacij.

Apache Tomcat sicer prav tako omogo£a vpogled v delovanje aplikacij, ven- dar ima le spletni gra£ni vmesnik, ki je dokaj okoren in ne ponuja enostavnega pregleda dogajanja. Zato se raje kot na spletni vmesnik zatekamo k pregledo- vanju dnevni²kih datotek, ki jih poleg osnovnih dogodkov lahko polnimo tudi sami s pomo£jo klicev dolo£enih metod v na²i aplikaciji.

Slika 4.3: GUI-vmesnik za streºnik Apache Tomcat

32 Izdelava aplikacije

• XAMPP Orodje, ki sem si ga izbral za poganjanje programske opreme po- datkovne baze, je XAMPP. Kratica XAMPP pomeni ƒross-patform Apache MySQL PHP Perl". Orodje je mogo£e namestiti na razli£ne operacijske sisteme in se uporablja za poganjanje spletnega streºnika Apache za spletna programska jezika PHP in Perl ter za poganjanje podatkovnih baz MySQL (Friends, 2016).

Slika 4.4: Nadzorna plo²£a orodja XAMPP

Uporabil sem ga zato, ker omogo£a poganjanje podatkovnih baz MySQL. Ta- k²na oblika dela mi je pohitrila delo, saj je orodje samo namestilo vse potrebno, da sem podatkovne baze lahko pri£el uporabljati. V nasprotnem primeru bi imel veliko dela s samo konguracijo podatkovne baze.

XAMPP je namenjen hitremu razvoju spletnih aplikacij in zato vklju£uje nekaj osnovnih orodij, ki uporabniku olaj²ajo delo. Eno od teh orodij je orodje za upravljanje podatkovnih baz phpMyAdmin. S pomo£jo modula Bitnami for XAMPP pa omogo£imo, da lahko na orodje namestimo enega od popularnih sistemov CMS in LMS ter druge uporabne spletne aplikacije (Bitnami, 2016).

Kljub zmogljivosti pa je streºnik namenjen razvoju in za uporabo kot produkcij- ski streºnik, saj ne omogo£a avtomatskega posodabljanja posameznih elementov in jih je potrebno posodobiti ro£no.

4.1 Orodja 33

4.1.3 Orodje za upravljanje podatkovnih baz

• phpMyAdmin

Orodje je del sistema XAMPP in omogo£a urejanje podatkov in strukture v podatkovni bazi MySQL. PhpMyAdmin je spletna aplikacija, napisana v pro- gramskem jeziku PHP in jo poganja aplikacijskih streºnik Apache.

Slika 4.5: Okno phpMyAdmin

Orodje je ºe nastavljeno in razvijalcu prihrani £as, ki bi ga zapravil z nasta- vljanjem orodja. Pregleden in bogat uporabni²ki vmesnik uporabniku omogo£a enostavno upravljanje podatkovnih baz. Tu lahko ureja strukturo posamezne baze, ustvarja nove tabele, izvaja poizvedbe in ukaze SQL, upravlja uporabnike in ²e mnogo drugih operacij.

• MySQL Workbench

Orodje je, tako kot phpMyAdmin, namenjeno pregledu in urejanju podatkovnih baz MySQL. Poleg osnovnih operacij, kot so urejanje strukture podatkovne baze ali sheme, izvajanje poizvedb in ukazov SQL, upravljanje uporabnikov in drugih operacij, sistem omogo£a tudi naprednej²e operacije. To so:

izdelava vizualizacije podatkovnega modela (model EER), migracija baze MySQL z enega streºnika na drugega, izvoz/uvoz baze,

varnostno kopiranje baze,

izdelava podatkovnega modela na podlagi obstoje£e baze oziroma tako imenovani "Reverse engineering".

34 Izdelava aplikacije

Slika 4.6: Okno MySQL Workbench

Orodje mi je pomagalo pri izdelavi podatkovnega modela. Z njegovo pomo-

£jo sem si laºje predstavljal, katere tabele so soodvisne med seboj in po katerih poljih jih lahko zdruºim. Z orodjem sem nato na podlagi vizualne sheme podat- kovnega modela izdelal skript, s katerim sem nato na podatkovni bazi ustvaril vse potrebne objekte.

4.1.4 Orodje za gra£no oblikovanje 4.1.5 Programske knjiºnice

• ZK

ZK je ogrodje, ki vsebuje paleto ºe pripravljenih elementov, ki jih razvijalec enostavno uvrsti na stran. Ogrodje temelji na programskem jeziku JAVA in spletnem jeziku HTML in je namenjeno izdelavi spletnih aplikacij. Glavne la- stnosti orodja:

enostavni klici AJAX,

vsebuje lastni UML (enotni jezik za modeliranje),

uporabni²ki vmesnik je napisan v programskem jeziku JAVA,

enostavno povezovanje spleta s podatkovno bazo (skriti klici AJAX in JSON),

4.2 Podatkovni model 35 lastni elementi za risanje grafov, prikaz tabel, razpredelnic in koledarja, veliko ²tevilo gradnikov,

²iroka podpora za brskalnike, ²tevilni prevodi v tuje jezike.

Na uradni spletni strani je poleg opisanih gradnikov tudi veliko ²tevilo prime- rov z izvorno kodo, na podlagi katere lahko gradnike vklju£i² v svojo spletno aplikacijo.

Dobra podpora pripomore k temu, da ga uporablja veliko ²tevilo znanih in manj znanih podjetij, saj je poleg proste oz. brezpla£ne verzije CE (£ommunity edition") na voljo tudi pla£ljiva verzija EE ("enterprise edition") za podjetja, ki vklju£uje z dodatno podporo in prilagoditve.

• docx4j

Docx4j je odprtokodna javanska knjiºnica, ki se uporablja za ustvarjanje in manipuliranje dokumentov DOCX, PPTX in XLSX, ki bi jih sicer izdelali s pomo£jo orodja Micorosoft Oce. 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 identikatorjem, ki je v primeru ²tudentov vpisna ²tevilka, v primeru

36 Izdelava aplikacije profesorjev pa mati£na ²tevilka ali druga enoli£na oznaka, pomembno je le, da se nobeden od identikatorjev 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 identikator povezani z entiteto Uporabniki.

• ’tudentje: Tu so shranjeni osnovni podatki o ²tudentih. Vnosi so preko polja identikator povezani z entiteto Uporabniki.

• ’tudijski program: Tu se nahajajo nazivi ²tudijskih programov.

• Predmet: Tu so shranjeni podatki o predmetu. Vnosi so povezani z entitetama Profesorji in ’tudentje preko vmesnih tabel.

• Hospitacija: Tu so shranjeni podatki o hospitirani uri. Podatki, ki se vna²ajo, opisujejo hospitirano uro, kdo je uro izvajal in temo ure. Vnosi so preko polja identikator povezani z entiteto Uporabniki.

• Vidik A: Tu so shranjeni podatki o opisu ure. Podatki so povezani s podatki v entiteti Hospitacija preko polja identikator.

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

• 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 identikator 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 identikator uporabnika povezujejo z entiteto Uporabnik. Preko polja identikator 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 identikator 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 identikatorju 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 konguracijske datoteke, datoteke za uporabni²ki vmesnik in da- toteke za zaledni sistem. Uporabni²ki vmesnik je spletna aplikacija, v zaledju pa se izvaja javanska koda. Struktura in organizacija teh datotek sta predstavljeni v Prilogi 1.

Pri programskih razredih sem jih poizkusil poimenovati glede na njihovo vlogo in na ta na£in zadostiti organizaciji, spletne datoteke pa sem razvrstil v mape glede na njihov namen.

38 Izdelava aplikacije

4.3.2 Prijavno okno

Slika 4.7: Prijavno okno

Prijavno okno vsebuje vnosna polja za vpis uporabni²kega imena in gesla. Po kliku na gumb Prijava se izvede klic AJAX na streºnik, kjer se preveri pravilnost oziroma veljavnost kombinacije. To se stori tako, da se najprej vzpostavi povezava povezava s podatkovno bazo in preveri ali v entiteti Uporabniki obstaja vnesena kombinacija.

ƒe ta obstaja, se v sejo uporabnika zapi²e njegov identikator in identikator 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 identikator in to ozna£imo z Boolovo kombinacijo sql/string. ƒe smo v metodo poslali identikator SQL-stavka, se pokli£e

²e metoda getSqlString objekta sqlStavki, ki vrne ºeleno SQL-poizvedbo. V objektu

4.3 Zgradba aplikacije 39 sqlStavki se hranijo SQL-stavki za poizvedbe in SQL-stavki za manipulacijo s po- datki.

SQL-stavek se nato poºene skupaj s podatki v spremenljivki parametri sql poizvedbe, ki se vna²a kot mnoºica.

Po rezultatu poizvedbe se nato sprehajamo s kazalci.

Drugi na£in za pridobivanje podatkov iz podatkovne baze pa je uporaba programskih predstavitev entitet. Ti razredi zdruºujejo vse moºne SQL-klice za izbrano entiteto.

4.3.4 Meni

Meni za profesorje

Slika 4.8: Meni za profesorje

Meni je razdeljen na tri podmenije:

• Datoteke: V podmeniju se nahajajo povezave do strani za izdelavo nove u£ne priprave, strani za izdelavo nove hospitacije, strani s pregledom vseh u£nih priprav profesorja in strani s pregledom vseh hospitacij profesorja. Poleg teh povezav se v podmeniju nahajata ²e gumb za tiskanje in gumb za odjavo.

Gumb tiskanje se omogo£i na strani za vnos in urejanje u£ne priprave in na strani za vnos in urejanje hospitacije.

S klikom na gumb Odjava se uporabnikova seja odstrani s streºnika in izpi²e iz aplikacije tako, da zahteva ponovno prijavo.

• Naloge:

V podmeniju se nahajata povezavi do strani za izdelavo nove naloge in strani s seznamom vseh nalog, ki jih je profesor ustvaril.

40 Izdelava aplikacije

• Pomo£:

V podmeniju se nahajata povezava za pomo£ in gumb za prikaz podatkov o aplikaciji.

S klikom na povezavo Pomo£ se odpre povezava za elektronsko po²to na elek- tronski naslov za podporo aplikacije.

S klikom na povezavo O programu pa se odpre prikazno okno, ki vsebuje osnovne podatke o aplikaciji.

Meni za ²tudente

Slika 4.9: Meni za ²tudente Meni je razdeljen na tri podmenije:

• Datoteke: V podmeniju se nahajajo povezave do strani za izdelavo nove u£ne priprave, strani za izdelavo nove hospitacije. Poleg teh povezav se v podmeniju nahaja ²e gumb za tiskanje in gumb za odjavo.

Gumb tiskanje se omogo£i na strani za vnos in urejanje u£ne priprave in na strani za vnos in urejanje hospitacije.

S klikom na gumb Odjava se uporabnikova seja odstrani s streºnika in izpi²e iz aplikacije tako, da zahteva ponovno prijavo.

• Pregled:

V podmeniju se nahajajo povezave do strani s pregledom vseh u£nih priprav

²tudenta, strani s pregledom vseh hospitacij ²tudenta in strani vseh nalog pred- meta.

• Pomo£:

V podmeniju se nahaja povezava za pomo£ in gumb za prikaz podatkov o apli- kaciji.

S klikom na povezavo Pomo£ se odpre povezava za elektronsko po²to na elek- tronski naslov za podporo aplikacije.

4.3 Zgradba aplikacije 41 S klikom na povezav O programu pa se odpre prikazno okno, ki vsebuje osnovne podatke o aplikaciji.

4.3.5 Vstopna stran

Slika 4.10: Vstopna stran

Vstopna stran je namenjena prikazu hitrih povezav do strani s pregledom vseh u£nih priprav ²tudenta, strani s pregledom vseh hospitacij ²tudenta in strani vseh nalog predmeta. Ta stran je enaka za profesorje in ²tudente.

4.3.6 Hospitacija

Aplikacija vsebuje dva tipa strani, vezanih na hospitacije. Prvi tip je vnosni obrazec, drugi pa je stran s seznamom. Razredi, ki se tu uporabijo, so:

• Hospitacije: To je programska predstavitev entitete (entitetni razred) Hospi- tacije v podatkovni bazi. Vklju£uje osnovne funkcije za nastavljanje parame- trov hospitacije. S pomo£jo metode shrani pa se naredi nov vnos v bazo.

• HospitacijeJpaController: je avtomatsko ustvarjen JPA-upravitelj za enti- teto Hospitacije. 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 entitete Vidik A. Tu so shranjene osnove funkcije in metode, ki laj²ajo in pohitrijo delo z entiteto. Avtomatsko ustvarjenim poizvedbam in funkcijam lahko dodamo svoje.