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.
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.
1 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
2 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
3 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.
4 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
5 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
6 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.
7 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.
8
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
9 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.
10
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]
11 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]
12 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]
13 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.
14
Slika 2.11. – Zadavanje naloga u sustavu Agram Trader [11]
Slika 2.12. – Pregled naloga u sustavu Agram Trader [11]
15 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
16 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,
17 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.
18 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].
19
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.
20 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.
21 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
22 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].
23 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
24 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
25 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
26 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].
27 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
28 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.
29
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:
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
30 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)
31 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.
32 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
33
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.
34
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.
35 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.
Klijentska Poslužiteljska komponenta komponenta Pregled imenika usluga i udomljenika
Dohvat specifikacija udomljenika
Korisnička interakcija Pozivi usluga
Slika 4.1. – Struktura sustava za financijsko upravljanje
36 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.
Web preglednik
Pregled imenika usluga i udomljenika Udomitelj Dohvat specifikacija Udomljenik sučelje web udomljenika usluge Pozivi usluga Kombinirani udomljenik Korisnička interakcija Samostalni udomljenik
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
37 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.
Poslužiteljska komponenta
Imenik usluga i Pregledavanje udomljenika imenika usluga i udomljenika Dohvat specifikacija udomljenika Specifikacije udomljenika Dohvat specifikacija udomljenika
Programska ostvarenja usluga Pozivi usluga
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.
38 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.
Okidač Prikupljanje Serijalizacija Slanje podataka i podataka poruke postavki Elementi sučelja za
unos podataka Komunika- Sekundarni cijsko element za prikaz sučelje podataka prema udomitelju
Primarni element Deserijalizacija Čekanje i za prikaz podataka podataka primanje poruke
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.
39 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
40 neke greške može detektirati samo poslužitelj, primjerice greške pri dohvatu podataka s vanjskog izvora.
Okidač Prikupljanje Serijalizacija Slanje podataka i podataka poruke postavki Elementi sučelja za
unos podataka Detekcija Komunika- greške Sekundarni cijsko element za prikaz sučelje podataka prema udomitelju
Primarni element Deserijalizacija Čekanje i za prikaz podataka podataka primanje poruke
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.
Dekodiranje Okidač Prikupljanje Detekcija podataka podataka i greške Elementi postavki sučelja za unos podataka Sekundarni Obrada podataka element za prikaz podataka
Primarni element Kodiranje za prikaz podataka podataka
Slika 4.6. – Arhitektura samostalnog udomljenika
41
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.
Okidač Prikupljanje Odluka o Samostalna obrada podataka i načinu Elementi postavki obrade sučelja za unos podataka Udaljena Primarni element obrada za prikaz podataka
Sekundarni element za prikaz podataka
Slika 4.7. – Arhitektura paralelnog kombiniranog udomljenika
42
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
Okidač Prikupljanje Udaljena podataka i obrada Samostalna obrada Elementi postavki sučelja za unos podataka
Primarni element za prikaz podataka
Sekundarni element za prikaz podataka
Slika 4.8. – Arhitektura serijskog kombiniranog udomljenika
43 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.
Komunikacijsko sučelje okružja
Detekcija greški Kodiranje podataka Validacija Dekodiranje Obrada podataka postavki
Dekodiranje podataka
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
44 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.
Komunikacijsko sučelje okružja – komunikacija s udomljenikom
Detekcija Kodiranje greški podataka Dekodiranje podataka 2 Validacija Dekodiranje Lokalna podataka postavki obrada
Kodiranje Dekodiranje podataka 2 podataka
Komunikacijsko sučelje okružja – komunikacija 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
45 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
46 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 i , a sve između njih interpretira se kao podatak. Zapis poruke o greški uokviren je oznakama
47 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
48 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
49 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.
50 Google Udomljenik Udomljenik Proizvoljni finance Zagrebačke za učitavanje dodatni Dohvat udomljenik burze tablica udomljenik podataka
Izračun Razdvajanje Posebni nalozi pokazatelja tablica
Obrada Množenje Spajanje Logički podataka tablica udomljenik
Ispis tablice Iscrtavanje Dojava Prikaz grafa potrošaču podataka
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.
Udomljenik za Udomljenik za dohvat dohvat podataka podataka 2 Greška u dohvatu Udomljenik za prikaz podataka Udomljenik za Udomljenik za obradu obradu
podataka podataka 2 Konkatenacija Greška u greški obradi
Slika 5.3 - Stvaranje greške, propagacija kroz sustav i prikazivanje
51 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: "
52 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.
53 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
54 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.
55 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).
56
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
57 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.
58
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
59
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.
60
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
61 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
62 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"
63 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
64 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
65
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.
66 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
67 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.
68 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.
69 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.
70 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
71 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.
72 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.
73 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.
74 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.
75 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
76 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
77