Sveučilište Jurja Dobrile u Puli
Odjel za ekonomiju i turizam
«Dr. Mijo Mirković»
INGRID HRGA
PRIMJER IZRADE PROTOTIPA WEB SJEDIŠTA
Završni rad
Pula, 2013.
Sveučilište Jurja Dobrile u Puli
Odjel za ekonomiju i turizam
«Dr. Mijo Mirković»
INGRID HRGA
PRIMJER IZRADE PROTOTIPA WEB SJEDIŠTA
Završni rad
JMBAG: 0067212898, izvanredni student
Studijski smjer: Poslovna informatika
Predmet: Elektroničko poslovanje
Mentor: izv.prof.dr.sc. Vanja Bevanda
Pula, veljača 2013.
Sadržaj
1. UVOD ..................................................................................................................... 4
2. WEB SJEDIŠTA, WEB APLIKACIJE .................................................................... 6
2.1. Definiranje web aplikacija................................................................................................ 6
2.2. Karakteristike web aplikacija .......................................................................................... 7
2.3. Kategorije web aplikacija prema fazama razvoja Weba .............................................. 9
2.3.1. Web 1.0 ...................................................................................................................... 10
2.3.2. Web 2.0 ...................................................................................................................... 10
2.3.3. Mobilni Web .............................................................................................................. 10
2.3.4. Semantički Web ......................................................................................................... 10
2.3. Arhitektura web aplikacija ............................................................................................ 11
2.5. Tehnologije....................................................................................................................... 12
2.5.1. HTTP .......................................................................................................................... 12
2.5.2. HTML......................................................................................................................... 13
2.5.3. CSS............................................................................................................................. 15
2.5.4. JavaScript ................................................................................................................... 16
2.5.5. AJAX.......................................................................................................................... 18
2.5.6. PHP............................................................................................................................. 20
2.5.7. Baze podataka ............................................................................................................ 21
2.5.7.1. MySQL................................................................................................................ 21
3. RAZVOJ WEB APLIKACIJA ............................................................................... 24
3.1. Planiranje i utvrđivanje zahtjeva .................................................................................. 25
3.2. Dizajn................................................................................................................................ 26
3.2.1. Upotrebljivost............................................................................................................. 26
3.2.2. Dizajn prezentacije ..................................................................................................... 27
3.2.2.1. Raspored elemenata............................................................................................. 27
3.2.2.2. Tipografija ........................................................................................................... 29
3.2.2.3. Boje ..................................................................................................................... 29
3.2.3. Dizajn navigacije........................................................................................................ 30
3.2.3.1. Kategorije navigacije........................................................................................... 30
3.2.3.2. Navigacijski mehanizmi...................................................................................... 31
3.2.4. Dizajn interakcije ....................................................................................................... 32
3.2.5. Modeliranje podataka ................................................................................................. 34
3.2.5.1. Konceptualno modeliranje .................................................................................. 34
3.2.5.2. Logičko modeliranje ........................................................................................... 35
3.2.5.3. Fizičko modeliranje............................................................................................. 36
3.3. Implementacija ................................................................................................................ 37
3.3.1. Implementacija prezentacijskog sloja ........................................................................ 37
3.3.2. Implementacija aplikacijskog sloja ............................................................................ 38
1
3.3.3. Implementacija podatkovnog sloja............................................................................. 38
3.4. Testiranje ......................................................................................................................... 38
3.4.1. Testiranje poveznica................................................................................................... 39
3.4.2. Testiranje kompatibilnosti.......................................................................................... 40
3.4.3. Testiranje upotrebljivosti............................................................................................ 40
3.4.4. Testiranje performansi................................................................................................ 40
3.4.5. Testiranje sigurnosti ................................................................................................... 41
3.5. Objavljivanje, održavanje i evolucija............................................................................ 41
3.5.1. Objavljivanje .............................................................................................................. 41
3.5.1.1. Odabir web poslužitelja i fizičkog smještaja web sjedišta .................................. 42
3.5.1.2. Registracija domene ............................................................................................ 42
3.5.2. Održavanje i evolucija................................................................................................ 43
4. UPRAVLJANJE PORTFELJEM .......................................................................... 44
4.1. Moderna portfolio teorija ............................................................................................... 44
4.2. Jednoindeksni model....................................................................................................... 46
4.3. Elton-Gruber metoda konstruiranja optimalnog portfelja......................................... 48
5. PROCES IZRADE PROTOTIPA WEB APLIKACIJE ZA UPRAVLJANJE
PORTFELJEM ......................................................................................................... 50
5.1. Planiranje i utvrđivanje zahtjeva .................................................................................. 50
5.1.1. Pozadina projekta ....................................................................................................... 50
5.1.2. Opis projekta .............................................................................................................. 50
5.1.3. Poslovni model........................................................................................................... 50
5.1.4. Pokazatelji uspjeha ..................................................................................................... 50
5.1.5. Ciljni korisnici............................................................................................................ 51
5.1.7. Zahtjevi....................................................................................................................... 51
5.1.8. Arhitektura ................................................................................................................. 53
5.2. Dizajn................................................................................................................................ 53
5.2.1. Konceptualni model podataka .................................................................................... 53
5.2.2. Wireframe modeli ...................................................................................................... 55
5.2.3. Relacijski model podataka ......................................................................................... 58
5.2.4. Grafički dizajn............................................................................................................ 62
5.2.4.1. Raspored elemenata............................................................................................. 62
5.2.4.2. Tipografija ........................................................................................................... 62
5.2.4.3. Paleta boja ........................................................................................................... 63
5.2.5. Navigacija................................................................................................................... 63
5.2.6. Interakcija................................................................................................................... 65
5.3. Implementacija ................................................................................................................ 67
5.3.1. Implementacija sučelja ............................................................................................... 67
5.3.2. Implementacija funkcionalnosti "izvršiti nalog"........................................................ 70
5.4.Testiranje .......................................................................................................................... 76
2
6. PRIMJERI KORIŠTENJA PROTOTIPA WEB APLIKACIJE ZA UPRAVLJANJE
PORTFELJEM ......................................................................................................... 78
6.1. Pregledavanje portfelja i otvaranje naloga................................................................... 78
6.2. Kreiranje novog portfelja ............................................................................................... 80
6.3. Izmjena portfelja ............................................................................................................. 81
6.4. Usporedba dionica ili portfelja....................................................................................... 84
6.5. Izračunavanje optimalnog portfelja .............................................................................. 85
6.6. Pregledavanje, izvršavanje ili opoziv naloga ................................................................ 88
6.7. Upravljanje računom...................................................................................................... 89
6.8. Pregledavanje dionica i podataka o trgovanju ............................................................. 89
7. ZAKLJUČAK........................................................................................................ 91
LITERATURA........................................................................................................... 92
POPIS SLIKA........................................................................................................... 94
3
1. Uvod
Razvoj Interneta i sa njime povezanih tehnologija iz temelja je promijenio način kako ljudi
rade, žive, komuniciraju, provode slobodno vrijeme. Otkad je 1991. stvoren1, naša ovisnost o
Webu i web aplikacijama kontinuirano raste. Zamišljen kao medij za razmjenu dokumenata i
lakšu komunikaciju znanstvenika u CERN-u2, Web svoj prvi procvat i početak
nezaustavljivog rasta doživljava sredinom 90-ih godina 20. stoljeća kada je zbog ubrzanog
razvoja i padanja cijena informatičke opreme ona postala dostupna širem krugu ljudi, a danas
je već nezamisliv bilo koji segment ljudskog djelovanja bez Interneta i onoga što Internet
omogućava3.
Cilj ovog rada sastoji se u prikazu procesa razvoja web sjedišta kroz njegove osnovne faze i to
najprije sa teorijskog aspekta a zatim kroz praktični primjer. Rad je koncipiran na način da se,
nakon uvoda, kroz tri poglavlja postavlja teorijska podloga koja se zatim kroz sljedeća dva
pogavlja konkretizira prikazom procesa izrade prototipa web sjedišta. Dok teorijski dio
uglavnom prikazuje opće principe primjenjive u razvoju bilo kojeg web sjedišta, za praktičan
dio odabrana je izrada web aplikacije za upravljanje portfeljem.
Drugo poglavlje započinje obrazlaganjem razlika između pojmova web sjediša i web
aplikacija, iza čega slijedi definiranje web aplikacija te navođenje njihovih ključnih
karakteristika. Budući da web aplikacije objedinjuju karakteristike informacijski orijentiranih
web sjedišta s jedne strane te tradicionalnih aplikacija s druge strane, to se i prikaz
karakteristika vrši putem njihove međusobne usporedbe. Osim poznavanja njihovih općih
karakteristika, za bolje razumijevanje web aplikacija potrebno je poznavati i tehnologije koje
se primjenjuju u njihovom razvoju. Stoga se u nastavku poglavlja daje njihov kratki pregled
koji je, s obzirom na njihovu brojnost i raznovrsnost, ipak ograničen samo na one doista
upotrijebljene u izradi prototipa.
1
Tim Berners-Lee je 6. kolovoza 1991. publicirao sustav za dijeljenje i diseminaciju znanstevnih podataka i
informacija koji je prozvao World Wide Web (skraćeno Web) (Rossi et al. 2008).
2 CERN (European Organization for Nuclear Research) jedan je od najvećih i najpriznatijih svjetskih
istraživačkih laboratorija koji se bavi funamentalnom fizikom – pitanjima od čega se svemir sastoji i kako
funkcionira. Nalazi se na francusko-švicarskoj granici zapadno od Ženeve.
3
Potrebno je razlikovati Internet i Web – Internet je globalna mreža koja povezuje računala i računalne mreže
dok je Web jedan od servisa Interneta koji omogućava razmjenu hipertekstualnih dokumenata.
4
Treće poglavlje daje opći prikaz procesa razvoja web aplikacija prema ključnim aktivnostima
koje obuhvaćaju: planiranje i utvrđivanje zahtjeva, dizajn, implementaciju, testiranje,
održavanje i evoluciju.
Budući da je namjena aplikacije upravljanje portfeljem, a što obuhvaća i sastavljanje
optimalnog portfelja, implementirana je
Elton-Gruber metoda konstruiranja optimalnog
portfelja temeljena na Sharpeovom jednoindeksnom modelu. Metoda je odabrana prvenstveno
zbog jednostavnosti implementacije budući da njezina primjena ne zahtijeva korištenje
dodataka u vidu solvera ili sličnog softvera. No, s druge strane uključuje određene
pretpostavke koje ju čine neprikladnom za korištenje u stvarnim uvjetima (poput pretpostavke
o beskonačnoj djeljivosti dionice, mogućnosti kupnje ili prodaje bilo koje količine dionice u
bilo kojem trenutku te zanemarivanja transakcijskih troškova). Sama metoda
i osnove
upravljanja portfeljem ukratko su prikazani u četvrtom poglavlju.
Peto poglavlje prikazuje proces izrade prototipa web aplikacije. Cilj prikaza nije
dokumentiranje gotovog rješenja već prikaz postepenih koraka od ideje do realizacije što
omogućuje da se ujedno pokaže kako zapravo često postoji odstupanje teorije od prakse.
Šesto poglavlje, u konačnici, prikazuje način korištenja implementiranih funkcionalnosti
aplikacije.
Pri izradi rada korišteni su domaći i strani izvori podataka u vidu knjiga i resursa dostupnih na
Internetu (priručnici, članci te podaci o povijesnim cijenama dionica). Od znanstevnih metoda
korištene su metoda analize, metoda sinteze, metoda deskripcije i metoda apstrakcije.
5
2. Web sjedišta, web aplikacije
Web sjedište može se definirati kao skup međusobno logički povezanih web stranica (Kappel
et al. 2006). No, ovakva je definicija preopćenita i ne govori o kompleksnosti koja se skriva
iza modernih web sjedišta. Izuzetno brzo širenje broja korisnika Interneta4, povećanje
brojnosti uređaja kojima se Internetu pristupa (osim PC-a danas su tu i smartphone uređaji,
tablet računala, igrače konzole...), te sve izraženijim zahtjevima korisnika za što
jednostavnijim, sigurnijim i prilagodljivijim web sjedištima, doveli su do velikih promjena
kako u sadržajima koji se putem Interneta isporučuju tako i u pristupu njihovom razvoju koji
je ubrzo postao kompleksan i prepun izazova.
U svojim je počecima Web bio poiman isključivo kao informacijski medij s fokusom na
samim dokumentima (Kappel et al. 2006). No, razvoj tehnologija i povećanje propusnosti
mreža omogućili su najprije dodavanje multimedije, a kasnije i sve veću interaktivnost koja je
sad u središte postavila korisnika, transformirajući ga od pasivnog konzumenta u aktivnog
kreatora sadržaja. S obzirom da su web sjedišta koja ne uključuju neki od oblika
interaktivnosti danas postala prava rijetkost, sve se više govori o web aplikacijama koje
korisnicima omogućavaju obavljanje određenih transakcija. Stoga se može reći da je iz
informacijskog Web evoluirao u aplikacijski medij (Kappel et al. 2006).
2.1. Definiranje web aplikacija
Web aplikacija predstavlja softver baziran na tehnologijama i standardima World Wide Web
Consortium-a (W3C)5 koji putem korisničkog sučelja (web preglednika) pruža resurse i
servise specifične za Web (Kappel et al. 2006). Iz definicije proizlazi da web aplikaciju čine:
•
softver
•
mreža (Internet ili intranet)
•
tehnologije (HTTP, HTML, JavaScript, PHP,...)
•
web preglednik
No, ono što je zapravo ključno za web aplikacije jest interakcija sa korisnikom. Statične web
stranice ne smatraju se web aplikacijama.
4
Broj korisnika Interneta povećao se za 566.4% u razdoblju između 2000. i 2012. godine.
World Wide Web Consortium (W3C) je najveća međunarodna organizacija koja se bavi razvojem standarda za
Web a među koje spadaju preporuke za (X)HTML, CSS, DOM, SVG i brojne druge.
5
6
2.2. Karakteristike web aplikacija
Budući da su web aplikacije takve aplikacije čija se
funkcionalnost procesira na web
poslužitelju, a zatim putem mreže isporučuje korisniku, one objedinjuju karakteristike
informacijski orijentiranih web sjedišta s jedne strane i tradicionalnih aplikacija s druge
strane. No, također posjeduju i određene karakteristike koje ih čine jedinstvenima.
Usporedba sa informacijskim web sjedištima može se izvršiti s obzirom na (Zambonini 2011):
a) ciljeve korisnika
b) zahtjeve
c) dizajn
d) sučelje.
a) Dok je kod informacijski orijentiranih web sjedišta cilj korisnika pronalaženje informacija,
kod web aplikacija to je obavljanje određenog zadatka.
b) Prilikom utvrđivanja zahtjeva web aplikacija naglasak se stavlja na utvrđivanje
funkcionalnih zahtjeva6, dok se kod informacijskih web sjedišta naglasak stavlja na
utvrđivanju zahtjeva vezanih uz sam sadržaj.
c) Struktura na strani funkcionalnosti definira se primarno dizajnom interakcije koji se odnosi
na uspostavljanje dijaloga između korisnika i aplikacije. S informacijskog gledišta, strukutura
je određena arhitekturom informacija odnosno usklađivanjem elemenata kako bi se korisniku
olakšalo razumijevanje sadržaja.
d) Dizajn sučelja web aplikacija sastoji se od uspostavljanja odnosa među elementima kako
bi se omogućila interakcija korisnika sa funkcionalnošću sustava, dok je kod informacijskih
web sjedišta naglasak na navigaciji odnosno skupu elemenata koji omogućavaju korisniku
kretanje kroz informacije.
S druge strane, karakteristike koje razdvajaju web aplikacije od tradicionalnog softvera mogu
se grupirati s obzirom na (Kappel et al. 2006):
a) proizvod
6
O zahtjevima će još biti riječi u poglavlju 3.1.
7
b) upotrebu
c) razvoj
a) proizvod
•
sadržaj se isporučuje u različitim formatima, često se kreira i mijenja dinamički te
postoje visoki zahtjevi za njegovom kvalitetom (uobičajena je krilatica: "Sadržaj je
kralj!")
•
sučelje web aplikacija zasnovano je na hipertekstualnim dokumentima7 koje
karakterizira nelinearnost - korisnici se mogu slobodno kretati kroz informacije što
predstavlja izazov prilikom njihovog strukturiranja
•
estetika je izrazito bitna te je podložna trendovima
•
web aplikacije moraju biti samorazumljive, njihovo korištenje ne treba iziskivati
dodatnu dokumentaciju
b) upotreba
•
za razliku od zatvorenih intraneta ili desktop aplikacija, Internet omogućava simultani
pristup informacijama i servisima mnogo većem broju nepoznatih korisnika koji se
znatno razlikuju s obzirom na kulturu iz koje potječu (društveni kontekst), uređaje
kojima pristupaju (tehnički kontekst), lokaciju s koje pristupaju (prirodni kontekst).
Premda je ove faktore nemoguće unaprijed predvidjeti niti ih je moguće kontrolirati,
izrazito je bitno kontinuirano prilagođavati aplikacije različitm situacijama njihove
uporabe odnosno njihovom kontekstu.
c) razvoj
•
razvoj web aplikacija zahtijeva raznovrsna znanja te se odvija u multidisciplinarnim
timovima koji dijelove aplikacija razvijaju paralelno
•
zbog kompetitivnih pritisaka i čestih izmjena zahtjeva životni ciklus8 web aplikacija
kraći je od onog tradicionalnog softvera
•
prilikom razvoja nemoguće je u potpunosti slijediti rigidni plan razvoja te je
fleskibilnost prijeko potrebna
7
Osnovne elemente hipertekstualnih dokumenata čine čvorovi (eng. node), poveznice (eng. link) i sidra (eng.
anchor). Čvor je jedinica informacije koja se može jedinstveno identificirati. Na Webu to može biti HTML
dokument kojem se može pristupiti putem URL-a (Uniform Resource Locator). Poveznica je put od jednog
čvora do drugog. Sidro je područje unutar sadržaja čvora koji je izvor ili odredište poveznice (Kappel et al.
2006).
8
Životni ciklus softvera predstavlja faze kroz koje prolazi softver tokom svog života: od začetka, preko razvoja,
upotrebe, održavanja pa do povlačenja iz upotrebe.
8
•
web aplikacije zahtijevaju distribuiranu, višeslojnu arhitekturu te ovise o dvije vanjske
komponente – poslužitelju i web pregledniku. Dok je poslužitelja obično moguće
konfigurirati prema zahtjevima programera, ne postoji način da se utječe na korisnike
preglednika i njihove preference, a dodatne komplikacije stvaraju dodaci u
preglednicima (eng. plug-in) koji proširuju njihovu funkcionalnost, te različite verzije
preglednika, svaka sa svojom implementacijom tehnologija i standarda.
•
tehnologiije na kojima se baziraju web aplikacije često su nove i nezrele.
Slika 1. Kompleksnost web sustava
(izvor: Rossi et al. 2008)
Slika 1. prikazuje tipično okruženje web sustava sa brojnim komponentama koje ga
sačinjavaju.
2.3. Kategorije web aplikacija prema fazama razvoja Weba
Svaku fazu razvoja Weba karakterizirala je pojava određene kategorije web aplikacije koje se
međusobno razlikuju s obzirom na upotrijebljene tehnologije i razinu interaktivnosti koju
omogućavaju.
9
2.3.1. Web 1.0
U počecima komercijalizacije Weba9 web sjedišta su bila primarno kolekcije statičnih web
stranica koje su se ograničavale na pružanje informacija o proizvodima i uslugama. U ovoj
fazi, nazvanoj "plitki Web" (eng. Shallow Web) (Rossi et al. 2008), još nema govora o web
aplikacijama. Nešto kasnije Web je postao dinamički. Uvođenje obrazaca i interaktivnih
kontrola omogućilo je dinamičko kreiranje stranica na temelju sadržaja pohranjenih u bazama
podataka. No, premda dinamički, Web je još uvijek karakterizirala ograničena interaktivnost.
U ovoj fazi, nazvanoj "duboki Web" (eng. Deep Web) (Rossi et al. 2008), pojavile su se
interaktivne web aplikacije (poput portala sa vijestima) te transakcijske web aplikacije (poput
e-trgovina).
2.3.2. Web 2.0
Sve intenzivnija primjena tehnologija poput AJAX –a10 i web servisa11, a koja je započela oko
2005. godine, omogućila je visoku interaktivnost te nove oblike komunikacije i suradnje
među korisnicima. Ovo razdoblje karakterizira pojava društvenih mreža (Facebook, Twitter...)
i kolaborativnih web aplikacija (platforme za e-učenje, Wiki) koje omogućavaju korisnicima
suradnju na izradi sadržaja na nestrukturiran način, intenzivnu komunikaciju i brzu razmjenu
informacija, te web baziranih aplikacija (RIA - Rich Internet Applications) koje se pokreću u
web pregledniku, ne traže instalaciju softvera, ali nude mogućnosti i funkcionalnost desktop
aplikacija (npr. Google mail).
2.3.3. Mobilni Web
Napredak u mobilnim komunikacijama i bežične mreže te pojava novih uređaja ( smartphone
uređaji, tablet računala,...) otvorili su put sveprisutnim (eng. ubiquitous) aplikacijama koje
nude nove mogućnosti poput pružanja servisa ovisno o lokaciji ili kontekstu.
2.3.4. Semantički Web
Daljnji razvoj usmjeren je prema semantičkom Webu koji za cilj ima prezentiranje
informacija u obliku koji neće biti razumljiv samo ljudima već i računalima a što bi trebalo
pridonijeti lakšem upravljanju znanjem na Webu.
9
Web je stavljen je na raspolaganje javnosti 1993.
AJAX (Asynchronous JavaScript and XML) obuhvaća skup tehnologija o kojima će biti riječi u poglavlju
2.5.5.
11
Web servis – softverska komponenta koja podržava interoperabilnu interakciju između računala preko mreže.
10
10
2.3. Arhitektura web aplikacija
Kvaliteta web aplikacija znatno ovisi o odabranoj arhitekturi. Loše performanse, otežano
održavanje i otežana proširivost najčešće su uzrokovani lošom arhitekturom. Premda ne
postoji jedinstvena definicija arhitekture, može se reći da arhitektura opisuje strukturu –
opisuje statične i dinamične aspekte sustava te omogućava njegovo razumijevanje (Rossi et al.
2008). Uobičajeno je opisivanje arhitekture web aplikacija s aspekta logičkih slojeva (eng.
layer) pri čemu se razdvajanje vrši s obzirom na ulogu pojedinog sloja u sustavu. Takvo
strukturiranje olakšava skalabilnost sustava odnosno njegovo proširivanje dodavanjem novih
komponenata u skladu sa rastućim potrebama. Najčešće se web aplikacije dijele na tri sloja i
tad se govori o troslojnoj arhitekturi koju čine:
•
prezentacijski sloj – zadužen za prikaz rezultata zahtjeva u odgovarajućem obliku
•
poslovni sloj – sadrži poslovnu logiku aplikacije
•
podatkovni sloj – zadužen za pružanje pristupa podacima.
Logički slojevi mogu se nalaziti na istom ili zasebnom fizičkom sloju (računalu).
Slika 2. Višeslojna arhitektura
(izvor: Kappel et al. 2006)
Slika 2. prikazuje arhitekturu jedne kompleksne aplikacije kojoj je poslovni sloj podijeljen na
dodatne slojeve te predstavlja primjer višeslojne arhitekture (eng. n-layer architecture).
11
2.5. Tehnologije
2.5.1. HTTP
HTTP (HyperText Transfer Protocol) je temeljni protokol Weba koji omogućava dohvaćanje
resursa na udaljenim računalima prema klijent-poslužitelj modelu pri čemu klijent i poslužitelj
komuniciraju razmjenom HTTP poruka (slika 3.). Klijent (npr. web preglednik)
šalje poslužitelju poruku zahtjeva kojom traži određeni resurs. Poslužitelj odgovara porukom
odgovora koja, ako je pronađen, sadrži i zahtijevani resurs. Po ispunjenju zahtjeva klijenta,
poslužitelj prekida komunikaciju.
Slika 3. Razmjena HTTP poruka
(izvor: Casteleyn et al. 2009)
Primjer zaglavlja HTTP poruke zahtjeva:
GET /prima-invest/sc/portfelji.php HTTP/1.1
User-Agent: Opera/9.80 (Windows NT 6.1; WOW64; U; en) Presto/2.10.289
Version/12.02
Host: localhost
Accept-Language: en,hr-HR;q=0.9,hr;q=0.8
Accept-Encoding: gzip, deflate
Referer: http://localhost/prima-invest/index.php
Connection: Keep-Alive
Accept: */*
X-Requested-With: XMLHttpRequest
Prva linija sadrži redak zahjeva sa podacima o metodi HTTP transfera (GET12), nazivu samog
resursa i putanji do njega (/prima-invest/sc/portfelji.php) te verziji korištenog protokola
(HTTP/1.1).Retci koji slijede predstavljaju zaglavlje poruke te sadrže podatke o klijentskoj
aplikaciji (User-Agent) koja je uputila zahtjev i dodatne podatke o zahtjevu (poput
preferencija u pogledu jezika (Accept-Language) i formata dokumenta (Accept) odgovora).
12
GET metoda uobičajeno se koristi za dohvaćanje podataka, dok se za slanje podataka na obradu, npr. putem
obrazaca, koristi POST metoda. Moguće je slati i manje količine podataka GET metodom, no tad su vidljivi u
nastavku adrese iza znaka upitnika. Npr. http://www.prima-invest.com/sc/portfelji.php?id=1.
Ostale metode su: HEAD, PUT, DELETE.
12
Primjer HTTP poruke odgovora:
HTTP/1.1 200 OK
Date: Fri, 23 Nov 2012 18:49:23 GMT
Server: Apache/2.2.21 (Win32) PHP/5.2.17
X-Powered-By: PHP/5.2.17
Keep-Alive: timeout=5, max=95
Connection: Keep-Alive
Content-Type: application/json; charset=utf-8
{"data":[{"id_portfelj":"336","naziv":"temp_OPT_1353256683","opis":"temp",
"datum_start":"2011-07-01","datum_izmjena":"2011-0701","broj_dionica":"0",
....
Prva linija poruke odgovora sadrži statusni redak koji uključuje podatke o verziji korištenog
protokola (HTTP/1.1) te statusni kod i frazu odgovora 13 (200 OK). Nakon toge slijede zaglavlje
i tijelo poruke unutar kojega se nalazi zahtijevani resurs (u primjeru prikazan u JSON14
formatu).
2.5.2. HTML
HTML (Hypertext Markup Language) je jezik za opisivanje strukture hipertekstualnih
dokumenata koji je od svog nastanka 1989. godine prošao kroz nekoliko verzija. Prva
formalna specifikacija izdana je 1992. godine, dok se verzija 4.01 iz 1999. godine, kao glavni
jezik Weba, zadržala više od desetljeća (Sikos 2011). 2000. godine predstavljena je prva
specifikacija XHTML-a kao reformulacije HTML-a u XML-u15 umjesto SGML-u16 uvodeći
time određena stroža pravila poput zahtjeva za dobro oblikovanim dokumentima (eng. wellformedness)17 .
13
Neki najčešći statusni kodovi i fraze:
200 OK - traženi resurs je pronađen
301 moved permanently – resurs je trajno premješten
404 not found – resurs nije pronađen
500 internal server error – greška poslužitelja.
14
JSON (JavaScript Object Notation) je format za razmjenu podataka kod kojega se objekti navode u vitičastim
zagradama i sastoje se od parova ključ - vrijednost razdvojenih zarezom npr. {"ime": "Ana", "prezime":"Anić"}.
Format je zbog svoje jednostavnosti u širokoj upotrebi pogotovo sa AJAX tehnologijama.
15
XML (Extensible Markup Language) – je metajezik napisan u SGML-u koji, za razliku od HTML-a, nema
predefinirane elemente. Stvoren je s ciljem jednostavne izrade i razmjene dokumenata putem Interneta neovisno
o korištenim tehnologijama.
16
SGML (Standard Generalized Markup Language) je meta jezik za opisivanje jezika za označavanje (eng.
markup language). Npr. HTML je jezik za označavanje napisan u SGML-u.
17
Kako bi se uklonili problemi prilikom interpretacije uzrokovani pretjeranom tolerantnošću HTML-a na greške,
XHTML postavlja zahtjev za dobro oblikovanim dokumentima (eng. well-formedness) koji se odnosi na opća
pravila sintakse poput:
• svaki otvoreni tag mora biti zatvoren (npr. <p> i </p>)
• prazni elementi (bez završnog taga) moraju također biti zatvoreni na odgovrajući način (npr. <br />)
• umetnuti tagovi se ne smiju preklapati (pravilno: <div><p>Nekakav tekst</p></div>, pogrešno:
<div><p>Nekakav tekst</div></p>) (Sikos 2011).
13
HTML jezik sastoji se od tagova kojima se označavaju dijelovi sadržaja dokumenta poput
naslova, paragrafa, tablice i sl. Većina18 html elemenata sastoji se od početnog i završnog
taga unutar zagrada (npr. tagovi <p> </p> označavaju paragraf) koji dodatno mogu sadržavati
atribute u obliku atribut="vrijednost" ( npr. <p id="prvi"></p> znači da paragraf ima atribut
id vrijednosti "prvi"19).
Osnovne elemente web stranice čine:
•
doctype deklaracija
•
html
•
title
•
head
•
body
kojima se definira osnovna strutrura HTML dokumenta poput:
<!DOCTYPE html>
<html>
<head>
<title>Naslov stranice</title>
</head>
<body>
<p>Sadržaj stranice</p>
</body>
</html>
Slika 4. prikazuje rezultat gornjeg primjera u web pregledniku.
Slika 4. Rezultat HTML primjera u web pregledniku
(izvor: izradila autorica)
18
Neki elementi imaju samo početni tag kao npr. <br /> element koji označava prijelaz u novi red (eng. break).
Na svakoj stranici može postojati samo jedan elemet određene vrijednosti id atributa stoga on omogućava
jednoznačnu identifikaciju elemenata na stranici.
19
14
Doctype (Document Type Definition) deklaracija mora biti prvi element stranice. Govori web
pregledniku u kojoj je verziji HTML-a pisana stranica a preglednik na temelju toga odlučuje
kako će prikazati stranicu. Verzija HTML 5 koristi deklaraciju iz primjera.
Tagovi <html></html> govore web pregledniku da se radi o html dokumentu. Sav se sadržaj
dokumenta, osim doctype deklaracije, mora nalaziti unutar ovih tagova.
Unutar html elementa dokument se dijeli na 2 dijela: "zaglavlje" i "tijelo" (head i body).
Unutar head elementa navode se podaci o stranici koji se ne prikazuju na samoj stranici.
Npr. title element (<title></title>), kojim se određuje naslov stranice, ne prikazuje se na
samoj stranici već na dijelu preglednika predviđenom za naslov (eng. titlebar). Unutar body
elementa smješta se sadržaj stranice koji će biti prikazan. U primjeru je to samo jedan element
<p> koji označava rečenicu "Sadržaj stranice" kao paragraf.
2.5.3. CSS
CSS (Cascading Style Sheets) je jezik za opisivanje prezentacije web stranica: tipografije,
boja i pozadina, te rasporeda elemenata na stranici. Razdvajanje strukture dokumenta
(definirane npr. HTML-om) od njegove prezentacije (definirane CSS-om) omogućava lakše
održavanje stranica, dijeljenje stilova među stranicama te prilagodbu stranica različitim
okruženjima.
Prva specifikacija CSS-a Level 1 izdana je 1996. kao preporuka W3C-a. Tom su verzijom
uvedeni stilovi za tipografiju, boje, tablice, poravnanje, margine, obrube i pozicioniranje.
Specifikacija Level 2 proširena je novim mogućnostima, a njena revizija 2.1 već je dugo
glavni izbor za stiliziranje web dokumenata. Premda je razvoj CSS3 (CSS Level 3) započeo
2005., web preglednici još uvijek nemaju punu podršku za brojne novine koje donosi.
Osnovne elemente CSS-a čine pravila koja se sastoje od:
•
selektora - određuju na koji će se element primijeniti određeni stil,
•
deklaracije - navode se unutar vitičastih zagrada a sastoje od svojstava i njihovih
vrijednosti odvojenih dvotočkom.
Primjer CSS pravila:
15
body {
background-color: black;
color: white;
}
U gornjem primjeru selektor je body što znači da će se stil primijeniti na čitavo "tijelo"
dokumenta, a unutar vitičastih zagrada nalazi se
deklaracija stila koja određuje da će
pozadina (background-color) biti crna, a boja teksta (color) bijela.
CSS pravila mogu se direktno umetati u HTML kod (što nije preporučljivo) ili se mogu
nalaziti u zasebnoj datoteci koja se zatim uključuje u HTML dokument referenciranjem
unutar <head> taga (što predstavlja preporučljiv način korištenja budući da doprinosi
razdvajanju strukture od prezentacije).
2.5.4. JavaScript
JavaScript (u daljnjem tekstu JS) je objektno-orijentirani skriptni jezik za klijentsko
programiranje (eng. client-side). Kod pisan u JS-u interpretira se i
izvršava u web
pregledniku nakon učitavanja stranice ili kao reakcija na događaj potaknut od strane
korisnika. JS omogućava dinamički HTML (poput dinamičke izmjene prezentacije web
stranica) ili izvršavanje dijelova poslovne logike na strani klijenta (poput validacije inputa) pri
čemu JS predstvalja aktivni dio dok HTML predstavlja statični dio koji je predmetom
modificiranja od strane skripne logike.
JS kod može se umetati u HTML dokumente unutar <script> taga ili se može nalaziti u
zasebnoj datoteci koja se uključuje referenciranjem unutar <head> taga.
Primjer JS funkcije:
<script>
function mijenjajPrikaz(id) {
var element = document.getElementById(id);
var atribut = "";
if (element.currentStyle){
//ako je Internet Explorer
atribut = element.currentStyle['display'];
}
else if (window.getComputedStyle) { //ostali preglednici
atribut = window.getComputedStyle(element, null).display;
}
if (atribut == "none") {
element.style.display = "block";
}
else {
16
element.style.display = "none";
}
}
</script>
U HTML-u se dodaje:
<div id="div1"><p>Sadržaj</p></div>
<input type="button" value="Promijeni" onclick=" mijenjajPrikaz('div1');"/>
U primjeru je dana JS funkcija koja prikazuje ili skriva određeni element na stranici
postavljanjem vrijednosti css svojstva display. Elemet koji se želi prikazati/sakriti ima
specificiran id atribut koji se proslijeđuje funkciji. Funkcija se poziva klikom na gumb
(onclick="
mijenjajPrikaz ('div1');").
Premda JS podržava većina web preglednika, postoje određene razlike u njegovoj
implementaciji tako da je uobičajen način za postizanje ujednačenog ponašanja u različitim
verzijama preglednika (eng. cross-browser compatibility) korištenje JavaScript biblioteka
poput jQuery. jQuery biblioteka pruža sloj apstrakcije koji uklanja razlike u implementaciji
različitih web preglednika te time ujednačava njihovo ponašanje i pojednostavljuje pisanje
koda.
U gornjem primjeru vidljivo je da se dio koda odnosi na slučaj ako je web preglednik u kojem
se prikazuje stranica Internet Explorer, a dio ako je to neki drugi preglednik. U donjem
primjeru dana je funkcija iste namjene, ali uz upotrebu jQuery bibilioteke.
jQuery;
<script>
$(".gumb").click(function (e) {
var id = $(this).attr("name");
var atribut = $("#" + id).css('display');
if (atribut == "none") {
$("#" + id).css('display', 'block');
} else {
$("#" + id).css('display', 'none');
}
});
</script>
U HTML-u se dodaje:
17
<div id="div1"><p>Sadržaj</p></div>
<input type="button" class="gumb" name="div1" value="Promijeni" />
Gumbu je dodan class atribut koji omogućava da se za više elemenata na stranici definira
jednak izgled ili ponašanje (u ovom slučaju je to mijenjanje prikaza), te mu je dodan name
atribut vrijednosti jednake kao i id atribut elementa kojeg želimo mijenjati. Uklonjen je poziv
funkcije iz HTML koda te je on sad povezan sa klikom na bilo koji gumb klase "gumb".
Ovakvo razdvajanje HTML-a i ostalog koda olakšava održavanje stranica i njihove izmjene.
Budući da je gornji primjer prilično jednostavan, razlika nije toliko izražena, no kod složenijih
situacija upotreba jQuery biblioteke znatno smanjuje potrebne linije koda.
2.5.5. AJAX
Naziv AJAX (Asynchronous JavaScript and XML) nastao je 2005. i predstavlja skup
tehnologija koje omogućavaju asinhronu komunikaciju odnosno parcijalno učitavanje i
manipulaciju sadržajem web stranica bez ponovnog učitavanja čitave stranice.
AJAX čine:
•
na prezentacijskom sloju: HTML ili XHTML, CSS i JavaScript
•
razmjena podataka vrši se u formatu: XML, JSON, HTML ili kao običan tekst
•
za asinhronu komunikaciju zadužen je JavaScritp XMLHttpRequest objekt.
Slika 5. Tradicionalni web model
(izvor: MacIntyre, Danchilla & Gogala 2011)
U tradicionalnom web modelu (slika 5.) web preglednik šalje HTTP zahtjev poslužitelju te od
njega prima odgovor. Korisnik za vrijeme čekanja na odgovor ne može na stranici obavljati
nikakav koristan rad, a po pristizanju odgovora, čitava se stranica ponovno učitava, neovisno
o veličini promjene na njoj.
18
Slika 6. Ajax model
(izvor: MacIntyre, Danchilla & Gogala 2011)
U Ajax modelu (slika 6.) kao posrednik između klijenta i poslužitelja javlja se AJAX engine
(XMLHttpRequest objekt). Klijent sad šalje zahtjeve AJAX engineu koji zatim ili samo vrši
izmjene na prezentacijskom sloju ili šalje asinhroni zahtjev poslužitelju koji vraća odgovor
AJAX engineu. Korisnik, za vrijeme čekanja na odgovor, može nastaviti koristiti aplikaciju.
Premda AJAX omogućava kreiranje visokointeraktivnih i responzivnih web aplikacija, ima i
određene nedostatke:
•
nemogućnost ili neujednačen rezultat korištenja gumba web preglednika za povratak
na prethodnu stranicu ili postavljanje stranice u zabilješke (eng. bookmark)
•
pretraživači ne mogu indeksirati dijelove AJAX aplikacija
•
korisnik može isključiti podršku za JavaScript te u tom slučaju aplikacija prestaje biti
funkcionalna.
Kao i u slučaju JavaScripta, jQuery bibiloteka olakšava primjenu AJAX-a uklanjajući
kompleksnost XMLHttpRequest objekta.
AJAX (jQuery)
$(".portfelj").click(function (e) {
$("#performanse").load("portfelj_performanse.php");
});
19
U HTML-u se dodaje:
<input type="button" class="portfelj" value="Prikaži performanse" />
<div id="performanse"></div>
U najjednostavnijem obliku .load() funkcija omogućava injektiranje dodatnog sadržaja u
stranicu bez da se čitava stranica ponovno učita. U primjeru se klikom na gumb klase
portfelj
poziva php skripta portfelj_performanse.php čiji se rezultat učitava u prazan <div>
element sa vrijednošću id atributa performanse.
2.5.6. PHP
PHP (PHP: Hypertext Preprocessor) jedan je od najpopularnijih server-side skriptnih jezika
koji je popularnost stekao zbog toga što je besplatan, otvorenog koda, sa velikom podrškom
zajednice i dostupan za sve važnije platforme i web poslužitelje. Kreiran je 1995. godine s
ciljem izrade dinamičkih web stranica a trenutno je u verziji 5.4. PHP se razlikuje od clientside skriptnih jezika (poput JavaScripta) po tome što se kod izvršava na serveru a korisniku se
šalje samo rezultat njegovog izvršavanja.
Uobičajena primjena server-side jezika, poput PHP-a, je dinamičko kreiranje stranica na
temelju podataka smještenima u bazama podataka. Korisnik na web stranici ispunjava obrazac
čijim se slanjem poziva PHP skripta te se na temelju podataka iz obrasca vrši upit na bazi i
generira rezultat.
PHP kod može se direktno umetati u HTML dokumente između tagova <?php i ?>20 ili se
nalaziti u zasebnim datotekama sa uobičajenom ekstenzijom .php.
<!DOCTYPE html>
<html>
<head>
<title>Naslov stranice</title>
</head>
<body>
<p><?php echo "Sadržaj stranice."; ?><p>
<p>"Sadržaj stranice."<p>
</body>
</html>
20
Moguće je koristiti i skraćenu verziju php oznaka <? ?> no to nije preporučljivo jer takve oznake koriste
XML dokumenti.
20
U gornjem primjeru php kod je ubačen unutar HTML-a između prvog para <p> tagova i daje
jednak rezultat kao i drugi par <p> tagova : ispisuje se rečenica "Sadržaj stranice".
2.5.7. Baze podataka
Baze podataka omogućavaju skladištenje podataka na strukturirani način te su neizostavna
komponenta većine web aplikacija. Relacijske baze podataka, koje pohranjuju podatke u
obliku relacija (stupaca i redaka) i koriste SQL21 jezik za manipulaciju podacima,
predstavljaju već niz godina najpopularnije rješenje za skladištenje podataka. Kao jedan od
najčešćih odabira među sustavima za upravljanje bazom podataka22 (SUBP) u kombinaciji sa
PHP-om ističe se MySQL.
2.5.7.1. MySQL
MySQL je SUBP otvorenog koda čija je prva verzija izdana 1995. godine, a trenutno se nalazi
u verziji 5.5. Posebnost MySQL-a je arhitektura strojeva za skladištenje (eng. storage engine)
koja razdvaja procesiranje upita i ostalih poslužiteljskih poslova od skladištenja i dohvaćanja
podataka. Takvo rješenje omogućava, osim odabira načina skladištenja podataka, također i
prilagodbu performansi te odabir ostalih mogućnosti i karakteristika (Schwartz et al. 2008).
Slika 7. prikazuje logičku arhitekturu MySQL-a. Gornji sloj sadrži servise uobičajene za
većinu mrežnih alata i poslužitelja (poput upravljanja konekcijom, autentikacijom i sl).
21
SQL (Structured Query Language) - jezik za rad sa relacijskom bazom podataka. Sadrži podjezike:
DDL (Data Definition Language) - jezik za definiranje strukture baze (naredbe CREATE, ALTER, DROP…)
DML (Data Manipulation Language) – jezik za upravljanje podacima (naredbe SELECT, INSERT, UPDATE,
DELETE…)
DCL (Data Control Language) – jezik za kontrolu pristupa podacima (naredbe GRANT, REVOKE)
TCL (Transaction Control Language) – jezik za upravaljanje transakcijama (naredbe COMMIT, SAVEPOINT,
ROLLBACK..)
22
Sustav za upravljanje bazom podataka (SUBP) - programska podrška koja omogućava definiranje baze
podataka (eng. Database Definition) i rad s podacima (eng. Data Management). Osim toga omogućava kontrolu
istovremenog pristupa podacima, zaštitu od neovlaštenog korištenja, izradu sigurnosnih kopija, obnovu u slučaju
"pada" itd.
21
Slika 7. Arhitektura MySQL SUBP-a
(izvor: Schwartz et al. 2008)
Srednji sloj predstavlja "mozak" MySQL-a. U njemu je smješten kod za procesiranje upita,
njihovu analizu, optimizaciju, ugrađene funkcije itd. Sve funkcionalnosti koje su na
raspolaganju strojevima za skladištenje smještene su u srednjem sloju (npr. uskladištene
procedure23, okidači24, pogledi25). U trećem sloju smješteni su strojevi za skladištenje koji su
zaduženi za skladištenje i dohvaćanje podataka. MySQL podržava 10 različith26 stojeva za
skladištenje, a odabir ovisi o namjeni te zahtijevanim karakteristikama i performansama.
Premda je standardni stroj za skladištenje MyISAM, InnoDB predstavlja optimalni odabir za
23
Uskladištene procedure (eng. Stored Procedures) – vrsta uskladištenog koda koji koristi proširenje SQL
jezika proceduralnim strukturama poput petlji, grananja i sl.
24
Okidač (eng. Trigger) – je vrsta pohranjenog koda koji se automatski pokreće prilikom izvršavanja DDL ili
DML naredbe ili nekog događaja vezanog za bazu.
25
Pogled (eng. View) - pohranjeni upit koji kao rezultat daje virtualnu tablicu. Omogućava jednostavnije
korištenje rezultata kompleksnih upita ili prilagodbu rezultata različitim korisnicima.
26 Podržani strojevi za skladištenje su: MyISAM, InnoDB, Memory,
Merge, Archive, Federated,
NDBCLUSTER, CSV, Blackhole, Example.
22
većinu situacija budući da podržava transakcije27, "hot" online backup28 , crash-recovery29,
zaključavanje na razini retka30 te vanjske ključeve31 (Schwartz et al. 2008).
MySQL od verzije 5.0 omogućava pohranjivanje koda u bazi nazvanog uskladištene rutine
(eng. stored routines) koji može biti u obliku procedura (eng. stored procedures), funkcija
(eng. stored functions), okidača (eng. triggers) ili periodičnih poslova – događaja (eng.
events). Svi ovi tipovi pohranjenog koda koriste proširenje SQL-a proceduralnim
konstruktima poput petlji ili grananja a osnovnu razliku među njima čini to što procedure i
funkcije mogu primati argumente i vraćati rezultate dok okidači i događaji to ne mogu
(Schwartz et al. 2008).
Postoje podijeljena mišljenja o njihovoj korisnosti i upotrebi, no općenito se kao prednosti
korištenja pohranjenog koda mogu navesti (Schwartz et al. 2008):
•
smanjuje se latencija i potrebna propusnost mreže budući da se kod izvršava na
mjestu gdje su smješteni podaci
•
omogućava ponovnu iskoristivost koda te centralizaciju poslovnih pravila čime se
osnažuje konzistentno ponašanje sustava
•
može doprinijeti većoj sigurnosti time što se korisniku može dopustiti izvršavanje
procedure bez da mu se dopusti pravo pristupa tablicama nad kojima se unutar
procedure vrše izmjene.
Neke negativnosti pohranjenog koda (Schwartz et al. 2008):
•
jezik je spor i primitivan u odnosu na (moderne) objektno orijentirane jezike
•
smještanje koda u bazu povećava opterećenje poslužitelja baze podataka koji je manje
skalabilan i skuplji od aplikacijskog ili web poslužitelja
•
MySQL implementacija pohranjenih rutina je prilično ograničena
•
stvara ovisnost o proizvođaču SUBP-a .
27
Transakcija je upit ili skupina upita koji moraju biti izvršeni u cijelosti ili uopće ne biti izvršeni.
28 "Hot" online backup podrazumijeva izradu kopija podataka dok su podaci raspoloživi korisnicima i nad njima
se vrše izmjene.
29
MyISAM tablice podložnije su greškama i teže se oporavljaju u slučaju problema od InnoDB tablica. Upravo
je to najčešći razlog odabira InnoDB stroja za skladištenje u situacijama kada nisu potrebne transakcije.
30
Zaključavanje na razini retka (eng. row-level locking) odnosi se na način povećanja mogućnosti konkurentnog
korištenja resursa. Umjesto zaključavanja cijele tablice prilikom izmjene podataka, zaključava se samo redak
nad kojim se vrši izmjena.
31
Vanjski ključ – služi za održavanje referencijalnog integriteta. Ako u tablici postoji vanjski ključ, svaka
vrijednost vanjskog ključa mora odgovarati vrijednosti primarnog ključa tablice s kojom je vanjskim ključem
povezana ili biti jednaka nul-vrijednosti.
23
3. Razvoj web aplikacija
Premda je u praksi dugo bio prisutan ad hoc pristup razvoju web sjedišta, s vremenom, kako
je taj razvoj postajao sve zahtjevniji, stvorio je potrebu slijeđenja određene metodologije ili
razvojnog procesa. Od 1998. godine počinje se govoriti o web inženjerstvu kao disciplini
koja preuzima metode i tehnike softverskog inženjerstva i projektnog menadžmenta te ih
prilagođava novim uvjetima (Rossi et al. 2008). U tu su svrhu razvijeni različiti procesni
modeli32 koji se međusobno razlikuju prema načinu dekompozicije procesa razvoja na
njegove osnovne aktivnosti te utvrđivanju optimalnog redoslijeda i tranzicije među njima.
No, unatoč određenim razlikama među njima, kao zajednička karakteristika ističe se
iterativost.
Izrazita dinamičnost okruženja koja dovodi do čestih izmjena zahtjeva onemogućava
definiranje potpunog rješenja unaprijed već se problem dijeli na manje dijelove koji se dalje
rješavaju u višestrukim kraćim ciklusima uz progresivna poboljšavanja. Za razliku od razvoja
tradicionalnog softevra u kojem se aplikacija izdaje samo jednom po udovoljavanju svim
zahtjevima, kod web aplikacija uobičajena je praksa publiciranja prije realizacije svih
zahtjeva. Što ranija povratna informacija izrazito je važna pa uobičajenu dokumentaciju često
zamjenjuju prototipi.
No, neovisno o odabranom procesnom modelu, kao osnovne aktivnosti razvoja web aplikacija
izdvajaju se (Casteleyn et al. 2009):
•
utvrđivanje zahtjeva – cilj je shvaćanje problema
•
dizajn - planiranje rješenja problema
•
implementacija – prevođenje plana u aplikacijski kod
•
testiranje i evaluacija – cilj je identificiranje grešaka ili neusklađenosti između
zahtjeva i njihove implementacije
•
objavljivanje - predaje se rješenje klijentu
•
održavanje – monitoring sustava u radu i održavanje njegovog "zdravlja"
•
evolucija – poboljšavanje razvijenog rješenja u skladu sa izmijenjenim potrebama i
novim zahtjevima.
32
Neke od razvojnih metoda web inženjerstva: WebML, WSDM, OOHDM (Casteleyn et al. 2009)
24
3.1. Planiranje i utvrđivanje zahtjeva
Prva faza životnog ciklusa aplikacije započinje poslovnim planiranjem kojim se jasno definira
problem koji je projektom potrebno riješiti zanemarujući pritom detalje rješenja. Rezultat
poslovnog planiranja treba biti jasna izjava o tome što naručitelj doista treba i očekuje od
projekta a što će predstavljati okvir za čitav projekt.
Nadalje, budući da se projekti pokreću
kao odgovor na potrebe poslovanja, a s ciljem
stvaranja dodatne vrijednosti, potrebno je jasno definirati poslovni model33 te kriterije
uspjeha, kako s obzirom na poslovne ciljeve, tako i s obzirom na ciljeve samog projekta.
Sljedeći korak sastoji se u identificiranju ključnih stakeholdera34, među kojima su svakako
najvažniji korisnici, a o čijem interesu ovisi i uspjeh samog projekta. Premda kod web
aplikacija korisnici nisu unaprijed poznati, razvijene su brojne metode kojima se olakšava
identificiranje njihovih temeljnih karakteristika među kojima je najpopularnija personas.35
Individualni ciljevi i očekivanja utvrđenih stakeholdera početna su točka kod iznalaženja
zahtjeva.
Zahtjev predstavlja svojstvo koje treba postići ili servis koji sustav treba pružiti. Uobičajeno
se dijele na funkcionalne i nefunkcionalne. Funkcionalni zahtjevi ondose se na ono što sustav
treba raditi, koje servise pružati i na koje ulazne podatke reagirati a kod web aplikacija mogu
se dodatno podijeliti na (Casteleyn et al. 2009):
•
organizacijske zahtjeve
•
zahjeve vezane uz domenu aplikacije odnosno njezin sadržaj
•
zahtjeve vezane uz navigaciju
•
zahtjve vezane uz interakciju.
33
Poslovni model daje odgovor na pitanje kako poduzeće stvara vrijednost.
Stakeholderi su osobe ili organizacije koje imaju direktni ili indirektni utjecaj na zahtjeve sustava koji se
razvija.
35
Personas su detaljni opisi tipičnog ciljnog korisnika u kojima se kao nužan minimum navode ime, dob,
lokacija, zanimanje, fotografija i biografija. Pomažu kod utvrđivanja tko i kako koristi aplikaciju i olakšavaju
donošenje odluka vezanih uz dizajn određenog aspekta projekta davanjem odgovora na pitanja poput: kako bi
(ovaj korisnik) ostavrio (ovaj zadatak)? Što bi (ovaj korisnik) tražio u (ovoj situaciji)?
34
25
Nefunkcionalni zahtjevi odnose se na ograničenja funkcionalnosti poput vremenskih
ograničenja, standarda i sl. a kod web aplikacija mogu obuhvaćati npr.odabir poslužitelja i
njegovih performasni, ciljne web preglednike i rezolucije, korištene tehnologije, strategiju
implementacije i sl.
Karakteristike web aplikacija navedene u poglavlju 2.2. čine utvrđivanje zahjeva posebno
izazovnim. Stoga ga je bitno provoditi iterativno i uz aktivno sudjelovanje svih ključnih
stakeholdera, s posebnom pažnjom usmjerenom na razumijevanje konteksta aplikacije i
arhitekture sustava (Casteleyn et al. 2009).
3.2. Dizajn
Dizajn aplikacije odnosi se na aktivnosti kojima se na temelju prethodno definiranog
problema i utvrđenih zahtjeva izrađuje konceptualni prijedlog rješenja.
Faza dizajna uobičajeno započinje izradom skica (mockup36 ili wireframe37)
ili
nefunkcionalnih prototipa u uskoj suradnji sa korisnicima kako bi se utvrdile karakteristike
aplikacije (npr. izgled i ponašanje komponenata poput tražilice, obrazaca i sl.) i što ranije
dobila povratna informacija. Odobrene skice i/ili prototipi predstavljaju temelj za razradu
dizajna prezentacije, navigacije, interakcije i modela podataka.
3.2.1. Upotrebljivost
Govoreći o dizajnu neizostavno se mora spomenuti pojam odnosno atribut kvalitete koji često
presuđuje hoće li proizvod biti prihvaćen od strane korisnika ili neće. Upotrebljivost (eng.
usability) odnosi se na lakoću kojom korisnici koriste aplikaciju prilikom postizanja svojih
ciljeva (Sharp, Rogers & Preece 2002).
Premda se upotrebljivost web aplikacija primarno spominje u kontekstu dizajna prezentacije,
odluke vezane uz dizajn ostalih aspekata aplikacije reflektiraju se u konačnici i na samog
korisnika, te je o upotrebljivosti potrebno voditi računa u svim fazama dizajna.
Upotrebljivost se postiže realizacijom sljedećih ciljeva (Sharp, Rogers & Preece 2002):
36
Mockup – slika koja prikazuje izgled gotove stranice ili sučelja aplikacije. Uključujue elemente poput logotipa,
boja, tipografije, stilova i uzorak sadržaja.
37
Wireframe – prikazuje strukturu i odnose elemenata na stranici, ali bez elemenata dizajna poput boja, slika i sl.
26
•
efektivnost – daje odgovor na pitanje u kojoj mjeri sustav odgovara namjeni
•
efikasnost – kaže u kojoj mjeri sustav omogućava korisnicima da budu produktivni.
Sustav je potrebno dizajnirati na način da se određeni zadatak može obaviti sa što
manje radnji. Npr. uputno je koristiti predefinirane postavke koje korisnici mogu
prema potrebi lako mijenjati.
•
sigurnost – odnosi se na zaštitu korisnika od opasnih i nepoželjnih situacija. Ovdje se
postavlja pitanje sprječava li sustav korisnika da napravi grešku, te ako ju ipak
napravi, omogućava li sustav oporavak. Npr. sprječavanje nepoželjnog brisanja na
način da se zatražiti potvrda korisnika.
•
korisnost – odnosi se na to pruža li sustav prikladan skup funkcija kako bi omogućio
korisniku da izvrši sve zadatke onako kako on to želi
•
jednostavnost učenja – odnosi se na to koliko je jednostvno naučiti korsititi sustav
po mogućnosti bez dodatne dokumentacije
•
lakoća pamćenja – jednom kad korisnik shvati kako koristiti sustav, postavlja se
pitanje koliko je to jednostavno i zapamtiti, odnosno kakvu pomoć korisnicima pruža
sučelje da bi zapamtili što trebaju napraviti.
3.2.2. Dizajn prezentacije
Dizajn prezentacije odnosi se na sveukupan izgled aplikacije (sktrukturiranje sadržaja, odabir
boja, slika i ostale multimedije, te tipografiju) u skladu sa nefunkcionalnim zahtjevima i
korporativnim identitetom naručitelja. Upravo prezentacija predstavlja ključni faktor za
stjecanje kredibiliteta38, a također je bitna i s obzirom na upotrebljivost te samu atraktivnost.
Kao što je već spomenuto, web aplikacije su izrazito podložne trendovima, a u
visokokompetitivnim uvjetima potrebno je istaknuti se, biti drugačiji od drugih.
3.2.2.1. Raspored elemenata
Raspored elemenata uglavnom se vrši prema pravilima preuzetima iz grafičkog dizaja koji se
prilikom strukturiranja sadržaja oslanja na mrežu vertikalnih i horizontalnih osi. Najčešći
odabir prilikom rasporeda elemenata web stranica predstavlja podjela sadržaja na zaglavlje,
podnožje te nekoliko stupaca između (slika 8.).
38
Studija je pokazala da je izgled web stranica najzaslužniji za stjecanje povjerenja korisnika. Korisnici
jednostavno ne vjeruju amaterski dizajniranim stranicama neovisno o njihovom sadržaju (Tidwell 2011).
27
Slika 8. Uobičajeni raspored elemenata web stranice
(izvor: izradila autorica)
Ovakvo rješenje uobičajeno je kod informacijski orijentiranih web sjedišta. No, kako se web
aplikacije prema namjeni znatno međusobno razlikuju, to su i njihova sučelja puno
raznovrsnija, a često oponašaju izgled desktop aplikacija.
Neovisno o namjeni aplikacije, prilikom raspoređivanja elemenata potrebno je obratiti pažnju
na (Tidwell 2011):
hijerarhiju – treba jasno ukazivati na relativnu važnost pojedinih elemenata i
njihovu međusobnu povezanost
ravnotežu – potrebno je omogućiti nesmetani tok informacija te spriječiti da
nesklad ili nered odvlače pažnju korisnika
gustoću informacija - pretjerana količina teksta, slika i ostale multimedije djeluje
odbojno i zamorno tako da često vrijedi "manje je više"
težište - potrebno je odrediti centralnu točku koja će korisniku omogućiti lakše
snalaženje među sadržajem pri čemu može pomoći i pametna upotreba praznog
prostora
dosljednost – odabrani izgled sučelja treba biti dosljedan kroz sve stranice.
28
3.2.2.2. Tipografija
Tipografija se odnosi na odabir fonta39 i njegove organizacije kako bi se postigla čitljivost
tekstualnih sadržaja i pridonijelo njihovoj estetici. Uobičajeno se vrši podjela fontova na serif
i sans-serif na temelju horizontalnog ili vertikalnog dodatka (serif) na krajevima slova. Na
slici 9. je kao primjer serif fonta prikazan "Times New Roman" a kao primjer sans-serif fonta
"Arial". Vidljivo je da "Times New Roman" posjeduje dodatak, dok ga "Arial" nema.
Za razliku od web sjedišta koja se temelje prvenstveno na pružanju informacija kroz veće
količine teksta, kod web aplikacija tekst se uglavnom nalazi na malim oznakama ili je dan u
kraćim rečenicama tako da je prilikom donošenja odluka o tipografiji web aplikacija potrebno
voditi računa o čitljivosti pojedinih znakova, a ne blokova teksta.
Slika 9. Serif i sans-serif font
(izvor: izradila autorica)
Općenito je uvriježeno da su serif fontovi čitljiviji na razini pojedinog znaka te su pogodniji
pri manjim veličinama, dok kod čitanja veće količine teksta dovode do zamora te su u tom
slučaju pogodniji serif fontovi (Zambonini 2011).
3.2.2.3. Boje
Boje su općenito najzaslužnije za prvi dojam koji korisnici stječu i opći ugođaj web stranica.
Premda njihov odbir treba odražavati brend i poruku koja se korisnicima želi uputiti, posebnu
pažnju treba pridati tome kako se njihovo kombiniranje odražava na čitljivost. Budući da oko
10% populacije ima određenih poteškoća sa raspoznavanjem boja (Tidwell 2011), potrebno je
izbjegavati
problematične kombinacije poput crvene i zelene, zelene i smeđe, plave i
ljubičaste te komplementarne boje koje puno brže dovode do zamora prilikom čitanja (slika
10.). S druge strane, kombinacije koje pridonose boljoj čitljivosti sastoje se općenito od
svijetle podloge i tamnog teksta ili svijetlog teksta na tamnoj podlozi.
39
Font - skup slovnih, brojčanih i ostalih znakova koji po izgledu pripadaju istoj vrsti.
29
Slika 10. Kombinacije boja: komplementarne, analogne, triadne
(izvor: Zambonini 2011)
Prilikom odabira boja također je uputno obratiti pažnju na kulturno uvjetovane razlike u
tumačenju njihovog značenja, posebno ako je aplikacija namijenjena međunarodnom tržištu.
Npr. dok je u zapadnim kulturama crvena boja čest odabir kojim se sugerira smanjenje (poput
pada cijena dionica na burzi), u istočnim se kulturama crvena boja tumači kao povećanje
(Zambonini 2011).
3.2.3. Dizajn navigacije
Dizajn navigacije odnosi na povezivanje stranica i elemenata sadržaja utvrđivanjem smislenih
veza među njima. Navigacija (Kalbach 2007):
1. pruža pristup informacijama
2. prikazuje lokaciju - korisnici trebaju znati:
a) gdje se nalaze
b) što tu mogu pronaći
c) gdje mogu otići
3. odražava dubinu sadržaja – npr. broj kategorija unutar izbornika daje korisniku
informaciju o širini nečije ponude
4. odražava brend - raspored navigacijskih elemenata, ton i stil na oznakama upotpunjuju
dojam o brendu.
3.2.3.1. Kategorije navigacije
Navigacija se može podijeliti na sljedeće kategorije (slika 11.) (Kalbach 2007):
30
Slika 11. Kategorije navigacije
(izvor: izradila autorica)
1. strukturnu – koja se dalje dijeli na:
a. primarnu - uobičajeno je smještena na vrhu stranice te zadržava ujednačeni
izgled kroz sve stranice. Omogućava kretanje između glavnih kategorija.
b. sekundarnu (lokalnu) – omogućava kretanje među podkategorijama, može biti
manje ujednačenog izgleda.
2. asocijativnu – povezuje sadržaj kroz različite hijerarhijske razine. Omogućuje
korisniku da čitajući o jednoj temi pristupi sličnoj temi ili dodatnom sadržaju (npr.
quick links, kontekstualna navigacija ("desni klik"), navigacija u podnožju).
3. pomoćnu – povezuje alate i mogućnosti koje pomažu korisniku prilikom ostvarivanja
određenih zadataka npr. prijava, pretraga i sl.
3.2.3.2. Navigacijski mehanizmi
Navigacija se realizira pomoću različitih navigacijskih mehanizama kao grupa poveznica koje
dijele sličan izgled i ponašanje (Kalbach 2007). Neki od najčešće korištenih navigacijskih
mehanizama jesu:
•
horizontalni40 i vertikalni izbornici41
40
Horizontalni izbornik - jedan je od najpopularnijih oblika navigacijskog mehanizma. Najčešće se koristi za
primanru navigaciju te se uglavnom nalazi neposredno iznad ili ispod zaglavlja svake stranice. Osnovni
nedostatak predstavlja organičeni broj elemenata koji se mogu smjestiti (optimalno 5-12) pa se često kombinira
sa dinamičkim izbornikom.
31
•
dinamički izbornici (eng. pull-down)42
•
tabovi43
•
mape web sjedišta44
•
mehanizmi za straničenje (eng. paging)45
•
stablasti mehanizmi (eng. tree)46
•
direktoriji47
•
oblaci oznaka (eng. tag clouds)48.
Rezultat dizajna navigacije čine:
1. elementi koji su dostupni korisniku
2. navigacijska struktura koja predstavlja puteve koje korisnik može slijediti da bi istražio
sadržaje ili ostvario svoje zadatke.
3.2.4. Dizajn interakcije
Interakcija se može promatrati kroz 5 dimenzija (Silver 2007):
1D – riječi,
2D – vizualni prikaz – čine ga elementi sučelja poput tipografije, dijagrama, ikona i
ostalih grafičkih elemenata s kojima korisnik dolazi u interakciju,
3D - fizički objekti ili prostor - unutar kojih se ostvaruje interakcija,
4D – vrijeme – unutar kojeg se odvija interakcija – npr. određeni se sadržaji (poput
zvuka, videa ili animacije) mijenjaju s protekom vremena,
5D – ponašanje – uključuje akcije i reakcije korisnika na sučelje.
Prve 3 dimenzije omogućavaju interakciju dok vrijeme i ponašanje definiraju interakciju.
41
Vertikalni izbornik fleksibilniji je od horizontalne navigacije budući da se elementi lako mogu dodavati prema
dolje. Uglavnom se smješta sa lijeve strane.
42
Dinamički izbornik (eng. pull-down) – da bi se prikazao sadržaj izbornika, potrebna je određena radnja
korisnika (klik ili prelazak pokazivačem iznad elementa). Osnovna prednost sastoji se u tome što omogućava
smještanje većeg broja kategorja budući da zauzima manje prostora.
43
Tabovi - najčeće imaju zaobljene uglove a od horizontanih izbornika razlikuju se samo po izgledu, dok im je
funkcionalnost jednaka. Imaju pozitivan psihološki efekt jer asociraju na arhiviranje.
44
Mapa web sjedišta – koristi se za prikazivanje strukture web sjedišta.
45
Straničenje (eng. paging) kao navigacijski mehanizam često se koristi kod prikazivanja rezulta pretrage kako
bi se pokazao broj pronađenih elemenata.
46
Stablasti (eng. tree) navigacijski mehanizam služi za prikazivanje hijerarhijskih struktura.
47
Direktoriji (kao navigacijski mehanizam) omogućavaju pristup stranicama sortiranim prema temama.
48
Oblaci oznaka (eng. tag clouds) - poveznice su dane abecednim redom a veličinom slova odražavaju
učestalost pojave ili važnost određenog pojma.
32
Dizajn interakcije kombinira razne vizualne, dinamičke, funkcionalne i tehničke elemente s
ciljem stvaranja interaktivnih proizvoda koji će korisnika poduprijeti u obavljanju zadataka
pomažući mu da bude što produktivniji. Ranije navedeni ciljevi lakoće korištenja
predstavljaju jednu stranu dizajna interakcije koja se nadopunjava ciljevima orijentiranim na
postizanje pozitivnog iskustva korištenja (eng. user experience) poput estetike, kreativnosti,
zabave, motivacije, emocionalnog ispunjenja (Sharp, Rogers & Preece 2002).
Dizajn interakcije mora biti takav da omogući fluidan tijek odvijanja dijaloga između
korisnika i aplikacije - korisnik ne smije dugo čekati na odgovor, komponente sučelja moraju
biti usklađene sa očekivanim i pozantim te se korisnika ne smije dovoditi u situacije
nejasnoće oko korištenja aplikacije.
Premda visokointeraktivne aplikacije pružaju korisniku bolji doživljaj i veće zadovoljstvo
korištenja, postoji određeni trade-off između lakoće održavanja i ponovne iskoristivosti koda
s jedne strane te interaktivnsoti i responzivnosti s druge strane (slika 12.)
Slika 12. Usporedba tehnologija za izradu sučelja
(izvor: Kappel et al. 2006)
Web aplikacije s atraktivnim i viskoko interaktivnim sučeljima baziranim na AJAX
tehnologijama često imaju čvrsto povezanu prezentaciju, podatke i logiku (Kappel et al. 2006)
što stvara probleme prilikom održavanja i nadogradnje te je i to potrebno uzeti u obzir
prilikom odluke koju razinu interaktivnosti pružiti.
33
3.2.5. Modeliranje podataka
Modeliranje podataka provodi se kroz tri faze:
1. konceptualno modeliranje
2. logičko modeliranje
3. fizičko modeliranje.
3.2.5.1. Konceptualno modeliranje
Konceptualno modeliranje koristi postupke apstrakcije
zahtjeva
identificiraju
entiteti50,
njihovi
49
atributi51
kojima se na temelju specifikacije
i
međusobne
veze52.
Rezultat
konceptualnog modeliranja je konceptualni model podataka neovisan o implementaciji.
Uobičajeno se prikazuje dijagramom entiteti-veze (eng. Entity-Relationship Diagram) koji je
zbog svoje jednostavnosti razumljiv i korisnicima te je pogodan za komunikaciju između
različitih stakeholdera.
Slika 13. Entiteti i osnovni tipovi veza
(izvor: izradila autorica)
Slika 13. prikazuje entitete i osnovne tipove veza u Martinovoj notaciji. Entiteti su prikazani
pravokutnikom a veze linijom. Uloga eniteta na lijevoj strani navedena je iznad linije dok je
49
Postupci apstrakcije– mentalni procesi kojima se vrši odabir bitnih karakteristika objekata, a zanemaruju one
nebitne.
50
Entitet – stvaran ili apstraktan predmet ili događaj o kojem se prikupljaju podaci (Varga 1994).
51
Atribut - svojstvo entiteta koje je bitno za sustav.
52
Veza – agregacija dvaju ili više entiteta u novi entitet (Varga 1994). Broj entiteta koji sudjeluju u vezi
predstavlja stupanj veze : 1 entitet - unarna (rekurzivna, involucijska), 2 entiteta - binarna, 3 entiteta – ternarna,
.., n-entiteta - n-arna. Osnovni tipovi veza s obzirom na broj entiteta jednog tipa koji sudjeluje u vezi s entitetom
drugog tipa :
1:1 (jedan entitet jednog tipa sudjeluje u vezi sa jednim entitetom drugog tipa),
1:M (jedan entitet jednog tipa sudjeluje u vezi sa više entiteta drugog tipa),
M:M (više entiteta jednog tipa sudjeluje u vezi sa više entiteta drugog tipa).
34
uloga entiteta na desnoj strani navedena ispod linije. Na liniji veze nalaze se oznake53 donje i
gornje granice sudjelovanja entiteta u vezi npr. portfelj mora sadržavati jednu ili više dionica,
dionica se može nalaziti u više portfelja (ne mora niti u jednom).
3.2.5.2. Logičko modeliranje
Logičkim modeliranjem prevodi se konceptualni model u opis strukture baze podataka koji
može procesirati i implementirati SUBP. Premda logički model ne ovisi o SUBP-u, on ovisi
o odabranom modelu podataka (hijerarhijskom, mrežnom, relacijskom...). Relacijski model
podataka danas je najčešće korišteni model čije je osnove postavio matematičar E.F.Codd
1970. godine (Varga 1994). To je formalni model utemeljen na matematičkom pojmu relacije
koja se u modelu prikazuje kao tablica sa stupcima i retcima (slika 14.). Za pronalaženje bilo
kojeg podatka u relacijskoj bazi podataka dovoljni su naziv tablice, naziv stupca i primarni
ključ54 (pravilo garantiranog pristupa)55.
Slika 14. Relacija "Dionica"
(izvor: izradila autorica)
Sama pretvorba konceptualnog modela u relacijski model sastoji se od nekoliko koraka
(Varga 1994):
•
pretvorbe entiteta u relacije
53
Oznaka bliža entiteu označava gornju granicu sudjelovanja u vezi dok druga oznaka označava donju granicu
(opcionalnost). Kružić označava 0, crtica 1, > ili < označavaju M.
54
Primarni ključ – atribut ili skup atributa koji služi za jednoznačnu identifikaciju svake n-torke relacije. Mora
udovoljiti zahtjevima:
• jedinstvenosti – u relaciji ne smije postojati n-torka sa jednakom vrijednošću primarnog ključa
• minimalnosti – ako se sastoji od više atributa, niti jedan njegov dio ne može se ukloniti a da se ne naruši
pravilo jedinstvenosti
• pravilo entitetskog integriteta – niti jedan dio primarnog ključa ne smije imati nul-vrijednost.
55
Codd –ovo pravilo broj 2. E.F.Codd je 1985. godine objavio 12 pravila (kriterija) kojima potpuno relacijska
baza podataka mora udovoljavati .
35
•
protvorbe veza uvođenjem primarnog ključa jedne relacije kao vanjski ključ druge ili
uvođenjem dodatne relacije
•
pretvorbe atributa u stupce uz opisivanje ograničenja (jedinstvenosti56, obveznosti57,
referencijalnog integriteta58, ograničenja uz provjeru59).
Dobro dizajnirana baza podataka sadrži podatke koji su konzistentni60, bez redundancije61 i ne
pokazuju anomalije prilikom unosa, izmjene ili brisanja62 (Varga 1994). Ove anomalije
moguće je izbjeći svođenjem relacije na prikladnu normalnu formu pri čemu svaka normalna
forma predstavlja strože pravilo ograničenja podataka u relacijama. Od 6 normalnih formi63
koje se koriste u praksi, obično se smatra dostatnim da se relacija nalazi u trećoj (3NF) što
obuhvaća da se ujedno nalazi i u 1NF64 i 2NF65 te da: "svaki neključni atribut ovisi o ključu,
cijelom ključu i ni o čemu osim o ključu"(Varga 1994).
3.2.5.3. Fizičko modeliranje
Fizičkim modeliranjem određuje se fizička struktura smještaja i metoda pristupa podacima na
sekundarnim memorijama. Uključuje odabir indeksa66, particioniranje67, grupiranje podataka
u klastere68 te selektivnu materijalizaciju69 podataka.
56
Ograničenje jedinstvenosti znači da u tablici ne smije postojati redak sa jednakom vrijednošću određenog
atributa (ili skupine atributa). UNIQUE ograničenjem može se postaviti zahtjev jedinstvenosti i na neključne
atribute.
57
Atributima koji moraju imati neku vrijednost postavlja se ograničenje NOT NULL.
58
Referencijalni integritet - vidi pod 31.
59
CHECK ograničenjem vrši se provjera odgovara li podatak zadanom intervalu vrijednosti ili određenim
uvjetima.
60
Konzistentnost podataka – znači da među podacima nema proturječnosti.
61
Redundancija (zalihost) označava nepotrebno ponavljanje podataka.
62
Anomalija prilikom unosa javlja se kad je nemoguć unos podatka jer nedostaje dio primarnog ključa (primarni
ključ ne smije sadržavati nul-vrijednost).
Anomalija prilikom brisanja nastaje kad dio primarnog ključa ili retka poprima nul-vrijednost te traži brisanje
čitavog retka što rezultira gubitkom podataka.
Anomalija prilkom izmjene javlja se kad je izmjena otežana zbog dupliciranih (redundantnih) podataka te
predstavlja opasnost da dođe do nekonzistentnosti u bazi.
63
Normalne forme koje se koriste u praksi: 1NF, 2NF, 3NF, BCNF (Boyce-Codd Normal Form), 4NF, 5NF.
Postoje dodatne normalne forme, ali više teorijskog značaja poput: RFNF(Redundancy Free Normal Form),
SKNF (Superkey Normal Form), 6NF.
64
1NF - relacija se nalazi u prvoj normalnoj formi ako su svi neključni atributi funkcijski zavisni o ključu
relacije (Varga 1994).
65
2NF – relacija se nalazi u drugoj normalnoj formi ako su svi neključni atributi potpuno funkcijski zavisni o
bilo kojem (mogućem) ključu relacije (Varga 1994).
66
Indeksi – objekti baze podataka koji služe za ubrzavanje pronalaženja podataka u bazi. Najčešće korištena
struktura indeksa je B-TREE (binarno stablo).
67
Particioniranje – odnosi se na podjelu većih tablica na manje kako bi se smanjila količina podataka koja se
vraća kao rezulata upita. Postoje dvije vrste particioniranja: horizontalno i vertikalno. Kod horizontalnog
particioniranja tablica se dijeli na tablice jednake strukture s time da svaka sadrži samo dio redaka originalne
tablice. Kod vertikalnog particioniranja tablica se dijeli na manje od kojih svaka sadrži samo dio stupaca.
68
Klastering - suprotno od particioniranja. Omogućava ubrzavanje rada sa podacima tako što se podaci kojima
se često zajedno pristupa smještaju blizu na disku čime se smanjuje broj potrebnih čitanja ili pisanja na disk.
36
Cilj fizičkog modeliranja je maksimizacija performansi baze podataka. Kriteriji kojima se pri
tome vodi obuhvaćaju:
•
vrijeme potrebno za izvršavanje upita
•
upotrebu prostora na disku
•
broj transkacija koje je moguće izvršiti u jedinici vremena.
Rezultat modeliranja podataka predstavljaju DDL naredbe SQL jezika kojima se kreira baza
podataka.
3.3. Implementacija
Faza dizajna proizvodi niz konceptualnih rješenja koja se u fazi implementacije prevode u
aplikacijski kod upotrebom različitih tehnologija i programskih jezika. Sam odabir tehnologija
trebao bi se temeljiti na mogućnosti jednostavnog i brzog razvoja kako bi se aplikacija mogla
što ranije prezentirati potencijalnim korisnicima te time utvrditi u kojoj mjeri ona zadovoljava
njihove potrebe. Uobičajeno je (i poželjno) izbjegavanje razvoja aplikacije "od nule" jer je
takav pristup dugotrajan i podložan greškama, već je uputno koristiti već gotov i testirani kod
u obliku predložaka, bibiloteka70, frameworka71 ili web servisa (Zambonini 2011).
3.3.1. Implementacija prezentacijskog sloja
Kod implementacije sučelja javlja se pitanje kako tretirati korisnike čiji preglednici ne
podržavaju tehnologije odabrane za izradu aplikacije. U vezi toga postoji nekoliko pristupa
među kojima se ističu "graciozna degradacija" (eng. graceful degradation) i "postepena
poboljšavanja" (eng. progressive enhancement).
Prvi pristup temelji se na principu da će dijelovi kompleksnog sustava otkazati te pokušava
pružiti alternativna rješenja koja, premda i dalje funkcionalna, pružaju nešto siromašniji
doživljaj (Parker et al. 2010). Takav se pristup realizira na način da se sučelje dizajnira i
kodira s namjerom iskorištavanja najmodernijih tehnologija i mogućnosti preglednika, a
69
Materijalizirani pogledi – za razliku od pogleda koji predstavljaju virtualne tablice kod kojih se pohranjuje
upit, ali ne i rezultat upita, rezultati materijaliziranih pogleda pohranjuju se kao bilo koja druga tablica.
70
Biblioteka - predstavlja kolekciju funkcija određene namjene (npr. za upravljanje konekcijom sa bazom,
enkripciju itd.).Upotreba bibiloteka je jednostavna te se svodi se na uključivanje bibiloteke u aplikaciju te
pozivanje pojedinih funkcija prema potrebi.
71
Framework – platforma za razvoj aplikacija koja pruža već gotove komponente i funkcionalnosti. Znatno
ubrzava razvoj budući da omogućava programerima da prilagode kod svojim potrebama umjesto da ga nanovo
pišu. Jedan od najpoznatijih je Microsoftov .NET framework za razvoj desktop i web aplikacija.
37
korisnicima preglednika ograničene funkcionalnosti pruža se alternativna verzija. Primjer
takvog pristupa je korištenje <noscript> HTML taga unutar kojega je moguće smjestiti
alternativni sadržaj za korisnike čiji preglednici ne podržavaju JavaScript (ili su tu podršku
sami isključili). No, umjesto alternativnog sadržaja, u praksi se to se često svodilo samo na
rečenicu "Vaš preglednik ne podržava JavaScript". Zbog očitog nedostatka - isključivanja
korisnika, a što nikome nije cilj jer dovodi do smanjenja potencijalne zarade - ovaj se pristup
se sve više napušta u korist drugog.
Pojam "progressive enhancement" prvi se put javlja 2003. godine (Parker et al. 2010), a
polazi od pretpostavke da se svaki sustav može svesti na jednostavan i funkcionalan temeljni
kod koji će svugdje raditi (Parker et al. 2010). Realizira se tako da se tehnologije dodaju u
slojevima. Započinje se sa sadržajem koji predstavlja temelj nad kojim se slažu ostali slojevi:
•
prvi sloj čini HTML
•
drugi sloj čini CSS – dodaju se stilovi za tipografiju, zatim za pozicioniranje i na kraju
boje i pozadine
•
treći sloj čini JavaScript
•
nakon toga idu ostale slabije podržane tehnologije.
Ovakvim se pristupom osigurava da će sav sadržaj i ključna fukcionalnost biti uvijek dostupni
korisniku bez obzira podržava li njegov preglednik najnovije tehnologije ili ne.
3.3.2. Implementacija aplikacijskog sloja
Budući da su za implementaciju aplikacijskog sloja na raspolaganju brojne tehnologije, ovdje
se zbog opširnosti neće posebno objašnajvati, već će u drugom dijelu rada biti prikazana
implementacija jedne funkcionalnosti.
3.3.3. Implementacija podatkovnog sloja
Implementacija podatkovnog sloja realizira se izradom baze podataka upotrebom SQL DDL
naredbi, punjenjem (testnim) podacima, izradom indeksa i određivanjem ograničenja
referencijalnog integriteta, pisanjem i (optimizacijom) upita i pohranjenog koda itd. Nakon
što je baza podataka izrađena i napunjena podacima, moguće ju je testirati.
3.4. Testiranje
Testiranje predstavlja aktivnost procjene kvalitete proizvoda kako bi se pronalaskom i
uklanjanjem defekata i problema povećala njegova kvaliteta (Kappel et al. 2006).
38
Premda se osnovni principi testiranja softvera mogu primijeniti i na web aplikacije, zbog
karakteristika navedenih u poglavlju 2.2. postoje dodatne okolnosti koje je potrebno uzeti u
obzir (Kappel et al. 2006):
•
pojedine greške u sadržaju moguće je pronaći tek ručnim metodama budući da alati za
automatiziranu provjeru (npr. pravopisa) prepoznaju samo određene vrste grešaka
•
neke je zahtjeve vezane uz prezentaciju, poput estetike sučelja koja je podložna
subjektivnosti, teško specificirati a samim time i testirati
•
zahtjev da aplikacija bude funkcionalna na različitim uređajima i konfiguracijama
također znači i potrebu da se testiranje provede za svaku od mogućih kombinacija. No,
budući da je to praktički nemoguće, u tu se svrhu koriste simulatori koji su i sami
podložni greškama.
•
zbog globalne dostupnosti potrebno je voditi računa o kulturnim razlikama i njima
uvjetovanim postavkama (npr. razlike u smjeru čitanja traže različite pristupe
navigaciji)
•
web aplikacije sastoje se od brojnih softverskih komponenata što često dovodi do
grešaka uzrokovanih njihovom nekompatibilnošću, pogrešnim konfiguriranjem ili
nezrelošću primijenjenih tehnologija
•
brze izmjene otežavaju testiranje i čine ga kompleksnijim od onog tradicionalnog
softvera.
Zbog prethodno navedenih karakteristika testiranje web aplikacija, osim provjere usklađenosti
sa specifikacijama i funkcionalnim zahtjevima, a koja je temelj testiranja tradicionalnog
softvera, potrebno je proširiti testiranjem (Kappel et al. 2006):
1. poveznica
2. kompatibilnosti
3. upotrebljivosti
4. performansi
5. sigurnosti.
3.4.1. Testiranje poveznica
Stranice moraju biti ispravno povezane i to na način da im je moguće pristupiti putem
određene poveznice, a također moraju sadržavati i poveznicu za povratak. Testiranje se može
provoditi ručno izradom mape web sjedišta ili pomoću tzv. Link Checker-a. Cilj testiranja je
39
pronalaženje poveznica koje upućuju na nepostojeće stranice (eng. broken link), stranica koje
ne sadrže poveznicu za povratak (eng. orphaned page) ili one koje uopće nisu povezane.
3.4.2. Testiranje kompatibilnosti
Cilj testiranja kompatibilnosti je pronalaženje grešaka (nekonzistentnosti u prikazu ili
smanjenje funkcionalnosti) uzrokovanih razlikama u web preglednicima i operativnim
sustavima. Testiranjem je potrebno utvrditi kako se aplikacija ponaša u preglednicima
različitih
proizvođača,
njihovim
različitm
verzijama,
na
različitim
rezolucijama,
konfiguracijama (kako hardverskim tako i softverskim), te utvrditi ostaje li aplikacija
funkcionalna u slučaju da korisnik onemogući cookies72, podršku za JavaScript, CSS ili neki
od dodataka (eng. plug-in) koje aplikacija koristi. U testiranju kompatibilnosti pomažu
validacijski servisi koji provjeravaju uskađenost sa standardima (HTML-a, CSS-a...) te razni
simulatori.
3.4.3. Testiranje upotrebljivosti
Testiranje upotrebljivosti testira lakoću korištenja različith verzija dizajna, navigacijskih
odluka i opće strukture aplikacije. Formalna testiranja provode se u laboratorijskim uvjetima
uz sudjelovanje reprezentativnog uzorka korisnika pri čemu se snima njihovo ponašanje
prilikom korištenja aplikacije. Također obuhvaća i provjeru prikladnosti aplikacije za osobe
sa određenim teškoćama (vizualnim, auditivnim, kognitivnim).
3.4.4. Testiranje performansi
Testiranje performansi uključuje:
a) testove opterećenja – kojima se provjerava ponašanje aplikacije pod različitim razinama
opterećenja te se mjeri vrijeme odaziva, propusnost, iskorištenost memorije, procesora
itd.
b) stres testove – koji mjere kako aplikacija reagira na stresne situacije poput opterećenja
iznad specificiranog maksimuma ili prilikom velikih fluktuacija u opterećenju
c) testove pouzdanosti – sustav se prati kroz produženo vrijeme rada kako bi se utvrdili
problemi
koji se manifestiraju s odgodom poput curenja memorije, nezatvorenih
konekcija prema bazi i sl.
72
Cookies (kolačići) su tekstualne datoteke smještene na računalu korisnika u koje web stranice zapisuju
određene podatke (npr. odabrane postavke korisnika). Budući da predstavljaju svojevrsni sigurnosni rizik, web
preglednici omogućavaju isključivanje podrške za kolačiće.
40
Za potrebe testiranja koriste se generatori opterećenja koji simuliraju konkurentne zahtjeve
većeg broja klijenata.
3.4.5. Testiranje sigurnosti
Sigurnost web aplikacija izrazito je kompleksna tema koja nadilazi okvire ovog rada, no
također predstavlja i kritični faktor, naročito za aplikacije koje uključuju novčane transakcije.
Konstantna izloženost web aplikacija najrazličitijim rizicima i prijetnjama traži sustavni
pristup njezinom ostvarivanju.
Općenito se tehnike testiranja sigurnosti mogu podijeliti na (OWASP 2008):
a) manualne provjere - odnose se na provjere ljudi, politika i procesa, ali mogu
uključivati i provjere različitih tehničkih odluka poput onih vezanih uz arhitekturu
sustava. Uobičajeno se provode analizom dokumenata ili provođenjem intervjua sa
dizajnerima ili vlasnicima sustava.
b) modeliranje prijetnji - odnosi se na identificiranje mogućih prijetnji i napada čime se
omogućava razvijanje strategija ublažavanja potencijalnih ranjivosti te usmjeravanje
pažnje na dijelove sustava kojima je ona najpotrebnija. Preporučuje se za sve
aplikacije razviti i dokumentirati model prijetnji.
c) provjere koda – predstavlja proces manualne provjere izvornog koda s ciljem
pronalaženja sigurnosnih propusta. Mnoge nenamjerne, ali važne sigurnosne probleme
jako je teško otkriti drugim oblicima analize ili testiranja, što čini provjeru izvornog
koda najboljom tehnikom testiranja. Sve se informacije za otkivanje sigurnosnih
problema nalaze negdje u kodu. Pregledom izvornog koda tester može precizno
utvrditi što se gdje događa (ili što bi se trebalo događati).
d) penetracijsko testiranje - odnosi se na testiranje aplikacije bez znanja o načinu
njezinog internog funkcioniranja. Tester, pristupajući aplikaciji kao regularni korisnik,
pokušava izvršiti određene napade te pronaći i iskoristiti slabosti.
3.5. Objavljivanje, održavanje i evolucija
3.5.1. Objavljivanje
Nakon implementacije web aplikacije postoje dvije ključne odluke koje treba donijeti prije
njezinog konačnog objavljivanja. Jedna se odnosi na odabir web poslužitelja i fizičkog
smještaja, a druga na odbir domene.
41
3.5.1.1. Odabir web poslužitelja i fizičkog smještaja web sjedišta
Ovisno o odlukama za vrijeme faze implementacije u vidu odabranih programskih jezika,
framework-a ili razvojnih alata, razlikuje se i stupanj slobode kod odabira web poslužitelja pri
čemu se poslužitelj odnosi kako na hardver, odnosno fizičko računalo na kojem se pokreće
aplikacija, tako i na softver zadužen za primanje HTTP zahtjeva i odgovore na njih. Npr.
uobičajeni web poslužitelj u kombinaciji sa PHP skriptnim jezikom i MySQL SUBP-om je
Apache HTTP Server.
Što se tiče odabira fizičke lokacije smještaja web sjedišta, uobičajene opcije su:
•
dijeljeni hosting
- pružatelj usluga smještaja web sjedišta stavlja korisniku na
raspolaganje određeni diskovni prostor koji dijeli sa drugim korisnicima. Predstavlja
najjeftinije rješenje prikladno za manje aplikacije ili osobne stranice.
•
VPS (Virtual Private Severs) - premda korisnici i dalje dijele isti hardver, svakome je
stavljena na raspoloaganje virtualna mašina što omogućava izolaciju od ostalih
korisnika budući da svatko ima instaliran svoj operativni sustav i drugi softver.
Ovakvo rješenje pogodno je za većinu web aplikacija.
•
dedicirani ili kolocirani poslužitelj – korisnik u prvom slučaju unajmljuje, a u drugom
slučaju smješta vlastiti poslužitelj kod pružatelja usluge što može, ali i ne mora,
obuhvaćati i usluge održavanja. Predstavlja najskuplju varijantu jer korisnik u
potonjem slučaju mora, osim vlastitog hardvera i softvera, posjedovati i sva potrebna
znanja za njihovo održavanje.
•
hosting u oblaku (eng. Cloud hosting) – zadnjih godina sve popularnije rješenje
pogodno za aplikacije koje su pod visokim, ali neujednačenim, opterećenjem.
Korisnici imaju na raspolaganju virtualne poslužitelje iza kojih stoji mreža fizičkih
poslužitelja. Time je omogućena visoka skalabilnost sustava pri čemu korisnici plaćaju
samo prema količini upotrijebljenih resursa.
3.5.1.2. Registracija domene
Od trenutka kad je web poslužitelj fizički spojen na Web i web softver pokrenut na
poslužitelju, resursi koji se na njemu nalaze postaju dostupni korisnicima. No, da bi korisnik
doista mogao pristupiti sadržajima, trebao bi poznavati IP adresu73 web poslužitelja. Budući
73
IP adresa je jedinstvena brojčana oznaka koja služi za identificiranje pojedinog računala u mreži. U okviru
verzije IP protokola IPv4, IP adrese se prezentiraju kao četiri decimalna broja u rasponu 0-255 odvojena točkom.
Npr. 93.137.197.252
42
da su IP adrese teško pamtljive, moguće je registrirati lako pamtljivu simboličku adresu –
domenu koja se putem DNS
74
poslužitelja povezuje sa fizičkom IP adresom. Registracija
domene vrši se putem registrara odnosno institucije ili kompanije kojoj je dodijeljeno pravo
obavljanja poslova registracije, aktivacije, deaktivacije i brisanja domena75 pri čemu korisnik
ne postaje vlasnik domene već samo ostvaruje pravo na njezino korištenje kroz određeno
razdoblje.
Prilikom odabira domene treba dobro razmilisti o nazivu. Naziv domene treba biti lako
pamtljiv i jedank ili što sličniji nazivu poduzeća, proizvoda, imenu osobe odnosno onoga što
čini glavni sadržaj web sjedišta jer će upravo po tim pojmovima korisnici vršiti pretraživanje.
Također je potrebno razmisliti o najčešćim pogreškama prilikom upisivanja pa je dobro
registrirati različite kombinacije koje će upućivati na isto web sjedište (npr. primainvest.com,
prima-invest.com, prima-invest.net itd.).
3.5.2. Održavanje i evolucija
Objavljivanjem web aplikacija ne prestaje njihov životni ciklus već se on nastavlja kroz
daljnje održavanje i evoluciju. Održavanje se odnosi na osiguranje ispravnog rada postojeće
web aplikacije bez izmjene njezinih bitnih karakteristika. Evolucija, s druge strane,
predstavlja kontinuirani proces izmjene određenih karakteristika u skladu sa novim ili
izmijenjenim zahtjevima. Neki od tipičnih razloga za evoluciju (Kappel et al. 2006):
•
neadekvatnost postojećeg rješenja – tek se kod stvarnog korištenja može u potpunosti
utvrditi odgovara li aplikacija potrebama korisnika
•
promjene poslovnih pravila
•
pojava novih tehnologija
•
izmjene dizajna radi povećanja atraktivnosti
•
poboljšanje koda radi povećanja skalabilnosti
•
postizanje interoperabilnosti odnosno integracija sa postojećim aplikacijama.
74
DNS (Domain Name System) – je strogo hijerarhijski distribuirani sustav u kojem se nalaze informacije o
IP adresama i domenskim imenima.Vrši preslikavanje domenskog imena u jednu ili više IP adresa i obrnuto,
preslikavanje jedne ili više IP adrese u jedno domensko ime. Klijentima DNS informacije pružaju DNS
poslužitelji.
75
Upravljanje globalnim imeničkim (domenskim) Internet prostorom ostvaruje se kroz nezavisnu organizaciju
Internet Corporation for Assigned Names and Numbers (ICANN), dok su za upravljanje nacionalnim vršnim
domenama zadužene ustanove unutar pojedinih država. Od 1993. godine za upravljenjm vršnom .hr domenom
zadužen je CARNet (Hrvatska akademska i istraživačka mreža).
43
4. Upravljanje portfeljem
Ako se portfelj definira kao skup financijske imovine u vlasništvu jednog investitora, onda se
upravljanje portfeljem odnosi na konstruiranje takvog portfelja koji će kroz vrijeme evoluirati
prema ciljnom prinosu postavljenom od strane investitora (Amenc & Sourd 2003). Metode
koje investitoru pritom stoje na raspolaganju nalaze se u rasponu od tradicionalnih metoda
financijske analize pa do kvantitativnih metoda utemeljenih na Markowitzevoj Modernoj
portfolio teoriji. Budući da su kvantitativne metode danas u najširoj upotrebi, a i sama
aplikacija razvijena za potrebe ovog rada implementira jednu od njih, u nastavku će o tome
biti riječ.
4.1. Moderna portfolio teorija
Moderna portfolio teorija (u daljnjem tekstu MPT) predstavlja jedan od prvih ozbiljnijih
pokušaja opisivanja tržišta konzistentnim matematičkim modelom. Osnovne postavke teorije
Markowitz je predstavio u članku iz 1952. godine, a 1990. godine je zajedno sa Sharpe i
Millerom dobio Nobelovu nagradu za ekonomiju (Amenc & Sourd 2003).
MPT teorija daje odgovor na pitanje kako racionalni investitor, suočen sa neizvjesnom
budućnošću, donosi odluke o izboru portfelja. Za razliku od situacije kad je ostvarivanje
određene stope prinosa sasvim izvjesna, pa je to ujedno i glavni kriterij kojim se investitor
vodi, u slučaju neizvjesne budućnosti investitor mora uzeti u obzir i rizik kao mogućnost da
investirana sredstva prinesu manju dobit od očekivane ili čak ostvare gubitak.
Markowitz je bio prvi koji je kvantificirao odnos između prinosa i rizika portfelja (Amenc &
Sourd 2003). Upravo je pronalaženje njihove ravnoteže te konstruiranje takvog portfelja koji
će za danu razinu prinosa imati minimalni rizik, odnosno za danu razinu rizika imati
maksimalni prinos, osnovna ideja MPT teorije. Markowitz je takav portfelj nazvao efikasnim,
a skup svih efikasnih portfelja efikasnom granicom.
Slika 15. stavlja u odnos očekvani prinos s jedne strane i standardnu devijaciju portfelja kao
mjeru rizika s druge strane. Skup svih mogućih portfelja na slici je prikazan sivom površinom.
Efikasna granica nalazi se na liniji između točaka A i B pri čemu točka A označava ujedno i
portfelj minimalne varijance.
44
Slika 15. Efikasna granica
(izvor: izradila autorica prema Elton et al 2003)
Očekivani prinos portfelja izražava se kao:
N
R P = ∑ X i Ri
(4.1.)
i =1
varijanca portfelja:
N
N
i =1
i =1
σ P2 = ∑ X i2σ i2 + ∑
N
∑X
j =1
i
X jσ iσ j ρ ij
(4.2.)
pri čemu je:
X i - udio pojedine dionice i u portfelju
Ri - očekivani prinos dionice i
σ i - standardna devijacija dionice i
σ j - standardna devijacija dionice j
ρ ij - koeficijent korelacije.
Za razliku od prinosa portfelja koji predstavlja jednostavnu aritmetičku sredinu prinosa
pojedinih dionica ponderiranih njihovim udjelima, rizik portfelja je kompleksniji. Rizik ovisi
o tome jesu li, i u kojoj mjeri, prinosi dionica međusobno korelirani. Smanjenje rizika dobije
se kad se drži portfelj čije dionice nisu perfektno korelirane.
Ono što predstavlja glavnu ideju diverzifikacije prema MPT, ujedno je i glavni problem za
implementaciju budući da zahtijeva brojene ulazne parametre i izračune. Potrebne ulazne
parametre čine: očekivani prinosi dionica, varijance dionica te korelacije svih mogućih parova
45
dionica u portfelju. Dok varijanci ima koliko i dionica u portfelju, za koeficijente korelacije
potrebno je N(N-1)/2 izračuna (N - broj dionica u portfelju)76. To je potaknulo razvoj modela
koji pokušavaju opisati i predvidjeti korelacijsku strukturu među dionicama. Jedan od takvih
modela je i jednoindeksni model.
4.2. Jednoindeksni model
Kako bi se omogućila praktična primjena MPT modela, krenulo se u analizu odnosa prinosa
pojedinačnih dionica u portfelju i tržišnog portfelja. Sharpe je 1963. osmislio
pojednostavljenje izračuna uočivši da varijacije u prinosima dionica imaju linearnu ovisnost o
faktoru zajedničkom cijelom tržištu i faktorima jedinstvenima za svaku pojedinačnu dionicu.
Faktor zajednički cijelom tržištu predstavlja se tržišnim indeksom. Otuda i naziv Sharpeov
jednoindeksni model odnosno empirijski tržišni model (Amenc & Sourd 2003).
Prinos dionce prema jednoindeksnom modelu izražava se kao:
Ri = α i + β iRm + ei
(4.3)
pri čemu je:
Ri - prinos dionice i
β i - konstanta koja mjeri očekivanu promjenu Ri povezanu sa 1% promjene Rm
Rm - prinos tržišnog indeksa
α i i ei - čine dio prinosa dionice neovisan o tržištu
α i - očekivana vrijednost
ei - slučajna (neočekivana) vrijednost – specifični prinos.
Beta koeficijent izražava se kao:
β i=
σ im
σ m2
(4.4.)
pri čemu je:
β i - beta koeficijent dionice i
σ im - kovarijanca dionice i i tržišnog indeksa
76
Za portfelj od 50 dionica, što se smatra dobro diverzificiranim portfeljem, potrebno je 50*49/2 koeficijenata
korelacije = 1225 izračuna.
46
σ m2 - varijanca tržišnog indeksa.
Očekivani prinos dionice:
R i = α i + β iRm
(4.5.)
pri čemu je:
Rm - očekivani prinos tržišnog indeksa.
Varijanca dionice:
σ i2 = β i2σ m2 + σ ei2
(4.6.)
pri čemu je:
σ ei2 - rezidualni rizik koji je moguće diverzificirati.
Kovarijanca dionica i i j:
σ ij = βi β jσ m2
i≠ j
(4.7.)
Osnovna pretpostavka modela sastoji se u tome da je rezidual ei nezavisan od e j za svaku
vrijednost i i j što implicira da je jedini razlog zbog kojeg se dionice kreću zajedno, njihovo
zajedničko kretanje sa tržištem. Za razliku od očekivanog prinosa i varijance dionice koji se
sastoje od dijela ovisnog o tržištu i drugog, jedinstvenog za svaku dionicu, kovarijanca ovisi
samo o tržišnom riziku (Elton et al 2003). Ovom pretpostavkom omogućeno je
pojednostavljenje izračuna.
Uvrštavanjem (4.5.) u (4.1.) očekivani prinos portfelja može se izraziti kao:
N
N
i =1
i =1
R p = ∑ X i α i + ∑ X i β i Rm
(4.8.)
Uvrštavanjem (4.6.) i (4.7.) u (4.2.) varijanca portfelja može se izraziti kao:
N
N
i =1
i =1
σ P2 = ∑ X i2 β i2σ m2 + ∑
N
N
j =1
i =1
∑ X i X jσ iσ j βi β jσ m2 + ∑ X i2σ ei2
47
(4.9.)
Iz gornjeg je vidljivo drastično pojednostavljenje izračuna varijance portfelja budući da je sad
on moguć sa samo 3N+1 izračuna (očekivani prinos svake dionice, varijanca svake dionice,
beta koeficijent svake dionice i varijanca prinosa tržišta).
Beta koeficijent portfelja može se izraziti kao:
N
β p = ∑ X i βi
(4.10.)
i =1
alfa portfelja:
N
α p = ∑ X iα i
(4.11.)
i =1
tad se (4.8) može napisati kao:
R p = α p + β p Rm
(4.12.)
a nakon sređivanja (4.9.) dobije se:
N
σ p2 = β p2σ m2 + ∑ X i2σ ei2
(4.13.)
i =1
4.3. Elton-Gruber metoda konstruiranja optimalnog portfelja
Elton i Gruber predložili su metodu konstruiranja optimalnog portfelja koja za bazu koristi
jednoindeksni model dajući rezultat jednak kvadratnom programiranju (Elton et al 2003).
Metoda se sastoji od rangiranja dionica prema određenom kriteriju, utvrđivanja granice koja
razdvaja dionice koje će biti uključene u portfelj i one koje to neće biti, te utvrđivanja udjela
odabranih dionica u optimalnom portfelju.
Kriterij prema kojem se vrši rangiranje dionica predstavljen je viškom prinosa iznad
bezrizičnog po jedinici sistemskog rizika, odnosno:
Ri − RF
(4.14.)
βi
48
pri čemu je:
Ri - očekivani prinos dionice i
RF - prinos bezrizičnog vrijednosnog papria
βi - beta koeficijent dionice i.
Omjer se računa za sve dionice koje su investitoru raspoložive za odabir. Razultati se
rangiraju od najvećeg prema najmanjem – što je omjer veći to je poželjniji. Kao rezultat toga,
ako se neka dionica drži u portfelju, onda se i sve rangirane iznad nje također drže u portfelju.
*
Granica C za odabir dionica koje će sačinjavati optimalni portfelj
određuje se prema
formuli:
i
σ m2 ∑
Ci =
( R j − RF ) β j
σ ej2
i β2
2
1 + σ m ∑ 2j
j =1 σ ej
j =1
(4.15.)
Dionice se prestaju dodavati u portfelj kada je omjer (4.14.) kandidat dionice niži od Ci .
(Ovo vrijedi za slučaj kad nije dopuštena kratka prodaja77. U slučaju da je dopuštena kratka
prodaja, postupak se ponešto razlikuje.)
Udjeli se određuju prema:
Xi =
Zi
∑Z
j∈ P
(4.16.)
j
gdje je:
Zi =
βi Ri − RF
(
− C* )
2
σ ei
βi
(4.17.)
77
Kratka prodaja je špekulativna operacija kojom investitor, u očekivanju pada cijene, posuđuje dionice ili neki
drugi vrijednosni papir koje prodaje sada a kasnije ponovno otkupljuje s namjerom da ih vrati. Ako je u
međuvremenu doista došlo do očekivanog pada cijene, investitor je zaradio na razlici u cijeni.
49
5. Proces izrade prototipa web aplikacije za upravljanje
portfeljem
5.1. Planiranje i utvrđivanje zahtjeva
5.1.1. Pozadina projekta
PrimaInvest je imaginarna brokerska kuća koja s ciljem povećanja zadovoljstva svojih
klijenata namjerava uvesti novu uslugu samostalnog upravljanja portfeljem vrijednosnih
papira. Analizom tržišta ustanovljeno je da postoji znatan broj potencijalnih malih investitora
koji se zbog nedovoljne upućenosti u funkcioniranje financijskih tržišta suzdržavaju od
investiranja na tržištima kapitala smatrajući to prevelikim rizikom.
5.1.2. Opis projekta
U vidu realizacije nove usluge uspostavit će se web sjedište putem kojega će korisnicima biti
dostupna aplikacija za upravljanje portfeljem. Aplikacija će korisnicima omogućiti uvid u
trgovanje vrijednosnim papirima, kreiranje portfelja, praćenje performansi te izdavanje naloga
za kupnju ili prodaju dionica. Također će pružati pomoć prilikom sastavljanja optimalnog
portfelja. Realizacija projekta trebala bi pridonijeti kako privlačenju novih, tako i povećanju
aktivnosti postojećih korisnika.
5.1.3. Poslovni model
Usluga će biti dostupna registriranim korinicima uz mjesečnu naknadu, te će se nuditi u
nekoliko modaliteta pretplate.
5.1.4. Pokazatelji uspjeha
Pokazatelji poslovnog uspjeha
•
povećanje broja malih investitora za 15% u roku 12 mjeseci
•
povećanje broja transkacija za 30% u roku 12 mjeseci
•
povećanje prosječne vrijednosti transkakcije za 10% u roku 6 mjeseci
Pokazatelji uspjeha projekta
•
broj registriranih korisnika nakon 6 mjeseci min. 500
•
rast broja registriranih korinika za 3% mjesečno narednih godinu dana
50
•
broj pretplaćenih korisnika nakon 6 mjeseci min. 150
•
rast broja pretplaćenih korisnika za 2% mjesečno narednih godinu dana
•
broj izdanih naloga putem aplikacije u roku 6 mjeseci izosi 15% nasptam ostalih
naloga
5.1.5. Ciljni korisnici
•
pojednicni zainteresirani za ulaganja na tržištima kapitala
•
korisnici modernih tehnologija i dinamičnog životnog stila
•
osobe nesklone riziku koje žele imati potpunu kontrolu nad svojim ulaganjima
Slika 16. Primjer opisa tipičnog korisnika - personas
(izvor: izradila autorica)
5.1.7. Zahtjevi
Kao pomoć prilikom utvrđivanja funkcionalnih zahtjeva s aspekta korisnika izrađeni su UML
dijagrami slučajeva korištenja78 (eng. Use Case Diagram). Web aplikacija predviđa tri tipa
korisnika (registrirani korisnik, pretplatnik, administrator) te se zahtjevi aplikacije mogu
grupirati na:
78
•
upravljanje korisnicima
•
upravljanje portfeljem
UML slučaj korištenja (eng. use case) je skup scenarija povezanih jednim ciljem korisnika.
51
•
administraciju.
Slika 17. Dijagram slučajeva korištenja pretplatnika
(izvor: izradila autorica)
Budući da prototip implemenitra samo dio povezan sa upravljanjem portfeljem, to osnovne
zahtjeve čine:
1. pregledavanje podataka o trgovanju dionica
2. kreiranje/brisanje portfelja
3. dodavanje/brisanje/izmjenu dionica u portfelju
4. izračunavanje pokazatelja performasni portfelja i donica
5. izračunavanje optimalnog portfelja
6. grafički prikaz kretanja cijena dionica, strukture portfelja, usporedbe pokazatelja
7. otvaranje/zatvaranje računa
8. uplatu/isplatu na/sa računa
52
9. otvaranje/izvršavanje/opoziv naloga za kupnju/prodaju dionica
10. otvaranje/izvršavanje/opoziv naloga za podešavanje strukture portfelja
11. usporedba portfelja
12. usporedba dionica.
Na slici 17. prikazan je UML dijagram slučajeva korištenja koji prikazuje ponašanje i
funkcionalnost sustava sa stajališta pretplatnika (nakon izvršene prijeve na sustav). Detaljan
opis korištenja aplikacije dan je u 6. poglavlju pa se ovdje neće dodatno opisivati.
5.1.8. Arhitektura
Aplikacija implementira troslojnu arhitekturu koja se, gledano s aspekta logičkih slojeva,
sastoji od:
•
Prezentacijskog sloja temeljenog na klijenstkim tehnologijama – HTML, CSS,
JavaScript te korištenju KendoUI frameworka i jQuery biblioteke.
•
Aplikacijskog sloja koji ima funkcionalnost ograničenu na preuzimanje zahtjeva
prezentacijskog sloja, validaciju inputa, autorizaciju te vraćanje rezultata u
odgovarajućem formatu. Srednji sloj koristi PHP jezik za server-side programiranje.
•
Podatkovnog sloja koji koristi MySQL SUBP i uskladištene procedure za pristup
podacima.
5.2. Dizajn
5.2.1. Konceptualni model podataka
Na temelju zahtjeva identificirani su osnovni entiteti te je izrađen početni model entiteti-veze
prikazan na slici 18.
Posjetitelj se može registrirati i tad postaje KORISNIK. KORISNIK može biti OBIČNI (to su
svi registrirani posjetitelji) ili ADMINISTRATOR (osoba zadužena za održavanje aplikacije)
– ekskluzivna specijalizacija KORISNIKA.
OBIČNI KORISNIK može se pretplatiti i tad postaje PRETPLATNIK. PRETPLATNIK mora
imati barem jednu PRETPLATU (ali može ih imati više jer će se u sustavu čuvati podaci i o
53
proteklim
pretplatama).
Svaka
se
PRETPLATA
odnosi
na
točno
određenog
PRETPLATNIKA.
Slika 18. Početni model eniteti-veze
(izvor: izradila autorica)
PRETPLATNIK može kreirati PORTFELJE, a svaki PORTFELJ priprada točno određenom
PRETPLATNIKU. PORTFELJ može biti prazan ili sadržavati DIONICE a svaka se
DIONICA može nalaziti u više PORTFELJA. Ovdje se radi o vezi M:M koja je razriješena
dodatnim entitetom PORTFELJ_DIONICA.
PRETPLATNIK za svaku PORTFELJ_DIONICU može izdati više NALOGA koji mogu biti
za KUPNJU ili PRODAJU (ekskluzivna specijalizacija). Svaki izvršeni NALOG registrira se
dodatno kao TRANSAKCIJA budući da se NALOG odonosi na promjene količine
PORTFELJ_DIONICE a TRANSKACIJE na promjene stanja RAČUNA.
PRETPLATNIK može otvoriti RAČUN. PRETPLATNIK može imati samo jedan RAČUN a
svaki RAČUN pripada samo jednom PRETPLATNIKU. Za svaki RAČUN registriraju se
54
TRANSKACIJE koje mogu biti UPLATA, ISPLATA ili NALOG_IZVRŠAVANJE
(ekskkluzivna specijalizacija).
Za svaku DIONICU registrira se PROMET. Svaki podatak o trgovanju odnosi se na točno
određenu DIONICU. Svaka DIONICA pripada određenom SEKTORU, ali SEKTOR ne mora
sadržavati DIONICE.
5.2.2. Wireframe modeli
Kao pomoć prilikom razrade modela podataka, te strukturiranja informacija, dizajna
navigacije i interakcije izrađeni su wireframe modeli.
Na slici 19. prikazan je primjer početnog prikaza (eng. screen) aplikacije korisnika koji već
ima kreirane portfelje sa detaljnim prikazom sastava jednog potrfelja. Iz modela je vidljivo da
su informacije strukturirane kroz nekoliko razina pri čemu osnovnu podjelu čini razlikovanje
grafičkih i tekstualnih informacija, dok daljnju razradu predstavlja podjela na one koje će biti
dostupne korisniku odmah pri pokretanju aplikacije i one koje će se prikazivati na zahtjev.
Budući da je većina financijskih informacija zapravo numeričkog karaktera, takve se
informacije najbolje razumijevaju pomoću vizualizacija. Zbog toga je odlučeno da grafovi
zauzmu dominantnu poziciju u prikazu. Što se tiče ostalih informacija, pretpostavka je da će
korisnika najviše zanimati stanje kreiranih portfelja na određen dan, te će se upravo takve
informacije prikazivati prilikom pokretanja aplikacije. Informacije o performansama portfelja
predstavljaju ujedno i potrebne atribute79 za entitet PORTFELJ:
79
Zajedno sa atributima utvrđene su i njihove derivacijske formule:
Portfelj:
količina dionica = suma količine svih dionica u portfelju
ulog = suma uloga u sve dionice u portfelju
vrijednost portfelja = suma umnoška zadnje cijene i količine svih dionica u portfelju
promjena = (vrijednost portfelja – ulog)/ulog*100
očekivani prinos = vidi (4.1.)
beta = vidi (4.10.)
varijanca = vidi (4.13.)
standardna devijacija =
var
Portfelj_dionica:
ulog = količina * prosječna kupovna cijena
prosječna kupovna cijena =
P1 * Q1 + P2 * Q2 + .... + Pn * Qn
Q1 + Q2 + ... + Qn
55
Slika 19. Wireframe model
(izvor: izradila autorica)
1. naziv, opis, datum kreiranja, datum izmjene, broj dionica u portfelju, ukupna količina
dionica, ulog, vrijednost, promjena, očekivani prinos, beta, varijanca, standardna
devijacija80
Sljedeću razinu predstavljaju informacije o sastavu portfelja odnosno o svakoj pojedinačnoj
PORTFELJ_DIONICI te se one prikazuju na zahtjev korisnika:
2. simbol, ulog, količina, prosječna kupovna cijena, stavrni udio, ciljni udio, datum
dodavanja, datum izmjene.
pri čemu je
P = kupovna cijena
Q = kupovna količina
stvarni udio = (zadnja cijena * količina ) / vrijednost portfelja *100
ciljni udio postavlja korisnik proizvoljno ili aplikacija prilikom izračunavanja optimalnog portfelja prema
jednoindeksnom modelu
80
Kurzivom su označeni atributi koji se zapravo ne pohranjuju u bazi već se samo izračunavaju i prikazuju.
56
Treću razinu predstavljaju opće informacije o DIONICI kojima je moguće pristupiti tek po
prikazivanju prethodnih informacija. Atribute DIONICE čine:
3. simbol, izdavatelj, broj izdanih, datum uvrštenja, nominala, sektor.
Što se tiče grafova, u početnom prikazu vidljivo je kretanje indeksa Crobex (za prikaz općeg
trenda na burzi), a na zahtjev korisnika prikazuju se grafovi strukture portfelja i/ili kretanja
cijena dionica. Ostale informacije (o nalozima, računu, transakcijama) dostupne su putem
izbornika.
Slika 20. Izgled gotovog sučelja
(izvor: izradila autorica)
Slika 20. prikazuje izgled gotove stranice izrađene prema prethodnom wireframe modelu.
57
5.2.3. Relacijski model podataka
Nakon razrade wireframe modela i početnog modela eniteti-veze, izrađen je logički model
podataka koji je prikazan na slici 21. Model je izrađen alatom "MySQL Workbench" koji
omogućava direktnu implementaciju (opcija "Forward Engineer"). U odnosu na početni
model entiteti-veze, ovdje su razriješene specijalizacije/generalizacije, veze M:M, određeni su
tipovi podataka za atribute i njihove domene, postavljena su NOT NULL ograničenja (plava
oznaka) na obavezne atribute i ograničenja UNIQUE na atribute ili kombinacije atributa za
koje se traži jedinstvenost (a koji nisu odabrani za primarni ključ), određeni su primarni
ključevi (žuta boja) i vanjski ključevi (crvena boja) te je model najprije normaliziran u 3NF a
zatim i denormaliziran. Također su dodana i ograničenja održavanja referencijalnog
integriteta vanjskih ključeva kod izmjene/brisanja, te su određeni početni indeksi.
Slijedi opis razrade modela:
U konačnom modelu specijalizacija korisnika riješena je dodatnom tablicom. Premda u
slučaju specijalizacije običnog korisnika na pretplatnika to nije bilo nužno, već se moglo
riješiti smještanjem svih atributa odnosno stupaca u jednu tablicu, zbog pretpostavke da će
ipak biti znatno više korisnika od pretplatnika, a da bi se izbjegle brojne nul vrijednosti do
kojih bi došlo jer se za pretplatnika bilježe dodatni podaci, ipak je uvedena nova tablica
pretplatnik.
Tablica nalog_izvršeni također je uvedena radi izbjegavanja nul vrijednosti. Kako
je
potrebno zadržati vezu između transakcije i naloga čije se izvršavanje registrira kao
transakcija, to se moglo realizirati dodatnim stupcem (id_nalog) u tablici transakcija. No
kako svaka transakcija nije izvršavanje naloga, to bi dovelo do pojave nul vrijednosti koje je
bolje izbjegavati. Osim toga, ovakvo rješenje omogućava dodatnu evidenciju specifičnu samo
za izvršene naloge.
58
Slika 21. Relacijski model podataka
(izvor: izradila autorica)
59
Atributima su određeni tipovi podataka i domene, postavljena su ograničenja NOT NULL na
gotovo sve atribute, a ujedno su im određene pretpostavljene ili standardne vrijednosti
(default) tamo gdje je to imalo smisla. Problem određivanja pretpostavljenih vrijednosti
predstavljaju npr. numerički podaci koji mogu poprimiti vrijednost od minus beskonačno do
plus beskonačno (prinos može biti negativan, 0 ili pozitivan). U takvom bi se slučaju moglo
signalizirati da nedostaje podatak nekom pretjeranom i teško mogućom vrijednošću poput
-99999999, međutim preporuka (Schwartz et al. 2008) je da se izbjegavaju takvi besmisleni
podaci jer mogu stvoriti više problema nego koristi.
Kod određivanja tipa podataka potrebno je uzeti u obzir i namjenu aplikacije. Budući da je
kod financijskih aplikacija izuzetno važna preciznost, za podatke koji predstavljaju realne
brojeve potrebno je koristiti tip DECIMAL (koji spada u precizne tipove podataka za koje se
primjenjuje računanje sa fiksnim zarezom) a nikako aproksimativne tipove poput FLOAT ili
DOUBLE za koje se primjenjuje računanje sa pomičnim zarezom dajući nepredvidive
rezultate (npr. dok kod tipa DECIMAL 0.1+0.2 daju uvijek rezultat 0.3, kod tipa FLOAT
0.1+0.2 daje rezultat 0.30000000149011613).
Stupcima ili kombinacijama stupaca čije vrijednosti moraju biti jedinstvene na razini tablice
dodano je ograničenje UNIQUE. Npr. e-mail adresa mora biti jedinstvena na razini tablice
korisnik jer će poslužiti za idetifikaciju korisnika, dok naziv portfelja mora biti jedinstven na
razini jednog korisnika te je ograničenje UNIQUE postavljeno na kombinaciju id_korisnik i
naziv u tablici portfelj.
Tablicama su određeni primarni ključevi, pri čemu je donesena odluka o korištenju surogat
ključeva (nazvanih id_imetablice) u kombinaciji sa mogućnošću koju nudi SUBP da se za
jedan stupac tablice odredi tip INT (integer) sa svojstvom AUTO_INCREMENT. To znači da
se, počevši od 1, njegova vrijednost povećava za 1 pri svakom unosu novog retka. Time se
osigurava jednoznačna identifikacija svakog retka, a kako ujedno nema nikakvog dodatnog
značenja, nije podložan eventualnim izmjenana kao što je to slučaj kod korištenja prirodnih
ključeva81. Korištenje surogat ključeva također olakšava i primjenu indeksa budući da su takvi
81
Prirodni ključevi – npr. JMBG ili OIB jednoznačno identificiraju osobu pa se mogu koristiti kao primarni
ključevi (premda to nije preporučljivo).
60
indeksi manji nego u slučaju kompozitnih ključeva82 (u indeks je uključen čitav primarni
ključ) a također olakšava i primjenu vanjskih ključeva.
Radi održavanja referencijalnog integriteta u tablice su uvedeni vanjski ključevi (u protivnom
bi to trebalo osigurati putem aplikacije) na način da su u vezama 1:M primarni ključevi tablica
na strani 1 uvedeni kao strani ključevi u tablice na strani M (npr. primarni ključ tablice
korisnik_tip id_korisnik_tip uveden je kao vanjski ključ u tablicu korisnik). U vezama 0:1
vanjski ključ je uveden u tablicu na strani 0 (npr. id_korisnik je uveden u tablicu racun kao
vanjski ključ).
Uz vanjske ključeve određene su i akcije koje će primijeniti prilikom brisanja ili izmjene
"roditelja" ili "djeteta": za slučaj brisanja postavljeno je ograničenje ON DELETE
RESTRICT što znači da se ne može obrisati "roditelj" prije nego se obrišu sva "djeca" (odbija
se brisanje sve dok potoji n-torka koja ima vanjski ključ sa tom vrijednošću) a za slučaj
izmjene ON UPDATE CASCADE što znači da izmjena "roditelja" dovodi do kaskadnog
mijenjaja"djece" (mijenja se n-torka sa primarnim ključem i sve n-torke koje imaju strani
ključ sa tom vrijednošću).
Shema je najprije normalizirana u 3NF, a zatim i denormalizirana uvođenjem deriviranih
atributa83. Kod utvrđivanja atributa bilo je potrebno odlučiti da li će se i koji će se derivirani
atributi doista pohranjivati u bazi, a što će se izračunavati za potrebe prikaza na zahtjev
korisnika. Premda u potpuno normaliziranoj shemi
nema deriviranih atributa jer to
predstavlja redundanciju te odstupanje od 3NF uvođenjem funkcijskih zavisnosti84 , ovdje je
u nekoliko slučajeva odstupljeno do tog pravila jer bi neki izračuni znatno usporili aplikaciju.
Tako su uvedene tablice dionica_izracun i indeks_izracun te je tablici racun dodan stupac
saldo jer je pretpostavka da će tablica transakcija biti jako prometna, te bi konstantno
preračunavanje predstavljalo nepotrebno opterećenje za aplikaciju (iako bi se zapravo
opravdanost ovakve odluke mogla utvrditi tek po izračunavanju troška izmjene dodatne
tablice i troška preračunavanja prilikom stvarnog korištenja baze).
82
Kompozitni ključevi – sastoje se od dva ili više stupaca koji su i sami ključevi (npr. id_nalog i id_transakcija
u tablici nalog_izvrseni), za razliku od složenih ključeva koji se sastoje od dva ili više stupaca koji nisu ključevi
(npr. ime i prezime iako to ne bi bio dobar primarni ključ).
83
Derivirani (izvedeni) atributi izračunavaju se na temelju podataka u stupacima iste ili neke druge tablice.
84
Ako su X i Y skupovi atributa relacije R, relacija R zadovoljava uvjete funkcijske zavisnosti X Y ako u
svakom trenutku za svaku X-vrijednost x postoji samo jedna Y-vrijednost y (Varga 1994).
61
Premda se optimalni indeksi mogu utvrditi tek nakon određenog vremena korišenja baze u
stvarnim uvjetima, za početak su kreirani indeksi koje alat automatski generira i to indeksi za
primarne ključeve, vanjske ključeve i UNIQUE indeksi.
Primjer SQL DDL naredbe za kreiranje tablice portfelj:
CREATE TABLE `portfelj` (
`id_portfelj` int(10) unsigned NOT NULL AUTO_INCREMENT,
`naziv` varchar(20) COLLATE utf8_slovenian_ci NOT NULL DEFAULT 'Portfelj_01',
`datum_start` datetime NOT NULL,
`datum_izmjena` datetime NOT NULL,
`opis` varchar(200) COLLATE utf8_slovenian_ci DEFAULT NULL,
`id_korisnik` int(10) unsigned NOT NULL,
PRIMARY KEY (`id_portfelj`),
UNIQUE KEY `id_korisnik_naziv_UNIQUE` (`naziv`,`id_korisnik`),
KEY `fk_portfelj_pretplatnik1` (`id_korisnik`),
CONSTRAINT
`fk_portfelj_pretplatnik1`
FOREIGN
KEY
(`id_korisnik`)
REFERENCES
`pretplatnik` (`id_korisnik`) ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_slovenian_ci
Kreiranje tablice započinje naredbom
CREATE
TABLE
iza koje se navodi ime tablice
(`portfelj`) te nazivi stupaca zajedno sa tipom podataka i eventualnim
NOT
NULL
ograničenjem i pretpostavljenom vrijednošću. Za stupce znakovnog tipa ( u primjeru varchar)
navedeno je i po kojem će se pravilu vršiti usporedba znakova (utf8_slovenian_ci) što je
bitno prilikom sortiranja. Nakon navođenja stupaca, određeni su primarni, jedinstveni i
vanjski ključevi, te je odabran stroj za skladištenje (InnoDB).
5.2.4. Grafički dizajn
5.2.4.1. Raspored elemenata
S obzirom na namjenu aplikacije, primijenjen je tradicionalni linearni raspored elemenata. U
gornjem dijelu nalazi se logotip zajedno sa primarnom navigacijom koji zadržavaju jednaku
poziciju na svim stranicama i unutar aplikacije. Srednji dio namijenjen je za grafičke prikaze
dok se preostali sadržaj nalazi u donjem dijelu.
5.2.4.2. Tipografija
Odabrani su sans-serif fontovi budući da su čitljiviji i djeluju neutralnije.
62
5.2.4.3. Paleta boja
Budući da logo sadrži jake boje na bijeloj podlozi, kao kontrast je odabrana tamna podloga u
sivim tonovima kako bi aplikacija djelovala suzdržanije i ozbiljnije, te kako suvišno šarenilo
ne bi odvlačilo korisnike od ispunjavanja osnovnih zadataka. Za akcente su odabrane boje iz
logotipa tvrtke ili one sličnog intenziteta.
Fotografije i ostala multimedija su izbjegnuti, premda bi se u razradi dizajna mogle uvrstiti
ikone koje bi korisnicima sugerirale radnje i zadatke koje mogu izvršiti pomoću aplikacije.
5.2.5. Navigacija
Navigacija web sjedišta podijeljena je na primarnu i sekundarnu (lokalnu) te je korišteno
nekoliko različitih navigacijskih mehanizama.
Primarnu navigaciju čini izbornik na vrhu stranice (slika 22.) kojim je omogućeno kretanje
između različitih tematskih stranica (Početna, O nama, Upravljanje portfeljem, Pretplata,
Kontakt). Lokalnu navigaciju (slika 23.) čini navigacija unutar aplikacije za odabir različitih
grupa opcija upravljanja portfeljem (Portfelji, Napravi novi, Izmijeni, Usporedi, Izračunaj
optimalni, Nalozi, Račun, Dionice).
Za oba tipa navigacije odabrana je horizontalna orijentacija zbog zahtjeva da aplikacija bude
"rastezljiva" odnosno da se prilagođava različitim rezolucijama. U slučaju vertikalne
navigacije dio širine otpadao bi na izbornike te bi se smanjila mogućnost korištenja na
manjim rezolucijama (iako je i to moguće prilagoditi pomoću CSS-a).
Aktivni elementi istaknuti su različitom bojom kako bi signalizirali korisniku gdje se nalazi.
Kod primarne navigacije je to učinjeno svijetlo sivom pozadinom (za razliku od neaktivnih
elemenata sa tamno sivom pozadinom) dok su kod sekundarne navigacije aktivni elementi
istaknuti bijelim slovima (za razliku od neaktivnih sivih).
63
Slika 22. Primarna navigacija i logotip kao navigacijski element
(izvor: izradila autorica)
Slika 23. Lokalna navigacija
(izvor: izradila autorica)
Temeljne navigacijske mehanizme korištene u aplikaciji čine:
1. horizonatlni izbornik za primarnu navigaciju (slika 22.).
2. tabovi za lokalnu navigaciju unutar aplikacije (slika 23.)
3. stablasti kod tablica za prikazivanje hijerarhije (slika 24. i slika 25.)
4. straničenje u kombinaciji sa "premotavanjem"
i direktnim pristupom odabranoj
stranici (slika 26.).
Slika 24. Stablasti navigacijski mehanizam - zatvoren
(izvor: izradila autorica)
64
Slika 25. Stablasti navigacijski mehanizam - otvoren
(izvor: izradila autorica)
Slika 26. Straničenje sa premotavanjem i direktnim pristupom stranici
(izvor: izradila autorica)
5.2.6. Interakcija
Na primjeru procesa "kupiti dionicu", odnosno njegovog dijela "izvršiti nalog", bit će
objašnjeni principi dizajna interakcije:
65
Cilj korisnika je izvršiti otvoreni nalog. Korisnik pronalazi naloge na tabu "Nalozi" čime je
definiran prostor unutar kojeg će se odvijati interakcija. Gumbi pored svakog naloga
omogućavaju korisniku da izvrši određenu akciju – izvršavanje naloga ili njegov opoziv – te
oni predstavljaju element koji omogućava interakciju. Klikom na gumb "Izvrši nalog" otvara
se prozor kojim se najprije provjerava je li korisnik doista zatražio izvršavanje (što je ujedno i
u skladu sa zahtjevom upotrebljivosti za sigurnošću). Nakon potvrde korisnika pokreće se
proces izvršavanja naloga na strani aplikacije.
Slika 27. Uspostavljanje dijaloga sa korisnikom
(izvor: izradila autorica)
Aplikacija prije samog izvršavanja naloga obavlja niz provjera pri čemu je bitno pružiti
korisniku povratnu informaciju o uspjehu ili neuspjehu izvršavanja određene akcije te razloga
eventualnog neuspjeha. U slučaju nastupanja bilo kakve okolnosti koja skreće normalni tijek
izvođenja, potrebno je korisnika upozoriti te mu ostaviti mogućnost odluke o nastavku tijeka.
Ovakvom razmjenom poruka ostvaruje se dijalog između korisnika i sustava što je temeljni
cilj interakcije. Loš primjer bio bi izvršavanje naloga bez ikakve povratne poruke. Premda bi
u ovakvom slučaju temeljna funkcionalnost i dalje bila omogućena, iskustvo korisnika s
takvom aplikacijom bilo bi prilično frustruirajuće.
Osim uspostavljanja dijaloga, važan element interakcije čini i vrijeme, odnosno responzivnost
aplikacije. Premda se kraće vrijeme između pojedine akcije korisnika i odgovora aplikacije
postiže upotrebom AJAX tehnologija, nerealno je očekivati da će to biti trenutno, tako da je
korisniku potrebno pružiti vizulani i/ili auditivni signal napretka i završetka operacije (slika
28.).
66
Slika 28. Signaliziranje napretka izvršavanja određene akcije
(izvor: izradila autorica)
5.3. Implementacija
Implementacija aplikacije bit će prikazana u dva dijela. Najprije će se na primjeru izrade
horizontalnog izbornika prikazati kako se slojevitom primjenom klijentskih tehnologija (CSSa i JavaScript-a) strukturni elementi HTML dokumenta transformiraju u dijelove sučelja, a
zatim će biti prikazana implementacija jedne funkcionalnosti kroz sva tri sloja na primjeru
izvršavanja naloga (premda u ponešto pojednostavljenom obliku).
5.3.1. Implementacija sučelja
Na slici 29. prikazana je temeljna struktura jedne stranice definirana samo upotrebom HTMLa. Unutar crvenog okvira nalazi se lista koja će se uz pomoć CSS-a pretvoriti u horizontalni
izbornik.
HTML kod kojim se definira lista poveznica:
<ul id="menu">
<li><a href="index.php">Početna</a></li>
<li><a href="info.php">O nama</a></li>
<li class="selected"><a href="portfelji.php">Upravljanje portfeljem</a></li>
<li><a href="pretplata.php">Pretplata</a></li>
<li><a href="kontakt.php">Kontakt<a/></li>
</ul>
67
<ul> tag označava listu (eng. unordered list), čiji se pojedini elementi označavaju sa <li>
tagom (eng. list item). Unutar svakog elementa liste nalazi se poveznica (definirana <a>
tagom) na određenu stranicu i tekst koji se prikazuje kao kategorija izbornika.
Slika 29. Temeljna struktura stranice
(izvor: izradila autorica)
Na slici 30. prikazana je ista stranica kao u gornjem primjeru, ali sa primijenjenim stilovima
za tipografiju i pozicioniranje, dok je na sljedećoj slici 31. prikazana gotova stranica sa
dodatnim stilovima za boje i pozadine.
68
Slika 30. Izgled stranice nakon primjene stilova za tipografiju i pozicioniranje
(izvor: izradila autorica)
Slika 31. Izgled gotovog sučelja
(izvor: izradila autorica)
69
Na slici 30. vidljivo je da je lista pretvorena u horizontalni izbornik. Najosnovniji oblik CSS
koda za takvu transformaciju je:
ul{
list-style-type:none;
}
li{
float:left;
}
Najprije se uklanjaju kružići ispred elemenata liste, a zatim se elementi slažu horizontalno.
Primjenom dodatnih stilova moguće je precizno definirati izgled izbornika. Budući da je za
izradu sučelja korišten KendoUI framework, transformacija je zapravo izvršena malo
drugačije. Framework nudi već predefinirane stilove pa je za pretvaranje liste u gotov
izbornik bila dovoljna samo jedna linija koda kojim se element sa vrijednošću id atributa
menu pretvara se u izbornik.
$("#menu").kendoMenu();
5.3.2. Implementacija funkcionalnosti "izvršiti nalog"
U donjem primjeru dana je ponešto skraćena verzija koda kojim se u KendoUI framework-u
određeni HTML element pretvara u tablicu. U ovom slučaju to je element vrijednosti id
atributa
otvoreni_nalozi
u kojem se prikazuju nalozi koje je moguće izvršiti (ili opozvati).
Tablica se puni podacima o nalozima definiranim u izvoru podataka (dataSource)
nalozi_o.
Jedan stupac tablice sadrži gumbe (command) za izvršavanje naloga. Sa svakim gumbom u
tom stupcu povezana je funkcija izvrsi.
KendoUI
$("#otvoreni_nalozi").kendoGrid({
dataSource: nalozi_o,
columns: [
{ field: "broj_naloga", title: "Broj naloga"},
{ field: "tip_naziv",title: "Tip"},
{ field: "simbol",title: "Dionica"},
{ field: "portfelj_naziv", title: "Portfelj"},
{ field: "cijena",title: "Cijena"},
70
{ field: "kolicina", title: "Količina"},
{ field: "datum_start", title: "Datum otvranja"},
{ command: [{name:"izvrsi", text: "Izvrši nalog", click:izvrsi }],title: ""},
{ command: [{name:"opozovi", text: "Opozovi nalog", click:opozovi}], title: ""}
]
});
HTML
<div id="otvoreni_nalozi"></div>
<div id="win_nalog_i"></div>
Slika 32. Otvoreni nalozi
(izvor: izradila autorica)
Klikom na gumb "Izvrši nalog" (slika 32.) poziva se funkcija
izvrsi
koja pronalazi redak
tablice u kojoj se nalazi upravo kliknuti gumb, uzima vrijednost stupca id_nalog u tom retku
te upućuje AJAX zahtjev kojim se poziva php skripta
proslijeđuje vrijednost
id_nalog
korištenjem
POST
izvrsi_nalog.php.
metode. Rezultat ovog poziva prikazuje
se u novom prozoru koji ima vrijednost id atributa win_nalog_i.
function izvrsi(e) {
e.preventDefault();
var dataItem = this.dataItem($(e.currentTarget).closest("tr"));
var wnd = $("#win_nalog_i").kendoWindow({
title: "Nalog",
modal: false,
visible: false,
resizable: true,
width: 275,
content: {
url: "inc/izvrsi_nalog.php",
data: { id_nalog: dataItem.id_nalog },
type: "POST",
}
71
Skripti se
}).data("kendoWindow");
wnd.center().open();
}
PHP
U php skriptu izvrsi_nalog.php najprije se uključuju dodatne skripte za upravljanje greškama
i sa parametrima konekcije. Nakon provjere metode kojom je upućen zahtjev
(if($_SERVER['REQUEST_METHOD']
== 'POST'))
vrši se provjera ima li proslijeđena varijabla
($_POST['id_nalog']) postavljenu vrijednost . Ako ima, vrijednost varijable se sanitizira kako
bi se smanjila mogućnost ubacivanja malicioznog koda i izvršavanja SQL injekcije85. Nakon
toga se uspostavlja konekcija sa bazom i priprema se SQL upit kojim se poziva (CALL)
porcedura
izvrsi_nalog.
U primjeru se koristi prepared statement86 kao dodatna zaštita87
kojim se na pripremljeni predložak upita veže varijabla $id_n. Rezultat izvršavanja procedure
dohvaća se drugim upitom, te se ovisno o vrijednosti statusne varijable ispisuje poruka
korisniku (slika 33.).
<?php
require_once('error_handler.php');
require_once('db_config.php');
if($_SERVER['REQUEST_METHOD'] == 'POST'){
if(isset($_POST['id_nalog'])){
$id_n=filter_var(trim($_POST['id_nalog']), FILTER_SANITIZE_NUMBER_INT);
$link= new mysqli('DB_HOST','DB_USER','DB_PASSWORD', 'DB_DATABASE');
$link->query("SET CHARACTER SET utf8");
$query="CALL izvrsi_nalog(?,@status)";
$stmt=$link->prepare($query);
$stmt->bind_param("i", $id_n);
85
SQL injekcija je tehnika napada koja se sastoji od ubacivanja SQL naredbi i izvršavanja neautoriziranih SQL
upita iskorištavajući neprovjeravanje unosa korisnika.
86
Prepared statements – predstavljaju svojevrsne predloške upita koji se zatim nadopunjuju promjenjivim
parametrima. Glavne prednosti njihove upotrebe sastoje se od :
• ubrzavanja rada - upit je potrebno samo jednom pripemiti a zatim se može izvršavati više puta sa istim
ili različitim parametrim što može znatno ubrzati rad u slučaju kompleksnih upita (izbjegava se
ponavljanje ciklusa analiza/kompajliranje/optimiziranje upita sa svakom promjenom parametra)
• zaštite od SQL injekcije (premda pod određenim okolnostima i dalje ostaje moguća).
87
U ovom slučaju to i nije bilo nužno jer sama procedura predstavlja zaštitu od SQL injekcije budući da se vrši
striktna provjera tipa ulaznog parametra te se sam upit ne mijenja unutar procedure.
72
$stmt->execute();
$stmt->close();
$result=$link->query("SELECT @status AS status");
$row=$result->fetch_object();
$status=$row->status;
$link->close();
$msg="";
if($status==1){
$msg="Transakcija je uspješno izvršena.";
}elseif($status==-1){
$msg="Transakcija nije izvršena.";
}else{
$msg="Greška.";
}
echo "<p><strong>Status: </strong>".$msg."</p>";
}
}
?>
Slika 33. Poruka o izvršenoj transakciji
(izvor: izradila autorica)
MySQL procedura
SET sql_mode=STRICT_TRANS_TABLES;
DROP PROCEDURE IF EXISTS `izvrsi_nalog`;
delimiter $$
CREATE PROCEDURE `izvrsi_nalog`(IN nalog_id INT UNSIGNED, OUT status INT)
MODIFIES SQL DATA
73
BEGIN
DECLARE racun_id INT UNSIGNED;
DECLARE nalog_broj INT UNSIGNED;
DECLARE nalog_cijena DECIMAL(10,2);
DECLARE nalog_kolicina DECIMAL(12,6);
DECLARE nalog_tip CHAR(1);
DECLARE nalog_dionica_id INT UNSIGNED;
DECLARE transakc_id_max INT UNSIGNED;
DECLARE transakc_id INT UNSIGNED;
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
ROLLBACK;
SET status=-1;
END;
######################################
SELECT n.broj_naloga, n.cijena, n.kolicina, n.id_nalog_tip, n.id_portfelj_dionica,
r.id_racun
INTO nalog_broj,nalog_cijena, nalog_kolicina, nalog_tip, nalog_dionica_id,
racun_id
FROM nalog AS n
INNER JOIN portfelj_dionica AS pd ON n.id_portfelj_dionica =
pd.id_portfelj_dionica
INNER JOIN portfelj AS p ON pd.id_portfelj=p.id_portfelj
INNER JOIN racun AS r ON p.id_korisnik=r.id_korisnik
WHERE n.id_nalog=nalog_id;
START TRANSACTION;
SELECT MAX(id_transakcija) INTO transakc_id_max FROM transakcija;
INSERT INTO transakcija (broj_transakcije, datum_start, iznos, opis,
id_transakcija_tip, id_racun)
VALUES (COALESCE(transakc_id_max,0)+100001, NOW(),
nalog_cijena*nalog_kolicina,
CONCAT('izvršenje naloga broj ', nalog_broj), 'n', racun_id);
SET transakc_id=LAST_INSERT_ID();
INSERT INTO nalog_izvrseni (id_nalog, id_transakcija, datum_kraj) VALUES
(nalog_id, transakc_id, NOW());
74
CASE nalog_tip
WHEN 'k' THEN #ako je nalog za kupnju
UPDATE racun SET stanje=stanje-nalog_cijena*nalog_kolicina,
datum_izmjena=NOW() WHERE id_racun=racun_id;
UPDATE portfelj_dionica SET
ulog=ulog+nalog_cijena*nalog_kolicina,
kolicina_ulog=kolicina_ulog+nalog_kolicina,
datum_izmjena=NOW()
WHERE id_portfelj_dionica=nalog_dionica_id;
WHEN 'p' THEN
#ako je nalog za prodaju
UPDATE racun SET stanje=stanje+nalog_cijena*nalog_kolicina,
datum_izmjena=NOW() WHERE id_racun=racun_id;
UPDATE portfelj_dionica SET
ulog=ulog*(1-nalog_kolicina/kolicina_ulog),
kolicina_ulog=kolicina_ulog-nalog_kolicina,
datum_izmjena=NOW()
WHERE id_portfelj_dionica=nalog_dionica_id;
END CASE;
COMMIT;
SET status=1;
END$$
Najprije se sa sql_mode=STRICT_TRANS_TABLES postavlja zahtjev striktne provjere tipa podataka
prilikom izvršavanja procedure.
Procedura se kreira sa
primjeru je to
CREATE PROCEDURE
`izvrsi_nalog`)
naredbom iza koje se navodi naziv procedure (u
te ulazni88 (u primjeru je to
nalog_id),
izlazni89 (u primjeru je
to status) ili ulazno/izlazni90 (u primjeru nema takvih) parametri.Unutar procedure deklariraju
se lokalne varijable91. Iza deklaracije lokalnih varijabli deklariran i način postupanja u slučaju
da dođe do bilo kakve greške (DECLARE
EXIT HANDLER FOR SQLEXCEPTION)
kojim je određeno da
se u tom slučaju prekida izvođenje procedure te se izvršava kod unutar bloka (ROLLBACK;
88
SET
Ulazni parametri – omogućavaju pozivajućem programu proslijeđivanje vrijednosti proceduri, ali izmjene
učinjene u samoj proceduri ne vraćaju se pozivajućem programu. Ispred naziva parametra navodi se oznaka IN
koja se može i izostaviti budući da je to pretpostavljeni (default) način.
89
Izlazni parametri - omogućavaju vraćanje vrijednosti pozivajućem programu. Ispred naziva parametra navodi
se oznaka OUT.
90
Ulazno-izlazni parametri – omogućavaju da se vrijednost proslijedi proceduri, ali i vrati nazad pozivajućem
programu. Ispred naziva parametra navodi se oznaka INOUT.
91
Lokalne varijable – deklariraju se unutar procedure i vidljive su samo unutar bloka unutar kojeg su
deklarirane.
75
status=-1;).
Tim se kodom poništavaju sve izmjene nad tablicama i ujedno se postavlja
vrijednost izlaznog parametra na –1 čime se signalizira pozivajućoj aplikaciji da transakcija
nije uspjela.
Prvim
SELECT
upitom pronalaze se svi podaci potrebni za izvršavanje naloga na temelju
vrijednosti ulaznog parametra nalog_id te se spremaju u lokalne varijable.
Budući da procedura vrši izmjene nad nekoliko tablica, a za koje je bitno da one budu ili u
potpunosti izvršene ili, u slučaju bilo kakve greške, u potpunosti poništene, skupina upita
kojom se vrše izmjene tretira se kao jedna tansakcija92. U standardnom režimu rada MySQL-a
svaki se pojedinačni upit odmah potvrđuje, a da bi se omogućilo ovakvo tretitanje skupine
upita, potrebno je postaviti svojstvo autocommit
na 0 (SET AUTOCOMMIT=0 ) ili
eksplicitno navesti početak transakcije sa START TRANSACTION, te na kraju transakciju i
potvrditi sa COMMIT93 ili poništiti sa ROLLBACK.
Unutar transakcije vrše se izmjene ovisno o tome radi li se o nalogu za kupnju ili prodaju i to
nad nekoliko tablica. U slučaju uspješno izvršene transakcije, izmjene se potvrđuju te se
postavlja vrijednost izlaznog parametra na 1. Ako je transakcija uspješno izvršena, izvršeni
nalog nalazit će se sad na popisu izvršenih naloga.
5.4.Testiranje
Na važnost testiranja ukazat će se kroz primjer testiranja kompatibilnosti web preglednika.
Prikaz apliakcije u web pregledniku Internet Explorer 6 (slika 34.) predstavlja primjer
ekstremne nekompatibilnosti korištenih tehnologija i web preglednika. Budući da KendoUI
92
Transakcija je upit ili skupina upita koji se tretiraju kao nedjeljiva cjelina. Za njih poslužitelj baze podataka
garantira da će biti izvršeni u potpunosti ili uopće neće biti izvršeni. U slučaju bilo kakve greške, izmjene se
poništitavaju kako bi baza ostala u konzistentnom stanju.
Transakcije same po sebi nisu dovolje već je nužno da susatv udovolji ACID testu:
Atomicity (cjelovitost) – transakcija mora funkcionirati kao nedjeljiva cjelina tako da se izvršava u potpunosti ili
se uopće ne izvršava.
Consistency (konzistentnost) – baza podatka mora se uvijek nalaziti u kozistentnom stanju (prelaziti iz jednog
konzistentnog stanja u drugo).
Isolation (izolacija) – rezultati transakcije nisu vidljivi izvan transakcije sve dok se ona ne potvrdi.
Durability (trajnost) – nakon što je transakcija potvrđena, izmjene su trajne.
93
Ovo je tzv. eksplicitni COMMIT za razliku od implicitnog kojim se potvrđuje transakcija bez izdavanja
COMMIT naredbe ( npr. izdavanjem DDL naredbe ili ponovnim navođenjem START TRANSACTION potvrdit
će se transakcija koja je bila u tijeku).
76
framework ne podržava ovu verziju preglednika, elementi sučelja uopće se ne prikazuju tako
da aplikaciju nije moguće koristiti. U produkcijskoj verziji ovakva situacija ne bi bila
prihvatljiva te bi alternativnim pristupom trebalo osigurati barem minimum funkcionalnosti za
korisnike starijih preglednika.
Slika 34. Izgled stranice u web pregledniku Internet Explorer 6
(izvor: izradila autorica)
Slika 35. Izgled stranice u web pregledniku Opera 9
(izvor: izradila autorica)
Manje ekstreman primjer predstavlja prikaz u pregledniku Opera 9 (slika 35.) koji također
nije podržan. U ovom slučaju aplikacija ostaje funkcionalna, ali temeljni problem čini
narušeni izgled sučelja zbog nepodržavanja određenih CSS svojstava, što također nije
prihvatljivo te bi trebalo korigirati primjenom jednog od pristupa navedenih u poglavlju 3.3.1.
77
6. Primjeri korištenja prototipa web aplikacije za upravljanje
portfeljem
6.1. Pregledavanje portfelja i otvaranje naloga
Slika 36. Prikaz portfelja i otvaranja naloga
(izvor: izradila autorica)
Slika 36. prikazuje početni prikaz aplikacije korisnika koji već ima kreirane portfelje.
Pregledavanja portfelja omogućeno je na tabu "Portfelji" (1). Za svaki portfelj prikazuju se
osnovni pokazatelji (2), dok su dodatne informacije i podaci o dionicama u sastavu portfelja
dostupni klikom na strelicu (7). Klikom na "Prikaži graf" (3) prikazuje se graf strukture
portfelja i kretanja cijena dionica (4) u njegovom sastavu za 60 tjedana unazad (to je period za
koji
se
izračunavaju
određeni
pokazatelji).
Moguće
je
otvoriti
nalog
za
kupnju/prodaju/podešavanje strukture portfelja klikom na "Otvori nalog" (5), te se tad u
zasebnom prozoru otvara obrazac za otvaranje naloga (6). Korisniku se prikazuju aktualni
podaci o trgovanju (8).
Na slici 37. prikazani su dodatni podaci o portfelju. Korisniku su na raspolaganju opći podaci
(1) i podaci o dionicama u sastavu portfelja (2). Za svaku dionicu prikazuju se određeni
pokazatelji (3), a klikom na "Info" (4) prikazuju se opći podaci o dionici u zasebnom prozoru
78
(5) ili klikom na "Prikaži graf" (6) prikazuje se graf kretanja cijene odabrane dionice (7). Za
svaku dionicu moguće je otvoriti nalog klikom na "Otvori nalog" (8) pri čemu se otvara
obrazac u zasebnom prozoru (9).
Slika 37. Prikaz dionica u portfelju, dodatnih informacija i otvaranja naloga
(izvor: izradila autorica)
Slika 38. Prikaz izbornika za odabir načina sortiranja i odabira stupaca
(izvor: izradila autorica)
79
Slika 38. prikazuje izbornik koji je dostupan na gotovo svim tablicama. Klikom na strelicu (1)
pored naziva stupca prikazuje se izbornik kojim je omogućen odabir načina sortiranja (2) te
odabir stupaca za prikaz (3).
Pravila:
1. Portfelj ne mora sadržavati dionice.
2. Portfelj može sadržavati kupljene i virtualne dionice94.
3. Otvoriti nalog za portfelj moguće je samo ako porftelj sadrži dionice (bilo kupljene ili
virtualne).
4. Otvaranjem naloga za kupnju/prodaju portfelja, te odabirom raspoređivanja iznosa
prema stvarnim/ciljnim udjelima, otvaraju se pojedinačni nalozi za kupnju/prodaju
dionica uz zadržavanje odabrane strukture portfelja.
5. Otvoriti nalog za prodaju moguće je samo ako postoje doista kupljene dionice u
portfelju (nije dozvoljena kratka prodaja).
6. Otvaranjem naloga za podrešavanje strukture portfelja otvaraju se pojedinačni nalozi
za kupnju/prodaju dionica u sastvau portfelja kako bi se stvarna struktura podesila
pema ciljnoj uz zadržavanje vrijednosti portfelja.
7. Otvoriti nalog za podešavanje strukture portfelja moguće je samo ako postoje doista
kupljene dionice u portfelju.
8. Ako su prilikom otvaranja naloga za podešavanje sturkture portfelja svi ciljni udjeli
postavljeni na nulu, otvorit će se nalozi za prodaju svih dionica iz portfelja.
6.2. Kreiranje novog portfelja
Slika 39. prikazuje opcije za kreiranje novog portfelja koje su dostupne na tabu "Napravi novi
portfelj" (1). Korisnik odabire naziv portfelja (2) i opis (3), te može odmah dodati dionice (4)
(to može i naknadno učitinit opcijama za izmjenu strukture portfelja). Korisniku su na
raspolaganju dodatne informacije o pojedinoj dionici (na slici 39. prikazane u zasebnom
prozoru) klikom na gumb "Info" (5) ili prikaz grafa kretanja cijena dionica klikom na gumb
"Prikaži graf" (6).
94
Kako bi se omogućilo praćenje učinka izmjene strukture portfelja, dopušteno je držanje dionica koje su doista
kupljene (s ulogom) i virtualne (bez uloga). Zbog toga se pravi i razlika u računanju udjela pojedine dionice u
portfelju. Stvarni udjeli računaju se na temelju udjela dionice u vrijednosti portfelja, a ciljni udio korisnik sam
postavlja ili se izračunava kod računanja optimalnog portfelja. Izdavanjem naloga za podešavanje strukture
portfelja moguće je stvarnu strukturu podesiti prema ciljnim udjelima.
80
Slika 39. Kreiranje novog portfelja
(izvor: izradila autorica)
Pravila:
1. Naziv je obavezan, mora sadržavati minimalno 2, a maksimalno 20 znakova i može se
sastojati samo od slova, brojeva i znaka podcrtavanja.
2. Opis nije obavezan, može sadržavati maksimalno 200 znakova.
3. Portfelj ne mora sadržavati dionice.
6.3. Izmjena portfelja
Slika 40. prikazuje opcije izmjene portfelja koje su dostupne na tabu "Izmijeni portfelj" (1). U
gornjem dijelu nalazi se popis svih portfelja korisnika (2). Korisnik može obrisati odabrani
portfelj(3), može izmijeniti naziv i/ili opis (4) ili strukturu portfelja (5). Klik na (4) ili (5)
otvara pristup opcijama za izmjenu.
Slika 40. Izmjena portfelja
(izvor: izradila autorica)
81
a) Izmjena naziva i/ili opisa
Slika 41. prikazuje opcije za izmjenu naziva i/ili opisa portfelja. Odabranom portfelju (1)
naziv (2) i opis (3) mijenjaju se uz ista pravila koja vrijede kao i kod kreiranja portfelja.
Slika 41. Izmjena naziva/opisa portfelja
(izvor: izradila autorica)
b) Izmjena strukture portfelja
Slika 42. prikazuje opcije izmjene strukture portfelja. Za odabrani portfelj (1) prikazuju se
pokazatelji u dva odjeljka (2) i (3) kako bi se mogao pratiti utjecaj izmjena na performanse
portfelja. Portfelju je moguće mijenjati strukturu dodavanjem (12) ili uklanjanjem (9) dionica.
Na raspolaganju su dodatne informacije o dionicama klikom na "Info" (10) i (13) i grafički
prikazi kretanja cijena klikom na "Prikaži graf" (11) i (14). Moguće je mijenjati i ciljne udjele
(7). Izmijenjeni udjeli označeni su crvenom oznakom (8). Nakon učinjenih izmjena moguće
je preračunati (4) pokazatelje da bi se vidio učinak izmjena na performanse portfela. U
odjeljku (2) prikazuju se performanse prije izmjene a u (3) nakon izmjene. Izmjene je moguće
pohraniti (6) ili poništiti (5).
82
Slika 42. Izmjena strukture portfelja
(izvor: izradila autorica)
Pravila:
1. Moguće je obrisati samo prazan portfelj ili onaj koji sadrži samo virtualne dionice.
Brisanje portfelja koji sadrži kupljene dionice moguće je tek nakon prodaje svih
dionica iz portfelja.
2. Iz portfelja moguće je ukloniti samo virtualne dionice (uklanjanje kupljenih obavlja se
prodajom).
3. Zbroj ciljnih udjela mora biti 0 ili 100.
4. Pokazatelji se u odjeljku (2) računaju na temelju kupljenih dionica (ako ih ima) i
stvarnih udjela, a ako se u portfelju nalaze samo virtualne, na temelju ciljnih udjela. U
odjeljku (3) pokazatelji se računaju na temelju ciljnih udjela.
5. U portfelju se dionica može pojaviti samo jednom (nije moguć višestruki prikaz iste
dionice).
83
6.4. Usporedba dionica ili portfelja
Slika 43. Usporedba portfelja
(izvor: izradila autorica)
Slika 43. prikazuje opcije za usporedbu portfelja. Na tabu "Usporedi" (1) dane su opcije za
usporednu odabranih portfelja (2) ili dionica (3).
a) Usporedba portfelja
Za odabrane portfelje (4) prikazuje se tablica sa pokazateljima a moguć je i prkaz grafa
prinos/rizik (5) ili graf cijena i udjela (8) pojedinačnog portfelja. Na grafu (5) dodatno se
prikazuje Crobex indeks (7).
b) Usporedba dionica
Usporedba dionica (prikazana na slici 44.) vrši se jednako kao i usporedba portfelja osim što
je omogućen odabir prikaza 2 vrste grafa (1): očekivani prinos i beta ili standardna devijacija.
84
Moguće je prikazivanje dodatnih informacija o pojedinoj dionici klikom na "Info" (2) te grafa
kretanja cijena pojedine dionice klikom na "Prikaži graf" (3).
Slika 44. Usporedba dionica
(izvor: izradila autorica)
Prvila:
1. Za prikaz mora biti odabran barem 1 portfelj ili dionica.
6.5. Izračunavanje optimalnog portfelja
Opcije za izračunavanje optimalnog portfelja (slika 45.) dostupne su na tabu "Izračunaj
optimalni portfelj" (1). Najprije se određuju parametri za izračun na tabu "Izračun" (2) a
rezultat se prikazuje na tabu "Rezultat" (3). Korisnik može postaviti kriterij likvidnosti (4)
ako želi isključiti dionice slabije likvidnosti. Daljnja restrikcija dionica koje ulaze u izračun
omogućena je odabirom sektora (5). Opis sektora dostupan je klikom na "Prikaži opis
sektora" (7) koji se prikazuje u zasebnom prozoru (8) ili kao tooltip (6).
85
Dionice koje udovoljavaju postavljenim kriterijima prikazuju se u tablici (9) te je korisniku
ostavljena mogućnost da isključi određene dionice iz izračuna (10). Klikom na "Info" (11)
dostupne su dodatne informacije o dionici u zasebno prozoru ili klikom na "Prikaži graf" (12)
graf kretanja cijene dionice. Klikom na "Izračujaj optimalni portfelj" (13) vrši se izračun i
prikazuje rezultat.
Slika 45. Izračunavanje optimalnog portfelja
(izvor: izradila autorica)
Na tabu "Rezultat" (Slika 46.) prikazuje se rezultat izračuna (1) i to usporedno za optimalni
portfelj i indeks Crobex. Struktura optimalnog portfelja prikazuje se u tablici (2). Omogućeno
je prikazivanje dvije vrste grafova (3): strukture optimalnog portfelja i kretanja cijena dionica
u njegovom sastavu za razdoblje izračuna (prikazano na slici 46.) te graf usporedbe prinosa i
rizika za optimalni portfelj i indeks Crobex (prikazano na slici 47.). Optimalni portfelj
moguće je spremiti klikom na "Spremi portfelj" (4). Moguće je dobiti i dodatne informacije o
dionici klikom n "Info" (5) ili grafički prikaz kretanja cijene dionice klikom na "Prikaži graf"
(6).
86
Slika 46. Rezultat izračuna optimalnog portfelja
(izvor: izradila autorica)
Slika 47. Graf prinos/rizik
(izvor: izradila autorica)
Pravila:
1. Kriterij likvidnosti u rasponu od 0 do 100 računa se na temelju broje dana trgovanja
određenom dionicom u odnosu na ukupan broj dana trgovanja u razdoblju od 60
87
tjedana unazad od dana na koji se vrši izračun. Kriterij likvidnosti postavljen na 0
znači da će u izračun biti uključene sve dionice, a 100 znači da će biti uključene samo
one kojima je broj dana trgovanja jednak ukupnom broju dana tgovanja (izračun ne
uzima u obzir količinu protrgovanih dionica).
2. Mora biti odabran barem jedan sektor.
3. U izračun mora biti uključena barem jedna dionica.
6.6. Pregledavanje, izvršavanje ili opoziv naloga
Slika 48. Nalozi
(izvor: izradila autorica)
Slika 48. prikazuje naloge koji su dostupni na tabu "Nalozi" (1) i to u odvojenom prikazu
otvorenih (2) i izvršenih (3). Otvorene naloge moguće je izvršiti (4) ili opozvati (5).
Pravila:
1. Da bi se izvršio ili opozvao, nalog mora biti otvoren.
2. Za izvršavanje naloga korisnik mora imati otvoreni račun.
3. U slučaju kupnje, saldo na računu mora biti veći ili jednak iznosu naloga.
4. U slučaju prodaje, količina dionice mora biti veća ili jednaka količini na nalogu (nije
dozvoljena kratka prodaja).
88
6.7. Upravljanje računom
Slika 49. prikazuje opcije upravljanja računom omogućene na tabu "Račun" (1). Korisnik ima
na raspolaganju opcije za otvaranje računa (2), zatvaranje (3), uplate na račun (4) i (5), te
isplate sa računa (6) i (7). Prikazuju se osnovne informacije o računu (8) i zadnjoj transakciji
(9), te popis svih transakcija po računu (10).
Slika 49. Upravljanje računom
(izvor: izradila autorica)
Pravila:
1. Korisnik može imati samo jedan otvoreni račun.
2. Prilikom zatvaranja računa saldo mora biti jedank nuli. Ako je saldo veći od nule,
potrebno je prije zatvaranja računa izvršiti isplatu.
3. Račun ne može imati negativan saldo.
6.8. Pregledavanje dionica i podataka o trgovanju
Na tabu "Dionice" (1) omogućeno je pregledavanje podataka o dionicama (slika 50.) i to
određenih pokazatelja (2), općih podataka (3) i podataka o trgovanju (4). Moguć je prikaz
grafa kretanja cijena određene dionice klikom na "Prikaži graf" (5).
89
Slika 50. Prikaz dionica i podataka o trgovanju
(izvor: izradila autorica)
90
7. Zaključak
U ovom radu prikazan je proces izrade web sjedišta s posebnim naglaskom na web aplikacije.
Zahtjevnost korisnika s jedne strane te sve brži razvoj i zastarijevanje tehnologija s druge
strane, učinili su web sustave izrazito heterogenim i dinamičnim tvorevinama koje svoju
kompleksnost često skrivaju iza atraktivnih sučelja pružajući samo iluziju jednostavnosti.
Upravo usklađivanje svih komponenata jednog takvog sustava kako bi se korisniku omogućio
jedinstveni doživljaj, a koji će biti razlogom da se on iznova vraća, predstavlja pravi izazov
razvoja. Pri tome se kao jedan od imperativa nameće postizanje odgovarajuće razine
upotrebljivosti koju potpomaže primjena Ajax tehnologija.
Premda se u radu nastojalo dati prikaz razvoja web aplikacija kao jednog zaokruženog
procesa, stvarnost nameće potrebu sagledavanja i nekih dodatnih aspekata koji zbog
ograničenog prostora nisu mogli biti obuhvaćeni ovim radom. Posebno se to odnosi na
sigurnost aplikacija koje uključuju novčane transakcije.
Osim teorijskog dijela, rad je pratila i izrada prototipa web aplikacije za upravljanje
portfeljem koji je, osim za prikaz procesa razvoja, poslužio i za postavljanje određenih
temelja s obzirom da je intencija autorice nastavak razvoja aplikacije. Tijekom rada stečena su
nova znanja vezana uz korištene tehnologije te su utvrđene i određene mane učinjenog
odabira. Daljnji razvoj išao bi u smjeru
implementacije dodatnih metoda konstruiranja
optimalnog portfelja čije bi pretpostvake bile bliže stvarnosti od primijenjene metode
temeljene na jednoindeksnom modelu. No, to bi podrazumijevalo i složenije izračune što bi
posljedično, zbog neprikladnosti PHP-a i ostalih skriptnih jezika za takvu namjenu, značilo
promjenu implementiranih tehnologija. Dodatna bi poboljšanja mogla predstavljati korištenje
web servisa za preuzimanje aktualnih podataka o trgovanju dionicama, povećanje
interaktivnosti te jednostavosti i ugodnosti korištenja putem omogućavanja drag&drop
dodavanja dionica u portfelj, te samostalnog odabira i slaganja elemenata sučelja, a svakako
bi trebalo tu uključiti i bolju podršku za starije web preglednike te prilagodbu aplikacije za
mobilne uređaje.
91
Literatura
Knjige:
1.
Amenc, N, Sourd, LV 2003, Portfolio Theory and Performance Analysis, John Wiley
& Sons Ltd, West Sussex
2.
Casteleyn, S, Daniel, F, Dolog, P, Matera, M 2009, Engineering Web Applications,
Springer-Verlag , Berlin
3.
Elton, EJ, Gruber, MJ, Brown, SJ, Goetzmann, WN 2003, Modern Portfolio Theory
and Investment Analysis, Sixth Edition, John Wiley & Sons Ltd, West Sussex
4.
Kalbach, J 2007, Designing Web Navigation, O’Reilly Media, Sebastopol
5.
Kappel, G, Proll, B, Reich, S, Retschitzegger, W 2006, Web Engineering The
Discipline of Systematic Development of Web Applications, John Wiley & Sons Ltd,
6.
Parker, T, Toland, P, Jehl, S, Wachs, MC 2010, Designing with Progressive
Enhancement: Building the Web that Works for Everyone, New Riders, Berkeley
7.
MacIntyre, P, Danchilla, B, Gogala, M 2011, Pro PHP Programming, Apress, New
York
8.
Rossi, G, Pastor, O, Schwabe, D, Olsina, L 2008, Web Engineering: Modelling and
Implementing Web Applications, Springer-Verlag, London
9.
Schwartz, B, Zaitsev, P, Tkachenko,V, Zawodny, JD, Lentz, A, Balling, DJ 2008,
High Performance MySQL, Second Edition, O’Reilly Media, Sebastopol
10.
Sharp, H, Rogers, Y, Preece, J 2002, Interaction Design: Beyond Human-Computer
Interaction, John Wiley & Sons Ltd, West Sussex
11.
Sikos, LF 2011, Web Standards - Mastering HTML5, CSS3, and XML, Apress, New
York
12.
Tidwell, J 2011, Designing Interfaces, O’Reilly Media, Sebastopol
13.
Varga, M 1994, Baze podataka, DRIP, Zagreb
14.
Zambonini, D 2011, A Practical Guide to Web App Success, Five Simple Steps,
Penarth
Ostalo:
1.
Internet World Stats, pristupljeno 20.10.2012.
http://www.internetworldstats.com/stats.htm
2.
Interoute, What is Cloud Hosting?, pristupljeno 13.12.2012.
http://www.interoute.com/vdc/what-is-cloud-hosting
92
3.
Korunić, D 2008, DNS priručnik, pristupljeno 13.12.2012.
http://sistemac-portal.carnet.hr/system/files/DNS-prirucnik-1_5.pdf
4.
OWASP 2008, OWASP Testing Guide, pristupljeno 15.01.2013.
http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf
5.
Pravilnik o ustrojstvu i upravljanju vršnom nacionalnom internetskom domenom,
pristupljeno 13.12.2012. http://www.dns.hr/pravilnik
6.
Silver, A 2007, What Puts the Design in Interaction Design, pristupljeno 28.11.2012.
http://www.uxmatters.com/mt/archives/2007/07/what-puts-the-design-in-interactiondesign.php
7.
World Wide Web Consortium, pristupljeno 03.12.2012.http://www.w3c.com
8.
Zagrebačka burza, pristupljeno 05.11.2012.http://www.zse.hr
93
Popis slika
Slika 1. Kompleksnost web sustava ........................................................................................... 9
Slika 2. Višeslojna arhitektura.................................................................................................. 11
Slika 3. Razmjena HTTP poruka.............................................................................................. 12
Slika 4. Rezultat HTML primjera u web pregledniku.............................................................. 14
Slika 5. Tradicionalni web model ............................................................................................ 18
Slika 6. Ajax model.................................................................................................................. 19
Slika 7. Arhitektura MySQL SUBP-a ...................................................................................... 22
Slika 8. Uobičajeni raspored elemenata web stranice .............................................................. 28
Slika 9. Serif i sans-serif font ................................................................................................... 29
Slika 10. Kombinacije boja: komplementarne, analogne, triadne............................................ 30
Slika 11. Kategorije navigacije ................................................................................................ 31
Slika 12. Usporedba tehnologija za izradu sučelja................................................................... 33
Slika 13. Entiteti i osnovni tipovi veza .................................................................................... 34
Slika 14. Relacija "Dionica"..................................................................................................... 35
Slika 15. Efikasna granica ........................................................................................................ 45
Slika 16. Primjer opisa tipičnog korisnika - personas ............................................................. 51
Slika 17. Dijagram slučajeva korištenja pretplatnika............................................................... 52
Slika 18. Početni model eniteti-veze ........................................................................................ 54
Slika 19. Wireframe model ...................................................................................................... 56
Slika 20. Izgled gotovog sučelja .............................................................................................. 57
Slika 21. Relacijski model podataka ........................................................................................ 59
Slika 22. Primarna navigacija i logotip kao navigacijski element ........................................... 64
Slika 23. Lokalna navigacija .................................................................................................... 64
Slika 24. Stablasti navigacijski mehanizam - zatvoren ............................................................ 64
Slika 25. Stablasti navigacijski mehanizam - otvoren.............................................................. 65
Slika 26. Straničenje sa premotavanjem i direktnim pristupom stranici.................................. 65
Slika 27. Uspostavljanje dijaloga sa korisnikom ..................................................................... 66
Slika 28. Signaliziranje napretka izvršavanja određene akcije ................................................ 67
Slika 29. Temeljna struktura stranice ....................................................................................... 68
Slika 30. Izgled stranice nakon primjene stilova za tipografiju i pozicioniranje ..................... 69
Slika 31. Izgled gotovog sučelja .............................................................................................. 69
Slika 32. Otvoreni nalozi.......................................................................................................... 71
Slika 33. Poruka o izvršenoj transakciji ................................................................................... 73
Slika 34. Izgled stranice u web pregledniku Internet Explorer 6 ............................................. 77
Slika 35. Izgled stranice u web pregledniku Opera 9............................................................... 77
Slika 36. Prikaz portfelja i otvaranja naloga ............................................................................ 78
Slika 37. Prikaz dionica u portfelju, dodatnih informacija i otvaranja naloga......................... 79
Slika 38. Prikaz izbornika za odabir načina sortiranja i odabira stupaca ................................. 79
Slika 39. Kreiranje novog portfelja .......................................................................................... 81
Slika 40. Izmjena portfelja ....................................................................................................... 81
Slika 41. Izmjena naziva/opisa portfelja .................................................................................. 82
Slika 42. Izmjena strukture portfelja ........................................................................................ 83
Slika 43. Usporedba portfelja................................................................................................... 84
Slika 44. Usporedba dionica..................................................................................................... 85
Slika 45. Izračunavanje optimalnog portfelja........................................................................... 86
Slika 46. Rezultat izračuna optimalnog portfelja ..................................................................... 87
Slika 47. Graf prinos/rizik ........................................................................................................ 87
Slika 48. Nalozi ........................................................................................................................ 88
94
Slika 49. Upravljanje računom................................................................................................. 89
Slika 50. Prikaz dionica i podataka o trgovanju....................................................................... 90
95
Sažetak
S obzirom na današnju neupitnu važnost prisutnosti na Webu, jednom kad se donese
odluka o uspostavljanju web sjedišta ili redizajniranju postojećeg, postavlja se pitanje
koji su to koraci potrebni u njegovom razvoju. Cilj rada sastoji se u prikazu razvoja
web sjedišta kroz ključne aktivnosti i to najprije teorijski a zatim kroz praktičan
primjer. Budući da gotovo i nema web sjedišta koje ne uključuje određenu razinu
interaktivnosti, to je za primjer odabrana izrada web aplikacije.
U radu se najprije vrši prikaz ključnih karakteristika web aplikacija i to putem
njihove usporedbe sa informacijski orijentiranim web sjedištima s jedne strane te
tradicionalnim aplikacijama s druge strane, nakon čega slijedi pregled tehnologija
koje stoje na raspolaganju prilikom razvoja, no ograničen na one doista korištene u
izradi samog prototipa. U nastavku se daje prikaz procesa razvoja koji obuhvaća:
planiranje i utvrđivanje zahtjeva, dizajn, implementaciju, testiranje, održavanje i
evoluciju.
Drugi dio rada posvećen je izradi prototipa web aplikacije za upravljanje portfeljem
dionica. Budući da aplikacija omogućava izračunavanje optimalnog portfelja, za
izračun je implementirana Elton-Gruber metoda konstruiranja optimalnog portfelja
temeljena na Sharpeovom jednoindeksnom modelu. U radu je dan i kratki prikaz
implementirane metode.
Ključne riječi: web aplikacije, proces razvoja, optimalni portfelj.

Obrazac o info.prije sklapanja ugovora o depozitu

Za Glavnu skupštinu Društva predlaže se Dnevni red: 1. Otvaranje

Poziv za Skupštinu WORD - TLM

prijava stjecanja dionica - Atlantska plovidba dd Dubrovnik

poziv za podnošenje ponuda za kupnju do [180.000

Julijana Matanović tekst

Izvješće Uprave o poslovanju

Primakonova metodologija implementacije Primavere

preuzeti ovdje - Croatia Lloyd dd

Dnevni red dana prije dana odrZavan ry v

- Munich Personal RePEc Archive