3.1.1 Naprava za zajem in preraˇ cun meritev
Uporabljena naprava za zajem meritev in nadaljnji izraˇcun je mali raˇcunalnik RPI podrobneje opisan v poglavju 2.1.1 s pripadajoˇco nadgradnjo opisano v poglavju 2.1.2.
Za komunikacijo in poˇsiljanje podatkov je bil uporabljen protokol MQTT v kombi-naciji z WebSocket protokolom. Kot je bilo ˇze podrobneje predstavljeno v poglavju 2.2.1.1, protokol MQTT deluje po sistemu objavi-naroˇci, kjer so klienti lahko posa-mezne naprave ali aplikacije, ki imajo razliˇcne funkcije, in lahko podatke objavljajo, prejemajo ali oboje hkrati. Zaradi enostavnejˇse izdelave programov in boljˇsega izko-ristka raˇcunalniˇskih virov (ˇzeleli smo se izogniti izvedbi preraˇcuna na samem spletnem streˇzniku, kjer prebiva spletna aplikacija), se na RPI hkrati izvaja veˇc posameznih Python programov oz. aplikacij, ki poleg svoje funkcije sluˇzijo tudi kot klienti. Doda-ten razlog take zasnove je tudi modularnost. V primeru, da bi ˇzeleli razˇsiriti funkcional-nost naˇse aplikacije in izvajati ˇse druge naˇcine obdelave podatkov, bi lahko enostavno izdelali dodatne kliente, ki lahko prebivajo tudi na drugih raˇcunalnikih. Pomembno je zgolj, da se ti poveˇzejo na MQTT posrednik in posluˇsajo oziroma objavljajo na ustrezno temo.
S tem namenom smo naslove MQTT tem (ang. topic) doloˇcili na sledeˇc naˇcin:
– Preko teme <ime_gostitelja>/control upravljamo z naˇso napravo. Na njo ob-javimo parametre, na katere se naprava odzove (npr. frekvenco zajema, ali naj se meritev shrani, ˇcas meritve itd.)
– Na temo <ime_gostitelja>/status naprava objavlja, ali je v pripravljenosti in ali trenutno zajema podatke ali ne. Na podlagi stanja o napravi v aplikaciji vemo, kaj se z njo dogaja.
– Tema <ime_gostitelja>/dataje najpomembnejˇsa tema, saj se na njo objavlja tok surovih podatkov v binarni obliki. Ta tok zajema drug klient na napravi in opravlja shranjevanje in izraˇcun, hkrati pa se tok preusmerja na protokol WebSocket in s tem v Django aplikacijo, da lahko izvedbo meritve spremljamo v realnem ˇcasu.
– <ime_gostitelja>/check je tema, na katero objavimo, kadar ˇzelimo preveriti sta-nje.
– <ime_gostitelja>/check/measurements je tema, ki nam sporoˇca stanje o datote-kah. Tako vemo, katere datoteke so shranjene na napravi in pripravljene za prenos na 34
Izdelava spletne aplikacije in sistema za zajem streˇznik in pregled rezultatov. Kot odgovor naprava na<ime_gostitelja>/measurements objavi seznama vseh shranjenih datotek.
– Tema<ime_gostitelja>/check/measurements/downloadse podobno kot prejˇsnja toˇcka, navezuje na datoteke shranjene na napravi. Z objavo ustreznega niza na to temo sproˇzimo prenos izbranih datotek na streˇznik.
<ime_gostitelja>je poljubno ime gostitelja, v naˇsem primeru je to raspberry.
Pri protokolu MQTT lahko izbiramo poljubno ˇstevilo tem in jih oblikujemo po naˇsem okusu. Na temo enostavno objavimo in ˇze lahko posluˇsamo njeno vsebino preko posre-dnika. Na napravi imamo torej tri kliente, ki bodo podrobneje razloˇzeni v nadaljevanju, tudi skozi izrezke programske kode.
3.1.1.1 Klient za zajem meritve
Prvi klient skrbi za upravljanje ADC in DAC nadgradnje malega raˇcunalnika RPI.
Odpira ter zapira tok podatkov. Poleg tega podaja trenutno stanje naprave in meritve, ki se izvajajo. Program je zaradi svoje narave (neprekinjenega toka podatkov v ˇcasu zajema) napisan asinhrono, torej s pomoˇcjo Python knjiˇzice asyncio in asinhrone knjiˇzice za implementacijo MQTT protokolaasyncio mqtt. Tak naˇcin nam omogoˇca, da lahko kljub neprekinjenemu toku podatkov (tega lahko uporabnik spremlja med meritvijo v aplikaciji), ki ga poˇsiljamo med zajemom in bi ponavadi blokiral celoten program, ˇse vedno prejemamo ukaze poslane s strani drugih klientov. Zajem preko zvoˇcne kartice oz. nadgradnje izvajamo s pomoˇcjo knjiˇzice PyAudio, ki je dokaj enostavna za uporabo in uˇcinkovito zajema vhodni kanal ter vraˇca surove binarne podatke v manjˇsih delih (ang. chunk) oz. buferjih. Te nato asinhrono objavljamo MQTT posredniku, ki podatke posreduje naprej drugim klientom.
Potek programa, katerega programska koda je prikazana v prilogi, je sledeˇc: na zaˇcetku uvozimo potrebne knjiˇzice. Sledi definicija osnovnih vrednosti. Najprej pridobimo osnovne informacije o napravi (ime, MAC naslov in vrsto nadgradnje), ki jih ob po-vezavi na spletno aplikacijo posredujemo, da nas ta prepozna. Nato sledi definicija prevzetih vrednosti v obliki Python slovarja (slovar smo izbrali, ker se ga da eno-stavno pretvori v *.json format, ki je v veliki veˇcini uporabljen pri poˇsiljanju enostavnih sporoˇcil preko MQTT). ˇCeprav se v praksi pri programiranju izogibamo spreminjanju globalne spremenljivke iz funkcij, smo jo tu koristili za shranjevanje vrednosti ukazov, ki jih program prejme od drugih klientov in se na podlagi teh odloˇci kakˇsen je nasle-dnji korak. Sledi glavna asinhrona funkcija, ki izbere asinhrone naloge ter priˇcne z izvajanjem. V tem delu definiramo, na katere teme je klient naroˇcen in na katere bo objavljal. V drugem delu programa sta definirani ˇse dve asinhroni funkciji, prva ki je zadolˇzena za prejemanje sporoˇcil in druga za poˇsiljanje toka podatkov. V zadnjem delu programa le ˇse poskrbimo za zakljuˇcevanje nalog in da se program izvaja neskonˇcno.
Za laˇzje razumevanje so programski kodi dodani komentarji. Koda je zaradi obseˇznosti priloˇzena na zadnjih straneh naloge.
Izdelava spletne aplikacije in sistema za zajem 3.1.1.2 Klient za delo z datotekami
Drugi klient je zadolˇzen za poroˇcanje o shranjenih meritvah in izraˇcunih na napravi.
Tu smo uporabili klasiˇcen objektni naˇcin programiranja, saj potrebe po asinhronosti ni bilo (poˇsiljamo in prejemamo le enostavna sporoˇcila v obliki nizov). Za MQTT komu-nikacijo se je uporabila uradna mqtt knjiˇzica, ki deluje na principucallback funkcij.
Program je razmeroma enostaven. V konstruktorju so najprej definirani vsi potrebni parametri od IP naslova, poti do datotek in callback funkcij. Nato sta definirani me-todi za povezavo s klientom in prejemanje sporoˇcil. V drugem delu je ˇse metoda, ki nam vrne in objavi seznam meritev v mapi in metoda, ki skrbi za prenos datotek na streˇznik. Slednja je navaden HTTP (”POST”) zahtevek, ki na poziv uporabnika poˇslje datoteke izraˇcuna in zajema na Django zaledni sistem. Tako enostavno prenesemo re-zultate izraˇcuna, ki se je izvajal na zajemni napravi na streˇznik spletne aplikacije, in si jih ogledamo preko uporabniˇskega vmesnika. Tudi programska koda tega klienta je priloˇzena na koncu magistrskega dela.
3.1.1.3 Klient za izvedbo izraˇcuna in shranjevanje datotek
Funkcija tretjega klienta je izvedba izraˇcuna in shranjevanje meritev. Podobno kot drugi klient je tudi ta sprogramiran na klasiˇcni objektni naˇcin. Klient se najprej poveˇze na MQTT posrednika in posluˇsa na kanalu, kjer prvi klient objavlja surove binarne podatke v ˇcasu zajema. Ko klient prejme znak, da se je zajem podatkov zaˇcel izvajati, glede na zahteve uporabnika (katere ta poda v aplikaciji in bodo razloˇzene v nadaljevanju poglavja) zaˇcne s shranjevanjem surovih binarnih podatkov. Na zaˇcetku se izvaja le dodajanje v seznam, ko pa klient dobi sporoˇcilo, da se je zajem zakljuˇcil, izvede ˇse preraˇcun. V prvem delu izraˇcuna pretvorimo binarne podatke obeh kanalov v cela ˇstevila. Loˇci se posamezen kanal in vsakega se ustrezno skalira glede na izhodno napetost nadgradnje in uporabljeno merilno opremo ter tip meritve. Tako v naˇsem primeru dobimo seznam ustreznih amplitudnih vrednosti posameznega kanala po ˇcasu.
Nato sledi glavni del izraˇcuna. Tu smo uporabili Welchovo metodo za pridobitev ce-nilk frekvenˇcne prenosne funkcije. Izraˇcun se nato shrani v dveh razliˇcnih oblikah.
Vse vrednosti se najprej shranijo v *.npz formatu, ki je format za shranjevanje numpy seznamov v binarni obliki. Datoteko lahko uporabnik v spletni aplikaciji prenese in enostavno uvozi v svojih Python programih za nadaljnje analize. Druga oblika podat-kov je shranjena v *.json datoteki. Ta tip datoteke je velikokrat uporabljen pri razvoju spetnih aplikacij, kjer je zaˇcelni del razvit s pomoˇcjo programskega jezika JavaScript.
V naˇsem primeru je za interaktivno vizualizacijo podatkov v aplikacie tovrsten format kljuˇcen. Sam program klienta je priloˇzen v prilogi magistrskega dela.
3.1.2 Povezava med napravo in spletno aplikacijo
Kljuˇcni element povezave med posameznimi klienti in spletno aplikacijo je MQTT posrednik. Izbrani MQTT posrednik je bil odprtokodni posrednik Eclipse Mosqitto [11], ki se v naˇsem primeru izvaja v Docker kontejnerju. Ta skrbi, da lahko z napravami upravljamo na daljavo, spremljamo njihovo stanje, ter v blizu realnega ˇcasa opazujemo 36
Izdelava spletne aplikacije in sistema za zajem meritev, ki se izvaja. Poleg MQTT posrednika je bilo potrebno implementirati ˇse klienta, ki nam vsebino MQTT sporoˇcil preusmeri na WebSocket protokol, ki je osnova pri razvoju aplikacij z razˇsiritvijo Django Channels. Razˇsiritev je bila podrobneje predstavljena v podpoglavju 2.2.2.1. Nekoliko veˇc o tem, zakaj je bilo to potrebno, v diskusiji. ˇCe povzamemo, MQTT kanale smo uporabili za upravljanje in pretakanje med posameznimi klienti, od katerih ima vsak svojo funkcijo, protokol WebSocket pa zaradi svoje uˇcinkovitosti in tudi boljˇse podpore v spletnih brskalnikih za prikaz zajema podatkov v realnem ˇcasu.
Preusmeritev je izvedena preko enostavnega programa, ki lahko prebiva ali na napravi za zajem ali na streˇzniku. Program je napisan asinhrono in vse kar poˇcne je, da posluˇsa MQTT temo, kjer je objavljen tok surovih binarnih podatkov in prejete pakete poˇsilja preko WebSocket protokola naprej. Zaledje naˇsega sistema v kombinaciji z Redis streˇznikom (ki zaradi enostavnejˇse konfiguracije prav tako prebiva v Docker kontejnerju) podatke prejema in jih posreduje naprej (veˇc o tem v naslednjem poglavju 3.1.3).
Izdelava spletne aplikacije in sistema za zajem
Za izdelavo zalednega sistema (ang. backend) spletne aplikacije je bil uporabljen Django - paket za izdelavo spletnih strani in aplikacij, podrobneje opisan v pod-poglavju 2.2.2.1, za izdelavo zaˇcelnega sistema (ang. frontend) pa HTML, CSS in programski jezik JavaScript.
Naˇs Django projekt oziroma spletna aplikacija kot celota je razdeljen na veˇc manjˇsih aplikacij, od katerih vsaka skrbi za doloˇceno funkcionalnost. To nam omogoˇca laˇzje programiranje in moˇznost enostavnega dodajanja novih funkcij v prihodnje. Aplikacije, ki sestavljajo naˇs Django projekt so:
– Aplikacija, ki skrbi za vpis in ustvarjanje novih uporabnikov ter dodajanje novih naprav (v kodi poimenovana account).
– Aplikacija, ki skrbi za upravljanje nadgradnje na napravi za zajemanje meritev in prikaz toka podatkov v bliˇzini realnega ˇcasa trenutno izvajajoˇce meritve (v kodi poimenovana mqtt stream).
– Aplikacija, ki skrbi za shranjevanje in prikaz meritev ter izvedenih preraˇcunov na podlagi le-teh (V kodi poimenovanameasurement).
Strukturo celotnega projekta in vsake podaplikacije prikazujeta sliki 3.2. Na sliki 3.2a vidimo, da osnovni direktorij projekta v naˇsemu primeru poimenovanega mqtt stream, vsebuje poddirektorij za vsako zgoraj na seznamu omenjeno aplikacijo. Poleg tega imamo ˇse mapo z istim imenom kot projekt, torej mqtt stream, ki vsebuje osnovne konfiguracije streˇznika, okolja in podatkovne baze ter direktorij media, kjer so shra-njene datoteke (v naˇsem primeru meritve). Slika 3.2b pa prikazuje osnovno drevesno strukturo vsake podaplikacije. Tu je vredno omeniti, da vsaka ustvarjena podaplikacija Django projekta vsebuje osnovne datoteke, ki so potrebne za osnovno funkcionalnost, glede na naˇse potrebe pa lahko poljubno dodajamo drugo logiko. V osnovi so v mapi static datoteke za logiko zaˇcelnega sistema (CSS in JS programska koda), v mapi tem-plates pa HTML predloge. Ostale datoteke imajo vsaka svojo funkcijo (npr. admin.py za definicijo prikaza v admin straneh,models.py za definicijo tabel v podatkovni bazi, views.py za definicijo pogledov aplikacije in urls.py za definicijo poti posameznega pogleda).
V nadaljevanju ne bomo podrobno opisovali strukture vsakega dela spletne aplikacije, temveˇc se bomo osredotoˇcili na dele in konfiguracije, ki so bili kljuˇcni, da smo dosegli ˇ
zeljeno funkcionalnost; torej spremljanje meritev z visoko frekvenco vzorˇcenja v realnem ˇ
casu in izvedba izraˇcuna cenilk frekvenˇcne prenosne funkcije.V prvem podpoglavju bodo tako opisane posebnosti zalednega sistema, v drugemu delu pa zaˇcelnega sistema.
V tretjem delu bo predstavljen naˇcin uporabe aplikacije s posnetki zaslona.
38
Izdelava spletne aplikacije in sistema za zajem
(a) (b)
Slika 3.2: (a) Drevesna struktura celotne spletne aplikacije oz. Django projekta (b) drevesna struktura posamezne manjse aplikacije.
3.1.3.1 Zaledni sistem aplikacije
Ker smo ˇzeleli spremljati potek meritve v realnem ˇcasu, smo poleg osnovnega Django paketa, kot ˇze zgoraj omenjeno, uporabili tudi razˇsiritev Django Channels. Za njegovo delovanje, kot je to opisano v podpoglavju 2.2.2.1, potrebujemo plast kanala, kjer smo uporabili Redis, ki se prav tako izvaja v svojem Docker kontejnerju. Django Channels v naˇsem primeru skrbi za posredovanje podatkov v realnem ˇcasu na zaˇcelni sistem preko WebSocket protokola, kjer jih z uporabo programskega jezika JS in knjiˇzice Chart.js [32]
prikazujemo.
Konfiguracija Vmesnika asinhronega streˇzniˇskega prehoda
Za uporabo WebSocket protokola v kombinaciji z Django paketom za izdelavo spletnih aplikacij, je potrebna konfiguracija vmesnika asinhronega streˇzniˇskega prehoda (ASGI).
Klasiˇcne spletne aplikacije, kjer ne potrebujemo asinhronosti, uporabljajo klasiˇcen vme-snik spletnega streˇznika (WSGI). Ta je tudi privzet v Django paketu.
Da lahko namestimo ASGI, moramo najprej na naˇs streˇznik namestiti Redis, ki bo sluˇzil kot plast kanala za prenos sporoˇcil. To najenostavneje storimo s pomoˇcjo uradne Redis Docker slike (ang. Docker image). Na streˇzniku, kjer imamo nameˇsˇcen Docker, poˇzenemo ukaz$ docker run --name oddaljeno-spremljanje-redis -d redis. Na naˇsemu streˇzniku imamo tako delujoˇc Redis, ki se po privzetih vrednostih nahaja na vratih 6379.
Ko smo prepriˇcani, da Redis streˇznik deluje, v naˇse virtualno okolje, kjer prebiva spletna aplikacija namestimo ˇse paket, ki ga programski jezik Python potrebuje za delo z njim pip install redis. Naslednji korak je seznanitev Django paketa, da za komunikacijsko plast uporabi Redis. To storimo tako, da v glavnem direktoriju Django projekta (v datoteko z nastavitvami settings.py) dodamo sledeˇce:
1 A S G I _ A P P L I C A T I O N = ’ m q t t _ p r o x y . a s g i . a p p l i c a t i o n ’
2 C H A N N E L _ L A Y E R S = {
3 ’ d e f a u l t ’: {
4 ’ B A C K E N D ’: ’ c h a n n e l s _ r e d i s . c o r e . R e d i s C h a n n e l L a y e r ’,
Izdelava spletne aplikacije in sistema za zajem
Kjer je IP naslov, naslov lokacije Redis streˇznika. Zadnji korak, da bo naˇsa aplikacija uporabljala ASGI namesto WSGI je definicija WebSocket protokola. To storimo z vpisom naslednjih nastavitev v datoteko asgi.py, ki prav tako prebiva v glavnem direktoriju Django projekta.
To so glavni koraki, ki jih je potrebno narediti, da lahko zaˇcnemo uporabljati razˇsiritev Django Channels za delo s protokolom WebSockets. Tu je vredno ˇse omeniti, da sedaj celoten sistem deluje preko ASGI, torej tudi klasiˇcni HTTP zahtevki.
Definicija porabnikov in poti
Naslednji korak je definicija porabnikov in poti, kjer bo WebSocket protokol dosto-pen. V praksi je seveda moˇzna definicija veˇc razliˇcnih poti, ki prebivajo v razliˇcnih delih aplikacij za razne namene. V naˇsem primeru potrebujemo le eno pot po kateri bomo prejemali tok podatkov iz zajemne naprave. V podaplikaciji, za katero smo se odloˇcili, da bo odgovorna za prejemanje toka podatkov (v naˇsem primeru poimenovana mqtt stream) ustvarimo datoteko z imenom routing.py in definiramo pot:
1 f r o m d j a n g o . u r l s i m p o r t r e _ p a t h
Izdelava spletne aplikacije in sistema za zajem Opazimo, da v poti definiramo porabnika (ang. consumer). Porabnike definiramo v loˇceni datoteki, ki smo jo poimenovaliconsumers.py in v naˇsem primeru zgleda tako:
1 i m p o r t j s o n
Kot je razvidno iz kode, tudi tu programiramo na asinhron naˇcin. Glavna funkcija tega programa je, da definiramo kaj se zgodi, ko se porabnik poveˇze na naˇs WebSocket naslov, kaj se zgodi, ko se povezava prekine in na kakˇsen naˇcin podatki prehajajo med uporabniki. Princip delovanja je ta, da vsak uporabnik, ki se poveˇze na naˇs naslov, vzpostavi WebSocket povezavo, ki je dlje ˇziveˇca (veˇc o tem je bilo opisano v poglavju 2.2.1.2), se prikljuˇci v skupino. Vsi v isti skupini prejemajo vsa sporoˇcila ter jih poˇsiljajo vsem hkrati. V naˇsem primeru lahko torej veˇc porabnikov soˇcasno spremlja meritve, saj bodo vsi prejemali tok podatkov, ki prihaja iz naprave za zajem meritve.
Ostali pogledi in modeli
Za ostale dele naˇse aplikacije (prikaz naprav, prikaz meritev, forma za upravljanje z napravo, prenos datotek ...) je bilo potrebno definirati ˇse ostale poglede. Vsi tu ne bodo predstavljeni, pokazali bomo le primer pogledov strani za prikaz meritev in
Izdelava spletne aplikacije in sistema za zajem
Za shranjevanje podatkov o uporabniku, napravah in meritvah, je bilo potrebno ustva-riti modele podatkovne baze. Definicija modela za meritve je prikazana v naslednjem izrezku kode:
Ostalo kodo spletne aplikacije si je mogoˇce ogledati v spletnem repozitoriju avtorja magistrskega dela Gregorja Obreze (Github: gregorobreza).
3.1.3.2 Zaˇcelni sistem aplikacije
Prejemanje binarnih podatkov preko WebSocket protokola in vizualizacija Kot smo ˇze veˇckrat omenili, preko WebSocket protokola v spletni brskalnik preko Django Channels prejemamo binarne podatke v ˇzivo. Surove binarne podatke smo 42
Izdelava spletne aplikacije in sistema za zajem izbrali zaradi uˇcinkovitosti prenosa. Da pa lahko podatke prikazujemo, smo jih morali s pomoˇcjo programksega jezika JS direktno pretvarjati in skalirati v cela ˇstevila. Po pretvorbi jih takoj poˇsiljamo na kanvas naˇsega grafa za prikaz. V naslednjem kratkem odseku iz kode je prikazana pretvorba in priprava optimalne podatkovne strukture, da lahko graf kar se da uˇcinkovito v ˇzivo posodabljamo.
1 // i n i c i a l i z a c i j a w e b s o c k e t s
Zaˇcelni MQTT klient za direktno komunikacijo z napravo
Na zaˇcelnem sistemu se je za upravljanje naprave uporabila ˇse JS knjiˇzica Eclipse Paho JavaScript Client [14], ki se neposredno poveˇze z MQTT posrednikom. Tako smo loˇcili upravljanje naprave in tok podatkov, ki poteka preko Django aplikacije in dosegli boljˇso zmogljivost in odzivnost celotnega sistema.
V naˇsi aplikaciji, ˇcakamo klike uporabnika in ko uporabnik izbere prametre ter klikne gumbZaˇcni, se sporoˇcilo z ukazi poˇslje aktivni napravi ter ta na podlagi le-teh priˇcne ali konˇca z zajemom.
Izdelava spletne aplikacije in sistema za zajem
Interaktivno posodabljanje grafov z uporabo AJAX zahtevkov
Tu smo uporabili ˇse en zelo pogost naˇcin posodabljanja vsebine strani. Pri klasiˇcnih zahtevkih se nam vedno nalaga celotna stran. To je velikokrat zamudno in uporabnikom neprijazno. V ta namen obstaja tehnika AJAX (ang. Asynchronous JavaScript and XML). Tu s pritiskom na gumb poˇsljemo zahtevek z JS funkcijo. Ta v odgovoru streˇznika dobi podatke, na podlagi katerih posodobi elemente na spletni strani. V naˇsi aplikaciji se to vidi pri prikazu meritev, saj se grafi z izbiro doloˇcene meritve posodabljajo dinamiˇcno, ne da bi se spletna stran osveˇzevala. Primer take uporabe v naˇsi aplikaciji je prikazan v naslednjem odseku iz kode.
1 // A J A X f u n k c i j a , ki se i z v e d e ob k l i k u na g u m b p r i k a z i
Izdelava spletne aplikacije in sistema za zajem
41 p o i n t D a t a 3 . p u s h ({ x : f r e q [ i ] , y : coh [ i ] }) ;
42 };
43 // p o s o d o b i t e v z g o r a j d e f i n i r a n i h g r a f o v
44 u p d a t e C a r t ( m y C h a r t 1 , p o i n t D a t a 1 )
45 u p d a t e C a r t ( m y C h a r t 2 , p o i n t D a t a 2 )
46 u p d a t e C a r t ( m y C h a r t 3 , p o i n t D a t a 3 )
47 })
48 49 };
Tudi pri zaˇcelnem sistemu aplikacije je ˇse veliko programske kode in HTML ter CSS predlog. Tudi te so dostopne v spletnem repozitoriju avtorja magistrskega dela Gre-gorja Obreze (Github: gregorobreza).
3.1.3.3 Uporaba aplikacije
Uporaba aplikacije je uporabniku prijazna in intuitivna. Pred vstopom na domaˇco stran aplikacija s pojavnim oknom pozove uporabnika k prijavi, kot to prikazuje slika 3.3.
Slika 3.3: Prijava v spletno aplikacijo