Sustav udomljenika podesivih za potrošačko financijsko ...2.2 Upravljanje investicijama Za razliku od financijske analize, koja služi za ocjene ponašanja firme u dužim periodima

SVEUČILIŠTE U ZAGREBU

FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

Diplomski rad br. 86

Sustav udomljenika podesivih za potrošačko financijsko upravljanje

Tomislav Lugarić

Zagreb, lipanj, 2010.

1

Zahvaljujem mentoru prof. dr. sc. Siniši

Srbljiću za priliku da radim na jednom zanimljivom, atraktivnom i poticajnom

projektu.

Zahvaljujem mr. sc. Miroslavu Popoviću za brojne savjete i smjernice

tokom pisanja rada.

Zahvaljujem kolegama s Ekonomskog fakulteta u Zagrebu Vjekoslavu Mesarošu i Jurici Štimcu

za savjete pri razvoju sustava, pomoć oko literature i vrijeme utrošeno na projektu.

Zahvaljujem dr. sc. Blanki Krauthacker za

pomoć pri pisanju, ispravljanju i oblikovanju rada.

Zahvaljujem kolegi Zvonimiru Pavliću za pomoć pri izgradnji programske

potpore ovom radu.

Zahvaljujem svojoj djevojci Gordani, kao i cijeloj obitelji za potporu i razumijevanje.

2

Sadržaj

1. Uvod..................................................................................................................... 3 2. Financijska analiza i upravljanje.......................................................................... 5

2.1 Metode financijske analize ................................................................................ 5 2.2 Upravljanje investicijama .................................................................................. 8 2.3 Postojeći portali za financijsku analizu i upravljanje ........................................ 8

2.2.1 Portali za pregled informacija..................................................................... 8 2.2.2 Portali s mogućnošću prilagodbe potrošaču ............................................. 12 2.2.3 Portali s mogućnošću upravljanja investicijama....................................... 13

3. Korištene tehnologije......................................................................................... 16 3.1 Tehnologije ostvarenja programske logike u pregledničkom sustavu............. 16

3.1.1 Jezik JavaScript......................................................................................... 16 3.1.2 Udomitelj udomljenika Apache Shindig i specifikacija OpenSocial........ 18

3.2 Tehnologije ostvarenja programske logike u poslužiteljskom sustavu ........... 20 3.2.1 Okružje .NET i jezik C# ........................................................................... 20 3.2.2 Tehnologija ASP.NET.............................................................................. 23 3.2.3 Usluga Google Chart API ......................................................................... 24

3.3 Tehnologije za povezivanje korisničkog i poslužiteljskog sustava ................. 28 3.3.1 Arhitektura SOA i tehnologija WS-*........................................................ 28 3.3.2 Alat Geppeto ............................................................................................. 33

4. Arhitektura ostvarenog sustava za financijsko upravljanje ............................... 36 4.1 Arhitektura sustava .......................................................................................... 36 4.2 Arhitektura udomljenika .................................................................................. 39 4.3 Arhitektura web usluga.................................................................................... 44 4.4 Standardni zapis za tablične podatke ............................................................... 46

5. Ostvarenje sustava za financijsko upravljanje ................................................... 48 5.1 Zahtijevane funkcionalnosti sustava za financijsko upravljanje...................... 48 5.2 Organizacija usluga, udomljenika i toka podataka u sustavu .......................... 49 5.3 Dobava podataka.............................................................................................. 53

5.3.1 Općenite funkcionalnosti .......................................................................... 53 5.3.2 Funkcionalnosti specifične za ekonomsku analizu................................... 54

5.4 Obrada podataka .............................................................................................. 55 5.4.1 Općenite funkcionalnosti .......................................................................... 56 5.4.2 Funkcionalnosti specifične za ekonomsku analizu................................... 61

5.5 Prikaz podataka................................................................................................ 64 5.5.1 Općenite funkcionalnosti .......................................................................... 64 5.5.2 Funkcionalnosti specifične za ekonomsku analizu................................... 66

5.6 Ostvarenje programske klase za rukovanje standardnim zapisom podataka... 67 5.7 Vanjski izvori podataka ................................................................................... 69 5.8 Ostvarenje web usluga ..................................................................................... 70

6. Zaključak ........................................................................................................... 71 7. Literatura............................................................................................................ 73 Sažetak ....................................................................................................................... 76 Summary.................................................................................................................... 77

3

1. Uvod

Sve veći razvoj globalne računalne mreže Internet, kao i sve veća raširenost osobnih

računala donose sa sobom promjenu u načinu na koji potrošači razmišljaju o aplikacijama i

njihovim mogućnostima. Potrošačke mreže (engl. consumer networks) razvijaju se, te

pokrivaju sve šira područja primjene poput trgovine, analize ekonomskih podataka,

meteorologije, te socijalnih aktivnosti [1]. Aplikacija koja bi imala visoku kvalitetu

doživljaja (engl. QoE, Quality of Experience) morala bi biti što prilagođenija potrošaču. U

pristupu u kojem profesionalni programeri razvijaju aplikacije za amatere, to jest prosječne

potrošače, programeri teško mogu predvidjeti sve zahtjeve potrošača. Osoba koja je

najbolje upućena u želje potrošač je sam taj potrošač. Kada bi se potrošaču dalo alat koji

on može razumjeti, a koji je ujedno po svojim mogućnostima mjerljiv s programskim

jezicima, potrošač bi bio u mogućnosti razviti aplikaciju visoke kvalitete doživljaja.

Potrošači ne razumiju elemente programskih jezika poput tipova podataka, funkcija,

rekurzija i grananja, te se takvi konstrukti moraju od njih sakriti odgovarajućim sučeljima

koja oni mogu razumjeti. Potrošači razumiju grafička sučelja web stranica, te se sakrivanje

programskog koda može ostvariti udomljenicima. Udomljenici su male web stranice koje

mogu prikazivati određene podatke, biti sučelja prema uslugama pisanima klasičnim

programskim jezicima poput jezika Java, C# ili Visual Basic. Alat Geppeto ostvaruje

paradigmu prilagođenu potrošaču, koja se temelji na udomljenicima kao građevnim

blokovima. Potrošač može povezivati sučelja udomljenika u sve složenije nove

udomljenike, te tako razviti aplikaciju prema svojim željama.

U ovom radu opisan je sustav za potrošačko financijsko upravljanje. Sustav se temelji

na udomljenicima kao građevnim elementima. Pri razvoju sustava vođeno je računa o

mogućnostima postojećih sustava za dohvat financijskih podataka i njihovu analizu.

Operacije analize i obrade financijskih podataka dekomponirane su u manje logičke cjeline

te je svaka od njih ostvarena jednim udomljenikom. Potrošač koristeći alat Geppeto

povezuje udomljenike u funkcionalnu aplikaciju formirajući vlastite tokove podataka.

U drugom poglavlju opisani su pojedini postojeći sustavi za dohvat financijskih

podataka, njihovu obradu i prezentaciju, te za financijsko upravljanje. Prikazane su

mogućnosti definiranja vlastitih pravila te reagiranja na određene događaje u sustavu. U

trećem poglavlju opisane su tehnologije korištene za izradu sustava. Opisani su jezik

4

JavaScript i knjižnica OpenSocial, koji su korišteni za razvoj udomljenika na klijentskoj

strani. Opisan je jezik C# i platforma .NET, koji su korišteni za razvoj web usluga na

poslužiteljskoj strani. Opisana je arhitektura sustava baziranog na uslugama (engl. Service

Oriented Architecture – SOA), koja je korištena za povezivanje udomljenika i usluga.

Opisan je alat Geppeto, koji se koristi za međusobno povezivanje udomljenika u aplikaciju.

U četvrtom i petom poglavlju opisano je programsko ostvarenje sustava za financijsko

upravljanje koji je rezultat ovog rada. Četvrto poglavlje opisuje arhitekturu sustava, a peto

ostvarenje, funkcioniranje pojedinih dijelova. Na kraju je iznesen zaključak rada.

5

2. Financijska analiza i upravljanje

Svaka tvrtka uvrštena na tržište vrijednosnih papira predmet je interesa nekoliko grupa

osoba. Među tim pravnim i fizičkim osobama su zaposlenici, uprava, banke, vlasnici

dionica tvrtke te vlasnici obveznica [2]. Svim ovim osobama ocjena položaja tvrtke na

tržištu važna je pri odlukama o ulaganju u tvrtku, davanje kredita tvrtki, kao i o tome što

tvrtka može ili ne može poduzimati u budućnosti. Osim podatka o trenutnoj i povijesnoj

cijeni dionice tvrtke, koji se može dobiti na burzi na koju je dionica uvrštena, dostupna su i

periodička financijska izvješća. Podaci o cijenama dionica koriste se u tehničkoj analizi,

koja u ovom radu nije obrađivana. Podaci iz periodičkih financijskih izvješća koriste se u

financijskoj analizi. U ovom poglavlju opisane su metode kojima se analiziraju periodička

izvješća, te razni portali na kojima se mogu dobiti podaci potrebni za analize, gotove

analize, a moguće je i formirati vlastitu analizu.

2.1 Metode financijske analize

Financijska izvješća služe da dobivanje pregleda nad sredstvima kojima je uprava

raspolagala, njihovim financiranjem, i što je s tim sredstvima postignuto. U izvješćima se

nalaze podaci o stanju imovine (engl. balance sheet), toku novca (engl. cash flow),

prihodima (engl. income statement) i podaci o kreditima odnosno dugovanjima tvrtke

(engl. loan agreements) [3]. Izvješće o stanju imovine daje pregled o svoj imovini i svim

dugovanjima odnosno potraživanjima tvrtke u određenom trenutku. Izvješće o toku novca

daje uvid o svim transakcijama u kojima novac prelazi s računa na račun, za razliku od

izvješća o stanju imovine i prihodima, koja bilježe promjene vrijednosti čak i kad novac

nije još uplaćen, primjerice kod uplata s počekom. Izvješće o prihodima prikazuje prihode i

rashode tokom određenog perioda, najčešće tokom godine ili tromjesečja [4].

Vrijednost tvrtke je određena njezinom profitabilnosti i rastom. Profitabilnost i rast

uvjetovani su strategijama tvrtke na tržištu proizvoda i strategijama tvrtke na financijskom

tržištu. Strategije na tržištu proizvoda (engl. product market strategies) određuju se

operativnim managementom (engl. operating management), kojim se upravlja prihodima i

rashodima te managementom ulaganja (engl. investment management), kojim se upravlja

fiksnim i tekućim kapitalom. Stretegije na financijskom tržištu (engl. financial market

policies) određuju se financijskim odlukama (engl financing decisions), koje određuju što

6

se radi s kapitalom i pasivom, te odlukama o dividendama dioničara (engl. dividend policy)

[5]. Slika 2.1 prikazuje gore opisane elemente određivanja vrijednosti tvrtke.

Slika 2.1. – Utjecaji na rast i profitabilnost tvrtke [5]

Četiri zaokružena oblika managementa predstavljaju četiri poluge kojima uprava može

utjecati na uspješnost tvrtke. Financijska analiza nastoji dati kvalitetnu ocjenu ponašanja

tvrtke na tržištu.

Dvije su ključne metode financijske analize: analiza omjera (engl. ratio analysis) i

analiza toka novca (engl. cash flow analysis). Analiza omjera omogućava da se na temelju

dosadašnjih podataka predvidi kako će se tvrtka u budućnosti ponašati na tržištu. Takva

predviđanja korisna su pri odobravanju zajmova, analize sigurnosti ulaganja i formiranje

korporativne strategije [5]. Analiza toka novca omogućava dobivanje uvida u to na kakve

se prihode kompanija oslanja, koliko ulaže u razvoj. Ako postoje gubici, analiza toka

novca može objasniti koji su tome razlozi. U ovom radu obrađuje se analiza omjera.

Cilj analize omjera je ocijeniti uspješnost tvrtke u svakom od ovih područja. Za bolju

ocjenu uspješnosti, kao i preciznije predviđanje ponašanja tvrtke u budućnosti potrebno je

provesti što detaljniju usporedbu omjera. Omjeri se mogu uspoređivati u vremenu, u

7

industriji ili apsolutno. Pri usporedbi po vremenu uzimaju se omjeri za određenu tvrtku

kroz određeni vremenski period. Ovakva usporedba omogućava ocjenu utjecaja strategija

tvrtke na njen uspjeh kroz vrijeme. Pri usporedbi u industriji uspoređuju se omjeri više

tvrtki unutar jedne industrije. Omogućava ocjenu konkurentnosti tvrtke, bez obzira na

stanje u kojem se industrija odnosno gospodarstvo nalazi, budući da se sve tvrtke unutar

industrije nalaze u jednakom položaju. Apsolutna usporedba može se provoditi samo za

neke pokazatelje za koje je moguće odrediti apsolutne referentne mjere [5].

Omjeri koji se računaju na temelju periodičkih izvješća dijele se u četiri glavne grupe:

omjeri poluge (engl. leverage ratios), omjeri likvidnosti (engl. liquidity ratios), omjeri

operativne efikasnosti (engl. operating efficency ratios) i omjeri profitabilnosti (engl.

profitability ratios) [2].

Omjeri poluge daju mjeru snage tvrtke da podnese kreditno opterećenje. Svako

zaduženje tvrtke može za posljedicu povećanje ili smanjenje dobiti. U slučaju povećanja

sva dodatna dobit ide dioničarima, a u slučaju smanjenja opet su na gubitku dioničari.

Pošto zaduženje stvara veću ili manju dobit, ovisno o stanju na tržištu, kaže se da stvara

financijsku polugu. Omjeri poluge daju mjeru tako stvorene poluge.

Omjeri likvidnosti daju mjeru koliko jednostavno i brzo tvrtka može doći do novca za

isplatu svojih financijskih obveza. Bolji omjer likvidnosti generalno označava brži i

pouzdaniji tok novca u kompaniji. Sredstva poput robe na skladištu i potraživanja su u

pravilu likvidna, dok nekretnine u pravilu nisu. Nedostatak pokazatelja likvidnosti je to što

brzo zastarijevaju.

Omjeri operativne efikasnosti daju mjeru koliko tvrtka efikasno koristi svoj kapital.

Viši omjeri označavaju bolju profitabilnost, no viši omjeri mogu i značiti da je tvrtka blizu

maksimalnog kapaciteta i da nema mjesta proširenju bez znatnijih ulaganja. Ostali omjeri

iz ove grupe pokazuju brzinu naplate potraživanja i količine robe koja stoji neprodana.

Omjeri profitabilnosti daju mjeru koliko tvrtka zarađuje. Omjeri u ovoj grupi govore

koliki udjeli profita se usmjeravaju u dividendu, kapital, zadržanu dobit i imovinu [2].

Na temelju svih ovih omjera analitičari mogu donositi odluke o budućim akcijama

tvrtke, kao i preporuke da li je tvrtkine dionice uputno kupovati ili prodavati. Iako analize

omjera ne mogu dati detaljne i finalne odgovore na sva pitanja, mogu dati analitičarima,

managerima i investitorima smjernice na što se treba usmjeriti pri oblikovanju osobnih ili

korporativnih strategija [5]. Također je moguće na temelju omjera zaključiti da li je firma

financijski stabilna ili se nalazi u opasnosti od bankrota.

8

2.2 Upravljanje investicijama

Za razliku od financijske analize, koja služi za ocjene ponašanja firme u dužim

periodima i za predviđanje generalnih trendova, upravljanje investicijama zahtjeva

praćenje kretanja cijena vrijednosnica u realnom vremenu. Ovisno o kretanjima cijena

vrijednosnica u bližoj ili daljoj prošlosti ulagač donosi odluku o kupnji ili prodaji. Kad je

odluka donesena, ulagač izdaje nalog za kupnju ili prodaju vrijednosnice koji šalje brokeru

koji ga izvršava. Financijska analiza također ima svoju ulogu pri upravljanju investicijama

budući da može predvidjeti trendove kretanja cijena vrijednosnica.

2.3 Postojeći portali za financijsku analizu i upravljanje

Informacije o tržištima vrijednosnih papira dostupne su putem različitih informativnih

portala. Na portalima se mogu dobiti informacije o trenutnim i povijesnim cijenama

vrijednosnih papira, periodička financijska izvješća i popis vrijednosnih papira.

Najjednostavniji portali samo prikazuju informacije nekog izvora, primjerice određene

burze. Složeniji portali mogu sakupljati informacije s više izvora, te čak i omogućavati

potrošaču određene prilagodbe sučelja, dok najnapredniji omogućavaju potrošaču

upravljanje svojim portfeljem. U ovom potpoglavlju dani su primjeri portala od

najjednostavnijih do najsloženijih.

2.2.1 Portali za pregled informacija

Najjednostavniji portali za izlaganje financijskih informacija samo prikazuju

informacije određenog izvora. Informacije su izložene u obliku tablica, a potrošaču je

prepušteno da među njima pronađe one koje ga zanimaju. Web stranice burza su primjer

ovakvih portala. Slika 2.2 prikazuje web stranicu Zagrebačke burze (www.zse.hr) na kojoj

su prikazane trenutne cijene dionica. Osim cijena, na stranici je moguće dobiti i podatke o

individualnoj dionici, poput kretanja cijene dionice u prošlosti, iscrtavanja grafova i

financijskih izvješća. Slika 2.3 pokazuje podstranicu s financijskim izvješćima. Financijska

izvješća na toj stranici nisu u standardiziranom formatu (neka su u formatu PDF, a neka

kao Microsoft Excel tablice). Iako izvješća jesu pregledno raspoređena da ih potrošač lako

može pronaći, zbog nekonzistentnog formata zapisa nepogodna su za strojnu obradu.

9

Slika 2.2. – Web stranica Zagrebačke burze, podaci o cijenama dionica [6]

Slika 2.3. – Web stranica Zagrebačke burze, financijska izvješća dionice [6]

Slični portali su www.limun.hr, www.anicazna.com, www.moja-dionica.com,

www.mojedionice.com i MSN money. Ovi portali okupljaju podatke o cijenama dionica s

više regionalnih burzi, a nude i podatke o fondovima, brokerima, te analize za registrirane

potrošače. Slika 2.4 prikazuje podstranicu portala mojedionice.com na kojoj se vidi dio

10

periodičkog financijskog izvješća. Ovako skupljeni i organizirani podaci vrlo su pregledni

potrošaču, a zahvaljujući jasnoj i standardiziranoj strukturi pogodni su za strojnu obradu.

Slika 2.4. – Portal mojedionice.com, periodičko izvješće [7]

Gore spomenuti portali nude osnovne funkcionalnosti besplatno, dok je za naprednije

funkcionalnosti potrebna registracija i/ili plaćanje usluge. Na slici 2.4 vidi se da su samo

prva tri stupca dostupna besplatno, dok za pregled starijih podataka je potrebna registracija.

Neki od portala nude i web usluge za dobavu podataka, koje se također naplaćuju, ali

predstavljaju puno bolje prilagođeno sučelje za strojnu obradu. Većina portala nudi i razne

oblike grafičkog prikaza podataka, najčešće kretanje cijene vrijednosnice tokom određenog

vremena. Na slici 2.5 prikazan je grafikon kretanja cijene vrijednosnice Končar

Elektroindustrija (KOEI-R-A) na stranicama Zagrebačke burze, a na 2.6 grafikon iste

dionice na stranici limun.hr.

11

Slika 2.5 – Kretanje cijene vrijednosnice KOEI-R-A prikazano na stranici Zagrebačke burze[6]

Slika 2.6. – Kretanje cijene vrijednosnice KOEI-R-A prikazano na stranici limun.hr [8]

12

2.2.2 Portali s mogućnošću prilagodbe potrošaču Osim funkcionalnosti navedenih u prethodnom potpoglavlju, ovdje opisani sustavi

pružaju mogućnosti prilagodbe prikaza potrošaču. Primjeri takvih sustava su Google

finance (finance.google.com), Yahoo finance (finance.yahoo.com) i Kapital-plus (kapital-

plus.net). Potrošači ovih stranica imaju daleko fleksibilniji pregled nad podacima koje

dohvaćaju. Portali Google finance i Kapital-Plus nude potrošaču mogućnost izgradnje

portfelja. Portfelj izgrađen u portalu Google finance prikazan je na slici 2.7, a u portalu

Kapital-Plus na slici 2.8.

Slika 2.7. – Portfelj u portalu Google finance [9]

Slika 2.8. – Portfelj u portalu Kapital-Plus [10]

13

Oba sustava nude sličan način pregleda portfelja. Potrošač može u portfelj dodavati

oznake (engl. tickers) vrijednosnih papira kojima trguje te imati brzi pregled nad njima.

Portal automatski prikuplja podatke o trenutnim cijenama vrijednosnica. Potrošač dodatno

može u portfelj upisati transakcije koje je izvršio (prodaja i kupnja vrijednosnica), te portal

automatski računa ostvarenu dobit ili gubitak. Pritiscima na oznake vrijednosnica potrošač

može dobiti detaljne podatke o njima. Oba portala omogućuju pregled vijesti vezanih uz

vrijednosnice, s time da portal Google finance dodatno ističe vijesti vezane uz

vrijednosnice uključene u portfelj. Portal Yahoo finance nudi jednake mogućnosti kao i

Google finance.

2.2.3 Portali s mogućnošću upravljanja investicijama Najkompleksniji portali osim svega navedenoga nude mogućnost zadavanja naloga

brokerima, odnosno online trgovanja dionicama. Takvi su sustavi najčešće povezani s

brokerskim kućama. Za razliku od dosad navedenih portala, na portalima s mogućnošću

upravljanja investicijama mogu se izvršavati transakcije s velikim količinama novčanih

sredstava, te imaju veću razinu sigurnosti. Osim provjere identiteta potrošača te

autorizacije, ovi portali pri svakom zadavanju naloga provjeravaju da li nalog zadovoljava

sva pravila trgovanja (primjerice da ne ruši cijenu dionice). Na slici 2.9. prikazana je

stranica za prijavu novog potrošača u sustav Agram Trader.

Slika 2.9. – Prijava novog potrošača u sustav Agram Trader [11]

14

Budući da se zahtijeva veća razina sigurnosti nego u dosad opisanim sustavima,

prilikom prijave se od potrošača traži potvrda istinitosti osobnih podataka, kao i da dostavi

broj računa za transakcije.

Na slici 2.10. prikazana je stranica na kojoj potrošač može graditi svoj portfelj. Kao i

stranice u dosad opisanim sustavima, stranica prikazuje kupljene vrijednosnice, dobit ili

gubitak ostvaren na istima te promijene cijena. Budući da sustav omogućava trgovanje i

provođenje transakcija, prikazan je i novac na računu te kupovna moć potrošača.

Slika 2.10. – Pregled stanja računa u sustavu Agram Trader [11]

Slika 2.11 prikazuje zadavanje naloga za kupnju vrijednosnice. Potrošač može narediti

kupnju ili prodaju određene vrijednosnice, kao i rokove do kojih se nalog mora izvršiti (u

protivnom se nalog automatski otkazuje). Nakon što je nalog zadan, potrošač može

pregledavati sve naloge u prošlosti, kao što je prikazano na slici 2.12.

15

Slika 2.11. – Zadavanje naloga u sustavu Agram Trader [11]

Slika 2.12. – Pregled naloga u sustavu Agram Trader [11]

16

3. Korištene tehnologije

Sustav udomljenika podesivih za potrošačko financijsko upravljanje podijeljen je na

klijentsku i poslužiteljsku stranu. Klijentska strana sastoji se od udomljenika koji

predstavljaju sučelja prema uslugama poslužiteljske strane. Iznimka su pojedini

najjednostavniji udomljenici kod kojih je cijela funkcionalnost ostvarena na klijentskoj

strani. Poslužiteljska strana sastoji se od web usluga te ostvaruje funkcionalnosti za koje su

udomljenici sučelja. U sustavu je potrebno ostvariti vezu udomljenika s web uslugama te

vezu udomljenika međusobno.

3.1 Tehnologije ostvarenja programske logike u pregledničkom sustavu

Klijentsku stranu čine udomljenici smještenu unutar udomljeničke platforme Shindig.

Funkcionalnost udomljenika ostvarena je programskim jezikom JavaScript. Za potrebe

komunikacije s poslužiteljem korišteno je programsko sučelje OpenSocial.

3.1.1 Jezik JavaScript Jezik JavaScript je skriptni jezik sa sintaksom vrlo sličnom jezicima C i Java, a

najčešće se koristi u razvoju klijentskih web primjenskih programa (engl. Client-side web

applications). Usporkos imenu, jezik JavaScript nema nikakve veze s programskim

jezikom Java [12]. Najčešće se koristi za izgradnju klijentskih programa koji se izvršavaju

u web-preglednicima, iako se može koristiti i kao skriptni jezik u aplikacijama poput

Microsoft Gadgets. Zbog svoje prilagođenosti izvršavanju unutar preglednika i mogućnosti

dinamičkih izmjena web stranica, jezik JavaScript ne ovisi o računalnoj platformi na kojoj

se pokreće, već isključivo o web pregledniku unutar kojeg se izvodi.

Jezik JavaScript je razvijen u kompaniji Netscape, izvorno pod imenom Mocha, zatim

LiveScript te na kraju JavaScript. Ime JavaScript dobio je u dogovoru između kompanija

Netscape i Sun Microsystems [12] po kojem je Netscape uključio Sunovu tehnologiju Java

u svoj preglednik Netscape. Jezik JavaScript je prvi put predstavljen u prosincu 1995.

godine kao dio preglednika Netscape Navigator 2.0B3. Slična imena izazvala su pogrešan

dojam da je jezik JavaScript verzija jezika Java koja se interpretira, ili čak kopija jezika

Java. JavaScript je dizajniran sa sličnom sintaksom i sličnim programskim elementima kao

17

jezici Java i C++, kako bi se programerima olakšalo učenje jezika [13]. Microsoft je razvio

svoju verziju jezika JavaScript zvanu JScript [14], te je uključio u preglednik Internet

Explorer 3.0. Standardizirana verzija jezika JavaScript, ECMAScript, predstavljena je

1997. godine. [15] te je danas u raširenoj upotrebi na Internetu. Zbog njihove velike

sličnosti, termin JavaScript koristi se kao naziv za jezike ECMAScript, JScript i

JavaScript. Iako je JScript vrlo sličan JavaScriptu, te se termini koriste ravnopravno,

JavaScript je bliži ECMA standardu nego JScript [12]. Danas u web preglednicima postoji

potpora sva tri jezika. Preglednik Mozilla podržava jezik JavaScript, a preglednik Internet

Explorer jezik JScript. Pojedini preglednici, poput preglednika Opera imaju potporu i za

više njih istovremeno. Jezik JScript se može koristiti i na .NET platformi, te se može

koristiti za razvoj Windows i web primjenskih programa [14].

Poput većine skriptnih jezika, jezik JavaScript ima slabo definirane tipove podataka

(engl. weakly typed language). To znači da se varijablu ne mora deklarirati, već se

deklaracijom smatra njezino prvo korištenje. Princip koji se koristi u JavaScriptu se naziva

„Pisanje pravilom patke“ (engl. Duck typing) [16]. Pisanje pravilom patke zasniva se na

takozvanom „testu patke“ (engl. Duck test). Test se objašnjava rečenicom: „Ako hoda kao

patka i glasa se kao patka, ja bi rekao da je to patka.“ Smisao testa je naglasiti da nije

toliko bitan sam tip podataka s kojim se rukuje, već kako se taj podatak ponaša. Ovakvo

određivanje sintakse olakšava implicitnu pretvorbu tipova podataka, te eliminira potrebu za

eksplicitnim deklariranjem varijabli. Problemi mogu nastati ako se ista varijabla pokuša

koristiti u dva različita konteksta, te se primjerice broj prebriše nizom znakova ili se

pokuša koristiti neinicijalizirana varijabla. Takve bi greške u jeziku sa strogo definiranim

tipovima podataka javljao kompajler, no u jezicima poput jezika JavaScript na njih mora

paziti programer [16].

Jezik JavaScript funkcionira kao objektno orijentirani jezik, a izvodi ga interpreter.

Podaci koji se stvaraju predstavljeni su objektima nad kojima se mogu pozivati

odgovarajuće članske funkcije. Kako je jezik interpretiran, ne zahtijeva nikakvo

prevođenje, već je dovoljno kod upisati u tekstualnu datoteku, uokviriti odgovarajućim

HTML (engl. HyperText Markup Language) oznakama ili nasloviti datoteku iz HTML

dokumenta te ga pokrenuti.

Razredi u jeziku JavaScript deklariraju se pomoću prototipova funkcija. Umjesto

deklaracije klase piše se njen konstruktor koji postavlja članske varijable na njihove

početne vrijednosti, pri čemu se one automatski deklariraju [17]. Pri generiranju objekta,

18

poziva se odgovarajući konstruktor koji mu određuje članske varijable, njihove početne

vrijednosti, i funkcije koje se nad njima mogu pozivati.

Jezik JavaScript u sebi nema funkcije za komuniciranje s okolinom, već se oslanja na

preglednik da mu pruži funkcije i objekte pomoću kojih se komunikacija ostvaruje. Primjer

funkcija kojima se ostvaruje komunikacija su funkcije za obradu događaja (engl. event

handler). Funkciju za obradu događaja preglednik pokreće kada detektira da se dogodio

određeni događaj. Primjer objekta kojima se komunikacija ostvaruje je model DOM [18]

(engl. Document object model), koji omogućava funkcijama u JavaScriptu da naslovljavaju

ili mijenjaju dijelove HTML dokumenta kao da se radi o strukturi podataka.

Potpora za regularne izraze je također jedna velika prednost JavaScripta. Sintaksa rada

s regularnim izrazima slična je onoj programskog jezika Perl [12], te pruža moćan alat za

manipuliranje nizovima znakova. Kako su HTML dokumenti opisani nizovima znakova,

regularni izrazi su vrlo praktično rješenje za pretraživanje odlomaka HTML koda koji se

dobiju primjenom modela DOM.

3.1.2 Udomitelj udomljenika Apache Shindig i specifikacija OpenSocial Apache Shindig je udomitelj (engl. container) za udomljavanje OpenSocial aplikacija.

Pokrenut je 2007. godine od strane kompanije Google kao udomitelj otvorenog koda (engl.

Open source) po specifikaciji sučelja OpenSocial. U prosincu 2007. organizacija Apache

Software Foundation preuzela je razvoj udomitelja te se on nastavlja u javnoj domeni.

Projekt je inicijalno potpomognut doprinosom koda koji pokreće stranicu iGoogle, no u

međuvremenu se projekt razvio u alat koji omogućava stranicama brzo postavljanje

infrastrukture za prikaz i udomljavanje udomljenika. Apache Shindig pruža mogućnosti za

prikazivanje udomljenika, posredovanje zahtjevima te obradu RPC i REST zahtjeva. Cilj

projekta je stvoriti infrastrukturu za brz razvoj stranica koje udomljuju OpenSocial

aplikacije. Razvojna zajednica nastoji ponuditi ostvarenja u što više programskih jezika.

Trenutno postoje ostvarenja u jezicima Java i PHP, a u planu su i ostvarenja u jezicima C#,

Perl i Ruby.

Apache Shindig se sastoji od 4 glavne cjeline:

JavaScript kod za udomljavanje udomljenika (engl. Gadget Container JavaScript)

je osnovni JavaScript kod koji omogućava funkcioniranje udomljenika. Kôd ostvaruje

podršku za sigurnost, komunikaciju, prikaz sučelja te programsko sučelje OpenSocial API.

19

Poslužitelj za prikaz udomljenika (engl. Gadget Rendering Server) se koristi za

pretvaranje XML opisa udomljenika u JavaScript i HTML kod koji se potom prikazuje

pomoću JavaScript koda za udomljavanje udomljenika.

JavaScript kod za podršku OpenSocial funkcionalnosti (engl. OpenSocial

Container) je nadogradnja na JavaScript kod za udomljevanje udomljenika. Omogućava

sve napredne OpenSocial funkcionalnosti poput profila, prijatelja, aktivnosti i

pohranjivanja podataka.

Poslužitelj sučelja za OpenSocial podatke (engl. OpenSocial Data Server) je

ostvarenje sučelja servera prema informacijama specifičnim za udomitelja. Sadrži REST

programska sučelja za OpenSocial funkcionalnost, čime omogućava laku nadogradnju

pozadinskim kodom ili skladištima podataka. [19]

Programsko sučelje OpenSocial je skup standardiziranih programskih funkcija

namijenjen izradi aplikacija koje objedinjuju više web stranica. Aplikacije koje koriste

sučelje OpenSocial lako se mogu povezivati s bilo kojom društvenom mrežom koja

podržava sučelje [20]. OpenSocial sadrži programska sučelja za jezik JavaScript te REST

protokole za komunikaciju između servera [21]. Sučelje je uključeno u brojnim

platformama za udomljenike poput iGoogle, Yahoo!, LinkedIn, orkut i Shindig. [22,23].

OpenSocial je inicijalno razvijen od strane kompanija Google, MySpace u suradnji s još

nekoliko društvenih mreža. Cilj projekta je stvoriti platformu koja će omogućiti integraciju

aplikacija neovisno o tome na kojoj se web stranici nalaze, čime se pojednostavljuje razvoj

aplikacija i proširuje potencijalni skup potrošača [21]. Trenutno aktualna verzija je

OpenSocial v0.9. Funkcionalnosti sučelja OpenSocial grupirane su kao objekti, te potrošač

može po potrebi pozivati funkcije nad njima. U ovom projektu korištena je funkcionalnost

slanja HTTP GET i POST zahtjeva na druge domene, koja je ostvarena u elementu

gadgets.io [24].

20

3.2 Tehnologije ostvarenja programske logike u poslužiteljskom sustavu

Poslužiteljsku stranu čini skup web usluga ostvarenih jezikom C# na platformi .NET.

Funkcionalnosti koje sustav pruža grupirane su na način da jedna usluga pruža skup

srodnih operacija. Svaka usluga opisana je svojim WSDL (engl. Web Services Description

Language) dokumentom prema WS-* (engl. Web Services) specifikaciji.

3.2.1 Okružje .NET i jezik C# Microsoft .NET je programsko okružje namijenjeno operativnom sustavu Windows.

Sastoji se od virtualnog stroja i brojnih programskih paketa s gotovim rješenjima za

osnovne programerske zahtjeve [25]. Osim Microsoftovog ostvarenja, postoje i druga

ostvarenja okružja, poput okružja otvorenog koda Mono [26], koja mogu raditi i na drugim

operativnim sustavima.

Razvoj okružja započeo je krajem 90-ih godina pod imenom Next Generation

Widnows Services. Probne verzije pojavile su se 2000. godine. Prva službena verzija 1.0

izdana je u veljači 2002. godine Verzija 1.1 objavljena u travnju 2003. godine imala je u

sebe ugrađene funkcionalnosti koje su prije bile opcionalni dodaci za platformu poput

ASP.NET kontrola i podrške za baze podataka. Poboljšana je sigurnost i dodana podrška

za IPv6 mrežni standard. Dodana je kompaktna verzija okružja (.NET Compact

Framework) namijenjena malim uređajima poput pocketPC.

Verzija 2.0 objavljena je u siječnju 2006. godine. Ova verzija je zadnja s podrškom za

Windows 98, ME i 2000. Osim promjena u programskim sučeljima, uvedena je podrška za

x64 platforme, te su dodani novi konstrukti jezika. Dodana je mini verzija (.NET Micro

Framework), predviđena za najkompaktnije i resursima najograničenije uređaje.

Verzija 3.0 objavljena je u studenom 2006. godine, i nije imala značajnih promjena u

arhitekturi niti je izdana kompaktna verzija. Infrastrukturno se oslanja na verziju 2.0.

Uključivala je dodatna programska sučelja za operacijski sustav Windows Vista. Dodane

su nove komponente za 3D grafiku, komunikaciju, nadzor procesa i sigurnost.

Verzija 3.5 objavljena je u studenom 2007. godine. Objavljena je i kompaktna verzija.

Kao i verzija 3.0 oslanja se na verziju 2.0. Dodana je podrška za lambda izraze, upiti nad

skupovima podataka LINQ (engl. Language Integrated Query). Poboljšana je mrežna

potpora, dodane nove funkcionalnosti i unaprijeđeno okruženje za web aplikacije

ASP.NET.

21

Trenutno aktualna verzija okružja 4.0 objavljena je u travnju 2010. godine. Dodana je

podrška za paralelizam u programiranju na višeprocesorskim sustavima i nove mogućnosti

u jezicima [25].

Važan cilj u razvoju okružja .NET je neovisnost o operacijskom sustavu na kojem se

aplikacije izvode. Praksa prije razvoja okružja .NET bila je da je svaki jezik imao svoje

knjižnice, s različitim pristupima, različitim načinima korištenja. Programerima je bilo

teško primijeniti svoje znanje jednog područja poput programiranja Web aplikacija na

drugo poput programiranja grafičkih aplikacija. Željelo se povećati mobilnost programera,

i ukloniti potrebu da se za svaku domenu problema mora učiti nove koncepte i nove

vještine. Uz to, cilj je bio ugraditi svojstvo objektne orijentiranosti, sakupljanje smeća i rad

s pokazivačima direktno u platformu, i ukloniti probleme koji nastaju kada o tome mora

brinuti programer [27].

Okružje .NET standardizirano je standardom ECMA-335 u prosincu 2001. godine, a

aktualna verzija standarda je iz lipnja 2006. godine. Standard definira osnovnu

infrastrukturu okružja pod nazivom CLI (engl. Common Language Infrastructure).

Okružje se sastoji od četiri ključna dijela: CTS (engl. Common Type System), CLS (engl.

Common Language Specification), metapodaci (engl. Metadata) i VES (engl. Virtual

Execution System) [28,29].

Specifikacija CTS definira tipove podataka koji postoje u jezicima razvijenim za

okružje .NET. U specifikaciji su sadržani svi tipovi podataka koji se uobičajeno nalaze u

suvremenim programskim jezicima, primjerice cijeli brojevi, pobrojani tipovi, stringovi.

Svaki jezik namijenjen za okružje s infrastrukturom CLI mora podržavati odgovarajući

podskup tih tipova. Praćenje specifikacije CTS osigurava veću robusnost i sigurnost

programa [29].

Specifikacija CLS predstavlja dogovor između dizajnera jezika i dizajnera okružja.

Sastoji se od određenog podskupa tipova iz specifikacije CTS te skupa pravila za

korištenje istih. Jezici koji se koriste u određenom okružju biti će najefikasniji ako koriste

samo tipove podataka iz specifikacije CTS, budući da se jedino na taj način može osigurati

uspješna integracija programskih modula pisanih u različitim jezicima [28]. U CLS je

sadržana i biblioteka osnovnih klasa – BCL (engl. Base Class Library), koja sadrži

programska ostvarenja osnovnih funkcionalnosti [29].

Metapodaci dodatno opisuju tipove podataka i načine korištenja na način nezavisan od

jezika. Time se omogućava razmjena podataka između alata za rad s jezicima, kao i za

komunikaciju sa sustavom za izvršavanje koda VES.

22

Sustav VES je programsko ostvarenje specifikacija CTS i CLS. On pruža usluge

izvođenja koda te upravljanja kodom i sigurnoću koda [29]. Kod pisan u jezicima koji su

CLI kompatibilni ne prevodi se u strojni kod, već u CIL (engl. Common Intermedate

Language). VES je odgovoran za prevođenje jezika CIL u strojni kod i njegovo

izvršavanje. Prevođenje koda ne izvršava se u cijelosti već se komadi programskog koda

prevode prema potrebi pri pozivima funkcija. Prevedeni dijelovi koda se spremaju u

priručnu memoriju (engl. cache) te se pri ponovnom pokretanju od tamo preuzimaju. Iz tog

razloga aplikacije prevedene u CIL pri opetovanim pokretanjima izvršavaju se sve brže.

Struktura okružja .NET prikazana je na slici 3.1.

Slika 3.1. – Struktura okružja .NET [29]

U osnovi okružja nalazi se Common Language Runtime, koji predstavlja ostvarenje

sustava VES. Više razine uključuju programske knjižnice. U najnižem sloju je skup

osnovnih knjižnica (engl. Base Class Library). Više razine sadrže knjižnice koje nisu

zahtijevane u specifikaciji CLI. Postoje knjižnice za rad s podacima poput baza podataka i

datoteka, knjižnice za grafička korisnička sučelja, programska sučelja i web sučelja. Na

najvišoj razini nalaze se programski jezici kompatibilni s .NET okružjem. Postoji preko 20

kompatibilnih jezika, među kojima su Python, Pascal, Fortran, Java, Visual Basic, C++ i

C# [30]. Posebnost .NET okružja i jezika koji se u tom okružju izvode je to da su

23

programske knjižnice ugrađene u platformu, a nisu dio jezika [29]. Dodatna prednost je da

programske knjižnice pisane u bilo kojem .NET kompatibilnom jeziku mogu koristiti svi

drugi .NET kompatibilni jezici.

Jezik C# je objektno orijentirani jezik namijenjen razvoju aplikacija na okružju .NET.

Pošto je razvijen kao ostvarenje specifikacije CLS, imao je jak utjecaj na razvoj okružja

.NET Razvio ga je Microsoftov tim predvođen inženjerima Andersom Hejlsbergom i

Scottom Wiltamuthom [31]. Hejlsberg je poznat po tome što je autor jezika Pascal i

Delphi. U jezik C# je ugrađeno iskustvo stečeno iz drugih programskih jezika poput jezika

Java, Object Pascal, C++, Eiffel i Modula-3 [32]. Pri razvoju se nastojalo omogućiti veću

pokretljivost programera između različitih domena, te ugraditi mogućnosti poput

sakupljanja smeća (engl. garbage collection), objektne orijentiranosti i rukovanja

greškama direktno u platformu, umjesto da se takve funkcionalnosti rješavaju dodatnim

zaglavljima i eksplicitnim pozivima funkcija [27]. Jezik C# ne prevodi se direktno u strojni

kod, već se prevodi u CIL (engl. Common Intermediate Language). U literaturi je moguće

naći i stariji naziv MSIL (engl. MicroSoft Intermediate Language). Takvo prevođenje

omogućava nezavisnost o platformi budući da je potrebno jedino ostvarenje okružja .NET

na računalu, kao i integriranje s programskim kodom pisanim u drugom jeziku, također

prevedenim u CIL [33]. Teoretski, C# prevoditelj može generirati bilo koji oblik strojnog

koda, no optimalno je prevođenje u CIL, budući da je sintaksa C# razvijena specifično da

odgovara sintaksi CIL.

Sintaksa jezika C# je rađena na način da bude lako prihvatljiva i prepoznatljiva

programerima jezika C/C++ te Java. Jezik C# i .NET platforma imaju ugrađene brojne

klase za razvoj web usluga i web aplikacija [33]. Ugrađena je dobra potpora za protokol

SOAP te za HTTP zahtjeve, čime je omogućeno lako povezivanje aplikacija u globalnoj

računalnoj mreži Internet.

3.2.2 Tehnologija ASP.NET U početku razvoja globalne računalne mreže Internet i World Wide Web sustava web

stranice bile su statičke, te je na njima svaku izmjenu sadržaja trebalo vršiti ručno. Za

potrebe suvremenih web stranica koje omogućavaju prikazivanje podataka u stvarnom

vremenu ili prilagođavanje sadržaja željama potrošača razvijene su tehnologije poput

Microsoft Active Server Pages (ASP). Tehnologija ASP omogućava izvršavanje koda na

poslužitelju koji ovisno o postupcima potrošača dinamički generira web stranicu [30].

24

Tehnologija je prvi put objavljena 1996. godine, i u prvim verzijama koristila je

skriptni jezik VBScript. Pošto je VBScript jezik interpretiran, performanse koda bile su

loše. Ograničenje na samo jedan jezik također je bilo odbojno programerima [30].

Paralelno s objavljivanjem okružja .NET, objavljen je i ASP.NET. Prelazak tehnologije

ASP na okružje .NET uklonilo je ograničenje glede jezika. Programski kod moguće je

pisati direktno u kodu stranice jezicima C#, VB.NET i JScript. Dodana je mogućnost

razdvajanja programskog koda u odvojene datoteke na poslužitelju tj. pozadinskog koda

(engl. Code behind), koji može biti u bilo kojem .NET jeziku [29]. Praksa pisanja

pozadinskog koda za web stranice dobra je jer omogućava dobro odvajanje prezentacijskog

sloja aplikacije od programske logike. Prelazak na .NET okružje također je donio

mogućnosti znatno lakšeg praćenja dosadašnjih akcija (engl. state management), za što je

prije bilo potrebno pisati mnogo koda. U okružju .NET samo okružje se brine za očuvanje

stanja sustava. Integracija okružja .NET s razvojnim okružjem znači da je web stranice

pisane tehnologijom ASP.NET moguće koristiti s podsustavom za pronalaženje i

otklanjanje greški (engl debugger) [30]. Jednako kao i za web stranice, tehnologiju

ASP.NET moguće je koristiti za izgradnju web usluga. Okružje .NET brine se o izlaganju

sučelja usluge i generiranju WSDL dokumenata koji uslugu opisuju.

3.2.3 Usluga Google Chart API

Usluga Google Chart API namijenjena je dinamičkom generiranju grafova. Pozivanje

usluge provodi se putem protokola HTTP korištenjem metode GET za manje količine

podataka odnosno korištenjem metode POST za veće količine podataka. Parametri se

mogu slati unutar identifikatora URI (engl. Uniform Resource Identifier) kod metode GET

ili unutar podataka koji se šalju prilikom korištenja metode POST. Kao odgovor na HTTP

zahtjev dobiva se slika koju je moguće prikazivati ili dalje obrađivati.

Podaci koji se u grafu prikazuju zadaju se parametrom "chd". Tom parametru

pridružuje se brojčani niz koji predstavlja podatke koji se ucrtavaju na graf. Podaci mogu

biti zapisani na četiri načina. Mogući zapisi su: tekstualni, tekstualni sa skaliranjem,

jednostavno kodiranje i prošireno kodiranje. Korištenjem ovih zapisa mogu se postići

različite preciznosti prikaza uz različite duljine identifikatora URI grafa.

Tekstualni način zapisa najjednostavniji je za korištenje, budući da je jedino potrebno

skalirati ulazne podatke u raspon brojeva između 0.0 i 100.0. Nedostatak je da se ovakvim

25

zapisom stvara najduži URI grafa. Ovakav zapis omogućava razlučivost od 1000

vrijednosti, te je prikladan za sve veličine grafova.

Pri korištenju tekstualnog zapisa parametru "chd" pridružuje se vrijednost "t:" i iza nje

niz decimalnih brojeva s jednim mjestom iza decimalne točke, odvojenih zarezima. Brojevi

moraju biti u rasponu 0.0 do 100.0. Posebno značenje ima broj -1, koji označava vrijednost

koja nedostaje. Ukoliko se šalje nekoliko skupova podataka, primjerice za iscrtavanje više

linija na istom grafu, oni se odjeljuju znakom "|".

Pojedini tipovi grafova podržavaju automatsko skaliranje podataka bilo kojeg raspona

u raspon između 0 i 100. Pri korištenju takvog zapisa, brojevi se ne moraju skalirati u

raspon 0 - 100. Umjesto toga, u URI se dodaje parametar "chds". Tom parametru

pridružuje se po jedan par vrijednosti za svaki skup podataka zadan parametrom "chd".

Prvi element para predstavlja minimalnu vrijednost koja se pojavljuje u skupu, a drugi

maksimalnu. Usluga preuzima na sebe posao skaliranja ulaznih podataka u raspon 0 – 100.

Vrijednost koja nedostaje označava se brojem manjim od minimalne vrijednosti za taj skup

podataka. Ako potrošač upiše manje parova vrijednosti nego skupova podataka, zadnji par

vrijednosti koristi se za skaliranje svih preostalih skupova podataka. Na taj način zadržana

je razlučivost kao i kod tekstualnog zapisa bez skaliranja, no potrošač usluge ne mora

brinuti o skaliranju podataka. Nedostatak je da svi tipovi grafa ne podržavaju ovaj zapis, a

URI je također vrlo dugačak.

Jednostavno kodiranje rezultira najkraćim identifikatorom URI. Njegov nedostatak je

razlučivost od samo 62 različite vrijednosti, te je prikladno samo za manje grafove ili

grafove gdje nije potrebna velika preciznost prikaza.

Pri jednostavnom kodiranju parametru "chd" pridružuje vrijednost "s:". Nakon toga

upisuje se niz slovnobrojčanih znakova koji predstavljaju brojeve 0 – 61 prema sljedećem

prikazu:

A – Z = 0 – 25; a – z = 26 – 51; 0 – 9 = 52 – 61.

Znak "_" označava podatak koji nedostaje. Ako se zadaje više skupova podataka,

odjeljuje ih se zarezom.

Prošireno kodiranje rezultira identifikatorom URI dužim od onog dobivenog

jednostavnim kodiranjem, ali kraćim od onog dobivenog tekstualnim zapisom. Prošireno

kodiranje omogućava razlučivost od 4096 različite vrijednosti, te je prikladno i za najveće

grafove. Nedostatak je što je programski najsloženije za ostvariti.

Pri proširenom kodiranju podaci parametru "chd" pridružuje se vrijednost "e:". Nakon

nje se nalazi niz brojeva kodiran na sličan način kao kod jednostavnog kodiranja. Uz

26

znakove koji se koriste pri jednostavnom kodiranju koriste se dodatno i "." te "-". Svaki

broj predstavljen je parom znakova. Vrijednost koja nedostaje prikazana je dvjema

podvlakama "__". Različiti skupovi podataka odvajaju se zarezom.

Kodiranje je izvedeno prema sljedećem prikazu:

AA = 0, AB = 1 ... AZ = 25

Aa = 26, Ab = 27 ... Az = 51

A0 = 52, A1 = 53 ... A9 = 61

A- = 62, A. = 63

BA = 64, BB = 65 ... BZ = 89

Ba = 90, Bb = 91 ... Bz = 115

B0 = 116, B1 = 117 ... B9 = 125

B- = 126, B. = 127

9A = 3904, 9B = 3905 ... 9Z = 3929

9a = 3930, 9b = 3931 ... 9z = 3955

90 = 3956, 91 = 3957 ... 99 = 3965

9- = 3966, 9. = 3967

-A = 3968, -B = 3969 ... -Z = 3993

-a = 3994, -b = 3995 ... -z = 4019

-0 = 4020, -1 = 4021 ... -9 = 4029

-- = 4030, -. = 4031

.A = 4032, .B = 4033 … .Z = 4057

.a = 4058, .b = 4059, … .z = 4083

.0 = 4084, .1 = 4085, … .9 = 4093

.- = 4094, .. = 4095

Slijedi usporedba različitih načina zapisa podataka:

Tekstualni:

chd=t:0.0,19.0,27.0,53.0,61.0,-1|12.0,39.0,57.0,45.0,51.0,27.0

Tekstualni sa skaliranjem:

chd=t:0.0,19.0,27.0,53.0,61.0,-1|12.0,39.0,57.0,45.0,51.0,27.0&chds=0,100

Jednostavno kodiranje:

chd=s:ATb19_,Mn5tzb

Prošireno kodiranje:

chd=e:AAATAbA1A9__,AMAnA5AtAzAb

27

Prilikom poziva usluge Google Chart API moguće je zadati dimenzije grafa i tip grafa.

Vrijednosti dimenzija grafa pridružuju se parametru "chs". U vrijednost parametra upisuje

se širina u pixelima, zatim znak "x" te visina u pixelima. Širina i visina grafa moraju biti

broj manji od 1000. Dodatno, graf može imati maksimalnu površinu od 300 000 pixela.

Ovo ograničenje ne odnosi se jedino na graf koji prikazuje kartu svijeta. Kod takvog grafa,

maksimalna širina je 440 pixela, a maksimalna visina 220.

Tip grafa određuje se pridruživanjem vrijednosti parametru "cht". Dostupni tipovi

grafova su:

Linijski grafovi (engl. line chart)

Stupčasti grafovi (engl. bar chart)

Grafovi oblika pite (engl. pie chart)

Vennovi dijagrami

Raspršeni dijagrami (engl. scatter chart)

Radar – grafovi (engl. radar chart)

Geografske karte

Google-mjerači (engl. google-o-meter)

QR kodovi (nalik na bar-kodove)

Karte svijeta ili regija

Izgled grafa može se dodatno prilagođavati opcionalnim parametrima. Ovisno o tipu

grafa može se odrediti naslov, boja i prozirnost grafa, debljina linija, dodati tumač

znakova, te dodati oznake za lakše očitavanje brojčanih vrijednosti s grafa [34].

28

3.3 Tehnologije za povezivanje korisničkog i poslužiteljskog sustava

U sustavu je potrebno ostvariti veze između komponenata na dvije razine. Prva razina

povezivanja skrivena je od potrošača i nalazi se između poslužitelja na kojem se nalazi

programska logika i udomljenika pomoću kojih se potrošaču izlažu mogućnosti

programske logike. Druga razina neposredno je dostupna potrošaču, a sastoji se u

međusobnom povezivanju udomljenika s ciljem izgradnje cjelovite aplikacije.

Za povezivanje poslužitelja s udomljenicima potreban je sustav koji jasno i

nedvosmisleno opisuje sučelja poslužiteljske i klijentske strane. Sustav mora omogućavati

prijenos različitih tipova podataka, kao i imati podršku za sigurnost.

Za međusobno povezivanje udomljenika potreban je sustav koji je potrošaču lako

shvatljiv, a istovremeno dovoljno moćan za izgradnju jedne aplikacije. Potrošač mora biti u

mogućnosti povezivanjem udomljenika složiti aplikaciju svojstava mjerljivih aplikaciji

pisanoj u nekom od viših programskih jezika.

3.3.1 Arhitektura SOA i tehnologija WS-* Arhitektura SOA (engl. Service Oriented Architecture) je koncept izgradnje sustava

kojim se želi postići labava povezanost među raznim komponentama sustava [35]. Svaki

sustav sastoji se od više elemenata koji se dijele u dvije grupe: pružatelji usluga (engl.

service provider) i potrošači usluga (engl. service consumer) [36]. Elementi sustava mogu

biti istovremeno i potrošači i pružatelji usluga. Za potrebe povezivanja važno je da i

pružatelj i potrošač imaju standardizirana sučelja i standardiziran opis sučelja, te da podaci

koje razmjenjuju budu u obliku standardiziranih poruka. Primjer komunikacije pružatelja i

potrošača usluge prikazan je na slici 3.2.

Slika 3.2. – Komunikacija pružatelja i proizvođača usluge u arhitekturi SOA [36]

Potrošač usluge oblikuje podatke potrebne za izvođenje usluge u standardiziranu

poruku te ju šalje pružatelju. Pružatelj usluge čita podatke te izvršava nad njima određenu

operaciju. Ta operacija može uključivati korištenje više drugih usluga, te u tom slučaju

29

pružatelj preuzima ulogu potrošača i opet započinje isti postupak prema nekom trećem

elementu sustava. Nakon završetka operacije, pružatelj rezultat izvođenja šalje nazad

potrošaču. Potrošač zatim podatke može dalje obrađivati, predočavati, ili može u ulozi

pružatelja usluge podatke slati nekom četvrtom elementu sustava.

Jasno definirana sučelja i standardizirane poruke osiguravaju laku nadogradivost

sustava i lako povezivanje više sustava. Pošto najmanja jedinica sustava više nije objekt,

programska funkcija ili odsječak koda, već usluga koja obavlja cjeloviti posao, postiže se

znatno bolja apstrakcija nego kod izgradnje sustava primjerice u objektno orijentiranom

programiranju [35].

Tehnologija WS-* (engl. Web Services) predstavlja ostvarenje ideje arhitekture SOA.

Pri izgradnji web usluga definirana su pravila [35]:

1) Protokol za komunikaciju je FTP, SMTP ili HTTP

2) Sve poruke moraju biti pisane jezikom XML, uz izuzetak privitaka koji mogu biti u

binarnom zapisu

Web usluge ostvaruju se kao REST web usluge ili SOAP web usluge. REST web

usluge oslanjaju se na protokol HTTP i jezik XML. Svaki pružatelj usluga je jedan resurs

(engl. resource), te je jednoznačno opisan svojim identifikatorom URI. Njihove prednosti

su jednostavnost i mali infrastrukturni zahtjevi pri ostvarivanju. U većini slučajeva

protokol HTTP dovoljno je dobar za ostvarenje svih potreba.

SOAP web usluge složenije su za ostvariti, ali imaju bolju nadogradivost. Također se

oslanjaju na protokol HTTP i jezik XML, no imaju naprednije mogućnosti. SOAP web

usluge oslanjaju se na jezik XML, koji služi kao osnova za izgradnju WSDL dokumenata i

SOAP poruka.

WSDL je jezik temeljen na jeziku XML koji se koristi za opisivanje usluga i načina na

koji se tim uslugama pristupa. WSDL je višeplatformski, neovisan je o sklopovlju i

programskom okruženju te je zato pogodan za opisivanje sučelja usluga. WSDL 1.0 je

razvijen 2000. godine od strane tvrtki IBM, Microsoft i Ariba za opis Web usluga kojima

se pristupa SOAP protokolom. Verzija 1.1 je formalizacija verzije 1.0 i ne uvodi nikakve

veće promjene. WSDL 1.2 iz 2003. godine je nacrt konzorcija W3C koji teži većoj

jednostavnosti i fleksibilnosti nego prethodne verzije. Verzija 1.2 je preimenovana u

WSDL 2.0 zbog značajnih razlika u odnosu na verziju 1.1. WSDL 2.0 je W3C preporuka

od 2007. godine i smatra se standardom. Promjene su: dodavanje semantike za opis jezika,

uklanjanje konstruktora message, nema potpore za preopterećenje operatora, portTypes su

preimenovani u interface, a ports su preimenovani u endpoints.

30

WSDL dokument opisuje Web uslugu koristeći četiri osnovna elementa:

portType – predstavlja operacije koje usluga izvodi;

message – predstavlja poruke koje koristi usluga;

types – predstavlja tipove podataka koje koristi usluga;

binding – predstavlja komunikacijske protokole koje usluga koristi.

Kostur praznog WSDL dokumenta prikazan je slijedećim kodom:

<definitions>

<types>

definition of types........

</types>

<message>

definition of a message....

</message>

<portType>

definition of a port.......

</portType>

<binding>

definition of a binding....

</binding>

</definitions>

Prvi i najvažniji element WSDL opisa je portType. Ovaj element opisuje Web uslugu,

operacije koje izvodi i poruke koje su u te operacije uključene, odnosno opisuje sučelja

Web usluge. Možemo ga usporediti s knjižnicom funkcija (ili klasom) u višim

programskim jezicima. Priključnica (engl. port) definira pristupnu točku Web usluge.

Drugi element je message, koji definira podatkovne elemente operacije. Svaka poruka

sastoji se od jednog ili više dijelova. Ovi dijelovi se mogu usporediti s parametrima poziva

funkcija u višim programskim jezicima.

Element types definira tipove podataka koji koristi Web usluga. WSDL koristi sintaksu

jezika XML za definiciju tipova podataka kako bi osigurao što veću platformsku

neovisnost.

Zadnji element binding definira format poruka i detalje protokola za svaku

priključnicu, odnosno za svaku operaciju.

SOAP (engl. Simple Object Access Protocol) je specifikacija, neovisna o platformi,

temeljena na jeziku XML, koja se koristi za razmjenu informacija između aplikacija preko

31

HTTP protokola. Omogućuje jednostavnu komunikaciju tekstualnim sadržajem preko

protokola HTTP koji je prilagođen upravo razmjeni tekstualnih sadržaja. Dosadašnje

aplikacije za međusobnu udaljenu komunikaciju koristile su pozive udaljenih procedura

metodom RPC (engl. Remote Procedure Calls). W3C je prvi opis ove specifikacije objavio

kao preporuku SOAP verzije 1.1. Danas W3C nastavlja s razvojem preporuke SOAP

verzije 1.2.

SOAP je izvorno bila kratica za Simple Object Access Protocol, no u međuvremenu je

postala kratica bez posebnog značenja [37], te predstavlja specifikaciju za slanje poruka

između web usluga. Sustav koji ostvaruje SOAP web usluge uz pružatelja i potrošača

usluga uvodi još i imenik usluga (engl. Directory). Struktura takvog sustava prikazana je

na slici 3.3.

Slika 3.3. – Sustav sa SOAP web uslugama [37]

Svaka web usluga opisana je standardnim jezikom za opis usluga WSDL, koji je baziran na

jeziku XML. Prilikom prijave usluge u imenik, pružatelj usluge šalje dokument pisan

jezikom WSDL u kojem je opisano sučelje usluge (broj 1 na slici). Dokument opisuje

tipove podataka (engl. data types) i poruke (engl. messages) kojima se podaci šalju.

Tipovi podataka i poruke grupirani su zajedno u operacije (engl. operations), koje

predstavljaju akcije koje usluga može napraviti. Operacije su grupirane po tipovima

priključnica (engl. port type). Zadnji sloj opisa, poveznice usluga (engl. service bindings)

32

povezuju apstraktne tipove portova sa stvarnim portovima, tj. stvarnim mrežnim adresama

[38].

Potrošač usluge šalje imeniku usluga zahtjev za određenom uslugom. Imenik kao

odgovor šalje WSDL dokument s opisom usluge (brojevi 2 i 3 na slici). Na temelju WSDL

opisa usluge potrošač može izgraditi SOAP poruke u formatu kakav usluga prihvaća, te

interpretirati SOAP poruke koje primi kao odgovore od pružatelja usluge (brojevi 4 i 5 na

slici) [37].

Specifikacija SOAP ima u sebi ugrađenu podršku za sigurnost, usmjeravanje poruka,

kao i za brojne tipove podataka. To znatno olakšava povezivost među sustavima i

osigurava laku nadogradivost u budućnosti.

33

3.3.2 Alat Geppeto Geppeto je alat za izgradnju aplikacija metodom povezivanja udomljenika. Postojeći

udomljenici služe kao moduli u izgradnji aplikacije umjesto funkcija i procedura, odnosno

objekata i klasa. Prilikom izgradnje aplikacije, potrošač zadaje ponašanje sustava koristeći

tri tipa udomljenika: TouchMe, TriggerMe i TickMe.

TouchMe udomljenik služi za objedinjavanje grupe udomljenika u jednu cjelinu koja

obavlja određeni posao. Izgradnja ovakvog udomljenika teče u dvije faze. U prvoj fazi

potrošač gradi sučelje novog kompozitnog udomljenika koristeći elemente sučelja

postojećih udomljenika. Nakon toga u drugoj fazi zadaje se ponašanje sučelja. Sustav

Geppeto omogućava zadavanje akcija nad sučeljima koje su intuitivno poznate prosječnom

potrošaču računala. Primjeri takvih akcija su kopiranje teksta iz okvira u okvir, stavljanje

kvačica uz opcije (engl. checkboxes), izabiranje opcija u padajućim izbornicima i upisi

teksta u okvire za unos teksta. Nizovi akcija koje potrošač zada pokreću se pritiscima na

tipke u sučelju kompozitnog TouchMe udomljenika. Primjer rada ovakvog udomljenika

prikazan je na slici 3.4. Sve akcije potrošač zadaje pritiscima na tipku miša, uz eventualno

korištenje tipkovnice, tako da nije potrebno apsolutno nikakvo poznavanje programskih

jezika.

Slika 3.4. – Primjer rada Geppeto TouchMe udomljenika

34

Kompozitni udomljenik, prikazan na slici lijevo, čeka pritisak na tipku „Draw Chart“

koja pokreće zadani slijed akcija. Slijed akcija prikazan je ispod udomljenika na način

kako ga potrošač može vidjeti u Geppeto sustavu. Nakon pritiska na tipku oznaka

vrijednosnice (engl. Ticker) kopira se iz kompozitnog udomljenika u udomljenik za dohvat

podataka o vrijednosnicama (broj 1 na slici 3.4.). Zatim pritišće tipku za dohvat podataka o

čeka da se akcija izvrši (broj 2 na slici 3.4.). Tako dobivene podatke kopira u udomljenik

za iscrtavanje grafikona (broj 3 na slici 3.4.) i pritišće tipku za iscrtavanje (broj 4 na slici

3.4.). Nakon iscrtavanja gotov grafikon kopira se nazad u kompozitni udomjenik (broj 5 na

slici 3.4.). Pojedini podaci na slici bili su unaprijed uneseni u sučelja udomljenika. Te

podatke može unijeti potrošač ili je moguće definirati dodatnu tipku u TouchMe

udomljeniku koja unosi podatke u sučelja osnovnih udomljenika. Ovako stvoren i

programiran kompozitni udomljenik može se koristiti i iz drugih kompozitnih udomljenika

na jednak način kao i ostali osnovni udomljenici, što je korisni pri izgradnji složenih

aplikacija kada je potrebno razbiti neku kompleksnu operaciju u logičke cjeline.

TriggerMe udomljenik služi za registriranje događaja u sustavu. Događaji u sustavu su

programski generirani signali koje mogu generirati drugi udomljenici, ili mogu dolaziti iz

drugih sustava poput senzora, informacijskih portala ili od potrošača. Primjeri događaja

koji se signaliziraju su signali da je logički uvjet petlje ispunjen (cijena dionice > 300),

povratna poruka poslana s korisničkog računa elektroničke pošte i obavijest da je mjerač

brzine vjetra detektirao orkan. TriggerMe udomljenik može kao reakciju na signal

pokrenuti jednu akciju u sustavu, primjerice pritisak na tipku u TouchMe udomljeniku koja

pokreće daljnji slijed akcija.

TickMe udomljenik radi na sličnom principu kao i TriggerMe, samo što umjesto da

reagira na vanjske signale iz sustava, reagira na vremenski signal. Potrošač zadaje

vremenski period u kojem treba izvršiti neku akciju, te je TickMe udomljenik ponavlja u

zadanim intervalima. Primjer takve akcije je: "Počevši danas od 12 sati, svakih 30 sekundi

pritisni tipku za iscrtavanje grafa na kompozitnom udomljeniku koji iscrtava povijest

cijene dionice za zadnjih 10 minuta" [39]. Primjer rada TickMe i TriggerMe udomljenika

prikazan je na slici 3.5.

35

Slika 3.5. – Primjer rada TickMe i TriggerMe udomljenika

Udomljenik TickMe ima zadan početni datum i vrijeme otkad treba početi izvršavati

akciju, interval u kojem treba ponavljati akciju i akciju koju treba izvršavati. Na slici je

zadan pritisak na tipku udomljenika Price checker, koji za zadanu oznaku vrijednosnice

dohvati cijenu, usporedi je sa zadanom i generira signal ukoliko je veća od zadane. Signal

se šalje u Geppeto sustav. Udomljenik TriggerMe ima zadan signal koji osluškuje i akciju

koju izvršava kada se signal pojavi. Na slici 3.5. je zadan signal koji šalje udomljenik Price

checker i akcija slanja poruke elektroničke pošte brokeru korištenjem udomljenika Mail

sender. Udomljenici Price checker i Mail sender mogu biti i osnovni i kompozitni

udomljenici. Signal koji generira udomljenik Price checker može osluškivati neograničen

broj TriggerMe udomljenika. Signali koje osluškuje TriggerMe udomljenik mogu dolaziti

iz Geppeto sustava, kao što je prikazano na slici 3.5. ili mogu dolaziti iz drugih sustava

koji signale šalju preko odgovarajućih programskih sučelja.

Alat Geppeto omogućava korištenje udomljenika na isti način kao što se u

programskim jezicima koriste programske knjižnice funkcija i procedura. U kombinaciji s

adekvatnim udomljenicima ima mogućnosti jednake programskim jezicima, no zahtjeva

mnogo manje stručnosti i predznanja potrošača.

36

4. Arhitektura ostvarenog sustava za financijsko upravljanje

U ovom poglavlju opisana je arhitektura ostvarenog sustava za financijsko upravljanje.

Potpoglavlje 4.1 opisuje arhitekturu cijelog sustava i podjelu na komponente. Potpoglavlje

4.2 opisuje arhitekturu udomljenika, potpoglavlje 4.3 arhitekturu web usluga, a

potpoglavlje 4.4 standardni zapis za kodiranje tabličnih podataka.

4.1 Arhitektura sustava

Sustav je podijeljen na dvije osnovne komponente: klijentsku komponentu i

poslužiteljsku komponentu. U Klijentska strana sastoji se od udomljenika, a poslužiteljska

od web usluga i njihove prateće podrške. Udomljenici se po svojem načinu rada dijele na

sučelja web usluga, samostalno ostvarene i kombinirane. Svi udomljenici i usluge popisani

su u imeniku usluga i udomljenika smještenom na poslužitelju. Struktura sustava prikazana

je na slici 4.1.

Slika 4.1. – Struktura sustava za financijsko upravljanje

Klijentska komponenta

Poslužiteljska komponenta

Pregled imenika usluga i udomljenika

Dohvat specifikacija udomljenika

Pozivi usluga

Korisnička interakcija

37

Potrošač interakciju sa sustavom ostvaruje putem grafičkih sučelja klijentske

komponente sustava. Komunikacija između klijentske komponente i poslužiteljske

komponente dijeli se na pregledavanje imenika usluga i udomljenika, prikazana punom

crtom, dohvat specifikacija udomljenika, prikazan kratko crtkanom crtom i pozive usluga

prikazane dugo crtkanom crtom. Za pregled imenika i dohvat specifikacija koristi se

protokol HTTP, a za pozive usluga protokol SOAP.

Na slici 4.2 prikazana je arhitektura klijentske strane sustava.

Slika 4.2. – Struktura klijentske komponente sustava

Na slici su prikazane tri vrste interakcije. Korisnička interakcija odvija se preko

grafičkih korisničkih sučelja web preglednika odnosno udomljenika. Međusobna

interakcija, prikazana unutar udomitelja odvija se putem alata Geppeto. Interakcija između

sustava i poslužitelja odvija se preko programskih sučelja poslužitelja.

Potrošač putem svojeg web preglednika može direktno pristupiti imeniku usluga i

udomljenika na poslužitelju. U imeniku usluga potrošač može pregledavati sve usluge koje

poslužitelj nudi i pregledavati njihove opise te dohvaćati opise programskih sučelja usluga

pisane jezikom WSDL. U imeniku udomljenika potrošač može pregledavati sve dostupne

udomljenike i njihove opise, te dohvaćati specifikacije udomljenika pisane jezikom XML.

Udomitelj udomljenika pokreće se unutar potrošačevog web preglednika. Udomitelj u

sebi ima podršku za dohvat specifikacija udomljenika i njihov prikaz, podršku za

Web preglednik

Udomitelj

Kombinirani udomljenik

Udomljenik sučelje web usluge

Samostalni udomljenik


Pozivi usluga

Korisnička interakcija

Pregled imenika usluga i

udomljenika

38

komunikaciju udomljenika s drugim domenama, te podršku za međusobno povezivanje

udomljenika korištenjem alata Geppeto. Putem sučelja udomitelja udomljenika potrošač

može zadati zahtjev za XML specifikacijom udomljenika koja se dohvaća s poslužitelja i

prikazuje.

Potrošač može direktno koristiti sučelja prikazanih udomljenika, ili može povezati više

udomljenika zajedno putem Geppeto sustava, te ih programirati da zajednički djeluju.

Udomljenici sučelja i kombinirani udomljenici komuniciraju s web uslugama putem SOAP

poruka, u kojima se mogu nalaziti jednostavni i složeni podaci.

Slika 4.3 prikazuje strukturu poslužiteljske komponente sustava.

Slika 4.3. – Struktura poslužiteljske komponente sustava

Poslužiteljska komponenta sastoji se od imenika usluga i udomljenika, modula sa

specifikacijama udomljenika i programskih ostvarenja usluga. Imenik obrađuje sve

zahtjeve za pregledom dostupnih usluga i udomljenika. Imenik po potrebi generira zahtjeve

za specifikacijama udomljenika te dohvaća specifikacije i prosljeđuje ih korisniku.

Zahtjevi za dohvatom šalju se direktno modulu sa specifikacijama udomljenika. Modul s

programskim ostvarenjima usluga obrađuje pozive usluga.

Poslužiteljska komponenta

Imenik usluga i udomljenika

Specifikacije udomljenika

Programska ostvarenja usluga

Pregledavanje imenika usluga i udomljenika


Pozivi usluga


39

Između udomljenika unutar udomitelja, kao i između udomljenika i web usluga

prenose se velike količine podataka zapisane u tabličnom obliku. Za potrebe prijenosa

takvih složenih podataka razvijen je poseban format zapisa temeljen na jeziku XML.

4.2 Arhitektura udomljenika

Po svojoj programskoj arhitekturi udomljenici se dijele na udomljenike sučelja usluga,

samostalne udomljenike i kombinirane udomljenike. Udomljenici sučelja usluga u sebi

imaju programsku podršku za kodiranje i dekodiranje podataka u SOAP poruke, te slanje i

primanje poruka. Obrada podatak izvršava se na poslužitelju. Prikladni su za složenije

postupke obrade kod kojih je vremensko ubrzanje zbog obrade u efikasnijem programskom

jeziku dovoljno veliko da opravda povećani vremenski trošak zbog komunikacije. Postoje

udomljenici sučelja usluga s lokalnim otkrivanjem greške i s udaljenim otkrivanjem

greške. Udomljenici s lokalnim otkrivanjem greške ne šalju poruke ukoliko na ulazu prime

grešku, dok udomljenici s udaljenim otkrivanjem greške šalju poruku bez obzira na sadržaj

i prepuštaju poslužitelju obradu greški. Na slici 4.4 prikazana je arhitektura udomljenika

sučelja web usluge s udaljenim detektiranjem greške.

Slika 4.4. – Arhitektura udomljenika sučelja web usluge s udaljenom detekcijom greške

Na slici je punim strelicama prikazan tok podataka, crtkanim strelicama prikazan tok

poruka o statusu, a strelicama s naizmjence crtom i točkom dojave o događajima između

modula.

Komunika-cijsko sučelje prema

udomitelju

Prikupljanje podataka i postavki

Serijalizacija podataka

Slanje poruke

Deserijalizacija podataka

Čekanje i primanje poruke

Elementi sučelja za

unos podataka Sekundarni element za prikaz podataka

Primarni element za prikaz podataka

Okidač

40

Podaci potrebni za pokretanje obrade uneseni su u elemente grafičkog korisničkog

sučelja za unos podataka od strane potrošača ili automatski od alata Geppeto. Obrada

podataka pokreće se nakon što modul okidač pošalje signal za pokretanje modulu za

prikupljanje podataka. Modul za prikupljanje podataka i postavki na temelju tekstnih

okvira, padajućih izbornika, okvira za stavljanje kvačica i ostalih elemenata postavi

vrijednosti programskih varijabli. Nakon što su podaci zapisani u varijable predaju se

modulu za serijalizaciju podataka koji ih smješta u unaprijed pripremljenu SOAP poruku.

Pripremljena SOAP poruka predaje se modulu za slanje poruke. Modul za slanje poruke

pomoću komunikacijskog sučelja udomitelja odašilje poruku poslužitelju i istovremeno

javlja sučelju da pozove modul za primitak poruke kad dođe povratna poruka od

poslužitelja. U slučaju da postoji više modula za primitak poruke, modul za odašiljanje

poruke mora odrediti koji se modul za primitak poruke poziva. Po dolasku poruke s

poslužitelja, odnosno po isteklom vremenu u kojem je poslužitelj morao odgovoriti

komunikacijsko sučelje udomitelja predaje poruku modulu za primitak poruke. Modul za

primitak poruke utvrđuje da li je poslužitelj uspješno odgovorio ili se dogodila greška.

Ukoliko je poslužitelj odgovorio, poruka se predaje modulu za deserijalizaciju. Modul za

deserijalizaciju odvaja korisne podatke iz SOAP poruke, obrađuje ih ukoliko je to potrebno

i prosljeđuje ih u primarni element za prikaz podataka. Svi moduli unutar udomljenika

dodatno ispisuju poruke o statusu procesiranja podataka na sekundarnom elementu za

prikaz podataka. Sekundarni element za prikaz podataka uz status prikazuje i greške koje

su se dogodile radi neispravnosti nekog dijela sustava, dok se greške koje su se dogodile

radi neispravnih podataka ispisuju u primarnom elementu za prikaz podataka. Samo

primarni element za prikaz podataka predviđen je da se iz njega podaci prosljeđuju u druge

udomljenike pomoću alata Geppeto.

Na slici 4.5 prikazana je arhitektura udomljenika sučelja web usluge s lokalnom

detekcijom greške. Udomljenik ima sve elemente kao i udomljenik s udaljenom detekcijom

greške, uz dodatak modula za detekciju greške prije modula za serijalizaciju. Modul za

detekciju greške provjeriti će sve ulazne podatke i sve postavke. Ukoliko bilo koji ulazni

podatak prepozna kao kodirani zapis poruke o greški, ili za bilo koju postavku zaključi da

je nevaljana, zaustaviti će normalan tok podataka, generirati novu poruku o greški i

proslijediti je direktno na primarni element za prikaz podataka. U protivnom, podaci se

obrađuju isto kao kod udomljenika s udaljenom detekcijom greške. Kod udomljenika s

lokalnom detekcijom greške implicitno je uključena i udaljena detekcija greške, budući da

41

neke greške može detektirati samo poslužitelj, primjerice greške pri dohvatu podataka s

vanjskog izvora.

Slika 4.5. – Arhitektura udomljenika sučelja web usluge s lokalnom detekcijom greške

Samostalni udomljenici ne komuniciraju s poslužiteljem tokom obrade podataka, već

se za obradu podataka oslanjaju isključivo na potrošačev web preglednik. Zbog relativno

ograničenih mogućnosti programskih jezika dostupnih unutar web preglednika u odnosu na

one dostupne na poslužitelju, samostalni udomljenici prikladni su za jednostavnije

postupke obrade podataka kod kojih ubrzanje zbog obrade na poslužitelju nije dovoljno da

opravda povećan vremenski trošak prouzročen komunikacijom. Slika 4.6 prikazuje

arhitekturu samostalnog udomljenika.

Slika 4.6. – Arhitektura samostalnog udomljenika


Dekodiranje podataka

Kodiranje podataka


unos podatakaSekundarni element za prikaz podataka


Okidač Detekcija greške

Obrada podataka

Komunika-cijsko sučelje prema

udomitelju


Serijalizacijapodataka

Slanje poruke

Deserijalizacija podataka

Čekanje i primanje poruke


unos podatakaSekundarni element za prikaz podataka


Okidač

Detekcija greške

42

Tok podataka u udomljeniku počinje na isti način kao i kod udomljenika sučelja web

usluga s lokalnom detekcijom greške. Nakon signala okidača, modul za prikupljanje

podataka i postavki pohrani podatke i postavke u odgovarajuće programske varijable.

Nakon toga, modul za detekciju greške provjerava da li je na ulaz udomljenika doveden

zapis o greški i da li su sve postavke ispravno zadane. Ukoliko je detektirana greška,

prosljeđuje se na primarni element za prikaz podataka, a odgovarajuća poruka se ispisuje

na sekundarni element za prikaz podataka. Ukoliko su podaci ispravni, šalju se modulu za

dekodiranje. Modul za dekodiranje potreban je samo ako se koriste tablični podaci, koje on

pretvara u odgovarajuće programske strukture podataka. Ako se dogodila greška pri

dekodiranju, modul za dekodiranje šalje je direktno na primarni element za prikaz

podataka. U protivnom šalje strukture podataka modulu za obradu podataka. Modul za

obradu podataka provodi zadanu operaciju nad podacima, te obrađene podatke šalje

modulu za kodiranje. U slučaju greške, šalje poruku o greški na primarni element za prikaz

podataka. Modul za kodiranje podataka kodira podatke u standardni format prije slanja na

primarni element za prikaz. Kao i kod prethodna dva tipa udomljenika, i kod samostalnog

udomljenika svi moduli šalju poruke o statusu obrade na sekundarni element za prikaz

podataka.

Kod pojedinih operacija moguće je da isplativost komuniciranja s poslužiteljem ovisi o

zadanim podacima, ili da je za neke dijelove obrade prikladnije izvršavanje na poslužitelju,

a neke u web pregledniku. U tom slučaju koriste se kombinirani udomljenici, koji se dijele

na dvije podgrupe: paralelne i serijske. Na slici 4.7 prikazana je arhitektura paralelnog

kombiniranog udomljenika.

Slika 4.7. – Arhitektura paralelnog kombiniranog udomljenika


Udaljena obrada

Sekundarni element za prikaz

podataka


unos podataka Primarni element za prikaz podataka

Okidač Odluka o načinu obrade

Samostalna obrada

43

Paralelno kombinirani udomljenik nakon prikupljanja podatke i postavke šalje modulu

za odluku o načinu obrade. Modul za odluku o načinu obrade odlučuje da li je isplativo

slati podatke poslužitelju na obradu te ih predaje modulu za udaljenu obradu ili modulu za

samostalnu obradu. Modul za udaljenu obradu predstavlja arhitekturu udomljenika sučelja

web usluge, a modul za samostalnu obradu arhitekturu samostalnog udomljenika. Iz obje

ove arhitekture izbačeni su moduli okidač i modul za prikupljanje podataka i postavki, te

elementi sučelja za unos i prikaz podataka, budući da su već sadržani u arhitekturi

kombiniranog udomljenika.

Serijski kombinirani udomljenik nema modul za odluku o načinu obrade budući da

uvijek obrađuje podatke i samostalno i udaljeno. Kod serijski kombiniranog udomljenika

podaci se predaju modulu za udaljenu obradu, a zatim modulu za samostalnu obradu ili

obrnuto, zavisno od potrebe operacije koju udomljenik ostvaruje. Serijski kombinirani

udomljenik uvijek podrazumijeva udaljenu obradu s lokalnom detekcijom greške budući da

zbog modula za samostalnu obradu ima u sebi modul za detekciju greške. Arhitektura

serijskog kombiniranog udomljenika prikazana je na slici 4.8

Slika 4.8. – Arhitektura serijskog kombiniranog udomljenika


Udaljena obrada

Sekundarni element za prikaz

podataka


unos podataka


Okidač Samostalna obrada

44

4.3 Arhitektura web usluga

Web usluge kojima se ostvaruju složenije funkcionalnosti u sustavu dijele se na

samostalne web usluge i web usluge s vanjskim izvorima podataka. Vanjski izvori

podataka mogu biti baze podataka, web stranice ili druge web usluge. Usluge su ostvarene

unutar okružja koje pruža funkcionalnosti potrebne za komunikaciju s udomljenicima i

vanjskim izvorima podataka.

Slika 4.9. prikazuje arhitekturu samostalne web usluge.

Slika 4.9. – Arhitektura samostalne web usluge

Tok podataka na slici prikazan je punom crtom, a tok poruka o greškama punom.

Dolazak poruke iz udomljenika u okružje koje podržava usluge pokreće obradu podataka

odgovarajućom uslugom. Podaci se prvo predaju modulu za detekciju greški. Modul

provjerava da li je u ikojem od parametara usluge doveden zapis greške, te ukoliko je,

prosljeđuje grešku modulu za kodiranje. Kod usluga koje se koriste u kombinaciji s

udomljenicima s lokalnom detekcijom greške ovaj modul može biti izostavljen. Ako nije

detektirana poruka o greški, podaci se prosljeđuju modulu za validaciju. Modul za

validaciju podataka provjerava jesu li svi podaci zapisani u ispravnom formatu i jesu li sve

postavke ispravno zadane. Ukoliko nije došlo do greške, podaci se predaju modulu za

dekodiranje podataka, a postavke modulu za dekodiranje postavki. Modul za dekodiranje

podataka pretvara standardan zapis tabličnih podataka u odgovarajuće programske

strukture, a modul za dekodiranje postavki dekodira postavke ukoliko je to potrebno

(primjerice ako su postavke zadane logičkim varijablama ili ključnim riječima). Podaci i

Kodiranje podataka

Komunikacijsko sučelje okružja

Detekcija greški

Validacija podataka


Dekodiranje postavki

Obrada

45

postavke predaju se modulu na obradu podataka koji izvršava operaciju nad podacima i

predaje ih modulu za kodiranje. Ukoliko se prilikom validacije, dekodiranja ili obrade

dogodila greška, prekida se normalan tok podataka i generirana poruka o greški direktno se

predaje modulu za kodiranje. Modul za kodiranje nakon što je dobio rezultat obrade, koji

može biti poruka o greški ili ispravni podaci, kodira ih u standardni format i putem sučelja

okružja šalje rezultate izvođenja operacije udomljeniku.

Slika 4.10. prikazuje arhitekturu usluge s vanjskim izvorom podataka.

Slika 4.10. – Arhitektura web usluge s vanjskim izvorom podataka

Nakon provjere greške, validacije i dekodiranja kao kod samostalne usluge, podaci i

postavke usmjeravaju se drugom modulu za kodiranje podataka. Drugi modul za kodiranje

podataka pretvara zapis podataka i postavki u programskim varijablama u zapis podataka i

postavki kakav prihvaća vanjski izvor podataka, te ih šalje vanjskom izvoru podataka

preko komunikacijskog sučelja okružja. Komunikacijsko sučelje okružja je samo jedno, a

prikazano kao dva modula radi bolje čitljivosti slike. Dio podataka može se proslijediti i

direktno modulu za lokalnu obradu, ovisno o ostvarenju usluge. Nakon što dođe odgovor

od vanjskog izvora podataka, podaci se predaju drugom modulu za dekodiranje koji ih

pretvara iz formata koji daje vanjski izvor podataka u odgovarajuće programske strukture.

Zatim se podaci mogu proslijediti modulu za lokalnu obradu (ako je potrebna) ili direktno

na modul za kodiranje koji ih kodira u standardni zapis i šalje udomljeniku. Kao i kod

Kodiranje podataka

Komunikacijsko sučelje okružja – komunikacija s udomljenikom

Detekcija greški

Validacija podataka


Dekodiranje postavki

Lokalna obrada

Komunikacijsko sučelje okružja – komunikacija s vanjskim izvorom podataka

Kodiranje podataka 2

Dekodiranje podataka 2

46

samostalne usluge, svi moduli mogu direktno poslati poruku o greški modulu za kodiranje i

prekinuti tok podataka ako se greška dogodi.

4.4 Standardni zapis za tablične podatke

Podaci kojima se rukuje u sustavu za financijsko upravljanje i analizu često su zapisani

u obliku tablica. U cilju lakšeg rukovanja s tablicama razvijen je standardni zapis podataka

kojeg koriste svi udomljenici i usluge u sustavu. Zapis podataka temeljen je na

pojednostavljenoj verziji jezika XML. Primarna namjena zapisa je prijenos tabličnih

podataka, no ugrađena je i podrška za skalare i poruke o greškama.

Pri zapisu tablica bitni podaci koji se moraju prenijeti su dimenzije tablice, oznake koji

redovi tablice predstavljaju imena redaka odnosno stupaca i podatke koji se u tablici

nalaze. Dodatno, kod pojedinih tablica potrebno je prenositi dodatne podatke o samoj

tablici poput naslova tablice, opisa podataka u tablici i slično. Primjer tablice i njenog

zapisa prikazan je na slici 4.11.

0 ZG RI SP

P 1 33 1

U 45 42 77

S 1 1 10

Slika 4.11. – Zapis tablice u standardnom formatu

Zapis je podijeljen na tri dijela: početnu oznaku, podatke i završnu oznaku. Početna

oznaka sadrži sve podatke o tablici, a podijeljena je na tri osnovna dijela. Prvi dio oznake

je obvezan, a ostala dva su neobvezni. Prvi dio oznake sadrži podatak da je zapis podataka

matrica, odnosno tablica, te broj redaka i broj stupaca odvojen znakom dvotočke. U

drugom dijelu oznake se zapisuju redni brojevi redaka i stupaca koji se označavaju kao

labele, odnosno ćelije s imenima stupaca i redaka, te koje se u obradi podataka ne dira.

Brojevi redaka s labelama pišu se sa sufiksom r, a brojevi stupaca sa sufiksom s. U

primjeru zapisa prvi redak i prvi stupac, koji su u tablici podebljani, su označeni kao labele

oznakama 0s i 0r. Treći dio oznake namijenjen je za dodavanje svih ostalih podataka i za

buduća proširenja zapisa. Od prva dva odvojen je znakom vertikalne crte. Zapisi u ovom

djelu zapisuju se kao parovi parametar=vrijednost. U primjeru zapisa naznačeno je da se

0|ZG|RI|SP|p|1|33|1|u|45|42|77|s|1|1|10 </m> <m4:4; 0r 0s | type=text title=“demo“>

47

radi o tekstualnoj tablici i da joj je naziv „demo“. Drugi dio zapisa sadrži podatke koji se u

samoj tablici nalaze. Podaci su zapisani na način da su pojedine ćelije tablice odvojene

znakom vertikalne crte, a zapisane su po retcima. U trećem dijelu zapisa nalazi se završna

oznaka koja označava kraj zapisa, a ima u sebi zapisano isto slovo kao prvi dio početne

oznake.

Zapis skalara i poruke o greški je jednostavniji. Zapis skalarnog podatka započinje

uokviren je oznakama <s> i </s>, a sve između njih interpretira se kao podatak. Zapis

poruke o greški uokviren je oznakama <e> i </e>, a tekst među njima se interpretira kao

opis greške.

48

5. Ostvarenje sustava za financijsko upravljanje

U ovom poglavlju opisani su rezultati rada na ovom diplomskom zadatku. Sustav za

udomljenika podesivih za financijsko upravljanje ostvaren u ovom radu temeljen je na

postojećim sustavima kao i na računskim operacijama kakve se susreću u ekonomiji. Svi

udomljenici razvijeni su i ispitani u web pregledniku Mozilla Firefox 3.5, udomitelju

udomljenika, a web usluge jezikom C# na okružju .NET 3.5. U potpoglavlju 5.1 opisane su

funkcionalnosti prepoznate kao bitne za izgradnju ovakvog sustava. Potpoglavlje 5.2.

opisuje logičku organizaciju usluga i udomljenika te tok podataka u sustavu. Potpoglavlja

5.3, 5.4 i 5.5 opisuju dijelove sustava zadužene za dohvat, obradu i prikaz podataka.

Potpoglavlje 5.6 opisuje ostvarenje posebne klase za rukovanje standardnim zapisom

podataka za tablične podatke, 5.7 vanjske izvore podataka, a potpoglavlje 5.8 ostvarenje

web usluga.

5.1 Zahtijevane funkcionalnosti sustava za financijsko upravljanje

Sustav razvijen u ovom diplomskom radu trebao je zadovoljiti zahtjeve iz područja

ekonomije i iz područja programiranja. Zahtjevi iz područja ekonomije odnose se na

mogućnosti dohvata, obrade i prikaza podataka, dok se zahtjevi iz područja programiranja

odnose na jednostavnost korištenja i mogućnosti izrade programa.

Po uzoru na sustave opisane u potpoglavlju 2.3 kao prva bitna funkcionalnost

izdvojena je dobava podataka te njihovo filtriranje odnosno prilagodba željama potrošača.

Potrošaču se mora omogućiti odabir podataka i filtriranje podataka po vremenu i po

identifikatoru vrijednosnice odnosno kompanije. Podaci koji se koriste u ovakvim

sustavima su podaci o vrijednosnicama, koji se mijenjaju u stvarnom vremenu tokom dana,

i periodička financijska izvješća, koja se izdaju tromjesečno odnosno godišnje.

Prema opisanim postupcima izračuna pokazatelja u financijskoj analizi opisanima u

potpoglavlju 2.1 izračun financijskih pokazatelja je izdvojen kao druga bitna

funkcionalnost. Pokazatelji izračunati iz financijskih izvješća daju uvid u stanje kompanije,

te je na temelju njih moguće odlučiti o tome da li je isplativo kompaniji odobriti zajam,

dopustiti preuzimanje druge kompanije ili nove investicije. Potrošaču je potrebno

49

omogućiti izračunavanje opisanih financijskih pokazatelja. Dodatno, potrebno je omogućiti

što više matematičkih operacija kako bi potrošač mogao i sam formulirati svoje izračune.

Treća bitna funkcionalnost, po uzoru na sustave iz potpoglavlja 2.3 je mogućnost

grafičkog prikaza podataka. Potrošaču je potrebno omogućiti da tablične podatke prikaže

kao grafove, radi lakše procjene trendova kretanja parametara kod podataka koji se

mijenjaju u vremenu, ili radi lakše usporedbe podataka uzetih iz više izvora.

Četvrta bitna funkcionalnost je praćenje promjene parametara i reagiranje na određene

događaje, po uzoru na naprednije sustave iz potpoglavlja 2.3. Potrošaču je potrebno

omogućiti zadavanje logičkih uvjeta kojima nadzire promjene podataka. Takvi logički

uvjeti korisni su pri donošenju odluka o kupnji ili prodaji vrijednosnica na temelju

ponašanja vrijednosnice u određenom periodu. Takve odluke mogu biti potkrijepljene i

podacima dobivenim iz prethodno izračunatih financijskih indikatora. Dodatno je potrebno

omogućiti dojavu događaja potrošaču ili nekom drugom, primjerice automatsko zadavanje

burzovnih naloga brokeru.

Sve funkcionalnosti moraju biti ostvarene na način koji je potrošaču lako shvatljiv.

Dijelovi sustava moraju biti lako povezivi, te svi moraju imati jasno definirana i

kompatibilna sučelja. Na taj se način također osigurava modularnost sustava, te laka

nadogradivost, budući da pojedine komponente sustava imaju minimalnu međusobnu

ovisnost.

5.2 Organizacija usluga, udomljenika i toka podataka u sustavu

Ostvareni sustav za financijsku analizu i upravljanje ostvaren je kao skupina

udomljenika. Većina udomljenika predstavlja sučelja prema programskim ostvarenjima

operacija koja je ostvarenih na poslužitelju kao web usluge. Pojedini udomljenici koji

ostvaruju programski nezahtjevne operacije nisu sučelja prema serveru već je sva

programska logika ostvarena u samom udomljeniku. Povezivanje udomljenika s

programskom logikom na poslužitelju ostvareno je korištenjem tehnologije WS-* i

protokola SOAP. Na poslužitelju su usluge organizirane na način da zajednički virtualni

direktorij dijele usluge srodne po domeni primjene. Direktorij za usluge opće namjene je

…/Kebap/, a za usluge specifične za financijsku analizu je …/Kebap-Finance/ Unutar

zajedničkog direktorija nalaze se usluge podijeljene po srodnim poslovima koje obavljaju,

primjerice usluga …/Kebap-finance/IO.asmx objedinjuje sve operacije za učitavanje

50

financijskih podataka. Organizacija usluga na poslužitelju prikazana je na slici 5.1. Na slici

su prikazane samo operacije koje imaju ostvarenje na poslužitelju.

Slika 5.1. – Organizacija usluga na poslužitelju

Po svojoj funkciji udomljenici se dijele na tri grupe: udomljenici koji dohvaćaju

podatke, udomljenici koji obrađuju podatke i udomljenici koji podatke prikazuju ili ih

prosljeđuju izvan sustava. Po svojoj domeni primjene, udomljenici su podijeljeni na

udomljenike opće namjene i specifične udomljenike za financijsku analizu i upravljanje.

Primjer podjele udomljenika po funkciji i toka podataka u sustavu prikazani su na slici

5.2. Udomljenici za dohvat podataka predstavljaju izvore, a udomljenici za prikaz ponore

podataka. Udomljenici za obradu mogu biti i izvori i ponori, te se među njima podaci

mogu usmjeravati u bilo kojem smjeru. Budući da je u sustavu jasno definiran jednoznačan

format podataka koji koriste svi udomljenici, u sustav potrošač lako može dodavati nove

udomljenike, dok god oni imaju podršku za sustav podataka.

51

Slika 5.2: Podjela udomljenika po funkcijama i tok podataka

Budući da se u sustavu potrošaču predočavaju samo podaci iz grupe udomljenika za

prikaz podataka, u sustavu se mora osigurati propagiranje greški do udomljenika za prikaz

podataka. Za lakše utvrđivanje uzroka greške potrebno je uz svaku grešku zabilježiti i

udomljenik u kojem je nastala. Da bi greške što manje opterećivale sustav, udomljenici

moraju biti optimirani na način da greška što brže kroz sustav dođe do udomljenika koji ju

prikazuju potrošaču. Udomljenici za dohvat i obradu podataka imaju ugrađenu podršku

koja u slučaju da je bilo koji ulazni parametar greška, odmah tu grešku propagiraju na

izlaz, bez ikakve obrade. Primjer prolaska greške kroz sustav i njenog predočavanja

potrošaču prikazan je na slici 5.3.

Slika 5.3 - Stvaranje greške, propagacija kroz sustav i prikazivanje

Obrada podataka

Dohvat

podataka

Prikaz

podataka

Google finance

udomljenik

Udomljenik Zagrebačke

burze

Udomljenik za učitavanje

tablica

Proizvoljni dodatni

udomljenik

Izračun pokazatelja

Razdvajanje tablica

Posebni nalozi

Spajanje tablica

Množenje

Logički udomljenik

Ispis tablice

Iscrtavanje grafa

Dojava potrošaču

Udomljenik za dohvat

podataka

Udomljenik za dohvat

podataka 2

Udomljenik za obradu

podataka

Udomljenik za obradu

podataka 2

Udomljenik za prikaz

podataka

Greška u obradi

Greška u dohvatu

Konkatenacija greški

52

U sustavu prikazanom na slici tok podataka prikazan je punom crtom, a tok poruka o

greškama isprekidanom crvenom crtom. Greške su se dogodile u prvom udomljeniku za

obradu podataka i u drugom udomljeniku za dohvat podataka. Oba udomljenika generirali

su kratke opise greški, te ih zajedno sa svojom oznakom kodirali u poruke o greškama.

Prvi udomljenik za obradu generirao je grešku oblika: "<e>Obrada podataka 1: Dijeljenje s

nulom</e>", a drugi udomljenik za dohvat podataka generirao je poruku oblika:

"<e>Dohvat podataka 2: poslužitelj nedostupan</e>". Dolaskom dviju poruka na drugi

udomljenik za obradu podataka u njemu je prekinut normalni tok podataka. Obje poruke o

greškama spojene su u jednu zajedničku oblika: "<e>Dohvat podataka 2: poslužitelj

nedostupan; Obrada podataka 1: Dijeljenje s nulom</e>". Zbog prekida normalnog toka

podataka nije pokretana nikakva obrada podataka u drugom udomljeniku za obradu

podataka, odnosno u usluzi koja ostvaruje njegovu funkcionalnost, zavisno o tome radi li

se u udomljeniku sučelju web usluge s lokalnom ili udaljenom detekcijom greške odnosno

o samostalnom udomljeniku. Konkatenirane poruke poslane su udomljeniku za prikaz

podataka koji je generirao prikaz greške. U slučaju da se za prikaz koristi udomljenik koji

iscrtava grafikone, greška je iscrtana uz lako uočljiv grafikon, a u slučaju da se radi o

tekstualnom ispisu generiran je tekst koji privlači pažnju potrošača, kako bi potrošač lakše

uočio da sustav ne radi ispravno.

53

5.3 Dobava podataka

Udomljenici za dohvat podataka osim što dohvaćaju podatke sa poslužitelja, vrše i

standardizaciju zapisa. Svi podaci u sustavu kodirani su u poseban format, prilagođen za

slanje tablica. U udomljenike se unose jednostavni podaci, upotrebom elemenata grafičkog

sučelja poput okvira za unos teksta, padajućih izbornika i gumbi. Izlaz iz udomljenika je

skup tabličnih podataka u standardiziranom zapisu.

5.3.1 Općenite funkcionalnosti Za dobavljanje podataka razvijen je jedan udomljenik opće namjene. Udomljenik

učitava tablične podatke zapisane u Sučelje udomljenika prikazano je na slici 5.4.

Slika 5.4. – Sučelje udomljenika za dohvat tabličnih podataka

Potrošač u okviru Name naslovljava dokument imenom koje mu je dao prilikom

uređivanja u alatu Google Docs. List dokumenta koji želi učitati može nasloviti njegovim

imenom ili njegovim rednim brojem u okviru Sheet. Ako tablica ima stupce ili retke koji

sadrže dodatne podatke poput labela redaka ili stupaca, potrošač ih može specificirati u

okvirima Label rows i Label cols.. Stavljanjem kvačice kraj Table is text određuje se kako

se tretiraju svi podaci u tablici koji nisu označeni kao labele. Ukoliko je kvačica stavljena,

svi podaci kodiraju se onako kako su zapisani. U protivnom, brojčani podaci se kodiraju

kako su zapisani, a svi podaci koji se ne mogu zapisati kao broj zamjenjuju se ključnom

riječi null koja označava nedostajući podatak. Ukoliko se prilikom učitavanja dogodila

greška, na izlazu se generira poruka o grešci. Ako je bilo koji od ulaznih podataka

prepoznat kao poruka o grešci, ona se direktno prosljeđuje na izlaz.

54

5.3.2 Funkcionalnosti specifične za ekonomsku analizu Za potrebe ekonomske analize i upravljanja razvijena su četiri para udomljenika.

Ostvareni su udomljenici za dohvat popisa uvrštenih vrijednosnica na burzi, dohvat

financijskih izvješća, dohvat trenutne cijene vrijednosnice i dohvat povijesti cijene

vrijednosnice. Svaku funkciju ostvaruje jedan par udomljenika, po jedan za Zagrebačku

burzu i portal Google Finance. Portalom Zagrebačke burze pokriveno je lokalno tržište,

dok portal Google Finance pokriva važnija strana tržišta. Oba udomljenika u svakom paru

imaju identična sučelja i identično ponašanje. Svi udomljenici su ostvareni na način da ako

im je na ulaz dovedena poruka o greški onda grešku proslijede direktno na izlaz i da

generiraju vlastite poruke o greškama ako se greške dogode.

Na slici 5.5. prikazano je sučelje udomljenika za dobavljanje popisa uvrštenih

kompanija na portalu Google finance. Potrošač može ograničiti koje ga burze zanimaju ili

može učitati sve kompanije sa svih burza.

Slika 5.5. – Sučelje udomljenika za učitavanje popisa uvrštenih kompanija

Na slici 5.6. prikazana su sučelja udomljenika za dohvaćanje financijskih izvješća i

trenutne cijene vrijednosnica. Potrošač naslovljava kompaniju, odnosno njenu

vrijednosnicu putem njene jedinstvene oznake na burzi (engl. ticker). U slučaju

financijskih izvješća moguće je nasloviti jednu vrijednosnicu po upitu, a u slučaju

trenutnih cijena moguće je nasloviti više njih.

Slika 5.6. – Sučelja udomljenika za dohvat financijskih izvješća i trenutnih cijena vrijednosnica

55

Na slici 5.7. prikazano je sučelje udomljenika za dohvat povijesnih cijena

vrijednosnica. Udomljenik ima tri načina rada: pregled dana, pregled više vrijednosnica za

jedan dan i pregled više dana za jednu vrijednosnicu. Načina rada određen je zadanim

parametrima.

Ako se unese samo datum, udomljenik dohvaća podatke za sve vrijednosnice na taj

dan. Ako se unese datum i jedna ili više oznaka vrijednosnice (engl ticker), dohvaća se

podatke o tim vrijednosnicama na taj dan. Ako se zada datum vrijednosnica i raspon (kao

pozitivan ili negativan cijeli broj), dohvaća podatke za tu dionicu kroz zadani raspon

počevši (pozitivan raspon) ili završivši (negativan raspon) zadanim datumom. Pri

zadavanju datuma moguće je unijeti i ključne riječi "today" i "yesterday" te cijeli brojevi

koji označavaju odmak od današnjeg dana, primjerice -20 označava datum koji je bio pred

20 dana.

Slika 5.7. – Sučelje udomljenika za dohvat povijesnih cijena vrijednosnice

5.4 Obrada podataka

Za obradu podataka razvijeni su udomljenici koji omogućavaju rukovanje podacima i

za matematičke te logičke operacije. Udomljenici za rukovanje omogućuju potrošaču da

izdvaja podatke iz tablica i uređuje tablice. Udomljenici za matematičke operacije

omogućuju osnovne matematičke operacije i specifične operacije prilagođene ekonomskoj

analizi. Logički udomljenici omogućuju zadavanje uvjeta i generiranje signala kada se

uvjet ispuni. Razvijen je logički udomljenik opće namjene i tri udomljenika prilagođena za

praćenje cijena vrijednosnica.

56

5.4.1 Općenite funkcionalnosti Za rukovanje podacima razvijeni su udomljenici koji omogućuju odabir podataka iz

tablice, proširivanje tablice novim podacima, prepisivanje starih podataka novima, iteracije

kroz niz podataka i implementacija reda.

Udomljenik za odabir podataka iz tablice prikazan je na slici 5.8. Udomljenik kao ulaz

prima postojeću tablicu, a za izlaz daje odabrane podatke. Ukoliko je odabrana samo jedna

ćelija, izlaz je vrijednost te ćelije kao jednostavan podatak. Ukoliko je odabrano više ćelija

izlaz je kodiran posebnim formatom zapisa za tablice. Odabir podataka se vrši zadavanjem

željenih redaka i stupaca. Retci i stupci mogu se zadati pobrojavanjem ili rasponom.

Pobrojavanjem se zadaju da se napišu redni brojevi stupaca/redaka, počevši od 1, ili

njihove labele. Pobrojani elementi se odvajaju duplim zarezom zbog mogućnosti da labela

ima u sebi jedan zarez. Zadavanje rasponom se radi crticom između početnog i konačnog

broja retka ili stupca. Moguće je kombinirati zadavanje pobrojavanjem i rasponom u istom

okviru za tekst.

Slika 5.8. – Sučelje udomljenika za odabir podataka iz tablice

Sučelje udomljenika za izmjenu sadržaja tablice prikazano je na slici 5.9. Udomljenik

prima originalnu tablicu i tablicu koja se dodaje. Zadaje se pozicija dodavanja, koja se

može zadati rednim brojevima redaka/stupaca ili njihovim labelama. Za dodavanje jedne

tablice do druge podržane su ključne riječi "left", "right", "above" i "below". Podatak

upisan u okvir "Pad with" upisuje se u sve ćelije nove tablice čina vrijednost nije

definirana. Može se zadati jedan od četiri načina rada: prepisivanje, horizontalno umetanje,

vertikalno umetanje ili umetanje ukriž (Cross insert).

57

Slika 5.9. – Sučelje udomljenika za izmjenu podataka u tablici

U načinu horizontalnog umetanja (engl. horizontal insert), prva tablica se presiječe po

vertikali desno od zadane ćelije. Nova tablica umetne se tako da je njen prvi redak

poravnat s retkom sa zadanom ćelijom, a desno od nje se umetne druga polovica originalne

tablice. Vertikalni način umetanja (engl. vertical insert) radi isto, samo što se originalna

tablica presiječe horizontalno ispod zadane ćelije, a nova se postavlja tako da je njen prvi

stupac poravnat sa stupcem sa zadanom ćelijom.

U načinu križnog umetanja (engl. cross insert), prva tablica presiječe se i horizontalno i

vertikalno, a nova tablica stavlja se da je njena lijeva gornja ćelija jedno mjesto desno i

jedno mjesto ispod zadane ćelije. Primjeri sva četiri načina rada prikazani su na slici 5.10.

Slika 5.10. – Četiri načina umetanja podataka u tablicu

58

Udomljenik za iteriranje kroz niz podataka, prikazan na slici 5.11, može raditi na dva

načina. Kao ulaz može primiti pobrojane zarezima odvojene podatke kroz koje mora

iterirati ili mu se može zadati tablica i redak/stupac u toj tablici kroz koji se iterira.

Pritiskom na odgovarajuće tipke iterira se prema naprijed (Next), prema nazad (Previous)

ili postavlja udomljenik u početno stanje (Reset). Iz početnog stanja pritiskom tipke za

naprijed postavlja se na početak niza, a za natrag na kraj niza. Kada se u iteraciji dođe do

kraja, na izlazu se generira poruka "#DONE#" koja signalizira kraj iteracije. Najveći dio

funkcionalnosti je ostvaren u samom udomljeniku, a manji pomoću web usluge.

Slika 5.11. – Sučelje udomljenika za iteriranje kroz niz podataka

Udomljenik koji ostvaruje strukturu reda predviđen je kao memorijski element za

upotrebu pri iscrtavanju grafova ili proračunima temeljenim na podacima prikupljenima u

stvarnom vremenu. Udomljenik prima tablicu sa starim podacima i stupac koji se u nju

dodaje. Zadaje mu se kapacitet (broj stupaca koliko je tablica široka) i smjer (u koju se

stranu podaci pomiču). Ukoliko se ne zada tablica sa starim podacima, udomljenik generira

novu. Sučelje udomljenika prikazano je na slici 5.12.

59

Slika 5.12. – Sučelje udomljenika koji ostvaruje strukturu reda

Za potporu odlučivanju razvijen je logički udomljenik. Udomljenik omogućava

potrošaču zadavanje proizvoljnog broja logičkih uvjeta. Potrošač u sučelje prvo unosi broj

uvjeta, te zatim generira prostor za unos uvjeta. Svaki uvjet prima par parametara, a

potrošač može izabrati kako se uspoređuju (<, <=, ==, !=, >, >=). Također može odabrati

radi li se među uvjetima logički "I" ili logički "ILI", tojest da li je izlaz istinit samo ako su

svi uvjeti ispunjeni ili je dovoljan jedan uvjet. Svaki se uvjet može negirati kvačicom.

Rezultati "TRUE" i "FALSE" s izlaza se mogu dovoditi na druge iste ovakve udomljenike

kako bi se mogla izgraditi složena stabla za složene uvjete. Moguće je i uključiti

generiranje signala kojima se logički udomljenik povezuje sa TriggerMe udomljenikom

Geppeto sustava te teko pokreće daljnje akcije. Sučelje udomljenika prikazano je slikom

5.13. Sva funkcionalnost je ostvarena u udomljeniku, bez ikakvih poziva web usluga.

Slika 5.13. – Sučelje logičkog udomljenika s dva logička uvjeta

60

Za matematičke operacije razvijen je udomljenik koji obavlja osnovne matematičke

operacije (+, -. *, /) nad skalarima i matricama, te udomljenik koji računa srednje

vrijednosti stupaca odnosno redaka matrice.

Na slici 5.14 prikazano je korisničko sučelje udomljenika za jednostavne aritmetičke

operacije (engl. Basic arithhmetic operations). Udomljenik kao ulaze prima dva operanda

koji mogu biti matrice ili skalari, te vraća rezultat operacije ili poruku o greški..

Udomljenik pruža funkcionalnost osnovnih računskih operacija nad podacima.

Slika 5.14. – Udomljenik za jednostavne operacije nad matricama

Udomljenik pruža i mogućnost rukovanja s "nepostojećim" podacima, koji se u

standardnom načinu zapisa obilježavaju sa "null". Potrošač u sučelju udomljenika može

izabrati način rukovanja s vrijednošću null:

- "null" - svaka operacija provedena nad podatkom null daje null kao rezultat

- "neutral element"– podatak null se tretira kao neutralni element za danu operaciju,

primjerice, za zbrajanju će se null tretirati kao 0, dok će se za množenje tretirati kao 1.

U standardnom obliku zapisa podataka potrošaču je omogućeno labeliranje podataka.

Nad elementima podataka koji su labele ne mogu se provoditi statističke operacije.

Udomljenik omogućava potrošaču da odabere želi li sačuvati labele ili ne. Na slici 5.15.

prokazan je način zbrajanja dvije matrice uz odbavianje labela, a na slici 5.16. zbrajanje

dvije matrice uz čuvanje labela prvog operanda.

61

Slika 5.15. – Operacija uz zanemarivanje labela

Slika 5.16. – Operacija uz zadržavanje labela prvog operanda

Udomljenik koji računa srednje vrijednosti redaka ili stupaca matrice kao ulaz prima

matricu i naputak računa li srednje vrijednosti redaka ili stupaca. Izlaz je vektor-redak ili

vektor-stupac koji sadrži tražene srednje vrijednosti. Sučelje udomljenika prikazano je na

slici 5.17.

Slika 5.17. – Sučelje udomljenika za izračun srednjih vrijednosti redaka ili stupaca matrice

5.4.2 Funkcionalnosti specifične za ekonomsku analizu Za potrebe ekonomske analize razvijeni su udomljenici koji rade proračune potrebne za

analizu financijskih pokazatelja i udomljenici za potporu upravljanju investicijama.

Razvijena su četiri udomljenika za proračun financijskih indikatora, koji računaju četiri

grupe indikatora: pokazatelje poluge (engl. leverage ratios), pokazatelje likvidnosti (engl.

liquidity ratios), pokazatelje operativne efikasnosti (engl. operating effuciency ratios) i

pokazatelje profitabilnosti (engl. profitability ratios). Imaju identična sučelja i način

korištenja. Udomljenici kao ulaz primaju podatke dobivene kao izlaz iz udomljenika za

dobavu financijskih izvješća s portala Google Finance i Zagrebačke burze. Izlaz je tablica

pokazatelja koja se može prikazivati u grafikonu, koristiti u daljnjim proračunima ili

62

koristiti u logičkom udomljeniku za provjeru uvjeta. Sučelje jednog od udomljenika iz ove

grupe prikazano je na slici 5.18.

Slika 5.18. – Sučelje udomljenika za izračun financijskih pokazatelja

Za potporu upravljanju investicijama također su razvijena dva para udomljenika.

Udomljenici predstavljaju burzovne naloge, te su predviđeni da ih se koristi ili kao

generatore signala koji se šalju direktno na burzu ili da ih se pomoću logičkih udomljenika

poveže s pošiljateljima obavijesti. Programska logika ova četiri udomljenika ne koristi web

usluge, već je ostvarena unutar koda udomljenika.

Prva dva udomljenika namijenjena su generiranju signala za prodaju kad je investitor

dovoljno zaradio ili je izgubio koliko je spreman izgubiti. Udomljenik "Stop Gain"

detektira kada je vrijednosnica porasla barem do zadane vrijednosti i generira signal za

prodaju. Udomljenik "Stop Loss" prati pad cijene vrijednosnice i generira signal za prodaju

kada cijena padne u blizinu zadane cijene. Udaljenost na kojoj će generirati signal

određena je brzinom pada vrijednosnice u prošlosti, čime se nastoji smanjiti rizik od

prekasnog reagiranja. Slika 5.19. prikazuje sučelja ovih udomljenika. Oba udomljenika

primaju kao ulazne podatke trenutnu cijenu vrijednosnice i graničnu cijenu koju potrošač

odredi. Kao izlaz daju tekst "true" ili "false".

Slika 5.19. – Sučelja udomljenika Stop Loss i Stop Gain

63

Drugi par udomljenika namijenjen je praćenju cijene vrijednosnice i reagiranju na

rizičniji način. Takozvani udomljenici "pohlepnici" nastoje držati dionicu do zadnjeg trena

rasta prije prodaje, odnosno odgoditi kupnju do zadnjeg trena padanja cijene s ciljem

maksimiziranja prihoda. Ako se promatra kretanje cijene dionice u vremenu kao funkcija

vremena cijena(t), prepoznaje se problem određivanja optimuma funkcije na zadanom

području vrijednosti, u ovom slučaju, u određenom vremenskom intervalu.

Nije moguće odrediti optimum funkcije ako ona nije unaprijed poznata (jer se

podaci o cijeni dobivaju u realnom vremenu), ali se može odrediti trenutak blizu

optimuma, na način da se djeluje kada promjena vrijednosti dionice poprimi suprotni trend

od onoga koji vodi prema optimumu (pozitivni smjer za prodaju, negativni smjer za

kupnju).

Udomljeniku se na ulaz dovodi trenutna tržišna vrijednost dionice ("Market price")

s udomljenika za dohvat podataka. Potrošač udomljenika zadaje korekcijski postotak, koji

određuje kolika promjena cijene u suprotnom smjeru od željenoga treba biti, da bi se

izvršila kupnja ili prodaja. Udomljenik na svom izlazu daje signal "BUY(cijena) " odnosno

"SELL(cijena) ". Ako akcija nije potrebna, udomljenik daje izlaz "false". Sučelja

udomljenika "pohlepnika" prikazana su na slici 5.20.

Slika 5.20. – Sučelja udomljenika "pohlepnika"

64

5.5 Prikaz podataka

Udomljenici za prikaz podataka mogu potrošaču podatke predočavati grafički ili

tablično. Poseban je slučaj udomljenik za dojavu potrošaču, koji omogućava sustavu da

dojavljuje određene događaje putem e-maila. Udomljenici također imaju namjenu

prikazivanja posebnih slika ukoliko prime poruku o greški, budući da svi tokovi podataka u

sustavu završavaju u udomljenicima za prikaz podataka.

5.5.1 Općenite funkcionalnosti Za prikaz podataka potrošaču razvijena su tri udomljenika. Omogućavaju prikaz

podataka kao tablicu, grafiranje podataka i slanje podataka potrošaču putem elektroničke

pošte.

Udomljenik za prikaz podataka u tabličnom obliku ostvaren je u normalnoj verziji i u

pojednostavljenoj verziji, koja je označena sufiksom „light“. Udomljenik ispisuje

primljenu tablicu kao HTML. Obična verzija dodatno podebljava sadržaj redaka i stupaca

koji su označeni kao labele (npr. imena dana u rasporedu sati). Pojednostavljena verzija

samo ispisuje tablicu, a koristi se u slučajevima kada nije potrebno ispisati dodatne podatke

poput naslova tablice niti naznačiti labele, već samo ispisati podatke. Sučelje s primjerom

ispisa kod obje verzije prikazano je na slici 5.21. Funkcionalnost pojednostavljene verzije

je ostvarena unutar koda udomljenika, bez upotebe web usluga, a funkcionalnost normalne

verzije je ostvarena kao web usluga na poslužitelju.

Slika 5.21. – Sučelje udomljenika za prikaz podataka u tabličnom obliku

Udomljenik za iscrtavanje linijskog grafa ostvaren je u pojednostavljenoj verziji,

označenoj sufiksom „light“, u kojoj se većina parametara grafa određuje automatski prema

danim podacima. Udomljenik prima tablične podatke koje treba grafirati i dimenziju grafa.

Maksimalna visina i širina je 1000 piksela, no površina grafa ne smije biti veća od 300 000

65

piksela. Potrošač dodatno može odabrati želi li iscrtati osi s labelama i legendom te mrežu

u pozadini.

Svaki redak u tablici interpretira se kao jedna linija u 2-d linijskom grafikonu. Svi retci

koji su označeni kao labele postavljaju se kao labele X-osi. Svi stupci označeni kao labele

postavljaju se kao labele Y osi. Dodatno, ako se na ulaz udomljenika dovede poruka o

grešci, udomljenik je ispisuje, te ispod nje crta graf s dvije prekrižene crvene crte.

Udomljenik za iscrtavanje grafova koristi uslugu Google Chart API. Sučelje

udomljenika s primjerom ispisa prikazano je na slici 5.22.

Slika 5.22. – Sučelje udomljenika za iscrtavanje linijskog grafa s primjerom ispisa za dionicu tvrtke

T-HT

Udomljenik za komunikaciju s potrošačem ostvaren je kao univerzalno sučelje prema

SMTP (engl. Simple Mail Transfer Protocol) poslužitelju. Kao ulaz prima adresu

primatelja i poruku koja se šalje. Potrošač može dodatno specificirati adresu, korisničko

ime i lozinku za SMTP poslužitelj koji koristi, ili koristiti predefinirani poslužitelj.

Udomljenik omogućava sustavu rad bez direktnog nadzora, budući da se sustav može

izgraditi tako da automatski kontaktira potrošača u slučaju da je potrebna njegova

intervencija. Sučelje udomljenika prikazano je na slici 5.23.

Slika 5.23. – Sučelje udomljenika za komunikaciju s potrošačem

66

5.5.2 Funkcionalnosti specifične za ekonomsku analizu Za potrebe ispisa razvijen je jedan udomljenik prilagođen ekonomskoj analizi.

Udomljenik iscrtava posebnu vrstu grafa pod nazivom svijeća na štapu (engl. candlestick

graph), nazvan tako prema svojem obliku. Graf je prilagođen prikazivanju dnevnih i

višednevnih trendova odjednom. Koristi četiri skupa podataka, koji predstavljaju najvišu

cijenu, početnu cijenu, zaključnu cijenu i najnižu cijenu. Raspon od najniže do najviše

prikazuje se štapom, A od početne do zaključne pravokutnikom. Ukoliko je zaključna

cijena viša od početne, pravokutnik je zelene boje, u protivnom je crvene boje.

Udomljenik prima iste podatke i parametre kao i udomljenik za iscrtavanje linijskog

grafa. Tablica s podacima mora imati barem četiri skupa podataka kako bi se graf iscrtao.

Ako u tablici postoje redovi s labelama "high", "low", "open" i "close", pridružuju se

odgovarajućim mjestima u grafu. Ukoliko ne postoje, prvi skup podataka se interpretira

kao najniža cijena, drugi kao početna cijena, treći kao zaključna a četvrti kao najviša. Svi

ostali skupovi podataka se zanemaruju. Kao i udomljenik za iscrtavanje linijskog grafa,

udomljenik za iscrtavanje grafa svijeća na štapu ispisati će grešku kao dvije prekrižene

crvene crte s tekstom greške. Na slici 5.24. prikazano je sučelje udomljenika s primjerom

ispisa.

Slika 5.24. – Sučelje udomljenika za iscrtavanje grafa svijeća na štapu s primjerom ispisa za dionicu

tvrtke Končar d.d.

67

5.6 Ostvarenje programske klase za rukovanje standardnim zapisom podataka

S ciljem olakšavanja obrade standardnog zapisa podataka, u jeziku C# razvijena je

posebna apstraktna programska klasa pod nazivom Gyros koja predstavlja taj oblik

podataka i omogućava obavljanje različitih operacija nad njim. Apstraktna klasa nasljeđuje

se u četiri klase koje predstavljaju četiri moguća tipa podataka. Slika 5.25 prikazuje

dijagram klase Gyros i klasa koje ju nasljeđuju.

Slika 5.25. – Dijagram klase Gyros

68

Apstraktna klasa Gyros sadrži osnovne strukture podataka koje su zajedničke svim

tipovima podataka. U klasi su nadjačani operatori i implementirane virtualne metode, koje

su namijenjene za nadjačavanje u drugim klasama. U slučaju da nisu nadjačane, virtualne

implementacije javljaju poruke o greškama. Četiri klase nasljeđuju klasu Gyros: matrica,

tekstualna matrica, skalar i greška. Klasa matrica predviđena je za tablice koje sadrže

brojčane podatke, dok tekstualni podaci mogu biti samo u retcima i stupcima označenim

kao labele. Podaci koji nisu labele i koji se ne mogu interpretirati kao brojevi mijenjaju se

ključnom riječju null. Tekstualna matrica podržava bilo kakav tip podataka u svim

ćelijama, ali ne podržava nikakve matematičke operacije. Skalar ne koristi strukturu

podataka matrice, već pohranjuje samo jedan broj, a greška pohranjuje samo zapis poruke

o greški.

Apstraktna klasa Gyros u sebi sadrži programsku strukturu za pohranu tablice kao niza

stringova, pohranu brojeva svih redaka i stupaca koji su označeni kao labele, pohranu

labela i zapis o tome kojeg je podatak tipa. Također sadrži konstante koje se koriste za

oznaku tipa i za nulu pri operacijama nad brojevima s pomičnom točkom. Sve klase koje je

nasljeđuju moraju ostvariti metodu za vraćanje standardnog zapisa.

Klase matrica i tekstualna matrica sadrže metode za izdvajanje podataka iz tablice,

dodavanje podataka u tablicu odnosno povezivanje više tablica u jednu i ostvarivanje

podatkovne strukture reda.

Klasa matrica dodatno ima ostvarene metode za računanje aritmetičkih sredina redova

ili stupaca matrice, operatore +, - i *; kao i posebnu strukturu podataka za numeričke

podatke, koja čuva samo retke i stupce koji nisu labele kao brojčane podatke s pomičnom

točkom.

Metoda VratiGyros() u svim klasam koristi se za kodiranje programskih struktura

podataka u standardni zapis. Za suprotnu operaciju razvijena je posebna klasa

GyrosInterpreter, koja pozivom metode GenerirajGyros() stvara novu instancu

odgovarajuće klase, ovisno o danim podacima. Metoda GenerirajGyros() kao parametar

može primiti standardni zapis primljen iz udomljenika ili skup podataka koji opisuju

tablicu.

Klase Gyros i GyrosInterpreter sadržane su u prostoru imena Kebap_Gyros.

69

5.7 Vanjski izvori podataka

Za dobavljanje podataka o vrijednosnicama i tvrtkama korišteni su portal Google

Finance za svjetske burze, a web stranica Zagrebačke burze i portal mojedionice.com za

podatke o vrijednosnicama i tvrtkama Zagrebačke burze. Za generiranje grafikona

korištena je web usluga Google Chart API.

Portal Google finance omogućava dohvaćanje podataka o trenutnoj cijeni vrijednosnice

u HTML formatu, kao i financijska izvješća. Podatke o povijesnim cijenama vrijednosnice

i popis svih uvrštenih tvrtki moguće je dobiti u .CSV formatu. Dohvat svih podataka vrši

se pomoću HTTP GET zahtjeva. Usluge za dohvat podataka dohvaćaju HTML stranicu

odnosno .CSV dokument, parsiraju ga i pretvaraju u standardni zapis tablice. Kod dohvata

popisa svih uvrštenih tvrtki koristi se sljedeća posebna metoda. Budući da dohvat svih

uvrštenih tvrtki traje dugo, a podaci se rijetko mijenjaju, nakon prvog dohvata se popis svih

tvrtki sprema u posebnu datoteku na poslužitelj. Sljedećih sedam dana svi dohvati popisa

tvrtki se obavljaju iz datoteke, a po isteku trideset dana datoteka se ažurira.

Web stranica Zagrebačke burze omogućava dohvat popisa svih uvrštenih tvrtki i

povijesne cijene dionice u HTML formatu. Dohvat trenutne cijene dionice moguć je u

tekstualnom formatu. Svi zahtjevi rade se pomoću HTTP GET zahtjeva, a usluge parsiraju

HTML stranice odnosno tekst i pretvaraju ga u standardni zapis tablice.

Portal mojedionice.com omogućava dohvat financijskih izvješća u HTML formatu.

Budući da besplatna verzija stranice ima ograničenje na broj zahtjeva koji je u kratkom

roku dozvoljeno izvršiti, rasterećenje je izvršeno na sličan način kao i kod portala Google

finance. Prilikom prvog dohvata izvješća za određenu tvrtku, izvješće se pohranjuje u

lokalnu datoteku na poslužitelj. Sljedećih mjesec dana se svi zahtjevi za tom dionicom

preusmjeravaju na lokalnu datoteku, nakon čega se ona ažurira svježim podacima s

poslužitelja.

Pri generiranju grafova koristi se usluga Google Chart API. Pri pozivu usluge uvijek se

koristi metoda POST i prošireno kodiranje budući da omogućavaju najviše podataka,

najbolju vertikalnu razlučivost i najkompaktniji zapis. Dobivene slike kodiraju se u base64

format i šalju udomljeniku koji ih može prokazati kao sliku bez ikakve dodatne obrade. Za

potrebe kodiranja podataka u prošireno kodiranje razvijena je posebna klasa

KoderZaProširenoKodiranje koji omogućava pretvorbu brojčanih podataka u

slovnobrojčani zapis sa 63 znamenke kakav koristi Google Chart API.

70

5.8 Ostvarenje web usluga

Web usluga u sustavu ostvarene su korištenjem tehnologije ASP.NET i jezika C#.

Okružje ASP.NET pruža podršku za pozivanje web usluga putem SOAP poruka,

komunikaciju web usluga s vanjskim izvorima podataka i generiranje WSDL opisa sučelja.

Ostvarenja funkcionalnosti ostvarena su u zasebnim datotekama s pozadinskim kodom

(engl. code behind) pisanima u jeziku C#. Jezik C# omogućava jednostavno korištenje

brojnih struktura podataka, laki razvoj dodatnih klasa. Brojne knjižnice koje se isporučuju

uz postojeće web usluge, poput knjižnice za Google Docs omogućavaju jednostavno

korištenje tih usluga.

Sve usluge smještene su u jedinstvenom direktoriju, koji sadrži .asmx web stranice s

njihovim programskim sučeljima i .dll datoteke s ostvarenjima pozadinskog koda. U

direktoriju je također smještena mapa resources u kojoj se nalaze sve lokalne datoteke

potrebne za rad sustava kao i datoteka Kebap.ini koja sadrži postavke sustava.

71

6. Zaključak U ovom radu opisana je teoretska podloga financijske analize, predviđanja zahtjeva

potrošača te način ispunjenja zahtjeva. Opisana je arhitektura i ostvarenje sustava za

financijsku analizu.

Ostvareni sustav sastoji se od programske logike koja je smještena na poslužitelju i

skrivena od potrošača te udomljenika koji su dostupni potrošaču. Programska logika

izložena je u obliku web usluga, te se može koristiti pozivima iz programskih jezika

odnosno iz vlastitih udomljenika. Potrošaču su dostupni i gotovi udomljenici koji

predstavljaju sučelja ostvarenih usluga. Dostupni su i udomljenici koji nisu sučelja prema

web uslugama, već je programska logika ostvarena u njima, te se izvršava u web

pregledniku potrošačkog računala. Potrošač može izgraditi složenu aplikaciju koristeći

dostupne udomljenike kao građevne blokove, a alat Geppeto kao sredstvo za povezivanje.

Sustav omogućava dohvat tabličnih podataka, njihovu matematičku obradu i prikazivanje,

odnosno reagiranje na postavljene uvjete. Posebno su razvijeni udomljenici prilagođeni

financijskoj analizi i upravljanju. Financijski udomljenici omogućavaju dohvat podataka o

vrijednosnicama s Zagrebačke burze koja pokriva lokalno tržište i portala Google finance,

koji pokriva većinu važnih svjetskih burzi. Omogućavaju obavljanje proračuna i izračun

pokazatelja kojima se može ocjenjivati stanje tvrtke koja izdaje vrijednosnice te praćenje

cijena vrijednosnice i detektiranje promjena trendova. Udomljenik za automatsko javljanje

potrošaču omogućava sustavu da radi bez nadzora i javlja se potrošaču samo kad je

intervencija potrebna.

Prednosti sustava su jednostavnost, modularnost i nadogradivost te neovisnost o

okružju u kojem se koristi. Korisnik ne mora poznavati programske jezike niti

programerske koncepte da bi koristio sustav. Udomljenici kao građevni blokovi

međusobno su neovisni, a zahvaljujući standardiziranom zapisu podataka moguće je

dodavanje novih. Budući da se cijeli sustav pokreće unutar web preglednika, ne ovisi o

operacijskom sustavu računala te se bez preinaka može koristiti u bilo kojem okružju.

Sustav se može prilagoditi i za druge domene primjene pri kojima je važno jednostavno

formiranje vlastitih tokova podataka, poput meteorologije, nadzora pametnih kuća ili

upravljanja proizvodnim procesima. Zahvaljujući standardiziranom zapisu podataka

moguće je razviti nove udomljenike koji ostvaruju dodatnu obradu ili koriste nove izvore

72

podataka. U budućnosti je moguće razviti udomljenike za dvosmjernu komunikaciju s

potrošačem pomoću više kanala poput instantnih poruka ili SMS usluga.

73

7. Literatura

1. Srbljić, S; Škvorc, D; Skrobo, D; Widget-Oriented Consumer Programming;

AUTOMATIKA: časopis za automatiku, mjerenje, elektroniku, računarstvo i

komunikacije, Vol.50 No.3-4 Prosinac 2009.

2. Brealy, R. A., Myers, S. C., Marcus, A. J.: Fundamentals od corporate Finance,

McGraw-Hill, New York, 2001.

3. Reilly, F., Brown, K.: Investment analysis and portfolio management, The Dryden

Press, Fort Worth, Texas, 2000.

4. Bodie, Z., Kane, A., Marcus, A. J.: Investments, McGraw-Hill, New York, 2001.

5. Palepu, K. G., Healy, P. M., Bernard, V. L.: Business analysis & valuation: using

financial statements : text & cases, Thomson/South-Western, 2004.

6. Zagrebačka burza; www.zse.hr; 20. 5. 2010.

7. MojeDionice.com – HDPG-R-A: Bilanca;

http://www.mojedionice.com/fund/IzvFinIzv.aspx?sifSim=HPDG-R-

A&idFinIzv=1; 20. 5. 2010.

8. Dionice – Limun.hr; http://www.limun.hr/dionice.aspx?dionice=KOEI-R-A; 29. 5.

2010.

9. My Portfolio – Google Finance;

http://www.google.com/finance/portfolio?action=view&pid=1; 20. 5. 2010.

10. Kapital-Plus – Portfelji; http://kapital-plus.net/index.php?Portfelji; 20. 5. 2010.

11. Agram Brokeri; https://online.agram-brokeri.hr/; 14. 6. 2010.

12. http://en.wikipedia.org/wiki/JavaScript; 4. 5. 2010.

13. http://www.htmlgoodies.com/beyond/javascript/article.php/3470971; 4. 5. 2010.

14. http://en.wikipedia.org/wiki/JScript; 4. 5. 2010.

15. http://en.wikipedia.org/wiki/ECMAScript; 4. 5. 2010.

16. http://en.wikipedia.org/wiki/Duck_typing; 4. 5. 2010.

17. Kasprzak, J., Greasemonkey and Security: Attempting to Summarize What You

Need to Know, 16. 2. 2008, http://jake.kasprzak.ca/2008/02/16/greasemonkey-and-

security-attempting-to-summarize-what-you-need-to-know-part-1-of-3/; 4. 5.

2010.

18. http://www.w3.org/DOM/; 4. 5. 2010.

74

19. Peterson, Dan; Let's get this shindig started; 12. 12. 2007.

http://blog.opensocial.org/2007/12/lets-get-this-shindig-started.html; 5. 6. 2010.

20. Shindig – Welcome to Apache Shindig; http://shindig.apache.org/; 5. 6. 2010.

21. Frequently asked questions – OpenSocial – Google Code;

http://code.google.com/apis/opensocial/faq.html; 4. 5. 2010.

22. Main page – OpenSocial;

http://wiki.opensocial.org/index.php?title=Main_Page#Container_Information; 4.

5. 2010.

23. Welcome to Apache Shindig; http://shindig.apache.org/; 4. 5. 2010.

24. Gadgets.io API reference;

http://wiki.opensocial.org/index.php?title=Gadgets.io_%28v0.9%29; 4. 5. 2010.

25. .NET framework; http://en.wikipedia.org/wiki/.NET_Framework; 7. 5. 2010.

26. What is Mono; http://mono-project.com/What_is_Mono; 7. 5. 2010.

27. Naomi Hamilton, The A-Z of Programming Languages: C#; 1. 10. 2008,

http://www.computerworld.com.au/article/261958/a-

z_programming_languages_c_/; 5. 5. 2010.

28. Standard ECMA-335, Common Language Infrastructure (CLI); 1. 6. 2006;

http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-335.pdf; 7.

5. 2010.

29. Mayo, J; C# Ekspert; Miš, 2002. Zagreb

30. .NET Framework Supported Languages;

http://www.startvbdotnet.com/dotnet/languages.aspx; 7. 5. 2010.

31. Liberty, J; Xie, D; Programming C#, 5th edition; O'Reilly Media, 2008.

32. C Sharp (programming language);

http://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29; 5. 5. 2010;

33. Liberty, J; Xie, D; Programming C#, 4th edition; O'Reilly Media, 2005.

34. Google Chart Tools / Image Charts (aka Chart API) – Google code;

http://code.google.com/apis/chart/image_charts.html; 8.6.2010.

35. Hao He, What is Service Oriented Architecture; 31. 3. 2006;

http://pesona.mmu.edu.my/~wruslan/SE2/Readings/detail/Reading-28.pdf; 12. 5.

2010.

36. Douglas K. Barry, Service-Oriented Architecture (SOA) definition;

http://www.service-architecture.com/web-services/articles/service-

oriented_architecture_soa_definition.html; 12. 5. 2010.

75

37. Douglas. K. Barry; Web Services Explained; http://www.service-

architecture.com/web-services/articles/web_services_explained.html; 12. 5. 2010.

38. Douglas. K. Barry; Web Services Description Language (WSDL)

http://www.service-architecture.com/web-

services/articles/web_services_description_language_wsdl.html; 12. 5. 2010.

39. Geppeto home page; http://geppeto.fer.hr/install.html; 13.5. 2010.

76

Sažetak Rad opisuje sustav udomljenika podesivih za potrošačko financijsko upravljanje.

Opisane su osnovne metode financijske analize i upravljanja. Iz metoda kao i iz

suvremenih financijskih portala izdvojene su funkcionalnosti koje bi sustav trebao

zadovoljiti. Potrošaču je omogućena izrada aplikacija koje dohvaćaju, obrađuju i prokazuju

financijske podatke, te reagiraju na događaje prema zadanim uvjetima. Sustav je podijeljen

na općeniti dio, koji je potencijalno primjenjiv i u drugim domenama osim ekonomije i dio

koji je specifičan za ekonomiju. Za financijsku analizu i upravljanje dostupni su podaci sa

Zagrebačke burze i s portala Google finance.

Ključne riječi: financijska analiza, udomljenici, kompozicija udomljenika, kompozicija

web usluga

77

Summary This thesis describes a system of web gadgets for consumer oriented financial

management. It also describes some elementary methods used in financial analysis and

management. Key functionalities the system had to implement were modelled after

methods most commonly used and after contemporary financial portals in the world.

. The user can develop applications to fetch, process and display financial dana, as well

as to react to certain events in the system. The system has a general-purpose section which

can be of use in other domains of application appart from economy and a section specific

to economy. Data from Zagreb Stock Exchange and from Google finance is available for

processing.

Keywords: financial analysis, gadgets, gadget composition, web services composition

Documents

Sustav udomljenika podesivih za potrošačko financijsko ...2.2 Upravljanje investicijama Za razliku od financijske analize, koja služi za ocjene ponašanja firme u dužim periodima