SVEUČILIŠTE U ZAGREBU FAKULTET PROMETNIH ZNANOSTI RAZVOJ SUSTAVA ZA UPRAVLJANJE REPOM STUDENTSKE SLUŽBE FAKULTETA PROMETNIH ZNANOSTI

Transcription

1 SVEUČILIŠTE U ZAGREBU FAKULTET PROMETNIH ZNANOSTI Neven Anđelović Ivan Cvitić Marko Gović RAZVOJ SUSTAVA ZA UPRAVLJANJE REPOM STUDENTSKE SLUŽBE FAKULTETA PROMETNIH ZNANOSTI Zagreb, 2013.

2 Ovaj rad izrađen je na Zavodu za informacijsko komunikacijski promet pod vodstvom doc. dr. sc. Ivane Ćavar i predan je na natječaj za dodjelu Rektorove nagrade u akademskoj godini 2012/2013.

3 POPIS KRATICA ASP CSS DBMS FCFS HCTM - Active Server Pages (aktivne poslužiteljske stranice) - Cascading Style Sheets (kaskadni stilski uzorci) - Database Management System (sustav upravljanja bazom podataka) - First Come First Served (prvi došao prvi poslužen) - Hawaii Council of Teachers of Mathematics (Vijeće predavača matematike, Hawaii) HTML - HyperText Markup Language (jezik za opis internetskih stranica ) IEEE JMBAG MSDNAA MVC OIB RQM SMS SQL UML - Institute of Electrical and Electronics Engineers (Institut inženjera elektrotehnike ) - Jedinstveni Matični Broj Akademskog Građana - Microsoft Developer Network Academic Alliance (Microsoft mreža za razvoj namijenjena akademskoj zajednici) - Model View Controller (Microsoft okruženje za razvoj Internet stranica) - Osobni Identifikacijski Broj - Referada Queue Management (naziv sustav upravljanja repom studentske službe čiji razvoj je prikazan ovim radom) - Short Message Service (usluga slanja kratkih tekstualnih poruka putem mobilnih terminalnih uređaja) - Structured Query Language (strukturirani jezik za upite) - Unified Modeling Language (jezik za ujedinjeno modeliranje) VB - Visual Basic (objektu usmjereni programski jezik ) XML - EXtensible Markup Language (jezik za označavanje podataka)

4 SADRŽAJ 1. UVOD PREGLED DOSADAŠNJIH ISTRAŽIVANJA SUSTAVI POSLUŽIVANJA Općenito o sustavima posluživanja Kendallova oznaka PROBLEM POSLUŽIVANJA KORISNIKA STUDENTSKE SLUŽBE FAKULTETA PROMETNIH ZNANOSTI Karakteristike sustava RQM@fpz Algoritam za procjenu očekivanog vremena do posluživanja OPIS TEHNOLOGIJA KORIŠTENIH PRI PROJEKTIRANJU I IZGRADNJI SUSTAVA Sustavi baza podataka Baza podataka Strukturirani jezik za upite Tehnologija ASP.NET Programski jezik C# RAZVOJ BAZE PODATAKA SUSTAVA RQM@fpz Utvrđivanje i analiza zahtjeva Modeliranje baze podataka Konceptualno modeliranje Logičko modeliranje Implementacija Pohranjena procedura dolazni Pohranjena procedura posluzivanje Pohranjena procedura dohvatneposluzenih Pohranjena procedura sljedecirednibroj Pohranjena procedura aktivnostradnogmjesta Pohranjena procedura prosjecnovrijemeposluzivanja Okidač trajanjeposluzivanja Okidač ocekivanovrijemedoposluzivanja Testiranje Održavanje... 34

5 7. RAZVOJ MODULA SUSTAVA Modul RQM.kiosk Modul RQM.služba Modul RQM.info Modul RQM.web MOGUĆNOSTI IMPLEMENTACIJE I PROŠIRENJA RAZVIJENOG SUSTAVA ZAKLJUČAK ZAHVALE LITERATURA SAŽETAK SUMMARY POPIS SLIKA PRILOG

6 1. UVOD Sustavi posluživanja u raznim oblicima oduvijek su prisutni u ljudskom društvu. Samim time prisutan je i rep, kao sastavni dio sustava posluživanja, ali i vrijeme čekanja u njemu. Brzim razvojem tehnologije uvidjela se mogućnost njezinog povezivanja sa razvijenom, matematički temeljenom, teorijom repova i sustava posluživanja. Objedinjavanjem dviju znanstvenih grana stvorena je osnovica za automatizacijom upravljanja repom u sustavima posluživanja. Potaknuti problemom čekanja korisnika u repu studentske službe Fakulteta prometnih znanosti, autori ovoga rada razvili su sustav RQM@fpz. Svrha razvijenog sustava je upravljanje repom studentske službe s ciljem pružanja veće kvalitete usluge i predstavlja prijedlog rješenja već spomenutog problema. Struktura ovoga rada podijeljena je unutar devet poglavlja uključujući uvod kao prvo i zaključak kao zadnje, deveto poglavlje. Unutar drugog poglavlja navedeno je nekoliko istraživanja i radova iz područja upravljanja repovima i sustava posluživanja koji su objavljeni u proteklih nekoliko godina. Trećim poglavljem ukratko je objašnjena teorija sustava posluživanja kao temelj razvoja algoritma za procjenu očekivanog vremena do posluživanja korisnika. Također, razjašnjena je i osnovna terminologija sustava posluživanja koju je nužno poznavati za daljnje razumijevanje tematike. U sklopu četvrtog poglavlja opisan je problem posluživanja korisnika studentske službe Fakulteta prometnih znanosti. Definirani su i Kendallovom oznakom opisani teoretski modeli na kojima se temelji posluživanje korisnika studentske službe, te je opisan i algoritam za procjenu očekivanog vremena do posluživanja korisnika. Za potrebe razvoja sustava korišteno je nekoliko tehnologija i programskih jezika koji su opisani petim poglavljem. Šestim poglavljem opisan je razvoj baze podataka sustava RQM@fpz od prikupljanja zahtjeva preko razrade konceptualnog, relacijskog i fizičkog modela, pa sve do njezine implementacije, testiranja i održavanja. U sklopu potpoglavlja kojim je opisana implementacija baze podataka opisane su pohranjene procedure i okidači korišteni u svrhu unosa, dohvata i obrade podataka. 1

7 Sedmim poglavljem opisan je razvoj četiri modula sustava modul RQM.kiosk, modul RQM.služba, modul RQM.info i modul RQM.web. Osim opisa razvoja prikazane su komponente od kojih se pojedini modul sastoji, te način rada i komunikacije sa bazom podataka. Osmim poglavljem ukratko je opisana mogućnost implementacije razvijenog sustava u već postojeći informacijsko komunikacijski sustav Fakulteta prometnih znanosti, te su navedene mogućnosti unaprjeđenja planiranih u budućnosti. 2

8 2. PREGLED DOSADAŠNJIH ISTRAŽIVANJA Teorija repa i sustavi posluživanja predmet su istraživanja dugi niz godina. Kako su sustavi posluživanja primjenjivi u mnogim znanstvenim i poslovnim granama, njihov razvoj, pa tako i razvoj sustava za upravljanje repom od velikog su značaja. Zbog brzog razvoja Internet mreže i velikog porasta količine mrežnih paketa koji se njome prenose često je predmetom istraživanja primjena teorije repa upravo u području upravljanja zagušenjem u Internet prometu. Usprkos važnosti i popularnosti Internet mreže, istraživanja vezana za upravljanje repom ne zaostaju niti u drugim područjima, te će u nastavku ovoga poglavlja biti navedena neka od relevantnih koja su provedena posljednjih godina. 1. Radom (Iannone, R. i sur. 2007), objavljenim na godišnjoj HCTM (engl. Hawaii Council of Teachers of Mathematics) konferenciji, prikazan je prijedlog modela za optimizaciju repa čekanja u zdravstvenim institucijama. Model je temeljen na kategorizaciji korisnika (pacijenata) prema prioritetima i planiranju kapaciteta infrastrukture koji se pridjeljuju korisnicima, [1]. 2. Istraživanjem (Wang, H. K., 2008), objavljenim u International Journal of Advanced Manufacturing Technology, analiziran je model sustava posluživanja sa konačnim kapacitetom izvorišta. Korisnici su grupirani u više klasa bez prioriteta gdje svaka klasa korisnika ima jednaku vjerojatnost za posluživanjem. Analizom su određeni optimalni kapacitet sustava i optimalan broj potrebnih poslužitelja, [2]. 3. Rad (Xiao, H., Zhang, G., 2010) objavljen u sklopu međunarodne IEEE (engl. Institute of Electrical and Electronics Engineers) konferencije opisuje primjenu teorije repa u optimizaciji pružanja bankovnih usluga. U radu je prikazan razvijeni model posluživanja koji opisuje posluživanje korisnika u bankama, prijedlozi podizanja kvalitete usluge primjenom izračunatog optimalnog modela posluživanja, te izračun optimalnog broja poslužitelja potrebnih za povećanje efikasnosti posluživanja, [3]. 4. U radu (Dao, R. i sur. 2011) objavljenom u sklopu međunarodne IEEE konferencije opisan je model optimizacije broja poslužitelja proizvodnog pogona sa stohastičkim dolascima korisnika pred sustav posluživanja, [4]. 3

9 5. Rad (Guo, P., Zhang, Z. G., 2013), objavljen u Manufacturing and Service Operation Management, opisuje sustav upravljanja repom u kojemu se poslužitelji dinamički mijenjaju u ovisnosti o duljini repa. Korisnici sustava posluživanja imaju mogućnost plaćanja naknade u svrhu povećanja prioriteta i bržeg dolaska na posluživanje. Pri ulasku u rep korisniku se dostavljaju osnovne statističke informacije poput očekivanog vremena boravka u repu i broja aktivnih poslužitelja, [5]. 4

10 3. SUSTAVI POSLUŽIVANJA 3.1. Općenito o sustavima posluživanja Sustavi posluživanja pojavljuju se u različitim inačicama i izvedbama, od posluživanja u bankovnim sustavima pa sve do obrade paketa u telekomunikacijskim čvorovima. Glavni cilj sustava posluživanja je postizanje što bolje kvalitete usluge za korisnike i upravljanje repom čekanja, [8]. Sustav posluživanja modeliran i opisan u ovom radu je implementiran na način da će izdati potvrdu s rednim brojem korisniku koji je upravo stigao, a službenica na radnom mjestu će, čim zatražena usluga postane dostupna, pozvati redni broj korisnika na posluživanje. Na taj način eliminira se potreba da korisnik fizički stoji u repu dok čeka na posluživanje. Sustavi posluživanja su sustavi u kojima postoje korisnici koji zahtijevaju uslugu od poslužitelja. Takvi sustavi su sačinjeni od tri glavna dijela: korisnik, rep i poslužitelj. Korisnik je osoba ili neki drugi entitet (npr. mrežni paket) koji zahtijeva posluživanje. Oni u sustav pristižu iz izvorišta, gdje se nalazi dolazno pučanstvo, odnosno, populacija. Izvorište se može smatrati beskonačno veliko ako je broj korisnika u izvorištu toliki da na vjerojatnost dolazaka korisnika na posluživanje ne utječe broj korisnika koji su prije otišli u sustav posluživanja i nalaze se ili u repu ili kod poslužitelja. U suprotnom, izvorište je konačno, [6]. Rep je skup korisnika koji čekaju na posluživanje, [6]. Rep se karakterizira maksimalnim brojem korisnika koji mogu istovremeno biti u njemu. Postoje dvije vrste repova: beskonačni i konačni repovi. Uobičajena pretpostavka je da je rep beskonačan, čak i u situacijama gdje postoji relativno velika gornja granica mogućeg broja korisnika u repu, zato što analiza sustava posluživanja postaje dodatno kompleksna ako je gornja granica mogućeg broja korisnika u repu velika. Poslužiteljsko mjesto je dio sustava posluživanja gdje se nalaze poslužitelji koji obavljaju posluživanje korisnika. Poslužitelj može biti osoba (npr. blagajnica) ili neki drugi entitet (npr. web poslužitelj). Bitne karakteristike poslužitelja su njihov broj i način rada. Broj poslužitelja može biti od jedan do neizmjerno, te se njihov broj može mijenjati ili ostati nepromjenjiv u vremenu. Za poslužitelje koji su međusobno isti i istodobno rade iste poslove, kaže se da rade serijski, a za poslužitelje koji su isti i istodobno rade različite poslove, kaže se da su paralelni, [6]. 5

11 Slikom 1 dan je shematski prikaz sustava posluživanja. Dolazni korisnici pristižu iz dolaznog pučanstva, te ulaze u sustav posluživanja. Ako rep ne postoji, korisnici direktno idu na posluživanje kod poslužitelja. U slučaju da je broj dolaznih korisnika veći nego broj korisnika koji se može poslužiti na poslužiteljima, stvara se rep. Način na koji korisnici ulaze u rep, kako se ponašaju i kako odlaze iz repa naziva se disciplina posluživanja. Dok korisnici borave u repu oni mogu odustati od čekanja ili čekati na posluživanje. Nakon što korisnik dođe do poslužitelja, te ga poslužitelj posluži, on izlazi iz sustava posluživanja. Slika 1: Shematski prikaz sustava posluživanja, [6] 3.2. Kendallova oznaka Sir Maurice Kendall je godine predložio skraćeni način opisivanja glavnih obilježja sustava posluživanja. Kendallova oznaka se sastoji od šest simbola, [6], [7]: A S s c p D Simbol A označava razdiobu međudolaznih vremena korisnika. Razdiobe mogu biti razne, te se označavaju slovima. M označava eksponencijalnu razdiobu, odnosno, eksponencijalno distribuirana vremena dolazaka korisnika, D označava determinističku razdiobu gdje su vremenski intervali konstantni, E k označava Erlangovu razdiobu k-tog reda, G označava opću, tj. proizvoljnu distribuciju vremenskih intervala. Simbol S definira razdiobu trajanja posluživanja. Vrste razdioba su iste kao za međudolazna vremena. Simbol s označava broj istovrsnih paralelnih poslužitelja. Ako se radi o zapisu C(n), tada se radi o C broju serijskih poslužitelja spojenih u n koraka ili stadija. 6

12 Simbol c prikazuje kapacitet sustava, tj. najveći dopušteni broj korisnika u sustavu posluživanja, dok simbol p prikazuje kapacitet izvorišta kao najveći dopušteni broj korisnika u izvorištu. Posljednji simbol označava disciplinu posluživanja u konkretnom sustavu posluživanja. 7

13 4. PROBLEM POSLUŽIVANJA KORISNIKA STUDENTSKE SLUŽBE FAKULTETA PROMETNIH ZNANOSTI Studentska služba Fakulteta prometnih znanosti namijenjena je studentima za obavljanje administrativnih poslova koji se javljaju tijekom studija, primjerice, upisi akademskih godina, preuzimanje potvrda, te prijava završnih i diplomskih radova. Studenti se trenutno poslužuju na četiri radna mjesta (u nastavku rada pod terminom radna mjesta podrazumijevaju se poslužitelji studentske službe namijenjeni posluživanju korisnika), s tim da je treće po redu radno mjesto namijenjeno prvenstveno prioritetnim korisnicima za prijavu i predaju završnih i diplomskih radova. Čekanje na posluživanje u repovima je često stresna i vremenski dugotrajna aktivnost. Velike gužve pred studentskom službom se redovito javljaju za vrijeme upisa nove akademske godine kada više desetaka studenata čekaju na posluživanje na pojedinom radnom mjestu. Često se događa da studenti trebaju izaći iz repa uplatiti školarinu ili obaviti nekakvu drugu radnju i time izgube svoje mjesto u repu, te taj dan gotovo sigurno neće doći na red za posluživanje. Također, učestali su pokušaji ulaska u red čekanja u neskladu s vremenima dolazaka korisnika u studentsku službu, te se među studentima javlja još veća nervoza i napetost. Uporabom sustava RQM@fpz gužve pred studentskom službom bi se drastično umanjile, efikasnije bi se upravljalo repom čekanja, povećala bi se učinkovitost službenica u studentskoj službi, te bi se omogućilo ugodno čekanje i pravednost pri pozivanju na posluživanje koja je temeljena na rednim brojevima potvrde. Studenti bi mogli za vrijeme čekanja na posluživanje obavljati druge aktivnosti poput odlaska na konzultacije, popunjavanja potrebnih obrazaca ili obavljanje poslova privatne prirode. Krajnja svrha ovog sustava je pružanje studentima, kao korisnicima, najbolje moguće usluge i izbjegavanje višesatnog čekanja u repu u kapacitetom ograničenom prostoru pred studentskom službom. Također, uvođenjem modeliranog sustava posluživanja uvelike bi se doprinijelo ugodnijoj radnoj okolini službenicama studentske službe, kao i produktivnijem i učinkovitijem obavljanju radnih aktivnosti. 8

14 4.1. Karakteristike sustava Karakteristike sustava posluživanja se mogu se promatrati kroz dva specifična modela posluživanja. U slučaju prioritetnih korisnika, sustav se može promatrati kao jednoposlužiteljski Poissonov sustav posluživanja s beskonačnim izvorištem. Kendallova oznaka koja ga opisuje glasi: M M 1 K FCFS. Funkcije razdiobe međudolaznih vremena i trajanja posluživanja su eksponencijalne. Broj poslužitelja je jedan, s obzirom da prioritetni korisnici mogu biti posluženi samo na trećem poslužitelju, odnosno radnom mjestu. U sustavu može biti najviše K korisnika jer je broj korisnika ograničen radnim vremenom studentske službe, stoga će svim korisnicima koji imaju očekivano vrijeme do posluživanja veće od radnog vremena studentske službe biti uskraćen ulazak u rep, odnosno, sustav. Izvorište nema ograničenja, a pravilo izlaska iz repa ka poslužitelju je FCFS (engl. First Come First Served). U drugom slučaju kada u repu nema prioritetnih korisnika, sustav je gotovo identičan kao u slučaju prioritetnih korisnika. Kendallova oznaka primjenjiva na ovaj model posluživanja glasi: M M 4 K FCFS. Razlika je u broju poslužitelja gdje uz postojeća tri za neprioritetne korisnike, poslužitelj za prioritetne korisnike započinje posluživati neprioritetne korisnike. Sustav je takve strukture sve dok se u repu ne pojavi prioritetni korisnik. On u tom slučaju odmah odlazi na posluživanje nakon završetka posluživanja neprioritetnog korisnika na poslužitelju za prioritetne korisnike. Takvo pravilo izlaska iz repa se naziva prednosno posluživanje s odgodivim prekidima. Konkretno, prioritetni korisnik pri ulasku u rep odmah staje na njegovo čelo i čeka završetak posluživanja korisnika koji se u tom trenutku nalazi kod poslužitelja, te odmah potom odlazi na posluživanje, [6]. U realnim uvjetima za očekivati je da će se sustav RQM@fpz ponašati kao kombinacija gore navedenih specifičnih modela Algoritam za procjenu očekivanog vremena do posluživanja Autori ovog rada razvili su algoritam namijenjen procjeni očekivanog vremena do posluživanja pojedinog korisnika, koji će biti opisan u nastavku. Algoritam za računanje očekivanog vremena do posluživanja pohranjen je unutar baze podataka u okidaču ocekivanovrijemedoposluzivanja. Važno je naglasiti da očekivano vrijeme do posluživanja ispisano na potvrdi može varirati u odnosu na vrijeme kad korisnik dođe na posluživanje. Kada prvi neprioritetni korisnik zatraži potvrdu, na njoj se ispisuje predefinirano prosječno 9

15 vrijeme posluživanja. Temeljem prethodnih analiza, od Fakulteta je dobiven podatak kako je prosječno vrijeme posluživanja jednog korisnika tri minute. Svaki sljedeći neprioritetni korisnik na svojoj potvrdi ima ispisanu vrijednost predefiniranog prosječnog vremena posluživanja sve dok se ne završi posluživanje prvog neprioritetnog korisnika i na temelju vremena posluživanja dalje se počinje računati novo dinamičko prosječno vrijeme posluživanja koje će polučiti realnije vrijeme čekanja. Prosječno vrijeme za neprioritetne korisnike se računa na način da se ukupno vrijeme posluživanja neprioritetnih korisnika podijeli s brojem posluženih neprioritetnih korisnika. Identičan način se koristi i za računanje prosječnog vremena posluživanja prioritetnih korisnika. Pomoću izraza 1 izračunava se očekivano vrijeme do posluživanja za neprioritetne korisnike uz uvjet da u repu nema prioritetnih korisnika. gdje je: (1) T ci očekivano vrijeme do posluživanja za i-tog neprioritetnog korisnika gdje i poprima vrijednosti u intervalu [1, K], [min] n n broj neprioritetnih neposluženih korisnika u trenutku t čiji trenutak ulaska u rep čekanja je raniji od trenutka ulaska i-tog neprioritetnog korisnika T 0 prosječno vrijeme posluživanja neprioritetnog korisnika [min] c broj poslužitelja Vrijednost T 0 se računa kao aritmetička sredina vremena posluživanja svih neprioritetnih korisnika. U trenutku kada u rep uđe prioritetni korisnik, očekivano vrijeme do posluživanja se više ne može odrediti pomoću izraza 1. Dolaskom prvog prioritetnog korisnika u sustav, isti se odmah svrstava na čelo repa. Očekivano vrijeme do posluživanja za prioritetne korisnike je dano izrazom 2. ( ) [ ] (2) gdje je: T pi očekivano vrijeme do posluživanja i-tog prioritetnog korisnika gdje i poprima vrijednosti u intervalu [1, K], [min] 10

16 z 3 indikator zauzetosti trećeg poslužiteljskog mjesta neprioritetnim korisnikom u trenutku evidentiranja prioritetnog korisnika u repu T 0 prosječno vrijeme posluživanja neprioritetnog korisnika [min] n p(i-1) broj prioritetnih korisnika u repu čiji trenutak ulaska u rep čekanja je raniji od trenutka ulaska i-tog korisnika T p0 prosječno vrijeme posluživanja prioritetnog korisnika [min] Ukoliko je u trenutku ulaska prioritetnog korisnika u rep čekanja, treće poslužiteljsko radno mjesto zauzeto neprioritetnim korisnikom, indikator z 3 poprima vrijednost 1, a ukoliko je u danom trenutku treće poslužiteljsko radno mjesto slobodno, indikator z 3 poprima vrijednost 0 i prioritetni korisnik može odmah pristupiti posluživanju. U slučaju da je z 3 = 1, T p1 se ne utvrđuje kao razlika T 0 i vremena koje je neprioritetni korisnik (koji u trenutku dolaska prioritetnog korisnika zauzima kapacitet trećeg poslužiteljskog radnog mjesta) već proveo u posluživanju, jer bi dobivena vrijednost mogla poprimiti negativne iznose. Kada i-ti neprioritetni korisnik uđe u rep u trenutku kada u repu čekaju obje kategorije korisnika, njegovo očekivano vrijeme do posluživanja se utvrđuje temeljem izraza 3. [ ( ( ) )] ( ) (3) U tom slučaju očekivano vrijeme do posluživanja je jednako umnošku broja neprioritetnih korisnika koji čekaju na posluživanje, a u rep su ušli ranije od i-tog korisnika, i prosječnog vremena posluživanja neprioritetnih korisnika na c 1 poslužitelja jer se u trenutku izračunavanja očekivanog vremena do posluživanja jedan poslužitelj koristi za posluživanje prioritetnih korisnika. 11

17 5. OPIS TEHNOLOGIJA KORIŠTENIH PRI PROJEKTIRANJU I IZGRADNJI SUSTAVA Sustav upravljanja repom studentske službe Fakulteta prometnih znanosti, RQM@fpz, razvijen je primjenom više tehnologija i podržanih razvojnih okruženja koja će biti opisana u nastavku ovoga poglavlja. Struktura sustava RQM@fpz podijeljena je u tri osnovna segmenata čiji je logički raspored prikazan slikom 2. RQM.kiosk RQM.web Internet Web poslužitelj Računalo za prijavu u sustav Poslužitelj baze podataka RQM.info Info zaslon SQL Korisnički terminalni uređaji Studentska služba RQM.služba Slika 2: Logička shema sustava Prvi segment je poslužiteljski i odnosi se na bazu podataka namijenjenu implementaciji na poslužitelj Fakulteta prometnih znanosti. Baza podataka razvijena je u Microsoft SQL Server 2008R2 razvojnom okruženju. Unutar same baze podataka, osim njezine strukture, definirane su pohranjene procedure i okidači koji upravljaju podacima u smislu unosa novih i izmjene postojećih podataka. Drugi segment su klijentske aplikacije razvijene korištenjem programskog jezika C# u Microsoft Visual Studio 2010 razvojnom okruženju, a namijenjene su instalaciji na klijentska računala studentske službe (modul RQM.služba ), kiosk računalo putem kojega se izvršava prijava korisnika u sustav (modul RQM.kiosk ), te povezivanje sa zaslonima u predvorju Fakulteta prometnih znanosti u svrhu informiranja korisnika o trenutnom stanju repa (modul RQM.info ). Treći segment obuhvaća web aplikaciju (modul RQM.web ) namijenjenu implementaciji na web poslužitelj Fakulteta prometnih znanosti. Web aplikacija je razvijena je korištenjem.net tehnologije i C# programskog jezika također pomoću Microsoft Visual 12

18 Studio 2010 razvojnog okruženja, a namijenjena je informiranju korisnika o trenutnom stanju repa putem Interneta Sustavi baza podataka Mogućnost trajne pohrane podataka na memorijski prostor računala prisutna je gotovo koliko i sama računala. Navedena mogućnost podržana je u svim programskim jezicima, pa tako primjerice jezici poput C, C#, Pascal i mnogi drugi, mogu stvoriti datoteku na tvrdom disku računala te u nju upisivati podatke, ali isto tako mogu otvoriti već postojeću datoteku i iz nje čitati, izvršavati promjene ili brisati podatke, [9]. Kako bi se izbjeglo individualno stvaranja datoteka i zapisivanje podataka u njih, te kako bi se samim time povećala produktivnost, kvaliteta i pouzdanost u razvoju aplikacija temeljenih na pohrani i pretrazi podataka, razvijen je sustav baze podataka (engl. Database System). Sustav baze podataka sastoji se od tri glavne komponente, baza podataka (engl. Database), sustav upravljanja bazom podataka (engl. Database Management System, DBMS) i strukturirani jezik za upite (engl. Structured Query Language, SQL), [9], [10]. Kako je već spomenuto, pojedina aplikacija ne stvara vlastite datoteke u memoriji računala već su pohrana i pristup podacima centralizirani, tj. zajednički su za sve aplikacije koje koriste određene podatke. Pristup podacima u bazama podataka nije direktan već se izvršava putem SQL upita i sustava za upravljanje bazom podataka, specijaliziranog programskog alata razvijenog isključivo u svrhu upravljanja bazom i posredovanja između korisnika (engl. Client) i poslužitelja (engl. Server). Opisani način pristupanja podacima u bazi prikazan je slikom 3, [9]. korisnik korisnik korisnik Sustav baze podataka SQL upit DBMS Baza podataka Slika 3: Princip pristupa podacima u bazi podataka 13

19 Baza podataka Baza podataka je skup međusobno povezanih podataka pohranjenih na memoriji računala koji su dostupni korisnicima i aplikacijama za dohvat, upisivanje i manipulaciju. Kako korisnici i aplikacije koje koriste bazu podataka ne bi morali poznavati detalje fizičkog prikaza podataka, tijekom vremena razvijeno je nekoliko modela baza podataka na koju bi se korisnici referencirali. Model baze podataka je zapravo njezina idealizirana logička struktura [9], [11]. Od početaka uporabe baza podataka razvijeno je ukupno četiri osnovna modela, [9]: 1) Mrežni model 2) Hijerarhijski model 3) Relacijski model 4) Objektni model Veliki nedostatak mrežnog i hijerarhijskog modela je što poveznice između tablica moraju biti unaprijed poznate i ugrađene u bazu prilikom njene izgradnje, što je ograničavalo dinamiku pri manipulaciji podacima zapisanim u takvoj bazi, [11]. Relacijski model koristi se već više od trideset godina, unatoč uvjerenju da je prelazak na objektno zasnovanu metodologiju neizbježan. Relacijski model baze podataka razvio je krajem 60-ih godina 20. stoljeća dr. E. F. Codd, [12]. Prva testiranja novog modela bila su spora i neučinkovita radi nedovoljne procesorske i memorijske snage tadašnjih računala. Razvojem računala, odnosno njihove učinkovitosti u smislu brzine obrade podataka paralelno se povećavala i učinkovitost relacijskih baza podataka. Naziv relacija je zapravo matematički izraz za tablicu kojom su predstavljeni podaci pohranjeni u bazi, a sastoje se od redaka i stupaca. Tablice su međusobno povezane putem ključa, tj. zajedničkog atributa, [9],[11]. 14

20 Strukturirani jezik za upite Strukturirani jezik za upite (SQL) je programski jezik koji je prihvaćen kao standard kada je u pitanju upravljanje podacima u relacijskim bazama podataka. Razvoj SQL-a tekao je paralelno sa razvojem relacijskog modela baza podataka. SQL je razvijen u sklopu projekta SystemR kompanije sa Donaldom Chamberlineom na čelu projektnog tima, a zasniva se na relacijskom računu s time da je matematička notacija zamijenjena engleskim ključnim riječima. Veliku ulogu u širenju SQL jezika imala je kompanija Oracle Corp. koja je ga je ugradila u vlastiti DBMS čime je taj jezik postao dostupan na raznim računalnim platformama [9]. Osim postavljanja samih upita, SQL dopušta definiranje relacija, njihovo ažuriranje (umetanje, izmjena, brisanje), sortiranje i formatiranje ispisa, aritmetičke operacije te petlje (FOR, WHILE) i kontrolu toka izvođenja koda (IF-THEN), [10]. Neke od najčešće korištenih naredbi u SQL-u su: SELECT naziv_atributa FROM naziv_tablice WHERE uvjet - koristi se za dohvat atributa iz tablice prema određenim uvjetima INSERT INTO naziv_tablice (naziv_atributa) VALUES (naziv_atributa) - koristi se za umetanje zapisa u definiranu tablicu UPDATE naziv_tablice SET naziv_atributa=vrijednost_atributa WHERE uvjet - koristi se za ažuriranje definirane tablice CREATE PROCEDURE naziv_procedure AS SQL_izraz - koristi se za kreiranje pohranjene procedure 15

21 5.2. Tehnologija ASP.NET ASP.NET (engl. Active Server Pages. NET) je jedna od najraširenijih tehnologija koja se koristi za pristup sadržaju putem web preglednika. Koristi HTML (engl. HyperText Markup Language), CSS (engl. Cascading Style Sheets), JavaScript i poslužiteljske procese kako bi se omogućio ne ometani rad web stranica. Postao je popularan zbog jednostavnosti korištenja poput opcije drag-and-drop. Opcija omogućava programerima odabir sadržaja kao što je tipka te postavljanje na željeno mjesto unutar aplikacije. ASP.NET će generirati kod umjesto programera. Također, omogućava programerima da odaberu jedan od tri različita modela izrade (programiranja) web stranica. Modeli su: web stranica, MVC (engl. Model View Controller) i web forme. Svi modeli su sadržani u C# programskom jeziku, [16]. Preteča ASP.NET-a je ASP (engl. Active Server Pages). ASP je prva tehnologija koja omogućava pokretanje pozadinskih procesa na IIS (engl. Internet Information Server) poslužitelju. Omogućava pokretanje procesa na web stranici pomoću IIS poslužitelja a ASP paketi koji se pokreću imaju.asp ekstenziju i najčešće su pisani u VBScripts i Jscript skriptnom jeziku, [19]. ASP.NET je nova generacija ASP-a. ASP nije kompatibilan sa ASP.NET, dok ga ASP.NET može sadržavati. Sadrži veliku bazu korisničkih kontrolera, veću podršku za komponente koje su bazirane na XML-u (engl. EXtensible Markup Language) i integriranu korisničku autentifikaciju te stranice koje su pisane u ASP.NET imaju ekstenziju.aspx, a najčešće su pisane u VB (engl. Visual Basic) ili C# programskim jezicima. U trenutku kada web preglednik zahtijeva ASP.NET datoteku ASP.NET program dohvaća traženu datoteku, učitava i sastavlja je te pokreće procese koji se u njoj nalaze. Zahtijevana datoteka (sadržaj) se vraća web poslužitelju u HTML obliku, [16]. HTML bi se mogao najbolje prevesti kao prezentacijski jezik za izradu web stranica. Hipertekst je dokument koji se piše, odnosno, stvara uporabom HTML jezika te se oblikuju i stvaraju tzv. hiperveze, odnosno, veze koje povezuju hipertekst dokumente u jednu cjelinu. Važno je napomenuti da HTML nije programski jezik te da se njime ne mogu izvršiti nikakve operacije, to je jezik za opis (povezivanje) hipertekstualnih dokumenata te su njegove datoteke obične tekst datoteke koje su označene.html ili.htm ekstenzijama. Poveznice koje se nalaze unutar HTML dokumenata omogućavaju povezivanje dokumenata, te uređuju hijerarhijsku strukturu čime se određuje način, odnosno, izgled sadržaja koji se prikazuje na Internet stranici, [17]. 16

22 CSS bi se najbolje mogao prevesti kao grafički jezik koji se koristi za grafičku izvedbu dokumenata izrađenih pomoću HTML jezika. U počecima razvijanja, prikazivanja i korištenja web stranica nije postojao CSS već su njegove funkcionalnosti bile implementirale u web stranice putem HTML jezika. Takav način izrade web stranica nije bio praktičan te se ubrzo uočila potreba za grafičkim jezikom koji bi omogućio uređivanje izgleda i raspored sadržaja na web stranicama pošto HTML nikada nije bio namijenjen sadržavanju tzv. tagova kako bi se omogućilo uređivanje dokumenta koji je napravljen HTML jezikom. Izdavanjem inačice 4.0 HTML-a, grafička izrada web stranica se izbacila iz HTML dokumenata te se preselila unutar odvojenih CSS datoteka kako bi se olakšala grafička izrada. CCS definira kako će elementi HTML biti prikazani na web stranici. Dokumenti koji su pohranjeni u CSS formatu imaju.css ekstenziju. Uvođenjem CSS-a je omogućena promjena sadržaja više web stranica odjednom izvođenjem promjena nad jednom datotekom za razliku od prijašnjih inačica HTML-a koji nisu imali CSS gdje se morala svaka HTML datoteka uređivati zasebno, [17]. JavaScript je skriptni jezik koji omogućava stvaranje interaktivnih web stranica. Interaktivnost je potrebna radi, inače, statičkih HTML stranica, te je ugrađen u sve inačice web preglednika kao što su Internet Explorer, Google Chrome i dr. Programski kod koji je napisan mora biti uključen ili se mora referencirati na HTML dokument kako bi se mogao izvršiti unutar web preglednika. To znači da uvođenjem JavaScript web stranice više ne moraju biti statičke (koristi statički HTML) već mogu uključivati programe koji su interaktivni sa korisnikom i podržavaju dinamičko stvaranje HTML sadržaja, [18] Programski jezik C# C# (C sharp) je jednostavan objektno orijentiran programski jezik razvijen od strane Microsofta. Prva verzija (C# 1.0) pojavila se godine, te su se potom ubrzo pojavile nove verzije ovog programskog jezika. Posljednja verzija C#-a (C# 5.0) je predstavljena u kolovozu godine. Ovaj programski jezik dizajniran je da bude jednostavan, siguran, objektno orijentiran i brz. Jednostavnost se manifestira kroz samo osamdeset ključnih riječi i desetak tipova, [14]. Siguran je za upis koda jer se traženje pogrešaka (engl. debugging) obavlja za vrijeme pisanja koda, a ne samo nakon pokretanja. C# kao objektno orijentirani programski jezik se sastoji od više različitih objekata koji mogu imati iste, slične ili potpuno specifične osobine. Te osobine se nazivaju atributima. Pored atributa objekti imaju i svoju 17

23 funkcionalnost opisanu blokovima koda koje sadrže nizove naredbi, koje se nazivaju metodama. Programiranje korištenjem objektno orijentirane paradigme 1 sastoji se od sljedećih koraka, [15]: - identificiranje objekata - identificiranje atributa objekata i njihovih vrijednosti - identificiranje funkcionalnosti objekata - klasifikacija objekata u klase - definiranje klasa - identificiranje komunikacije između objekata. 1 Programska paradigma osnovni stil računalnog programiranja 18

24 6. RAZVOJ BAZE PODATAKA SUSTAVA Razvoj baze podataka predstavlja složen zadatak koji zahtjeva primjenu raznovrsnih metoda i alata te se takvom projektnom zadatku, nužno, mora pristupati studijski i planski. Prema [9], razvoj baze podataka moguće je podijeliti u pet osnovnih cjelina, koje se još nazivaju i razvojnim ciklusom i općenito su karakteristika programskog inženjerstva: 1) Utvrđivanje i analiza zahtjeva 2) Modeliranje (konceptualno i logičko) 3) Implementacija 4) Testiranje 5) Održavanje. Baza podataka predstavlja osnovicu cjelokupnog RQM@fpz sustava, a razvijena je s idejom rasterećenja klijentskih računala. Prema tome sve operacije poput izračunavanja očekivanog vremena do posluživanja i izračuna prosječnog vremena posluživanja izvršavaju se na poslužitelju baze podataka. Ovakav pristup razvoju sustava osigurava smanjenu količinu prometa unutar mreže, a time i brži rad modula sustava. Kako bi ovaj način razvoja bio ostvariv, upravljanje podacima u bazi nužno je provesti putem pohranjenih procedura pri čemu moduli sustava bazi podataka dostavljaju samo vrijednosti traženih parametara, te prihvaćaju vrijednosti novih parametara kao rezultat obrade unutar pohranjene procedure. Pohranjene procedure korištene su i zbog svojih drugih prednosti poput enkapsulacije 2 (engl. encapsulation) logike upita ili algoritama, lakšeg upravljanja iznimkama i sl. Njihovom uporabom povećana je i sigurnost sustava pošto se na bazu podataka ne postavljaju SQL upiti iz modula sustava čime je smanjena mogućnost izvršavanje SQL injection 3 metode napada, [20]. 2 Hrvatski prijevod začahurenost nije zadovoljavajući 3 Metoda napada kojom se bazi podataka šalje prilagođen SQL upit s ciljem otkrivanja povjerljivih podataka ili stjecanja kontrole nad sustavom 19

25 6.1. Utvrđivanje i analiza zahtjeva Prilikom izrade baze podataka potrebno je utvrditi i analizirati zahtjeve koji će pred nju biti postavljeni. Kako bi to bilo moguće potrebno je poznavati procese i postupke koji se odvijaju unutar studentske službe. Također potrebno je definirati procedure i postupke koji će se obavljati nad podacima pohranjenima unutar baze podataka. Studentska služba Fakulteta prometnih znanosti trenutno se sastoji od četiri radna mjesta. Tijekom radnog vremena studentske službe korisnici imaju mogućnost dolaska na posluživanje. Sva četiri radna mjesta studentske službe namijenjena su posluživanju korisnika bez prioriteta što obuhvaća sve korisnike osim onih koji prijavljuju ili predaju završne i diplomske radove. Prioritetni korisnik, odnosno korisnik koji predaje diplomski ili završni rad prilikom dolaska u studentsku službu ima prioritet posluživanja na radnom mjestu broj 3. Proces posluživanja korisnika u studentskoj službi opisan ja UML dijagramom aktivnosti prikazanim slikom 4. dolazak studenta pred studentsku službu radno vrijeme studentske službe isteklo [false] [true] student ne ulazi u rep ulazak studenta u rep prioritetni student broj prioritetnih studenata u repu>0 [true] [false] [provjera broja studenata] [provjera broja studenata] [true] čekanje broj studenata u repu>0 [false] [true] čekanje posluživanje na radnom mjestu br. 3 [false] posluživanje studenta odlazak iz studentske službe Slika 4: UML dijagram aktivnosti posluživanja studenta u studentskoj službi 20

26 Nakon implementacije sustava proces posluživanja korisnika bio bi izmijenjen u nekim segmentima, što je moguće vidjeti iz UML dijagrama aktivnosti prikazanog slikom 5. Korisnik prije posluživanja u studentskoj službi mora izvršiti prijavu u sustav RQM@fpz. Prijava se vrši unošenjem JMBAG 4 -a te odabirom kategorije A ili kategorije B. Kategorija A označava sve korisnike koji zahtijevaju posluživanje osim onih koji zahtijevaju posluživanje vezano uz diplomske i završne radove, te oni pripadaju kategoriji B. Korisnici kategorije B su korisnici sa prioritetom posluživanja na radnom mjestu broj 3. Prijavni podaci korisnika upisuju se u bazu podataka te se izračunava očekivano vrijeme do posluživanja. Sustav izdaje korisniku potvrdu koja sadrži redni broj i kategoriju posluživanja, datum i vrijeme izdavanja potvrde, očekivano vrijeme do posluživanja, te opcionalno dodatne informacije. Korisnik status repa može provjeravati na dva načina, putem info zaslona u predvorju Fakulteta ili putem web stranice. Nakon objave rednog broja na info zaslonu koji odgovara rednom broju na potvrdi korisnik odlazi na posluživanje na radno mjesto ispisano uz redni broj na info zaslonu. Službenica na radnom mjestu poslužuje dolazećeg korisnika. 4 JMBAG (Jedinstveni Matični Broj Akademskog Građana) broj koji jedinstveno određuje svaku osobu akademske zajednice 21

27 dolazak studenta u studentsku službu pristupanje računalu za prijavu na posluživanje unos JMBAG-a i odabir kategorije radno vrijeme studentske službe isteklo/ očekivano vrijeme do posluživanja prelazi radno vrijeme službe [false] [true] Ispis poruke studentu o nemogućnosti posluživanja [kategorija A] [katogorija B] preuzimanje potvrde koja sadrži redni broj i očekivano vrijeme do posluživanja kategorije A preuzimanje potvrde koja sadrži redni broj i očekivano vrijeme do posluživanja kategorije B [false] provjera informacija o posluživanju na zaslonu/web stranici provjera informacija o posluživanju na zaslonu/web stranici [false] redni broj sa potvrde je prikazan redni broj sa potvrde je prikazan [true] [true] odlazak na posluživanje na radno mjesto prikazano putem info zaslona odlazak na posluživanje na radno mjesto prikazano putem info zaslona kraj posluživanja odlazak iz studentske službe Slika 5: Proces posluživanja studenta u studentskoj službi nakon implementacije sustava RQM@fpz 22

28 6.2. Modeliranje baze podataka Konceptualno modeliranje Temeljem, prethodno, pojednostavljeno opisanog procesa posluživanja studenata u studentskoj službi moguće je pristupiti konceptualnom modeliranju baze podataka. U prvom koraku potrebno je izlučiti entitete, atribute i veze kao osnovu daljnjeg razvoja. Entitet je skup objekata od interesa iz realnog svijeta sa naglašenim zajedničkim svojstvima, [10],[13]. Entiteti koji se mogu izlučiti iz opisanog procesa su: a) Student entitet koji predstavlja studente Fakulteta (korisnike) koji zahtijevaju posluživanje u studentskoj službi, b) Radno mjesto poslužitelj na koji dolaze korisnici na posluživanje, c) Službenica studentske službe entitet koji obavlja posluživanje korisnika na radnom mjestu, d) Potvrda entitet koji je nužan u razvoju baze podataka u smislu jedinstvene pohrane svake prijave studenta u sustav. Veze su odnosi između entiteta od interesa čijom se uspostavom izražava njihova povezanost, [9]. Između definiranih entiteta moguće je uspostaviti slijedeće veze: a) Jedan korisnik preuzima nula ili mnogo potvrda [0..*], jedna potvrda preuzeta je od samo jednog korisnika [1..1], b) Jedna službenica studentske službe poslužuje nula ili mnogo potvrda [0..*], jedna potvrda poslužena je kod samo jedne službenice studentske službe [1..1], c) Na jednom radnom mjestu obrađuje se nula ili mnogo potvrda [0..*], jedna potvrda obrađena je na samo jednom radnom mjestu [1..1]. Nakon definiranih entiteta i veza među njima potrebno je još samo definirati atribute. Atributi su obilježja ili svojstva entiteta koja su od značaja za izradu baze podataka, [13]. Primjer nekih atributa od značaja pridodanih pojedinom entitetu su: a) Student (JMBAG, OIB 5, ime, prezime), b) Radno mjesto (broj radnog mjesta), c) Službenica studentske službe (ime, prezime), 5 OIB (Osobni Identifikacijski Broj) broj koji jedinstveno određuje svakog državljanina Republike Hrvatske 23

29 d) Potvrda (datum izdavanja potvrde, kategorija, redni broj, očekivano vrijeme do posluživanja). Na osnovi definiranih entiteta, veza i atributa razrađena je konceptualna shema baze podataka prikazana slikom 6. Entiteti su prikazani unutar pravokutnika, veze unutar rombova, a atributi unutar elipse. Između entiteta, također su naznačeni i kardinaliteti koji se nalaze na poveznicama između entiteta i veze. ime JMBAG prezime OIB Student (1,1) rmid preuzima (0,n) slid brrm Radno mjesto (1,1) poslužuje (0,n) Potvrda (0,n) obrađuje (1,1) Službenica slime aktivnost rbroj pri slprezime ticketid ocekvr vrodlaska vrdolaska datumizdavanja vrposluzivanja Slika 6: Grafički prikaz konceptualne sheme (Chenov dijagram) Logičko modeliranje Glavni cilj logičkog modeliranja baze podataka jest stvoriti relacijsku shemu baze podataka. Relacijska shema, prikazana slikom 7, opisuje logičku strukturu baze u skladu s pravilima relacijskog modela podataka, a od konceptualne sheme se razlikuje u mogućnosti implementacije putem DBMS-a. Prilikom logičkog modeliranja potrebno je definirati relacije (tablice) koje odgovaraju entitetima iz konceptualnog modela. Tablice se sastoje od stupaca i redaka pri čemu stupci odgovaraju atributima iz konceptualnog modela, a redci predstavljaju vrijednosti pojedinog atributa. 24

30 Student PK jmbag oib ime prezime Ticket RadnoMjesto PK,FK3 PK rmid ticketid PK rmid brrm aktivnost FK2 FK1 datumizdavanja pri rbroj vrdolaska vrodlaska jmbag slid vrposluzivanja ocekvr PK Sluzbenica slid slime slprezime Slika 7: Grafički prikaz relacijske sheme Logičkim modeliranjem definirani su primarni ključevi pojedine tablice te tipovi podataka pojedinog atributa, što je vidljivo iz rječnika podataka prikazanog tablicom 1. Kako su već u samome početku modeliranja uočeni svi potrebni entiteti, atributi i veze, ne postoji potreba za dodatnom normalizacijom baze podataka. Tablica 1: Rječnik podataka IME PODATKA TIP PODATKA OPIS TABLICA JMBAG varchar(10) jedinstvena oznaka studenta Student OIB varchar(11) OIB studenta Student ime varchar(max) ime studenta Student prezime varchar(max) prezime studenta Student rmid tinyint jedinstvena oznaka radnog mjesta RadnoMjesto brrm tinyint broj radnog mjesta RadnoMjesto aktivnost bit oznaka da li je radno mjesto otvoreno za posluživanje RadnoMjesto slid tinyint jedinstvena oznaka službenice studentske službe Sluzbenica slime varchar(max) Ime službenice Sluzbenica slprezime varchar(max) Prezime službenice Sluzbenica ticketid integer jedinstvena oznaka potvrde Potvrda datumizdavanja datetime Datum/vrijeme izdavanja potvrde Potvrda pri bit izabrana kategorija studenta Potvrda rbroj smallint redni broj izdane potvrde Potvrda vrdolaska datetime vrijeme dolaska na posluživanje Potvrda vrodlaska datetime vrijeme odlaska sa posluživanja Potvrda vrposluzivanja time vrijeme od početka do kraja posluživanja Potvrda ocekvr time očekivano vrijeme do posluživanja studenta Potvrda 25

31 6.3. Implementacija Implementacija baze podataka temelji se na zapisivanju, prethodno razrađenog, logičkog modela SQL jezikom, poštujući sintaksu i ostala pravila pisanja SQL koda. Krajnji cilj implementacije je stvaranje fizičkog zapisa baze na tvrdi disk klijentskog računala ili poslužitelja. Većinu detalja unutar fizičkog modela određuje DBMS putem ugrađenih pravila. Definiranje atributa pojedine tablice izvršava se prema već razrađenom rječniku podataka. Slikom 8 prikazan je izvorni SQL kod implementacije baze putem MS SQL Server 2008R2 razvojnog okruženja. Unutar koda definirani su i atributi te primarni i strani ključevi kao i atributi čija vrijednost je obavezna (NOT NULL). Uz implementiranu bazu podataka kreirane su pohranjene procedure i okidači za umetanje, ažuriranje i dohvat podataka iz baze u svrhu manipulacije podacima putem razvijenih modula RQM@fpz sustava koji će biti prikazani u kasnijim poglavljima ovoga rada. Slika 8: Izvorni SQL kod implementacije baze podataka 26

32 Pohranjena procedura dolazni Pohranjena procedura dolazni kreirana je s ciljem umetanja novog zapisa u tablicu Potvrda, što je vidljivo na slici 10. Zbog opsežnosti izvornog SQL koda, način rada pohranjene procedure prikazan je UML dijagramom aktivnosti (slika 9). / vrijednosti JMBAG i pri (modul RQM.kiosk) provjera JMBAG-a JMBAG zapisan u bazi podataka [true] [false] obavjest o pogrešno upisanom JMBAG-u provjera broja izdanih potvrda u trenutnom danu broj potvrda>0 [true] [false] umetanje zapisa u tablicu "Potvrda" umetanje zapisa u tablicu "Potvrda" redni broj = 1 / aktiviranje okidača ocekivanovrijemedoposluzivanja redni broj=max(redni broj) + 1 pri = vrijednost pri iz RQM.kiosk datum izdavanja potvrde=trenutni datum/vrijeme JMBAG= JMBAG iz RQM.kiosk Slika 9: UML dijagram aktivnosti za pohranjenu proceduru dolazni Prilikom umetanja novog zapisa potrebno je postaviti vrijednosti sljedećih atributa: 1) ticketid primarni ključ tablice čija se vrijednost unosi automatski dodavanjem novog zapisa, 27

33 2) datumizdavanja datum i vrijeme izdavanja potvrde, poprima vrijednost trenutnog vremena sustava, 3) pri kategorija koju korisnik odabire prilikom prijave putem modula RQM.kiosk, poprima vrijednost 1 za kategoriju A ili vrijednost 0 za kategoriju B, 4) rbroj redni broj potvrde. Početni redni broj je 1, a zadnji ovisi o broju korisnika prijavljenih u sustav tijekom dana. Početkom novog dana redni brojevi polaze ponovno od broja 1, 5) JMBAG unosi ga korisnik putem modula RQM.kiosk prilikom prijave u sustav. Kako je JMBAG strani ključ u tablici Potvrda, a primarni ključ u tablici Student, unos JMBAG-a koji ne postoji u tablici Student rezultirat će pogreškom sustava zbog kršenja pravila očuvanja referencijalnog integriteta, 6) ocekvr očekivano vrijeme do posluživanja, izračunava se dinamički, algoritmom implementiranim unutar okidača koji će biti objašnjen naknadno. Slika 10: Tablica Potvrda nakon izvršavanja pohranjene procedure dolazni Pohranjena procedura posluzivanje Uloga pohranjene procedure posluzivanje u bazi podataka je ažuriranje tablice Potvrda. Izvršavanje pohranjene procedure poziva se iz modula RQM.služba koji dostavlja vrijednosti parametara rmid (ID radnog mjesta) i slid (ID službenice studentske službe). Na temelju dostavljenih vrijednosti pohranjena procedura ažurira slijedeće atribute, što je i vidljivo iz slike 11: 1) vrdolaska atribut koji označava datum i vrijeme dolaska potvrde (korisnika) na posluživanje i poprima vrijednost vremena sustava u trenutku pozivanja pohranjene procedure iz modula RQM.služba 28

34 2) vrodlaska - atribut koji označava datum i vrijeme odlaska potvrde sa posluživanja i poprima vrijednost vremena sustava u trenutku pozivanja pohranjene procedure iz modula RQM.služba. Pozivom pohranjene procedure slijedno se ažurira atribut vrodlaska potvrde koja je trenutno na posluživanju i atribut vrdolaska potvrde koja je slijedeća zapisana u tablici Potvrda 3) rmid primarni ključ tablice RadnoMjesto i strani ključ tablice Potvrda. Vrijednost parametra rmid pohranjenoj proceduri dostavlja modul RQM.služba koja se zapisuje u tablici Potvrda i označava radno mjesto na kojemu se izvršava posluživanje. Sustav će rezultirati pogreškom ukoliko vrijednost ne postoji u tablici RadnoMjesto u cilju očuvanja referencijalnog integriteta. 4) slid primarni ključ tablice Sluzbenica i strani ključ tablice Potvrda. Vrijednost parametra slid pohranjenoj proceduri dostavlja modul RQM.služba, te se ista zapisuje unutar tablice Potvrda i označava službenicu studentske službe koja obavlja posluživanje. Pravilo referencijalnog integriteta mora biti poštivano kao i kod prethodno opisanog atributa, rmid. 5) vrposluživanja atribut koji poprima vrijednost trajanja posluživanja, odnosno, proteklo vrijeme od početka do kraja posluživanja. Vrijednost atributa ažurira okidač trajanjeposluzivanja koji će biti opisan naknadno. Zbog opširnosti izvornog SQL koda, pohranjena procedura opisana je UML dijagramom aktivnosti u sklopu priloga 1. Iz ažurirane tablice Potvrda, prikazane slikom 11, vidljivo je kako radno mjesto broj 1 ne ažurira zapise gdje atribut pri ima vrijednost 0. Razlog tomu je što se potvrde sa prioritetom poslužuju isključivo na radnom mjestu broj 3. Slika 11: Tablica Potvrda nakon ažuriranja putem pohranjene procedure posluzivanje 29

35 Pohranjena procedura dohvatneposluzenih Jedna od opcija modula RQM.služba, RQM.info i RQM.web je prikaz broja korisnika u repu prema kategoriji. U svrhu dostave traženih vrijednosti kreirana je pohranjena procedura neposluzeni. Navedena procedura na temelju vrijednosti parametra pri, primljenog od nabrojanih modula, prebrojava zapise u bazi gdje je vrijednost atributa vrdolaska NULL što označava da potvrda još nije obrađena. Izvorni SQL kod opisane pohranjene procedure prikazan je slikom 12. Slika 12: Izvorni SQL kod pohranjene procedure dohvatneposluzenih Pohranjena procedura sljedecirednibroj Jedna od najvažnijih informacija koju moduli sustava RQM@fpz imaju mogućnost prikazati je redni broj potvrde koja se počinje posluživati. Ta informacija je ključna korisnicima sustava kako bi znali kada je njihov red za posluživanje, kao i službenici studentske službe koja na temelju te informacije može provjeriti ima li dolazeći korisnik ispravan redni broj na fizičkoj (ispisanoj) potvrdi. Moduli sustava zadaju vrijednost parametra rmid na temelju kojega pohranjena procedura vrši dohvat rednog broja ( rbroj ) iz tablice Potvrda gdje zadana vrijednost rmid odgovara vrijednosti atributa rmid u zapisima tablice te gdje je vrijednost atributa vrodlaska NULL. Izvorni SQL kod pohranjene procedure vidljiv je na slici 13. Slika 13: Izvorni SQL kod pohranjene procedure sljedecirednibroj 30

36 Pohranjena procedura aktivnostradnogmjesta Izračun očekivanog vremena do posluživanja temelji se, između ostaloga, na broju radnih mjesta studentske službe koji aktivno poslužuju korisnike. Prilikom obavljanja određenih administrativnih poslova službenica studentske službe nije u mogućnosti posluživati korisnike te je samim time radno mjesto službenice neaktivno. U svrhu kontrole aktivnosti radnih mjesta potrebno je bazi podataka osigurati mehanizam koji će pratiti njihovu aktivnost. Opisani problem riješen je dodavanjem atributa aktivnost tablici RadnoMjesto koji može poprimiti dvije vrijednosti, 0 i 1. Vrijednost 0 je zadana vrijednost atributa i označava radno mjesto neaktivnim, dok vrijednost 1 označava da je radno mjesto aktivno te se na njemu vrši posluživanje korisnika. Promjena vrijednosti atributa aktivnost izvršava se putem pohranjene procedure aktivnostradnogmjesta, čiji je izvorni SQL kod prikazan slikom 14. Slika 14: Izvorni SQL kod za pohranjenu proceduru aktivnostradnogmjesta Prilikom pokretanja modula RQM.služba, pohranjenoj proceduri dostavlja se vrijednost koji odgovara radnom mjestu na kojemu je modul pokrenut te vrijednost 1 Na temelju dostavljenih vrijednosti parametara izvršava se ažuriranje odgovarajućeg retka u tablici RadnoMjesto koja je prikazana slikom 15. Prilikom zatvaranja modula, vrijednost mijenja se iz 1 u 0 te se tablica ponovno ažurira. Slika 15: Prikaz tablice RadnoMjesto 31

37 Pohranjena procedura prosjecnovrijemeposluzivanja Pohranjena procedura prosjecnovrijemeposluzivanja, čiji je izvorni SQL kod prikazan slikom 16, namijenjena je dohvatu prosječnog vremena posluživanja korisnika pojedine kategorije. Vrijednost pohranjene procedure prosljeđuje se, na zahtjev, modulu RQM.info koji prosječno vrijeme posluživanja prikazuje kao informaciju na info zaslonu. Slika 16: Izvorni SQL kod pohranjene procedure "prosjecnovrijemeposluzivanja" Slika Okidač trajanjeposluzivanja Okidač trajanjeposluzivanja izvršava se po ažuriranju retka tablice Potvrda od strane pohranjene procedure posluzivanje s ciljem postavljanja vrijednosti atributa vrposluzivanja. Atribut vrposluzivanja označava vrijeme trajanja posluživanja jedne potvrde i rezultat je razlike atributa vrodlaska i vrdolaska što je vidljivo iz slike 11. Slika 17: Izvorni SQL kod za okidač trajanjeposluzivanja Iz slike 17, redak 4, vidljivo je kako se okidač izvršava tek kada se izvrši ažuriranje atributa vrodlaska što označava završetak posluživanja jedne potvrde. 32

38 Okidač ocekivanovrijemedoposluzivanja Očekivano vrijeme do posluživanja je parametar koji se izračunava dinamički, a u ovisnosti je o broju aktivnih radnih mjesta, prethodnim vremenima trajanja posluživanja, broju korisnika u repu, te odabranoj kategoriji tj. prioritetu. Okidač ocekivanovrijemedoposluzivanja izvršava se prilikom umetanja novog zapisa u tablicu Potvrda od strane pohranjene procedure dolazni. Unutar samog okidača implementiran je algoritam za izračun očekivanog vremena, a njegovo izvršavanje rezultira ažuriranjem atributa ocekvr, unutar tablice Potvrda, dobivenom vrijednošću Testiranje Testiranje baze podataka je zahtjevan i neizbježan zadatak koji je nužno provoditi kako bi se postigla željena funkcionalnost. Izvodi se, nerijetko, velikim brojem iteracija unosa podataka i njihove analize kako bi se otkrile i otklonile eventualne pogreške nastale tijekom razvoja. Baza podataka, razvijena za sustav RQM@fpz, testirana je unosom preko 4000 zapisa (vidljivo na slikama 10 i 11, vrijednost atributa ticketid ) tijekom perioda od pet mjeseci. Testiranje je provedeno s ciljem ispravljanja razvojnih pogrešaka prilikom kreiranja fizičke strukture baze, kreiranja pohranjenih procedura i okidača, te s ciljem provjere ponašanja baze u različitim okolnostima. Također, tijekom razvoja modula sustava, baza je testirana u svrhu prilagodbe određenih pohranjenih procedura s ciljem uspostave funkcionalnosti i stabilnosti razvijenog sustava. Način testiranja provodio se u dvije faze. Tijekom prve faze baza je testirana putem SQL razvojnog okruženja, odnosno manualnim pokretanjem pohranjenih procedura te analizom podataka zapisanih u bazi. Drugom fazom, u testiranje su uključeni i razvijeni moduli sustava putem kojih se vršio unos, ažuriranje i dohvat podataka čime su otkrivene i ispravljene određene pogreške. 33

39 6.5. Održavanje Održavanje baze podataka predstavlja kontinuiran i složen proces koji započinje njezinim ulaskom u redovnu uporabu. Ovim potpoglavljem biti će ukratko objašnjen način na koji je planirano održavanje baze podataka nakon njezinog ulaska u redovnu uporabu. Prema [9], postupak održavanja baze podataka planiran je na tri razine: 1) Korekcijsko održavanje odnosi se na ispravljanje pogrešaka koje nisu otkrivene tijekom faze testiranje, 2) Perfekcijsko održavanje obuhvaća izmjenu ili prilagodbu početne sheme radi prilagodbe novim aplikacijama ili modulima sustava koji nisu postojali u početku, 3) Adaptacijsko održavanje podrazumijeva prilagodbu baze u slučaju korištenja DBMS-a koji se nije koristio tijekom razvoja baze. Održavanje obuhvaća, također, i periodičko stvaranje sigurnosnih kopija baze podataka, potpunih i diferencijalnih, odnosno njihove kombinacije kako bi se mogao izvršiti njezin oporavak u slučaju gubitka podataka, [13]. Vrlo je bitan i periodički pregled i analiza dnevničkih zapisa kako bi se na vrijeme uočile i ispravile određene pogreške i poteškoće u radu baze. 34

40 7. RAZVOJ MODULA SUSTAVA 7.1. Modul RQM.kiosk Aplikacija RQM.kiosk je modul sustava a namijenjena je korisnicima koji žele koristiti usluge studentske službe Fakulteta prometnih znanosti. Korisnici se pomoću nje prijavljuju na posluživanje, te ih se svrstava u rep. Izgled aplikacije prikazan je na slici 18. Korisnici će se moći upoznati s popisom administrativnih poslova vezanih za određenu kategoriju posluživanja putem info plakata u predvorju Fakulteta, te na službenim stranicama Fakulteta. Slika 18: Izgled aplikacije RQM.kiosk Sama aplikacija se sastoji od polja za unos JMBAG-a, tipki za unos brojeva i brisanje, te dvije tipke za odabir kategorije. Unos JMBAG-a se vrši na način da korisnik putem dodirnika (engl. touchscreen) upisuje vlastiti JMBAG, te potom odabire željenu kategoriju. Nakon toga korisniku se ispisuje potvrda s oznakom odabrane kategorije, rednim brojem, JMBAG-om, vremenom kada je potvrda zatražena, te očekivanim vremenom do posluživanja. 35

41 Aplikacija RQM.kiosk je izgrađena u razvojnom alatu Microsoft Visual Studio 2010, pri čemu su korištene Microsoft.NET komponente čije ponašanje je definirano programskim jezikom C#. Microsoft.NET komponente korištene pri izradi aplikacije su sljedeće: - textbox za upis JMBAG-a unosjmbag - tipke za unos brojeva od 0 do 9 tipka0 tipka9 - tipka za brisanje cijelog unosa C tipkabrisisve - tipka za brisanje zadnjeg unesenog broja tipkabrisi - tipka za odabir kategorije A kategorija_a - tipka za odabir kategorije B kategorija_b Za potrebe unosa JMBAG-a kreirane su tipke s vrijednostima od 0 do 9. Prilikom pritiska na tipku u polje za unos (engl. textbox) se upisuje vrijednost koja je definirana samom tipkom. U slučaju da korisnik želi izbrisati zadnji uneseni broj u textbox, to će učiniti pritiskom na tipku. Brisanje cjelokupnog sadržaja textboxa se obavlja tipkom C. Nakon što je korisnik unio svoj JMBAG, odabire kategoriju posluživanja pritiskom na odgovarajuću tipku. Prilikom odabira kategorije aplikacija izvršava nekoliko operacija. Prvo što aplikacija radi jest povezivanje sa bazom podataka. Sljedeća operacija jest slanje vrijednosti ulaznih parametara pohranjenoj proceduri dolazni u bazi podataka. Te vrijednosti su netom upisani JMBAG i odabrana kategorija. Zatim se izvršava ažuriranje baze podataka s novim ulaznim parametrima i provjera se postoji li uneseni JMBAG u bazi podataka, te se provjerava je li očekivano vrijeme do posluživanja manje od radnog vremena studentske službe. U slučaju da uneseni JMBAG ne postoji u bazi podataka, korisniku se na zaslonu ispisuje poruka NEISPRAVAN JMBAG!. Ukoliko JMBAG postoji u bazi podataka, korisniku se ispisuje potvrda i briše se sadržaj upisan u textboxu, te idući korisnik može koristiti aplikaciju. U slučaju kada očekivano vrijeme do posluživanja prelazi radno vrijeme studentske službe, korisniku se na zaslonu ispisuje poruka OČEKIVANO VRIJEME DO POSLUŽIVANJA PRELAZI RADNO VRIJEME STUDENTSKE SLUŽBE. Prethodno navedeni procesi prikazani su UML sekvencijalnim dijagramom na slici

42 Korisnik RQM.kiosk Baza podataka unos traženih podataka (JMBAG, kategorija) slanje vrijednosti unesenih parametara (JMBAG, kategorija) unos zapisa slanje vrijednosti traženih parametara izračun očekivanog vremena do posluživanja izdavanje potvrde ispis potvrde Slika 19: Prikaz procesa izdavanja potvrde pomoću modula RQM.kiosk Ispisana potvrda sadrži JMBAG kao način zaštite od njezine zloupotrebe, tj. da ne bi dolazilo do zamjene potvrda među korisnicima ili da korisnik ne bi nasumično ispisivao potvrde za svoje kolege koje će tek naknadno doći i time eventualno poremetiti prosječno vrijeme posluživanja jer dotični korisnici nisu na vrijeme stigli na posluživanje. Potvrda također sadrži i vrijeme izdavanja potvrde, oznaku kategorije i redni broj posluživanja, te očekivano vrijeme do posluživanja Modul RQM.služba Aplikacija RQM.služba je modul sustava RQM@fpz, a namijenjena je korištenju službenicama studentske službe Fakulteta prometnih znanosti. Funkcije aplikacije RQM.služba moguće je podijeliti u dvije skupine. Prva funkcija je pozivanje korisnika u repu na posluživanje, dok je druga funkcija pružanje uvida u trenutno stanje repa. Izgled aplikacije prikazan je na slici 20. Pri dizajnu aplikacije stavljen je naglasak prema jednostavnosti izgleda sučelja jer je predviđeno da aplikacija bude u always on top modu, kako bi što manje ometala službenice studentske službe u radu na računalu. 37

43 Slika 20: Grafičko sučelje modula RQM.služba Sučelje aplikacije sačinjavaju četiri glavna dijela. Prvi dio je prikaz sistemskog vremena. U drugom dijelu se nalazi prikaz trenutnog stanja repa, odnosno, koliko korisnika pojedine kategorije trenutno čeka na posluživanje, dok se u trećem dijelu prikazuje sljedeći dolazni redni broj. Četvrti dio sučelja aplikacije je tipka za pozivanje sljedećeg korisnika na posluživanje. Za potrebe sustava RQM@fpz izrađene su četiri različite aplikacije RQM.služba. Svaka aplikacija u programskom kodu ima implementiranu vrijednost odgovarajućeg radnog mjesta zbog izbjegavanja postavljanja dodatnog izbornika za odabir radnog mjesta unutar grafičkog sučelja aplikacije, čime je očuvana jednostavnost izgleda same aplikacije. Aplikacija RQM.služba je izrađena, poput aplikacije RQM.kiosk, u razvojnom alatu Microsoft Visual Studio 2010, pri čemu su korištene Microsoft.NET komponente čije ponašanje je definirano programskim jezikom C#. Microsoft.NET komponente korištene pri izradi aplikacije su sljedeće: - label za prikaz vremena sustava vrijeme - label za prikaz broja korisnika u repu za kategoriju A kat_a_u_red - label za prikaz broja korisnika u repu za kategoriju B kat_b_u_red - label za prikaz rednog broja potvrde koja sljedeća dolazi na posluživanje sljedecirb - tipka za pozivanje sljedećeg korisnika na posluživanje sljedecistudent - timer za povlačenje vrijednosti sistemskog vremena vrijeme1 - timer za osvježavanje broja korisnika u repu za kategoriju A kat_a - timer za osvježavanje broja korisnika u repu za kategoriju B kat_b - timer za osvježavanje rednog broja potvrde sljedecirb 38

44 U gornjem desnom kutu grafičkog sučelja aplikacije je postavljen prikaz datuma i sistemskog vremena. Osvježavanje trenutnog vremena sustava se obavlja pomoću brojača (engl. timer) vrijeme1, sama vrijednost ispisuje se u oznaci (engl. label) vrijeme. U svrhu pružanja uvida službenicama u trenutno stanje repa postavljena su dva labela u kojima se prikazuje trenutno stanje repa za pojedinu kategoriju. Vrijednosti u njima osvježavaju se pomoću dva timera kat_a i kat_b koji su programirani da svaku sekundu iz baze podataka, putem pohranjene procedure dohvatneposluzenih, vrše dohvat trenutnog stanja repa. Kada se na izlazu iz repa pojavi korisnik koji dolazi na posluživanje, redni broj njegove potvrde će se prikazati u labelu sljedecirb. Pritiskom na tipku sljedecistudent se poziva pohranjena procedura sljedecirednibroj koja vrši dohvat vrijednosti rednog broja potvrde iz baze podataka s kojom će sljedeći korisnik doći na posluživanje. Početak posluživanja novog korisnika vrši se pritiskom tipke sljedecistudent, što rezultira ažuriranjem tablice Potvrda u bazi podataka. U labelu koji sadrži broj korisnika u repu, vrijednost broja se umanjuje za jedan, odnosno, prikazuje se novo trenutno stanje. Po završetku posluživanja, ponovnim pritiskom na tipku sljedecistudent završava se posluživanje trenutnog korisnika i poziva se sljedeći korisnik iz repa na posluživanje. Istovremeno se vrši ažuriranje tablice Potvrda u bazi podataka putem pohranjene procedure posluzivanje koja upisuje vrijeme odlaska korisnika s poslužiteljskog mjesta i paralelno upisuje vrijeme dolaska novog korisnika na posluživanje. Slika 21Slika 21 prikazuje proces koji aplikacija obavlja prilikom posluživanja korisnika. Službenica RQM.služba Baza podataka tipka "SLJEDEĆI STUDENT" vrijednosti parametra (slid, rmid) ažuriranje tablice "Potvrda" prikaz dolaznog rednog broja vrijednost sljedeceg rednog broja dohvat sljedečeg rednog broja Slika 21: UML sekvencijalni dijagram posluživanja korisnika putem modula RQM.služba 39

45 7.3. Modul RQM.info Aplikacija RQM.info je modul sustava namijenjen korisnicima Fakulteta prometnih znanosti koji koriste usluge studentske službe. Aplikacija prikazuje redne brojeve koji se trenutno poslužuju na radnim mjestima studentske službe, vrijednosti broja korisnika pojedine kategorije koji čekaju na posluživanje, te prosječno vrijeme posluživanja za pojedinu kategoriju. Grafičko sučelje aplikacije RQM.info prikazano je na slici 22. Sama aplikacija se prikazuje na zaslonu koji je postavljen u predvorju Fakulteta. Modul RQM.info je izrađen kako bi korisnici koji čekaju na posluživane mogli pratiti proces posluživanja i imati uvid u trenutno stanje repa. Prilikom pozivanja sljedećeg korisnika na posluživanje, oglasit će se zvučni signal koji će upozoriti da se jedno radno mjesto oslobodilo. Slika 22: Grafičko sučelje modula RQM.info Aplikacija RQM.info je, poput prethodne dvije, izgrađena u razvojnom alatu Microsoft Visual Studio 2010, pri čemu su korištene Microsoft.NET komponente čije ponašanje je definirano programskim jezikom C#. Microsoft.NET komponente korištene pri izradi aplikacije su sljedeće: - labeli za prikaz rednog broja potvrde koji se trenutno poslužuje na radnom mjestu 1 do radnog mjesta 4 RB_radno_mjesto_1, RB_radno_mjesto_4 - label za prikaz trenutnog broja korisnika kategorije A u repu kat_a_u_repu - label za prikaz trenutnog broja korisnika kategorije B u repu kat_b_u_repu 40

46 - label za prikaz prosječnog vremena posluživanja kategorije A pros_vri_kat_a - label za prikaz prosječnog vremena posluživanja kategorije B pros_vri_kat_b - timer za ažuriranje rednog broja potvrde koja se trenutno poslužuje na radnom mjestu 1 tick_rm_1 - timer za ažuriranje rednog broja potvrde koja se trenutno poslužuje na radnom mjestu 2 tick_rm_2 - timer za ažuriranje rednog broja potvrde koja se trenutno poslužuje na radnom mjestu 3 tick_rm_3 - timer za ažuriranje rednog broja potvrde koja se trenutno poslužuje na radnom mjestu 4 tick_rm_4 - timer za ažuriranje broja korisnika kategorije A u repu tick_kat_a_rep - timer za ažuriranje broja korisnika kategorije B u repu tick_kat_b_rep - timer za ažuriranje vrijednosti prosječnog vremena posluživanja kategorije A tick_pros_vri_kat_a - timer za ažuriranje vrijednosti prosječnog vremena posluživanja kategorije B tick_pros_vri_kat_b Kada službenica u aplikaciji RQM.služba pritisne tipku sljedecistudent, korisnik koji se nalazi na izlazu iz repa se poziva na posluživanje na radno mjesto s kojeg je odaslan zahtjev za početak posluživanja. Pri tom se u bazi podataka upisuje vrijeme početka posluživanja i identifikacijski broj radnog mjesta rmid. Timeri za osvježavanje rednog broja potvrde svaku sekundu ažuriraju aplikaciju s novim stanjem u bazi podataka i kada se promjena dogodi, u label za prikaz rednog broja potvrde upisuju novi redni broj koji pohranjena procedura sljedecirednibroj šalje ka aplikaciji kao izlaznu vrijednost. Korisnicima je omogućeno praćenje trenutnog stanja repa koje se ispisuje u labelima za prikaz trenutnog stanja repa za pojedinu kategoriju. Princip rada je identičan kao i kod modula RQM.služba. Pomoću timera tick_kat_a_rep i tick_kat_b_rep svaku sekundu se ažurira vrijednost broja korisnika u repu za pojedinu kategoriju. Dohvat vrijednosti vrši se putem pohranjene procedure dohvatneposluzenih u bazi podataka. U svrhu dodatne informiranosti korisnika o stanju repa omogućen je i uvid u prosječno vrijeme posluživanja korisnika za pojedinu kategoriju. Timeri za ažuriranje vrijednosti prosječnog vremena kategorija A i B svakih 30 sekundi iz baze podataka vrše dohvat 41

47 vrijednosti prosječnog vremena koju kao izlaznu vrijednost daje pohranjena procedura prosjecnovrijemeposluzivanja Modul RQM.web RQM.web je naziv web aplikacije koja je jedan od modula sustava Svrha aplikacije je informiranje korisnika sustava o trenutnom statusu izdane potvrde. Važno je napomenuti da korisnik mora imati omogućen pristup Internetu putem svojeg osobnog ili prijenosnog računala, mobilnog terminalnog uređaja ili tablet računala kako bi mu bila omogućena usluga. Jednostavan dizajna sučelja omogućuje lakše i brže snalaženje korisnika unutar same aplikacije koja je podijeljena u tri dijela, što je vidljivo iz slike 23. Slika 23: Grafičko sučelje modula "RQM.web" Prvi dio aplikacije namijenjen je unosu rednog broja ispisanog na potvrdi u za to definirano polje. Nakon unosa rednog broja potvrde aplikacija se, pritiskom na tipku PROVJERI povezuje sa bazom podataka s ciljem dohvata podataka. 42